企业官网建设流程全解析

Current Position

【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done

Phase: Not started (defining requirements) Plan: — Status: Defining requirements Last activity: [today] — Milestone v[X.Y] started

工作流文档明确要求：**不要手工编辑 STATE.md**，必须走 SDK 处理器。 ## Step 6–7：清理提交与加载运行时上下文 ### 清理与提交 - 删除已消费的 `MILESTONE-CONTEXT.md`（若存在）； - 清空上一里程碑遗留的阶段目录： ```bash gsd-sdk query phases.clear --confirm

phasesClear处理器位于 sdk/src/query/phase-lifecycle.ts#L1678-L1715：它会删除除999.x之外的 backlog 阶段目录，且必须带--confirm，否则抛出校验错误（"Pass --confirm to proceed"）——这是一道防误删的安全闸门。

• 提交规划文档：

gsd-sdk query commit "docs: start milestone v[X.Y] [Name]" --files .planning/PROJECT.md .planning/STATE.md

加载初始化上下文与模型

INIT=$(gsd-sdk query init.new-milestone) if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi AGENT_SKILLS_RESEARCHER=$(gsd-sdk query agent-skills gsd-project-researcher) AGENT_SKILLS_SYNTHESIZER=$(gsd-sdk query agent-skills gsd-research-synthesizer) AGENT_SKILLS_ROADMAPPER=$(gsd-sdk query agent-skills gsd-roadmapper)

从 init JSON 中提取的关键字段（TS 实现见 sdk/src/query/init.ts#L613-L670，CJS 平行实现见 get-shit-done/bin/lib/init.cjs#L563-L607）：

特别值得注意phase_dir_count的语义：SDK 与 CJS 两侧都按里程碑过滤阶段目录（getMilestonePhaseFilter），避免上一里程碑未归档的残留目录虚增计数、进而误判 "fresh start"（注释中明确标注了 bug #2445）。

如果agents_installed为false，工作流会显示警告并列出缺失的代理，提示npx get-shit-done-cc@latest --global安装，然后跳过并行研究、内联生成路线图——这是一个优雅降级路径。

Step 7.5：--reset-phase-numbers的安全护栏

仅当显式传入--reset-phase-numbers时生效：

1. 将新路线图的起始阶段编号设为1；
2. 若phase_dir_count > 0，先把旧阶段目录归档，避免新01-*/02-*目录与残留里程碑目录冲突：

mkdir -p "${phase_archive_path}" find .planning/phases -mindepth 1 -maxdepth 1 -type d -exec mv {} "${phase_archive_path}/" \;

归档后需验证.planning/phases/不再包含旧目录。若phase_dir_count > 0但phase_archive_path缺失（即没有已完成的里程碑归档目标），工作流会停止并解释：重置编号在不具备归档目标时不安全，需先完成/归档上一里程碑，再重跑/gsd:new-milestone --reset-phase-numbers ${GSD_WS}。

Step 8：研究决策与四路并行研究

决策分支

research_enabled来自 init JSON（即config.workflow.research）。工作流根据默认值调整 AskUserQuestion 的选项顺序：

• 默认开启：推荐 "Research first (Recommended)"，可 "Skip research for this milestone"；
• 默认关闭：推荐 "Skip research (current default)"，可临时 "Research first"。

一个关键约束被文档显式强调：不要把本次选择持久化到 config.json。workflow.research是跨项目、控制plan-phase行为的持久用户偏好，在这里修改会静默改变未来的/gsd:plan-phase行为；要改默认值应走/gsd:settings。

四路并行研究

选择 "Research first" 后，工作流建立.planning/research/目录，并行派生 4 个gsd-project-researcher子代理，每个代理使用统一模板（含<research_type>、<milestone_context>、<question>、<files_to_read>、${AGENT_SKILLS_RESEARCHER}、<downstream_consumer>、<quality_gate>、<output>等占位），但按维度填充不同字段：

每个代理以subagent_type="gsd-project-researcher"、model="{researcher_model}"派生，产物模板位于~/.claude/get-shit-done/templates/research-project/{FILE}。

文档在此嵌入两条CODEX 运行时编排规则：派生 4 个研究代理后不得自行读取研究文件或独立综合（防止重复劳动浪费上下文），必须等 4 个代理全部完成后才派生合成器；合成器（gsd-research-synthesizer）读取四份研究文件，产出SUMMARY.md并提交，随后工作流展示要点摘要（Stack additions / Feature table stakes / Watch Out For）。

Step 9：定义带 REQ-ID 的规格化需求

