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:

   # 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:

     ## 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