sulthan/mangaBookmark
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

Skills: add plan-tickets, update implement-tickets and ticket-implementer

Browse Source
This commit is contained in:
Sulthan Zaki
2026-08-22 16:42:49 +07:00
parent 4aaf1d4f91
commit 1f3ede8d6a
3 changed files with 172 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.omp/agents/ticket-implementer.md
+16 -15
View File
@@ -24,34 +24,35 @@ Your branch is already checked out there. Never `git checkout`, `git switch`,
## Order of work
1. Read the brief file. It is the single source of requirements — use its exact
values verbatim.
2. Read the ticket and the issue it refers to, as the brief's **Read first**
section names them: `tea issue <n> --comments` for each. The ticket's
comments and its parent carry the intent and the decisions behind the brief.
Read no other ticket and no other brief.
3. Read `AGENTS.md` in the worktree, plus the nested `AGENTS.md` for the area
1. Read the brief file. It is the only statement of requirements you get — use
its exact values verbatim, and read nothing from the tracker. The
orchestrator has already read the ticket, its comments and its parent spec,
and folded every live decision into the brief; the threads themselves also
hold reversed and rejected ones you cannot tell apart from here.
2. Read `AGENTS.md` in the worktree, plus the nested `AGENTS.md` for the area
you touch. Its invariants bind you: security rules, design system, comment
policy.
4. Ask before writing code if requirements, acceptance criteria, approach, or
3. Ask before writing code if requirements, acceptance criteria, approach, or
dependencies are unclear. Asking is free; guessing is not.
5. Implement exactly what the brief specifies. At each TDD seam the brief names,
4. Implement exactly what the brief specifies. At each TDD seam the brief names,
run the `tdd` skill and follow its red → green loop.
Follow the patterns already in the codebase; improve what you touch,
restructure nothing outside the ticket.
6. Verify. Focused tests while iterating, the brief's full verification commands
5. Verify. Focused tests while iterating, the brief's full verification commands
once at the end. Test output must be pristine.
7. Commit to your branch. Reference the ticket number in the subject.
8. Review (below), fix, re-verify, commit the fixes.
9. Write the report file, then return the status contract.
6. Commit to your branch. Reference the ticket number in the subject.
7. Review (below), fix, re-verify, commit the fixes.
8. Write the report file, then return the status contract.
## Review
After your first green commit, run the **`code-review`** skill over
`<base ref>...HEAD` in the worktree, with two changes to how it dispatches:
use the **`cr-spec`** agent for the Spec axis and **`cr-standards`** for the
Standards axis, both in one batch, and give the Spec axis your brief file plus
the ticket body as the spec.
Standards axis, both in one batch, and hand the Spec axis your brief file as the
spec plus the ticket number from the brief's title, telling it to read the
ticket itself (`tea issue <n> --comments`). The tracker check belongs in that
read-only context, not in yours.
Fix every Critical and Important finding, then re-run the tests that cover the
amended code. Two fix rounds maximum: anything still open after that goes in the