blueprint

Break a spec, brief, issue tracker item, or user request into agent-sized tasks, using phases and milestones only when they clarify larger work, delivered to exactly one destination.

Bootstrap a new or empty project repository with a local skeleton: README, license, .gitignore, AGENTS.md, docs, and optional commit or push only when explicit. Interview the repo creator when file-changing decisions are unclear.

Create a traceable Git branch for the current task.

Verify browser-rendered work in a real browser. Use for HTML, UI, visual docs, presentations, local apps, and browser-facing changes.

Stage intended changes and create one Conventional Commit.

Find and fix the root cause when something breaks: a failing test, a broken build, a bug report, or behavior that doesn't match expectations. Use when the user says 'debug', 'why is this failing', 'fix this bug', or when a failure interrupts other work.

Write a lightweight technical design document for ambiguous or consequential architecture decisions before implementation.

Write or tighten Codex and Claude Code /goal prompts with clear done conditions, required checks, evidence, and stop rules.

Turn one scoped task into a verified diff: code, tests, verification, report. The inner build step of the delivery flow. Use directly when the workspace is prepared and no PR is expected; use task-to-pr when a ticket should become a PR.

Run several tickets to draft PRs at the same time, one isolated worker per ticket. Use when the user passes multiple tickets and wants them worked in parallel. Composes task-to-pr per ticket; never writes code itself.

Commit, push, and open a pull request. Use when finished work on the current branch needs to become a PR.

Takes an open pull request with feedback to merge-ready by inspecting live PR state, classifying feedback, fixing only still-actionable findings, verifying checks, and reporting merge readiness. Never merges. Use when the user asks 'fix the PR', 'address review comments', 'merge?', 'is this ready?', or wants PR feedback resolved.

Improve the shape of existing code without changing behavior.

Review a code change for correctness, security, contracts, and tests.

Write an implementation spec to docs/<feature-slug>/spec.md and pause for human review. Use when the user says "write a spec" or "spec this out", or when implementation requirements, contracts, invariants, interfaces, or error behavior need review before coding. Use design-doc instead for architecture ambiguity, alternatives, or tradeoffs.

Turn one ticket into a draft PR. Use when the user passes a ticket reference (JIRA-123, LIN-123, github#456, an issue URL) and expects code, tests, review, verification, and a PR. Use implement when no PR is expected; use multitask for several tickets at once.

Test-first variant of implement: understand the desired behavior, write a failing test, make it pass, then simplify.