mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
Release 1.1.0 — one config file, and a process weight you choose
`project.yaml` at the repo root is now the single source of truth for a project's configuration, replacing `production/stage.txt`, `production/review-mode.txt` and `.claude/docs/technical-preferences.md` (all three still read as a fallback; nothing is force-deleted). **`modes.rigor` — one question instead of six.** `minimal`, `standard` or `full` fronts six knobs: `modes.workflow`, `docs.density`, `qa.level`, `modes.story_granularity`, `modes.review_mode` and `team.size`. It defaults to `minimal`, which is a change from 1.0's behaviour: the heavier tier was measured costing several times more to reach working code without producing a better result, and returning nothing when a fresh developer inherited the project. Pin `modes.rigor: standard` to keep 1.0's process level. Also in this release: - `/settings` to view or change any setting, and `project.local.yaml` for per-developer preferences that should not be committed. - `system_overrides` to hold one system to a higher standard than the rest of the project, and `testing.strict` to set per test type whether missing evidence blocks a story or warns. - A story that changes anything the player sees is not closed until the game has been launched, observed, and a screenshot retained in `production/qa/evidence/`. A parse check is not a run. This holds at every rigor level, including `minimal`, where automated tests are waived but the look is not. - The code root is engine-specific and enforced as such: Godot `src/`, Unity `Assets/`, Unreal `Source/<Module>/`. Two of the three will not build a project laid out any other way. - Migration tooling for existing projects: `.claude/scripts/migrate-v1-config.sh` converts a 1.0 layout, non-destructively by default, with a report to review before `--finalize` deletes anything. - Ask-before-write holds regardless of personal automation settings. Upgrading from 1.0 or earlier: see UPGRADING.md. Full list of changes: CHANGELOG.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016xvzG3i7pWQg4LjyDwWMXd
This commit is contained in:
Donchitos
co-authored by
Claude Opus 5
Claude Opus 5
parent
984023ddac
commit
d05699707f
@@ -0,0 +1,26 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# AD-ART-BIBLE — Art Bible Sign-Off
|
||||
|
||||
Agent: `art-director` | Model tier: Sonnet | Domain: Visual identity, art bible, visual production readiness
|
||||
|
||||
**Trigger**: After the art bible is drafted (`/art-bible`), before asset production begins
|
||||
|
||||
**Context to pass**:
|
||||
- Art bible path (`design/art/art-bible.md`)
|
||||
- Game pillars and core fantasy
|
||||
- Platform and performance constraints (`platform.*` and `performance.*` from `project.yaml`, falling back to `.claude/docs/technical-preferences.md`)
|
||||
- Visual identity anchor chosen during brainstorm (from `design/gdd/game-concept.md`)
|
||||
|
||||
**Prompt**:
|
||||
> "Review this art bible for completeness and internal consistency. Does the color
|
||||
> system match the mood targets? Does the shape language follow from the visual
|
||||
> identity statement? Are the asset standards achievable within the platform
|
||||
> constraints? Does the character design direction give artists enough to work from
|
||||
> without over-specifying? Are there contradictions between sections? Would an
|
||||
> outsourcing team be able to produce assets from this document without additional
|
||||
> briefing? Return APPROVE (art bible is production-ready), CONCERNS [specific
|
||||
> sections needing clarification], or REJECT [fundamental inconsistencies that must
|
||||
> be resolved before asset production begins]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,25 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# AD-CONCEPT-VISUAL — Visual Identity Anchor
|
||||
|
||||
Agent: `art-director` | Model tier: Sonnet | Domain: Visual identity, art bible, visual production readiness
|
||||
|
||||
**Trigger**: After game pillars are locked (brainstorm Phase 4), in parallel with CD-PILLARS
|
||||
|
||||
**Context to pass**:
|
||||
- Game concept (elevator pitch, core fantasy, unique hook)
|
||||
- Full pillar set with names, definitions, and design tests
|
||||
- Target platform (if known)
|
||||
- Any reference games or visual touchstones mentioned by the user
|
||||
|
||||
**Prompt**:
|
||||
> "Based on these game pillars and core concept, propose 2-3 distinct visual identity
|
||||
> directions. For each direction provide: (1) a one-line visual rule that could guide
|
||||
> all visual decisions (e.g., 'everything must move', 'beauty is in the decay'), (2)
|
||||
> mood and atmosphere targets, (3) shape language (sharp/rounded/organic/geometric
|
||||
> emphasis), (4) color philosophy (palette direction, what colors mean in this world).
|
||||
> Be specific — avoid generic descriptions. One direction should directly serve the
|
||||
> primary design pillar. Name each direction. Recommend which best serves the stated
|
||||
> pillars and explain why."
|
||||
|
||||
**Verdicts**: CONCEPTS (multiple valid options — user selects) / STRONG (one direction clearly dominant) / CONCERNS (pillars don't provide enough direction to differentiate visual identity yet)
|
||||
@@ -0,0 +1,26 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# AD-PHASE-GATE — Visual Readiness at Phase Transition
|
||||
|
||||
Agent: `art-director` | Model tier: Sonnet | Domain: Visual identity, art bible, visual production readiness
|
||||
|
||||
**Trigger**: Always at `/gate-check` — spawn in parallel with CD-PHASE-GATE, TD-PHASE-GATE, and PR-PHASE-GATE
|
||||
|
||||
**Context to pass**:
|
||||
- Target phase name
|
||||
- List of all art/visual artifacts present (file paths)
|
||||
- Visual identity anchor from `design/gdd/game-concept.md` (if present)
|
||||
- Art bible path if it exists (`design/art/art-bible.md`)
|
||||
|
||||
**Prompt**:
|
||||
> "Review the current project state for [target phase] gate readiness from a visual
|
||||
> direction perspective. Is the visual identity established and documented at the
|
||||
> level this phase requires? Are the right visual artifacts in place? Would visual
|
||||
> teams be able to begin their work without visual direction gaps that cause costly
|
||||
> rework later? Are there visual decisions that are being deferred past their latest
|
||||
> responsible moment? Return READY, CONCERNS [specific visual direction gaps that
|
||||
> could cause production rework], or NOT READY [visual blockers that must exist
|
||||
> before this phase can succeed — specify what artifact is missing and why it
|
||||
> matters at this stage]."
|
||||
|
||||
**Verdicts**: READY / CONCERNS / NOT READY
|
||||
@@ -0,0 +1,23 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# AD-VISUAL — Art Director Visual Consistency Review
|
||||
|
||||
Agent: `art-director` | Model tier: Sonnet (Tier 2 lead — invoked when a domain specialist's feasibility sign-off is needed)
|
||||
|
||||
**Trigger**: After art direction decisions are made, when new asset types are
|
||||
introduced, or when a tech art decision affects visual style
|
||||
|
||||
**Context to pass**:
|
||||
- Art bible path (if exists at `design/art/art-bible.md`)
|
||||
- The specific asset type, style decision, or visual direction being reviewed
|
||||
- Reference images or style descriptions
|
||||
- Platform and performance constraints
|
||||
|
||||
**Prompt**:
|
||||
> "Review this visual direction decision for consistency with the established art
|
||||
> style and production constraints. Does it match the art bible? Is it achievable
|
||||
> within the platform's performance budget? Are there asset pipeline implications
|
||||
> that create technical risk? Return APPROVE, CONCERNS [specific adjustments], or
|
||||
> REJECT [style violation or production risk that must be resolved first]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,23 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# CD-GDD-ALIGN — GDD Pillar Alignment Check
|
||||
|
||||
Agent: `creative-director` | Model tier: Opus | Domain: Vision, pillars, player experience
|
||||
|
||||
**Trigger**: After a system GDD is authored (design-system, quick-design, or any
|
||||
workflow that produces a GDD)
|
||||
|
||||
**Context to pass**:
|
||||
- GDD file path
|
||||
- Game pillars (from `design/gdd/game-concept.md` or `design/gdd/game-pillars.md`)
|
||||
- MDA aesthetics target for this game
|
||||
- System's stated Player Fantasy section
|
||||
|
||||
**Prompt**:
|
||||
> "Review this system GDD for pillar alignment. Does every section serve the stated
|
||||
> pillars? Are there mechanics or rules that contradict or weaken a pillar? Does
|
||||
> the Player Fantasy section match the game's core fantasy? Return APPROVE, CONCERNS
|
||||
> [specific sections with issues], or REJECT [pillar violations that must be
|
||||
> redesigned before this system is implementable]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,24 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# CD-NARRATIVE — Narrative Consistency Check
|
||||
|
||||
Agent: `creative-director` | Model tier: Opus | Domain: Vision, pillars, player experience
|
||||
|
||||
**Trigger**: After narrative GDDs, lore documents, dialogue specs, or world-building
|
||||
documents are authored (team-narrative, design-system for story systems, writer
|
||||
deliverables)
|
||||
|
||||
**Context to pass**:
|
||||
- Document file path(s)
|
||||
- Game pillars
|
||||
- Narrative direction brief or tone guide (if exists at `design/narrative/`)
|
||||
- Any existing lore that the new document references
|
||||
|
||||
**Prompt**:
|
||||
> "Review this narrative content for consistency with the game's pillars and
|
||||
> established world rules. Does the tone match the game's established voice? Are
|
||||
> there contradictions with existing lore or world-building? Does the content serve
|
||||
> the player experience pillar? Return APPROVE, CONCERNS [specific inconsistencies],
|
||||
> or REJECT [contradictions that break world coherence]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,21 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# CD-PHASE-GATE — Creative Readiness at Phase Transition
|
||||
|
||||
Agent: `creative-director` | Model tier: Opus | Domain: Vision, pillars, player experience
|
||||
|
||||
**Trigger**: Always at `/gate-check` — spawn in parallel with TD-PHASE-GATE and PR-PHASE-GATE
|
||||
|
||||
**Context to pass**:
|
||||
- Target phase name
|
||||
- List of all artifacts present (file paths)
|
||||
- Game pillars and core fantasy
|
||||
|
||||
**Prompt**:
|
||||
> "Review the current project state for [target phase] gate readiness from a
|
||||
> creative direction perspective. Are the game pillars faithfully represented in
|
||||
> all design artifacts? Does the current state preserve the core fantasy? Are there
|
||||
> any design decisions across GDDs or architecture that compromise the intended
|
||||
> player experience? Return READY, CONCERNS [list], or NOT READY [blockers]."
|
||||
|
||||
**Verdicts**: READY / CONCERNS / NOT READY
|
||||
@@ -0,0 +1,24 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# CD-PILLARS — Pillar Stress Test
|
||||
|
||||
Agent: `creative-director` | Model tier: Opus | Domain: Vision, pillars, player experience
|
||||
|
||||
**Trigger**: After game pillars and anti-pillars are defined (brainstorm Phase 4,
|
||||
or any time pillars are revised)
|
||||
|
||||
**Context to pass**:
|
||||
- Full pillar set with names, definitions, and design tests
|
||||
- Anti-pillars list
|
||||
- Core fantasy statement
|
||||
- Unique hook ("Like X, AND ALSO Y")
|
||||
|
||||
**Prompt**:
|
||||
> "Review these game pillars. Are they falsifiable — could a real design decision
|
||||
> actually fail this pillar? Do they create meaningful tension with each other? Do
|
||||
> they differentiate this game from its closest comparables? Would they help resolve
|
||||
> a design disagreement in practice, or are they too vague to be useful? Return
|
||||
> specific feedback for each pillar and an overall verdict: APPROVE (strong), CONCERNS
|
||||
> [list] (needs sharpening), or REJECT (weak — pillars do not carry weight)."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,23 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# CD-PLAYTEST — Player Experience Validation
|
||||
|
||||
Agent: `creative-director` | Model tier: Opus | Domain: Vision, pillars, player experience
|
||||
|
||||
**Trigger**: After playtest reports are generated (`/playtest-report`), or after
|
||||
any session that produces player feedback
|
||||
|
||||
**Context to pass**:
|
||||
- Playtest report file path
|
||||
- Game pillars and core fantasy statement
|
||||
- The specific hypothesis being tested
|
||||
|
||||
**Prompt**:
|
||||
> "Review this playtest report against the game's design pillars and core fantasy.
|
||||
> Is the player experience matching the intended fantasy? Are there systematic issues
|
||||
> that represent pillar drift — mechanics that feel fine in isolation but undermine
|
||||
> the intended experience? Return APPROVE (core fantasy is landing), CONCERNS [gaps
|
||||
> between intended and actual experience], or REJECT [core fantasy is not present —
|
||||
> redesign needed before further playtesting]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,27 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# CD-SYSTEMS — Systems Decomposition Vision Check
|
||||
|
||||
Agent: `creative-director` | Model tier: Opus | Domain: Vision, pillars, player experience
|
||||
|
||||
**Trigger**: After the systems index is written by `/map-systems` — validates the
|
||||
complete system set before GDD authoring begins
|
||||
|
||||
**Context to pass**:
|
||||
- Systems index path (`design/gdd/systems-index.md`)
|
||||
- Game pillars and core fantasy (from `design/gdd/game-concept.md`)
|
||||
- Priority tier assignments (MVP / Vertical Slice / Alpha / Full Vision)
|
||||
- Any high-risk or bottleneck systems identified in the dependency map
|
||||
|
||||
**Prompt**:
|
||||
> "Review this systems decomposition against the game's design pillars. Does the
|
||||
> full set of MVP-tier systems collectively deliver the core fantasy? Are there
|
||||
> systems whose mechanics don't serve any stated pillar — indicating they may be
|
||||
> scope creep? Are there pillar-critical player experiences that have no system
|
||||
> assigned to deliver them? Are any systems missing that the core loop requires?
|
||||
> Return APPROVE (systems serve the vision), CONCERNS [specific gaps or
|
||||
> misalignments with their pillar implications], or REJECT [fundamental gaps —
|
||||
> the decomposition misses critical design intent and must be revised before GDD
|
||||
> authoring begins]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,23 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# LP-CODE-REVIEW — Lead Programmer Code Review
|
||||
|
||||
Agent: `lead-programmer` | Model tier: Sonnet (Tier 2 lead — invoked when a domain specialist's feasibility sign-off is needed)
|
||||
|
||||
**Trigger**: After a dev story is implemented (`/dev-story`, `/story-done`), or
|
||||
as part of `/code-review`
|
||||
|
||||
**Context to pass**:
|
||||
- Implementation file paths
|
||||
- Story file path (for acceptance criteria)
|
||||
- Relevant GDD section
|
||||
- ADR that governs this system
|
||||
|
||||
**Prompt**:
|
||||
> "Review this implementation against the story acceptance criteria and governing
|
||||
> ADR. Does the code match the architecture boundary definitions? Are there
|
||||
> violations of the coding standards or forbidden patterns? Is the public API
|
||||
> testable and documented? Are there any correctness issues against the GDD rules?
|
||||
> Return APPROVE, CONCERNS [specific issues], or REJECT [must be revised before merge]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,23 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# LP-FEASIBILITY — Lead Programmer Implementation Feasibility
|
||||
|
||||
Agent: `lead-programmer` | Model tier: Sonnet (Tier 2 lead — invoked when a domain specialist's feasibility sign-off is needed)
|
||||
|
||||
**Trigger**: After the master architecture document is written (`/create-architecture`
|
||||
Phase 7b), or when a new architectural pattern is proposed
|
||||
|
||||
**Context to pass**:
|
||||
- Architecture document path
|
||||
- Technical requirements baseline summary
|
||||
- ADR list with statuses
|
||||
|
||||
**Prompt**:
|
||||
> "Review this architecture for implementation feasibility. Flag: (a) any decisions
|
||||
> that would be difficult or impossible to implement with the stated engine and
|
||||
> language, (b) any missing interface definitions that programmers would need to
|
||||
> invent themselves, (c) any patterns that create avoidable technical debt or
|
||||
> that contradict standard [engine] idioms. Return FEASIBLE, CONCERNS [list], or
|
||||
> INFEASIBLE [blockers that make this architecture unimplementable as written]."
|
||||
|
||||
**Verdicts**: FEASIBLE / CONCERNS / INFEASIBLE
|
||||
@@ -0,0 +1,24 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# ND-CONSISTENCY — Narrative Director Consistency Check
|
||||
|
||||
Agent: `narrative-director` | Model tier: Sonnet (Tier 2 lead — invoked when a domain specialist's feasibility sign-off is needed)
|
||||
|
||||
**Trigger**: After writer deliverables (dialogue, lore, item descriptions) are
|
||||
authored, or when a design decision has narrative implications
|
||||
|
||||
**Context to pass**:
|
||||
- Document or content file path(s)
|
||||
- Narrative bible or tone guide path (if exists)
|
||||
- Relevant world-building rules
|
||||
- Character or faction profiles affected
|
||||
|
||||
**Prompt**:
|
||||
> "Review this narrative content for internal consistency and adherence to
|
||||
> established world rules. Are character voices consistent with their established
|
||||
> profiles? Does the lore contradict any established facts? Is the tone consistent
|
||||
> with the game's narrative direction? Return APPROVE, CONCERNS [specific
|
||||
> inconsistencies to fix], or REJECT [contradictions that break the narrative
|
||||
> foundation]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,30 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# PR-EPIC — Epic Structure Feasibility Review
|
||||
|
||||
Agent: `producer` | Model tier: Opus | Domain: Scope, timeline, dependencies, production risk
|
||||
|
||||
**Trigger**: After epics are defined by `/create-epics`, before stories are
|
||||
broken out — validates the epic structure is producible before `/create-stories`
|
||||
is invoked
|
||||
|
||||
**Context to pass**:
|
||||
- Epic definition file paths (all epics just created)
|
||||
- Epic index path (`production/epics/index.md`)
|
||||
- Milestone timeline and target dates
|
||||
- Team capacity (solo / small team / size)
|
||||
- Layer being epiced (Foundation / Core / Feature / etc.)
|
||||
|
||||
**Prompt**:
|
||||
> "Review this epic structure for production feasibility before story breakdown
|
||||
> begins. Are the epic boundaries scoped appropriately — could each epic realistically
|
||||
> complete before a milestone deadline? Are epics correctly ordered by system
|
||||
> dependency — does any epic require another epic's output before it can start?
|
||||
> Are any epics underscoped (too small, should merge) or overscoped (too large,
|
||||
> should split into 2-3 focused epics)? Are the Foundation-layer epics scoped to
|
||||
> allow Core-layer epics to begin at the start of the next sprint after Foundation
|
||||
> completes? Return REALISTIC (epic structure is producible), CONCERNS [specific
|
||||
> structural adjustments before stories are written], or UNREALISTIC [epics must
|
||||
> be split, merged, or reordered — story breakdown cannot begin until resolved]."
|
||||
|
||||
**Verdicts**: REALISTIC / CONCERNS / UNREALISTIC
|
||||
@@ -0,0 +1,24 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# PR-MILESTONE — Milestone Risk Assessment
|
||||
|
||||
Agent: `producer` | Model tier: Opus | Domain: Scope, timeline, dependencies, production risk
|
||||
|
||||
**Trigger**: At milestone review (`/milestone-review`), at mid-sprint retrospectives,
|
||||
or when a scope change is proposed that affects the milestone
|
||||
|
||||
**Context to pass**:
|
||||
- Milestone definition and target date
|
||||
- Current completion percentage
|
||||
- Blocked stories count
|
||||
- Sprint velocity data (if available)
|
||||
|
||||
**Prompt**:
|
||||
> "Review this milestone status. Based on current velocity and blocked story count,
|
||||
> will this milestone hit its target date? What are the top 3 production risks
|
||||
> between now and the milestone? Are there scope items that should be cut to protect
|
||||
> the milestone date vs. items that are non-negotiable? Return ON TRACK, AT RISK
|
||||
> [specific mitigations], or OFF TRACK [date must slip or scope must cut — provide
|
||||
> both options]."
|
||||
|
||||
**Verdicts**: ON TRACK / AT RISK / OFF TRACK
|
||||
@@ -0,0 +1,22 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# PR-PHASE-GATE — Production Readiness at Phase Transition
|
||||
|
||||
Agent: `producer` | Model tier: Opus | Domain: Scope, timeline, dependencies, production risk
|
||||
|
||||
**Trigger**: Always at `/gate-check` — spawn in parallel with CD-PHASE-GATE and TD-PHASE-GATE
|
||||
|
||||
**Context to pass**:
|
||||
- Target phase name
|
||||
- Sprint and milestone artifacts present
|
||||
- Team size and capacity
|
||||
- Current blocked story count
|
||||
|
||||
**Prompt**:
|
||||
> "Review the current project state for [target phase] gate readiness from a
|
||||
> production perspective. Is the scope realistic for the stated timeline and team
|
||||
> size? Are dependencies properly ordered so the team can actually execute in
|
||||
> sequence? Are there milestone or sprint risks that could derail the phase within
|
||||
> the first two sprints? Return READY, CONCERNS [list], or NOT READY [blockers]."
|
||||
|
||||
**Verdicts**: READY / CONCERNS / NOT READY
|
||||
@@ -0,0 +1,25 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# PR-SCOPE — Scope and Timeline Validation
|
||||
|
||||
Agent: `producer` | Model tier: Opus | Domain: Scope, timeline, dependencies, production risk
|
||||
|
||||
**Trigger**: After scope tiers are defined (brainstorm Phase 6, quick-design, or
|
||||
any workflow that produces an MVP definition and timeline estimate)
|
||||
|
||||
**Context to pass**:
|
||||
- Full vision scope description
|
||||
- MVP definition
|
||||
- Timeline estimate
|
||||
- Team size (solo / small team / etc.)
|
||||
- Scope tiers (what ships if time runs out)
|
||||
|
||||
**Prompt**:
|
||||
> "Review this scope estimate. Is the MVP achievable in the stated timeline for
|
||||
> the stated team size? Are the scope tiers correctly ordered by risk — does each
|
||||
> tier deliver a shippable product if work stops there? What is the most likely
|
||||
> cut point under time pressure, and is it a graceful fallback or a broken product?
|
||||
> Return REALISTIC (scope matches capacity), OPTIMISTIC [specific adjustments
|
||||
> recommended], or UNREALISTIC [blockers — timeline or MVP must be revised]."
|
||||
|
||||
**Verdicts**: REALISTIC / OPTIMISTIC / UNREALISTIC
|
||||
@@ -0,0 +1,24 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# PR-SPRINT — Sprint Feasibility Review
|
||||
|
||||
Agent: `producer` | Model tier: Opus | Domain: Scope, timeline, dependencies, production risk
|
||||
|
||||
**Trigger**: Before finalising a sprint plan (`/sprint-plan`), and after any
|
||||
mid-sprint scope change
|
||||
|
||||
**Context to pass**:
|
||||
- Proposed sprint story list (titles, estimates, dependencies)
|
||||
- Team capacity (hours available)
|
||||
- Current sprint backlog debt (if any)
|
||||
- Milestone constraints
|
||||
|
||||
**Prompt**:
|
||||
> "Review this sprint plan for feasibility. Is the story load realistic for the
|
||||
> available capacity? Are stories correctly ordered by dependency? Are there hidden
|
||||
> dependencies between stories that could block the sprint mid-way? Are any stories
|
||||
> underestimated given their technical complexity? Return REALISTIC (plan is
|
||||
> achievable), CONCERNS [specific risks], or UNREALISTIC [sprint must be
|
||||
> descoped — identify which stories to defer]."
|
||||
|
||||
**Verdicts**: REALISTIC / CONCERNS / UNREALISTIC
|
||||
@@ -0,0 +1,27 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# QL-STORY-READY — QA Lead Story Readiness Check
|
||||
|
||||
Agent: `qa-lead` | Model tier: Sonnet (Tier 2 lead — invoked when a domain specialist's feasibility sign-off is needed)
|
||||
|
||||
**Trigger**: Before a story is accepted into a sprint — invoked by `/create-stories`,
|
||||
`/story-readiness`, and `/sprint-plan` during story selection
|
||||
|
||||
**Context to pass**:
|
||||
- Story file path
|
||||
- Story type (Logic / Integration / Visual/Feel / UI / Config/Data)
|
||||
- Acceptance criteria list (verbatim from the story)
|
||||
- The GDD requirement (TR-ID and text) the story covers
|
||||
|
||||
**Prompt**:
|
||||
> "Review this story's acceptance criteria for testability before it enters the
|
||||
> sprint. Are all criteria specific enough that a developer would know unambiguously
|
||||
> when they are done? For Logic-type stories: can every criterion be verified with
|
||||
> an automated test? For Integration stories: is each criterion observable in a
|
||||
> controlled test environment? Flag criteria that are too vague to implement
|
||||
> against, and flag criteria that require a full game build to test (mark these
|
||||
> DEFERRED, not BLOCKED). Return ADEQUATE (criteria are implementable as written),
|
||||
> GAPS [specific criteria needing refinement], or INADEQUATE [criteria are too
|
||||
> vague — story must be revised before sprint inclusion]."
|
||||
|
||||
**Verdicts**: ADEQUATE / GAPS / INADEQUATE
|
||||
@@ -0,0 +1,23 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# QL-TEST-COVERAGE — QA Lead Test Coverage Review
|
||||
|
||||
Agent: `qa-lead` | Model tier: Sonnet (Tier 2 lead — invoked when a domain specialist's feasibility sign-off is needed)
|
||||
|
||||
**Trigger**: After implementation stories are complete, before marking an epic
|
||||
done, or at `/gate-check` Production → Polish
|
||||
|
||||
**Context to pass**:
|
||||
- List of implemented stories with story types (Logic / Integration / Visual / UI / Config)
|
||||
- Test file paths in `tests/`
|
||||
- GDD acceptance criteria for the system
|
||||
|
||||
**Prompt**:
|
||||
> "Review the test coverage for these implementation stories. Are all Logic stories
|
||||
> covered by passing unit tests? Are Integration stories covered by integration
|
||||
> tests or documented playtests? Are the GDD acceptance criteria each mapped to at
|
||||
> least one test? Are there untested edge cases from the GDD Edge Cases section?
|
||||
> Return ADEQUATE (coverage meets standards), GAPS [specific missing tests], or
|
||||
> INADEQUATE [critical logic is untested — do not advance]."
|
||||
|
||||
**Verdicts**: ADEQUATE / GAPS / INADEQUATE
|
||||
@@ -0,0 +1,23 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# TD-ADR — Architecture Decision Review
|
||||
|
||||
Agent: `technical-director` | Model tier: Opus | Domain: Architecture, engine risk, performance
|
||||
|
||||
**Trigger**: After an individual ADR is authored (`/architecture-decision`), before
|
||||
it is marked Accepted
|
||||
|
||||
**Context to pass**:
|
||||
- ADR file path
|
||||
- Engine version and knowledge gap risk level for the domain
|
||||
- Related ADRs (if any)
|
||||
|
||||
**Prompt**:
|
||||
> "Review this Architecture Decision Record. Does it have a clear problem statement
|
||||
> and rationale? Are the rejected alternatives genuinely considered? Does the
|
||||
> Consequences section acknowledge the trade-offs honestly? Is the engine version
|
||||
> stamped? Are post-cutoff API risks flagged? Does it link to the GDD requirements
|
||||
> it covers? Return APPROVE, CONCERNS [specific gaps], or REJECT [the decision is
|
||||
> underspecified or makes unsound technical assumptions]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,24 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# TD-ARCHITECTURE — Architecture Sign-Off
|
||||
|
||||
Agent: `technical-director` | Model tier: Opus | Domain: Architecture, engine risk, performance
|
||||
|
||||
**Trigger**: After the master architecture document is drafted (`/create-architecture`
|
||||
Phase 7), and after any major architecture revision
|
||||
|
||||
**Context to pass**:
|
||||
- Architecture document path (`docs/architecture/architecture.md`)
|
||||
- Technical requirements baseline (TR-IDs and count)
|
||||
- ADR list with statuses
|
||||
- Engine knowledge gap inventory
|
||||
|
||||
**Prompt**:
|
||||
> "Review this master architecture document for technical soundness. Check: (1) Is
|
||||
> every technical requirement from the baseline covered by an architectural decision?
|
||||
> (2) Are all HIGH risk engine domains explicitly addressed or flagged as open
|
||||
> questions? (3) Are the API boundaries clean, minimal, and implementable? (4) Are
|
||||
> Foundation layer ADR gaps resolved before implementation begins? Return APPROVE,
|
||||
> CONCERNS [list], or REJECT [blockers that must be resolved before coding starts]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,25 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# TD-CHANGE-IMPACT — Design Change Impact Review
|
||||
|
||||
Agent: `technical-director` | Model tier: Opus | Domain: Architecture, engine risk, performance
|
||||
|
||||
**Trigger**: After the Design Change Impact Report is produced
|
||||
(`/propagate-design-change` Phase 6), before the resolution workflow begins
|
||||
|
||||
**Context to pass**:
|
||||
- The full Design Change Impact Report from Phase 6 — change summary, every
|
||||
affected ADR with its Still Valid / Needs Review / Likely Superseded
|
||||
classification, and the recommended actions
|
||||
|
||||
**Prompt**:
|
||||
> "Review this design-change impact assessment before any ADR is revised. Are the
|
||||
> impact classifications correct — in particular, is any ADR under-classified
|
||||
> (marked Still Valid when the change actually contradicts its assumptions)? Are
|
||||
> the recommended actions architecturally sound? Were any cascading effects on
|
||||
> other ADRs or systems missed — decisions that depend on the ones already
|
||||
> flagged? Return APPROVE, CONCERNS [the specific ADRs or recommendations to
|
||||
> revisit], or REJECT [the assessment must be re-analyzed before resolution
|
||||
> begins — say what was missed]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,22 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# TD-ENGINE-RISK — Engine Version Risk Review
|
||||
|
||||
Agent: `technical-director` | Model tier: Opus | Domain: Architecture, engine risk, performance
|
||||
|
||||
**Trigger**: When making architecture decisions that touch post-cutoff engine APIs,
|
||||
or before finalizing any engine-specific implementation approach
|
||||
|
||||
**Context to pass**:
|
||||
- The specific API or feature being used
|
||||
- Engine version and LLM knowledge cutoff (from `docs/engine-reference/[engine]/VERSION.md`)
|
||||
- Relevant excerpt from breaking-changes or deprecated-apis docs
|
||||
|
||||
**Prompt**:
|
||||
> "Review this engine API usage against the version reference. Is this API present
|
||||
> in [engine version]? Has its signature, behaviour, or namespace changed since the
|
||||
> LLM knowledge cutoff? Are there known deprecations or post-cutoff alternatives?
|
||||
> Return APPROVE (safe to use as described), CONCERNS [verify before implementing],
|
||||
> or REJECT [API has changed — provide corrected approach]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,24 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# TD-FEASIBILITY — Technical Feasibility Assessment
|
||||
|
||||
Agent: `technical-director` | Model tier: Opus | Domain: Architecture, engine risk, performance
|
||||
|
||||
**Trigger**: After biggest technical risks are identified during scope/feasibility
|
||||
(brainstorm Phase 6, quick-design, or any early-stage concept with technical unknowns)
|
||||
|
||||
**Context to pass**:
|
||||
- Concept's core loop description
|
||||
- Platform target
|
||||
- Engine choice (or "undecided")
|
||||
- List of identified technical risks
|
||||
|
||||
**Prompt**:
|
||||
> "Review these technical risks for a [genre] game targeting [platform] using
|
||||
> [engine or 'undecided engine']. Flag any HIGH risk items that could invalidate
|
||||
> the concept as described, any risks that are engine-specific and should influence
|
||||
> the engine choice, and any risks that are commonly underestimated by solo
|
||||
> developers. Return VIABLE (risks are manageable), CONCERNS [list with mitigation
|
||||
> suggestions], or HIGH RISK [blockers that require concept or scope revision]."
|
||||
|
||||
**Verdicts**: VIABLE / CONCERNS / HIGH RISK
|
||||
@@ -0,0 +1,26 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# TD-MANIFEST — Control Manifest Review
|
||||
|
||||
Agent: `technical-director` | Model tier: Opus | Domain: Architecture, engine risk, performance
|
||||
|
||||
**Trigger**: After control-manifest rules are extracted and previewed
|
||||
(`/create-control-manifest` Phase 4), before the manifest file is written
|
||||
|
||||
**Context to pass**:
|
||||
- The Control Manifest Preview from Phase 4 (rule counts per layer, full extracted rule list)
|
||||
- The list of ADRs covered
|
||||
- Engine version
|
||||
- Any rules sourced from `technical-preferences.md` or engine reference docs
|
||||
|
||||
**Prompt**:
|
||||
> "Review this control manifest before it is written. Are all mandatory ADR
|
||||
> patterns captured and accurately stated? Are the forbidden approaches complete
|
||||
> and correctly attributed to their source ADR? Were any rules added that lack a
|
||||
> source ADR or preference document — that is, invented rather than extracted?
|
||||
> Are the performance guardrails consistent with the constraints the ADRs
|
||||
> actually set? Return APPROVE, CONCERNS [list the specific rules to revise], or
|
||||
> REJECT [rules that are wrong or unsourced and must be fixed before the manifest
|
||||
> is written]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
@@ -0,0 +1,22 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# TD-PHASE-GATE — Technical Readiness at Phase Transition
|
||||
|
||||
Agent: `technical-director` | Model tier: Opus | Domain: Architecture, engine risk, performance
|
||||
|
||||
**Trigger**: Always at `/gate-check` — spawn in parallel with CD-PHASE-GATE and PR-PHASE-GATE
|
||||
|
||||
**Context to pass**:
|
||||
- Target phase name
|
||||
- Architecture document path (if exists)
|
||||
- Engine reference path
|
||||
- ADR list
|
||||
|
||||
**Prompt**:
|
||||
> "Review the current project state for [target phase] gate readiness from a
|
||||
> technical direction perspective. Is the architecture sound for this phase? Are
|
||||
> all high-risk engine domains addressed? Are performance budgets realistic and
|
||||
> documented? Are Foundation-layer decisions complete enough to begin implementation?
|
||||
> Return READY, CONCERNS [list], or NOT READY [blockers]."
|
||||
|
||||
**Verdicts**: READY / CONCERNS / NOT READY
|
||||
@@ -0,0 +1,31 @@
|
||||
> Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
|
||||
|
||||
# TD-SYSTEM-BOUNDARY — System Boundary Architecture Review
|
||||
|
||||
Agent: `technical-director` | Model tier: Opus | Domain: Architecture, engine risk, performance
|
||||
|
||||
**Trigger**: After `/map-systems` Phase 3 dependency mapping is agreed but before
|
||||
GDD authoring begins — validates that the system structure is architecturally
|
||||
sound before teams invest in writing GDDs against it
|
||||
|
||||
**Context to pass**:
|
||||
- Systems index path (or the dependency map summary if index not yet written)
|
||||
- Layer assignments (Foundation / Core / Feature / Presentation / Polish)
|
||||
- The full dependency graph (what each system depends on)
|
||||
- Any bottleneck systems flagged (many dependents)
|
||||
- Any circular dependencies found and their proposed resolutions
|
||||
|
||||
**Prompt**:
|
||||
> "Review this systems decomposition from an architectural perspective before GDD
|
||||
> authoring begins. Are the system boundaries clean — does each system own a
|
||||
> distinct concern with minimal overlap? Are there God Object risks (systems doing
|
||||
> too much)? Does the dependency ordering create implementation-sequencing problems?
|
||||
> Are there implicit shared-state problems in the proposed boundaries that will
|
||||
> cause tight coupling when implemented? Are any Foundation-layer systems actually
|
||||
> dependent on Feature-layer systems (inverted dependency)? Return APPROVE
|
||||
> (boundaries are architecturally sound — proceed to GDD authoring), CONCERNS
|
||||
> [specific boundary issues to address in the GDDs themselves], or REJECT
|
||||
> [fundamental boundary problems — the system structure will cause architectural
|
||||
> issues and must be restructured before any GDD is written]."
|
||||
|
||||
**Verdicts**: APPROVE / CONCERNS / REJECT
|
||||
Reference in New Issue
Block a user