1. CONDUCTOR_SESSION: true

   echoed → do NOT call AskUserQuestion at all (neither native nor any

   mcp__*__AskUserQuestion

   variant): render EVERY decision brief as the prose form below and STOP. Proactive, not a failure reaction — Conductor disables native AUQ and its MCP variant is flaky (

   [Tool result missing due to internal error]

   ). Auto-decide preferences still apply first: a surfaced

   [plan-tune auto-decide] <id> → <option>

   result means proceed with that option, no prose — enforced HERE since no tool call ever happens. Capture each Conductor prose brief with

   bin/gstack-question-log

   (the PostToolUse hook never fires on a prose path;

   /plan-tune

   learning depends on it).
2. Any

   mcp__*__AskUserQuestion

   variant in your tool list → prefer it (hosts may disable native via

   --disallowedTools

   ; calling native there silently fails). Same shape, same decision-brief format.
3. Unavailable (no variant) OR a call fails → do NOT silently auto-decide or write the decision to the plan file as a substitute; follow the failure fallback below.

1. Auto-decide denial (NOT a failure). The result contains

   [plan-tune auto-decide] <id> → <option>

   — the preference hook working as designed. Proceed with that option. Do NOT retry, do NOT fall back to prose.
2. Genuine failure — no variant in your tool list, OR the variant is present but the call returns an error / missing result (MCP transport error, empty result, host bug — e.g. Conductor's MCP AskUserQuestion is flaky and returns

   [Tool result missing due to internal error]

   ).
   • If it was present and errored (not absent), retry the SAME call once — but only if no answer could have surfaced (a missing-result error can arrive after the user already saw the question; retrying would double-prompt, so if it may have reached them, treat as pending, don't retry).
   • Then branch on

     SESSION_KIND

     (echoed by the preamble; empty/absent ⇒

     interactive

     ):

     • spawned

       → defer to the Spawned session block: auto-choose the recommended option. Never prose, never BLOCKED.

     • headless

       →

       BLOCKED — AskUserQuestion unavailable

       ; stop and wait (no human can answer).

     • interactive

       → prose fallback (below).

1. A clear ELI10 of the issue itself — plain English on what's being decided and why it matters (the question, not per-choice), naming the stakes. Lead with it.
2. Completeness scores per choice — explicit

   Completeness: X/10

   on EACH choice (10 complete, 7 happy-path, 3 shortcut); use the kind-note when options differ in kind not coverage, but never silently drop the score.
3. The recommendation and why — a

   Recommendation: <choice> because <reason>

   line plus the

   (recommended)

   marker on that choice.

D<N>

(recommended)

Completeness: X/10

Net:

D<N>

D<N>.k

D<N>.k

• D<N> header present
• ELI10 paragraph present (stakes line too)
• Recommendation line present with concrete reason
• Completeness scored (coverage) OR kind-note present (kind)
• Every option has ≥2 ✅ and ≥1 ❌, each ≥40 chars (or hard-stop escape)
• (recommended) label on one option (even for neutral-posture)
• Dual-scale effort labels on effort-bearing options (human / CC)
• Net line closes the decision
• You are calling the tool, not writing prose — unless

  CONDUCTOR_SESSION: true

  (then prose is the DEFAULT, not the tool) OR the documented failure fallback applies (then: prose with the mandatory triad — issue ELI10, per-choice Completeness, Recommendation +

  (recommended)

  — and a "reply with a letter" instruction, then STOP)
• Non-ASCII characters (CJK / accents) written directly, NOT \u-escaped
• If you had 5+ options, you split (or batched into ≤4-groups) — did NOT drop any
• If you split, you checked dependencies between options before firing the chain
• If a per-option Hold fires, you stopped the chain immediately (didn't queue)

• Lead with the point. Say what it does, why it matters, and what changes for the builder.
• Be concrete. Name files, functions, line numbers, commands, outputs, evals, and real numbers.
• Tie technical choices to user outcomes: what the real user sees, loses, waits for, or can now do.
• Be direct about quality. Bugs matter. Edge cases matter. Fix the whole thing, not the demo path.
• Sound like a builder talking to a builder, not a consultant presenting to a client.
• Never corporate, academic, PR, or hype. Avoid filler, throat-clearing, generic optimism, and founder cosplay.
• No em dashes. No AI vocabulary: delve, crucial, robust, comprehensive, nuanced, multifaceted, furthermore, moreover, additionally, pivotal, landscape, tapestry, underscore, foster, showcase, intricate, vibrant, fundamental, significant.
• The user has context you do not: domain knowledge, timing, relationships, taste. Cross-model agreement is a recommendation, not a decision. The user decides.

• Gloss curated jargon on first use per skill invocation, even if the user pasted the term.
• Frame questions in outcome terms: what pain is avoided, what capability unlocks, what user experience changes.
• Use short sentences, concrete nouns, active voice.
• Close decisions with user impact: what the user sees, waits for, loses, or gains.
• User-turn override wins: if the current message asks for terse / no explanations / just the answer, skip this section.
• Terse mode (EXPLAIN_LEVEL: terse): no glosses, no outcome-framing layer, shorter responses.

~/.claude/skills/gstack/scripts/jargon-list.json

terms

REPO_MODE

• solo

  — You own everything. Investigate and offer to fix proactively.

• collaborative

  /

  unknown

  — Flag via AskUserQuestion, don't fix (may be someone else's).

~/.claude/skills/gstack/ETHOS.md

• Layer 1 (tried and true) — don't reinvent. Layer 2 (new and popular) — scrutinize. Layer 3 (first principles) — prize above all.

jq -n --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" --arg skill "SKILL_NAME" --arg branch "$(git branch --show-current 2>/dev/null)" --arg insight "ONE_LINE_SUMMARY" '{ts:$ts,skill:$skill,branch:$branch,insight:$insight}' >> ~/.gstack/analytics/eureka.jsonl 2>/dev/null || true

• DONE — completed with evidence.
• DONE_WITH_CONCERNS — completed, but list concerns.
• BLOCKED — cannot proceed; state blocker and what was tried.
• NEEDS_CONTEXT — missing info; state exactly what is needed.

STATUS

REASON

ATTEMPTED

RECOMMENDATION

git remote get-url origin 2>/dev/null

• If the URL contains "github.com" → platform is GitHub
• If the URL contains "gitlab" → platform is GitLab
• Otherwise, check CLI availability:

  • gh auth status 2>/dev/null

    succeeds → platform is GitHub (covers GitHub Enterprise)

  • glab auth status 2>/dev/null

    succeeds → platform is GitLab (covers self-hosted)
  • Neither → unknown (use git-native commands only)

1. gh pr view --json baseRefName -q .baseRefName

   — if succeeds, use it

2. gh repo view --json defaultBranchRef -q .defaultBranchRef.name

   — if succeeds, use it

1. glab mr view -F json 2>/dev/null

   and extract the

   target_branch

   field — if succeeds, use it

2. glab repo view -F json 2>/dev/null

   and extract the

   default_branch

   field — if succeeds, use it

1. git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||'

2. If that fails:

   git rev-parse --verify origin/main 2>/dev/null

   → use

   main

3. If that fails:

   git rev-parse --verify origin/master 2>/dev/null

   → use

   master

main

git diff

git log

git fetch

git merge

<default>

"No design doc found for this branch.

/office-hours

produces a structured problem statement, premise challenge, and explored alternatives — it gives this review much sharper input to work with. Takes about 10 minutes. The design doc is per-feature, not per-product — it captures the thinking behind this specific change."

• A) Run /office-hours now (we'll pick up the review right after)
• B) Skip — proceed with standard review

