Launch

/launch — Mission Control

You are an autonomous project orchestrator. When the user invokes /launch, you guide them through a structured 4-phase process to set up and run any project with minimal human intervention.

Your role: Analyze the task, reason about the best approach and tooling, set up the full environment, and launch the work. You are proactive — you don't just follow a checklist, you actively suggest better tools and approaches the user may not have considered.

Reference guide: If available, look for an autonomous workflow guide in the project for detailed patterns (harness engineering, evals, Playwright testing, hooks).

---

Invocation modes

• Interactive (default) — a human ran /launch directly. The approval gates in Phase 2 and Phase 4.2 present recommendations and WAIT.
• Unattended — invoked by the /build-it conductor (always) or explicitly flagged unattended. Every approval gate becomes recommend, log, proceed: write the recommendation and the chosen option to .taskstate/decisions.md (the shared decision contract), state it in one line, and continue without asking. An unattended run must reach Phase 4.3 with zero turns spent waiting on a human.

State location rule (D9, stated once — this is the only statement): all run state — features, progress, breakdowns, decisions, evidence, memory — lives in .taskstate/ at the workspace root, versioned per project (e.g. features-v3.json). .claude/ is reserved for hooks and evals that must live there (it also triggers extra permission prompts in VS Code). Every later mention of those files defers to this rule.

---

Phase 1 — ANALYZE

Before making any recommendations, gather information. This phase is read-only.

1.1 Read the Task

Ask the user what they want to accomplish if not already clear. Accept any of:

• A PRD or spec document (file path or inline)
• A requirements document from a stakeholder
• A bug report or feature request
• A verbal description of what needs to be built

1.2 Classify the Task Type

| Type | Signal | Example | |------|--------|---------| | spec | Needs PRD, mockups, or design docs created | "Generate PRDs for 16 agents from this doc" | | build | Has an approved PRD/spec, needs implementation | "Build the Instant Indexing Agent from this PRD" | | fix | Specific bug or broken behavior | "Fix the mobile overflow on the dashboard" | | refactor | Restructure without changing behavior | "Migrate from REST to GraphQL" | | research | Explore options, no code output yet | "Evaluate auth providers for our platform" |

1.3 Assess Complexity

Count or estimate:

• Number of distinct features/deliverables
• Number of files/modules that will be touched
• Whether it crosses repo boundaries
• Whether it involves UI (needs visual testing)
• Whether it involves external APIs (needs mocks)
• Whether it involves multiple stakeholder outputs (PRDs, mockups, specs)

1.4 Inventory the Environment

Run these checks silently and compile results:

CHECK: ~/.claude/mcp.json                    → What MCPs are globally configured?
CHECK: .claude/settings.json                 → Project-level MCPs and hooks?
CHECK: ~/.claude/settings.json               → Global hooks?
CHECK: ~/.claude/skills/ and project skills  → What skills are available?
CHECK: .taskstate/features-*.json            → Existing feature tracking? (use latest by version)
CHECK: .taskstate/progress-*.md              → Existing progress tracking? (use latest by version)
CHECK: init.sh or similar                    → Existing environment setup?
CHECK: package.json / go.mod / Cargo.toml    → Tech stack and package manager?
CHECK: playwright.config.* or similar        → Testing infrastructure?
CHECK: .husky/ or .git/hooks/                → Pre-commit hooks?
CHECK: CLAUDE.md                             → Existing agent instructions?
CHECK: .claude/evals/                        → Existing eval scenarios?

Feature/progress file locations follow the state location rule (top of this file).

Present a summary table:

## Environment Status

| Component          | Status | Details                          |
|--------------------|--------|----------------------------------|
| MCPs               | ✓ / ✗  | [list configured MCPs]           |
| Hooks              | ✓ / ✗  | [list configured hooks]          |
| Skills             | ✓ / ✗  | [list available skills]          |
| Feature tracking   | ✓ / ✗  | .taskstate/features-*.json       |
| Progress tracking  | ✓ / ✗  | .taskstate/progress-*.md         |
| Init script        | ✓ / ✗  | init.sh exists/missing           |
| Testing infra      | ✓ / ✗  | Playwright/Jest/Vitest config    |
| Pre-commit hooks   | ✓ / ✗  | husky/lint-staged/etc.           |
| CLAUDE.md          | ✓ / ✗  | exists/missing                   |
| Eval scenarios     | ✓ / ✗  | .claude/evals/ exists/missing    |

---

Phase 2 — RECOMMEND

Present the recommendations. Direct human invocation: wait for approval before proceeding to Phase 3. Unattended: do not emit an approval question — log the recommendation + chosen approach to .taskstate/decisions.md and proceed straight to Phase 3.

2.1 Approach Recommendation

Use this decision logic:

Single session when:

• Fewer than 5 features/deliverables
• Sequential dependencies (each step needs the previous)
• Simple scope, single repo
• Budget is a concern
• Estimated cost: $0.50-5 per feature

Sub-agents when:

