kata-new-project

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<objective>
Initialize a new project with deep context gathering and workflow configuration.
This is the most leveraged moment in any project. Deep questioning here means better plans, better execution, better outcomes.
Creates:
  • .planning/PROJECT.md
    — project context
  • .planning/config.json
    — workflow preferences
After this command: Run
/kata-add-milestone
to define your first milestone.
</objective>
<execution_context>
@./references/questioning.md @./references/ui-brand.md @./references/project-template.md
</execution_context>
<process>
<objective>
通过深度收集上下文信息和配置工作流来初始化新项目。
这是任何项目中价值最高的时刻。在此阶段进行深入提问意味着更完善的计划、更顺畅的执行和更理想的结果。
创建的文件:
  • .planning/PROJECT.md
    — 项目上下文文档
  • .planning/config.json
    — 工作流偏好配置文件
执行此命令后: 运行
/kata-add-milestone
来定义你的第一个里程碑。
</objective>
<execution_context>
@./references/questioning.md @./references/ui-brand.md @./references/project-template.md
</execution_context>
<process>

Phase 1: Setup

阶段1:准备工作

MANDATORY FIRST STEP — Execute these checks before ANY user interaction:
  1. Abort if project exists:
    bash
    [ -f .planning/PROJECT.md ] && echo "ERROR: Project already initialized. Use /kata-track-progress" && exit 1
  2. Initialize git repo in THIS directory (required even if inside a parent repo):
    bash
    if [ -d .git ] || [ -f .git ]; then
        echo "Git repo exists in current directory"
    else
        git init
        echo "Initialized new git repo"
    fi
  3. Detect existing code (brownfield detection):
    bash
    CODE_FILES=$(find . -name "*.ts" -o -name "*.js" -o -name "*.py" -o -name "*.go" -o -name "*.rs" -o -name "*.swift" -o -name "*.java" 2>/dev/null | grep -v node_modules | grep -v .git | head -20)
    HAS_PACKAGE=$([ -f package.json ] || [ -f requirements.txt ] || [ -f Cargo.toml ] || [ -f go.mod ] || [ -f Package.swift ] && echo "yes")
    HAS_CODEBASE_MAP=$([ -d .planning/codebase ] && echo "yes")
    You MUST run all bash commands above using the Bash tool before proceeding.
必须首先执行的步骤 — 在与用户进行任何交互前完成以下检查:
  1. 若项目已存在则终止:
    bash
    [ -f .planning/PROJECT.md ] && echo "ERROR: Project already initialized. Use /kata-track-progress" && exit 1
  2. 在此目录中初始化git仓库(即使在父仓库内也需要执行此操作):
    bash
    if [ -d .git ] || [ -f .git ]; then
        echo "Git repo exists in current directory"
    else
        git init
        echo "Initialized new git repo"
    fi
  3. 检测现有代码(遗留项目检测):
    bash
    CODE_FILES=$(find . -name "*.ts" -o -name "*.js" -o -name "*.py" -o -name "*.go" -o -name "*.rs" -o -name "*.swift" -o -name "*.java" 2>/dev/null | grep -v node_modules | grep -v .git | head -20)
    HAS_PACKAGE=$([ -f package.json ] || [ -f requirements.txt ] || [ -f Cargo.toml ] || [ -f go.mod ] || [ -f Package.swift ] && echo "yes")
    HAS_CODEBASE_MAP=$([ -d .planning/codebase ] && echo "yes")
    在继续操作前,必须使用Bash工具运行上述所有bash命令。

Phase 2: Brownfield Offer

阶段2:遗留项目处理提议

If existing code detected and .planning/codebase/ doesn't exist:
Check the results from setup step:
  • If
    CODE_FILES
    is non-empty OR
    HAS_PACKAGE
    is "yes"
  • AND
    HAS_CODEBASE_MAP
    is NOT "yes"
Use AskUserQuestion:
  • header: "Existing Code"
  • question: "I detected existing code in this directory. Would you like to map the codebase first?"
  • options:
    • "Map codebase first" — Run /kata-map-codebase to understand existing architecture (Recommended)
    • "Skip mapping" — Proceed with project initialization
If "Map codebase first":
Run `/kata-map-codebase` first, then return to `/kata-new-project`
Exit command.
If "Skip mapping": Continue to Phase 3.
If no existing code detected OR codebase already mapped: Continue to Phase 3.
若检测到现有代码且.planning/codebase/目录不存在:
查看准备步骤的结果:
  • CODE_FILES
    非空 或
    HAS_PACKAGE
    为"yes"
  • HAS_CODEBASE_MAP
    不为"yes"
使用AskUserQuestion工具:
  • 标题: "现有代码"
  • 问题: "我在此目录中检测到现有代码。是否要先映射代码库?"
  • 选项:
    • "先映射代码库" — 运行
      /kata-map-codebase
      来了解现有架构(推荐)
    • "跳过映射" — 继续进行项目初始化
若选择“先映射代码库”:
先运行`/kata-map-codebase`,再返回`/kata-new-project`
终止当前命令。
若选择“跳过映射”: 继续进入阶段3。
若未检测到现有代码 或 代码库已完成映射: 继续进入阶段3。

Phase 3: Deep Questioning

阶段3:深度提问

Display stage banner:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► QUESTIONING ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Open the conversation:
Ask inline (freeform, NOT AskUserQuestion):
"What do you want to build?"
Wait for their response. This gives you the context needed to ask intelligent follow-up questions.
Follow the thread:
Based on what they said, ask follow-up questions that dig into their response. Use AskUserQuestion with options that probe what they mentioned — interpretations, clarifications, concrete examples.
Keep following threads. Each answer opens new threads to explore. Ask about:
  • What excited them
  • What problem sparked this
  • What they mean by vague terms
  • What it would actually look like
  • What's already decided
