Github Issue Lifecycle
GitHub issue lifecycle tracker for swamp. Drives issues from open through triage, planning, implementation, PR linkage, and merge as versioned swamp data — with optional label sync and comment posting back to the issue.
No external dependencies beyond the gh CLI. Designed for solo developers
or small teams working on GitHub repos who want observable, queryable issue
lifecycle data without leaving the terminal.
State Machine
opened ──[start]──> triaging
triaging ──[triage]──> classified
classified ──[plan]──> planned
planned ──[iterate]──> planned (feedback loop)
planned ──[approve]──> approved
approved ──[implement]──> implementing
implementing ──[link_pr]──> pr_open
pr_open ──[pr_merged]──> done
pr_open ──[pr_failed]──> pr_failed
pr_failed ──[link_pr]──> pr_open (retry)
Any ──[close]──> closedUsage
swamp extension pull @webframp/github-issue-lifecycle
# Create a lifecycle tracker for a repo
swamp model create @webframp/github-issue-lifecycle tracker \
--global repo=webframp/swamp-extensions
# Start tracking an issue
swamp model method run tracker start --input issue_number=42
# Triage it
swamp model method run tracker triage \
--input issue_number=42 --input kind=bug --input priority=high
# Plan implementation
swamp model method run tracker plan \
--input issue_number=42 \
--input summary="Fix pagination bug" \
--input steps='["Read current code","Fix off-by-one","Add test"]'
# Approve and implement
swamp model method run tracker approve --input issue_number=42
swamp model method run tracker implement --input issue_number=42
# Link a PR
swamp model method run tracker link_pr \
--input issue_number=42 \
--input pr_url=https://github.com/webframp/swamp-extensions/pull/100
# Record merge
swamp model method run tracker pr_merged --input issue_number=42Prerequisites
ghCLI installed and authenticated (gh auth login)- swamp initialized in the repository (
swamp init)
2026.07.27.1
Fixed: The fmt task ran deno fmt --check, so deno task fmt verified
formatting instead of applying it and there was no way to format the extension
through its own task. fmt now formats and a new fmt:check verifies, matching
every other extension in the repository.
Fixed: deno fmt no longer inspects CLAUDE.md / AGENTS.md. Those files
are gitignored and never present in CI, but deno fmt does not read .gitignore,
so deno task fmt:check could fail locally on a file CI does not have.
Upgrade note: Tooling and formatting only. No model, method, schema, or behavior change — nothing to do on upgrade.
Global Arguments
| Argument | Type | Description |
|---|---|---|
| repo | string | GitHub repo in owner/name format (e.g., webframp/swamp-extensions) |
| postComments | boolean | Post lifecycle transition comments to the GitHub issue |
| syncLabels | boolean | Sync lifecycle phase as a GitHub label (lifecycle:<phase>) |
| Argument | Type | Description |
|---|---|---|
| issue_number | number | GitHub issue number |
| Argument | Type | Description |
|---|---|---|
| issue_number | number | |
| kind | enum | |
| priority? | enum | |
| component? | string | |
| notes? | string |
| Argument | Type | Description |
|---|---|---|
| issue_number | number | |
| summary | string | One-line summary of approach |
| steps | array | Implementation steps |
| risks? | array | |
| feedback? | string |
| Argument | Type | Description |
|---|---|---|
| issue_number | number | |
| summary | string | |
| steps | array | |
| risks? | array | |
| feedback | string | What changed and why |
| Argument | Type | Description |
|---|---|---|
| issue_number | number |
| Argument | Type | Description |
|---|---|---|
| issue_number | number | |
| branch? | string | Working branch name if known |
| Argument | Type | Description |
|---|---|---|
| issue_number | number | |
| pr_url | string | Full PR URL |
| branch? | string |
| Argument | Type | Description |
|---|---|---|
| issue_number | number |
| Argument | Type | Description |
|---|---|---|
| issue_number | number | |
| reason? | string |
| Argument | Type | Description |
|---|---|---|
| issue_number | number | |
| close_issue? | boolean | Close the GitHub issue (default: true) |
| Argument | Type | Description |
|---|---|---|
| issue_number | number | |
| reason? | string |
| Argument | Type | Description |
|---|---|---|
| issue_number | number |
Resources
Drives a GitHub issue through the full lifecycle: start → triage → plan → approve → implement. Each job calls the corresponding lifecycle model method sequentially, with the agent providing classification and plan content as inputs. This workflow handles the pre-PR phases. Once implementation starts, the pr-fix-loop skill takes over and calls link_pr / pr_merged / pr_failed as the PR progresses through CI. Designed to be called once per issue when you want the agent to drive the full triage-to
Cycle-time metrics, stuck issues, and retry counts from lifecycle data
2026.07.24.1
Added: Initial release of the GitHub issue lifecycle tracker.
- 12 methods covering the full issue lifecycle: start, triage, plan, iterate, approve, implement, link_pr, pr_merged, pr_failed, complete, close, status
- State machine with enforced valid transitions
- Optional lifecycle comment posting to the GitHub issue thread
- Optional
lifecycle:<phase>label sync on the issue - All state stored as versioned swamp resources (state, context, classification, plan, pullRequest) — queryable via CEL
- PR number auto-extraction from URL
- Idempotent link_pr (safe to re-link after retry)
- Configurable via globalArgs: repo, postComments, syncLabels
- Has README or module doc2/2earned
- README has a code example1/1earned
- README is substantive1/1earned
- Most symbols documented1/1earned
- No slow types (deprecated)1/1earned
- Dependencies pass trust audit2/2earned
- Has description1/1earned
- Platform support declared (or universal)2/2earned
- License declared1/1earned
- Verified public repository2/2earned