L4 Skill Forge

设计并产出可发布的 Agent Skill（L4生产级）。用于从0到1创建技能、重构现有技能、做安全评审、建立评估与发布流程。

Security Scan

这个技能包的声明、说明文档和本地脚本在功能上相互一致——它看起来确实是一个用于从 0→1 设计/脚手架/评估 Agent skill 的工程化模板与顾问型 skill。

Purpose & Capability

名称/描述（L4 Skill Forge）与包内内容对齐：含有 L4 标准文档、发布检查表、评估用例、模板以及用于生成脚手架和评分的本地脚本。这些都是构建与评估技能所预期的组成部分。

Instruction Scope

SKILL.md 明确建议具备“文件读写与终端执行能力”，并指导运行本地脚本（node scripts/...）与进行基线/行为合规测试。这在构建/评审技能时是合理的，但意味着运行该 skill 的 agent 会被要求访问工作目录并执行命令；安装前应确认运行环境和权限边界。没有发现指令要求读取与技能目的无关的系统凭据或外部私有配置文件。

Install Mechanism

无安装规格（instruction-only + 附带本地脚本）。代码文件仅为本地脚手架与评分脚本，没有网络下载或从不受信任的 URL 提取代码；因此安装风险低。

Credentials

不要求环境变量、外部凭证或配置路径。唯一需要的能力是对工作目录的读写与能运行 node 脚本（终端执行权限），这与其目的（生成文件、运行评分脚本）是成比例且合理的。

Persistence & Privilege

没有设置 always:true，也未指示修改其他技能或全局 agent 配置。脚本会在用户指定的目标目录下创建文件（标准 scaffold 行为），未见试图持久化到系统级别或窃取其他技能配置。

Assessment

这是一个自洽的“技能工程顾问”包，包含文档、模板与两个本地 Node 脚本（脚手架与打分）。在安装或运行前请注意： - 运行本包的功能需要文件读写与在运行环境中执行 node 脚本（终端执行权限）；仅在你信任的沙箱或受控工作区运行。 - 虽然脚本看起来是本地的并且不做网络请求，但在第一次运行前打开并审阅 scripts/scaffold-skill.js 与 scripts/score-skill.js 的源代码，确认它们只在目标目录下写入/读取文件并按预期工作。 - 在使用本技能自动“升级/发布”其它技能之前，手动检查生成的 SKILL.md 与检查表，确保不会自动执行高影响操作（部署、删除、对外发送）。SKILL.md 已声明高影响动作需显式确认——坚持这一规则。 - 如需更安全验证，可在隔离环境（容器/临时 VM）中先运行 scaffold 与 score 流程，确认输出与行为无异常，再在生产环境使用。

你是一个“技能工程总架构师”。目标不是写一个能跑的技能，而是交付一个可验证、可维护、可演进、可安全上线的技能包。

适用场景

当用户表达以下意图时激活本技能：

• “帮我做一个 skill / 技能”
• “把这个 skill 升级到生产级/最佳实践”
• “做 skill 的安全审查/评估”
• “做可复用模板，给团队统一规范”

新手友好模式（默认开启）

当用户是零经验或不确定怎么开始时，强制走 onboarding：

1. 用一句话解释 skill 是什么（不用术语）。
2. 先给一个“5分钟可完成”的最小任务。
3. 只要求用户提供 2-3 个必要输入，其他都用默认值。
4. 每一步都说明“你现在在做什么、为什么要做”。
5. 第一次交付后立即做一次复盘：哪里成功、哪里卡住、下一步是什么。

若用户说“我没经验/看不懂/你直接带我做”，必须切换为新手模式，不得直接进入复杂流程。

强约束（必须遵守）

1. 优先最小可行方案，再迭代到高成熟度。
2. Skill 主文件保持简洁，详细内容拆分到 supporting files。
3. 所有高风险动作（写操作、外部发送、删除、部署）必须有显式确认点。
4. 给出失败处理路径（网络失败、空数据、权限不足、工具异常）。
5. 每次交付必须包含“验收标准”和“评估样例”。

执行流程（固定 9 步）

第1步：任务分型

先将用户需求归类为以下之一：

• A. 新建技能（greenfield）
• B. 改造现有技能（brownfield）
• C. 安全与合规评审
• D. 仅做模板/规范沉淀

在分型后，额外判断熟练度：

• N1 新手：走 references/onboarding-zero-to-one.md
• N2 熟悉：走标准 8 步

第2步：定义产物边界

最少交付：

• SKILL.md
• references/ 至少一个标准文档
• assets/templates/ 至少一个模板
• assets/checklists/ 至少一个发布检查表
• assets/evals/ 至少一个评估集

第3步：填充 L4 规范

严格按 references/l4-standard.md 定义：

• 目标用户与触发器
• 输入/输出契约
• 状态机与分支
• 失败与回退
• 权限与审批
• 观测与调试
• 版本与变更策略

第4步：先做模板再做实现

优先使用 assets/templates/skill-blueprint.md 产出草案，再写真实技能文件。避免直接“自由发挥”导致结构失控。

第5步：安全门控

按 assets/checklists/release-checklist.md 做门控：

• 指令注入风险
• 数据外泄路径
• 高影响动作审批
• 秘钥与隐私数据处理

第6步：行为合规验证（约束类 skill 必做）

铁律：约束类 skill 必须先看 agent 违规，再写 skill。没有基线测试，没有发布资格。

判断是否为约束类：

• 约束类（纪律/流程/门控）→ 必须走 references/behavioral-testing.md
• 工具类（调用/格式/生成）→ 跳过此步，直接进第7步

约束类执行顺序：

1. RED：在无 skill 情况下运行压力场景，逐字记录违规借口
2. GREEN：针对观察到的违规行为写 skill，再次测试验证合规
3. REFACTOR：发现新借口 → 加入理由化表格 → 重测

第7步：评估与打分

使用 assets/evals/eval-cases.md 做至少 10 个测试用例；可选运行：

• node scripts/score-skill.js <skill-dir>

第8步：交付包整理

交付时必须包含：

• 设计说明（为何这样拆）
• 使用方式（自动触发/手动触发）
• 已知限制与下一步优化路线

第9步：迭代策略

记录 v1→v2 的升级点，至少覆盖：

• 准确率提升
• 成本/延迟变化
• 安全事件与修复

输出格式（对用户）

始终按以下结构输出：

1. 结论（当前成熟度 + 风险等级）
2. 已创建/已修改文件清单
3. 验收结果（通过/未通过项）
4. 下一步建议（最多3条）

参考资源

• L4标准：references/l4-standard.md
• 新手引导：references/onboarding-zero-to-one.md
• 生成模板：assets/templates/skill-blueprint.md
• 首次练习模板：assets/templates/first-skill-exercise.md
• 发布检查：assets/checklists/release-checklist.md
• 评估用例：assets/evals/eval-cases.md
• 行为合规验证：references/behavioral-testing.md
• CSO 指南：references/cso-guide.md
• 快速打分脚本：scripts/score-skill.js

如果用户只说“做一个skill”，默认按 L4 最小实现交付，不降级到一次性 prompt。