mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
Fix release for 1.1.2: the 14 longest skills keep their later phases after a compaction, a question nobody answered is never taken as an answer, settings read the same from a subfolder, the commit check works for a project in a subfolder of a larger repository, every skill opens with a title, and the shipped allow rules no longer approve deleting a branch or writing files without asking. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.2 → v1.1.3). Refs #83 Refs #133 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185en4t76fPn7315q4c3nko
116 lines
6.0 KiB
Markdown
116 lines
6.0 KiB
Markdown
---
|
|
name: architecture-review
|
|
description: "Traceability matrix mapping GDD requirements to ADRs. Finds gaps, cross-ADR conflicts, engine compatibility. PASS/CONCERNS/NOT ASSESSED/FAIL."
|
|
argument-hint: "[focus: full | coverage | consistency | engine | single-gdd path/to/gdd.md]"
|
|
user-invocable: true
|
|
allowed-tools: Read, Glob, Grep, Bash, Write, Agent, AskUserQuestion, Bash(bash "*/.claude/skills/architecture-review/../../hooks/yaml-helper.sh" resolve_config *)
|
|
model: opus
|
|
---
|
|
|
|
!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow`
|
|
|
|
# Architecture Review
|
|
|
|
The architecture review validates that the complete body of architectural decisions
|
|
covers all game design requirements, is internally consistent, and correctly targets
|
|
the project's pinned engine version. It is the quality gate between Technical Setup
|
|
and Pre-Production.
|
|
|
|
**Argument modes:**
|
|
- **No argument / `full`**: Full review — all phases
|
|
- **`coverage`**: Traceability only — which GDD requirements have no ADR
|
|
- **`consistency`**: Cross-ADR conflict detection only
|
|
- **`engine`**: Engine compatibility audit only
|
|
- **`single-gdd [path]`**: Review architecture coverage for one specific GDD
|
|
- **`rtm`**: Requirements Traceability Matrix — extends the standard matrix
|
|
to include story file paths and test file paths; outputs
|
|
`docs/architecture/requirements-traceability.md` with the full
|
|
GDD requirement → ADR → Story → Test chain. Use in Production phase when
|
|
stories and tests exist.
|
|
|
|
---
|
|
|
|
Every `AskUserQuestion` call follows `.claude/docs/automation-modes.md`
|
|
(collaborative asks always · guided major-only · autonomous logs and proceeds;
|
|
`automation_always_ask` categories always prompt).
|
|
|
|
**`workflow`** (see `.claude/docs/workflow-modes.md`):
|
|
- `full` — full traceability matrix across all GDDs and all ADRs.
|
|
- `standard` — reduced scope: architecture doc + critical ADRs only.
|
|
- `minimal` — not applicable (no architecture doc required).
|
|
|
|
## Phase 1: Load Everything
|
|
|
|
**Read `references/1-load.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
|
|
|
## Phase 2: Extract Technical Requirements from Every GDD
|
|
|
|
**Read `references/2-extract-requirements.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
|
|
|
## Phase 3: Build the Traceability Matrix
|
|
|
|
**Read `references/3-traceability.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
|
|
|
## Phase 4: Cross-ADR Conflict Detection
|
|
|
|
**Read `references/4-conflicts.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
|
|
|
## Phase 5: Engine Compatibility Cross-Check
|
|
|
|
**Read `references/5-engine.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
|
|
|
## Phase 6: Architecture Document Coverage
|
|
|
|
**Read `references/6-document-coverage.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
|
|
|
## Phase 7: Output the Review Report
|
|
|
|
**Read `references/7-report.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
|
|
|
## Phase 8: Write and Update Traceability Index
|
|
|
|
**Read `references/8-write.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
|
|
|
## Phase 9: Handoff
|
|
|
|
**Read `references/9-handoff.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
|
|
|
## Error Recovery Protocol
|
|
|
|
**First, verify the artifact.** If the return contract named a path, check the
|
|
path exists before treating the phase as done — **a named artifact that is not
|
|
on disk is a failed phase, however fluent the response reads.** An agent can
|
|
burn a full phase and return a plausible preamble having written nothing, which
|
|
is neither BLOCKED nor an error nor "fails to complete", so the trigger below
|
|
never fires. Resume it naming the unmet contract; the context is
|
|
usually still there.
|
|
|
|
If any spawned agent returns BLOCKED, errors, or fails to complete: **surface it
|
|
immediately, don't proceed past a dependency it blocks, and always produce a
|
|
partial report** (retry scope here = fewer GDDs / single-system). Full procedure:
|
|
`.claude/docs/error-recovery-protocol.md`.
|
|
|
|
---
|
|
|
|
## Collaborative Protocol
|
|
|
|
**Applies in `collaborative` mode (the default).** For `guided` and
|
|
`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below
|
|
describe what collaborative mode requires, not universal behavior.
|
|
|
|
1. **Read silently** — do not narrate every file read
|
|
2. **Show the matrix** — present the full traceability matrix before any write
|
|
approval; let the user see the state
|
|
3. **Don't guess** — if a requirement is ambiguous, ask: "Is [X] a technical
|
|
requirement or a design preference?"
|
|
4. **Draft before approval** — always show the content that will be written (the
|
|
report, the updated ADR section, the systems-index row) inline in the conversation
|
|
before requesting approval. Never ask to write something the user has not yet seen.
|
|
5. **Use `AskUserQuestion` for write approvals** — plain text "May I?" is not
|
|
sufficient. Use the structured tool with labeled options [A]/[B]/[C] so the
|
|
user can choose between "write now", "show full draft first", and "not yet".
|
|
Multi-file changesets must list every file and what changes, then ask once
|
|
with grouped options — not a separate plain-text question per file.
|
|
6. **Non-blocking** — the verdict is advisory; the user decides whether to continue
|
|
despite CONCERNS or even FAIL findings
|