Consult
questioning.md
for techniques:
  • Challenge vagueness
  • Make abstract concrete
  • Surface assumptions
  • Find edges
  • Reveal motivation
Check context (background, not out loud):
As you go, mentally check the context checklist from
questioning.md
. If gaps remain, weave questions naturally. Don't suddenly switch to checklist mode.
Decision gate:
When you could write a clear PROJECT.md, use AskUserQuestion:
  • header: "Ready?"
  • question: "I think I understand what you're after. Ready to create PROJECT.md?"
  • options:
    • "Create PROJECT.md" — Let's move forward
    • "Keep exploring" — I want to share more / ask me more
If "Keep exploring" — ask what they want to add, or identify gaps and probe naturally.
Loop until "Create PROJECT.md" selected.
显示阶段横幅:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► 提问环节 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
开启对话:
以自由格式提问(不使用AskUserQuestion工具):
“你想要构建什么?”
等待用户回复。这将为你提供上下文信息,以便提出更有针对性的后续问题。
跟进对话:
根据用户的回复,提出能深入挖掘信息的后续问题。使用AskUserQuestion工具并提供选项,探索用户提到的内容——包括解读、澄清、具体示例等。
持续跟进对话。每个回答都会引出新的探索方向。可以询问以下内容:
  • 最让他们兴奋的点是什么
  • 是什么问题促使他们启动这个项目
  • 他们提到的模糊术语具体指什么
  • 最终成品实际会是什么样子
  • 哪些内容已经确定
参考
questioning.md
中的技巧:
  • 挑战模糊表述
  • 将抽象概念具体化
  • 挖掘潜在假设
  • 探索边界情况
  • 揭示动机
检查上下文(仅在后台进行,不对外展示):
在提问过程中,对照
questioning.md
中的上下文清单进行检查。若存在信息缺口,自然地融入问题中,不要突然切换到清单式提问模式。
决策节点:
当你能够撰写清晰的PROJECT.md时,使用AskUserQuestion工具:
  • 标题: "是否准备就绪?"
  • 问题: "我认为我已经了解你的需求。是否准备创建PROJECT.md?"
  • 选项:
    • "创建PROJECT.md" — 继续推进
    • "继续探索" — 我想分享更多内容/请继续提问
若选择“继续探索” — 询问用户想要补充的内容,或找出信息缺口并自然地进行挖掘。
循环此过程,直到用户选择“创建PROJECT.md”。

Phase 4: Write PROJECT.md

阶段4:撰写PROJECT.md

First, create all project directories in a single command:
bash
mkdir -p .planning/phases/pending .planning/phases/active .planning/phases/completed
touch .planning/phases/pending/.gitkeep .planning/phases/active/.gitkeep .planning/phases/completed/.gitkeep
This creates
.planning/
,
.planning/phases/
, the three state subdirectories, and
.gitkeep
files so git tracks them. Run this BEFORE writing any files.
Synthesize all context into
.planning/PROJECT.md
using the template from
@./references/project-template.md
.
For greenfield projects:
Initialize requirements as hypotheses:
markdown
undefined
首先,通过单个命令创建所有项目目录:
bash
mkdir -p .planning/phases/pending .planning/phases/active .planning/phases/completed
touch .planning/phases/pending/.gitkeep .planning/phases/active/.gitkeep .planning/phases/completed/.gitkeep
此命令将创建
.planning/
.planning/phases/
、三个状态子目录,以及
.gitkeep
文件,确保git能追踪这些目录。在撰写任何文件前先运行此命令。
使用
@./references/project-template.md
中的模板,将所有上下文信息整合到
.planning/PROJECT.md
中。
对于新项目(无现有代码):
将需求初始化为假设:
markdown
undefined

Requirements

需求

Validated

已验证

(None yet — ship to validate)
(暂无 — 交付后验证)

Active

待处理

  • [Requirement 1]
  • [Requirement 2]
  • [Requirement 3]
  • [需求1]
  • [需求2]
  • [需求3]

Out of Scope

超出范围

  • [Exclusion 1] — [why]
  • [Exclusion 2] — [why]

All Active requirements are hypotheses until shipped and validated.

**For brownfield projects (codebase map exists):**

Infer Validated requirements from existing code:

1. Read `.planning/codebase/ARCHITECTURE.md` and `STACK.md`
2. Identify what the codebase already does
3. These become the initial Validated set

```markdown
  • [排除项1] — [原因]
  • [排除项2] — [原因]

所有待处理需求在交付并验证前均为假设。

**对于遗留项目(已存在代码库映射):**

从现有代码中推断已验证需求:

1. 读取`.planning/codebase/ARCHITECTURE.md`和`STACK.md`
2. 识别代码库已实现的功能
3. 将这些功能作为初始的已验证需求

```markdown

Requirements

需求

Validated

已验证

  • ✓ [Existing capability 1] — existing
  • ✓ [Existing capability 2] — existing
  • ✓ [Existing capability 3] — existing
  • ✓ [现有功能1] — 已存在
  • ✓ [现有功能2] — 已存在
  • ✓ [现有功能3] — 已存在

Active

待处理

  • [New requirement 1]
  • [New requirement 2]
  • [新需求1]
  • [新需求2]

Out of Scope

超出范围

  • [Exclusion 1] — [why]

**Key Decisions:**

Initialize with any decisions made during questioning:

```markdown
  • [排除项1] — [原因]

**关键决策:**

将提问过程中做出的所有决策进行初始化:

```markdown

Key Decisions

关键决策

DecisionRationaleOutcome
[Choice from questioning][Why]— Pending

**Last updated footer:**

