Launch review
An operating system for Claude Code. Skills, hooks (MCR), and a lean-context framework for smarter AI coding sessions.
npx -y skills add justnau1020/claude-os --skill launch-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Structured debate -> plan -> execute pipeline for evaluating feature readiness. Runs 5-agent debate, creates action plan with review, then executes fixes.
SKILL.md
5.8 KB, as published. Nobody here has run it
Launch Review Pipeline
A structured, multi-phase agent pipeline that evaluates feature readiness through adversarial debate, creates a reviewed action plan, and executes fixes. Each phase runs as an isolated team to prevent context bloat.
Invocation
/launch-review [topic] [--scope "focus areas"] [--constraints "known constraints"]
Examples:
/launch-review "checkout experience" --scope "cart, payment, confirmation"/launch-review "v2 API launch" --constraints "backwards compatible, feature flag gated"
Phase 0: Constraints Gathering (No Team)
Before spawning any agents, the main agent MUST:
- Ask the user for known constraints:
- Legal restrictions (prohibited libraries, data sources, licenses)
- Business rules (budget limits, timeline, must-have vs nice-to-have)
- Scope boundaries (what's in/out of this review)
- Any prior decisions already made
- Check memory for relevant project constraints
- Compile a constraints block that gets injected into every agent's prompt
Format:
CONSTRAINTS (non-negotiable):
- [constraint 1]
- [constraint 2]
DO NOT propose solutions that violate these constraints.
This phase prevents the #1 failure mode: agents recommending something that's already been ruled out.
Phase 1: Debate Team
Create team: TeamCreate with name {topic}-debate
Agents (5):
| Agent | Role | Type |
|---|---|---|
arch-critic | Code auditor -- finds gaps, bugs, half-baked features | general-purpose |
comp-critic | Competitive benchmarker -- researches competitors, holds us to that bar | general-purpose |
code-defender | Argues launch readiness from actual code evidence | general-purpose |
industry-defender | Argues competitive positioning from market research | general-purpose |
moderator | Synthesizes all 4 reports, writes verdict | general-purpose |
Flow:
- Spawn all 5 agents. The 4 debaters run in parallel. Moderator is blocked by all 4.
- Each debater sends their report to
moderatorvia SendMessage. - Moderator writes the report to
docs/{TOPIC}_READINESS_REPORT.md. - Moderator sends summary to
team-lead.
Handoff artifact: docs/{TOPIC}_READINESS_REPORT.md
Team transition checklist:
- Report file exists on disk
- Moderator confirmed report is written
- Shutdown all agents
-
TeamDelete
Phase 2: Planning Team
Create team: TeamCreate with name {topic}-planning
Agents (2):
| Agent | Role | Type |
|---|---|---|
planner | Reads report, creates action plan with team structure | general-purpose |
reviewer | Audits plan against code, verifies file references, checks for gaps | general-purpose |
Flow:
- Spawn
plannerfirst. It reads the report from disk, createsdocs/{TOPIC}_ACTION_PLAN.md. - Once planner delivers, shut it down and spawn
reviewer. - Reviewer reads the plan, verifies against actual code, appends review section.
- Reviewer sends summary to
team-lead.
The plan MUST include:
- All issues from the report, prioritized
- Specific files/lines affected
- Agent team structure for execution (using TeamCreate, NOT standalone subagents)
- Phasing and dependencies
- Acceptance criteria per task
Handoff artifact: docs/{TOPIC}_ACTION_PLAN.md (with review section)
Team transition checklist:
- Plan file exists on disk with review section
- Reviewer confirmed approval (with or without changes)
- Shutdown all agents
-
TeamDelete
Phase 3: Execution Team
Create team: TeamCreate with name {topic}-execution
Agents: Per the plan's team structure. Typically:
- One engineer per workstream (worktree isolation)
- Each reads the action plan from disk
Critical rules:
Agents MUST commit their work
Every code-writing agent must git add + git commit in their worktree before reporting done. Uncommitted worktree changes are lost on cleanup.
Merge before delete
Before TeamDelete, a merge agent MUST:
- List all worktrees with
git worktree list - For each agent worktree:
- Verify changes are committed
- Merge the worktree branch into main
- Remove the worktree
- Run
git worktree prune - Delete merged branches
- Confirm
git statusis clean
NEVER call TeamDelete while worktrees contain unmerged work.
Failure recovery
If an agent fails or auth drops:
- Check if worktree has uncommitted changes before re-running
- If changes exist, commit them first
- Respawn the agent pointing at the same worktree branch
Handoff artifact: Clean main branch with all fixes merged.
Phase 4: Backlog (No Team)
Main agent writes docs/{TOPIC}_BACKLOG.md capturing:
- What was completed
- What remains (with priority)
- Action items requiring human intervention
- Known constraints for future sessions
Anti-Patterns (Learned the Hard Way)
- Never TeamDelete before merging worktrees. This destroyed completed work in the first run of this pipeline.
- Never skip Phase 0. Three layers of agents all recommended a legally prohibited library because no one told them the constraint.
- Decision agents must wait for all inputs. The manager made a call before receiving the legal report. Use
addBlockedByon tasks to enforce sequencing. - Don't create teams you don't need yet. One-team-at-a-time constraint means premature creation forces premature deletion.
- Debaters and planners don't need worktrees. They write docs, not code. Only execution agents need worktree isolation.
- Keep the main agent's context lean. It delegates, routes, and summarizes. It does not read files, grep code, or write implementations.