pr-workflow

$npx mdskill add Chorus-AIDLC/Chorus/pr-workflow

Automate end-to-end PR submission with branching, CI checks, and merging.

  • Handles local code changes through branch creation, commits, and merges.
  • Depends on git CLI for branching and GitHub for PR creation and CI.
  • Validates file changes and CI status before recommending merge actions.
  • Executes automated steps to fix failures and complete the pull request.

SKILL.md

.github/skills/pr-workflowView on GitHub ↗
---
name: pr-workflow
description: Complete workflow for submitting code changes — create branch, commit, open PR, check CI, fix failures, and merge.
license: AGPL-3.0
metadata:
  author: chorus
  version: "0.1.0"
  category: development
---

# PR Workflow

Complete workflow for taking local code changes through branch creation, PR, CI verification, failure fix, and merge.

## Prerequisites

- Code changes are already made and tested locally
- Remote `origin` is configured
- `gh` CLI is authenticated

## Steps

### 1. Pre-flight Check

```bash
git status
git diff --stat
git log --oneline -5
```

Verify before proceeding:
- Only intended files are modified
- No sensitive files (.env, credentials) staged
- No temp artifacts (screenshots, logs) left behind

### 2. Create Branch

Branch from current HEAD. Naming convention:

| Type | Prefix | Example |
|------|--------|---------|
| Bug fix | `fix/` | `fix/remove-legacy-textarea` |
| Feature | `feat/` | `feat/structured-ac-editor` |
| Refactor | `refactor/` | `refactor/service-layer` |
| Test | `test/` | `test/e2e-proposal-flow` |
| Docs | `docs/` | `docs/api-reference` |
| Chore | `chore/` | `chore/bump-deps` |

```bash
git checkout -b {prefix}{short-description}
```

### 3. Stage and Commit

Stage specific files only — never use `git add .` or `git add -A`:

```bash
git add path/to/file1 path/to/file2
```

**Note**: Next.js paths need shell escaping:
```bash
git add src/app/\(dashboard\)/projects/\[uuid\]/file.tsx
```

Commit with HEREDOC for clean multi-line messages:

```bash
git commit -m "$(cat <<'EOF'
{type}: {concise description of why, not what}

{Optional body explaining context or trade-offs}

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
EOF
)"
```

### 4. Push and Open PR

```bash
git push -u origin {branch-name}
```

```bash
gh pr create --title "{type}: {title under 70 chars}" --body "$(cat <<'EOF'
## Summary
- Change 1
- Change 2

## Changed files
| File | Change |
|------|--------|
| `path/file.ts` | What changed |

## Test plan
- [x] Automated test passed
- [ ] Manual verification needed

Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
```

### 5. Check CI

```bash
gh pr checks {pr-number}
```

- **All pass** — report to user, ready for merge
- **Any fail** — proceed to Step 6

### 6. Fix CI Failures

Get the failed logs:

```bash
gh pr checks {pr-number}                          # find failed run ID
gh run view {run-id} --log-failed 2>&1 | tail -80  # read failure details
```

Common failure types and fixes:

| Failure | Local repro | Fix |
|---------|------------|-----|
| Test assertion | `npx vitest run path/to/test.ts` | Update test expectations to match new behavior |
| Type error | `npx tsc --noEmit` | Fix types; check only your errors with `\| grep {keyword}` |
| Lint error | `pnpm lint` | Auto-fix or manual fix |
| Missing test update | `grep -r "changedField" src/**/__tests__/` | Update test fixtures/helpers using the old field |

After fixing:

```bash
git add {fixed-files}
git commit -m "$(cat <<'EOF'
fix: {what was fixed in tests/types}

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
EOF
)"
git push
```

Re-check CI — repeat until green:

```bash
gh pr checks {pr-number}
```

### 7. Merge

Only when user explicitly requests. Default to squash merge:

```bash
gh pr merge {pr-number} --squash --delete-branch
git checkout main && git pull
```

## Checklist

Before opening PR:
- [ ] `npx tsc --noEmit` passes (or no new errors)
- [ ] Related tests pass locally
- [ ] No screenshots, temp files, or debug logs in working tree
- [ ] Grep test files for any changed field/function names

Before merging:
- [ ] CI is green
- [ ] User has approved the merge

More from Chorus-AIDLC/Chorus

SkillDescription
blogWrite release blog posts for Chorus — problem-first narrative, bilingual (zh/en), following the project's editorial style.
brainstorm-chorusOptional divergent-then-convergent dialogue for fuzzy ideas. Invoked from the idea skill as a prelude to structured elaboration; produces one ElaborationRound of decision-point Q&A and returns control. Never writes files, never posts comments, never validates elaboration.
chorusChorus AI Agent collaboration platform — overview, tools, and workflow routing.
chorus-proposal-reviewerRead-only Chorus proposal reviewer. Fetches a proposal via MCP, audits PRD/task drafts against the originating Idea, and posts a structured VERDICT comment. Invoke by mounting this skill into a default sub-agent via spawn_agent(agent_type="default", items=[{ type: "skill", path: "chorus:chorus-proposal-reviewer", ... }, { type: "text", text: "Review proposal <uuid>. Max review rounds: 3." }]).
chorus-task-reviewerRead-only Chorus task reviewer. Fetches a task plus its acceptance criteria plus originating proposal documents via MCP, independently verifies the implementation, and posts a structured VERDICT comment. Invoke by mounting this skill into a default sub-agent via spawn_agent(agent_type="default", items=[{ type: "skill", path: "chorus:chorus-task-reviewer", ... }, { type: "text", text: "Review task <uuid>. Max review rounds: 3." }]).
developChorus Development workflow — claim tasks, report work, and submit for verification.
develop-chorusChorus Development workflow — claim tasks, report work, self-check acceptance criteria, and submit for verification.
ideaChorus Idea workflow — claim ideas, run elaboration, and prepare for proposal.
idea-chorusChorus Idea workflow — claim ideas, run elaboration rounds, and prepare for proposal creation.
openspec-apply-changeImplement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.