원클릭으로
원클릭으로
当用户在 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:
最后问自己一句:
如果这份文档真的会被反复执行,你敢不敢为它的后果负责?