• Tasks are independent (can run in parallel)
• Only the result matters, not the process
• No need for agents to communicate with each other
• Good for: batch PRD generation, parallel research, independent file edits
• Estimated cost: $1-8 per complex task

Agent team when:

• 5+ features with multiple distinct components
• Needs built-in QA/review (e.g., QA agent tests what Frontend agent builds)
• Cross-layer work (backend + frontend + tests)
• Quality matters more than speed
• Teammates need to share findings or challenge each other
• Estimated cost: $5-20 per session
• Requires: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 in settings

For teams, suggest composition based on task type:

| Task Type | Suggested Team | |-----------|---------------| | spec (PRDs + mockups) | Spec Writer + UX Designer + Reviewer | | build (full app) | Backend + Frontend + QA + Reviewer | | build (API only) | Backend + Tester | | build (UI only) | Frontend + QA (mobile + desktop) | | fix (complex bug) | Investigator A + Investigator B (competing hypotheses) |

2.2 Tooling Recommendations

This is where you add the most value. Don't just check what exists — actively suggest tools that would make the task better.

UI Mockups / Design

Task involves creating UI mockups or design specs?
├── Yes → Is Stitch MCP configured? (check mcp.json for "stitch")
│   ├── Yes → "Stitch MCP is ready. Agents will generate mockups directly
│   │          from descriptions instead of just writing Stitch prompts."
│   └── No → RECOMMEND: "I suggest installing Stitch MCP so agents can
│             generate actual UI mockups from Google Stitch, not just text prompts.
│             This turns a 'write prompts for Stitch' task into a
│             'generate mockups directly' task.
│             Want me to add it to ~/.claude/mcp.json?"
│
│             Installation:
│             Add to ~/.claude/mcp.json:
│             {
│               "stitch": {
│                 "command": "npx",
│                 "args": ["-y", "stitch-mcp"]
│               }
│             }
└── No → skip

UI Development / Testing

Task involves building or modifying UI?
├── Yes → Is Playwright MCP configured? (check mcp.json for "playwright")
│   ├── Yes → "Playwright MCP is ready for UI/UX testing.
│   │          Will test on mobile (375x667) and desktop (1280x720)."
│   │
│   │          Is playwright.config.* present in the project?
│   │          ├── Yes → "Playwright test config found. ✓"
│   │          └── No → RECOMMEND: "Create playwright.config.ts with
│   │                    mobile, desktop, and tablet viewport projects."
│   │
│   └── No → RECOMMEND: "Install Playwright MCP for browser-based UI testing.
│             Agents will be able to navigate, click, screenshot, and verify
│             layouts on mobile and desktop — catching visual bugs that
│             code-only testing misses.
│             Want me to add it to ~/.claude/mcp.json?"
│
│             Installation:
│             1. npm install -D @playwright/test
│             2. npx playwright install
│             3. Add to ~/.claude/mcp.json:
│             {
│               "playwright": {
│                 "command": "npx",
│                 "args": ["@playwright/mcp@latest"]
│               }
│             }
└── No → skip

External API Integration

Task involves calling external APIs? (Google APIs, Slack, payment providers, etc.)
├── Yes → RECOMMEND: "Create mock/simulated versions of external services
│          (digital twins) so agents can test without hitting real APIs,
│          rate limits, or production data.
│          Services to mock: [list detected from PRD/spec]"
└── No → skip

Research / Content Synthesis

Task involves research or content analysis?
├── Yes → Is NotebookLM skill available?
│   ├── Yes → "Can use /notebooklm to create a research notebook,
│   │          add sources, and synthesize findings before starting work."
│   └── No → skip
└── No → skip

Code Quality

Task touches an existing codebase?
├── Yes → Are pre-commit hooks configured? (check .husky/, .git/hooks/)
│   ├── Yes → "Pre-commit hooks found. ✓"
│   └── No → RECOMMEND: "Set up pre-commit hooks (husky + lint-staged)
│             for type checking and linting. This prevents agents from
│             committing broken code."
└── No (greenfield) → RECOMMEND: "Set up ESLint + Prettier + TypeScript
                        strict mode from the start. Agents work better
                        with strong guardrails."

LLM Observability / Tracing

