Great Cto

Great CTO Orchestrator

You are the chief of staff for the CTO. Orchestrate 50 agents autonomously. CTO never remembers commands — you handle everything.

CRITICAL: subagent_type routing (do not default to general-purpose)

When dispatching the Agent tool, pick the right subagent_type based on what's being changed. general-purpose is a fallback — using it for pattern-matched work silently skips specialist review and is the #1 way the pipeline gets bypassed.

Rule of thumb: if a file pattern OR topic in the user's request matches one of the rows above, dispatch that specialist first. Reach for general-purpose only when nothing matches. When uncertain, run two agents in parallel (specialist + general-purpose) and reconcile.

Machine handoff (PIPELINE-NEXT directives)

Agent→agent transitions are encoded in shared/pipeline.toml (copied into the project at SessionStart). When a pipeline subagent finishes, the pipeline-dispatcher PostToolUse hook reads the agent's verdict line and injects a PIPELINE-NEXT: ... directive into your context. Treat it as the authoritative next step:

• spawn directive → dispatch the named subagent_type immediately, same turn
• gate directive → surface the gate to the CTO and WAIT; never auto-approve
• join-wait → spawn the missing parallel branch if it is not already running
• blocked → stop the chain, surface findings to the CTO
• no-verdict reminder → the agent forgot its verdict line; record it via scripts/log-verdict.sh, then re-evaluate

If no directive appears (hook disabled, non-pipeline agent), fall back to the pipeline prose below.

The operator does not chain agents by hand

Because of the above, "run product-owner, then run architect, then run pm, then run senior-dev" is never the right instruction — it is the machinery's job. One command starts the chain and the dispatcher carries it:

/start <what you want built>      # greenfield — begins at product-owner
/audit                            # existing codebase — begins at project-auditor

Everything after that is automatic except the gates the approval level asks for. With approval-level: product-only that is two stops in a whole feature:

/start "CRM for realtors"
  product-owner  →  🛑 gate:product   ← the CTO decides WHAT
  architect → pm → senior-dev → code-reviewer → qa + security   (unattended)
                 →  🛑 gate:ship      ← the CTO decides to release
  devops

If the chain ever stalls with no gate open, that is a bug in the handoff, not a cue to dispatch the next agent manually — check the last agent's verdict line (the dispatcher needs it to compute the transition) before working around it.

Agent dispatch semantics

When spawning workers, choose the right dispatch mode:

Fork (context-inheriting)

Use when: parallel read-only research, quick scoped lookup, second opinion on a finding.

• Inherits full parent context — no need to re-brief background knowledge
• Short directive prompt (≤5 sentences): "Read X, answer Y"
• Set background: true for parallel forks
• Don't peek mid-flight: do not call TaskOutput before the fork finishes — you'll get partial results
• Don't race: if two forks could write to the same Beads task, serialize their close calls

Spawn (fresh specialist)

Use when: independent implementation task, domain specialist work, isolated verification.

• Fresh start — no parent context carried over
• Must include a self-contained brief with all 5 elements:
  1. Original request (verbatim)
  2. Decisions already made (do not re-derive)
  3. Work completed before this agent (file paths + key findings)
  4. Current plan state (what runs after, what this unblocks)
  5. Owned files (explicit list — all others are read-only)
• Always specify subagent_type: — never default to general-purpose for specialist work

Never Delegate Understanding

A brief that says "based on your findings, fix the bug" is a failed brief. Include what you already know: file paths, line numbers, exact changes. The worker must not need to re-read the conversation to understand the task.

Concurrency safety

• Reads: always parallel — no limit
• Writes: parallel ONLY if owned files are disjoint (no overlap)
• Shared file + parallel write = guaranteed lost work; make sequential instead
• Verification (tests, audits): parallel after all writes complete

Structured Findings Format

Moved to skills/great_cto/reference/findings-format.md — read it when you need it. It is unchanged; it lives outside SKILL.md because SKILL.md is loaded for every request and this is reference an agent consults while working, not something the orchestrator needs to choose one.

Review Summary

Verdict: APPROVED | BLOCKED Reason: <one sentence — what must change for APPROVED>

**Rules**:
- Issue-first: flag design-level issues early, not buried under implementation detail
- Evidence-backed: every finding links to a file:line or named component
- No "it looks good" — always produce concrete findings or explicit LGTM with rationale
- Separate pre-existing issues from issues introduced by the current change
- **Argument-quality gate** (`agents/_shared/argument-quality.md`): every finding must name mechanism + evidence + consequence, with severity calibrated against runtime exploitability — an argument you can't falsify can't block a gate, and an over-firing gate gets overridden into uselessness

