home / skills / shotaiuchi / dotclaude / ghwf1-kickoff

ghwf1-kickoff skill

/dotclaude/skills/ghwf1-kickoff

This skill creates a workspace from a GitHub issue, sets up a kickoff document, and opens a draft PR to streamline project kickoff.

npx playbooks add skill shotaiuchi/dotclaude --skill ghwf1-kickoff

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.5 KB
---
name: ghwf1-kickoff
description: GitHub Issue からワークスペースと Draft PR を作成
argument-hint: "<issue-number> [--no-branch]"
context: fork
agent: general-purpose
---

**Always respond in Japanese. Write all workflow documents (*.md) in Japanese.**

# /ghwf1-kickoff

GitHub Issue を取得し、ブランチ作成、キックオフドキュメント作成、Draft PR 作成を行う。

## Usage

```
/ghwf1-kickoff <issue-number> [--no-branch]
/ghwf1-kickoff update
/ghwf1-kickoff revise "<instruction>"
```

## Arguments

- `<issue-number>`: GitHub Issue 番号 (必須)
- `--no-branch`: 現在のブランチを使用 (main/master では不可)

## Subcommands

- `update`: 対話形式でキックオフ更新
- `revise "<instruction>"`: 指示に基づいて自動更新

## Processing (New)

### Phase 1: Workspace Setup

1. **Prerequisites**: `gh auth status` 確認

2. **Fetch Issue**:
   ```bash
   gh issue view <number> --json title,body,labels,author,comments
   ```
   - Include comments as additional context/requirements

3. **Generate work-id**:
   - Format: `<TYPE>-<issue>-<slug>`
   - TYPE: labels から判定 (enhancement→FEAT, bug→FIX, etc.)
   - slug: タイトルから生成 (lowercase, alphanumeric+hyphens, max 40 chars)

4. **Select base branch**:
   - Priority: `default_base_branch` from config > `main`

5. **Create work branch**:
   - `git checkout -b feat/<issue>-<slug> <base_branch>`
   - **GUARD**: main/master では ABORT

6. **Initialize WF directory**:
   ```bash
   source "$HOME/.claude/scripts/wf-init.sh" && wf_init_project
   mkdir -p docs/wf/<work-id>/
   ```

### Phase 2: Kickoff Document

7. **Brainstorming dialogue**:
   - Goal, Success Criteria, Constraints, Non-goals, Dependencies

8. **Create 01_KICKOFF.md**:
   - Template: `~/.claude/templates/01_KICKOFF.md`

### Phase 3: Git Operations

**Execute immediately without confirmation:**

9. **Commit**:
   ```bash
   git add .wf/ docs/wf/<work-id>/
   git commit -m "docs(wf): create workspace and kickoff <work-id>"
   ```

10. **Push**:
    ```bash
    git push -u origin <branch>
    ```

### Phase 4: Draft PR Creation (NEW)

11. **Create Draft PR**:
    ```bash
    gh pr create --draft \
      --title "WIP: <issue-title>" \
      --body "$(cat <<'EOF'
    Closes #<issue-number>

    ## Progress
    - [x] ghwf1-kickoff
    - [ ] ghwf2-spec
    - [ ] ghwf3-plan
    - [ ] ghwf4-review
    - [ ] ghwf5-implement
    - [ ] ghwf6-verify
    - [ ] ghwf7-pr (Ready for Review)

    ---
    🤖 Generated by ghwf
    EOF
    )"
    ```

12. **Get PR number**:
    ```bash
    PR_NUMBER=$(gh pr view --json number -q '.number')
    ```

### Phase 5: Label Update (NEW)

13. **Update Issue labels**:
    ```bash
    gh issue edit <issue-number> \
      --remove-label "ghwf:approve,ghwf:executing" \
      --add-label "ghwf:waiting,ghwf:step-1"
    ```

### Phase 6: State Update

