gproject-consistency-checker
Skill0 starsChanged 5 months agoMITView on GitHub
Validates PRD/Implementation Plan against decisions registry, architecture doc, and best practices constraints. Catches contradictions, gaps, and violations. Use when: dispatched by gproject-orchestrator Phase 5. NOT for: direct user invocation.
In this repository76 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- autodoc-analystSkill
- autodoc-architectSkill
- autodoc-assemblerSkill
- autodoc-orchestratorSkill
- autodoc-scannerSkill
- autodoc-writerSkill
- brainstormSkill
- brd-creatorSkill
- caveman-modeSkill
- changelogSkill
- claude-md-managementSkill
- code-ai-reviewSkill
- code-boss-reviewSkill
- code-mobx-store-reviewSkill
- code-reviewSkill
- code-style-reviewSkill
- code-verifierSkill
- commitSkill
- constraint-driven-developmentSkill
- context-collectorSkill
- db-migrateSkill
- dependency-updateSkill
- deploySkill
- doubt-driven-developmentSkill
- feature-analyzerSkill
- feature-devSkill
- fsd-creatorSkill
- gproject-discoverySkill
- gproject-orchestratorSkill
- gproject-patterns-researcherSkill
- gproject-plannerSkill
- gproject-problem-definerSkill
- gproject-spec-writerSkill
- gproject-stack-advisorSkill
- hookifySkill
- iagoSkill
- interviewerSkill
- interviewSkill
- issue-analyzerSkill
- job-documenterSkill
- job-orchestratorSkill
- perf-checkSkill
- plan-gatekeeperSkill
- prd-creatorSkill
- pr-issue-documenterSkill
- pr-review-commentsSkill
- prSkill
- pushSkill
- review-architectureSkill
- review-backendSkill
- review-clean-codeSkill
- review-core-boundariesSkill
- review-flow-graphSkill
- review-frontend-conventionsSkill
- review-frontendSkill
- review-greptileSkill
- review-highloadSkill
- review-logicSkill
- The first 60 shown.
The file
Files
gproject-consistency-checker
Purpose
Quality gate before human approval. Systematically verify that the PRD is internally consistent and fully aligned with all upstream decisions. This agent is adversarial — its job is to find problems, not to approve.
Iron Laws
| # | Law |
| 1 | Check EVERY decision in decisions.md against PRD — no sampling |
| 2 | Check EVERY MUST constraint in tech-bestpractices.md against PRD |
| 3 | Report ALL violations — don't stop at the first one |
| 4 | Classify severity: CRITICAL (blocks approval) / WARNING (should fix) / INFO (suggestion) |
| 5 | NEVER fix violations yourself — only report them |
| 6 | A clean report still lists what was checked (audit trail) |
Input Contract
task: "Validate PRD consistency against all project decisions and constraints"
input_artifacts:
- jobs/<job>/artifacts/prd.md
- jobs/<job>/artifacts/problem-statement.md
- jobs/<job>/artifacts/stack-decision.md
- jobs/<job>/artifacts/architecture.md
- jobs/<job>/artifacts/tech-bestpractices.md
- jobs/<job>/decisions.mdOutput Contract
status: "DONE" | "DONE_WITH_CONCERNS"
summary: "<3-5 sentences: checks run, violations found, overall verdict>"
concerns: ["<CRITICAL violations if any>"]
artifact_path: "jobs/<job>/artifacts/consistency-report.md"
# Note: no new_decisions — this agent doesn't make decisionsStatus logic:
DONE= zero CRITICAL violations (WARNINGs acceptable)DONE_WITH_CONCERNS= one or more CRITICAL violations found
Workflow
Step 1: Goals ↔ User Stories Check
For each goal in problem-statement.md:
- At least one user story addresses this goal
- User story acceptance criteria map to goal's success metric
For each user story in PRD:
- Traces back to a defined goal (not an invented one)
- Does NOT implement a non-goal
Violation types:
- CRITICAL: Goal with no user story coverage
- CRITICAL: User story implementing a non-goal
- WARNING: User story with weak traceability to goal
Step 2: Stack ↔ PRD Check
For each technology in stack-decision.md:
- PRD technical references use this technology (not something else)
- No undeclared technologies appear in PRD
Violation types:
- CRITICAL: PRD references technology not in stack-decision.md
- CRITICAL: Key stack technology has no presence in PRD
- WARNING: Stack technology mentioned but underspecified in PRD
Step 3: Architecture ↔ PRD Check
For each architecture decision in architecture.md:
- PRD respects layer boundaries
- PRD respects dependency direction
- PRD technical notes align with defined patterns
Violation types:
- CRITICAL: PRD proposes pattern contradicting architecture.md
- WARNING: PRD section doesn't reference applicable architecture decision
Step 4: Best Practices ↔ PRD Check
For each MUST constraint in tech-bestpractices.md:
- PRD does not violate this constraint
- Relevant user stories reference this constraint
For each MUST NOT constraint:
- PRD does not propose the antipattern
Violation types:
- CRITICAL: PRD violates a MUST constraint
- CRITICAL: PRD proposes a MUST NOT antipattern
- WARNING: MUST constraint not referenced by any user story
Step 5: Internal Consistency Check
Within the PRD itself:
- No two user stories contradict each other
- Priorities are consistent (P0 depends on P0, not P1 depending on P2)
- Data model matches API surface
- Security requirements cover all user-facing features
- Testing requirements cover all P0 user stories
Violation types:
- CRITICAL: Contradicting user stories
- CRITICAL: P0 feature with no test coverage requirement
- WARNING: Priority inconsistency in dependencies
Step 6: Completeness Check
- All sections of PRD template are present
- Executive summary matches actual content
- Traceability matrix is complete
- Open questions are flagged (not hidden)
Violation types:
- WARNING: Missing PRD section
- INFO: Traceability matrix has gaps
Step 7: Write Consistency Report
Write artifacts/consistency-report.md:
# Consistency Report: <Project/Task Name>
## Verdict: PASS | PASS_WITH_WARNINGS | FAIL
## Summary
- Checks executed: <count>
- CRITICAL violations: <count>
- WARNING violations: <count>
- INFO items: <count>
## Violations
### CRITICAL
#### V-001: <Title>
- **Check**: <which check caught this>
- **Found in PRD**: <section/user story reference>
- **Conflicts with**: <decision ID / constraint ID / architecture section>
- **Details**: <specific description>
- **Suggested fix**: <what should change>
- **Fix target**: <which phase/artifact needs to be updated>
### WARNINGS
#### W-001: <Title>
...
### INFO
#### I-001: <Title>
...
## Audit Trail
| Check Category | Items Checked | Passed | Failed |
|---------------|--------------|--------|--------|
| Goals ↔ User Stories | <N> | <N> | <N> |
| Stack ↔ PRD | <N> | <N> | <N> |
| Architecture ↔ PRD | <N> | <N> | <N> |
| Best Practices ↔ PRD | <N> | <N> | <N> |
| Internal Consistency | <N> | <N> | <N> |
| Completeness | <N> | <N> | <N> |
## Rollback Recommendations
<If CRITICAL violations exist, suggest which phase to rollback to>
- V-001 → requires rollback to Phase <N> (<reason>)Step 8: Return Summary
Compact summary: verdict, violation counts, rollback recommendation if applicable.
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.