```markdown
---
*Last updated: [date] after initialization*
Do not compress. Capture everything gathered.
Commit PROJECT.md:
bash
git add .planning/PROJECT.md .planning/phases/pending/.gitkeep .planning/phases/active/.gitkeep .planning/phases/completed/.gitkeep
git commit -m "$(cat <<'EOF'
docs: initialize project

[One-liner from PROJECT.md What This Is section]
EOF
)"
决策理由结果
[提问过程中做出的选择][原因]— 待确认

**最后更新页脚:**

```markdown
---
*最后更新: [日期] 初始化后*
不要压缩内容,完整记录所有收集到的信息。
提交PROJECT.md:
bash
git add .planning/PROJECT.md .planning/phases/pending/.gitkeep .planning/phases/active/.gitkeep .planning/phases/completed/.gitkeep
git commit -m "$(cat <<'EOF'
docs: initialize project

[PROJECT.md中“项目概述”部分的一句话描述]
EOF
)"

Phase 5: Workflow Preferences

阶段5:工作流偏好设置

Round 1 — Core workflow settings (4 questions):
questions: [
  {
    header: "Mode",
    question: "How do you want to work?",
    multiSelect: false,
    options: [
      { label: "YOLO (Recommended)", description: "Auto-approve, just execute" },
      { label: "Interactive", description: "Confirm at each step" }
    ]
  },
  {
    header: "Depth",
    question: "How thorough should planning be?",
    multiSelect: false,
    options: [
      { label: "Quick", description: "Ship fast (3-5 phases, 1-3 plans each)" },
      { label: "Standard", description: "Balanced scope and speed (5-8 phases, 3-5 plans each)" },
      { label: "Comprehensive", description: "Thorough coverage (8-12 phases, 5-10 plans each)" }
    ]
  },
  {
    header: "Execution",
    question: "Run plans in parallel?",
    multiSelect: false,
    options: [
      { label: "Parallel (Recommended)", description: "Independent plans run simultaneously" },
      { label: "Sequential", description: "One plan at a time" }
    ]
  },
  {
    header: "Git Tracking",
    question: "Commit planning docs to git?",
    multiSelect: false,
    options: [
      { label: "Yes (Recommended)", description: "Planning docs tracked in version control" },
      { label: "No", description: "Keep .planning/ local-only (add to .gitignore)" }
    ]
  },
  {
    header: "PR Workflow",
    question: "Use PR-based release workflow?",
    multiSelect: false,
    options: [
      { label: "Yes (Recommended)", description: "Protect main, create PRs, tag via GitHub Release" },
      { label: "No", description: "Commit directly to main, create tags locally" }
    ]
  },
  {
    header: "GitHub Tracking",
    question: "Enable GitHub Milestone/Issue tracking?",
    multiSelect: false,
    options: [
      { label: "Yes (Recommended)", description: "Create GitHub Milestones for Kata milestones, optionally create Issues for phases" },
      { label: "No", description: "Keep planning local to .planning/ directory only" }
    ]
  }
]
第一轮 — 核心工作流设置(4个问题):
questions: [
  {
    header: "模式",
    question: "你希望采用哪种工作模式?",
    multiSelect: false,
    options: [
      { label: "YOLO(推荐)", description: "自动批准,直接执行" },
      { label: "交互式", description: "每一步都需要确认" }
    ]
  },
  {
    header: "规划深度",
    question: "规划应达到何种细致程度?",
    multiSelect: false,
    options: [
      { label: "快速", description: "快速交付(3-5个阶段,每个阶段1-3个计划)" },
      { label: "标准", description: "平衡范围与速度(5-8个阶段,每个阶段3-5个计划)" },
      { label: "全面", description: "全面覆盖(8-12个阶段,每个阶段5-10个计划)" }
    ]
  },
  {
    header: "执行方式",
    question: "是否并行运行计划?",
    multiSelect: false,
    options: [
      { label: "并行(推荐)", description: "独立计划同时运行" },
      { label: "串行", description: "一次运行一个计划" }
    ]
  },
  {
    header: "Git追踪",
    question: "是否将规划文档提交到git?",
    multiSelect: false,
    options: [
      { label: "是(推荐)", description: "规划文档纳入版本控制" },
      { label: "否", description: "仅本地保留.planning/目录(添加到.gitignore)" }
    ]
  },
  {
    header: "PR工作流",
    question: "是否采用基于PR的发布工作流?",
    multiSelect: false,
    options: [
      { label: "是(推荐)", description: "保护main分支,创建PR,通过GitHub Release打标签" },
      { label: "否", description: "直接提交到main分支,在本地创建标签" }
    ]
  },
  {
    header: "GitHub追踪",
    question: "是否启用GitHub Milestone/Issue追踪?",
    multiSelect: false,
    options: [
      { label: "是(推荐)", description: "为Kata里程碑创建GitHub Milestones,可选为阶段创建Issues" },
      { label: "否", description: "仅在.planning/目录中保留本地规划" }
    ]
  }
]

If GitHub Tracking = Yes, ask follow-up:

若GitHub追踪 = 是,提出后续问题:

{ header: "Issue Creation", question: "When should GitHub Issues be created for phases?", multiSelect: false, options: [ { label: "Auto", description: "Create Issues automatically for each phase (no prompting)" }, { label: "Ask per milestone", description: "Prompt once per milestone, decision applies to all phases" }, { label: "Never", description: "Only create Milestones, no phase-level Issues" } ] }

**GitHub Repository Check (conditional):**

**If GitHub Tracking = Yes:**

After confirming GitHub preferences, check for existing remote:

```bash
{ header: "Issue创建时机", question: "应为阶段创建GitHub Issues的时机?", multiSelect: false, options: [ { label: "自动", description: "自动为每个阶段创建Issues(无需提示)" }, { label: "每个里程碑询问一次", description: "每个里程碑提示一次,决策适用于所有阶段" }, { label: "从不", description: "仅创建Milestones,不创建阶段级Issues" } ] }

**GitHub仓库检查(条件性操作):**

**若GitHub追踪 = 是:**

确认GitHub偏好设置后,检查是否存在远程仓库:

```bash

Check if gh CLI is authenticated

检查gh CLI是否已认证

