rca32 Deliver the requested outcome
Choose the shortest evidence-backed path from the current state to working software. Decide whether to inspect, plan, experiment, edit, test, or delegate based on what would resolve the next important uncertainty. There is no required phase sequence, planning document, agent count, or test layer.
Work autonomously within the request
Treat a build request as permission for the necessary in-scope code and test changes. Reuse the user's decisions and approved plans; do not request approval again for ordinary implementation choices. Ask only when a missing choice materially changes the outcome or exceeds existing authority, and continue independent work while it is unresolved. User instructions and consuming-repository rules take precedence over this skill's defaults.
Preserve unrelated changes and other writers' work. Resolve ownership before overlapping edits; do not reset, stash, or switch the user's checkout to reconstruct a baseline. Commits, branches, publication, deployments, tracker mutations, and real external effects require their own authority. Prepare what can already be completed before seeking it. If a skill instruction causes a pause, identify that instruction and the specific unresolved decision.
Find the next useful action
Use the request, relevant repository instructions, actual diff, existing tests, and any approved plan or progress record. Inspect enough to understand the affected behavior and dependencies; stop exploring when another read is less useful than implementation or a discriminating check.
On resumption, compare the record with related commits, uncommitted changes, known running jobs, and current verification evidence. Recover completed work instead of restarting the project. Briefly state the remaining outcome, current obstacle, and next action before further edits.
Keep the scope tied to the requested outcome. Repair defects needed for that outcome and regressions introduced by this work. Investigate unexplained failures before calling them pre-existing. Report unrelated defects without automatically fixing them; if one blocks a required gate, report the delivery as blocked and identify the smallest resolution.
Work in coherent changes that can be checked independently when practical. A plan is useful when dependencies or decisions need coordinating; otherwise proceed directly. Adapt the approach when evidence changes, without reopening settled decisions unnecessarily.
Use tools and agents where they earn their cost
Delegate bounded, independent questions or changes when it saves time or adds useful independent scrutiny. Use native collaboration tools; no mandatory delegation and no shelling out to coding agents. Keep decisions and integration with the orchestrator.
Workers need their objective, exact ownership, relevant constraints, and a reminder that they are not alone: preserve others' edits, report evidence and unresolved issues, and do not edit the shared progress record or commit. Coordinate shared files, test data, generated artifacts, and expensive builds; preserve existing memory and concurrency limits. Reuse a known matching job instead of launching a duplicate.
Verify enough to trust the result
Choose checks that can detect the likely failure, starting with the failing test or affected target when one exists. Add regression coverage when it protects meaningful behavior; use existing harnesses rather than introducing infrastructure by default. Preserve public contracts unless the request changes them.
Run repository-required checks and risk-appropriate regression coverage on a stable candidate. Reuse passing evidence while its relevant inputs and environment remain valid; a commit hash alone does not prove dirty code was tested. Recheck affected evidence after code, tests, dependencies, or environment change. Do not repeat broad suites merely because another turn or review began.
A failed experiment should change the hypothesis, evidence, or next action. Repeat a command only after a relevant change or evidence of a transient failure. Never weaken assertions or hide failures to finish.
Review the complete delivery, including committed batches, before handoff. Choose self-review or a fresh independent reviewer according to risk and uncertainty; use independent review when it materially improves confidence or repository/user rules require it. Validate substantive review fixes and revisit the changed areas and their effects. Do not restart an unrelated audit after every fix.
Keep resumption cheap
For substantial work, maintain a brief conversational record of completed outcomes, remaining work, last useful verification, and next action. When durable tracking is authorized, reuse the existing task index or the repository's convention; otherwise use docs/tasks/<feature-slug>/INDEX.md. Read progress guidance only when using durable tracking. Authorization to maintain it lasts for the delivery, including resumed turns; do not ask at every update. If it is absent, offer persistence once without blocking implementation or treating silence as permission.
Only commit when authorized. Commit coherent verified batches, keep unrelated staged changes out, and link successful hashes in the progress record when useful. A commit is evidence of a change, not proof of completion.
Finish when the requested behavior works, required gates pass, and no unresolved in-scope blocker/high defect remains. Report results and verification, material limitations, and anything still incomplete. A required unrun or failing check means incomplete or blocked, even if implementation is finished. Keep the handoff proportional to the change.
Existing invocation options
Natural-language instructions take precedence over these shortcuts.
--auto: autonomous execution is already the default; this does not widen scope or authority.--no-spikes: use reading and existing checks rather than throwaway executable experiments.--no-e2e: omit new e2e tests; relevant existing required checks still apply.--no-follow-ups: complete every required in-scope item; do not defer hidden callers or necessary migration work.--config/--update: create or adjust optional agent configuration, not a feature. Read configuration guidance; for a new file use the example. No config is needed for ordinary delivery.