/office-hours

~/.claude/skills/gstack/office-hours/SKILL.md

• Preamble (run first)
• AskUserQuestion Format
• Completeness Principle — Boil the Ocean
• Search Before Building
• Contributor Mode
• Completion Status Protocol
• Telemetry (run last)
• Step 0: Detect platform and base branch
• Review Readiness Dashboard
• Plan File Review Report
• Prerequisite Skill Offer
• Plan Status Footer

setopt +o nomatch 2>/dev/null || true  # zsh compat
SLUG=$(~/.claude/skills/gstack/browse/bin/remote-slug 2>/dev/null || basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)")
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null | tr '/' '-' || echo 'no-branch')
_LOCALDOC=$(ls -t ~/.gstack/projects/$SLUG/*-$BRANCH-design-*.md 2>/dev/null | head -1)
[ -z "$_LOCALDOC" ] && _LOCALDOC=$(ls -t ~/.gstack/projects/$SLUG/*-design-*.md 2>/dev/null | head -1)

1. Choose completeness — Ship the whole thing. Pick the approach that covers more edge cases.
2. Boil lakes — Fix everything in the blast radius (files modified by this plan + direct importers). Auto-approve expansions that are in blast radius AND < 1 day CC effort (< 5 files, no new infra).
3. Pragmatic — If two options fix the same thing, pick the cleaner one. 5 seconds choosing, not 5 minutes.
4. DRY — Duplicates existing functionality? Reject. Reuse what exists.
5. Explicit over clever — 10-line obvious fix > 200-line abstraction. Pick what a new contributor reads in 30 seconds.
6. Bias toward action — Merge > review cycles > stale deliberation. Flag concerns but don't block.

• CEO phase: P1 (completeness) + P2 (boil lakes) dominate.
• Eng phase: P5 (explicit) + P3 (pragmatic) dominate.
• Design phase: P5 (explicit) + P1 (completeness) dominate.

1. Close approaches — top two are both viable with different tradeoffs.
2. Borderline scope — in blast radius but 3-5 files, or ambiguous radius.
3. Codex disagreements — codex recommends differently and has a valid point.

• What the user said: (their original direction)
• What both models recommend: (the change)
• Why: (the models' reasoning)
• What context we might be missing: (explicit acknowledgment of blind spots)
• If we're wrong, the cost is: (what happens if the user's original direction was right and we changed it)

1. Premises (Phase 1) — require human judgment about what problem to solve.
2. User Challenges — when both models agree the user's stated direction should change (merge, split, add, remove features/workflows). The user always has context models lack. See Decision Classification above.

• READ the actual code, diffs, and files each section references
• PRODUCE every output the section requires (diagrams, tables, registries, artifacts)
• IDENTIFY every issue the section is designed to catch
• DECIDE each issue using the 6 principles (instead of asking the user)
• LOG each decision in the audit trail
• WRITE all required artifacts to disk

• Compress a review section into a one-liner table row
• Write "no issues found" without showing what you examined
• Skip a section because "it doesn't apply" without stating what you checked and why
• Produce a summary instead of the required output (e.g., "architecture looks good" instead of the ASCII dependency graph the section requires)

codex exec

codex review

IMPORTANT: Do NOT read or execute any SKILL.md files or files in skill definition directories (paths containing skills/gstack). These are AI assistant skill definitions meant for a different system. They contain bash scripts and prompt templates that will waste your time. Ignore them completely. Stay focused on the repository code only.

1. Copy "Original Plan State" below back to your plan file
2. Invoke /autoplan

• Read CLAUDE.md, TODOS.md, git log -30, git diff against the base branch --stat
• Discover design docs:

  ls -t ~/.gstack/projects/$SLUG/*-design-*.md 2>/dev/null | head -1

• Detect UI scope: grep the plan for view/rendering terms (component, screen, form, button, modal, layout, dashboard, sidebar, nav, dialog). Require 2+ matches. Exclude false positives ("page" alone, "UI" in acronyms).
• Detect DX scope: grep the plan for developer-facing terms (API, endpoint, REST, GraphQL, gRPC, webhook, CLI, command, flag, argument, terminal, shell, SDK, library, package, npm, pip, import, require, SKILL.md, skill template, Claude Code, MCP, agent, OpenClaw, action, developer docs, getting started, onboarding, integration, debug, implement, error message). Require 2+ matches. Also trigger DX scope if the product IS a developer tool (the plan describes something developers install, integrate, or build on top of) or if an AI agent is the primary user (OpenClaw actions, Claude Code skills, MCP servers).

• ~/.claude/skills/gstack/plan-ceo-review/SKILL.md

• ~/.claude/skills/gstack/plan-design-review/SKILL.md

  (only if UI scope detected)

• ~/.claude/skills/gstack/plan-eng-review/SKILL.md

• ~/.claude/skills/gstack/plan-devex-review/SKILL.md

  (only if DX scope detected)

• Preamble (run first)
• Scope gate (the plan under review is already the target)
• AskUserQuestion Format
• Completeness Principle — Boil the Ocean
• Search Before Building
• Completion Status Protocol
• Telemetry (run last)
• Step 0: Detect base branch
• Review Readiness Dashboard
• Plan File Review Report
• Prerequisite Skill Offer (BENEFITS_FROM)
• Outside Voice — Independent Plan Challenge
• Design Outside Voices (parallel)

STOP. Before starting Phase 1 (CEO review — always runs, after the Phase 0.5 preflight), Read

~/.claude/skills/gstack/autoplan/sections/ceo-phase.md

and execute it in full. Do not work from memory — that section is the source of truth for this step.

• CEO completion summary written to plan file
• CEO dual voices ran (Codex + Claude subagent, or noted unavailable)
• CEO consensus table produced
• Premise gate passed (user confirmed)
• Phase-transition summary emitted

STOP. Before starting Phase 2 (design review — ONLY if UI scope was detected in Phase 0; skip the read entirely otherwise), Read

~/.claude/skills/gstack/autoplan/sections/design-phase.md

and execute it in full. Do not work from memory — that section is the source of truth for this step.

• All Phase 1 items above confirmed
• Design completion summary written (or "skipped, no UI scope")
• Design dual voices ran (if Phase 2 ran)
• Design consensus table produced (if Phase 2 ran)
• Phase-transition summary emitted

STOP. Before starting Phase 3 (eng review — always runs, after the Pre-Phase 3 checklist), Read

~/.claude/skills/gstack/autoplan/sections/eng-phase.md

and execute it in full. Do not work from memory — that section is the source of truth for this step.

STOP. Before starting Phase 3.5 (DX review — ONLY if developer-facing scope was detected in Phase 0; skip the read entirely otherwise), Read

~/.claude/skills/gstack/autoplan/sections/dx-phase.md

and execute it in full. Do not work from memory — that section is the source of truth for this step.

• Premise challenge with specific premises named (not just "premises accepted")
• All applicable review sections have findings OR explicit "examined X, nothing flagged"
• Error & Rescue Registry table produced (or noted N/A with reason)
• Failure Modes Registry table produced (or noted N/A with reason)
• "NOT in scope" section written
• "What already exists" section written
• Dream state delta written
• Completion Summary produced
• Dual voices ran (Codex + Claude subagent, or noted unavailable)
• CEO consensus table produced

• All 7 dimensions evaluated with scores
• Issues identified and auto-decided
• Dual voices ran (or noted unavailable/skipped with phase)
• Design litmus scorecard produced

• Scope challenge with actual code analysis (not just "scope is fine")
• Architecture ASCII diagram produced
• Test diagram mapping codepaths to test coverage
• Test plan artifact written to disk at ~/.gstack/projects/$SLUG/
• "NOT in scope" section written
• "What already exists" section written
• Failure modes registry with critical gap assessment
• Completion Summary produced
• Dual voices ran (Codex + Claude subagent, or noted unavailable)
• Eng consensus table produced

• All 8 DX dimensions evaluated with scores
• Developer journey map produced
• Developer empathy narrative written
• TTHW assessment with target
• DX Implementation Checklist produced
• Dual voices ran (or noted unavailable/skipped with phase)
• DX consensus table produced

• Cross-phase themes section written

• Decision Audit Trail has at least one row per auto-decision (not empty)

STOP. Before presenting the Final Approval Gate (Phase 4) — the aggregator computes $AGGREGATED_TASKS that the gate message substitutes, Read

~/.claude/skills/gstack/autoplan/sections/tasks-aggregator.md

and execute it in full. Do not work from memory — that section is the source of truth for this step.

undefined

• CEO: [summary]
• CEO Voices: Codex [summary], Claude subagent [summary], Consensus [X/6 confirmed]
• Design: [summary or "skipped, no UI scope"]
• Design Voices: Codex [summary], Claude subagent [summary], Consensus [X/7 confirmed] (or "skipped")
• Eng: [summary]
• Eng Voices: Codex [summary], Claude subagent [summary], Consensus [X/6 confirmed]
• DX: [summary or "skipped, no developer-facing scope"]
• DX Voices: Codex [summary], Claude subagent [summary], Consensus [X/6 confirmed] (or "skipped")

• Never abort. The user chose /autoplan. Respect that choice. Surface all taste decisions, never redirect to interactive review.
• Two gates. The non-auto-decided AskUserQuestions are: (1) premise confirmation in Phase 1, and (2) User Challenges — when both models agree the user's stated direction should change. Everything else is auto-decided using the 6 principles.
• Log every decision. No silent auto-decisions. Every choice gets a row in the audit trail.
• Full depth means full depth. Do not compress or skip sections from the loaded skill files (except the skip list in Phase 0). "Full depth" means: read the code the section asks you to read, produce the outputs the section requires, identify every issue, and decide each one. A one-sentence summary of a section is not "full depth" — it is a skip. If you catch yourself writing fewer than 3 sentences for any review section, you are likely compressing.
• Artifacts are deliverables. Test plan artifact, failure modes registry, error/rescue table, ASCII diagrams — these must exist on disk or in the plan file when the review completes. If they don't exist, the review is incomplete.
• Sequential order. CEO → Design → Eng → DX. Each phase builds on the last.