mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 13:01:50 +00:00
* Add /vertical-slice skill, prototype overhaul, and workflow integration - Add /vertical-slice skill for pre-production validation (Phase 4 gate) - Overhaul /prototype skill with two-mode design: concept prototype (Phase 1) vs vertical slice (Phase 4), with clearer differentiation and higher standards for VS - Update prototyper agent to own both prototype and vertical-slice workflows - Add prototype-report.md and vertical-slice-report.md output templates - Update WORKFLOW-GUIDE, quick-start, skills-reference, agent-coordination-map, and skill-flow-diagrams to fully integrate both skills into the 7-phase pipeline - Remove orphaned empty quick-prototype/ directory Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * sync v1 counts + polish Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add entity inventory flow, relax vertical-slice gate, improve UX authoring prompts - /asset-spec: new Phase 0b entity & screen inventory when no argument and no existing inventory — reads GDDs/art-bible, proposes categorized list, writes design/assets/entity-inventory.md collaboratively - /asset-spec: entity/character target falls back to inline user description when no source doc exists, rather than failing - /gate-check: vertical slice changed from blocking to CONCERNS-only when absent; built-but-broken slice still fails; adds entity inventory as gate artifact - /ux-design: convert inline approval prompts to AskUserQuestion for structured option capture at key authoring decision points - workflow-catalog.yaml: entity-inventory step added to pre-production; UX spec min_count raised to 3; vertical-slice and prototype marked required: false with updated descriptions - .gitignore: exclude marrow/ eval tooling directory Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Add missing AskUserQuestion widgets to 7 skills Audit found 11 decision points across 7 skills where structured option prompts were missing — using plain text, auto-selection, or no gate at all. Skills patched: - create-epics: per-epic approval + producer CONCERNS verdict - sprint-plan: producer CONCERNS verdict with scope/timeline options - milestone-review: AT RISK / OFF TRACK producer verdicts require acknowledgement - retrospective: existing-retro handling converted from plain text [A]/[B] - quick-design: classification confirmation + draft approve/revise/redirect - tech-debt add mode: category (6 options) + effort (S/M/L/XL) structured capture - regression-suite: no-arg mode selection instead of silent auto-detect - hotfix: severity confirmation gate before workflow begins Also added AskUserQuestion to allowed-tools headers for retrospective, quick-design, tech-debt, regression-suite, and hotfix. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Prep v1 stable: fix WORKFLOW-GUIDE counts, stale agent names, and skill model fields - WORKFLOW-GUIDE.md: correct agent count (48→49), skill count (66/68→73), add 6 missing skills to Appendix B, fix Creative category count (2→4), replace 3 non-existent agent names with correct ue-*/unity-* specialists, add missing godot-csharp/gdextension specialists to hierarchy, fix production/stories/ paths → production/epics/ - coordination-rules.md: replace "not yet used" with opt-in env var note - quick-start.md: rename duplicate "Validate the concept" label → "Prototype the mechanic" - skill-flow-diagrams.md: remove duplicate legacy UX pipeline section - All 62 skills missing model: field now have explicit model: sonnet Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: comprehensive skill audit — consistency, UX, and flow gaps Two-pass audit fixing ~35 bugs across 41 files. Pre-production flow: - Brainstorm next-steps split into Path A (design-first) and Path B (prototype-first) — eliminates "prototype after architecture" confusion - /architecture-review added to pre-production flow in brainstorm and create-architecture handoffs - gate-check traceability check corrected to requirements-traceability.md - dev-story TR registry error now points to /architecture-review (not /create-epics) - start now writes production/stage.txt on first onboarding AskUserQuestion gaps filled: - balance-check, code-review, hotfix, day-one-patch, consistency-check all gain closing widgets and/or missing allowed-tools declarations - hotfix git branch creation now requires user confirmation - sprint-plan review-mode setup moved to Phase 0 (before gates run) - team-combat gains architecture→implementation approval gate - design-review APPROVED path consolidated from 3 widgets to 1 multiSelect All 9 team-* skills: - Phase 0 review-mode resolution added (solo/lean/full now respected) - team-audio output path fixed (design/gdd/ → design/audio/) - team-level final doc compilation delegated to level-designer subagent - team-narrative localization-lead added to composition list - team-qa sprint path fixed (flat files, not directories) - team-release NO-GO override captures written justification - team-live-ops Cancel verdict now explicitly BLOCKED Other fixes: - Art bible path standardized to design/art/art-bible.md (3 wrong refs) - AD-PHASE-GATE added to lean-mode skip list in director-gates.md - design-system duplicate 5d heading fixed; skeleton decline path added; mandatory agent spawns now respect review mode - story-readiness acceptance criteria thresholds now type-aware - create-stories gains multi-ADR and no-ADR handling guidance - consistency-check creates docs/consistency-failures.md on first run - retrospective frontmatter bash injection replaced with explicit Bash call - smoke-check ls -t gains PowerShell fallback - Conventional Commits format documented in coding-standards.md - gate-check: ADR acceptance gate, QA plan check, chain-of-verification tool-action requirement all added Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: expose --review flag in argument-hints for all team-* skills All 9 team-* skills already implement Phase 0 review-mode resolution internally (full/lean/solo), but none advertised [--review full|lean|solo] in their argument-hint. Users had no way to discover the per-run override. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add SECURITY.md with coordinated disclosure policy Defines scope, reporting process (GitHub private vulnerability reporting), contributor security guidelines for hooks/skills/agents, and 90-day coordinated disclosure timeline. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add CONTRIBUTING.md with framework contribution guidelines Covers what PRs are welcome, skill/hook/agent technical requirements, the collaborative principle, testing expectations, commit format, and platform compatibility requirements. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add v1.0.0-beta → v1.0 upgrade section to UPGRADING.md Documents the 17 commits since the beta tag: new /vertical-slice gate, entity inventory flow in /map-systems, AskUserQuestion widgets across 7 skills, --review flag exposure on team-* skills, bug fixes (#21, #36, #42, #43, #45), and the new CONTRIBUTING.md and SECURITY.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
309 lines
10 KiB
Markdown
309 lines
10 KiB
Markdown
---
|
||
name: consistency-check
|
||
description: "Scan all GDDs against the entity registry to detect cross-document inconsistencies: same entity with different stats, same item with different values, same formula with different variables. Grep-first approach — reads registry then targets only conflicting GDD sections rather than full document reads."
|
||
argument-hint: "[full | since-last-review | entity:<name> | item:<name>]"
|
||
user-invocable: true
|
||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, AskUserQuestion
|
||
model: sonnet
|
||
---
|
||
|
||
# Consistency Check
|
||
|
||
Detects cross-document inconsistencies by comparing all GDDs against the
|
||
entity registry (`design/registry/entities.yaml`). Uses a grep-first approach:
|
||
reads the registry once, then targets only the GDD sections that mention
|
||
registered names — no full document reads unless a conflict needs investigation.
|
||
|
||
**This skill is the write-time safety net.** It catches what `/design-system`'s
|
||
per-section checks may have missed and what `/review-all-gdds`'s holistic review
|
||
catches too late.
|
||
|
||
**When to run:**
|
||
- After writing each new GDD (before moving to the next system)
|
||
- Before `/review-all-gdds` (so that skill starts with a clean baseline)
|
||
- Before `/create-architecture` (inconsistencies poison downstream ADRs)
|
||
- On demand: `/consistency-check entity:[name]` to check one entity specifically
|
||
|
||
**Output:** Conflict report + optional registry corrections
|
||
|
||
---
|
||
|
||
## Phase 1: Parse Arguments and Load Registry
|
||
|
||
**Modes:**
|
||
- No argument / `full` — check all registered entries against all GDDs
|
||
- `since-last-review` — check only GDDs modified since the last review report
|
||
- `entity:<name>` — check one specific entity across all GDDs
|
||
- `item:<name>` — check one specific item across all GDDs
|
||
|
||
**Load the registry:**
|
||
|
||
```
|
||
Read path="design/registry/entities.yaml"
|
||
```
|
||
|
||
If the file does not exist or has no entries:
|
||
> "Entity registry is empty. Run `/design-system` to write GDDs — the registry
|
||
> is populated automatically after each GDD is completed. Nothing to check yet."
|
||
|
||
Stop and exit.
|
||
|
||
Build four lookup tables from the registry:
|
||
- **entity_map**: `{ name → { source, attributes, referenced_by } }`
|
||
- **item_map**: `{ name → { source, value_gold, weight, ... } }`
|
||
- **formula_map**: `{ name → { source, variables, output_range } }`
|
||
- **constant_map**: `{ name → { source, value, unit } }`
|
||
|
||
Count total registered entries. Report:
|
||
```
|
||
Registry loaded: [N] entities, [N] items, [N] formulas, [N] constants
|
||
Scope: [full | since-last-review | entity:name]
|
||
```
|
||
|
||
---
|
||
|
||
## Phase 2: Locate In-Scope GDDs
|
||
|
||
```
|
||
Glob pattern="design/gdd/*.md"
|
||
```
|
||
|
||
Exclude: `game-concept.md`, `systems-index.md`, `game-pillars.md` — these are
|
||
not system GDDs.
|
||
|
||
For `since-last-review` mode:
|
||
```bash
|
||
git log --name-only --pretty=format: -- design/gdd/ | grep "\.md$" | sort -u
|
||
```
|
||
Limit to GDDs modified since the most recent `design/gdd/gdd-cross-review-*.md`
|
||
file's creation date.
|
||
|
||
Report the in-scope GDD list before scanning.
|
||
|
||
---
|
||
|
||
## Phase 3: Grep-First Conflict Scan
|
||
|
||
For each registered entry, grep every in-scope GDD for the entry's name.
|
||
Do NOT do full reads — extract only the matching lines and their immediate
|
||
context (-C 3 lines).
|
||
|
||
This is the core optimization: instead of reading 10 GDDs × 400 lines each
|
||
(4,000 lines), you grep 50 entity names × 10 GDDs (50 targeted searches,
|
||
each returning ~10 lines on a hit).
|
||
|
||
### 3a: Entity Scan
|
||
|
||
For each entity in entity_map:
|
||
|
||
```
|
||
Grep pattern="[entity_name]" glob="design/gdd/*.md" output_mode="content" -C 3
|
||
```
|
||
|
||
For each GDD hit, extract the values mentioned near the entity name:
|
||
- any numeric attributes (counts, costs, durations, ranges, rates)
|
||
- any categorical attributes (types, tiers, categories)
|
||
- any derived values (totals, outputs, results)
|
||
- any other attributes registered in entity_map
|
||
|
||
Compare extracted values against the registry entry.
|
||
|
||
**Conflict detection:**
|
||
- Registry says `[entity_name].[attribute] = [value_A]`. GDD says `[entity_name] has [value_B]`. → **CONFLICT**
|
||
- Registry says `[item_name].[attribute] = [value_A]`. GDD says `[item_name] is [value_B]`. → **CONFLICT**
|
||
- GDD mentions `[entity_name]` but doesn't specify the attribute. → **NOTE** (no conflict, just unverifiable)
|
||
|
||
### 3b: Item Scan
|
||
|
||
For each item in item_map, grep all GDDs for the item name. Extract:
|
||
- sell price / value / gold value
|
||
- weight
|
||
- stack rules (stackable / non-stackable)
|
||
- category
|
||
|
||
Compare against registry entry values.
|
||
|
||
### 3c: Formula Scan
|
||
|
||
For each formula in formula_map, grep all GDDs for the formula name. Extract:
|
||
- variable names mentioned near the formula
|
||
- output range or cap values mentioned
|
||
|
||
Compare against registry entry:
|
||
- Different variable names → **CONFLICT**
|
||
- Output range stated differently → **CONFLICT**
|
||
|
||
### 3d: Constant Scan
|
||
|
||
For each constant in constant_map, grep all GDDs for the constant name. Extract:
|
||
- Any numeric value mentioned near the constant name
|
||
|
||
Compare against registry value:
|
||
- Different number → **CONFLICT**
|
||
|
||
---
|
||
|
||
## Phase 4: Deep Investigation (Conflicts Only)
|
||
|
||
For each conflict found in Phase 3, do a targeted full-section read of the
|
||
conflicting GDD to get precise context:
|
||
|
||
```
|
||
Read path="design/gdd/[conflicting_gdd].md"
|
||
```
|
||
(Or use Grep with wider context if the file is large)
|
||
|
||
Confirm the conflict with full context. Determine:
|
||
1. **Which GDD is correct?** Check the `source:` field in the registry — the
|
||
source GDD is the authoritative owner. Any other GDD that contradicts it
|
||
is the one that needs updating.
|
||
2. **Is the registry itself out of date?** If the source GDD was updated after
|
||
the registry entry was written (check git log), the registry may be stale.
|
||
3. **Is this a genuine design change?** If the conflict represents an intentional
|
||
design decision, the resolution is: update the source GDD, update the registry,
|
||
then fix all other GDDs.
|
||
|
||
For each conflict, classify:
|
||
- **🔴 CONFLICT** — same named entity/item/formula/constant with different values
|
||
in different GDDs. Must resolve before architecture begins.
|
||
- **⚠️ STALE REGISTRY** — source GDD value changed but registry not updated.
|
||
Registry needs updating; other GDDs may be correct already.
|
||
- **ℹ️ UNVERIFIABLE** — entity mentioned but no comparable attribute stated.
|
||
Not a conflict; just noting the reference.
|
||
|
||
---
|
||
|
||
## Phase 5: Output Report
|
||
|
||
```
|
||
## Consistency Check Report
|
||
Date: [date]
|
||
Registry entries checked: [N entities, N items, N formulas, N constants]
|
||
GDDs scanned: [N] ([list names])
|
||
|
||
---
|
||
|
||
### Conflicts Found (must resolve before architecture)
|
||
|
||
🔴 [Entity/Item/Formula/Constant Name]
|
||
Registry (source: [gdd]): [attribute] = [value]
|
||
Conflict in [other_gdd].md: [attribute] = [different_value]
|
||
→ Resolution needed: [which doc to change and to what]
|
||
|
||
---
|
||
|
||
### Stale Registry Entries (registry behind the GDD)
|
||
|
||
⚠️ [Entry Name]
|
||
Registry says: [value] (written [date])
|
||
Source GDD now says: [new value]
|
||
→ Update registry entry to match source GDD, then check referenced_by docs.
|
||
|
||
---
|
||
|
||
### Unverifiable References (no conflict, informational)
|
||
|
||
ℹ️ [gdd].md mentions [entity_name] but states no comparable attributes.
|
||
No conflict detected. No action required.
|
||
|
||
---
|
||
|
||
### Clean Entries (no issues found)
|
||
|
||
✅ [N] registry entries verified across all GDDs with no conflicts.
|
||
|
||
---
|
||
|
||
Verdict: PASS | CONFLICTS FOUND
|
||
```
|
||
|
||
**Verdict:**
|
||
- **PASS** — no conflicts. Registry and GDDs agree on all checked values.
|
||
- **CONFLICTS FOUND** — one or more conflicts detected. List resolution steps.
|
||
|
||
---
|
||
|
||
## Phase 6: Registry Corrections
|
||
|
||
If stale registry entries were found, ask:
|
||
> "May I update `design/registry/entities.yaml` to fix the [N] stale entries?"
|
||
|
||
For each stale entry:
|
||
- Update the `value` / attribute field
|
||
- Set `revised:` to today's date
|
||
- Add a YAML comment with the old value: `# was: [old_value] before [date]`
|
||
|
||
If new entries were found in GDDs that are not in the registry, ask:
|
||
> "Found [N] entities/items mentioned in GDDs that aren't in the registry yet.
|
||
> May I add them to `design/registry/entities.yaml`?"
|
||
|
||
Only add entries that appear in more than one GDD (true cross-system facts).
|
||
|
||
**Never delete registry entries.** Set `status: deprecated` if an entry is removed
|
||
from all GDDs.
|
||
|
||
After writing: Verdict: **COMPLETE** — consistency check finished.
|
||
If conflicts remain unresolved: Verdict: **BLOCKED** — [N] conflicts need manual resolution before architecture begins.
|
||
|
||
### 6b: Append to Reflexion Log
|
||
|
||
If any 🔴 CONFLICT entries were found (regardless of whether they were resolved),
|
||
append an entry to `docs/consistency-failures.md` for each conflict:
|
||
|
||
```markdown
|
||
### [YYYY-MM-DD] — /consistency-check — 🔴 CONFLICT
|
||
**Domain**: [system domain(s) involved]
|
||
**Documents involved**: [source GDD] vs [conflicting GDD]
|
||
**What happened**: [specific conflict — entity name, attribute, differing values]
|
||
**Resolution**: [how it was fixed, or "Unresolved — manual action needed"]
|
||
**Pattern**: [generalised lesson, e.g. "Item values defined in combat GDD were not
|
||
referenced in economy GDD before authoring — always check entities.yaml first"]
|
||
```
|
||
|
||
If `docs/consistency-failures.md` does not exist, create it with this header before appending:
|
||
|
||
```markdown
|
||
# Consistency Failure Log
|
||
|
||
<!-- Auto-maintained by /consistency-check. Do not edit manually. -->
|
||
<!-- One entry per detected conflict, in chronological order. -->
|
||
|
||
| Date | GDD A | GDD B | Conflict Type | Status |
|
||
|------|-------|-------|---------------|--------|
|
||
```
|
||
|
||
Then append the new conflict entries. Never skip logging — a missing file is not a reason to lose conflict history.
|
||
|
||
---
|
||
|
||
## Phase 7: Session State and Closing
|
||
|
||
Silently append to `production/session-state/active.md` (create the file if it does not exist):
|
||
|
||
```
|
||
<!-- CONSISTENCY-CHECK: [date] | GDDs checked: [N] | Conflicts found: [N] | Report: docs/consistency-report-[date].md -->
|
||
```
|
||
|
||
Then close with an `AskUserQuestion` widget:
|
||
|
||
- **Prompt**: "Consistency check complete — [N] conflicts found. What next?"
|
||
- **Options**:
|
||
- `[A] Fix the highest-priority conflict now`
|
||
- `[B] Save full report and stop`
|
||
- `[C] Run /design-review on the most conflicted GDD`
|
||
- `[D] Stop here`
|
||
|
||
Never end the skill with plain text. Always close with this widget.
|
||
|
||
---
|
||
|
||
## Recovery / Reference
|
||
|
||
- **If PASS**: Run `/review-all-gdds` for holistic design-theory review, or
|
||
`/create-architecture` if all MVP GDDs are complete.
|
||
- **If CONFLICTS FOUND**: Fix the flagged GDDs, then re-run
|
||
`/consistency-check` to confirm resolution.
|
||
- **If STALE REGISTRY**: Update the registry (Phase 6), then re-run to verify.
|
||
- Run `/consistency-check` after writing each new GDD to catch issues early,
|
||
not at architecture time.
|