From stn-skills
Use between pipeline phases to validate handoff artifacts against contracts. Catches incomplete specs, ambiguous criteria, and plan defects before they propagate downstream. Invoked automatically by build-feature at every boundary. Triggers: "validate handoff", "check the spec", "verify the plan".
How this skill is triggered — by the user, by Claude, or both
Slash command
/stn-skills:pipeline-handoff-validatorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Validates artifacts at pipeline boundaries before they are consumed by the next phase. Catches incomplete specs, ambiguous acceptance criteria, and plan defects before they propagate through the pipeline and compound into larger failures.
Validates artifacts at pipeline boundaries before they are consumed by the next phase. Catches incomplete specs, ambiguous acceptance criteria, and plan defects before they propagate through the pipeline and compound into larger failures.
Core principle: Artifacts at pipeline boundaries are contracts. Unvalidated contracts produce downstream failures that are harder to diagnose than the original defect.
Announce: "I'm using the pipeline-handoff-validator to check this artifact before proceeding."
EVERY ARTIFACT CROSSING A PIPELINE BOUNDARY IS VALIDATED AGAINST ITS CONTRACT.
GAPS FOUND HERE COST MINUTES. GAPS FOUND DOWNSTREAM COST HOURS.
graph TD
A{"Artifact handoff\nbetween skills?"} -->|yes| B{"Which boundary?"}
A -->|no| C["Not in scope"]
B -->|"Design spec → Plan"| D["Mode A:\nSpec Validation"]
B -->|"Plan → Execution"| E["Mode B:\nPlan Validation"]
Invoked automatically by build-feature between macro-phases.
Invoked manually when using pipeline skills individually (e.g., running plan-writing on a spec produced in a previous session).
Validates a design spec before plan-writing consumes it.
Input: Path to design spec document (typically docs/specs/YYYY-MM-DD-<topic>-design.md)
Contract checks:
| # | Check | What it validates | Pass condition |
|---|---|---|---|
| A1 | Structure | Spec follows skills/brainstorming/references/design-spec-template.md | All required sections present: Problem Statement, Success Criteria, Scope Boundaries, Selected Approach, Acceptance Criteria, Risk Register |
| A2 | Testable criteria | Every acceptance criterion has a verification method | Each criterion contains a concrete assertion (not vague goals like "should be fast") |
| A3 | Scope boundaries | Always/Ask First/Never table is defined | Table exists with at least 1 entry in each column |
| A4 | Risk coverage | Selected approach has documented risks | At least 1 risk with likelihood, impact, and mitigation |
| A5 | Assumptions resolved | No critical unverified assumptions | Zero assumptions marked "Unverified" that gate a design decision |
| A6 | Approach clarity | Selected approach has sufficient detail for decomposition | Approach section contains specific technology choices, not abstract patterns |
Procedure:
Validates a plan document before plan-execution consumes it.
Input: Path to plan document (typically .plan/plan-{YYYYMMDD}-{slug}.md)
Contract checks:
| # | Check | What it validates | Pass condition |
|---|---|---|---|
| B1 | Structure | Plan follows skills/plan-writing/references/plan-document-template.md | All required sections present: Metadata, Requirements, File Structure, Tasks, DAG, Waves |
| B2 | Quality score | Plan passed adversarial verification | Plan Quality Score documented and >= 90 |
| B3 | Rollback blocks | Every task has a rollback strategy | Each task contains a rollback block with specific commands |
| B4 | DAG integrity | No circular dependencies | Mermaid graph parseable, no cycles in dependency chain |
| B5 | File structure | Lock-In table present | File Structure Lock-In table exists with Action column (CREATE/MODIFY) |
| B6 | Zero placeholders | No placeholder patterns in code blocks | Scan all code blocks against skills/plan-writing/references/placeholder-detector-rules.md patterns: zero matches |
| B7 | Requirements traced | Every requirement maps to at least one task | Traceability matrix present with R(N) → T(M) mappings, no orphans |
Procedure:
skills/plan-writing/references/placeholder-detector-rules.mdBoth modes produce a Handoff Compliance Table displayed to the user:
## Handoff Compliance — [Mode A: Spec / Mode B: Plan]
**Artifact:** `<file path>`
**Validated:** <timestamp>
| # | Check | Result | Detail |
|---|-------|--------|--------|
| A1/B1 | Structure | PASS/GAP | [missing sections or "all sections present"] |
| A2/B2 | ... | PASS/GAP | [specific evidence] |
| ... |
**Verdict:** READY / GAPS FOUND (N gaps)
If gaps are found, each gap includes:
The build-feature skill invokes this validator automatically:
If the validator reports gaps:
| Excuse | Reality |
|---|---|
| "The spec was just written, it's fine" | Freshness does not equal completeness. Validate. |
| "Plan-writing will catch any issues" | Plan-writing assumes valid input. Garbage in, garbage out. |
| "This is a simple feature, validation is overkill" | Simple features with unclear acceptance criteria produce the most rework. |
| "I can see the spec has all sections" | Seeing sections is not the same as verifying their content. Read them. |
| "The user already approved the spec at GATE 4" | User approval validates direction. Contract validation checks completeness. Different concerns. |
| "Validation slows down the pipeline" | Catching gaps here takes minutes. Catching them during execution takes hours. |
npx claudepluginhub sthiermann/stn-skills --plugin stn-skillsReviews planning artifacts like requirements, data models, API contracts for gaps in analysis and design phases. Classifies issues by severity for quality gates before proceeding.
Analyzes specs and plans for soundness before sign-off. Auto-fixes inferrable issues and surfaces design decisions for review.
Validates AI developer workflow steps (plan, build, review, fix) against contracts by checking specs, git commits, builds, tests via bash/git.