GH_AUTH=$(gh auth status &>/dev/null && echo "true" || echo "false")
GH_AUTH=$(gh auth status &>/dev/null && echo "true" || echo "false")

Check for GitHub remote

检查是否存在GitHub远程仓库

HAS_GITHUB_REMOTE=$(git remote -v 2>/dev/null | grep -q 'github.com' && echo "true" || echo "false")

**If `HAS_GITHUB_REMOTE=false` and user selected GitHub Tracking = Yes:**

Use AskUserQuestion:
- header: "GitHub Repository"
- question: "GitHub tracking enabled, but no GitHub repository is linked. Create one now?"
- options:
  - "Create private repo (Recommended)" — Run `gh repo create --source=. --private --push`
  - "Create public repo" — Run `gh repo create --source=. --public --push`
  - "Skip for now" — Disable GitHub tracking (can enable later with `gh repo create`)

**If "Create private repo":**
```bash
if [ "$GH_AUTH" = "true" ]; then
  gh repo create --source=. --private --push && echo "GitHub repository created" || echo "Warning: Failed to create repository"
else
  echo "Warning: GitHub CLI not authenticated. Run 'gh auth login' first, then 'gh repo create --source=. --private --push'"
fi
Continue with
github.enabled: true
.
If "Create public repo":
bash
if [ "$GH_AUTH" = "true" ]; then
  gh repo create --source=. --public --push && echo "GitHub repository created" || echo "Warning: Failed to create repository"
else
  echo "Warning: GitHub CLI not authenticated. Run 'gh auth login' first, then 'gh repo create --source=. --public --push'"
fi
Continue with
github.enabled: true
.
If "Skip for now":
  • Set
    github.enabled: false
    in config.json (override user's earlier selection)
  • Display note: "GitHub tracking disabled — no repository configured. Run
    gh repo create --source=. --public
    to enable later, then update
    .planning/config.json
    ."
If
HAS_GITHUB_REMOTE=true
:
  • Proceed normally with user's GitHub preferences
  • No additional prompts needed
Round 2 — Workflow agents:
These spawn additional agents during planning/execution. They add tokens and time but improve quality.
AgentWhen it runsWhat it does
ResearcherBefore planning each phaseInvestigates domain, finds patterns, surfaces gotchas
Plan CheckerAfter plan is createdVerifies plan actually achieves the phase goal
VerifierAfter phase executionConfirms must-haves were delivered
All recommended for important projects. Skip for quick experiments.
questions: [
  {
    header: "Research",
    question: "Research before planning each phase? (adds tokens/time)",
    multiSelect: false,
    options: [
      { label: "Yes (Recommended)", description: "Investigate domain, find patterns, surface gotchas" },
      { label: "No", description: "Plan directly from requirements" }
    ]
  },
  {
    header: "Plan Check",
    question: "Verify plans will achieve their goals? (adds tokens/time)",
    multiSelect: false,
    options: [
      { label: "Yes (Recommended)", description: "Catch gaps before execution starts" },
      { label: "No", description: "Execute plans without verification" }
    ]
  },
  {
    header: "Verifier",
    question: "Verify work satisfies requirements after each phase? (adds tokens/time)",
    multiSelect: false,
    options: [
      { label: "Yes (Recommended)", description: "Confirm deliverables match phase goals" },
      { label: "No", description: "Trust execution, skip verification" }
    ]
  },
  {
    header: "Model Profile",
    question: "Which AI models for planning agents?",
    multiSelect: false,
    options: [
      { label: "Balanced (Recommended)", description: "Sonnet for most agents — good quality/cost ratio" },
      { label: "Quality", description: "Opus for research/roadmap — higher cost, deeper analysis" },
      { label: "Budget", description: "Haiku where possible — fastest, lowest cost" }
    ]
  },
  {
    header: "Statusline",
    question: "Enable Kata statusline? (shows model, context usage, update status)",
    multiSelect: false,
    options: [
      { label: "Yes (Recommended)", description: "Display live session info in Claude Code statusline" },
      { label: "No", description: "Use default Claude Code statusline" }
    ]
  }
]
Create
.planning/config.json
with all settings:
json
{
  "mode": "yolo|interactive",
  "depth": "quick|standard|comprehensive",
  "parallelization": true|false,
  "commit_docs": true|false,
  "pr_workflow": true|false,
  "model_profile": "quality|balanced|budget",
  "display": {
    "statusline": true|false
  },
  "workflow": {
    "research": true|false,
    "plan_check": true|false,
    "verifier": true|false
  },
  "github": {
    "enabled": true|false,
    "issueMode": "auto|ask|never"
  }
}
GitHub Tracking conditional logic:
If GitHub Tracking = Yes:
  • Ask the Issue Creation follow-up question
  • Check for GitHub remote (see GitHub Repository Check above)
  • Set
    github.enabled
    based on final state (true if remote exists or was created, false if skipped)
  • Set
    github.issueMode
    based on Issue Creation choice:
    • "Auto" →
      "auto"
    • "Ask per milestone" →
      "ask"
    • "Never" →
      "never"
  • Display note based on outcome:
    • If remote exists/created: "GitHub integration enabled. Milestones will be created via
      gh
      CLI."
    • If skipped: "GitHub tracking disabled — no repository configured."
If GitHub Tracking = No:
  • Skip the Issue Creation question
  • Skip the GitHub Repository Check
  • Set
    github.enabled: false
  • Set
    github.issueMode: "never"
If commit_docs = No:
  • Set
    commit_docs: false
    in config.json
  • Add
    .planning/
    to
    .gitignore
    (create if needed)
If commit_docs = Yes:
  • No additional gitignore entries needed
Commit config.json:
bash
git add .planning/config.json
git commit -m "$(cat <<'EOF'
chore: add project config

Mode: [chosen mode]
Depth: [chosen depth]
Parallelization: [enabled/disabled]
Workflow agents: research=[on/off], plan_check=[on/off], verifier=[on/off]
EOF
)"
Note: Run
/kata-configure-settings
anytime to update these preferences.
If pr_workflow = Yes:
Ask about GitHub Actions release workflow:
AskUserQuestion([
  {
    header: "GitHub Actions",
    question: "Scaffold a GitHub Actions workflow to auto-publish on release?",
    multiSelect: false,
    options: [
      { label: "Yes (Recommended)", description: "Create .github/workflows/release.yml for npm publish" },
      { label: "No", description: "I'll set up CI/CD myself" }
    ]
  }
])
If "Yes":
Create
.github/workflows/release.yml
:
Branch Protection Recommendation:
After scaffolding, display:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ⚠ RECOMMENDED: Enable GitHub Branch Protection
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Since you've enabled PR workflow, we strongly recommend
protecting your main branch to prevent accidental direct pushes.

Go to: https://github.com/{owner}/{repo}/settings/branches

Enable these settings for `main`:
  ✓ Require a pull request before merging
  ✓ Do not allow bypassing the above settings
  ✗ Allow force pushes (uncheck this)

This ensures ALL changes go through PRs — even in emergencies,
you can temporarily disable protection from GitHub settings.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
bash
mkdir -p .github/workflows
Write the workflow file:
yaml
name: Publish to npm

on:
  push:
    branches:
      - main

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          registry-url: 'https://registry.npmjs.org'

      - name: Get package info
        id: package
        run: |
          LOCAL_VERSION=$(node -p "require('./package.json').version")
          PACKAGE_NAME=$(node -p "require('./package.json').name")
          echo "local_version=$LOCAL_VERSION" >> $GITHUB_OUTPUT
          echo "package_name=$PACKAGE_NAME" >> $GITHUB_OUTPUT

          # Get published version (returns empty if not published)
          PUBLISHED_VERSION=$(npm view "$PACKAGE_NAME" version 2>/dev/null || echo "")
          echo "published_version=$PUBLISHED_VERSION" >> $GITHUB_OUTPUT

          echo "Local version: $LOCAL_VERSION"
          echo "Published version: $PUBLISHED_VERSION"

      - name: Check if should publish
        id: check
        run: |
          LOCAL="${{ steps.package.outputs.local_version }}"
          PUBLISHED="${{ steps.package.outputs.published_version }}"

          if [ -z "$PUBLISHED" ]; then
            echo "Package not yet published, will publish"
            echo "should_publish=true" >> $GITHUB_OUTPUT
          elif [ "$LOCAL" != "$PUBLISHED" ]; then
            echo "Version changed ($PUBLISHED -> $LOCAL), will publish"
            echo "should_publish=true" >> $GITHUB_OUTPUT
          else
            echo "Version unchanged ($LOCAL), skipping publish"
            echo "should_publish=false" >> $GITHUB_OUTPUT
          fi

      - name: Publish to npm
        if: steps.check.outputs.should_publish == 'true'
        run: npm publish --access public
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

      - name: Create GitHub Release
        if: steps.check.outputs.should_publish == 'true'
        uses: softprops/action-gh-release@v2
        with:
          tag_name: v${{ steps.package.outputs.local_version }}
          name: v${{ steps.package.outputs.local_version }}
          generate_release_notes: true
          make_latest: true
Commit the workflow:
bash
git add .github/workflows/release.yml
git commit -m "$(cat <<'EOF'
ci: add npm publish workflow

Publishes to npm and creates GitHub Release when:
- Push to main
- package.json version differs from published version

Requires NPM_TOKEN secret in repository settings.
EOF
)"
Display setup instructions:
✓ Created .github/workflows/release.yml
HAS_GITHUB_REMOTE=$(git remote -v 2>/dev/null | grep -q 'github.com' && echo "true" || echo "false")

**若`HAS_GITHUB_REMOTE=false`且用户选择了GitHub追踪 = 是:**

使用AskUserQuestion工具:
- 标题: "GitHub仓库"
- 问题: "已启用GitHub追踪,但未关联GitHub仓库。是否现在创建一个?"
- 选项:
  - "创建私有仓库(推荐)" — 运行`gh repo create --source=. --private --push`
  - "创建公开仓库" — 运行`gh repo create --source=. --public --push`
  - "暂时跳过" — 禁用GitHub追踪(后续可通过`gh repo create`启用)

**若选择“创建私有仓库”:**
```bash
if [ "$GH_AUTH" = "true" ]; then
  gh repo create --source=. --private --push && echo "GitHub repository created" || echo "Warning: Failed to create repository"
