gh-issuelisted

<!-- Generated by agnostic-ai. Do not edit this file directly; edit specs under .agnostic-ai/ and run `agnostic-ai sync`. --> # GitHub Issue Workflow ## Context Read both the issue body **and every comment** as requirements input. Maintainer follow-ups frequently add scope, edge cases, or override the original description; when a later comment conflicts with the body, prefer the comment. !`gh issue view ${ARGUMENTS#\#} --json number,url,title,body,labels,assignees,state,comments 2>/dev/null || echo "Provide an issue number"` ## Instructions ### Phase 1: Setup 1. **Parse the issue number** from `$ARGUMENTS` (strip `#` if present). 2. **Assign yourself if unassigned**: ```bash gh issue edit <number> --add-assignee @me ``` 3. **Create a branch** from fresh `origin/main` based on the issue type: Determine the branch prefix from labels: - `bug` → `fix/` - `enhancement` → `feat/` - `documentation` → `docs/` - No label → `feat/` (default) Branch name format: `<prefix><issue-number>-<slug>` ```bash git checkout main && git pull --ff-only git checkout -b <branch-name> ``` ### Phase 2: Plan 4. **Enter Plan Mode** to design the implementation: - Explore the codebase to understand affected areas. - Identify files that need changes. - Respect adapter independence: `.claude/rules/no-cross-adapter-imports.md`. - Honor the adapter skeleton: `.claude/rules/adapter-pattern.md`. - Plan the TDD approach (what tests to write firs