berwinsingh/oldhand

Conducts non-trivial software work end to end through a chain of stage skills: reads the ticket or prompt, traces the real code path, reuses proven code, makes the smallest correct change, has sub-agents review and QA it in the running app, and lets a computed verdict, not the model, say when it is done. Use when the user asks to implement, build, fix, debug, root-cause, investigate, QA or verify a feature or bug; says "pick up this ticket", "work on ENG-123", "fix this bug", "why is X broken", "plan this first" or "make sure it works end to end"; or pastes a Jira, Linear, Asana, monday.com or GitHub issue, a spec, or a prompt with assumptions, constraints or acceptance criteria. Also use for plan-only requests on such work and for parallel QA or adversarial review of a change with sub-agents. Not for one-line edits, typo fixes, lookups or explaining code.

Implements a planned change the lazy, correct way: reuse what the codebase has, then the standard library, the platform and installed dependencies, and only then the least new code, fixing the whole class of bug at the shared point. Takes a baseline of the repo checks before the first edit, leaves one focused regression check, proves that check guards the fix with a mutation run (mutate.py), and compares the checks with the baseline. Records unit, integration and mutation results in the Oldhand ledger and writes build.md in the task's .oldhand folder. Use when the user says "implement the plan", "build the planned change" or "go ahead with the plan", or approves a plan from oldhand-plan. Not for planning, for investigating without a fix, for end-to-end QA (oldhand-qa), or for committing and pushing (oldhand-ship). One stage of oldhand; for a whole ticket or fix, use oldhand.

Turns a ticket, document or prompt into a work contract with numbered acceptance criteria (AC) and regression criteria (R), then opens the task's .oldhand folder and ledger that every later Oldhand stage reads. Reads the whole tracker item (description, every comment, attachments, linked work), keeps the user's assumptions, changed requirements, constraints, partial work and requested proof, and records which remote actions are authorized. Use when the user says "here is the spec", "scope this", "write the acceptance criteria" or "what exactly is being asked". Not for one-line edits, typo fixes, lookups or explaining code. One stage of oldhand; for a whole ticket or fix, use oldhand.

Captures the durable, non-obvious lessons from a task (diagnosis recipes, API and platform quirks, environment traps, failed experiments with their numbers, decisions and their why, rollback points, user corrections) into the project's existing agent instruction file or the host's memory system, each note dated with why and how to apply, and corrects or deletes notes the task proved wrong. Use when the user says "write down what we learned on this task", "save the lessons from this task", "capture this task's lessons for next time", or at the end of the oldhand chain. Not for documenting code structure, changelogs or git history, and never for storing secrets or customer data. One stage of oldhand; for a whole ticket or fix, use oldhand.

Plans the smallest complete code change before anything is edited: the fix point on the shared path, the files to touch and why, one regression check, scenarios for every acceptance and regression criterion (including negative, messy and the original failing case), blast radius and rollback, who does what at which model tier, and the budget for live or paid runs. Writes plan.md in the task's .oldhand folder and, in plan-only mode, stops there until the user approves. Use when the user says "how would you fix this", "what would you change" or "write the implementation plan", or after oldhand-trace, oldhand-rca or oldhand-research. Not for writing code, reviewing a diff, or a change small enough to make in one obvious edit. One stage of oldhand; for a whole ticket or fix, use oldhand.

Runs the QA panel for a change: turns the contract's acceptance and regression criteria into scenario cards (acceptance, the original failing case, neighbouring regressions, negative paths and messy real-world input), spawns one QA sub-agent per scenario to drive the real app through a browser, computer use, an API or a CLI, collects screenshots and response bodies as evidence, tallies pass, fail and blocked into the task ledger, and has the lead re-run the most important scenario itself. Use when the user says "QA this change", "run the QA scenarios", "make sure existing stuff still works", "try it with messy inputs", or after oldhand-review. Not for writing unit tests, reviewing a diff (oldhand-review) or deciding whether to ship (oldhand-ship). One stage of oldhand; for a whole ticket or fix, use oldhand.

Finds the evidence-backed root cause of a bug, incident or unexpected behaviour. Pins the symptom to a real failing case, confirms the account, deployed commit and config first, reads the failing run's own record, reproduces with the real stored input, clears or convicts each suspect with a cheap read-only probe, names the class of bug and every sibling site, defines a failed set and a regression set for replay, and spawns 2-3 read-only sub-agents to try to refute the chosen cause. Use when the user says "root-cause this", "find the root cause", "find out what went wrong", "why did this run fail", "this keeps failing", or hands over a batch of failed cases. Not for new features with no failure, or for a fix whose cause is already proven. One stage of oldhand; for a whole ticket or fix, use oldhand.

Checks for prior art before anything new is built or added: the codebase, the standard library, the platform, installed dependencies, then open source, stopping at the first rung that holds. Reads current official docs, probes external APIs and new model capabilities read-only, spikes a candidate dependency on real messy inputs, and runs a license gate (MIT and Apache-2.0 allowed, BSD and ISC ask first, copyleft or unknown rejected) with the reviewed commit recorded. Use when the user says "is there a library for this", "has someone solved this", "what should we use", "can we reuse something", "check the license", "does this API support X", or before adding a dependency or a new capability. Not for bug fixes inside existing code, or for one-line choices. One stage of oldhand; for a whole ticket or fix, use oldhand.

Reviews a code change with a board of read-only reviewer sub-agents, one lens each (contract, correctness, security and simplicity, plus data and AI behaviour when the change touches them). Each reviewer reads a stand-alone brief and writes a memo of file:line findings with failure scenarios; the chair tries to refute every finding before accepting it, records survivors in the Oldhand ledger, fixes high and medium findings, and lists lows as follow-ups. One review round and one fix round. Writes review.md and a review folder in the task's .oldhand folder. Use when the user says "review this", "review my diff", "review the PR", "find bugs in this change", "adversarial review", "get a second opinion on this code", or after oldhand-build. Not for style-only feedback, auditing a whole codebase, or explaining code. One stage of oldhand; for a whole ticket or fix, use oldhand.

Decides whether a change is done and delivers it: computes the verdict (VERIFIED, NOT YET, BLOCKED or INCOMPLETE) from the task ledger with ledger.py, never by hand, writes report.md with the evidence, what is not verified and every claim labelled observed, traced or assumed, then commits, pushes, opens a PR, updates the tracker or deploys only when the request authorizes it, and verifies each result by its URL or id. Use when the user says "ship the oldhand task", "is the oldhand task verified", "write the oldhand report", "open the PR for this task", or after oldhand-qa. Not for testing a change (oldhand-qa), reviewing it (oldhand-review) or publishing anything the user has not authorized. One stage of oldhand; for a whole ticket or fix, use oldhand.

Maps the real path a change or bug runs through, hop by hop from the entry point to the rendered result: file:line, what happens, timeout and retries, and failure mode for each hop; every caller, reader and sibling of the code that will change; which process runs each phase; the config the runtime really reads; and the trust boundaries. Can spawn read-only scout sub-agents, one per subsystem. Use when the user says "trace this", "where does this happen", "what calls this", "map the flow" or "what would this change break". Not for one-file edits with no callers, or for explaining a snippet. One stage of oldhand; for a whole ticket or fix, use oldhand.