Run any Skill in Manus with one click

ticket-implementer

Stars1

Forks0

UpdatedJune 30, 2026 at 19:44

Start an Agent Smith ticket the right way — read the ticket, its dependencies, the PRD Decision Log, and the affected architecture/docs before editing. Use when picking up an AS-NNN ticket, deciding what to work on next, or before touching code for a backlog item. Triggers: "work on AS-", "start a ticket", "implement the ticket", "what should I work on next", "pick a ticket".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

tonitienda

tonitienda/agent-smith

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	ticket-implementer
description	Start an Agent Smith ticket the right way — read the ticket, its dependencies, the PRD Decision Log, and the affected architecture/docs before editing. Use when picking up an AS-NNN ticket, deciding what to work on next, or before touching code for a backlog item. Triggers: "work on AS-", "start a ticket", "implement the ticket", "what should I work on next", "pick a ticket".
license	MIT

Ticket implementer

Read before editing — context first, code second.

Before editing

The ticket: docs/project/tickets/AS-NNN-slug.md. Confirm status: ready-to-implement; honour its acceptance criteria and Open questions. Files are the source of truth over GitHub issues.
Dependencies: every depends_on ticket should be done (or at least designed). The index in docs/project/tickets/README.md and its "Suggested build order" define real ordering — the AS-NNN sequence is just stable identity. Prefer the ticket that unblocks the most or resolves the most uncertainty.
Product truth: the Decision Log docs/project/decisions.md — read D0–D9 first; it overrides the rest of PRD.md. Stay inside scope (D6: V1 = AS-001…AS-030); never pull deferred features in silently (D0).
Architecture: if the change touches runtime seams, data flow, storage, or provider/tool boundaries, read and plan to update the C4 docs under docs/architecture/ — contracts are guarded by internal/archtest. New code follows package-contracts.md.

While implementing

Run scripts/harness/quick.sh in the inner loop; see the quality-gate-runner skill.
Surface follow-on work as a new AS-NNN ticket (continue the sequence, file it, add it to the README index) — never as a silent TODO.
Keep docs current in the same change (README.md, CLAUDE.md, focused docs).

Before handoff

Run the full gate scripts/harness/full.sh (see ci-failure-triage if CI is red).
Set status: done in the ticket frontmatter and update the README index. Do not run ticket-sync or close the issue yourself — CI does that on merge.

Ticket file conventions (when adding/changing a ticket)

One file per ticket: docs/project/tickets/AS-NNN-slug.md, indexed in the README. Update the index table in the same change. Ticket IDs are stable — never renumber or reuse.
Frontmatter is machine-read by cmd/ticket-sync; keep id, title, status, optional type, github_issue, depends_on, area, priority intact. Never invent a github_issue value — the tool writes it back.
status ∈ ready-to-implement | needs-clarification | done. A needs-clarification ticket must carry an "Open questions" section. Use type: bug for defects.
Numbering: implementation tickets continue AS-NNN; QA/verification/manual-test follow-ups use the separate AS-Q-NNN sequence (fewer parallel-PR collisions). PRs that reuse an existing ID fail CI; if two parallel PRs still collide, the merge ticket-sync workflow renumbers and rewrites depends_on references.
Files are the source of truth over GitHub issues — land the file change and let CI sync/close the issue. go run ./cmd/ticket-sync -dry-run is fine to preview locally; never push issue-state changes from a session.
When a ticket is created/implemented/clarified/found-buggy during a smoke pass, update docs/projects/manual-test-campaign.md alongside the ticket file and README index.

More from this repository

same repository

pr-workflow

tonitienda/agent-smith

Agent Smith pull-request lifecycle — open a PR, subscribe to activity, reply to and resolve every review thread, handle the Gemini/Copilot review order, and auto-merge when clean. Use when work on a branch is committed and pushed, when a PR exists for the branch, or when handling review comments or CI on a PR. Triggers: "open a PR", "PR review", "review comment", "CI failed on the PR", "merge the PR", "is the PR ready".

