breakdownBreak an epic or a design document into owned, sequenced tasks: one deliverable each, an owner, a dependency order, the parallel lanes that avoid two people editing the same file, and a definition of done per task. Use before a sprint starts, when work has to be shared across several developers, or
catchupSummarise an epic or a pull request for someone not in the conversation that produced it: what the work is and for whom, why now, scope, what it touches and where in the code, who decides, unfamiliar terms, and where it is easy to go wrong. For an epic, also the understanding check the developer ans
conventionExtract, record, and enforce the coding conventions a team actually follows: branch and commit rules, naming, layering, error handling, test layout, review etiquette, and the tooling that enforces each rule. Also drafts the collaboration files the project lacks, `CONTRIBUTING.md`, the pull request t
design-docWrite the technical design document a team reviews before coding, plus its ADR: current state, options with trade-offs, chosen approach, data and API changes, migration, rollback, risks, open questions, and who signs off. Use before code that touches a schema, a public contract, a shared module, or
estimateEstimate how many points and how many hours a task, a feature, or a screen takes: size each item with a stated basis, mark the confidence, and add the risk buffer as a visible line, so the numbers can be argued with in planning. Use for story points, hour or man-day estimates, and re-estimation afte
fixFix a defect the way a team reviewer will accept: capture the failure verbatim, prove the cause before changing a line, check that the current behaviour is not a decision somebody made on purpose, make the smallest change that removes the cause, verify it by layer, stop after three ruled-out hypothe
gitCarry a finished piece of work into version control: read what changed, stage it after scanning for anything that must never be committed, split it into commits that can be reverted one at a time, branch and push on consent, open the pull request with the artifact as its body, and merge only when a
handoverHand work over to another person or team so nothing depends on the leaver's memory: the true state of each item, decisions and why they were made, the traps, the credentials and access to transfer, the contacts, and the questions only the leaver can answer, asked before they go. Use when a member le
helpAnswer which atk skill to run. With no argument it reads the state of the project, meaning the profile, the artifacts on disk and their approval state, the plans, and the branch, then names the next skill with the line to type, the evidence behind it, what the skill needs first, and who approves wha
implementWrite the code for a piece of work the way a team will accept it: decide whether the work needs a plan before a line is written, follow the project's own conventions and reference modules, verify by layer with the project's own commands, then call the team review and fix what it blocks on before han
incidentRun a production incident and close it properly: a timeline built from evidence, impact and severity, the proven root cause, the mitigation actually applied, a blameless postmortem, follow-up actions with owners and dates, and the runbook that makes the next occurrence shorter. Use during an outage,
initSet up atk in a project: read the repository to find the build, test, and lint commands, the layer layout, the tracker, and the docs root, confirm what was found, ask only for what no file can answer, and write the profile every other skill reads. Use once when a team first installs atk in a project
intakeTurn a raw stakeholder or client request into reviewable requirements: context, user stories, acceptance criteria, out-of-scope list, open questions, and the person who must answer each one. Use when a request arrives as a chat message, a meeting note, a mail, a one-line ticket, or a Figma design, a
onboardOnboard a new member onto a project team: the access list, the environment setup verified by a command that actually runs, a map of the codebase by ownership, the team's working agreements, and a first-week plan ending in a real contribution the team reviews. Use when someone joins the project, move
orchestrateCarry one or several pieces of team work through the atk lifecycle: read how far each has come, from a client's raw request to a ready plan, propose the atk skills each still needs as jobs with the agent, the way it runs, and the person who answers it, and after the team approves the proposal, run t
planTurn a piece of work into phases and steps: today's code with file paths, phases that each end in something reviewable, steps that leave the tree working and how each is checked, what is out of scope, and what is unclear with who must answer. Also reviews a written plan against the repository and th
qaPlan and write the team's testing: the project's master test plan, a plan per feature with scope and exit criteria, test cases traced to acceptance criteria, a regression matrix, and the handoff a developer owes QA. Afterwards, records a test run, raises its failures as bugs, and records a fixed bug
releaseRun a team release: assemble the change list from the diff, write release notes for the audience that reads them, produce the pre-flight and post-deploy checklist with an owner per step, state the rollback path, audit the licenses of the dependencies it ships against the project's own policy, and re
retroRun a sprint retrospective on evidence rather than memory, and write the status report that goes up: what the data says about the sprint, what the team says, the few actions worth taking with an owner each, and whether last retro's actions actually happened. Use at the end of a sprint, a milestone,
reviewReview a teammate's pull request the way a team reviewer should: against the requirement, the design, and the team conventions, with findings ranked by severity, each one citing a line and stating the failure it causes, and blocking issues separated from preferences. Use before approving a PR, when
run-casesExecute approved test cases against a deployed DEV or staging environment, through the browser or an app on an Android device: refuse production and the local stack, recon the accounts and data, triage every case as automatable, semi-automatable, manual, or blocked, naming who clears each obstacle,
securityReview the security of a change, a release, or a feature the way a team has to answer for it: the assets and trust boundaries in scope, the project's own scanners run, threats walked per boundary, every finding verified against the code with the path from entry point to impact, a checklist from the
specWrite and keep current the reference documents a team reads long after the work merged: the API contract per resource, the schema per table, the behaviour of a feature, and a screen's components as its Figma design draws them. Also reports where they drift from the code, and a screen from its design
tailorWrite down how this team wants a skill to behave, as a file in the project rather than an edit to the kit: read the shipped skill, ask what the team does differently and why, refuse the parts that would let a skill decide what a person owns, and write the override file with the person who approved i
verifyConfirm a change works by running the real thing: start the app the way the project starts it, exercise it with real requests or an app on an Android device, assert the side effect in the data rather than the status code, compare the screen against the design when asked, and stop after three rounds