agnostic-ai-gh-issue

GitHub Issue Workflow

Context

Read both the issue body and every comment as requirements input. Maintainer follow-ups often add scope or edge cases, or override the original description; when a later comment conflicts with the body, prefer the comment.

::target claude !gh issue view ${ARGUMENTS#\#} --json number,url,title,body,labels,assignees,state,comments 2>/dev/null || echo "Provide an issue number" ::end

Read the issue first: gh issue view <number> --json number,url,title,body,labels,assignees,state,comments.

Instructions

Phase 1: Setup

1. Parse the issue number from the text passed after the skill name (strip # if present).

2. Assign yourself if unassigned:

   gh issue edit <number> --add-assignee @me
   

3. Create a branch from fresh origin/main based on the issue type:

   Check that the worktree is clean. Fetch origin/main, stop if local main has unpublished commits, then fast-forward it. Never discard local work.

   Determine the branch prefix from labels:

   • bug → fix/
   • enhancement → feat/
   • documentation → docs/
   • No label → feat/ (default)

   Branch name format: <prefix><issue-number>-<slug>

   test -z "$(git status --porcelain)" || exit 1
   git fetch origin main
   git switch main
   test "$(git rev-list --count origin/main..main)" -eq 0 || exit 1
   git pull --ff-only
   git switch -c <branch-name>
   

Phase 2: Design

1. Design the implementation before editing:

   • Explore the codebase to understand affected areas.
   • Identify files that need changes.
   • Respect adapter independence: .agnostic-ai/rules/no-cross-adapter-imports.md.
   • Honor the adapter skeleton: .agnostic-ai/rules/adapter-pattern.md.
   • Plan the TDD approach (what tests to write first).

2. Keep a short implementation plan with:

   • Summary of what the issue requires.
   • List of files to create/modify.
   • Test strategy (unit per package, integration under tests/integration).
   • Step-by-step implementation order.