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:
- — project context
.planning/PROJECT.md - — workflow preferences
.planning/config.json
After this command: Run to define your first milestone.
</objective>
/kata-add-milestone<execution_context>
@./references/questioning.md
@./references/ui-brand.md
@./references/project-template.md
</execution_context>
<process><objective>
通过深度收集上下文信息和配置工作流来初始化新项目。
这是任何项目中价值最高的时刻。在此阶段进行深入提问意味着更完善的计划、更顺畅的执行和更理想的结果。
创建的文件:
- — 项目上下文文档
.planning/PROJECT.md - — 工作流偏好配置文件
.planning/config.json
执行此命令后: 运行来定义你的第一个里程碑。
</objective>
/kata-add-milestone<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:
-
Abort if project exists:bash
[ -f .planning/PROJECT.md ] && echo "ERROR: Project already initialized. Use /kata-track-progress" && exit 1 -
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 -
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.
必须首先执行的步骤 — 在与用户进行任何交互前完成以下检查:
-
若项目已存在则终止:bash
[ -f .planning/PROJECT.md ] && echo "ERROR: Project already initialized. Use /kata-track-progress" && exit 1 -
在此目录中初始化git仓库(即使在父仓库内也需要执行此操作):bash
if [ -d .git ] || [ -f .git ]; then echo "Git repo exists in current directory" else git init echo "Initialized new git repo" fi -
检测现有代码(遗留项目检测):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 is non-empty OR
CODE_FILESis "yes"HAS_PACKAGE - AND is NOT "yes"
HAS_CODEBASE_MAP
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为"yes"HAS_PACKAGE - 且不为"yes"
HAS_CODEBASE_MAP
使用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 for techniques:
questioning.md- 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 . If gaps remain, weave questions naturally. Don't suddenly switch to checklist mode.
questioning.mdDecision 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/.gitkeepThis creates , , the three state subdirectories, and files so git tracks them. Run this BEFORE writing any files.
.planning/.planning/phases/.gitkeepSynthesize all context into using the template from .
.planning/PROJECT.md@./references/project-template.mdFor 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此命令将创建、、三个状态子目录,以及文件,确保git能追踪这些目录。在撰写任何文件前先运行此命令。
.planning/.planning/phases/.gitkeep使用中的模板,将所有上下文信息整合到中。
@./references/project-template.md.planning/PROJECT.md对于新项目(无现有代码):
将需求初始化为假设:
markdown
undefinedRequirements
需求
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. 将这些功能作为初始的已验证需求
```markdownRequirements
需求
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] — [原因]
**关键决策:**
将提问过程中做出的所有决策进行初始化:
```markdownKey Decisions
关键决策
| Decision | Rationale | Outcome |
|---|---|---|
| [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偏好设置后,检查是否存在远程仓库:
```bashCheck 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'"
fiContinue with .
github.enabled: trueIf "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'"
fiContinue with .
github.enabled: trueIf "Skip for now":
- Set in config.json (override user's earlier selection)
github.enabled: false - Display note: "GitHub tracking disabled — no repository configured. Run to enable later, then update
gh repo create --source=. --public.".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.
| Agent | When it runs | What it does |
|---|---|---|
| Researcher | Before planning each phase | Investigates domain, finds patterns, surfaces gotchas |
| Plan Checker | After plan is created | Verifies plan actually achieves the phase goal |
| Verifier | After phase execution | Confirms 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 with all settings:
.planning/config.jsonjson
{
"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 based on final state (true if remote exists or was created, false if skipped)
github.enabled - Set based on Issue Creation choice:
github.issueMode- "Auto" →
"auto" - "Ask per milestone" →
"ask" - "Never" →
"never"
- "Auto" →
- Display note based on outcome:
- If remote exists/created: "GitHub integration enabled. Milestones will be created via CLI."
gh - If skipped: "GitHub tracking disabled — no repository configured."
- If remote exists/created: "GitHub integration enabled. Milestones will be created via
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 in config.json
commit_docs: false - Add to
.planning/(create if needed).gitignore
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 anytime to update these preferences.
/kata-configure-settingsIf 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.ymlBranch 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/workflowsWrite 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: trueCommit 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.ymlHAS_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.jsonjson
{
"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仓库检查部分)
- 根据最终状态设置(若远程仓库存在或已创建则为true,若跳过则为false)
github.enabled - 根据Issue创建时机的选择设置:
github.issueMode- "自动" →
"auto" - "每个里程碑询问一次" →
"ask" - "从不" →
"never"
- "自动" →
- 根据结果显示提示:
- 若远程仓库存在/已创建:"已启用GitHub集成。将通过CLI创建Milestones。"
gh - 若跳过:"GitHub追踪已禁用 — 未配置仓库。"
- 若远程仓库存在/已创建:"已启用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.ymlSetup Required
所需设置
Add NPM_TOKEN secret to your GitHub repository:
- Go to repo Settings → Secrets and variables → Actions
- Click "New repository secret"
- Name: NPM_TOKEN
- 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仓库:
- 前往仓库设置 → Secrets and variables → Actions
- 点击"New repository secret"
- 名称: NPM_TOKEN
- 值: 你的npm访问令牌(来自npmjs.com → Access Tokens)
当你合并更新了package.json版本的PR时,工作流将自动发布。
**若statusline = 是:**
更新`.claude/settings.json`中的状态栏配置:
```bashEnsure .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:
| Agent | quality | balanced | budget |
|---|---|---|---|
| kata-project-researcher | opus | sonnet | haiku |
| kata-research-synthesizer | sonnet | sonnet | haiku |
| kata-roadmapper | opus | sonnet | sonnet |
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”。
模型查找表:
| 代理 | quality | balanced | budget |
|---|---|---|---|
| kata-project-researcher | opus | sonnet | haiku |
| kata-research-synthesizer | sonnet | sonnet | haiku |
| kata-roadmapper | opus | sonnet | sonnet |
存储解析后的模型,以便后续在需要里程碑调研/路线图制定时用于任务调用。
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
undefinedCheck 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"
fiIf 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]
| Artifact | Location |
|---|---|
| Project | |
| Config | |
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 ► 项目初始化完成 ✓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[项目名称]
| 工件 | 位置 |
|---|---|
| 项目文档 | |
| 配置文件 | |
已准备好进行里程碑规划 ✓
若pr_workflow = 是,追加以下内容:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ 推荐:启用分支保护
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
已启用PR工作流。请保护你的main分支:
https://github.com/{owner}/{repo}/settings/branches
`main`分支的设置:
✓ 合并前需要拉取请求
✓ 不允许绕过上述设置
✗ 允许强制推送(取消勾选)───────────────────────────────────────────────────────────────
▶ Next Up
▶ 下一步
Define your first milestone
/kata-add-milestone<sub> first → fresh context window</sub>
/clear───────────────────────────────────────────────────────────────
</process>
<output>
.planning/PROJECT.md.planning/config.json
<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>先运行 → 刷新上下文窗口</sub>
/clear───────────────────────────────────────────────────────────────
</process>
<output>
.planning/PROJECT.md.planning/config.json
<success_criteria>
- 已创建.planning/目录
- 已创建.planning/phases/pending/、active/、completed/目录
- 已初始化Git仓库
- 已完成遗留项目检测
- 已完成深度提问(跟进对话,不仓促)
- PROJECT.md完整记录了上下文信息 → 已提交
- config.json包含工作流模式、深度、并行设置 → 已提交
- 自我验证通过(所有工件均存在)
- 用户了解下一步是运行
/kata-add-milestone
原子提交: PROJECT.md和config.json已提交。即使上下文丢失,工件仍会保留。
</success_criteria>