else
  echo "Warning: GitHub CLI not authenticated. Run 'gh auth login' first, then 'gh repo create --source=. --private --push'"
fi
继续设置
github.enabled: true
若选择“创建公开仓库”:
bash
if [ "$GH_AUTH" = "true" ]; then
  gh repo create --source=. --public --push && echo "GitHub repository created" || echo "Warning: Failed to create repository"
else
  echo "Warning: GitHub CLI not authenticated. Run 'gh auth login' first, then 'gh repo create --source=. --public --push'"
fi
继续设置
github.enabled: true
若选择“暂时跳过”:
  • 在config.json中设置
    github.enabled: false
    (覆盖用户之前的选择)
  • 显示提示:"GitHub追踪已禁用 — 未配置仓库。后续可运行
    gh repo create --source=. --public
    启用,然后更新
    .planning/config.json
    。"
HAS_GITHUB_REMOTE=true
  • 按照用户的GitHub偏好设置正常进行
  • 无需额外提示
第二轮 — 工作流代理:
这些代理将在规划/执行过程中生成额外的辅助进程。它们会消耗更多token和时间,但能提升质量。
代理运行时机功能
Researcher每个阶段规划前调研领域情况,发现模式,揭示潜在问题
Plan Checker计划创建后验证计划是否能实现阶段目标
Verifier阶段执行后确认已交付必要内容
对于重要项目,推荐启用所有代理。快速实验项目可跳过。
questions: [
  {
    header: "调研",
    question: "每个阶段规划前是否进行调研?(会增加token消耗和时间)",
    multiSelect: false,
    options: [
      { label: "是(推荐)", description: "调研领域情况,发现模式,揭示潜在问题" },
      { label: "否", description: "直接根据需求制定计划" }
    ]
  },
  {
    header: "计划检查",
    question: "是否验证计划能否实现目标?(会增加token消耗和时间)",
    multiSelect: false,
    options: [
      { label: "是(推荐)", description: "在执行前发现漏洞" },
      { label: "否", description: "直接执行计划,不进行验证" }
    ]
  },
  {
    header: "结果验证",
    question: "每个阶段执行后是否验证工作是否满足需求?(会增加token消耗和时间)",
    multiSelect: false,
    options: [
      { label: "是(推荐)", description: "确认交付成果符合阶段目标" },
      { label: "否", description: "信任执行结果,跳过验证" }
    ]
  },
  {
    header: "模型配置",
    question: "规划代理使用哪种AI模型?",
    multiSelect: false,
    options: [
      { label: "平衡型(推荐)", description: "大多数代理使用Sonnet — 性价比高" },
      { label: "高质量", description: "调研/路线图使用Opus — 成本更高,分析更深入" },
      { label: "经济型", description: "尽可能使用Haiku — 速度最快,成本最低" }
    ]
  },
  {
    header: "状态栏",
    question: "是否启用Kata状态栏?(显示模型、上下文使用情况、更新状态)",
    multiSelect: false,
    options: [
      { label: "是(推荐)", description: "在Claude Code状态栏中显示实时会话信息" },
      { label: "否", description: "使用默认Claude Code状态栏" }
    ]
  }
]
创建包含所有设置的
.planning/config.json
json
{
  "mode": "yolo|interactive",
  "depth": "quick|standard|comprehensive",
  "parallelization": true|false,
  "commit_docs": true|false,
  "pr_workflow": true|false,
  "model_profile": "quality|balanced|budget",
  "display": {
    "statusline": true|false
  },
  "workflow": {
    "research": true|false,
    "plan_check": true|false,
    "verifier": true|false
  },
  "github": {
    "enabled": true|false,
    "issueMode": "auto|ask|never"
  }
}
GitHub追踪条件逻辑:
若GitHub追踪 = 是:
  • 提出Issue创建时机的后续问题
  • 检查是否存在GitHub远程仓库(见上述GitHub仓库检查部分)
  • 根据最终状态设置
    github.enabled
    (若远程仓库存在或已创建则为true,若跳过则为false)
  • 根据Issue创建时机的选择设置
    github.issueMode
    • "自动" →
      "auto"
    • "每个里程碑询问一次" →
      "ask"
    • "从不" →
      "never"
  • 根据结果显示提示:
    • 若远程仓库存在/已创建:"已启用GitHub集成。将通过
      gh
      CLI创建Milestones。"
    • 若跳过:"GitHub追踪已禁用 — 未配置仓库。"
