home / skills / shotaiuchi / dotclaude / wf1-kickoff

wf1-kickoff skill

/dotclaude/skills/wf1-kickoff

This skill creates a new workspace and kickoff document or updates an existing one, guiding branch setup, kickoff creation, and state tracking.

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

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

Files (1)
SKILL.md
6.3 KB
---
name: wf1-kickoff
description: 新規ワークスペースとキックオフドキュメントを作成
argument-hint: "<github=N | jira=ID | local=ID> [title=...] [type=...] [--no-branch]"
context: fork
agent: general-purpose
---

**Always respond in Japanese.**

# /wf1-kickoff

Create a new workspace and Kickoff document, or update an existing one.

## Usage

```
/wf1-kickoff github=<number> [--no-branch]
/wf1-kickoff jira=<jira-id> [title="title"] [--no-branch]
/wf1-kickoff local=<id> title="title" [type=<TYPE>] [--no-branch]
/wf1-kickoff [update | revise "<instruction>" | chat]
```

## Arguments

### Source (mutually exclusive, for new workspace)

- `github`: GitHub Issue number
- `jira`: Jira ticket ID (e.g., `ABC-123`)
- `local`: Local ID (arbitrary string)
- `title`: Title (required for jira/local)
- `type`: FEAT/FIX/REFACTOR/CHORE/RFC (local only, default: FEAT)
- `--no-branch`: Skip branch creation, use current branch as work branch

### Subcommands (for existing workspace)

- `update`: Update existing Kickoff via dialogue
- `revise "<instruction>"`: Auto-revise based on instruction
- `chat`: Brainstorming dialogue mode

## Processing (New Workspace)

### Phase 1: Workspace Setup

1. **Check prerequisites**: `jq` required. `gh` required for github mode (check `gh auth status`).

2. **Generate work-id**:
   - github: Fetch issue via `gh issue view`. TYPE from labels (enhancement→FEAT, bug→FIX, etc.). Format: `<TYPE>-<issue>-<slug>`
   - jira: Format: `JIRA-<jira-id>-<slug>`
   - local: Format: `<TYPE>-<local-id>-<slug>`. Ask if user also wants to create GitHub Issue/Jira (can promote later with `/wf0-promote`).
   - slug: lowercase, alphanumeric+hyphens, max 40 chars

3. **Select base branch**: Priority: current branch (default) > `default_base_branch` from `.wf/config.json` > `main`. Confirm with user.

4. **Create work branch**:
   > **CRITICAL**: Working on main/master directly is forbidden. All work MUST happen on a feature branch.

   **If `--no-branch` is specified:**
   - Skip branch creation. Use the current branch as the work branch.
   - **Verify**: current branch MUST NOT be main/master. If it is, **ABORT** with error "Cannot use --no-branch on main/master".
   - Record the current branch name as `git.branch`.

   **Otherwise (default):**
   - `git checkout -b <prefix>/<issue>-<slug> <base_branch>`
   - **Verify immediately**: if still on main/master, **ABORT entire process**.

5. **Initialize WF directory**: Run `source "$HOME/.claude/scripts/wf-init.sh" && wf_init_project`

6. **Early branch recording** (CRITICAL: do NOT defer to Phase 3):
   - Verify again not on main/master
   - Write `git.base` and `git.branch` to state.json immediately

7. **Create document directory**: `mkdir -p docs/wf/<work-id>/`

### Phase 2: Kickoff Creation

8. **Get source information**: Fetch from GitHub/Jira/state.json based on source type.

9. **Plan Mode for local works**: If local and no existing `01_KICKOFF.md`:
   - Check for `.wf/<work-id>/plan.md` (temp working doc, not committed)
   - If absent, enter Plan Mode to explore requirements interactively
   - Save plan, then use as Kickoff input

10. **Brainstorming dialogue**: Discuss Goal, Success Criteria, Constraints, Non-goals, Dependencies with user.

11. **Create 01_KICKOFF.md**: Load template from `~/.claude/templates/01_KICKOFF.md`, fill with dialogue results.

### Phase 3: Finalization

12. **Update state.json**:
    > **GUARD**: Verify `git.branch` is NOT null/main/master before writing. ABORT if so.

    Set: `active_work`, `current: "wf1-kickoff"`, `next: "wf2-spec"`, source info, git info, `kickoff.revision: 1`, `created_at`.

13. **Commit**: `git add .wf/state.json docs/wf/<work-id>/` with message `docs(wf): create workspace and kickoff <work-id>`

14. **Completion message**: Show Work ID, Branch, Base, Docs path, next step (`/wf2-spec`).

## Subcommand Processing (Existing Workspace)

Get active work from state.json. Require `01_KICKOFF.md` exists.

- **update**: Dialogue → update `01_KICKOFF.md` → append to `06_REVISIONS.md` (template: `~/.claude/templates/06_REVISIONS.md`) → increment `kickoff.revision`
- **revise**: Auto-revise from instruction → confirm → update → append revision history (see Revise Processing below)
- **chat**: Free dialogue with Issue context. Can reflect in Notes section.
- **Commit**: `docs(wf): update kickoff <work-id>` with revision number.

