feat: add Gemini CLI slash command support

Introduces .gemini/commands/ with TOML definitions for 7 slash commands
(build, spec, planning, review, test, ship, code-simplify), enabling
Gemini CLI to auto-discover them from the project root.

The planning command is named /planning rather than /plan to avoid
conflicting with a Gemini CLI internal command name.

Updates README.md project structure tree and adds a Slash Commands
section with a reference table to docs/gemini-cli-setup.md.

.gemini/commands/build.toml

@@ -0,0 +1,19 @@
+name = "build"
+description = "Implement the next task incrementally — build, test, verify, commit"
+
+prompt = """
+Invoke the agent-skills:incremental-implementation skill alongside agent-skills:test-driven-development.
+
+Pick the next pending task from the plan. For each task:
+
+1. Read the task's acceptance criteria
+2. Load relevant context (existing code, patterns, types)
+3. Write a failing test for the expected behavior (RED)
+4. Implement the minimum code to pass the test (GREEN)
+5. Run the full test suite to check for regressions
+6. Run the build to verify compilation
+7. Commit with a descriptive message
+8. Mark the task complete and move to the next one
+
+If any step fails, follow the agent-skills:debugging-and-error-recovery skill.
+"""

.gemini/commands/code-simplify.toml

@@ -0,0 +1,23 @@
+name = "code-simplify"
+description = "Simplify code for clarity and maintainability — reduce complexity without changing behavior"
+
+prompt = """
+Invoke the agent-skills:code-simplification skill.
+
+Simplify recently changed code (or the specified scope) while preserving exact behavior:
+
+1. Read GEMINI.md and study project conventions
+2. Identify the target code — recent changes unless a broader scope is specified
+3. Understand the code's purpose, callers, edge cases, and test coverage before touching it
+4. Scan for simplification opportunities:
+   - Deep nesting → guard clauses or extracted helpers
+   - Long functions → split by responsibility
+   - Nested ternaries → if/else or switch
+   - Generic names → descriptive names
+   - Duplicated logic → shared functions
+   - Dead code → remove after confirming
+5. Apply each simplification incrementally — run tests after each change
+6. Verify all tests pass, the build succeeds, and the diff is clean
+
+If tests fail after a simplification, revert that change and reconsider. Use `code-review-and-quality` to review the result.
+"""

.gemini/commands/planning.toml

@@ -0,0 +1,17 @@
+name = "planning"
+description = "Break work into small verifiable tasks with acceptance criteria and dependency ordering"
+
+prompt = """
+Invoke the agent-skills:planning-and-task-breakdown skill.
+
+Read the existing spec (SPEC.md or equivalent) and the relevant codebase sections. Then:
+
+1. Enter plan mode — read only, no code changes
+2. Identify the dependency graph between components
+3. Slice work vertically (one complete path per task, not horizontal layers)
+4. Write tasks with acceptance criteria and verification steps
+5. Add checkpoints between phases
+6. Present the plan for human review
+
+Save the plan to tasks/plan.md and task list to tasks/todo.md.
+"""

.gemini/commands/review.toml

@@ -0,0 +1,17 @@
+name = "review"
+description = "Conduct a five-axis code review — correctness, readability, architecture, security, performance"
+
+prompt = """
+Invoke the agent-skills:code-review-and-quality skill.
+
+Review the current changes (staged or recent commits) across all five axes:
+
+1. **Correctness** — Does it match the spec? Edge cases handled? Tests adequate?
+2. **Readability** — Clear names? Straightforward logic? Well-organized?
+3. **Architecture** — Follows existing patterns? Clean boundaries? Right abstraction level?
+4. **Security** — Input validated? Secrets safe? Auth checked? (Use security-and-hardening skill)
+5. **Performance** — No N+1 queries? No unbounded ops? (Use performance-optimization skill)
+
+Categorize findings as Critical, Important, or Suggestion.
+Output a structured review with specific file:line references and fix recommendations.
+"""

.gemini/commands/ship.toml

