Menu
执行 /craft 时必读。提供 Workflow / Skill / Prompt 骨架与质量护栏。以判断准绳替代堆砌步骤。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
当用户在 skills-only 环境中需要判断应该从哪个 anws 工作流开始，或需要在 forge / change / genesis / probe / blueprint / challenge / upgrade 之间路由时使用。它是 anws 工作流集合的导航入口。
纯静态「契约忠实度 / 实现侧证据」审查：对照 PRD、ADR、系统设计、05A_TASKS 与 05B_VERIFICATION_PLAN，围绕契约闭合、任务兑现、架构健康、安全边界、验证证据与回流一致性产出可追溯结论；供 /challenge（CODE/FULL）与 /forge（Step 3 §3.6 波末）共用。
当用户需求模糊、术语不清晰时使用。通过交互式追问澄清领域概念，提取实体、流程与暗物质（missing_components）。由 **`/genesis` Step 1** 在 Step 0 已确定 `TARGET_DIR = .anws/v{N}` 后调用；与 **同工作区 `/genesis`** 连用。
当 `/challenge` 需要设计侧规范契约闭合证据（架构与系统设计文档三维审查）时加载；产出可锚点、按严重度分级的发现供纳入 07_CHALLENGE_REPORT，不作脱离 challenge 上下文的终局裁决。
规定面向真人的 E2E / 手动验证《测试指南》与《E2E Verification》报告骨架（PRD 可追溯、人机走查顺序、评测列仅能 PASS/PARTIAL_PASS/FAIL）；**不含实机浏览器编排**——先后顺序与回填义务由宿主 **`/forge` §3.7**（及 `/forge` 对应条文）统一写死。
Generate a persistent .nexus-map/ knowledge base that lets any AI session instantly understand a codebase's architecture, systems, dependencies, and change hotspots. Use when starting work on an unfamiliar repository, onboarding with AI-assisted context, preparing for a major refactoring initiative, or enabling reliable cold-start AI sessions across a team. Produces INDEX.md, systems.md, concept_model.json, git_forensics.md and more. Requires shell execution and Python 3.10+. For ad-hoc file queries or instant impact analysis during active development, use nexus-query instead.
| name | craft-authoring |
| description | 执行 /craft 时必读。提供 Workflow / Skill / Prompt 骨架与质量护栏。以判断准绳替代堆砌步骤。 |
本 skill 承接 /craft 中“如何写成”的细节。
/craft 给方向，这里给落地。方向如果没有落地，会变成口号；落地如果没有方向，会变成机械动作。
判断准绳：
与
output-contract的分工：本节只定义 Workflow / Skill / Prompt 撰写脚手架；持久化报告的共用 spec、父子委派与单写者规则见.agents/skills/output-contract/SKILL.md。
与 CLI 安装清单的分工：哪些路径会随anws init复制、registry 与BUNDLE_POLICY边界见references/BUNDLE_POLICY.md。
---
description: [一句话说明用途]
---
# /name
<phase_context>
你是 **[角色]**。
**使命**：...
**能力**：...
**限制**：...
**与用户的关系**：...
**Output Goal**: `路径`
</phase_context>
---
## CRITICAL 写作约束
> [!IMPORTANT]
> 写作约束由 `/craft` 主 workflow 统一定义，此处不重复展开。
---
## Step 1: [标题]
### 做什么
...
### 为什么
...
### 怎么验收
- ...
- ...
---
<completion_criteria>
- [可验证完成标准]
</completion_criteria>
---
name: kebab-name
description: 当 [具体触发场景] 时加载。[能力概括]
---
# 标题
## 做什么
...
## 为什么
...
## 怎么验收
- 输入契约：...
- 输出契约：...
description 忌：泛化能力标签。
description 宜：明确触发场景与边界。
判断准绳：
一个好的 description 像门禁，不像标语。
它要决定“何时进入”，也要决定“何时不进入”。
# 标题
## 做什么
...
## 为什么
...
## 怎么验收
- 约束：...
- 输出格式：...
| 机制 | 用途 |
|---|---|
[!IMPORTANT] | 不可跳过节点 |
## CRITICAL | 边界醒目 |
你**必须** | 强制动作 |
<completion_criteria> | 完成定义 |
重要约束至少写清：做什么、为什么、偏航信号。
用 sequential-thinking 组织 3-5 个 thought，覆盖目标、易错点、每步 I/O、调研结论落点。
质量快检：
判断准绳：
如果一个段落不能告诉执行者“该做什么”，它就是噪声。
如果一个段落不能告诉执行者“为何如此”，它就是命令。
如果一个段落不能告诉执行者“如何验证”，它就是祈祷。
结构：
phase_context（workflow 场景）CRITICAL 块<completion_criteria>内容：
发布前必须执行静态评分：
references/PROMPT_QUALITY_RUBRIC.mdreferences/SCORECARD_TEMPLATE.md 对应的评分卡硬门规则：
Infeasible用 sequential-thinking 做 3-5 个 thought：
最后问自己一句：
如果这份文档真的会被反复执行，你敢不敢为它的后果负责？