14. **Update state.json**:
    ```json
    {
      "active_work": "<work-id>",
      "works": {
        "<work-id>": {
          "source": {
            "type": "github",
            "issue": <issue-number>,
            "pr": <pr-number>
          },
          "current": "ghwf1-kickoff",
          "next": "ghwf2-spec",
          "last_execution": "<ISO8601>",
          "git": {
            "base": "<base-branch>",
            "branch": "<work-branch>"
          },
          "kickoff": {
            "revision": 1
          }
        }
      }
    }
    ```

15. **Completion message**:
    - Work ID
    - Branch
    - PR URL
    - Next step: `/ghwf2-spec` or add `ghwf:approve` label

## Revise Processing

For `revise` subcommand (used by daemon for revision):

1. **Fetch feedback**:
   ```bash
   gh pr view <pr> --json reviews,comments
   gh issue view <issue> --json body,comments
   ```

2. **Filter bot comments**:
   - Exclude `github-actions[bot]`
   - Exclude comments starting with `🤖`

3. **Analyze changes**:
   - PR review comments
   - Issue body diff
   - New Issue comments since last execution

4. **Update 01_KICKOFF.md**

5. **Append to 06_REVISIONS.md**:
   ```markdown
   ## Revision N (YYYY-MM-DD)

   ### Trigger
   - <source of revision>

   ### Changes
   - <list of changes>
   ```

6. **Update state.json**:
   - Increment `kickoff.revision`
   - Set `current: "ghwf1-kickoff"`, `next: "ghwf2-spec"`

7. **Commit**: `docs(wf): revise kickoff <work-id> (revision N)`

## Error Handling

| Scenario | Behavior |
|----------|----------|
| Issue not found | Error with issue number |
| Branch exists | Error with branch name |
| On main/master | ABORT |
| gh not authenticated | Error with instructions |

Overview

This skill automates creating a workspace and draft PR from a GitHub Issue. It fetches issue context, generates a work-id and branch, initializes a kickoff document, commits and pushes the work, then opens a Draft PR and updates issue labels/state. It enforces guards like rejecting operations on main/master and requires gh authentication.

How this skill works

The skill retrieves the issue (title, body, labels, author, comments) and derives a work-id from labels and a slugified title. It selects a base branch, creates a feature branch, runs project workspace init, and populates docs/wf/<work-id>/ with a templated 01_KICKOFF.md created from brainstorming items. The workflow commits and pushes changes, creates a Draft PR that references the issue, captures the PR number, updates issue labels, and writes state.json reflecting the new active work. A revise command fetches feedback and updates kickoff and revisions accordingly.

When to use it

  • You want a reproducible kickoff workspace for a GitHub Issue.
  • You need an automated Draft PR that closes the issue and tracks workflow progress.
  • You want to standardize kickoff docs and work-id naming across tasks.
  • You need automated label and state tracking when starting work.

Best practices

  • Ensure gh is authenticated (gh auth status) before running the skill.
  • Do not run from main/master; use --no-branch only when already on a safe feature branch.
  • Keep issue comments and requirements up to date so kickoff captures correct context.
  • Use clear, concise issue titles to generate readable slugs (alphanumeric, hyphens).
  • Review generated 01_KICKOFF.md and update success criteria and constraints immediately.

Example use cases

  • Start work on an enhancement issue: create branch, kickoff doc, and Draft PR in one command.
  • Kick off a bug fix with a standardized work-id (FIX-123-fix-crash) and workflow docs directory.
  • Automate state and label transitions when a new task moves from approval to execution.
  • Run revise to apply reviewer comments and append changes to 06_REVISIONS.md.

FAQ

What happens if the branch already exists?

The skill aborts with an error describing the conflicting branch name; resolve or delete the branch before retrying.

Can I skip creating a new branch?

Yes. Use --no-branch to operate on the current branch, but avoid running from main/master—this is explicitly blocked.