Menü
项目配置向导。首次使用或配置未完成时触发。探测项目现状，通过最少的对话完成配置。后续标准在开发中自然积累。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | project-setup |
| description | 项目配置向导。首次使用或配置未完成时触发。探测项目现状，通过最少的对话完成配置。后续标准在开发中自然积累。 |
目标：让用户尽快开始描述需求。配置越少越好，AI 能推断的不问，必须用户决定的才问。 文档是给 AI 跨会话使用的，不是给用户读的。
/project-setup!grep -q "\[项目名称\]" CLAUDE.md 2>/dev/null && echo "CLAUDE.md: ❌ 未配置" || echo "CLAUDE.md: ✅ 已配置"
!grep -q "\[用 2-3 句话" docs/RUBRIC.md 2>/dev/null && echo "RUBRIC.md: ❌ 未配置" || echo "RUBRIC.md: ✅ 已配置"
!grep -q "\[待定义\]" docs/ARCHITECTURE.md 2>/dev/null && echo "ARCHITECTURE.md: ❌ 未配置" || echo "ARCHITECTURE.md: ✅ 已配置"
在问任何问题之前，先从项目中采集能采集的一切：
package.json / pyproject.toml / Cargo.toml / go.mod / pom.xml
→ 推断：项目名称、描述、技术栈、依赖tsconfig.json / .eslintrc* / prettier.config* / Dockerfile
→ 推断：语言版本、代码规范、部署方式ls 项目根目录和 src/ 目录
→ 推断：架构分层如果项目是空的（刚 init 或刚创建），跳过探测，进入阶段二。
AI 基于探测结果形成推荐方案，逐项呈现给用户确认。每一项都是"AI 推荐 + 理由 + 用户是否有别的想法"。
逐项呈现推断和推荐：
项目信息 "从 package.json 看，项目叫 xxx，描述是 yyy。对吗？"
技术栈 "我检测到的技术栈是：前端 Next.js + TypeScript，后端 Next.js API Routes，数据库 Prisma + [PostgreSQL?]，测试未检测到。
- 数据库确认是 PostgreSQL 吗？
- 测试框架你打算用什么？我推荐 Vitest（因为和 Next.js 生态搭配好），你觉得呢？"
架构 "从目录结构和 import 关系，我推断的架构是：
app/ → components/ → lib/services/ → lib/repositories/ → Prisma依赖规则：组件不直接调数据库，业务逻辑在 services 层。 这是你想要的结构吗？还是你有别的分层想法？"
类型共享方式（仅适用于有前后端交互的项目） "你的前后端如何共享类型定义？常见方式有：
- monorepo 共享包（直接 import）
- OpenAPI schema + 代码生成
- tRPC（TypeScript 全栈）
- GraphQL schema
- 手动维护共享类型文件
你已经有方案了吗？还是想听我的建议？"
确认后写入 ARCHITECTURE.md 的"前后端类型契约"部分的
[待定义]。代码标准 "关于代码标准，你有没有：
- 特别想要的技术实践或代码风格？
- 特别讨厌的写法或踩过的坑？ 这些会作为项目的评分标准，指导后续开发方向。没有的话可以先跳过，开发中随时补充。"
每项等用户回答后再问下一项。用户的回答可能修正推断、补充信息、或提出完全不同的方案——都要尊重用户的选择。
项目目标 "你想做什么？"
根据回答，AI 给出完整的技术方案推荐：
技术栈推荐 "基于你的需求，我推荐以下技术栈：
- 前端：[推荐] — [理由]
- 后端：[推荐] — [理由]
- 数据库：[推荐] — [理由]
- 测试：[推荐] — [理由]
如果你有其他偏好（比如已经熟悉某个框架），告诉我，我会基于你的选择调整架构。"
架构推荐 "基于 [技术栈] 和你的需求规模，我推荐的架构是：
- [分层方案] — [理由]
- [关键依赖规则] — [理由]
你觉得这个方案怎么样？还是有别的想法？"
有多个合理选择时（如 Next.js vs Remix，monolith vs microservice），列出各选项的优劣对比，让用户选。AI 可以表达推荐倾向，但不替用户决定。
代码标准 "你对代码风格有什么偏好吗？比如：
- 函数式还是面向对象？
- 有没有特别讨厌的写法？ 没有的话先跳过，开发过程中随时告诉我。"
所有项讨论完后，汇总一份总览给用户最终确认：
"总结一下我们确定的方案：
- 项目：[名称] — [描述]
- 技术栈：[前端] / [后端] / [数据库] / [测试]
- 架构：[分层概述]
- 关键规则：[1-2 条最重要的约束]
- 代码标准：[已确认的惩罚/奖励项，或"后续积累"]
确认后我就写入配置，可以开始做第一个功能了。有要改的吗？"
用户确认后进入写入阶段。如果用户要改，当场改对应项，不重跑整个流程。
用 Edit 工具精确替换占位符，不要重写整个文件。
[项目名称] 和 [一句话描述]根据确认的技术栈，在 .claude/settings.json 的 PostToolUse hooks 中追加 lint/类型检查命令。示例：
npx tsc --noEmit 2>&1 | head -20; npx eslint --quiet "$FILEPATH" 2>/dev/null; exit 0ruff check "$FILEPATH" 2>/dev/null; exit 0go vet ./... 2>&1 | head -20; exit 0cargo check 2>&1 | head -20; exit 0matcher 设为 Write|Edit|MultiEdit（和 prettier hook 同组）。exit 0（提醒模式）或 exit 2（阻断模式），推荐用 exit 0 避免开发中频繁阻断。
如果用户不确定用什么 lint 工具，根据技术栈推荐最主流的选择。
剂量轻：起步只落愿景 + 需求单表两个种子（setup.sh 已铺），L3-L6 随真实开发自然长，不预填空壳。
L1-vision；还没定的功能留一行 待定，不强行凑。[待填]/待定 即可，开发中再补 —— 与 RUBRIC 渐进式积累同基调，不在配置阶段逼用户填满。[ ] : ,（全角会被 check-context-chain.sh 机读静默漏）。写入后读回每个文件，确认：
[待定义]、[项目名称]、[一句话描述] 等占位符（docs/context/ 的 [待填]/待定 是探索期合法状态，不算残留，不阻断配置完成）"配置完成。告诉我你想做的第一个功能吧。"
配置向导只生成 RUBRIC 的基础框架。后续标准通过以下方式自然积累：
触发条件：用户说了类似"不要这样"、"以后都这样做"、"这个方向对"等反馈时，AI 判断是否值得写入 RUBRIC，值得就写入并告知用户"我把这个记到了项目标准里"。
结构化交接+晋升门禁。上下文快满或 finishing 阶段触发。覆写 handoff.md 的唯一正路:归档→清账(待晋升暂存逐条裁决:上架/弃置/顺延/阻塞)→按模板单源覆写→自查。
代码审查。一批代码改动完成后触发。ultracode/Workflow 在场时走 review-scout(reviewType='code',scout 现推维:code 地板 3 维 + 动态加);否则回落 Superpowers requesting-code-review(either-or,不叠加,不改 Superpowers 包)。
设计审查。系统设计完成后触发。扁平 fork 4 个独立挑战者从自洽性、完整性、合理性、RUBRIC 对齐四个维度审查设计文档。
方向评估。当 Superpowers 的 finishing-a-development-branch 完成、功能分支准备合并时自动触发。判断方向是否正确、是否需要推翻。
流程审计。finishing 阶段 evaluate 之后、分流之前触发。扁平 fork 1 个独立挑战者审计 AI 对流程的遵从度,记录到 docs/audits/,不自动优化。
提交前安全扫描。finishing 阶段 evaluate 之前触发。扁平 fork 3 个独立挑战者扫描 git diff,检测凭证泄露、危险操作、prompt 注入、数据外泄风险。