pipeline-github-feature

Files (1)

• SKILL.md

SKILL.md (first lines)

## Pipeline: GitHub Feature Development (Claude LLMs)

```
specs.md / User Input
  │
  ├─ 1. requirements-engineer (Opus-tier)
  │     Read specs.md or user input → structured requirements
  │     → docs/context/specs/<id>-requirements.md
  │     → User validates requirements
  │
  ├─ 2. Create GitHub Issue
  │     Format requirements as feature request issue
  │     → gh issue create --title "..." --body "..."
  │     → Issue number becomes the tracking ID
  │
  ├─ 3. architect (Opus-tier)
  │     Read requirements → design solution
  │     → docs/context/specs/<id>-spec.md + <id>-todo.md
  │     → User approves plan
  │
  ├─ 4. tdd-developer (Sonnet-tier) — per step
  │     RED: write failing tests → commit
  │     GREEN: minimum code → commit
  │     REFACTOR: improve → commit
  │
  ├─ 5. qa (Opus-tier)
  │     Run affected unit + integration tests
  │     Report pass/fail with exact errors
  │
  ├─ 6. reviewer (Sonnet-tier) — per-step review
  │     Review code against requirements + conventions
  │     🔴 MUST FIX / 🟡 SHOULD FIX / 🟢 SUGGESTION
  │     → User triages: [F]ix / [T]ech debt / [I]gnore
  │     → Max 3 fix loops per step
  │
  ├─ 7. Create Pull Request (gh pr create)
  │     Push branch → create PR → link GitHub issue
  │     → "Closes #<issue-number>"
  │
  └─ 8. diff-reviewer (Opus-tier) — whole-PR diff review
        Review the created PR end-to-end against the issue's AC:
        quality, correctness, logic, conventions, security,
        landmines, best practices
        🔴 CRITICAL / 🟠 MAJOR / 🟡 MINOR / 🟢 NIT + verdict
        → Preview findings + confirm, then post inline comments
          on the diff (and conceptual threads) via gh
```

> **`reviewer` vs `diff-reviewer`:** `reviewer` is the interactive,
> per-step quality gate that runs *during* development (steps 4–6 repeat
> per todo step). `diff-reviewer` runs *once on the finished PR* — it reads
> the whole diff, ranks issues by severity, and posts them back onto the PR
> (after a preview/confirm gate). Step 8 is optional but recommended before
> requesting human review.

### Prerequisites
- GitHub repository with `gh` CLI configured
- Claude Code installed (agents run as Claude Code subagents)
- Optional: `specs.md` in repo root or provided path

### Usage

#### Step 1: Gather requirements

**From specs.md:**
```
Use requirements-engineer to analyze specs.md
```
The agent reads `specs.md` (or a specific path), extracts features,
and produces structured requirements.

**From user input:**
```
Use requirements-engineer: "We need user authentication with OAuth2,
supporting Google and GitHub providers, with role-based access control"
```

Review the generated `docs/context/specs/<id>-requirements.md`.
Validate acceptance criteria and assumptions.

#### Step 2: Create GitHub issue
```bash
gh issue create \
  --title "feat: <feature name>" \
  --body "$(cat docs/context/specs/<id>-requirements.md | head -n 100)" \
  --label "feature-request"
```
Or let the requirements-engineer format and create the issue directly:
```
Use requirements-engineer to create a GitHub issue from <id>-requirements.md
```

#### Step 3: Design the solution
```
Use architect to design the solution for <id>-requirements.md
```
Review the spec and todo. Approve before proceeding.

#### Step 4: Implement step by step
```
Use tdd-developer on Step 1 of <id>-todo.md
```

#### Step 5: Test after each step
```
Use qa to verify Step 1
```

#### Step 6: Review after each step
```
Use reviewer to review Step 1
```
Triage findings: [F]ix / [T]ech debt / [I]gnore.

#### Step 7: Create Pull Request
```
/pr
```
Or manually:

From igorilic/agentic-orchestration, MIT.

More from igorilic/agentic-orchestration