若GitHub追踪 = 否:
  • 跳过Issue创建时机的问题
  • 跳过GitHub仓库检查
  • 设置
    github.enabled: false
  • 设置
    github.issueMode: "never"
若commit_docs = 否:
  • 在config.json中设置
    commit_docs: false
  • .planning/
    添加到
    .gitignore
    (若不存在则创建)
若commit_docs = 是:
  • 无需添加额外的gitignore条目
提交config.json:
bash
git add .planning/config.json
git commit -m "$(cat <<'EOF'
chore: add project config

Mode: [所选模式]
Depth: [所选深度]
Parallelization: [启用/禁用]
Workflow agents: research=[开启/关闭], plan_check=[开启/关闭], verifier=[开启/关闭]
EOF
)"
注意: 可随时运行
/kata-configure-settings
来更新这些偏好设置。
若pr_workflow = 是:
询问关于GitHub Actions发布工作流的问题:
AskUserQuestion([
  {
    header: "GitHub Actions",
    question: "是否生成GitHub Actions工作流以在发布时自动推送?",
    multiSelect: false,
    options: [
      { label: "是(推荐)", description: "创建.github/workflows/release.yml用于npm发布" },
      { label: "否", description: "我将自行设置CI/CD" }
    ]
  }
])
若选择“是”:
创建
.github/workflows/release.yml
分支保护建议:
生成工作流后,显示以下内容:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ⚠ 推荐:启用GitHub分支保护
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

已启用PR工作流。强烈建议保护你的main分支,防止意外直接推送。

前往:https://github.com/{owner}/{repo}/settings/branches

为`main`分支启用以下设置:
  ✓ 合并前需要拉取请求
  ✓ 不允许绕过上述设置
  ✗ 允许强制推送(取消勾选)

这确保所有更改都通过PR进行 — 即使在紧急情况下,你也可以从GitHub设置中临时禁用保护。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
bash
mkdir -p .github/workflows
编写工作流文件:
yaml
name: Publish to npm

