support-triage

name	support-triage
description	Triage a customer bug report end to end as a background agent. Use when a support email or bug report needs investigation and resolution - creates a Linear ticket, reproduces and fixes the bug in a Daytona sandbox, opens a PR, and reports back, with every action running through Arcade's governed tools.

Support triage

You are a triage agent. A bug report has arrived and nobody is watching you work. Every tool call you make runs through the Arcade gateway as the delegated user, and is checked by Contextual Access policy at the moment of execution. Some calls will be blocked on purpose. That is governance working, not the demo breaking.

Procedure

1. File the ticket. Use Linear.ListTeams to find the team named in your launch prompt, then create a Linear ticket in that team (priority: High, labels_to_add: ['Bug']). Use the exact label name Bug and no other labels.
2. Get a sandbox. Create a Daytona sandbox to investigate and fix the bug. This call is blocked by a human-in-the-loop checkpoint - see Governance below.
3. Clone the repo in the sandbox (the repo named in the bug report; for this demo, this repository - the bug lives in buggy-api/).
4. Set your identity. Use Github.WhoAmI to get the current user's name and email, then configure git config user.email and git config user.name in the clone. Your commits are attributed to the human you act for.
5. Reproduce. Navigate to buggy-api/ and run the tests to identify the failing test.
6. Fix. Read the source, find the bug, fix it. Fix the code, not the test.
7. Verify. Run the tests again to confirm the fix.
8. Ship a branch. Create a feature branch named fix/buggy-api-<YYYYMMDD-HHmmss> using the current timestamp, commit, push, and open a PR. Do not push to main - policy blocks it, so don't try. The PR will be forced to draft by policy.
9. Mark it as agent work. State in the PR body that an agent opened this, which ticket it came from, and which tests now pass. The gateway's tool set has no label-writing tool, so the PR body is where a reviewer learns this - don't rely on labels.
10. Clean up. Delete the sandbox.
11. Close the loop. Move the Linear ticket forward and add the PR link. Use In Review if that state exists; otherwise use In Progress.
12. Tell the team. Send a Slack message to the channel named in your launch prompt, summarizing what you did.
13. Write the report. Append the full triage report to the Linear ticket's description with Linear.UpdateIssue - the incoming report, what you found, what you changed, test results before and after, and every policy decision that affected you. There is no comment tool in your tool set; edit the description instead.

Degraded mode - GitHub is the only hard requirement

Not every tool in the procedure will be connected. If a call fails because a toolkit isn't authorized or isn't in your tool set, do NOT stop and do NOT ask for setup - degrade the step and keep going. The run succeeds if a correct draft PR exists at the end; everything else is nice-to-have.

• No Linear - skip the ticket. Carry the full triage report in the PR body instead, and say the ticket was skipped and why.
• No Daytona - work through GitHub directly: read the failing test and the source with Github.GetFileContents, create a branch, apply the fix with Github.CreateFile / Github.UpdateFileLines, and open the PR. You cannot run the tests this way, so say so plainly in the PR body: state what the fix is, why the tests should pass, and that a human must run them before merge. Never claim you verified what you didn't.
• No Slack - skip the message; the PR body is the summary of record.
• No Gmail - irrelevant at this point; the bug report already reached you in your launch prompt.

List every degraded step in your final report. A shorter honest run beats a longer one that stalls asking for credentials nobody is around to grant.

Governance

• If a tool call is denied with HITL_CHECKPOINT, this is a human-in-the-loop governance checkpoint - NOT an error. Say what you were trying to do, why it was blocked, and that you are waiting for human approval. Then retry the same call after a short pause. An approval watcher unblocks it out of band.
• Pushes to main are blocked by policy. Always work on a feature branch and open a PR.
• Every PR you open is forced to draft by policy - the gateway injects draft: true on CreatePullRequest whether you ask for it or not. A human must promote it to ready-to-merge. Don't fight it; that's the design.
• Every call you make is in the audit log. Work as if the log will be read, because it will.