# Launch

> Mission control for autonomous projects — analyzes tasks, recommends approaches (sub-agents/teams), sets up environment (features, evals, hooks, init.sh), suggests and configures tooling (MCPs), and launches the work.

- **Type:** Skill
- **Install:** `agentstack add skill-devotts-build-it-launch`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [DevOtts](https://agentstack.voostack.com/s/devotts)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [DevOtts](https://github.com/DevOtts)
- **Source:** https://github.com/DevOtts/build-it/tree/main/plugins/build-it/skills/launch

## Install

```sh
agentstack add skill-devotts-build-it-launch
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# /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:

```json
{
  "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

```markdown
# 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:

```bash
#!/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.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** yes
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-devotts-build-it-launch
- Seller: https://agentstack.voostack.com/s/devotts
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.
