SPARV Five-Phase Workflow
A Specify→Plan→Act→Review→Vault workflow with external memory files that pushes vague requirements through to verifiable delivery in one pass, instead of coding on assumptions.
Positives: EHRB high-risk detection mandates explicit user confirmation, PreToolUse hook runs --dry-run (prompt only), scripts operate only within project-local .sparv/, no network egress, no credential access, least-privilege scope. Deducted: PostToolUse hook silently runs save-progress.sh after every tool call with coarse consent; init-session.sh --force is used without explaining overwrite consequences; no rollback/cleanup path for .sparv/ state documented; publisher unverified and attribution only reaches a personal email.
Positives: shown scripts (check-ehrb.sh, failure-tracker.sh, changelog-update.sh, archive-session.sh) have solid argument validation, clear error output and defined exit codes with diagnosable failure messages. Deducted: static read cannot execute anything; SKILL.md places state at .sparv/state.yaml root while archive-session.sh looks for sessions under .sparv/plan/<session_id>/ — an internal inconsistency; init-session.sh, save-progress.sh, reboot-test.sh and lib/state-lock.sh are absent from evidence so key paths are unverifiable; repo CI covers only codeagent-wrapper, not sparv.
Positives: target scenario (per-project requirements-to-delivery), /sparv trigger, Quick/Full routing conditions, and fixed phase names are all explicitly declared; EHRB patterns include Chinese keywords. Deducted: no declared non-fit boundaries (non-software tasks, projects without TDD); the subjective 10-point Specify gate may cause false triggers or stalling in Specify; no Chinese-language documentation.
Positives: well-layered SKILL.md/README, install/uninstall commands, version 1.1.0 consistent with plugin., script usage help and examples, repo-level AGPL-3.0 LICENSE. Deducted: no per-skill CHANGELOG or version history (only a tool to write one); maintenance responsibility and update path rest on an unverified repository; hooks swallow errors with || true — a hidden assumption.
Positives: the combination of external memory (journal/state), failure escalation, and risk confirmation plausibly reduces blind iteration; the value claim is clearly articulated. Deducted: static review cannot confirm outputs are directly usable; the value depends on LLM self-scored spec numbers, and the correlation between the >=9 gate and delivery quality is unproven; marginal benefit over running the agent directly is argued only at the documentation level.
Positives: methodology is cross-consistent across SKILL.md/README/methodology.md, and script sources are auditable. Deducted: no sparv-specific test suite or execution records; visible CI tests only codeagent-wrapper and cannot corroborate this skill's key paths; no third-party execution evidence, so within static caps only a low score is warranted.
- Session directory conventions conflict between SKILL.md (.sparv/state.yaml) and archive-session.sh (.sparv/plan/<id>/); verify the actual init structure before use.
- Hooks run silently after every tool call (errors swallowed with || true), and init-session.sh --force may overwrite existing .sparv/ state — prefer --dry-run or a backup first.
- The 10-point Specify gate is LLM-self-scored and may cause repeated questioning or stalling on ambiguous requirements; publisher is not registry-verified.
- Repository CI does not cover sparv scripts; this assessment is a purely static review with no execution verification.
What does this skill do, and when should you use it?
SPARV is a skill inside the stellarlinkco/myclaude repository, located at skills/sparv/. It structures development tasks into five fixed phases — Specify, Plan, Act, Review, Vault — and enforces a 10-point spec gate (score ≥9 required before planning) so requirements are clarified up front. During execution it maintains external memory in .sparv/state.yaml and journal.md, auto-saving progress every 2 tool calls, and escalates to the user after 3 consecutive failures or when high-risk operations (production, sensitive data, billing APIs, etc.) are detected. Version 1.1 adds uncertainty declaration, a Quick/Full routing choice, and knowledge-base maintenance.
Runs init-session.sh in the project root to create .sparv/state.yaml (state machine) and journal.md (unified log); scores requirements 0-10 across five dimensions (value, scope, acceptance, boundaries, risk) and keeps asking questions below 9; in Plan, breaks work into 2-5 minute atomic tasks written to the journal; in Act, enforces TDD (no production code without a failing test), auto-appends the journal via a PostToolUse hook running save-progress.sh every 2 actions, scans diffs for high-risk changes via a PreToolUse hook running check-ehrb.sh, and tracks consecutive failures with failure-tracker.sh (exit code 3 on the third); in Review, performs two-stage spec-conformance and code-quality checks with a 3-round fix cap, then runs reboot-test.sh (3-question self-check); in Vault, archives the session with archive-session.sh into .sparv/history/, optionally updates the .sparv/kb.md knowledge base and CHANGELOG via changelog-update.sh.
- A solo developer handed a vague feature request who wants acceptance criteria and boundaries clarified before any code is written
- A team that wants AI coding sessions to leave an auditable decision trail instead of context scattered across chat history
- Changes touching production, sensitive data, or billing APIs where a mandatory human confirmation gate is required
- TDD practitioners who want the model held to a 'failing test first' discipline
- Long sessions interrupted mid-work that need fast context recovery via journal.md and the 3-question reboot test
What are this skill's strengths and limitations?
- The 10-point spec gate and uncertainty declarations materially reduce the model starting work on wrong assumptions
- journal.md + state.yaml provide structured external memory that is traceable across sessions
- EHRB high-risk detection and the 3-failure escalation protocol are built-in guardrails
- Six bundled shell scripts mean rules are script-enforced, not just prose
- Quick/Full routing lets small tasks skip the full five-phase ceremony
- The automatic hooks (2-action save, EHRB diff scan, Stop self-check) depend on Claude Code's hooks mechanism and need manual rework on other clients
- All script paths are hardcoded to ~/.claude/skills/sparv/scripts/ and break under a different install directory
- No test suite or independent usage evidence for the sparv skill is provided in the README
- The gating process is heavy for tiny tasks; Quick mode skips Plan but still demands journaling and review
- The repository is AGPL-3.0; closed-source commercial use requires a commercial license from the author
How do you install this skill?
Install the collection: run npx github:stellarlinkco/myclaude (interactive installer) or npx github:stellarlinkco/myclaude --list to list installable items. The skill lands in ~/.claude/skills/sparv/. You can also toggle it in config. via "sparv": {"enabled": true}. Whether the sparv skill can be installed standalone is undocumented — it ships inside the sparv module and is not in the standalone skills list.
How do you use this skill?
After installation, invoke it in Claude Code with the /sparv command. First run ~/.claude/skills/sparv/scripts/init-session.sh --force in the project root to create .sparv/; then proceed through Specify (answer scoring questions, reach ≥9 and write a completion_promise), Plan, Act, Review, Vault. The 2-action save, EHRB scan and reboot test run automatically via hooks defined in hooks/hooks., provided those hooks are wired into Claude Code's settings..
How does this skill compare with similar options?
Within the same repo, the do skill is README-recommended as the default (5-phase feature development with codeagent multi-backend orchestration) and omo focuses on multi-agent routing. If you only want a disciplined spec process without multi-backend execution, sparv is lighter; for feature development across multiple AI backends, do fits better.