Menu
Close GitHub issues with a structured comment (What was done, How to verify). Use after fixing a bug or completing a task linked to a GitHub issue.
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.
Based on SOC occupation classification
**Triathlon Agent Developer Guide**: Rules and context for developing the triathlon-agent bot. MANDATORY: use this skill for ANY work on project code. Triggers: code, bug, feature, refactor, test, migration, deploy, MCP tool, actor, ORM, API endpoint, webapp, React, Docker, PR, commit, branch, pipeline, CI, worker, scheduler, Dramatiq, Redis, Intervals.icu, alembic, FastAPI, poetry. Also triggers when MCP triathlon is connected and when discussing project architecture, performance, or infrastructure.
Disciplined workflow for moving a `docs/*_SPEC.md` forward — forces audit → phased plan → confirmation gate → implementation. Triggers when the user invokes `/spec`, `/spec <path>`, or `/spec <path> phase=<N>`. Use this instead of jumping straight into implementation when the user references a spec document. Without arguments: list all specs with phase-status snapshot (which phases done / pending / in-progress). With a spec path: audit existing implementation in code → present phase plan from the spec → identify the first incomplete phase → propose its scope as a punch-list → **STOP and ask user for explicit OK before writing any code**. Mandatory stop point: never start implementing before the user confirms. Even if the punch-list seems obvious. The forced gate is the whole point — `/spec` exists because plain "implement WEBHOOK_DATA_CAPTURE Phase 1" loses the audit step.
| name | github-workflow |
| description | Close GitHub issues with a structured comment (What was done, How to verify). Use after fixing a bug or completing a task linked to a GitHub issue. |
When working on a task that references a GitHub Issue:
Add a closing comment to the issue before closing it. This serves as release notes — other agents and the user should understand what changed without reading the full diff.
Use this template:
## Done
**What was done:**
Brief summary of changes — 2-4 sentences. Mention key decisions made during implementation.
**Files changed:**
- `path/to/file.py` — what changed
- `path/to/other.py` — what changed
**Deploy / run:**
- `docker compose up -d --build`
- `docker compose run --rm api python -m bot.cli <command>`
- `alembic upgrade head` (if migration added)
**How to verify:**
- "Open the Mini App → Activities → tap any swim activity → check SWOLF value"
- "Run MCP tool `get_efficiency_trend` with sport=bike, days=90 — should return weekly EF data"
- "Send /morning to the bot — recommendation should mention zone suggestions"
- "Check `GET /api/progress?sport=swim&days=90` — response should include swolf field"
**Related:**
- Links to updated docs/specs
- Follow-up issues if any
Not every section is needed. Bug fixes might skip "Deploy" if it's just a code change. But "What was done" and "How to verify" are always required.
gh issue close <number> --comment "$(cat <<'EOF'
## Done
...paste closing comment...
EOF
)" --repo radikkhaziev/triathlon-agent
Or add comment first, then close:
gh issue comment <number> --body "..." --repo radikkhaziev/triathlon-agent
gh issue close <number> --repo radikkhaziev/triathlon-agent