on:
  push:
    branches:
      - main

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          registry-url: 'https://registry.npmjs.org'

      - name: Get package info
        id: package
        run: |
          LOCAL_VERSION=$(node -p "require('./package.json').version")
          PACKAGE_NAME=$(node -p "require('./package.json').name")
          echo "local_version=$LOCAL_VERSION" >> $GITHUB_OUTPUT
          echo "package_name=$PACKAGE_NAME" >> $GITHUB_OUTPUT

          # 获取已发布版本(若未发布则返回空)
          PUBLISHED_VERSION=$(npm view "$PACKAGE_NAME" version 2>/dev/null || echo "")
          echo "published_version=$PUBLISHED_VERSION" >> $GITHUB_OUTPUT

          echo "Local version: $LOCAL_VERSION"
          echo "Published version: $PUBLISHED_VERSION"

      - name: Check if should publish
        id: check
        run: |
          LOCAL="${{ steps.package.outputs.local_version }}"
          PUBLISHED="${{ steps.package.outputs.published_version }}"

          if [ -z "$PUBLISHED" ]; then
            echo "Package not yet published, will publish"
            echo "should_publish=true" >> $GITHUB_OUTPUT
          elif [ "$LOCAL" != "$PUBLISHED" ]; then
            echo "Version changed ($PUBLISHED -> $LOCAL), will publish"
            echo "should_publish=true" >> $GITHUB_OUTPUT
          else
            echo "Version unchanged ($LOCAL), skipping publish"
            echo "should_publish=false" >> $GITHUB_OUTPUT
          fi

      - name: Publish to npm
        if: steps.check.outputs.should_publish == 'true'
        run: npm publish --access public
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

      - name: Create GitHub Release
        if: steps.check.outputs.should_publish == 'true'
        uses: softprops/action-gh-release@v2
        with:
          tag_name: v${{ steps.package.outputs.local_version }}
          name: v${{ steps.package.outputs.local_version }}
          generate_release_notes: true
          make_latest: true
提交工作流:
bash
git add .github/workflows/release.yml
git commit -m "$(cat <<'EOF'
ci: add npm publish workflow

满足以下条件时自动发布到npm并创建GitHub Release:
- 推送到main分支
- package.json版本与已发布版本不同

需要在仓库设置中配置NPM_TOKEN密钥。
EOF
)"
显示设置说明:
✓ 已创建.github/workflows/release.yml

Setup Required

所需设置

Add NPM_TOKEN secret to your GitHub repository:
  1. Go to repo Settings → Secrets and variables → Actions
  2. Click "New repository secret"
  3. Name: NPM_TOKEN
  4. Value: Your npm access token (from npmjs.com → Access Tokens)
The workflow will auto-publish when you merge PRs that bump package.json version.

**If statusline = Yes:**

Update `.claude/settings.json` with statusline configuration:

```bash
将NPM_TOKEN密钥添加到你的GitHub仓库:
  1. 前往仓库设置 → Secrets and variables → Actions
  2. 点击"New repository secret"
  3. 名称: NPM_TOKEN
  4. 值: 你的npm访问令牌(来自npmjs.com → Access Tokens)
当你合并更新了package.json版本的PR时,工作流将自动发布。

**若statusline = 是:**

更新`.claude/settings.json`中的状态栏配置:

```bash

Ensure .claude directory exists

确保.claude目录存在

mkdir -p .claude
mkdir -p .claude

Check if settings.json exists and has statusLine

检查settings.json是否存在且已配置statusLine

if [ -f .claude/settings.json ]; then

Check if statusLine already configured

if grep -q '"statusLine"' .claude/settings.json; then echo "Statusline already configured in .claude/settings.json" else # Add statusLine to existing settings using node node -e " const fs = require('fs'); const settings = JSON.parse(fs.readFileSync('.claude/settings.json', 'utf8')); settings.statusLine = { type: 'command', command: 'node "$CLAUDE_PROJECT_DIR/.claude/hooks/kata-statusline.js"' }; fs.writeFileSync('.claude/settings.json', JSON.stringify(settings, null, 2)); " echo "✓ Statusline enabled in .claude/settings.json" fi else

Create new settings.json with statusLine

cat > .claude/settings.json << 'SETTINGS_EOF' { "statusLine": { "type": "command", "command": "node "$CLAUDE_PROJECT_DIR/.claude/hooks/kata-statusline.js"" } } SETTINGS_EOF echo "✓ Created .claude/settings.json with statusline" fi

The statusline hook will be automatically installed on next session start by Kata's SessionStart hook.

**If statusline = No:**

No changes to `.claude/settings.json`.
if [ -f .claude/settings.json ]; then

检查statusLine是否已配置

if grep -q '"statusLine"' .claude/settings.json; then echo "Statusline already configured in .claude/settings.json" else # 使用node将statusLine添加到现有设置中 node -e " const fs = require('fs'); const settings = JSON.parse(fs.readFileSync('.claude/settings.json', 'utf8')); settings.statusLine = { type: 'command', command: 'node "$CLAUDE_PROJECT_DIR/.claude/hooks/kata-statusline.js"' }; fs.writeFileSync('.claude/settings.json', JSON.stringify(settings, null, 2)); " echo "✓ 已在.claude/settings.json中启用状态栏" fi else

创建包含statusLine的新settings.json

cat > .claude/settings.json << 'SETTINGS_EOF' { "statusLine": { "type": "command", "command": "node "$CLAUDE_PROJECT_DIR/.claude/hooks/kata-statusline.js"" } } SETTINGS_EOF echo "✓ 已创建包含状态栏配置的.claude/settings.json" fi

状态栏钩子将在下次会话启动时由Kata的SessionStart钩子自动安装。

**若statusline = 否:**

无需修改`.claude/settings.json`。

Phase 5.5: Resolve Model Profile

阶段5.5:解析模型配置