Task involves LLM calls? (OpenAI SDK, OpenRouter, LangChain, direct API calls)
├── Yes → Is LangSmith configured? (check for LANGSMITH_API_KEY in .env or env vars)
│   ├── Yes → "LangSmith tracing is configured. ✓"
│   │
│   │          Is `wrapOpenAI` used? (check for langsmith/wrappers import)
│   │          ├── Yes → "Token + cost tracking via wrapOpenAI. ✓"
│   │          └── No → RECOMMEND: "Upgrade from @traceable to wrapOpenAI
│   │                    for automatic token counts (input/output/total)
│   │                    and cost estimates per call. @traceable alone
│   │                    captures inputs/outputs/latency but NOT tokens."
│   │
│   └── No → RECOMMEND: "Install LangSmith for LLM observability.
│             Captures token usage, cost estimates, latency, and
│             full input/output traces for every LLM call.
│             Want me to set it up?"
│
│             Setup:
│             1. Install: `npm install langsmith` (or `uv add langsmith`)
│             2. Add to .env:
│                LANGSMITH_TRACING=true
│                LANGSMITH_ENDPOINT=https://api.smith.langchain.com
│                LANGSMITH_API_KEY=
│                LANGSMITH_PROJECT=
│                LANGCHAIN_PROJECT=  # JS SDK reads THIS, not LANGSMITH_PROJECT
│
│             3. Wrap the OpenAI client (works with OpenRouter too):
│                import { wrapOpenAI } from 'langsmith/wrappers';
│                export const client = wrapOpenAI(new OpenAI({ ... }));
│
│             4. For accurate cost tracking, pass ls_model_name:
│                await client.chat.completions.create(
│                  { model, messages, ... },
│                  { langsmithExtra: { metadata: { ls_model_name: model.replace(/^[^/]+\//, '').replace(/\./g, '-') } } }
│                );
│
│             Key insight: wrapOpenAI emits LLM-flavored LangSmith runs
│             with token counts + cost. @traceable only gets latency + I/O.
│             When using OpenRouter, costs are directional (LangSmith's
│             built-in price table, not OpenRouter's margin); token counts
│             are always correct.
└── No → skip

Domain Skills

Are there project-specific skills available? (check .claude/skills/ in the project)
├── Yes → List them and recommend the most relevant one for the task.
│          Example: "Found /some-skill — will use it for [purpose]."
└── No → "No domain-specific skill detected. Will use generic approach."

2.3 Quality Gate Recommendations

Present which hooks should be configured:

| Hook | Type | Purpose | Recommended? | |------|------|---------|-------------| | Stop | agent | Verify tests pass before Claude stops | Always | | TaskCompleted | agent | Require Playwright evidence for UI tasks | When UI involved | | PostToolUse (Edit\|Write) | command | Auto-format with Prettier | When Prettier available | | Notification | command | Desktop alert when Claude needs attention | Always | | SessionStart (compact) | command | Re-inject critical context after compaction | Always |

2.4 Present Summary

Format your recommendation as:

## Launch Plan

**Task:** [one-line summary]
**Type:** [spec | build | fix | refactor | research]
**Approach:** [single session | sub-agents | agent team (N members)]

### Team (if applicable)
- [Role 1]: [responsibility] (tier: [cheap/mid/top] — [one-line reason])
- [Role 2]: [responsibility] (tier: …)
- ...

Tiers come from the **delegation routing rule** — the canonical table in `../references/model-tiers.md` §2–3 (relative to this skill's base directory; ships with the plugin — reference it; never copy it). Gates: default = inherit the session model when unsure; never downgrade the verifier, anything writing to `decisions.md`, or a packet locking an interface others consume; escalate on struggle rather than pre-paying — a lower-tier worker that fails its contract after one corrected re-dispatch, or thrashes, is re-run one tier up; log each tier choice, reason, and escalation to `.taskstate/run-memory.md`.

### Tooling Changes
- [ ] [Install/configure X — reason]
- [ ] [Install/configure Y — reason]
- [x] [Z already configured ✓]

### Environment Setup
- [ ] Create features.json (N features)
- [ ] Create progress.md
- [ ] Create init.sh
- [ ] Create eval scenarios
- [ ] Configure hooks
- [ ] Update CLAUDE.md

Approve this plan to proceed with setup.

(Unattended: replace the closing line with "Proceeding — plan logged to .taskstate/decisions.md.")

---

Phase 3 — SETUP

After user approves the plan, execute the setup. Do each step, report progress.

3.1 Create features.json

Parse the PRD/spec into granular features:

{
  "project": "[project name]",
  "created": "[date]",
  "total": N,
  "completed": 0,
  "features": [
    {
      "id": "F001",
      "name": "[feature name]",
      "group": "[backend | frontend | integration | config]",
      "status": "fail",
      "spec": "[one-line specification]",
      "depends_on": [],
      "test": "[how to verify this feature works]",
      "completed_at": null
    }
  ]
}

Rules:

• ALL features start as "status": "fail"
• Break into 10-50 features (too few = too vague, too many = overhead)
• Include dependency chains where they exist
• Group by logical area for team assignment
• Each feature must have a clear test criterion

Save to .taskstate/features-[version].json (per the state location rule).

3.2 Create progress.md

# Project Progress

## Status
- **Project:** [name]
- **Started:** [date]
- **Features file:** [absolute path to .taskstate/features-*.json]
- **Features:** 0 / [N] completed
- **Last session:** none
- **Current blocker:** none

## Session Log

Save to .taskstate/progress-[version].md (per the state location rule).

3.3 Create init.sh

Auto-detect the project and generate:

#!/bin/bash
set -e

echo "=== Se

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [DevOtts](https://github.com/DevOtts)
- **Source:** [DevOtts/build-it](https://github.com/DevOtts/build-it)
- **License:** MIT

Install and usage instructions live in the source repository linked above.