home / skills / shotaiuchi / dotclaude / 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-kickoffReview the files below or copy the command above to add this skill to your agents.
---
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 |
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>/.
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.
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.