Axidify Issue tracking
Track work items using this project's chosen system (discover; do not assume):
- If
docs/issue-log.md(or similar) exists — follow its format and ID scheme - Else if the repo uses GitHub Issues — use
gh issue create/gh issue list - Else if another tracker is documented — follow that (Linear, Jira, etc.)
- Else — ask the user where issues should be recorded before filing
Before filing
- Search existing issues / log for duplicates
- Search the codebase; ground the entry in real paths
Operations
| User intent | Action |
|---|---|
| List open items | Search issue log or gh issue list (or project's tool) |
| New issue | Classify (bug / enhancement / feature); include repro, root cause, affected paths when known |
Fix ID |
Resolve and archive per project convention |
Close ID |
Close without fix (reason required) |
Update ID |
Amend an existing entry |
Use project severity / priority / labels when documented. Link to branch or PR if the project convention says so.
Project conventions
If present, respect project guidance in:
AGENTS.md,CLAUDE.md, orCONTRIBUTING.md.github/ai-instructions.mdor similar team docsdocs/plans/*.md— initiative Issues & fixes log (implementation findings); distinct from GitHub Issues /issue-log.md
Do not invent issue templates or labels that conflict with those files.
Related skills
- discover-project — find where this project records issues
- plan-driven-implementation — plan Issues & fixes log vs tracker issues (use both when fixing during a plan)
- debug — investigate before filing bugs
- implement — fix linked to an issue ID
- pr — reference
Fixes #Nwhen conventions allow