菜单
This skill should be used when the user asks to 'check spec alignment', 'verify requirements coverage', 'detect drift', 'spec audit', or automatically at wave gates. Verifies implementation aligns with specification - different from code review which checks quality.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | opencode-spec-check |
| description | This skill should be used when the user asks to 'check spec alignment', 'verify requirements coverage', 'detect drift', 'spec audit', or automatically at wave gates. Verifies implementation aligns with specification - different from code review which checks quality. |
Read-only verification that implementation aligns with specification. Detects coverage gaps, scope creep, and requirement drift.
When to run:
/opencode-wave-gate sequence)/finalize/opencode-spec-checkNot what this does: Check code quality, style, security (that's code-reviewer's job).
Spec-check runs as part of wave-gate sequence, between test verification and code review:
Wave N complete
-> verify test evidence
-> /opencode-spec-check
-> spawn code reviewers
-> advance wave
CRITICAL findings from spec-check block wave advancement.
# Find spec
SPEC=$(ls -t .claude/specs/*/spec.md | head -1)
# Find plan (look for architecture.md or plan.md in the spec dir)
SPEC_DIR=$(dirname "$SPEC")
PLAN=$(ls "$SPEC_DIR"/architecture.md "$SPEC_DIR"/plan.md 2>/dev/null | head -1)
If a task graph JSON artifact exists on disk (from decompose phase), read it for wave/task info:
ls "$SPEC_DIR"/task-graph.json 2>/dev/null
Extract from spec:
Build mapping:
FR-001 -> {description, priority, related_scenarios}
FR-002 -> {description, priority, related_scenarios}
SC-001 -> {metric, threshold}
...
From wave tasks and git diff:
# Files changed in current wave
BASE=$(git merge-base HEAD origin/main 2>/dev/null || echo "HEAD~10")
git diff --name-only $BASE..HEAD
Extract from code:
Check every FR/SC has corresponding implementation:
| Finding | Severity |
|---|---|
| P1 requirement with no code | CRITICAL |
| P2 requirement with no code | HIGH |
| P3 requirement with no code | MEDIUM |
| Success criteria with no test | HIGH |
| Acceptance scenario with no test | MEDIUM |
Detection method:
Check for code that maps to no requirement:
| Finding | Severity |
|---|---|
| New feature not in spec | CRITICAL |
| New endpoint not in spec | HIGH |
| New entity not in spec | HIGH |
| Extra configuration | MEDIUM |
Detection method:
Check naming consistency:
| Finding | Severity |
|---|---|
| Spec says "Order", code says "Purchase" | MEDIUM |
| Spec says "User", code says "Customer" | MEDIUM |
| Inconsistent naming across files | LOW |
Detection method:
For each Given/When/Then in spec:
| Finding | Severity |
|---|---|
| Happy path scenario with no test | HIGH |
| Error scenario with no test | MEDIUM |
| Edge case scenario with no test | LOW |
Detection method:
For each SC-xxx:
| Finding | Severity |
|---|---|
| Metric claimed but no measurement | HIGH |
| Threshold exists but not tested | MEDIUM |
| SC marked complete but no evidence | CRITICAL |
Detection method:
## Spec-Check Report
**Spec:** .claude/specs/2025-01-29-user-auth/spec.md
**Wave:** 2
**Tasks Checked:** T3, T4, T5
### CRITICAL (2)
1. **Coverage Gap:** FR-003 (email validation) has no implementation
- Requirement: "System MUST validate email format"
- Expected in: T3 (auth service)
- Found: No validation logic in auth service
2. **Scope Creep:** New /api/admin endpoint not in spec
- File: src/routes/admin.ts
- Not mapped to any FR-xxx
- Not in Out of Scope (should be if intentional)
### HIGH (1)
1. **Acceptance Gap:** US1 error scenario has no test
- Scenario: "Given invalid password, When submit, Then error shown"
- Expected test: Login failure test
- Found: Only happy path tested
### MEDIUM (2)
1. **Terminology Drift:** Spec "User" vs Code "Account"
2. **Missing Metric:** SC-002 (response time) not measured in tests
### Summary
| Severity | Count |
|----------|-------|
| CRITICAL | 2 |
| HIGH | 1 |
| MEDIUM | 2 |
| LOW | 0 |
**Verdict:** BLOCKED - 2 critical findings must be resolved
Write the spec-check results to the spec directory:
SPEC_DIR=$(dirname "$SPEC")
# Write to: $SPEC_DIR/spec-check-wave-N.md
Wave advancement blocked if:
Wave advancement proceeds if:
When critical issues fixed:
/opencode-spec-check| Severity | Meaning | Blocks Wave? |
|---|---|---|
| CRITICAL | Spec violation, missing P1 requirement, scope creep | Yes |
| HIGH | Missing test coverage, P2 gaps | No (advisory) |
| MEDIUM | Terminology drift, P3 gaps | No (advisory) |
| LOW | Minor inconsistencies | No (informational) |
/opencode-spec-check # Check current wave
/opencode-spec-check --full # Check all waves
/opencode-spec-check --spec path/to/spec.md # Use specific spec
**Finding:** FR-003 has no implementation
**Fix options:**
1. Implement the requirement (spawn impl agent for affected task)
2. Defer requirement (move to Out of Scope with justification)
3. Update spec if requirement changed (requires re-approval)
**Finding:** New endpoint not in spec
**Fix options:**
1. Add requirement to spec (FR-xxx) and re-run /opencode-specify
2. Remove code if truly out of scope
3. Document in Out of Scope as "added during implementation" with rationale
Create and schedule CrossFit workouts on Garmin Connect. Use when user asks to 'create a CrossFit workout', 'make a WOD', 'build an EMOM', 'schedule a CrossFit session', 'AMRAP workout', 'Tabata', 'for time workout', or any request to create a non-running workout for Garmin.
This skill should be used when the user asks to 'design a feature', 'evaluate approaches', 'plan the architecture', 'domain modeling', 'DDD design', 'bounded contexts', 'functional core imperative shell', 'how should I structure this', 'what pattern should I use', or needs upfront architectural design for Java/Spring Boot, TypeScript/Next.js, or Rust codebases. For DESIGN decisions before implementation - not for reviewing existing code (use the architecture-agent via /review-pr for that).
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
This skill should be used when the user asks to 'implement', 'write code', 'build a feature', 'create a function', 'add functionality', 'code this', 'make this work', or needs to write production code for Java/Spring Boot or TypeScript/Next.js following FP, DDD, and testability patterns. Ensures code follows functional core/imperative shell, proper invariants, Either-based error handling, and is designed for testing without mocks.
This skill should be used when the user asks to 'specify a feature', 'write requirements', 'define what we're building', 'capture requirements', 'document the spec', or before invoking /architecture-tech-lead for non-trivial features. Produces formal specifications (WHAT/WHY) that feed into architecture and planning phases.
This skill should be used when the user asks to 'plan this', 'orchestrate', 'break down', 'split into phases', 'coordinate tasks', 'create a plan', 'multi-step feature', or has complex tasks needing structured decomposition. Decomposes work into wave-based parallel tasks, assigns specialized agents, creates GitHub Issue for tracking, and manages execution through phase artifacts on disk.