aayudha docs Built from de79988 (2026-10-26)

respond: handle a production incident

During an incident, a rushed command in production can make things worse. respond proposes one action from your team's ops catalog, runs it only after a person approves it, keeps the timeline, and closes the incident with its follow-up Bug.

Field Value
In plain words Helps handle an incident: proposes a fix from your runbook, runs it only after a person approves, and keeps the timeline.
Journey stage Keep it running
Accountable seat Production Engineer (Shesha)
Does the work Shesha, the Accountable seat's twin, in the build model lane, with the seat's paired human when it has one
Consulted AI Native Engineer (Nakul), DevOps & DevEx Tinkerer (Nala)
Informed Engineering Manager (Drona), Founder (Atri)
Layers it can touch L07 Operational data / state, L09 Platform / operations
Who reasons your agent's own model, inside the skill
Writes as a person's own GitHub identity
Where it runs the aayu command, a skill in your agent
The skill your agent reads skills/respond/SKILL.md

When to use it

Not sure what broke yet? Start with investigate.

Run it

respond writes under your own GitHub identity and is never offered to agents as an MCP tool, so you run it yourself, in your own terminal. The skill helps you pick the action:

Use the respond skill on incident issue 42: read the investigation note, tell me which catalog action to propose with which parameters, what verifies it, and what rolls it back.

Needs setup: respond runs only actions in your ops/actions.toml on the default branch. Write your catalog (ops/README.md has the schema), merge it through a reviewed pull request, and give each human-approved action a GitHub Environment with required reviewers.

aayu respond <incident>
Input Required What it does
<incident> yes Incident issue.
--action no Catalog action to propose.
--params no Action parameters as key=value pairs separated by commas.
--postmortem no Blameless postmortem (Markdown) to check against the incident, its timeline, and its investigation note, and post on the incident (replaced in place).
--close no Close the incident: file its linked Bug (carrying the investigation note's implicated code and durable fix) and the retro entry; a Sev0 or Sev1 incident needs its postmortem first.

With the example action from the schema: aayu respond 42 --action restart-api --params service=api,replicas=2.

What you get back

A timeline on the incident, with each finished run and who approved it. --postmortem checks and posts the postmortem. --close files the linked Bug, appends the retro entry to the ledger, and closes the incident; a Sev0 or Sev1 incident needs its postmortem first.

You should see awaiting a human reviewer's approval of environment … with the run's link, then the run and its approver in the timeline. A refusal exits 4 and names what is missing; see exit codes.

Gates

It checks these before it acts, and stops when one fails:

What only a person does

To approve, open the waiting aayudha-ops.yml run on GitHub and approve its environment as a required reviewer. A person also decides when the impact is over, after the recovery query from the note.

What's next