ワンクリックでManusで任意のスキルを実行

始める

craft-authoring

スター141

フォーク23

更新日2026年5月15日 03:03

执行 /craft 时必读。提供 Workflow / Skill / Prompt 骨架与质量护栏。以判断准绳替代堆砌步骤。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

Haaaiawd

Haaaiawd/ANWS

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Craft Authoring - 脚手架与自检

本 skill 承接 /craft 中“如何写成”的细节。
/craft 给方向，这里给落地。方向如果没有落地，会变成口号；落地如果没有方向，会变成机械动作。

全局写作协议

禁止使用 emoji。
允许拟人叙事，但语气必须克制、理性、专业。
使用短句，每句表达单一语义。
每个 Step 固定回答：做什么 / 为什么 / 怎么验收。
先给意义，再给规则，再给验证。禁止只写漂亮话。

判断准绳：

好文档让执行者更清醒、更稳定、更可复现。
坏文档让执行者更兴奋，却更依赖临场发挥。

与 output-contract 的分工：本节只定义 Workflow / Skill / Prompt 撰写脚手架；持久化报告的共用 spec、父子委派与单写者规则见 .agents/skills/output-contract/SKILL.md。
与 CLI 安装清单的分工：哪些路径会随 anws init 复制、registry 与 BUNDLE_POLICY 边界见 references/BUNDLE_POLICY.md。

Workflow 骨架（最小可用）

---
description: [一句话说明用途]
---

# /name

<phase_context>
你是 **[角色]**。
**使命**：...
**能力**：...
**限制**：...
**与用户的关系**：...
**Output Goal**: `路径`
</phase_context>

---

## CRITICAL 写作约束

> [!IMPORTANT]
> 写作约束由 `/craft` 主 workflow 统一定义，此处不重复展开。

---

## Step 1: [标题]

### 做什么
...

### 为什么
...

### 怎么验收
- ...
- ...

---

<completion_criteria>
- [可验证完成标准]
</completion_criteria>

Skill 骨架（description 必须是触发条件）

---
name: kebab-name
description: 当 [具体触发场景] 时加载。[能力概括]
---

# 标题

## 做什么
...

## 为什么
...

## 怎么验收
- 输入契约：...
- 输出契约：...

description 忌：泛化能力标签。
description 宜：明确触发场景与边界。

判断准绳：
一个好的 description 像门禁，不像标语。
它要决定“何时进入”，也要决定“何时不进入”。

Prompt 骨架

# 标题

## 做什么
...

## 为什么
...

## 怎么验收
- 约束：...
- 输出格式：...

防护语法速查

机制	用途
`[!IMPORTANT]`	不可跳过节点
`## CRITICAL`	边界醒目
`你必须`	强制动作
`<completion_criteria>`	完成定义

重要约束至少写清：做什么、为什么、偏航信号。

填充内容（Step 5 等价）

用 sequential-thinking 组织 3-5 个 thought，覆盖目标、易错点、每步 I/O、调研结论落点。

质量快检：

章节是否单问题回答
约束是否写明为什么
输出是否可验证

判断准绳：
如果一个段落不能告诉执行者“该做什么”，它就是噪声。
如果一个段落不能告诉执行者“为何如此”，它就是命令。
如果一个段落不能告诉执行者“如何验证”，它就是祈祷。

验证清单（输出前）

结构：

frontmatter
phase_context（workflow 场景）
CRITICAL 块
<completion_criteria>

内容：

路径与命名正确
触发条件清晰
输入输出契约完整
失败信号可被外部观察

评分闸门（发布前）

发布前必须执行静态评分：

读取 references/PROMPT_QUALITY_RUBRIC.md
生成 references/SCORECARD_TEMPLATE.md 对应的评分卡
输出 Tier（T0/T1/T2/T3）与七维加权得分

硬门规则：

若触发 Hard Fail Gate，结论必须为 Infeasible
若未触发 Hard Fail 且总分 < 4.0，必须回炉一次再评分

自我批评（输出前最后一道）

用 sequential-thinking 做 3-5 个 thought：

用户会卡在哪一步
AI 可能跳过哪条约束
哪一节仍存在多问题混写
修复后再交付

最后问自己一句：
如果这份文档真的会被反复执行，你敢不敢为它的后果负责？

このリポジトリの他の Skills

同じリポジトリ

anws-system

Haaaiawd/ANWS

当用户在 skills-only 环境中需要判断应该从哪个 anws 工作流开始，或需要在 forge / change / genesis / probe / blueprint / challenge / upgrade 之间路由时使用。它是 anws 工作流集合的导航入口。

2026-05-15141

code-reviewer

Haaaiawd/ANWS

纯静态「契约忠实度 / 实现侧证据」审查：对照 PRD、ADR、系统设计、05A_TASKS 与 05B_VERIFICATION_PLAN，围绕契约闭合、任务兑现、架构健康、安全边界、验证证据与回流一致性产出可追溯结论；供 /challenge（CODE/FULL）与 /forge（Step 3 §3.6 波末）共用。

2026-05-15141

concept-modeler