进入 "DEFINING REQUIREMENTS" 阶段后：

1. 读取PROJECT.md的 core value、当前里程碑目标、已验证需求；
2. 若$SELECTED_SEEDS非空，将种子想法及其 "Why This Matters" 并入需求定义输入；
3. 若有研究产物，读取FEATURES.md并按类别呈现（Table stakes / Differentiators / Research notes）；若无研究，则通过对话收集需求（"What are the main things users need to do with [new features]?"）；
4. 对每个类别用AskUserQuestion（multiSelect: true，header 不超过 12 字符）进行范围圈定，选项含 "None for this milestone"（推迟整个类别）；
5. 通过 AskUserQuestion 检查缺口（"No, research covered it" / "Yes, let me add some"）。

随后生成REQUIREMENTS.md：

• 按类别分组的 v1 需求（复选框 + REQ-ID）
• Future Requirements（推迟项）
• Out of Scope（显式排除及理由）
• Traceability 章节（空，由路线图填充）

REQ-ID 格式为[CATEGORY]-[NUMBER]（如AUTH-01、NOTIF-02），并延续既有编号。文档给出四条需求质量准则：具体可测（"User can reset password via email link" 而非 "Handle password reset"）、用户视角（"User can X" 而非 "System does Y"）、原子性（一条需求一个能力）、独立性（需求间依赖最小）。

完整需求列表须向用户确认（yes / adjust，adjust 则回到范围圈定循环），确认后提交：

gsd-sdk query commit "docs: define milestone v[X.Y] requirements" --files .planning/REQUIREMENTS.md

Step 10：派生 roadmapper 生成分阶段路线图

起始阶段编号

• --reset-phase-numbers激活 → 从Phase 1开始；
• 默认 → 延续上一里程碑的最后阶段编号（v1.0 结束于 phase 5，则 v1.1 从 phase 6 开始）。

子代理契约

roadmapper 子代理（gsd-roadmapper）接收<planning_context>（读取PROJECT.md、REQUIREMENTS.md、research/SUMMARY.md（若存在）、config.json、MILESTONES.md）与 7 条明确指令：

1. 尊重所选编号模式（reset 或延续）；
2. 仅从本里程碑的需求推导阶段；
3. 每条需求精确映射到一个阶段；
4. 每阶段推导 2–5 条成功标准（可观察的用户行为）；
5. 校验 100% 覆盖；
6. 立即写文件（ROADMAP.md、STATE.md，更新REQUIREMENTS.md的可追溯性）；
7. 返回ROADMAP CREATED及摘要。

文档同样嵌入 CODEX 编排规则：派生后立即停止本任务工作，等待子代理返回结果。

返回处理与审批

• ## ROADMAP BLOCKED：展示阻塞点，与用户协作后重新派生；
• ## ROADMAP CREATED：读取并内联展示提案路线图：

## Proposed Roadmap **[N] phases** | **[X] requirements mapped** | All covered ✓ | # | Phase | Goal | Requirements | Success Criteria | |---|-------|------|--------------|------------------| | [N] | [Name] | [Goal] | [REQ-IDs] | [count] |

并通过 AskUserQuestion 提供三选一审批："Approve"（提交并继续）、"Adjust phases"（收集修改意见、带修订上下文重派生、循环至批准）、"Review full file"（展示原始ROADMAP.md后重新询问）。批准后提交：

gsd-sdk query commit "docs: create milestone v[X.Y] roadmap ([N] phases)" --files .planning/ROADMAP.md .planning/STATE.md .planning/REQUIREMENTS.md

Step 10.5：待办事项与路线图阶段的关联

路线图批准后，扫描待办事项并打上resolves_phase标签：

PENDING_TODOS=$(ls .planning/todos/pending/*.md 2>/dev/null | head -50)

无待办则静默跳过。否则将每个待办的title/areafrontmatter 字段及正文（Problem 与 Solution）与各阶段的 goal、REQ-ID、描述做尽力而为的匹配（文档强调"不要过度匹配"：窄范围、具体 scope 的待办是最佳候选，模糊或横切待办保持不关联）。匹配成功的待办在 YAML frontmatter 中追加resolves_phase: [N]：

--- created: [existing] title: [existing] area: [existing] resolves_phase: [N] files: [existing] ---

只修改有明确自信匹配的待办；匹配后提交：

gsd-sdk query commit "docs: tag [count] pending todos with resolves_phase after milestone v[X.Y] roadmap" --files .planning/todos/pending/*.md

【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done