froggo-mission-control: Skill for Claude Code

Task Decomposition

Core principle: define constraints, not instructions

A well-written task tells an agent what done looks like, not how to get there.

The agent has full freedom in HOW to reach the completion condition. The completion condition is what gets enforced — not the implementation steps.

"Work until all tests pass" outperforms "do A, then B, then C"

This is the difference between a constraint and a checklist. Checklists can be completed without achieving the goal. Constraints cannot be faked.

---

Decomposition principles

1. Each task completable in < 4 hours
2. One agent per task — clear ownership
3. Each subtask has exactly one measurable completion condition
4. Dependencies identified upfront
5. The HOW is left to the agent — only specify WHAT and WHEN DONE

---

Task format

• Title: Verb + noun ("Implement dark mode toggle")
• Priority: P0 (critical) P1 (high) P2 (medium) P3 (low)
• Labels: feature, bug, docs, infra, research
• Assigned: Specific agent ID
• Description: Context + acceptance criteria (the constraints)

Acceptance criteria format

Write acceptance criteria as verifiable conditions, not steps:

✓ `npx tsc --noEmit` exits 0
✓ `npm run build` succeeds
✓ `npm test` passes (no regressions)
✓ The toggle persists across page reload
✓ Works in both light and dark system preference

NOT this:

- Add a toggle button to the header
- Connect to the theme store
- Save preference to localStorage

The first is a constraint. The second is a recipe. Agents follow recipes mechanically and stop when the list ends, even if the goal isn't met.

---

Subtask structure

Subtasks carve the work into independently verifiable slices. Each subtask gets:

• A clear scope (what part of the goal it owns)
• A single completion condition (the constraint the agent works toward)
• Freedom in approach (no step-by-step instructions unless absolutely required)

Example — good subtask decomposition