Haaaiawd/ANWS

当用户需求模糊、术语不清晰时使用。通过交互式追问澄清领域概念，提取实体、流程与暗物质（missing_components）。由 **`/genesis` Step 1** 在 Step 0 已确定 `TARGET_DIR = .anws/v{N}` 后调用；与 **同工作区 `/genesis`** 连用。

2026-05-15141

design-reviewer

Haaaiawd/ANWS

当 `/challenge` 需要设计侧规范契约闭合证据（架构与系统设计文档三维审查）时加载；产出可锚点、按严重度分级的发现供纳入 07_CHALLENGE_REPORT，不作脱离 challenge 上下文的终局裁决。

2026-05-15141

e2e-testing-guide

Haaaiawd/ANWS

规定面向真人的 E2E / 手动验证《测试指南》与《E2E Verification》报告骨架（PRD 可追溯、人机走查顺序、评测列仅能 PASS/PARTIAL_PASS/FAIL）；**不含实机浏览器编排**——先后顺序与回填义务由宿主 **`/forge` §3.7**（及 `/forge` 对应条文）统一写死。

2026-05-15141

nexus-mapper

Haaaiawd/ANWS

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.

2026-05-15141

name	craft-authoring
description	执行 /craft 时必读。提供 Workflow / Skill / Prompt 骨架与质量护栏。以判断准绳替代堆砌步骤。

Craft Authoring - 脚手架与自检

本 skill 承接 /craft 中“如何写成”的细节。
/craft 给方向，这里给落地。方向如果没有落地，会变成口号；落地如果没有方向，会变成机械动作。

全局写作协议

禁止使用 emoji。
允许拟人叙事，但语气必须克制、理性、专业。
使用短句，每句表达单一语义。
每个 Step 固定回答：做什么 / 为什么 / 怎么验收。
先给意义，再给规则，再给验证。禁止只写漂亮话。

判断准绳：

好文档让执行者更清醒、更稳定、更可复现。
坏文档让执行者更兴奋，却更依赖临场发挥。

与 output-contract 的分工：本节只定义 Workflow / Skill / Prompt 撰写脚手架；持久化报告的共用 spec、父子委派与单写者规则见 .agents/skills/output-contract/SKILL.md。
与 CLI 安装清单的分工：哪些路径会随 anws init 复制、registry 与 BUNDLE_POLICY 边界见 references/BUNDLE_POLICY.md。

Workflow 骨架（最小可用）

---
description: [一句话说明用途]
---

# /name

<phase_context>
你是 **[角色]**。
**使命**：...
**能力**：...
**限制**：...
**与用户的关系**：...
**Output Goal**: `路径`
</phase_context>

---

## CRITICAL 写作约束

> [!IMPORTANT]
> 写作约束由 `/craft` 主 workflow 统一定义，此处不重复展开。

---

## Step 1: [标题]

### 做什么
...

### 为什么
...

### 怎么验收
- ...
- ...

---

<completion_criteria>
- [可验证完成标准]
</completion_criteria>

Skill 骨架（description 必须是触发条件）

---
name: kebab-name
description: 当 [具体触发场景] 时加载。[能力概括]
---

# 标题

## 做什么
...

## 为什么
...

## 怎么验收
- 输入契约：...
- 输出契约：...

description 忌：泛化能力标签。
description 宜：明确触发场景与边界。

判断准绳：
一个好的 description 像门禁，不像标语。
它要决定“何时进入”，也要决定“何时不进入”。

Prompt 骨架

# 标题

## 做什么
...

## 为什么
...

## 怎么验收
- 约束：...
- 输出格式：...

防护语法速查

机制	用途
`[!IMPORTANT]`	不可跳过节点
`## CRITICAL`	边界醒目
`你必须`	强制动作
`<completion_criteria>`	完成定义

重要约束至少写清：做什么、为什么、偏航信号。

填充内容（Step 5 等价）

用 sequential-thinking 组织 3-5 个 thought，覆盖目标、易错点、每步 I/O、调研结论落点。

质量快检：

章节是否单问题回答
约束是否写明为什么
输出是否可验证

验证清单（输出前）

结构：

frontmatter
phase_context（workflow 场景）
CRITICAL 块
<completion_criteria>

内容：

路径与命名正确
触发条件清晰
输入输出契约完整
失败信号可被外部观察

评分闸门（发布前）

发布前必须执行静态评分：

读取 references/PROMPT_QUALITY_RUBRIC.md
生成 references/SCORECARD_TEMPLATE.md 对应的评分卡
输出 Tier（T0/T1/T2/T3）与七维加权得分

硬门规则：

若触发 Hard Fail Gate，结论必须为 Infeasible
若未触发 Hard Fail 且总分 < 4.0，必须回炉一次再评分

自我批评（输出前最后一道）

用 sequential-thinking 做 3-5 个 thought：

用户会卡在哪一步
AI 可能跳过哪条约束
哪一节仍存在多问题混写
修复后再交付

最后问自己一句：
如果这份文档真的会被反复执行，你敢不敢为它的后果负责？