klaussy-rest-of-the-owl.\n\nAdapted for Cline.
\n\n
\n- This skill orchestrates parallel sub-agents using Claude's
\nAgenttool /subagent_typesyntax. Most coding agents now have their own parallel sub-agent or task mechanism (e.g. Cursor'sTask, Codex'sspawn_agent, Gemini subagents, Copilot'stask) — use yours and translate the wording. If it truly has none, apply each lens or angle yourself, sequentially, and combine the findings.- Where it references \"plan mode\" or
\nExitPlanMode, use your agent's own plan/approval mode if it has one; otherwise present your plan and wait for explicit approval before editing any files.
$ARGUMENTS
If $ARGUMENTS is empty, use the task definition the user pasted into the conversation (a ticket, a design note, a one-line ask). If there is none, stop and ask for one — this skill needs a target.
How to draw an owl: (1) draw two circles. (2) draw the rest of the owl. The user just handed you the two circles. This skill draws the rest: the whole lifecycle from \"here's what I want\" to \"here's a green, reviewed PR waiting for your merge\", including the enormous unglamorous middle the meme skips.
\nIt does everything except merge. The merge button stays with the human. Never merge, never force-push over someone else's work, never mark the PR ready-to-merge on the user's behalf.
\nYou are an orchestrator. Each phase below names the sibling skill that owns that work: open that skill's SKILL.md, follow it, come back here. This file holds the sequence and the gates between phases, not the steps — where a phase and its skill disagree, the skill wins on how and this file wins on when to stop.
Track the run with TodoWrite: one todo per phase, in_progress when you start it, completed when it's done. The flow is long and mostly unattended; the todo list is how the user follows along.
Close every phase in the chat. When a phase's gate is met, write one line saying so before you start the next: Phase 3 done: review clean, 2 findings fixed, suite green. The todo list alone doesn't reach a user reading the transcript or a run's final output, and a turn that ends on a tool call with no text looks like a hang.
Keep the main context lean. Everything you read stays in this conversation and is re-read on every later turn, so hand the read-heavy phases (review, self-review, QA) to a sub-agent when your agent has one. Give it the skill to follow, the base branch, and the exact shape of what to return, and tell it that shape replaces the skill's own output section and that it reports rather than stopping to ask; it returns a short summary and you act on that. Two exceptions run inline: an agent with no sub-agents, and a review of 150 or more reviewable lines, which takes review's parallel path (a sub-agent can't start sub-agents of its own).
\nThe sibling skills are written to run on their own, so several end by handing back to the user. Inside the owl that hand-back is the next phase, not the end of the turn. These override the skills:
\nExitPlanMode request and start at Phase 4, working plan.md top to bottom.REVIEW_OUTPUT.md.pr-description.md. Open the request yourself with the adapter's create command, passing that file as the body.Stop and hand back — don't barrel ahead — whenever a phase hits something a human must decide: a missing secret or env var, an ambiguous requirement, a destructive migration, or a test failure that looks like a real bug in existing code rather than in your change.
\nfastapi-grant-permissions so editing, tests, git and the forge CLI don't prompt all run.<base> everywhere, and say which you picked in the first progress update. A branch the task or user names wins, then the target of an existing request for this branch; otherwise resolve it:If the klaussy command isn't found, run it as python3 -m klaussy <command> (python -m klaussy on Windows, where python3 is usually absent) before falling back any further — the package is often installed with only its script directory off PATH. Use the fallback named for that step when that fails too, and say which one you used: a fallback answers a narrower question than the command it stands in for.
Resolve the base first, by running the command. Every range below is against <base>. Run klaussy base --explain before any range and reuse its answer; if the klaussy command isn't found, try python3 -m klaussy base --explain (python -m klaussy on Windows), then git symbolic-ref --short refs/remotes/origin/HEAD without its origin/ prefix, and master if that's empty too. Don't work the base out by eye. Picking the obvious branch gets the same answer most of the time and misses the case that matters: the command also reports branches HEAD may have been cut from, and a branch stacked on another one gets a range covering commits your change never added. If it names any, say so and ask which base to use rather than picking. Either way, state the base you used, and that you checked.
| # | \nFollow | \nGate before moving on | \n
|---|---|---|
| 1 | \nfastapi-plan (or fastapi-implement's lighter planning for a small, single-surface task) | \nAn approved plan.md. Ask now if the task leaves a real ambiguity; a wrong assumption costs the whole owl. Keep the plan and any breaking-change notes as session notes per fastapi-session-context. | \n
| 2 | \nfastapi-implement | \nThe plan's boxes are ticked and the suite is green. No scope creep beyond the task definition. | \n
| 3 | \nfastapi-review against git diff <base>...HEAD, then fastapi-self-review | \nEvery finding you agree with is fixed, the rest noted with a reason, suite re-run. Sub-agent returns the verdict line and one line per finding (severity, file:line, fix). | \n
| 4 | \nfastapi-qa | \nQA is genuinely clean. Let the skill right-size the evidence; don't hand-pick it. Sub-agent returns each check with pass/fail, the artifacts folder, and any asset URLs for the PR body. | \n
| 5 | \nfastapi-pr | \nThe request is open against <base>, its number and URL reported. Commit on a topic branch (never straight to <base>) and push first. Embed the QA evidence from Phase 4 in the body. | \n
| 6 | \nfastapi-review again, now that it's a real PR | \nFindings fixed, committed, pushed. A PR at rest reads differently: integration seams and the change as a whole surface here. | \n
| 7 | \nwaiting.md, then the adapter's CI commands | \nEvery check is green. | \n
| 8 | \nwaiting.md, then fastapi-address-review | \nEvery comment answered with a change or a reason. Pushing fixes re-triggers CI, so go back to 7 if anything goes red. | \n
| 9 | \n— | \nStop. Report and hand back. | \n
Phase 4 is a gate, not a formality. If QA shows the change is broken or ugly, go back to phase 2 or 3, fix it, and re-QA. Don't open a PR on a change QA has already failed and leave it for CI or the reviewer to catch.
\nPhase 7: fixing CI. Pull each failing check's logs with the adapter's log command and fix the real cause. A flaky check gets one re-run before you treat it as genuine. If a failure is in code your change didn't touch and can't have caused, stop and tell the user rather than guessing.
\nPhase 9: landing. Report the PR link, its check status, which review comments you addressed and how, the QA artifacts folder and anything still to attach by hand, and the one thing left: the user's merge. Mark all TodoWrite tasks complete. Say plainly if you stopped early and why. This report is the last thing in the run, so never end on a tool call: if you stop anywhere, for any reason, the report still gets written.
\norigin points at GitHub, so the gh CLI is the adapter. Confirm a flag with gh <command> --help before running one you haven't used in this repo; CLI interfaces drift between versions.
| Need | \nCommand | \n
|---|---|
| Read a ticket | \ngh issue view <n> --comments | \n
| Open a request | \ngh pr create --base <branch> --title <title> --body-file <file> | \n
| Request status | \ngh pr view <n> --json state,mergeable,reviewDecision,baseRefName | \n
| CI status | \ngh pr checks <n>, then gh run view <run-id> --log-failed on a failure | \n
| Retarget a request | \ngh pr edit <n> --base <branch> | \n
{owner}/{repo} are placeholders gh fills from the current repo, leave them literal.
xfail a test, loosen a lint rule, or --no-verify past a guard to make CI pass. A red check is information; fix the cause.Humanize anything a human will read. Before prose ships — a PR body, a review comment or reply, a commit message, a changelog entry, docs — run it through the fastapi-humanize skill and use what comes back. That skill holds the rules; don't keep a second copy of them here.
The scrubber is not that pass. klaussy humanize deletes a fixed list of mechanical tells (dashes, filler openers, a few hedges) and changes nothing else. It can't cut a paragraph that shouldn't exist, turn a noun phrase back into a verb, drop the closing principle, or make three sentences one, and that's most of what makes prose read as generated. Anything a human will read gets the fastapi-humanize skill: cut, voice, check, then scrub. Running the CLI, or klaussy humanize --check, is not that pass and doesn't stand in for it.
fastapi-plan, which forces the clarifying questions), then come back.