name	gh-issue
description	Fetch a GitHub issue, create a branch, plan and implement with TDD, then open a PR
user-invocable	true
argument-hint	<issue-number>
allowed-tools	Bash, Read, Edit, Write, Grep, Glob, Agent, WebFetch

GitHub Issue Workflow

Fetch a GitHub issue, create a branch, implement following TDD, and open a PR.

Arguments

$ARGUMENTS — Issue number (e.g., 42 or #42)

Instructions

Phase 1: Setup

Parse the issue number from $ARGUMENTS (strip # if present).

Fetch issue details:

gh issue view <number> --json title,body,labels,assignees,milestone,state

Assign yourself if unassigned:

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

Create a branch from main:

Determine prefix from labels:
- bug → fix/
- enhancement → feat/
- documentation → docs/
- Default → feat/
Branch name: <prefix><issue-number>-<slug> (slug: lowercase title, spaces → -, max 50 chars).
```
git checkout main && git pull
git checkout -b <branch-name>
```

Phase 2: Plan

Analyze the issue: requirements, labels, referenced issues, affected areas (which bashdep:: function or doc).
Explore the codebase for context:
- Find the relevant section in bashdep (single file)
- Find the closest related tests in tests/unit/bashdep_test.sh
- Read the corresponding entry in docs/api.md or docs/behavior.md
Create implementation plan:
- Acceptance Criteria
- Test Strategy (which tests to write first — pure-logic vs filesystem vs snapshot)
- Files to Change (bashdep, tests/unit/bashdep_test.sh, docs/*.md, CHANGELOG.md)
- Implementation Order (smallest first step)
Use EnterPlanMode if implementation is non-trivial.

Phase 3: Implement

Follow strict TDD workflow (see .claude/rules/tdd-workflow.md):

For each test:
- RED — Write failing test, verify it fails for the RIGHT reason
- GREEN — Minimal code in bashdep to pass
- REFACTOR — Improve while keeping tests green
Run the suite frequently:
```
make test
```
Quality checks after each refactor:
```
make sa && make lint
```
Mode coverage — if the change is mutating, add tests for BASHDEP_DRY_RUN, BASHDEP_SILENT, BASHDEP_VERBOSE, BASHDEP_FORCE as relevant.

Phase 4: Ship

Final verification:
```
make pre_commit/run
```
Commit using the /commit skill, with a body referencing the issue (e.g., Closes #<issue-number>).
Create PR using the /pr skill:
```
/pr #<issue-number>
```

Output Format

After fetching, present:

## Issue #<number>: <title>

**Labels:** <labels>
**State:** <state>
**Branch:** <branch-name>

### Description
<body content>

### Next Steps
1. Explore `bashdep` for the relevant function
2. Create implementation plan
3. Begin TDD cycle

GitHub Issue Workflow

Fetch a GitHub issue, create a branch, implement following TDD, and open a PR.

Arguments

$ARGUMENTS — Issue number (e.g., 42 or #42)

Instructions

Phase 1: Setup

Parse the issue number from $ARGUMENTS (strip # if present).

Fetch issue details:

gh issue view <number> --json title,body,labels,assignees,milestone,state

Assign yourself if unassigned:

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

Create a branch from main:

Determine prefix from labels:

bug → fix/
enhancement → feat/
documentation → docs/
Default → feat/

Branch name: <prefix><issue-number>-<slug> (slug: lowercase title, spaces → -, max 50 chars).

git checkout main && git pull
git checkout -b <branch-name>

Phase 2: Plan

Analyze the issue: requirements, labels, referenced issues, affected areas (which bashdep:: function or doc).

Explore the codebase for context:

Find the relevant section in bashdep (single file)
Find the closest related tests in tests/unit/bashdep_test.sh
Read the corresponding entry in docs/api.md or docs/behavior.md

Create implementation plan:

Acceptance Criteria
Test Strategy (which tests to write first — pure-logic vs filesystem vs snapshot)
Files to Change (bashdep, tests/unit/bashdep_test.sh, docs/*.md, CHANGELOG.md)
Implementation Order (smallest first step)

Use EnterPlanMode if implementation is non-trivial.

Phase 3: Implement

Follow strict TDD workflow (see .claude/rules/tdd-workflow.md):

For each test:

RED — Write failing test, verify it fails for the RIGHT reason
GREEN — Minimal code in bashdep to pass
REFACTOR — Improve while keeping tests green

Run the suite frequently:

make test

Quality checks after each refactor:

make sa && make lint

Mode coverage — if the change is mutating, add tests for BASHDEP_DRY_RUN, BASHDEP_SILENT, BASHDEP_VERBOSE, BASHDEP_FORCE as relevant.

Phase 4: Ship

Final verification:

make pre_commit/run

Commit using the /commit skill, with a body referencing the issue (e.g., Closes #<issue-number>).

Create PR using the /pr skill:

/pr #<issue-number>

Output Format

After fetching, present:

## Issue #<number>: <title> **Labels:** <labels> **State:** <state> **Branch:** <branch-name> ### Description <body content> ### Next Steps 1. Explore `bashdep` for the relevant function 2. Create implementation plan 3. Begin TDD cycle

gh-issue

GitHub Issue Workflow

Arguments

Instructions

Phase 1: Setup

Phase 2: Plan

Phase 3: Implement

Phase 4: Ship

Output Format

Mehr aus diesem Repository

GitHub Issue Workflow

Arguments

Instructions

Phase 1: Setup

Phase 2: Plan

Phase 3: Implement

Phase 4: Ship

Output Format

Mehr aus diesem Repository