amigo-labs

Lightweight bugfix workflow. No full spec needed — just find the root cause, fix it, add a regression test, and commit. Use for bugs, not for new features.

Reverse-engineer a spec from existing code. Explores the codebase for a given area/feature and generates a spec that documents what's already implemented. Use to create specs for legacy code or to establish a baseline.

Implement a feature based on an existing spec from docs/specs/. Reads the spec, implements in 3 gated phases (contract, code, verify+commit). Use after /spec.

Collaboratively create or update a feature spec. Creates a new spec if none exists, or updates an existing one when requirements change. Use for new features and significant changes — not for bugfixes.

Verify a spec against the codebase and update its status. Without argument runs a general project consistency check. Use "all" for full audit before releases.

Create a spec or ADR for a new feature, module, or architectural change. Uses the project's templates and conventions. Output goes to specs/active/.

Use when implementing features, refactoring, or extending code. Drives verified development: designs with specs or ADRs, extracts testable acceptance criteria, implements iteratively, and verifies completeness before declaring done.

Audit and fix crate/package consistency in the amigo-native monorepo. Use whenever new crates are added, branches are merged that introduced new crates, or you need to verify every crate follows the reference conventions established by argon2/csv/sanitize-html/slugify/xxhash. Checks __conformance__ test infrastructure (parity.spec.ts/upstream.spec.ts + fuzz.spec.ts), package.json scripts (test:conformance, test:all) and dev-deps (fast-check), README presence, npm/ platform-stub directories (6 NAPI targets), docs/packages.json registration with all metadata fields, and marquee PACKAGES count. Flags the legacy __parity__/test:parity convention as outdated. After reporting gaps, this skill offers to apply the fix plan interactively — mechanical fixes (renames, script patches, npm stubs) get applied automatically, content fixes (README, docs entries, fuzz tests) get generated as templates the user reviews. Run this before publishing, before opening PRs that add crates, after merging feature branches, or when CI f

Evaluate a single package against the amigo-native perf-review framework and decide keep-great-or-kill. Takes one package name (argument or prompted) and auto-detects the mode — an existing `crates/*` entry gets a measurement-based Green/Yellow/Red/Black classification with a Phase-C optimization plan or a Phase-D deprecation path, while an unknown npm name gets a candidate assessment with FFI-overhead heuristics, a BACKLOG check, a scan for a usable Rust crate, and a go/no-go prediction. Output is a single decision doc at `docs/perf-review/<pkg>.md`; the skill never touches crate source, benchmarks, docs/packages.json, or BACKLOG.md. Use when deciding whether to port a new npm package, when a released crate looks weak in docs/data.json, before deprecating or archiving a package, or for the quarterly re-review of already-shipped crates.