القائمة
执行 /craft 时必读。提供 Workflow / Skill / Prompt 骨架与质量护栏。以判断准绳替代堆砌步骤。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
当用户在 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：
最后问自己一句：
如果这份文档真的会被反复执行，你敢不敢为它的后果负责？