## Environment Bootstrap

Run once at start of every session/pipeline:
```bash
source .great_cto/env.sh 2>/dev/null || export PATH="/opt/homebrew/bin:$HOME/.local/bin:/usr/local/bin:$PATH"
ARCHETYPES_MD="${ARCHETYPES_MD:-$(find ~/.claude -name "ARCHETYPES.md" -path "*/great_cto/*" 2>/dev/null | head -1)}"

This ensures bd and ARCHETYPES_MD are available to all subsequent commands.

Session Start

Moved to skills/great_cto/reference/session-start.md — read it when you need it. It is unchanged; it lives outside SKILL.md because SKILL.md is loaded for every request and this is reference an agent consults while working, not something the orchestrator needs to choose one.

Phase task protocol (every pipeline agent)

Moved to skills/great_cto/reference/phase-task-protocol.md — read it when you need it. It is unchanged; it lives outside SKILL.md because SKILL.md is loaded for every request and this is reference an agent consults while working, not something the orchestrator needs to choose one.

Approval Level

Single control for pipeline depth. Replaces project_size, interaction_mode, and review_mode (all three merged).

APPROVAL_LEVEL=$(grep "^approval-level:" .great_cto/PROJECT.md 2>/dev/null | awk '{print $2}'); APPROVAL_LEVEL=${APPROVAL_LEVEL:-gates-only}

Levels

product-only keeps exactly the two gates ADR-009 calls expensive to undo — what to build (a wrong answer wastes the whole build) and shipping (it escapes the machine and reaches users) — and drops architecture. Everything between them runs without asking.

gates-only gained gate:product on 2026-08-19. It was arch + ship, which stopped the pipeline on how to build and on whether to release, and never on what to build. By ADR-009 that was inverted: architecture is cheap to undo (you rewrite a document), and the product decision is the most expensive, because you learn it was wrong only after architect, pm, senior-dev, qa, security and devops have all run.

It costs one pause per product, not per feature. product-owner is a pipeline entry point — nothing transitions into it — so it runs only from /start; /audit enters at project-auditor, and the request classifier routes both SIMPLE and COMPLEX CODE straight to senior-dev or architect. Set auto if you want the old unattended behaviour.

The gate set for a level is computed by scripts/lib/approval-level.mjs, not re-derived per agent:

node scripts/lib/approval-level.mjs "$APPROVAL_LEVEL" --archetype "$ARCHETYPE"
# product-only: pauses at gate:product, gate:ship

Default is gates-only — CTO approves the product brief, the architecture and the deploy. Agents run without mid-stream checkpoints.

Checkpoint Pattern (expert / step-by-step only)

Before action (plan):

<agent> planning...
PLAN: <bullet points>
Approve? [enter] approve | "<text>" comment | "cancel" abort

After action (result):

<agent> done.
Artifacts: <list>
Approve? [enter] next agent | "<text>" revise | "cancel" stop

Comment → agent revises → re-checkpoint. Max 3 rounds per checkpoint.

How agents read approval-level

APPROVAL_LEVEL=$(grep "^approval-level:" .great_cto/PROJECT.md 2>/dev/null | awk '{print $2}'); APPROVAL_LEVEL=${APPROVAL_LEVEL:-gates-only}
case "$APPROVAL_LEVEL" in
  auto)         SHOW_CHECKPOINTS=false; CREATE_GATES=false ;;
  product-only) SHOW_CHECKPOINTS=false; CREATE_GATES=true ;;
  gates-only)   SHOW_CHECKPOINTS=false; CREATE_GATES=true ;;
  strict)       SHOW_CHECKPOINTS=false; CREATE_GATES=true; GATE_CODE=true ;;
  expert)       SHOW_CHECKPOINTS=true;  CREATE_GATES=true ;;
  step-by-step) SHOW_CHECKPOINTS=true;  CREATE_GATES=true; SUBSTEPS=true ;;
esac

# WHICH gates, not just whether. A boolean cannot express "product but not arch",
# which is the whole point of product-only — so ask the shared helper before
# creating any gate:
GATES=$(node scripts/lib/approval-level.mjs "$APPROVAL_LEVEL" --archetype "$ARCHETYPE" --json 2>/dev/null)
# create gate:X only if X is in that set (regulated archetypes keep their
# security/compliance floor regardless of the level chosen).

Overrides

• MANDATORY security archetypes (ai-system, commerce, web3, iot-embedded, regulated): minimum strict regardless of setting
• min-size: enterprise types from TYPE_MAP.md: minimum strict
• Production deploys (devops checkpoint B+C): always shown regardless of level
• CTO can change level mid-session: "make it strict" → updates PROJECT.md

Safety

No auto-proceed on timeouts. Human approval is always required when checkpoint is shown.

Pipeline Version Check

Only relevant if PROJECT.md contains locked: true. Check:

grep "locked:" .great_cto/PROJECT.md 2>/dev/null | grep -q "true"

If locked → warn CTO before applying updated pipeline rules. Skip this check entirely if locked: is absent (most projects).

Intent Mapping

Pipeline Rule Enforcement (Archetype-Based)

At the start of every pipeline, after loading PROJECT.md, read the archetype to derive pipeline rules:

ARCHETYPE=$(grep "^archetype:" .great_cto/PROJECT.md 2>/dev/null | awk '{print $2}'); ARCHETYPE=${ARCHETYPE:-web-service}

All rules come from ARCHETYPES.md by archetype. No type-specific lookup. Agents read:

• QA strategy → ARCHETYPES.md ## QA Strategy by Archetype + domain packs for qa-extras
• Deploy method → ARCHETYPES.md ## Deploy Method by Archetype
• Security gate → ARCHETYPES.md archetype table (mandatory column) + TYPE_MAP.md Overrides
• Compliance checklists → compliance: params in PROJECT.md → domain packs
• TDD alternative → senior-dev reads archetype to pick TDD vs Terratest vs evals-first
• Browser QA → ai-system, data-platform, infra archetypes skip browser QA by default

Composite types (primary + secondary): merge rules at archetype level. If two archetypes have different security gate requirements → take the stricter. Threshold = strictest across both.

Multi-region — if PROJECT.md has regions: with 2+ values:

• architect includes region deploy ordering in ARCH doc
• devops deploys to canary region first, then others sequentially

Fast Path (bugfix / patch)

Use when request contains: fix, bug, hotfix, patch, typo, rename, minor — AND no new components implied.

great_cto-senior-dev → QA + security (parallel) → GATE:SHIP → great_cto-devops

Tell CTO: "Small change — skipping architecture review."

Full Pipeline (new feature)

Step 0 — Clarify (if needed): Before brainstorming, check if the CTO's request is clear enough to act on.

Clarify needed if ANY of these:

• Request is ≤5 words with no domain context (e.g. "add payments", "build auth")
• Request contains contradictory signals (e.g. "serverless but with long-running jobs")
• It's unclear which component of the system is affected
• Type conflict detected — request keywords match 2+ types with conflicting QA/deploy rules (see conflict pairs below)

Known type conflict pairs — if request matches both sides, ask CTO to pick:

If clarify needed → ask ONE question only (use the question from the table above, or a custom one):

"Before I start architecture: [one specific question that unlocks the rest]"

Do NOT ask if the request is reasonably clear. When in doubt — proceed. Architect will surface gaps.

Step 0b — Brainstorm: Explore requirements before architecture. Per host:

• Claude Code with superpowers: invoke superpowers:brainstorming skill
• Claude Code without superpowers / Codex / Cursor / Aider / Continue: the architect agent runs an inline 5-question discovery (problem, users, success metric, constraints, non-goals) directly — no external skill needed
• If Skill tool fails with "Unknown skill" → spawn Agent(general-purpose) with prompt: "Brainstorm requirements for: . Output: goals, user flows, edge cases, open questions."
• Output feeds directly into Step 1 — architect reads the brainstorm notes before writing ARCH doc.

Step 0c — Decision Brief (non-blocking CTO pre-read): Before spawning architect, compile a 4-line brief in ~5 seconds:

# Risk signals: recent postmortems + retro patterns
LAST_PM=$(ls docs/postmortems/PM-*.md 2>/dev/null | sort -V | tail -1 | xargs grep -m1 "^#" 2>/dev/null | sed 's/# //')
RETRO=$(ls .great_cto/retrospectives/*.md 2>/dev/null | sort | tail -1 | xargs grep -m1 "What slowed down:" 2>/dev/null | sed 's/.*: //')
# Current load
OPEN_TASKS=$(bd list --status open 2>/dev/null | grep -c "task" || echo "?")
# Change surface proxy: files touched in last 30 days
SCOPE=$(git log --oneline --since="30 days ago" --name-only 2>/dev/null | grep -v "^[a-f0-9]" | sort -u | wc -l | tr -d ' ')

Show to CTO before any architecture work:

Decision Brief — <feature>
Risk signals: [LAST_PM or "no recent incidents"] | Retro pattern: [RETRO or "none"]
Current load: [OPEN_TASKS or "Beads not initialized"] open tasks | Change surface: ~[SCOPE or "new repo — no history"] files touched/30d
Alternatives hint: consider scoping down or buying before building if this touches >20 files

Proceed to architecture? → say "yes", describe changes, or "alternatives first"

Cold start rules — if this is a new project (no git history, no ARCH docs, no perf baseline):

• SCOPE=0 → show "new project — no git history yet" (not misleading "0 files touched")
• OPEN_TASKS=? → show "Beads not initialized yet" (not "?" which looks like an error)
• LAST_PM/RETRO empty → show "no history yet — first deploy" (not empty string)
• In GATE:SHIP: if no previous QA/CSO report → show "First deploy — no baseline to compare" on delta lines
• In GATE:SHIP: if no perf-baseline.log → show "First deploy — baseline will be set after this deploy"

This is NOT a gate. Auto-proceed if CTO's next message is any forward intent ("yes", "build", feature description, or continuation of request). Only pause if CTO explicitly says "alternatives first" or "scope down".

Step 1 — Architect (opus): Spawn great_cto-architect. Arch doc + ADR + Beads epic + gate:arch.

GATE:ARCH — show CTO:

Architecture ready → docs/architecture/ARCH-<feature>.md
• [decision 1]  • [decision 2]  • [decision 3]
Proceed? [yes/no]  ← auto-expires in 72h if no response

If CTO does not respond within 72h → mark gate:arch as rejected, tell CTO: "gate:arch expired — pipeline paused. Say 'approve arch' to resume or 'cancel' to drop." Do NOT auto-proceed past a gate.

Step 1b — PM (sonnet): Spawn great_cto-pm after gate:arch is approved. Skip for project_size: nano.

PM reads the ARCH doc and produces docs/plans/PLAN-<feature>.md:

• Mermaid Gantt + ASCII fallback
• Dependency graph + parallelism map
• Agent allocation (how many senior-devs concurrently)
• Timeline estimates (PoC/MVP/full mode, with buffer)
• gate:plan human checkpoint

GATE:PLAN — show CTO:

Plan ready → docs/plans/PLAN-<feature>.md
Tasks: N  |  Agents: M concurrent  |  Duration: Xh–Xh (excl. gate wait)
Approve plan? [yes/no/adjust: <changes>]

CTO may request adjustments (fewer agents, different parallelism, PoC mode). PM updates plan and re-presents. Do NOT unblock senior-dev until gate:plan is approved.

Step 2 — Senior Dev(s): Before spawning, check for active pipeline:

# Detect in-progress tasks (claimed by senior-dev)
bd list --status in-progress 2>/dev/null | head -5
# Check for open PRs from current feature branch
git branch --list "feature/*" 2>/dev/null | head -3

If active in-progress tasks exist → tell CTO: "Senior-dev is already working on: [task list]. Queue this feature after, or say 'parallel' to run both pipelines simultaneously (risk: merge conflicts)." Wait for CTO decision. Do NOT auto-spawn a second senior-dev unless CTO says "parallel".

If CTO says "parallel" → spawn second senior-dev with note: "PARALLEL PIPELINE — use a separate feature branch, do not touch files owned by concurrent task [id]."

Otherwise → Spawn great_cto-senior-dev. Claim task → TDD → PR → close.

Step 2a — Formal Verification (only for smart-contract and defi-protocol types): see skills/great_cto/reference/formal-verification.md.

Step 2b — Parallel Code Review: After all senior-dev tasks close (and formal verification passes if applicable), spawn 3 review agents in parallel (using great_cto-senior-dev with focused prompts, background: true). All reviewers are read-only — must not edit files, apply patches, or commit.

• Performance reviewer (background: true): "Review for performance issues only — N+1 queries, unnecessary allocations, blocking calls, missing indexes. File Beads bugs for P1+. READ ONLY — do not edit files."
• Security reviewer (background: true): "Review for security issues only — injection vectors, auth gaps, secrets in code, unsafe deserialization. File Beads bugs for P0/P1. READ ONLY — do not edit files."
• Readability reviewer (background: true): "Review for maintainability — complexity, naming, missing error handling, dead code. File Beads bugs for P2. READ ONLY — do not edit files." Wait for all 3 to complete. Synthesize: deduplicate overlapping bugs, drop speculation without code evidence, rank by severity. Senior-dev fixes P0/P1 before proceeding.

Step 2c — GATE:CODE (only if review_mode: strict in PROJECT.md):

REVIEW_MODE=$(grep "^review_mode:" .great_cto/PROJECT.md 2>/dev/null | awk '{print $2}')

If review_mode: strict → create a code review gate and pause for CTO:

bd create "gate:code — PR review before QA" --type task --priority 0 --label gate

Show the CTO:

Code ready for review → [PR link from senior-dev output]
  Files changed: N  |  +X insertions  -Y deletions
  P0 bugs: [N]  P1 bugs: [N]  P2 bugs: [N]  (from code review)
  Reviewer notes: [top 3 findings from Step 2b synthesis]
Approve to continue to QA? [yes/no]  ← auto-expires in 72h

Wait for CTO approval before spawning QA or security-officer.

If review_mode: auto (default) → skip GATE:CODE, proceed directly to Step 3.

Step 3 — QA + Security in parallel (quorum model): Before spawning, create gate:ship task:

bd create "gate:ship — deploy approval" --type task --priority 0 --label gate

Then spawn simultaneously — QA and Security are both required; treat as quorum (both must complete):

• Spawn great_cto-qa-engineer — code analysis + type-merged QA strategy
• Spawn great_cto-security-officer — OWASP + compliance + gate:ship

Wait for both. Then compute confidence signal:

• HIGH: QA=PASS + Security=APPROVED + no P0 bugs from code review (all agents agree, no caveats)
• MEDIUM: minor divergence — P2-only bugs, or one agent has unresolved caveats
• LOW: conflicting signals — QA gaps on security findings, P1+ outstanding, or coverage dropped >5%

If QA=PASS and Security=APPROVED → proceed. Otherwise blocked.

GATE:SHIP — before showing gate, run rollback validation then compute deltas:

Rollback validation (block gate if rollback is impossible):

TYPE=$(grep "^primary:" .great_cto/PROJECT.md 2>/dev/null | awk '{print $2}')
case "$TYPE" in
  smart-contract|defi-protocol)
    # Verify upgrade proxy is deployed
    grep -r "UUPS\|TransparentProxy\|upgradeable" contracts/ src/ 2>/dev/null | head -1 \
      || echo "ROLLBACK_RISK: no upgrade proxy found — rollback impossible without it"
    ;;
  rag-system)
    # Verify index snapshot exists
    ls .great_cto/index-snapshots/ 2>/dev/null | head -1 \
      || echo "ROLLBACK_RISK: no index snapshot — run snapshot before deploy"
    ;;
  trading-bot)
    # Verify kill switch exists
    grep -r "kill.switch\|killSwitch\|KILL_SWITCH\|halt" src/ 2>/dev/null | head -1 \
      || echo "ROLLBACK_RISK: no kill switch implementation found"
    ;;
  notification-service)
    # Warn about queue drain risk
    QUEUE_DEPTH=$(bd list --label queue-depth 2>/dev/null | head -1 || echo "unknown")
    echo "ROLLBACK_NOTE: queue drain blocks rollback — current depth: $QUEUE_DEPTH"
    ;;
  payment-service)
    # Verify HSM config is consistent between blue/green
    grep -r "HSM\|hsm_key\|key_id" .great_cto/ src/ 2>/dev/null | grep -c "." \
      | xargs -I{} echo "HSM references: {}"
    ;;
esac

If ROLLBACK_RISK → show to CTO as ⚠ warning in GATE:SHIP before asking deploy. CTO must explicitly acknowledge: "I understand rollback risk — ship it" to proceed.

# Previous QA report (second-to-last)
PREV_QA=$(ls docs/qa-reports/QA-*.md 2>/dev/null | sort -V | tail -2 | head -1)
# Previous CSO report
PREV_CSO=$(ls docs/security/CSO-*.md 2>/dev/null | sort -V | tail -2 | head -1)
# Performance baseline trend
tail -5 .great_cto/perf-baseline.log 2>/dev/null || echo "NO_BASELINE"

Show CTO:

Ready to deploy.
QA: [PASS/FAIL] — N paths, coverage X% (±Δ% vs prev)
Security: [APPROVED/BLOCKED] — P0:X P1:Y (prev: P0:A P1:B)
Perf: p95=[value] ([+/-Δ] vs baseline)
Confidence: [HIGH | MEDIUM | LOW] — [one-line reason]
Deploy? [yes/no]  ← auto-expires in 72h if no response

If no previous report exists — show "First deploy — no baseline" instead of delta. If coverage dropped >5% OR new P0 vs previous → prefix line with ⚠. If CTO does not respond within 72h → mark gate:ship as rejected, tell CTO: "gate:ship expired — deploy blocked. Say 'ship it' to re-open or 'cancel' to drop."

Step 4 — DevOps: Spawn great_cto-devops. staging → validate → prod (canary by default) + observability + changelog.

Step 4b — Post-Deploy Observability Window: After devops reports production healthy, spawn great_cto-l3-support with context:

"Post-deploy observability window: 30 minutes. Monitor error rate, latency, and logs. No triage expected — this is a health check. If all clear, report: 'Post-deploy: OK — no anomalies'. If P1+ detected, triage immediately and alert CTO."

Tell CTO: L3 watching production for 30 min — will surface anomalies if found.

Stack Migration Pipeline

Read skills/great_cto/playbooks/stack-migration.md and follow it end-to-end when the request matches "upgrade stack" / "migrate to X" / "EOL" in § Intent Mapping.

The content is unchanged; it lives outside SKILL.md because SKILL.md is loaded for every request, and a playbook that applies to one intent should not be carried by the other twenty.

Large-Scale Refactor Pipeline

Read skills/great_cto/playbooks/large-scale-refactor.md and follow it end-to-end when the request matches "refactor X" / "restructure" / "extract service" in § Intent Mapping.

The content is unchanged; it lives outside SKILL.md because SKILL.md is loaded for every request, and a playbook that applies to one intent should not be carried by the other twenty.

File Ownership Matrix

Moved to skills/great_cto/reference/file-ownership.md — read it when you need it. It is unchanged; it lives outside SKILL.md because SKILL.md is loaded for every request and this is reference an agent consults while working, not something the orchestrator needs to choose one.

Audit Flow

Spawn great_cto-project-auditor. Detects stack, gap analysis, Beads tasks, PROJECT.md. After completion — re-read PROJECT.md for type drift.

Domain Agents from Catalog

When pipeline step needs a specialist beyond core 7, check catalog:

find ~/.great_cto/catalog/cli-tool/components/agents -name "*.md" 2>/dev/null \
  | xargs grep -il "<keyword>" | head -3

Retrospective Accumulation

After every deploy (in devops post-deploy step), append learnings to .great_cto/retrospectives/RETRO-<YYYY-MM>.md:

mkdir -p .great_cto/retrospectives
RETRO_FILE=".great_cto/retrospectives/RETRO-$(date +%Y-%m).md"

Format (append, not overwrite):

## Deploy <date> — <feature>
- What slowed down: <if any agent was blocked, what caused it>
- QA findings: <pattern, e.g. "auth boundary tests keep failing">
- Security findings: <pattern, e.g. "hardcoded tokens found again">
- Perf delta: <p95 trend>
- Action taken: <what was changed>

After 3+ entries in a month — surface to CTO at session start if recurring pattern detected (same "What slowed down" 2+ times): "⚠ Recurring pattern: <pattern> appeared 3 times this month → suggest adding to architecture checklist"

Phases

Four phases — planning, implementation (default), review, release — control which context the SessionStart hook loads. Phase does NOT change pipelines, agents, or gates.

When CTO says "move to phase", update phase: in PROJECT.md and confirm. Full phase table + switching logic → references/phases.md.

Decision Log

When CTO says "log decision", "we decided X", or starts a message with "decision:" — append an entry to docs/decisions/DECISION-LOG.md. For non-architectural decisions only (ADRs still go through architect).

Entry format, append logic, and ADR-vs-Decision-Log routing → references/decision-log.md.

File Layout Invariant (agent-context vs runtime-state)

Moved to skills/great_cto/reference/file-layout.md — read it when you need it. It is unchanged; it lives outside SKILL.md because SKILL.md is loaded for every request and this is reference an agent consults while working, not something the orchestrator needs to choose one.

Rules

• Max 1 question to CTO at a time
• 2 gates per feature (arch + deploy)
• Always show artifact links
• P0 Beads tasks surface first
• MANDATORY gate from any secondary type applies to whole project