From hl-design-systems
This skill should be used when the user asks to "analyze a crate for no_std", "assess no_std compatibility", "check if a crate supports no_std", "evaluate no_std support", "no_std assessment report", "can this crate compile with no_std", "no_std feasibility", "what std dependencies does this crate have", or mentions evaluating a Rust crate or library for `no_std` compilation support.
npx claudepluginhub horizenlabs/hl-claude-marketplace --plugin hl-design-systemsThis skill uses the workspace's default tool permissions.
Analyze a Rust crate to determine if it can compile with `no_std` support. When direct
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Performs token-optimized structural code search using tree-sitter AST parsing to discover symbols, outline files, and unfold code without reading full files.
Analyze a Rust crate to determine if it can compile with no_std support. When direct
no_std compilation is not possible, evaluate strategies to achieve compatibility —
including feature-gating, forking, or contributing upstream PRs — with a structured
report and independent audit.
The user provides crate coordinates in one of these forms:
If the coordinate is a GitHub repo, clone it to a temporary directory for analysis. If a crate name on crates.io, look up the repository URL from the crate's metadata page and clone that.
If the coordinate format is ambiguous, ask the user before proceeding.
Cargo.toml, src/, feature flags, dependency graphExecute the bundled scanner script for an automated first pass:
bash ${CLAUDE_PLUGIN_ROOT}/skills/zkverify-verifier-assessment/no-std-assessment/scripts/scan-std-usage.sh <path-to-crate>
The script reports:
#![no_std] / #![cfg_attr(..., no_std)]use std:: imports categorized by modulestd feature flag configuration in Cargo.tomlFor each std usage found, classify it using the quick reference table:
| Category | std Modules | no_std Alternative | Difficulty |
|---|---|---|---|
| Core types | fmt, ops, cmp, convert, marker | core::* | Trivial |
| Collections | collections, vec, string, boxed | alloc::* (requires alloc) | Easy |
| Synchronization | sync | spin, critical-section, portable-atomic | Moderate |
| Error handling | error::Error trait | Custom or core::error (nightly) | Moderate |
| I/O | io, fs, net | No direct replacement | Blocker |
| Threading | thread | No direct replacement | Blocker |
| Time | time | Platform-specific | Moderate |
| Environment | env, process | No replacement | Blocker |
Consult references/analysis-guide.md for detailed classification, common patterns,
and replacement strategies.
If the target crate is part of a workspace:
no_std compatibilityFor external (non-workspace) dependencies:
no_std (look for #![no_std], std feature flag,
or crate documentation)no_stdFor each blocker or difficulty, evaluate possible strategies:
std / no_std feature flags to conditionally compile problematic codestd types with traits implementable for both environmentsstd-dependent crates with no_std-compatible alternativesno_std supportno_std support to the original repositoryFor each strategy, analyze:
no_std issues/PRs,
maintainer responsiveness, last commit date)Produce the report following the template in references/report-template.md.
Default output path: reports/<crate-name>-no-std-assessment.md
Allow the user to specify a different path. Create the reports/ directory if needed.
If a report already exists at the target path, ask the user whether to overwrite it or
append a timestamp to the new filename (e.g., <crate-name>-no-std-assessment-20260316.md).
Before presenting the final report, spawn a subagent to audit it. The audit agent MUST operate with a clean context — no inherited bias from the analysis work.
Spawn the audit agent using the Agent tool with this structure:
Audit this no_std compatibility assessment report for the Rust crate at <source-path>.
Instructions:
1. Read the draft report below
2. Independently examine the crate source code to verify each conclusion
3. For each conclusion in the breakdown and summary sections:
- Verify it against the actual source code
- Assign a confidence percentage
- Label: GOOD (>90%), REASONABLE (70-90%), POOR (<70%)
4. Be skeptical — challenge every assumption
5. If a conclusion cannot be verified from the source, mark it POOR
6. Return the report with confidence ratings added to every conclusion
Draft report:
<full report content>
After the audit completes, integrate the confidence ratings into the final report.
Write the audited report to the output path. Present a brief summary to the user highlighting the verdict and any blockers.
references/report-template.md — Complete report structure with all required
sections, formatting rules, confidence level definitions, and the summary table formatreferences/analysis-guide.md — Detailed guide on std module classification,
common no_std patterns, replacement strategies, and PR feasibility evaluation criteriascripts/scan-std-usage.sh — Automated scanner for std usage patterns in Rust
source files; run against the crate root to get a categorized first-pass report