From ticket
Implement fixes for all tickets triaged as mechanically fixable. Delegates each fix to a subagent, runs project-declared verification, and marks tickets resolved. Does not commit — use /commit-session afterwards.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ticket:ticket-fixThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Implement fixes for open tickets that `/ticket-triage` has marked as mechanically fixable (no user decision needed). Each fix is delegated to a subagent to keep the main conversation context lean. This skill **does not commit** — after resolution, use `/commit-session` to commit the changes.
Implement fixes for open tickets that /ticket-triage has marked as mechanically fixable (no user decision needed). Each fix is delegated to a subagent to keep the main conversation context lean. This skill does not commit — after resolution, use /commit-session to commit the changes.
These skills must remain project-agnostic. When updating this SKILL.md, do not introduce hardcoded references to specific languages, frameworks, test runners, build tools, file paths, or directory layouts (e.g., go vet, npx playwright, pytest, doc/SPEC.md, e2e/tests/, server_test.go). Project-specific knowledge belongs in the host repo's CLAUDE.md and the host repo's <ticket-dir>/CLAUDE.md — this skill reads that configuration at runtime, it does not embed it. If a new instruction would only make sense in one tech stack, rewrite it as a principle (e.g., "run the verification commands declared in CLAUDE.md") before merging.
CLAUDE.md (if present) for:
Tickets: <path>). Default: doc/tickets/.Spec: doc/SPEC.md). Optional.## Verification or ## Testing heading. Optional.<ticket-dir>/CLAUDE.md for the ticket schema, lifecycle, and any declarations it adds (spec path, verification commands) that the root CLAUDE.md didn't set.If a spec path is not declared anywhere, the spec-update step is skipped later.
If verification commands are not declared anywhere, ask the user once what to run (e.g., "How should I verify changes — what commands run the test suite, linter, or type-checker?"). Remember the answer for the rest of this invocation.
List tickets in <ticket-dir>/ that meet ALL of:
status: open or status: in-progress.## Triage section.Mechanical fix: yes and Requires user decision: no.If $ARGUMENTS contains a ticket number, narrow the set to just that ticket (and check it meets the criteria above; if not, tell the user why and stop).
If open tickets exist but none have been triaged, tell the user to run /ticket-triage first and stop. Do not attempt to fix un-triaged tickets.
Sort candidates by priority (critical > high > medium > low), then by ticket number. Process in that order.
Context discipline: the parent (you) orchestrates only — reading tickets, dispatching subagents, verifying their output, and presenting the final summary. Do not read source code or perform fixes directly in the main conversation.
Parallelism: launch subagents in parallel when their tickets touch disjoint files. When two tickets touch the same files, run them sequentially so later subagents see the earlier fix.
Subagent prompt requirements (include every one of these, or the subagent cannot do its job):
CLAUDE.md (and any project-specific guides it references) before making changes, so the subagent follows project conventions.resolved/."After each subagent completes, verify its output: inspect git diff or read the changed files to confirm the fix matches the ticket and the verification truly passed. Only then move to the next subagent.
a. Mark in progress. Update the ticket file's status to in-progress and set updated to today's date.
b. Implement the fix. Make the minimal code changes the ticket requires. Follow the conventions in the host repo's CLAUDE.md. Do not refactor surrounding code or add unrelated improvements.
c. Add or update tests. This is required, not optional. Analyze every code path that was added or changed, and add tests that cover the new or modified behavior.
Principles (language- and framework-agnostic):
d. Verify. Run the verification commands declared for this project (Step 1). All of them must pass. If verification fails after reasonable attempts to fix, do not force the change — see step (f).
e. Update the spec (only if a spec path is declared AND the change is user-visible). User-visible changes include new/altered endpoints, new CLI flags, changed defaults, altered response formats, new configuration options. Internal refactors, test-only changes, and comment tweaks do not require spec updates. Skip this step entirely if no spec path is declared.
f. Resolve or bounce back.
status to resolved, update updated to today, fill in a ## Resolution section summarizing what changed (including tests added and spec updates), then move the file to <ticket-dir>/resolved/.## Triage section to set Mechanical fix: no and Requires user decision: yes with a note explaining why, keep status: open, and return a failure report to the parent.After all candidates are processed, show:
| Ticket | Title | What was done |
|---|---|---|
| #NNNN | ... | ... |
| Ticket | Title | Reason |
|---|---|---|
| #NNNN | ... | ... |
| Ticket | Title | Decision needed |
|---|---|---|
| #NNNN | ... | ... |
End with a pointer to run /commit-session (or the project's preferred commit flow) to commit the resolved fixes.
git commit, git add, or equivalent. It leaves the working tree dirty with resolved tickets moved and source/test edits staged in the filesystem, ready for the user (or /commit-session) to commit.Requires user decision: yes in triage must never be auto-fixed — list them under "Skipped" and move on.Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub hayamiz/hayamiz-agentkit --plugin ticket