forge-validate
Skill2 starsChanged 5 months agoMITView on GitHub
Run a full pipeline gap analysis and confirm traceability end-to-end —
2 other projects use a version of this.
Adopted by
Most recently taken up by
- TT-Wang/forgetheir own version, first seen Nov 1, 2026
- luminary19/ateliertheir own version, first seen Jun 27, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- TT-Wang/forge★ 34same name
- luminary19/atelier★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository46 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- forge-opencode/CLAUDE.mdCLAUDE.md
- forge-adoptSkill
- forge-arch-proSkill
- forge-archSkill
- forge-autopilotSkill
- forge-autopilot-stopSkill
- forge-build-proSkill
- forge-buildSkill
- forge-deploySkill
- forge-doctorSkill
- dreamer-runSkill
- forge-evalSkill
- forge-feedbackSkill
- flowSkill
- forge-force-advanceSkill
- graduateSkill
- health-checkSkill
- forge-initSkill
- forge-monitorSkill
- forge-orchestrateSkill
- forge-plan-proSkill
- forge-planSkill
- preflightSkill
- forge-product-proSkill
- forge-productSkill
- forge-releaseSkill
- forge-resolveSkill
- forge-resumeSkill
- forge-retroSkill
- forge-reviewSkill
- forge-rulesSkill
- forge-set-profileSkill
- skill-creatorSkill
- forge-spec-proSkill
- forge-specSkill
- forge-sprint-proSkill
- forge-sprintSkill
- forge-srs-proSkill
- forge-srsSkill
- forge-statusSkill
- forge-trace-matrixSkill
- forge-uninstallSkill
- watchSkill
- watch-stopSkill
- forge-whySkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 24
Before a gate check or /forge:release, to catch drift the mechanical per-stage gates don't check (e.g.
- Very specific: line 27
After a big edit to pipeline//*.md (renamed/renumbered requirements, merged docs) to confirm nothing broke the ID chain.
- Very specific: line 40
Read pipeline/state.md to confirm this is a Forge project.
- Distinctive: line 71
If the user wants a saved copy instead of (or in addition to) the chat output:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/forge:validate — pipeline gap analysis & traceability confirmation
/forge:validate runs scripts/validate-traceability.py, which combines four checks
the per-stage gate scripts don't cover (malformed IDs, misplaced ID definitions,
duplicate ID definitions, unimplemented/orphaned requirements) with a rollup of the
existing traceability and gate-completeness scripts, into one report.
When to Use
/forge:validate— run the full report now.- Before a gate check or
/forge:release, to catch drift the mechanical per-stage gates don't check (e.g. a requirement defined but never picked up by any task). - After a big edit to
pipeline/**/*.md(renamed/renumbered requirements, merged docs) to confirm nothing broke the ID chain. - The user explicitly asks about traceability, ID hygiene, or gap analysis.
When NOT to Use
- A single stage's gate → that's
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/check-gate.py --stage N(via/forge:statusor the stage's own skill), not this. - The user wants the pipeline actually advanced →
/forge:orchestrateor the specific stage's/forge:*command.
Pre-flight Check
Read pipeline/state.md to confirm this is a Forge project. If it doesn't exist,
tell the user to run /forge:init first and stop — an uninitialized project has no
pipeline/ directory for this to scan.
Steps
- Run the report:
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/validate-traceability.py --cwd . \ --plugin-dir ${CLAUDE_PLUGIN_ROOT} - Present the full markdown report verbatim. It has two parts:
- Traceability & Gate Rollup — pass/fail per existing script
(
traceability-check.py --full-chain, DAG completeness/completion, SRS acceptance, spec coverage, NFR coverage, progress sync, TODO ticketing). - Four gap-analysis sections — Malformed IDs, Misplaced ID Definitions, Duplicate ID Definitions, Unimplemented / Orphaned Requirements — each with a count and, when non-empty, the exact id/file/reason for every finding.
- Traceability & Gate Rollup — pass/fail per existing script
(
- Interpret the Status line for the user:
- CLEAN — every rollup check passed and all four gap-analysis sections are empty. No action needed.
- ISSUES FOUND — walk through each non-empty section and suggest the fix:
- Malformed: rename the id to the canonical form the detail line names.
- Misplaced: either move the definition into its home doc, or if the second occurrence is meant to be a reference (not a new definition), drop it down from a heading to inline prose.
- Duplicate: the two blocks under the same heading id likely diverged — merge them or renumber the second one.
- Unimplemented: either add the missing downstream reference (a task, a progress row, an eval entry) or confirm with the user it's genuinely out of scope and should be marked as such in the SRS.
- If the user wants a saved copy instead of (or in addition to) the chat output:
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/validate-traceability.py --cwd . \ --plugin-dir ${CLAUDE_PLUGIN_ROOT} --out pipeline/validation-report.md
Verification
- Exit code 0 = clean (every rollup check passed, all four gap sections empty), non-zero = at least one issue.
- Re-running after fixes should show fewer (ideally zero) findings in the sections that were addressed — re-run to confirm rather than assuming a fix worked.
- The rollup section's pass/fail matches what
check-gate.pywould report for the relevant stage — this report doesn't invent new gate semantics, it aggregates the existing ones plus the four new checks.
Examples
User: "/forge:validate"
Claude: [runs the script] "Traceability report — ISSUES FOUND:
- ✅ Traceability chain, DAG completeness, SRS acceptance, TODO ticketing
- ❌ NFR coverage — NFR-002 never evaluated
- Malformed IDs (1):
REQ-7inpipeline/01-srs/srs.md— expected 3-digit id - Unimplemented (1):
REQ-014inpipeline/01-srs/srs.md— never referenced in task-dag.md, progress.md, or eval-report.md
Two things to fix: rename REQ-7 → REQ-007, and either scope REQ-014 into a task or mark it explicitly out-of-scope."
User: "/forge:validate" (on a clean project)
Claude: [runs the script] "CLEAN — traceability chain intact, all gate-completeness checks pass, and no malformed, misplaced, duplicate, or orphaned IDs found."
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

