no-std-assessment

name	no-std-assessment
description	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.

no_std Compatibility Assessment

Purpose

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.

Crate Coordinates

The user provides crate coordinates in one of these forms:

• GitHub repository (most common): a repo URL, optionally with a crate name within the workspace
• Local path: a filesystem path to the crate root
• crates.io crate name: fetch source via the repository link in crate metadata

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.

Analysis Workflow

1. Obtain and Explore the Source

• Clone or locate the crate source
• Identify if it is a workspace or a single crate
• Map the structure: Cargo.toml, src/, feature flags, dependency graph

2. Run the std Usage Scanner

Execute 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:

• Presence or absence of #![no_std] / #![cfg_attr(..., no_std)]
• All use std:: imports categorized by module
• std feature flag configuration in Cargo.toml
• Risk classification of std usage (blocker / moderate / easy)
• Workspace detection and dependency listing

3. Deep Analysis of std Usage

For 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.

4. Handle Workspaces

If the target crate is part of a workspace:

• Identify all workspace members that are dependencies of the target crate
• Analyze each workspace member for no_std compatibility
• Trace the dependency graph to understand which workspace crates are actually pulled in
• Report findings per workspace member

5. Handle External Dependencies

For external (non-workspace) dependencies:

• Check if each dependency supports no_std (look for #![no_std], std feature flag, or crate documentation)
• Report any external dependency that does not support no_std
• Do NOT perform deep analysis on external crates — only report their status
• Note which external dependencies are optional or behind feature flags

6. Evaluate Strategies

For each blocker or difficulty, evaluate possible strategies:

• Feature-gating: add std / no_std feature flags to conditionally compile problematic code
• Abstraction: replace concrete std types with traits implementable for both environments
• Alternative crates: replace std-dependent crates with no_std-compatible alternatives
• Forking: fork the crate and modify for no_std support
• Upstream PR: contribute no_std support to the original repository

For each strategy, analyze:

• Pros and cons
• Estimated effort
• Feasibility of an upstream PR (check repo activity, existing no_std issues/PRs, maintainer responsiveness, last commit date)

7. Generate the Report

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).

8. Audit the Report (Mandatory)

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.

9. Deliver the Final Report

Write the audited report to the output path. Present a brief summary to the user highlighting the verdict and any blockers.

Key Principles

• ASK DON'T GUESS: if any aspect of the crate, its usage, or the analysis is unclear, ask the user before proceeding
• Be skeptical: question every assumption; think about conditional compilation, feature flags, and platform-specific code
• Depth over breadth: focus on the target crate and its workspace; report but do not deeply analyze external dependencies
• Practical focus: evaluate real-world feasibility, including community dynamics and maintenance burden

Additional Resources

Reference Files

• references/report-template.md — Complete report structure with all required sections, formatting rules, confidence level definitions, and the summary table format
• references/analysis-guide.md — Detailed guide on std module classification, common no_std patterns, replacement strategies, and PR feasibility evaluation criteria

Scripts

• scripts/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