2026-06-301

reflect-artifacts

tonitienda/agent-smith

Reflect phase — produce the three success artifacts (a measurable success metric, an instrumentation diff, a check-back ticket draft) without ever reading shipped-app runtime data.

2026-06-241

find-side-effects

tonitienda/agent-smith

Analyse phase — trace what else the change touches: callers, shared state, persisted formats, and cross-package contracts.

2026-06-211

grill-gaps

tonitienda/agent-smith

Analyse phase — interrogate the request for missing requirements, unstated assumptions, and unhandled cases before any code is written.

2026-06-211

plan-review

tonitienda/agent-smith

Plan phase — pressure-test the proposed plan: smallest viable change, ordering, and the test that will prove it.

2026-06-211

reflect-notes

tonitienda/agent-smith

Reflect phase — capture what was learned as durable, grounded notes: surprises, follow-on tickets, and method tweaks.

2026-06-211

name	ticket-implementer
description	Start an Agent Smith ticket the right way — read the ticket, its dependencies, the PRD Decision Log, and the affected architecture/docs before editing. Use when picking up an AS-NNN ticket, deciding what to work on next, or before touching code for a backlog item. Triggers: "work on AS-", "start a ticket", "implement the ticket", "what should I work on next", "pick a ticket".
license	MIT

Ticket implementer

Read before editing — context first, code second.

Before editing

The ticket: docs/project/tickets/AS-NNN-slug.md. Confirm status: ready-to-implement; honour its acceptance criteria and Open questions. Files are the source of truth over GitHub issues.
Dependencies: every depends_on ticket should be done (or at least designed). The index in docs/project/tickets/README.md and its "Suggested build order" define real ordering — the AS-NNN sequence is just stable identity. Prefer the ticket that unblocks the most or resolves the most uncertainty.
Product truth: the Decision Log docs/project/decisions.md — read D0–D9 first; it overrides the rest of PRD.md. Stay inside scope (D6: V1 = AS-001…AS-030); never pull deferred features in silently (D0).
Architecture: if the change touches runtime seams, data flow, storage, or provider/tool boundaries, read and plan to update the C4 docs under docs/architecture/ — contracts are guarded by internal/archtest. New code follows package-contracts.md.

While implementing

Run scripts/harness/quick.sh in the inner loop; see the quality-gate-runner skill.
Surface follow-on work as a new AS-NNN ticket (continue the sequence, file it, add it to the README index) — never as a silent TODO.
Keep docs current in the same change (README.md, CLAUDE.md, focused docs).

Before handoff

Run the full gate scripts/harness/full.sh (see ci-failure-triage if CI is red).
Set status: done in the ticket frontmatter and update the README index. Do not run ticket-sync or close the issue yourself — CI does that on merge.

Ticket file conventions (when adding/changing a ticket)

One file per ticket: docs/project/tickets/AS-NNN-slug.md, indexed in the README. Update the index table in the same change. Ticket IDs are stable — never renumber or reuse.
Frontmatter is machine-read by cmd/ticket-sync; keep id, title, status, optional type, github_issue, depends_on, area, priority intact. Never invent a github_issue value — the tool writes it back.
status ∈ ready-to-implement | needs-clarification | done. A needs-clarification ticket must carry an "Open questions" section. Use type: bug for defects.
Numbering: implementation tickets continue AS-NNN; QA/verification/manual-test follow-ups use the separate AS-Q-NNN sequence (fewer parallel-PR collisions). PRs that reuse an existing ID fail CI; if two parallel PRs still collide, the merge ticket-sync workflow renumbers and rewrites depends_on references.
Files are the source of truth over GitHub issues — land the file change and let CI sync/close the issue. go run ./cmd/ticket-sync -dry-run is fine to preview locally; never push issue-state changes from a session.
When a ticket is created/implemented/clarified/found-buggy during a smoke pass, update docs/projects/manual-test-campaign.md alongside the ticket file and README index.