### Revise Processing (Auto Mode Integration)

The `revise` subcommand supports automated revision based on PR/Issue feedback. This is used by `/wf0-remote auto` when processing `needs-revision` labeled issues.

#### Steps

1. **Load existing context**:
   - Read current `01_KICKOFF.md`
   - Read `state.json` for source info (issue number, PR number)

2. **Fetch feedback sources**:
   ```bash
   # Get PR reviews and comments
   gh pr view <pr_number> --json reviews,comments,body

   # Get Issue updates (compare with original)
   gh issue view <issue_number> --json body,comments
   ```

3. **Analyze feedback**:
   - Extract actionable items from PR review comments
   - Identify changes in Issue description since last revision
   - Summarize new Issue comments since last processing

4. **Generate revision plan**:
   - Create list of changes to incorporate
   - Confirm with user (unless running in auto mode)

5. **Update documents**:
   - Modify relevant sections in `01_KICKOFF.md`
   - Append revision entry to `06_REVISIONS.md`:
     ```markdown
     ## Revision N (YYYY-MM-DD)

     ### Trigger
     - PR review feedback / Issue update / Manual instruction

     ### Changes
     - [List of changes made]

     ### Feedback Incorporated
     - [Summary of feedback addressed]
     ```

6. **Update state.json**:
   - Increment `kickoff.revision`
   - Set `current: "wf1-kickoff"`
   - Set `next: "wf2-spec"`

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

## Worktree (Optional)

If `config.worktree.enabled` is true: `git worktree add .worktrees/<branch-name> <branch>`. Record in `.wf/local.json`.

## Error Handling

| Scenario | Behavior |
|----------|----------|
| Branch already exists | Error with existing branch name |
| GitHub Issue not found | Error with issue number |
| Title missing (jira/local) | Prompt for title |
| Multiple source types | Error listing conflicts |
| Still on main/master at Step 5+ | **ABORT immediately** |
| `--no-branch` on main/master | **ABORT** with error message |

Overview

This skill creates a new workspace and a Kickoff document or updates an existing kickoff for ongoing work. It orchestrates branch creation, workspace scaffolding, interactive planning dialogue, and produces a populated 01_KICKOFF.md and state tracking. It enforces safe branching rules and commits the kickoff into docs/wf/<work-id>/.

How this skill works

For a new workspace it accepts a GitHub issue number, Jira ID, or a local ID + title, generates a normalized work-id and slug, selects a safe base branch, and creates a feature branch (unless --no-branch is used). It runs project initialization, captures an interactive brainstorming session (goal, success criteria, constraints, dependencies), renders the kickoff from a template, updates state.json, and commits the results. Subcommands support update, automated revise from feedback, and chat-based brainstorming for existing workspaces.

When to use it

  • Starting work tied to a GitHub issue, Jira ticket, or local task that needs a formal kickoff
  • You need a consistent work-id, kickoff doc, and git feature branch created together
  • Preparing to promote a local task into tracked work later
  • When you want guided brainstorming to define goals, success criteria, non-goals, and dependencies
  • Automated revision after PR reviews or issue feedback

Best practices

  • Never work directly on main/master; always create a feature branch or use --no-branch only on a non-main branch
  • Provide a clear title for jira/local sources to ensure a good slug and work-id
  • Confirm base branch selection if your repo uses a non-standard default_base_branch in .wf/config.json
  • Run prerequisite checks (jq and gh) beforehand to avoid interruptions
  • Use the Plan Mode for local tasks to capture uncommitted planning notes before creating the kickoff

Example use cases

  • Create a kickoff from GitHub issue #42 to standardize scope and create a feature branch: /wf1-kickoff github=42
  • Kick off work for Jira ticket ABC-123 with a supplied title to produce docs/wf/JIRA-ABC-123-<slug>
  • Start a local feature with a custom type and title: /wf1-kickoff local=XYZ title="Add metrics export" type=FEAT
  • Revise an existing kickoff automatically from PR review feedback: /wf1-kickoff revise "address review points about success criteria"
  • Enter an interactive brainstorming session for an active workspace: /wf1-kickoff chat

FAQ

What happens if I run with --no-branch on main/master?

The process aborts with an error: you cannot use --no-branch on main/master. Switch to a non-main branch first.

How is the work-id generated for GitHub and Jira sources?

GitHub uses TYPE from issue labels and formats TYPE-<issue>-<slug>. Jira uses JIRA-<id>-<slug>. Slugs are lowercased, alphanumeric with hyphens, max 40 chars.

Can I revise a kickoff automatically from PR reviews?

Yes. The revise flow fetches PR reviews and issue comments, extracts actionable items, builds a revision plan, updates 01_KICKOFF.md, appends to 06_REVISIONS.md, increments kickoff.revision, and commits.