Read model profile for agent spawning:
bash
MODEL_PROFILE=$(cat .planning/config.json 2>/dev/null | grep -o '"model_profile"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "balanced")
Default to "balanced" if not set.
Model lookup table:
Agentqualitybalancedbudget
kata-project-researcheropussonnethaiku
kata-research-synthesizersonnetsonnethaiku
kata-roadmapperopussonnetsonnet
Store resolved models for use in Task calls if milestone research/roadmapping is needed later.
读取模型配置以用于生成代理:
bash
MODEL_PROFILE=$(cat .planning/config.json 2>/dev/null | grep -o '"model_profile"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "balanced")
若未设置,默认使用“balanced”。
模型查找表:
代理qualitybalancedbudget
kata-project-researcheropussonnethaiku
kata-research-synthesizersonnetsonnethaiku
kata-roadmapperopussonnetsonnet
存储解析后的模型,以便后续在需要里程碑调研/路线图制定时用于任务调用。

Phase 6: Done

阶段6:完成

Commit PROJECT.md and config.json (if not already committed):
Check if uncommitted changes exist and commit them:
bash
undefined
提交PROJECT.md和config.json(若尚未提交):
检查是否存在未提交的更改并提交:
bash
undefined

Check for uncommitted planning files

检查规划文件是否有未提交的更改

if git status --porcelain .planning/PROJECT.md .planning/config.json 2>/dev/null | grep -q '.'; then git add .planning/PROJECT.md .planning/config.json git commit -m "$(cat <<'EOF' docs: initialize project
Project context and workflow configuration. EOF )" fi

**Self-validation — verify all required artifacts exist before displaying completion:**

```bash
MISSING=""
[ ! -f .planning/PROJECT.md ] && MISSING="${MISSING}\n- .planning/PROJECT.md"
[ ! -f .planning/config.json ] && MISSING="${MISSING}\n- .planning/config.json"
[ ! -f .planning/phases/pending/.gitkeep ] && MISSING="${MISSING}\n- .planning/phases/pending/.gitkeep"
[ ! -f .planning/phases/active/.gitkeep ] && MISSING="${MISSING}\n- .planning/phases/active/.gitkeep"
[ ! -f .planning/phases/completed/.gitkeep ] && MISSING="${MISSING}\n- .planning/phases/completed/.gitkeep"
if [ -n "$MISSING" ]; then
  echo "MISSING ARTIFACTS:${MISSING}"
else
  echo "ALL ARTIFACTS PRESENT"
fi
If anything is missing: Create the missing artifacts now. Do NOT proceed to the completion banner until all artifacts exist.
Display completion banner:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► PROJECT INITIALIZED ✓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Project Name]
ArtifactLocation
Project
.planning/PROJECT.md
Config
.planning/config.json
Ready for milestone planning ✓
If pr_workflow = Yes, append:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ⚠ RECOMMENDED: Enable Branch Protection
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PR workflow is enabled. Protect your main branch:

  https://github.com/{owner}/{repo}/settings/branches

Settings for `main`:
  ✓ Require a pull request before merging
  ✓ Do not allow bypassing the above settings
  ✗ Allow force pushes (uncheck)
───────────────────────────────────────────────────────────────
if git status --porcelain .planning/PROJECT.md .planning/config.json 2>/dev/null | grep -q '.'; then git add .planning/PROJECT.md .planning/config.json git commit -m "$(cat <<'EOF' docs: initialize project
Project context and workflow configuration. EOF )" fi

**自我验证 — 在显示完成信息前,验证所有必需的工件是否存在:**

```bash
MISSING=""
[ ! -f .planning/PROJECT.md ] && MISSING="${MISSING}\n- .planning/PROJECT.md"
[ ! -f .planning/config.json ] && MISSING="${MISSING}\n- .planning/config.json"
[ ! -f .planning/phases/pending/.gitkeep ] && MISSING="${MISSING}\n- .planning/phases/pending/.gitkeep"
[ ! -f .planning/phases/active/.gitkeep ] && MISSING="${MISSING}\n- .planning/phases/active/.gitkeep"
[ ! -f .planning/phases/completed/.gitkeep ] && MISSING="${MISSING}\n- .planning/phases/completed/.gitkeep"
if [ -n "$MISSING" ]; then
  echo "MISSING ARTIFACTS:${MISSING}"
else
  echo "ALL ARTIFACTS PRESENT"
fi
若存在缺失的工件: 立即创建缺失的工件。在所有工件都存在前,不要显示完成横幅。
显示完成横幅:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► 项目初始化完成 ✓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[项目名称]
工件位置
项目文档
.planning/PROJECT.md
配置文件
.planning/config.json
已准备好进行里程碑规划 ✓
若pr_workflow = 是,追加以下内容:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ⚠ 推荐:启用分支保护
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

已启用PR工作流。请保护你的main分支:

  https://github.com/{owner}/{repo}/settings/branches

`main`分支的设置:
  ✓ 合并前需要拉取请求
  ✓ 不允许绕过上述设置
  ✗ 允许强制推送(取消勾选)
───────────────────────────────────────────────────────────────

▶ Next Up

▶ 下一步

Define your first milestone
/kata-add-milestone
— research, requirements, and roadmap
<sub>
/clear
first → fresh context window</sub>
───────────────────────────────────────────────────────────────
</process> <output>
  • .planning/PROJECT.md
  • .planning/config.json
</output>
<success_criteria>
  • .planning/ directory created
  • .planning/phases/pending/, active/, completed/ directories created
  • Git repo initialized
  • Brownfield detection completed
  • Deep questioning completed (threads followed, not rushed)
  • PROJECT.md captures full context → committed
  • config.json has workflow mode, depth, parallelization → committed
  • Self-validation passed (all artifacts exist)
  • User knows next step is
    /kata-add-milestone
Atomic commits: PROJECT.md and config.json are committed. If context is lost, artifacts persist.
</success_criteria>
定义你的第一个里程碑
/kata-add-milestone
— 调研、需求和路线图制定
<sub>先运行
/clear
→ 刷新上下文窗口</sub>
───────────────────────────────────────────────────────────────
</process> <output>
  • .planning/PROJECT.md
  • .planning/config.json
</output>
<success_criteria>
  • 已创建.planning/目录
  • 已创建.planning/phases/pending/、active/、completed/目录
  • 已初始化Git仓库
  • 已完成遗留项目检测
  • 已完成深度提问(跟进对话,不仓促)
  • PROJECT.md完整记录了上下文信息 → 已提交
  • config.json包含工作流模式、深度、并行设置 → 已提交
  • 自我验证通过(所有工件均存在)
  • 用户了解下一步是运行
    /kata-add-milestone
原子提交: PROJECT.md和config.json已提交。即使上下文丢失,工件仍会保留。
</success_criteria>