@@ -0,0 +1,73 @@
+name = "ship"
+description = "Run the pre-launch checklist via parallel fan-out to specialist personas, then synthesize a go/no-go decision"
+
+prompt = """
+Invoke the agent-skills:shipping-and-launch skill.
+
+`/ship` is a **fan-out orchestrator**. It runs three specialist personas in parallel against the current change, then merges their reports into a single go/no-go decision with a rollback plan. The personas operate independently — no shared state, no ordering — which is what makes parallel execution safe and useful here.
+
+## Phase A — Parallel fan-out
+
+Spawn three subagents concurrently using the Agent tool. **Issue all three Agent tool calls in a single assistant turn so they execute in parallel** — sequential calls defeat the purpose of this command.
+
+In Gemini CLI, each call passes `subagent_type` matching the persona's `name` field:
+
+1. **`code-reviewer`** — Run a five-axis review (correctness, readability, architecture, security, performance) on the staged changes or recent commits. Output the standard review template.
+2. **`security-auditor`** — Run a vulnerability and threat-model pass. Check OWASP Top 10, secrets handling, auth/authz, dependency CVEs. Output the standard audit report.
+3. **`test-engineer`** — Analyze test coverage for the change. Identify gaps in happy path, edge cases, error paths, and concurrency scenarios. Output the standard coverage analysis.
+
+In other harnesses without an Agent tool, invoke each persona's system prompt sequentially and treat their outputs as if returned in parallel — the merge phase still works.
+
+Constraints (from Gemini CLI's subagent model):
+- Subagents cannot spawn other subagents — do not let one persona delegate to another.
+- Each subagent gets its own context window and returns only its report to this main session.
+- If you need teammates that talk to each other instead of just reporting back, use Gemini CLI Agent Teams and reference these personas as teammate types (see `references/orchestration-patterns.md`).
+
+**Persona resolution.** If you've defined your own `code-reviewer`, `security-auditor`, or `test-engineer` in `.gemini/agents/` or `~/.gemini/agents/`, those take precedence over this plugin's versions — `/ship` picks up your customizations automatically. This is intentional: plugin subagents sit at the bottom of Gemini CLI's scope priority table, so user-level definitions win by design.
+
+## Phase B — Merge in main context
+
+Once all three reports are back, the main agent (not a sub-persona) synthesizes them:
+
+1. **Code Quality** — Aggregate Critical/Important findings from `code-reviewer` and any failing tests, lint, or build output. Resolve duplicates between reviewers.
+2. **Security** — Promote any Critical/High `security-auditor` findings to launch blockers. Cross-reference with `code-reviewer`'s security axis.
+3. **Performance** — Pull from `code-reviewer`'s performance axis; cross-check Core Web Vitals if applicable.
+4. **Accessibility** — Verify keyboard nav, screen reader support, contrast (not covered by the three personas — handle directly here, or invoke the accessibility checklist).
+5. **Infrastructure** — Env vars, migrations, monitoring, feature flags. Verify directly.
+6. **Documentation** — README, ADRs, changelog. Verify directly.
+
+## Phase C — Decision and rollback
+
+Produce a single output:
+
+```markdown
+## Ship Decision: GO | NO-GO
+
+### Blockers (must fix before ship)
+- [Source persona: Critical finding + file:line]
+
+### Recommended fixes (should fix before ship)
+- [Source persona: Important finding + file:line]
+
+### Acknowledged risks (shipping anyway)
+- [Risk + mitigation]
+
+### Rollback plan
+- Trigger conditions: [what signals would prompt rollback]
+- Rollback procedure: [exact steps]
+- Recovery time objective: [target]
+
+### Specialist reports (full)
+- [code-reviewer report]
+- [security-auditor report]
+- [test-engineer report]
+```
+
+## Rules
+
+1. The three Phase A personas run in parallel — never sequentially.
+2. Personas do not call each other. The main agent merges in Phase B.
+3. The rollback plan is mandatory before any GO decision.
+4. If any persona returns a Critical finding, the default verdict is NO-GO unless the user explicitly accepts the risk.
+5. **Skip the fan-out only if all of the following are true:** the change touches 2 files or fewer, the diff is under 50 lines, and it does not touch auth, payments, data access, or config/env. Otherwise, default to fan-out. `/ship` is designed for production-bound changes — when the blast radius is non-trivial, run the parallel review even if the diff looks small.
+"""

.gemini/commands/spec.toml

@@ -0,0 +1,16 @@
+name = "spec"
+description = "Start spec-driven development — write a structured specification before writing code"
+
+prompt = """
+Invoke the agent-skills:spec-driven-development skill.
+
+Begin by understanding what the user wants to build. Ask clarifying questions about:
+1. The objective and target users
+2. Core features and acceptance criteria
+3. Tech stack preferences and constraints
+4. Known boundaries (what to always do, ask first about, and never do)
+
+Then generate a structured spec covering all six core areas: objective, commands, project structure, code style, testing strategy, and boundaries.
+
+Save the spec as SPEC.md in the project root and confirm with the user before proceeding.
+"""

.gemini/commands/test.toml

@@ -0,0 +1,20 @@
+name = "test"
+description = "Run TDD workflow — write failing tests, implement, verify. For bugs, use the Prove-It pattern."
+
+prompt = """
+Invoke the agent-skills:test-driven-development skill.
+
+For new features:
+1. Write tests that describe the expected behavior (they should FAIL)
+2. Implement the code to make them pass
+3. Refactor while keeping tests green
+
+For bug fixes (Prove-It pattern):
+1. Write a test that reproduces the bug (must FAIL)
+2. Confirm the test fails
+3. Implement the fix
+4. Confirm the test passes
+5. Run the full test suite for regressions
+
+For browser-related issues, also invoke agent-skills:browser-testing-with-devtools to verify with Chrome DevTools MCP.
+"""

README.md

@@ -265,7 +265,8 @@ agent-skills/
 ├── agents/                            # 3 specialist personas
 ├── references/                        # 4 supplementary checklists
 ├── hooks/                             # Session lifecycle hooks
-├── .claude/commands/                  # 7 slash commands
+├── .claude/commands/                  # 7 slash commands (Claude Code)
+├── .gemini/commands/                  # 7 slash commands (Gemini CLI)
 └── docs/                              # Setup guides per tool
 ```
 

docs/gemini-cli-setup.md

@@ -105,6 +105,24 @@ Use the @skills/test-driven-development/SKILL.md skill to implement this fix.
 
 This is useful when you want to ensure a specific workflow is followed without waiting for auto-discovery.
 
+## Slash Commands
+
+The repo ships 7 slash commands under `.gemini/commands/` that map to the development lifecycle. Gemini CLI auto-discovers them when you run from the project root.
+
+| Command | What it does |
+|---------|--------------|
+| `/spec` | Write a structured spec before writing code |
+| `/planning` | Break work into small, verifiable tasks |
+| `/build` | Implement the next task incrementally |
+| `/test` | Run TDD workflow — red, green, refactor |
+| `/review` | Five-axis code review |
+| `/code-simplify` | Reduce complexity without changing behavior |
+| `/ship` | Pre-launch checklist via parallel persona fan-out |
+
+Each command invokes the corresponding skill automatically — no manual skill loading required.
+
+> **Note:** Use `/planning` instead of `/plan` — `/plan` conflicts with a Gemini CLI internal command name.
+
 ## Usage Tips
 
 1. **Prefer skills over GEMINI.md** — Skills activate on demand and keep your context window focused. Only put skills in GEMINI.md if you want them always loaded.