claude-context: Skill for Claude Code

/spec-review

Vault paths (DEVS-78): resolve once per session with vault-path (~/.local/bin/vault-path). PROJECT_VAULT=$(vault-path project) is <repo>/DocVault/, and edits ride the current branch and PR. SHARED_VAULT=$(vault-path shared) is usually /Volumes/DATA/GitHub/Devops/DocVault/, and edits commit directly to Devops main (DocVault/** only). Sensitive pages from public repos go in $(vault-path private).

You are the peer reviewer for a single phase of an active /spec. This is the reviewer-side skill; the originating agent invoked /spec review <ISSUE-ID> <phase> <your-name> and handed you a pointer to this skill instead of pasting a long prompt.

Invocation

/spec-review <ISSUE-ID> <phase> [REVIEWER-TAG]

• <ISSUE-ID> — the issue prefix and number, e.g. STRK-123, STAK-457.
• <phase> — one of requirements, discovery, approach, tasks.
• [REVIEWER-TAG] — optional. The uppercase tag used to prefix your comments (e.g. OPUS, GEMINI, DEEPSEEK, KIMI, CODEX). If omitted, you will be prompted.

If ISSUE-ID or phase is missing, print:

Usage: /spec-review <ISSUE-ID> <phase> [REVIEWER-TAG]
       phase ∈ requirements | discovery | approach | tasks
       REVIEWER-TAG — uppercase label for your review blocks (e.g. OPUS, GEMINI, KIMI)

…and exit. Do not guess.

Hard gates (run in order; fail fast)

1. Resolve the spec directory. It lives at {specs-root}/{ISSUE-ID}-{slug}/, in-repo (the worktree's copy when run from a worktree). Resolve {specs-root} per .agents/skills/spec/references/conventions.md → Folder resolution (specs.path in .claude/project.json, default DocVault/specs). Glob for {specs-root}/{ISSUE-ID}-* (ignore archive/) — there should be exactly one match. If zero or multiple, STOP and print the candidates.
2. Locate the target file. {SPEC_DIR}/{phase}.md. If absent, STOP: "Phase {phase} has not been drafted yet for {ISSUE-ID}." Read the phase files it depends on too (discovery → requirements; approach → requirements + discovery; tasks → all four), plus AGENTS.md and .context/GLOSSARY.md if present.
3. Establish your reviewer tag ({{COMMENT_PREFIX}}). Do NOT auto-detect or guess based on model name — models misidentify themselves across harnesses.
   • If a REVIEWER-TAG argument was supplied on invocation, use it as-is (uppercase).
   • Otherwise, ask the user: "What tag should I use for this review? (e.g. OPUS, GEMINI, DEEPSEEK, KIMI, CODEX)" — wait for their answer before continuing.
   • This tag appears in every > {{COMMENT_PREFIX}}: comment and the ## {{COMMENT_PREFIX}} Review section header.
4. Detect existing peer reviews without blocking new reviewers. Scan the target file for inline > {prefix}: blocks or ## {prefix} Review sections NOT nested under ## Review Archive.
   • If unreconciled review from other reviewers is present, keep going. Preserve those comments exactly and add your own {{COMMENT_PREFIX}} comments alongside them. Multiple peer reviewers are expected to update the same phase file before reconciliation.
   • If unreconciled review from your own {{COMMENT_PREFIX}} is already present, STOP: "Review from {{COMMENT_PREFIX}} is already present in {phase}. Ask the human whether to rerun this reviewer or reconcile first."
   • Do not tell the human to run /spec reconcile just because OPUS, DEEPSEEK, GEMINI, KIMI, CODEX, or another peer reviewer has already left comments. Reconciliation happens once, after all requested peer reviews have updated the file.