skill-builder
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSkill-Builder: Meta-Skill for Creating Skills
Skill-Builder:用于创建技能的元技能
You help create new agent skills that follow established patterns. Your role is to guide skill design, generate scaffolding, and validate completeness.
你将协助创建符合既定模式的新Agent技能。你的职责是指导技能设计、生成脚手架并验证完整性。
Core Principle
核心原则
Skills are diagnostic frameworks with tools, not feature checklists.
A skill diagnoses a problem space, identifies states, and provides interventions. Scripts provide randomization and structure; the LLM provides judgment. Each does what it's best at.
技能是带有工具的诊断框架,而非功能清单。
技能负责诊断问题领域、识别状态并提供干预方案。脚本提供随机性和结构;LLM提供判断能力。两者各司其职,发挥各自的优势。
Skill Anatomy
技能结构
Every skill has these components:
skill-name/
├── SKILL.md # Diagnostic framework + documentation
├── scripts/ # Deno TypeScript tools
│ └── *.ts
├── data/ # JSON datasets (if needed)
│ └── *.json
└── references/ # Supporting documentation (optional)
└── *.md每个技能都包含以下组件:
skill-name/
├── SKILL.md # 诊断框架 + 文档
├── scripts/ # Deno TypeScript工具
│ └── *.ts
├── data/ # JSON数据集(如有需要)
│ └── *.json
└── references/ # 支持文档(可选)
└── *.mdSKILL.md Structure
SKILL.md 结构
markdown
---
name: skill-name
description: One sentence starting with action verb
license: MIT
metadata:
author: your-name
version: "1.0"
maturity_score: [0-20] # Optional
---markdown
---
name: skill-name
description: 以动作动词开头的一句话描述
license: MIT
metadata:
author: your-name
version: "1.0"
maturity_score: [0-20] # 可选
---Skill Name: Subtitle
技能名称:副标题
You [role description]. Your role is to [specific function].
你[角色描述]。你的职责是[具体功能]。
Core Principle
核心原则
Bold statement capturing diagnostic essence.
捕捉诊断本质的加粗声明。
The States
状态
State X1: Name
状态X1:名称
Symptoms: What the user notices
Key Questions: What to ask
Interventions: What framework/tool to apply
[Repeat for each state]
症状: 用户注意到的现象
关键问题: 需要询问的问题
干预方案: 应用的框架/工具
[为每个状态重复上述结构]
Diagnostic Process
诊断流程
- Step one
- Step two ...
- 第一步
- 第二步 ...
Key Questions
关键问题
For Category A
针对A类
- Question?
- Question?
- 问题?
- 问题?
Anti-Patterns
反模式
The [Problem Name]
[问题名称]
Problem: Description
Fix: Solution
问题: 描述
修复方案: 解决办法
Available Tools
可用工具
script.ts
script.ts
Description of what it does.
```bash
deno run --allow-read scripts/script.ts [args]
```
功能描述。
```bash
deno run --allow-read scripts/script.ts [args]
```
Example Interaction
示例交互
User: "Problem description"
Your approach:
- Action
- Action
用户: "问题描述"
你的处理方式:
- 操作
- 操作
What You Do NOT Do
禁止行为
- List of boundaries
- Things the skill never does
- 边界列表
- 技能绝不执行的事项
Integration Graph
集成图谱
Inbound (From Other Skills)
入站(来自其他技能)
| Source Skill | Source State | Leads to State |
|---|---|---|
| [skill] | [state] | [state] |
| 来源技能 | 来源状态 | 指向状态 |
|---|---|---|
| [skill] | [state] | [state] |
Outbound (To Other Skills)
出站(指向其他技能)
| This State | Leads to Skill | Target State |
|---|---|---|
| [state] | [skill] | [state] |
| 当前状态 | 指向技能 | 目标状态 |
|---|---|---|
| [state] | [skill] | [state] |
Complementary Skills
互补技能
| Skill | Relationship |
|---|---|
| [skill] | [how they relate] |
undefined| 技能 | 关系 |
|---|---|
| [skill] | [关联方式] |
undefinedSkill Types
技能类型
Type D: Diagnostic Skills
D类:诊断技能
Purpose: Identify problems, recommend interventions
Pattern: States → Questions → Interventions
Examples: story-sense, worldbuilding, conlang
Key characteristics:
- Problem states with symptoms/questions
- Cross-references to intervention tools
- "What you do NOT do" section enforces boundaries
- Integration tables mapping to other skills
用途: 识别问题,推荐干预方案
模式: 状态 → 问题 → 干预方案
示例: story-sense、worldbuilding、conlang
关键特性:
- 包含症状/问题的问题状态
- 指向干预工具的交叉引用
- “禁止行为”部分明确边界
- 映射到其他技能的集成表
Type G: Generator Skills
G类:生成技能
Purpose: Produce structured output from parameters
Pattern: Parameters → Generation → Output
Examples: Functions in story-sense, phonology in conlang
Key characteristics:
- Input parameters with defaults
- Randomization with optional seeding
- Multiple output formats (human, JSON, brief)
- Quality levels (starter → comprehensive)
用途: 根据参数生成结构化输出
模式: 参数 → 生成 → 输出
示例: story-sense中的函数、conlang中的音系
关键特性:
- 带默认值的输入参数
- 支持可选种子的随机化
- 多种输出格式(人类可读、JSON、简洁版)
- 不同质量等级(入门级 → 全面级)
Type U: Utility Skills
U类:实用技能
Purpose: Support other skills, build infrastructure
Pattern: Input → Analysis/Transformation → Report
Examples: list-builder, skill-builder
Key characteristics:
- Meta-level operation
- Quality metrics and validation
- Templates and scaffolding
- Cross-skill applicability
用途: 支持其他技能,构建基础设施
模式: 输入 → 分析/转换 → 报告
示例: list-builder、skill-builder
关键特性:
- 元级操作
- 质量指标与验证
- 模板与脚手架
- 跨技能适用性
Type O: Orchestrator Skills
O类:编排技能
Purpose: Coordinate multiple skills into autonomous workflows
Pattern: Input → Multi-Pass Evaluation Loop → Polished Output
Examples: chapter-drafter
Key characteristics:
- Invokes multiple sub-skills sequentially
- Iterates until quality thresholds met
- Accumulates context across work units
- Operates autonomously without human checkpoints
Required frontmatter:
yaml
metadata:
orchestrates: # Sub-skills to coordinate
- skill-one
- skill-two
pass_order: # Evaluation sequence
- skill-one
- skill-two
pass_weights: # Weight per skill (sum to 100)
skill-one: 50
skill-two: 50
max_iterations: 3 # Per-pass iteration limit
global_max_iterations: 50 # Total capSee for architectural details.
skills/fiction/orchestrators/README.md用途: 将多个技能协调为自主工作流
模式: 输入 → 多轮评估循环 → 优化输出
示例: chapter-drafter
关键特性:
- 按顺序调用多个子技能
- 迭代直到达到质量阈值
- 跨工作单元累积上下文
- 无需人工检查点即可自主运行
必填前置内容:
yaml
metadata:
orchestrates: # 要协调的子技能
- skill-one
- skill-two
pass_order: # 评估顺序
- skill-one
- skill-two
pass_weights: # 每个技能的权重(总和为100)
skill-one: 50
skill-two: 50
max_iterations: 3 # 每轮迭代限制
global_max_iterations: 50 # 总迭代上限有关架构细节,请参阅。
skills/fiction/orchestrators/README.mdSkill Maturity Scoring (24 points)
技能成熟度评分(24分)
Skills are evaluated on a 24-point scale parallel to the framework 24-point system.
技能采用与框架24分制平行的24分评估体系。
Completeness (11 points)
完整性(11分)
| Check | Points | Criteria |
|---|---|---|
| Core Principle | 1 | Bold statement capturing diagnostic essence |
| States | 2 | 3-7 states for diagnostic skills (N/A for generator/utility) |
| State Components | 2 | Symptoms, Key Questions, Interventions for each state |
| Diagnostic Process | 1 | Step-by-step process documented |
| Anti-Patterns | 2 | 3+ anti-patterns with Problem/Fix structure |
| Examples | 2 | 2+ worked examples showing skill application |
| Boundaries | 1 | "What You Do NOT Do" section |
| 检查项 | 分值 | 标准 |
|---|---|---|
| 核心原则 | 1 | 包含捕捉诊断本质的加粗声明 |
| 状态 | 2 | 诊断技能包含3-7个状态(生成/实用技能不适用) |
| 状态组件 | 2 | 每个状态包含症状、关键问题和干预方案 |
| 诊断流程 | 1 | 记录了分步流程 |
| 反模式 | 2 | 包含3个以上带“问题/修复”结构的反模式 |
| 示例 | 2 | 包含2个以上展示技能应用的实际示例 |
| 边界 | 1 | 包含“禁止行为”部分 |
Quality (5 points)
质量(5分)
| Check | Points | Criteria |
|---|---|---|
| Self-Contained | 1 | Can be used without reading other skills |
| Type+Mode Declared | 1 | Required frontmatter fields present |
| State Naming | 1 | Consistent state prefix matching skill abbreviation |
| Integration Map | 1 | Documents connections to other skills |
| Tools Documented | 1 | All scripts have usage documentation |
| 检查项 | 分值 | 标准 |
|---|---|---|
| 自包含 | 1 | 无需阅读其他技能即可使用 |
| 类型+模式声明 | 1 | 包含必填的前置字段 |
| 状态命名 | 1 | 状态前缀与技能缩写一致 |
| 集成图谱 | 1 | 记录了与其他技能的连接 |
| 工具文档 | 1 | 所有脚本都有使用文档 |
Usability (4 points)
易用性(4分)
| Check | Points | Criteria |
|---|---|---|
| Output Persistence | 1 | Customized (not boilerplate) persistence section |
| Progressive Disclosure | 1 | Quick reference section for at-a-glance use |
| Decision Tree | 1 | Routing logic for common scenarios |
| Actionability | 1 | Clear next steps for each diagnosis |
| 检查项 | 分值 | 标准 |
|---|---|---|
| 输出持久化 | 1 | 包含自定义(非模板化)的持久化部分 |
| 渐进式披露 | 1 | 包含供快速参考的内容 |
| 决策树 | 1 | 包含常见场景的路由逻辑 |
| 可操作性 | 1 | 每个诊断结果都有明确的后续步骤 |
Execution Intelligence (4 points) — NEW
执行智能(4分)—— 新增
| Check | Points | Criteria |
|---|---|---|
| Reasoning Requirements | 1 | Specifies when extended thinking benefits the task |
| Execution Strategy | 1 | Documents sequential vs. parallelizable work |
| Subagent Guidance | 1 | Identifies when to spawn specialized subagents |
| Context Management | 1 | Documents token footprint and optimization strategies |
| 检查项 | 分值 | 标准 |
|---|---|---|
| 推理要求 | 1 | 指定了何时需要扩展思考以获益 |
| 执行策略 | 1 | 记录了顺序执行与并行执行的场景 |
| 子Agent指导 | 1 | 确定了何时需要生成专业子Agent |
| 上下文管理 | 1 | 记录了Token占用量和优化策略 |
Maturity Levels
成熟度等级
| Level | Score | Description |
|---|---|---|
| Draft | 0-8 | Missing core elements |
| Developing | 9-14 | Functional but incomplete |
| Stable | 15-20 | Production-ready |
| Battle-Tested | 21-24 | Has case studies + full execution intelligence |
| 等级 | 分数 | 描述 |
|---|---|---|
| 草稿 | 0-8 | 缺少核心元素 |
| 开发中 | 9-14 | 可用但不完整 |
| 稳定 | 15-20 | 可投入生产 |
| 实战验证 | 21-24 | 包含案例研究 + 完整执行智能 |
Required Metadata
必填元数据
Type (Required)
类型(必填)
Every skill must declare its type in frontmatter:
yaml
metadata:| Type | Definition | Required Sections |
|---|---|---|
| diagnostic | Identifies problems, recommends interventions | States, Diagnostic Process, Anti-Patterns |
| generator | Produces structured output from parameters | Parameters, Generation Logic, Output Formats |
| utility | Supports other skills, builds infrastructure | Process, Templates, Validation |
| orchestrator | Coordinates multiple skills into autonomous workflows | Orchestration Loop, Pass Criteria, Iteration Limits |
每个技能必须在前置内容中声明其类型:
yaml
metadata:| 类型 | 定义 | 必填部分 |
|---|---|---|
| diagnostic | 识别问题,推荐干预方案 | 状态、诊断流程、反模式 |
| generator | 根据参数生成结构化输出 | 参数、生成逻辑、输出格式 |
| utility | 支持其他技能,构建基础设施 | 流程、模板、验证 |
| orchestrator | 将多个技能协调为自主工作流 | 编排循环、通过标准、迭代限制 |
Mode (Required)
模式(必填)
Every skill must declare its mode in frontmatter:
yaml
metadata:| Mode | Definition | User Relationship |
|---|---|---|
| diagnostic | Identifies problem states and recommends | Agent diagnoses, user decides |
| assistive | Guides without producing content | Agent asks questions, user creates |
| collaborative | Works alongside user | Agent produces, user guides |
| evaluative | Assesses existing work | Agent reviews, user responds |
| application | Operates in real-time context | Agent runs, user participates |
| generative | Creates output from parameters | Agent produces, user selects |
Compound modes (e.g., ) are allowed when skills perform multiple functions.
diagnostic+generative每个技能必须在前置内容中声明其模式:
yaml
metadata:| 模式 | 定义 | 用户关系 |
|---|---|---|
| diagnostic | 识别问题状态并给出建议 | Agent诊断,用户决策 |
| assistive | 提供指导但不生成内容 | Agent提问,用户创作 |
| collaborative | 与用户协同工作 | Agent生成内容,用户指导 |
| evaluative | 评估现有工作 | Agent评审,用户回应 |
| application | 在实时上下文中运行 | Agent执行,用户参与 |
| generative | 根据参数生成输出 | Agent生成内容,用户选择 |
复合模式(如)在技能执行多项功能时允许使用。
diagnostic+generativeOptional Metadata
可选元数据
yaml
metadata:
maturity_score: 15yaml
metadata:
maturity_score: 15State Naming Convention
状态命名规范
States must follow a consistent naming pattern:
Convention:
{ABBREV}{NUMBER}: {State Name}Rules:
- Abbreviation is 1-3 uppercase letters derived from skill name
- Numbers start at 0 (for "no X exists" states) or 1
- State names are descriptive, not just numbers
- Sub-states use decimal notation (4.5, 5.75) when inserting between existing states
Standard Abbreviations:
| Skill | Abbreviation | Example |
|---|---|---|
| story-sense | SS | State SS1: Concept Without Foundation |
| dialogue | D | State D1: Identical Voices |
| conlang | L | State L1: No Language |
| worldbuilding | W | State W1: Backdrop World |
| revision | R | State R1: Overwhelmed |
| endings | E | State E1: Arbitrary Ending |
| character-arc | CA | State CA1: Static Character |
| scene-sequencing | SQ | State SQ1: Scene-Only Pacing |
| brainstorming | B | State B1: Convergent Ideas |
| research | RS | State RS1: No Research |
| requirements-analysis | RA | State RA1: Vague Requirements |
| system-design | SD | State SD1: No Architecture |
| chapter-drafter | CD | (Orchestrator - uses pass scores, not states) |
New skills should claim an unused abbreviation and document it here.
状态必须遵循统一的命名模式:
规范:
{ABBREV}{NUMBER}: {State Name}规则:
- 缩写为1-3个大写字母,由技能名称衍生
- 编号从0(表示“无X存在”状态)或1开始
- 状态名称具有描述性,不能仅用编号
- 插入现有状态之间的子状态使用十进制表示(如4.5、5.75)
标准缩写:
| 技能 | 缩写 | 示例 |
|---|---|---|
| story-sense | SS | State SS1: Concept Without Foundation |
| dialogue | D | State D1: Identical Voices |
| conlang | L | State L1: No Language |
| worldbuilding | W | State W1: Backdrop World |
| revision | R | State R1: Overwhelmed |
| endings | E | State E1: Arbitrary Ending |
| character-arc | CA | State CA1: Static Character |
| scene-sequencing | SQ | State SQ1: Scene-Only Pacing |
| brainstorming | B | State B1: Convergent Ideas |
| research | RS | State RS1: No Research |
| requirements-analysis | RA | State RA1: Vague Requirements |
| system-design | SD | State SD1: No Architecture |
| chapter-drafter | CD | (编排技能 - 使用通过分数,而非状态) |
新技能应选用未被使用的缩写并在此处记录。
Integration Graph Requirements
集成图谱要求
Every skill must document its connections to other skills.
Required Format:
markdown
undefined每个技能必须记录与其他技能的连接。
必填格式:
markdown
undefinedIntegration Graph
集成图谱
Inbound (From Other Skills)
入站(来自其他技能)
| Source Skill | Source State | Leads to State |
|---|---|---|
| story-sense | SS5: Plot Without Purpose | D4: No Subtext |
| 来源技能 | 来源状态 | 指向状态 |
|---|---|---|
| story-sense | SS5: Plot Without Purpose | D4: No Subtext |
Outbound (To Other Skills)
出站(指向其他技能)
| This State | Leads to Skill | Target State |
|---|---|---|
| D6: Pacing Mismatch | scene-sequencing | SQ2: Sequel Missing |
| 当前状态 | 指向技能 | 目标状态 |
|---|---|---|
| D6: Pacing Mismatch | scene-sequencing | SQ2: Sequel Missing |
Complementary Skills
互补技能
| Skill | Relationship |
|---|---|
| character-arc | Voice reflects transformation |
| worldbuilding | Speech reflects culture |
**Requirements:**
- Minimum 1 inbound OR 1 outbound connection
- Complementary skills list for context
- State-level specificity (not just skill-to-skill)
- Bidirectional documentation (if A references B, B should reference A)| 技能 | 关系 |
|---|---|
| character-arc | 声音反映角色转变 |
| worldbuilding | 语言反映文化背景 |
**要求:**
- 至少包含1个入站或1个出站连接
- 包含互补技能列表以提供上下文
- 状态级别的具体性(不能仅记录技能间的连接)
- 双向记录(如果A引用B,B也应引用A)Execution Intelligence Requirements
执行智能要求
Skills should document how they're best executed by Claude Code.
技能应记录如何让Claude Code以最佳方式执行。
Reasoning Requirements Section
推理要求部分
Document when extended thinking () benefits the skill:
ultrathinkmarkdown
undefined记录何时使用扩展思考()对技能有益:
ultrathinkmarkdown
undefinedReasoning Requirements
推理要求
Standard Reasoning
标准推理
- Initial diagnosis and symptom matching
- Simple state identification
- Script execution and output interpretation
- 初始诊断和症状匹配
- 简单状态识别
- 脚本执行和输出解释
Extended Reasoning (ultrathink)
扩展推理(ultrathink)
Use extended thinking for:
- Multi-framework synthesis - [Why: requires holding multiple models simultaneously]
- Complex worldbuilding systems - [Why: many interdependent variables]
- Cascade analysis across states - [Why: second-order effects compound]
Trigger phrases: "deep analysis", "comprehensive review", "multi-framework synthesis"
**Why this matters:** LLMs have a completion reward bias—they rush toward visible goals. Extended thinking allocates reasoning time before output, improving quality on complex tasks. This aligns with the LLM Process Design Framework principle.在以下场景使用扩展思考:
- 多框架综合 - [原因:需要同时掌握多个模型]
- 复杂世界构建系统 - [原因:存在大量相互依赖的变量]
- 跨状态级联分析 - [原因:二阶效应会不断累积]
触发短语: "深度分析"、"全面评审"、"多框架综合"
**重要性:** LLM存在完成奖励偏差——会急于输出可见结果。扩展思考在输出前分配了推理时间,可提升复杂任务的质量。这与LLM流程设计框架原则一致。Execution Strategy Section
执行策略部分
Document sequential vs. parallel work:
markdown
undefined记录顺序执行与并行执行的场景:
markdown
undefinedExecution Strategy
执行策略
Sequential (Default)
顺序执行(默认)
- Diagnosis must complete before intervention
- State identification before framework selection
- 诊断完成后才能进行干预
- 先确定状态,再选择框架
Parallelizable
可并行执行
- Multiple script runs (entropy + functions) can run concurrently
- Research across multiple frameworks can parallelize
- Use when: Tasks are independent and can merge results
- 多个脚本运行(熵 + 函数)可同时进行
- 跨多个框架的研究可并行处理
- 适用场景:任务相互独立,结果可合并
Subagent Candidates
子Agent候选
| Task | Agent Type | When to Spawn |
|---|---|---|
| Codebase exploration | Explore | When skill needs project context |
| Framework research | general-purpose | When synthesizing across 3+ frameworks |
undefined| 任务 | Agent类型 | 生成时机 |
|---|---|---|
| 代码库探索 | Explore | 当技能需要项目上下文时 |
| 框架研究 | general-purpose | 当综合3个以上框架时 |
undefinedContext Management Section
上下文管理部分
Document token usage and optimization:
markdown
undefined记录Token使用情况和优化策略:
markdown
undefinedContext Management
上下文管理
Approximate Token Footprint
预估Token占用量
- Skill base: ~2k tokens
- With full state definitions: ~4k tokens
- With scripts inline: ~8k tokens (avoid unless debugging)
- 技能基础: ~2k tokens
- 包含完整状态定义: ~4k tokens
- 内联脚本: ~8k tokens(除非调试,否则避免)
Context Optimization
上下文优化
- Load scripts on-demand rather than including inline
- Reference framework documentation by name rather than embedding
- Use Quick Reference section for common cases
- 按需加载脚本,而非内联包含
- 通过名称引用框架文档,而非嵌入内容
- 针对常见场景使用快速参考部分
When Context Gets Tight
上下文紧张时的处理
- Prioritize: Current state diagnosis and immediate intervention
- Defer: Integration graph, full anti-patterns list
- Drop: Script source code, historical examples
undefined- 优先处理:当前状态诊断和即时干预
- 延后处理:集成图谱、完整反模式列表
- 舍弃内容:脚本源代码、历史示例
undefinedAnti-Pattern Requirements
反模式要求
Every skill must document common mistakes.
Minimum Requirements:
- 3 anti-patterns for diagnostic skills
- 2 anti-patterns for generator/utility skills
Required Structure:
markdown
undefined每个技能必须记录常见错误。
最低要求:
- 诊断技能包含3个以上反模式
- 生成/实用技能包含2个以上反模式
必填结构:
markdown
undefinedThe {Anti-Pattern Name}
{反模式名称}
Pattern: What the problematic behavior looks like
Problem: Why this causes harm
Fix: How to resolve it
Detection: [Optional] How to recognize this happening
**Common Anti-Pattern Categories:**
| Category | Example Names |
|----------|---------------|
| Scope Creep | The Kitchen Sink, The Mission Creep |
| Missing Depth | The Surface Treatment, The Checklist |
| Wrong Level | The Bottom-Up Edit, The Premature Optimization |
| User Relationship | The Puppet Master, The Passive Recipient |
| Integration | The Orphan Skill, The Boundary Ignorer |模式: 问题行为的表现
问题: 造成危害的原因
修复方案: 解决办法
检测方式: [可选] 如何识别该问题
**常见反模式类别:**
| 类别 | 示例名称 |
|----------|---------------|
| 范围蔓延 | 包罗万象、任务蔓延 |
| 缺乏深度 | 表面处理、清单式执行 |
| 层级错误 | 自底向上编辑、过早优化 |
| 用户关系 | 傀儡操控、被动接受 |
| 集成问题 | 孤立技能、边界无视者 |Script Patterns
脚本模式
Standard Script Template
标准脚本模板
typescript
#!/usr/bin/env -S deno run --allow-read
/**
* Script Name
*
* Description of what it does.
*
* Usage:
* deno run --allow-read script.ts [args]
*/
// === INTERFACES ===
interface ResultType {
field: string;
// ...
}
// === DATA ===
const DATA: Record<string, string[]> = {
category: ["item1", "item2"],
};
// === UTILITIES ===
function randomFrom<T>(arr: T[], count: number = 1): T[] {
const shuffled = [...arr].sort(() => Math.random() - 0.5);
return shuffled.slice(0, Math.min(count, arr.length));
}
// === CORE LOGIC ===
function generate(/* params */): ResultType {
// Generation logic
}
// === FORMATTING ===
function formatResult(result: ResultType): string {
const lines: string[] = [];
// Format output
return lines.join("\n");
}
// === MAIN ===
function main(): void {
const args = Deno.args;
// Help
if (args.includes("--help") || args.includes("-h")) {
console.log(`Script Name
Usage:
deno run --allow-read script.ts [options]
Options:
--flag Description
--json Output as JSON
`);
Deno.exit(0);
}
// Parse arguments
const flagIndex = args.indexOf("--flag");
const flagValue = flagIndex !== -1 ? args[flagIndex + 1] : null;
const jsonOutput = args.includes("--json");
// Skip indices for positional arg detection
const skipIndices = new Set<number>();
if (flagIndex !== -1) {
skipIndices.add(flagIndex);
skipIndices.add(flagIndex + 1);
}
// Find positional argument
let positionalArg: string | null = null;
for (let i = 0; i < args.length; i++) {
if (!args[i].startsWith("--") && !skipIndices.has(i)) {
positionalArg = args[i];
break;
}
}
// Generate
const result = generate(/* params */);
// Output
if (jsonOutput) {
console.log(JSON.stringify(result, null, 2));
} else {
console.log(formatResult(result));
}
}
main();typescript
#!/usr/bin/env -S deno run --allow-read
/**
* Script Name
*
* Description of what it does.
*
* Usage:
* deno run --allow-read script.ts [args]
*/
// === INTERFACES ===
interface ResultType {
field: string;
// ...
}
// === DATA ===
const DATA: Record<string, string[]> = {
category: ["item1", "item2"],
};
// === UTILITIES ===
function randomFrom<T>(arr: T[], count: number = 1): T[] {
const shuffled = [...arr].sort(() => Math.random() - 0.5);
return shuffled.slice(0, Math.min(count, arr.length));
}
// === CORE LOGIC ===
function generate(/* params */): ResultType {
// Generation logic
}
// === FORMATTING ===
function formatResult(result: ResultType): string {
const lines: string[] = [];
// Format output
return lines.join("\n");
}
// === MAIN ===
function main(): void {
const args = Deno.args;
// Help
if (args.includes("--help") || args.includes("-h")) {
console.log(`Script Name
Usage:
deno run --allow-read script.ts [options]
Options:
--flag Description
--json Output as JSON
`);
Deno.exit(0);
}
// Parse arguments
const flagIndex = args.indexOf("--flag");
const flagValue = flagIndex !== -1 ? args[flagIndex + 1] : null;
const jsonOutput = args.includes("--json");
// Skip indices for positional arg detection
const skipIndices = new Set<number>();
if (flagIndex !== -1) {
skipIndices.add(flagIndex);
skipIndices.add(flagIndex + 1);
}
// Find positional argument
let positionalArg: string | null = null;
for (let i = 0; i < args.length; i++) {
if (!args[i].startsWith("--") && !skipIndices.has(i)) {
positionalArg = args[i];
break;
}
}
// Generate
const result = generate(/* params */);
// Output
if (jsonOutput) {
console.log(JSON.stringify(result, null, 2));
} else {
console.log(formatResult(result));
}
}
main();Argument Parsing Pattern
参数解析模式
typescript
// 1. Help check first
if (args.includes("--help") || args.includes("-h")) { ... }
// 2. Parse --flag value pairs
const flagIndex = args.indexOf("--flag");
const flagValue = flagIndex !== -1 ? args[flagIndex + 1] : defaultValue;
// 3. Boolean flags
const boolFlag = args.includes("--bool");
// 4. Track consumed indices
const skipIndices = new Set<number>();
if (flagIndex !== -1) {
skipIndices.add(flagIndex);
skipIndices.add(flagIndex + 1);
}
// 5. Find positional args
for (let i = 0; i < args.length; i++) {
if (!args[i].startsWith("--") && !skipIndices.has(i)) {
positionalArg = args[i];
break;
}
}typescript
// 1. 先检查帮助命令
if (args.includes("--help") || args.includes("-h")) { ... }
// 2. 解析--flag 键值对
const flagIndex = args.indexOf("--flag");
const flagValue = flagIndex !== -1 ? args[flagIndex + 1] : defaultValue;
// 3. 布尔型标志
const boolFlag = args.includes("--bool");
// 4. 跟踪已消耗的索引
const skipIndices = new Set<number>();
if (flagIndex !== -1) {
skipIndices.add(flagIndex);
skipIndices.add(flagIndex + 1);
}
// 5. 查找位置参数
for (let i = 0; i < args.length; i++) {
if (!args[i].startsWith("--") && !skipIndices.has(i)) {
positionalArg = args[i];
break;
}
}Data Loading Pattern
数据加载模式
typescript
// For external JSON files
async function loadData<T>(path: string): Promise<T> {
try {
const text = await Deno.readTextFile(path);
return JSON.parse(text);
} catch (e) {
console.error(`Error loading ${path}: ${e}`);
Deno.exit(1);
}
}
// Relative path from script
const scriptDir = new URL(".", import.meta.url).pathname;
const dataPath = `${scriptDir}../data/file.json`;typescript
// 加载外部JSON文件
async function loadData<T>(path: string): Promise<T> {
try {
const text = await Deno.readTextFile(path);
return JSON.parse(text);
} catch (e) {
console.error(`Error loading ${path}: ${e}`);
Deno.exit(1);
}
}
// 脚本的相对路径
const scriptDir = new URL(".", import.meta.url).pathname;
const dataPath = `${scriptDir}../data/file.json`;Output Pattern
输出模式
typescript
// Always support multiple formats
if (jsonOutput) {
console.log(JSON.stringify(result, null, 2));
} else if (briefOutput) {
console.log(formatBrief(result));
} else {
console.log(formatFull(result));
}typescript
// 始终支持多种格式
if (jsonOutput) {
console.log(JSON.stringify(result, null, 2));
} else if (briefOutput) {
console.log(formatBrief(result));
} else {
console.log(formatFull(result));
}Data File Patterns
数据文件模式
Simple List (for entropy/randomization)
简单列表(用于熵/随机化)
json
{
"list_name": [
"Specific item with enough detail to spark ideas",
"Another item that's 20-60 characters ideally",
"Items should be concrete not vague"
]
}Quality thresholds:
- Starter: 10-30 items (demo only)
- Functional: 30-75 items (usable)
- Production: 75-150 items (ready)
- Comprehensive: 150+ items (reference quality)
json
{
"list_name": [
"足够具体、能激发灵感的条目",
"理想长度为20-60字符的另一个条目",
"条目应具体而非模糊"
]
}质量阈值:
- 入门级:10-30条(仅用于演示)
- 功能级:30-75条(可用)
- 生产级:75-150条(可投入使用)
- 全面级:150条以上(参考级质量)
Structured Data (for complex generation)
结构化数据(用于复杂生成)
json
{
"_meta": {
"description": "What this data is for",
"usage": "How to use it",
"source": "Where it came from (optional)"
},
"category": {
"item_name": {
"property": "value",
"frequency": 0.85,
"tags": ["tag1", "tag2"]
}
}
}json
{
"_meta": {
"description": "数据用途",
"usage": "使用方式",
"source": "数据来源(可选)"
},
"category": {
"item_name": {
"property": "value",
"frequency": 0.85,
"tags": ["tag1", "tag2"]
}
}
}Frequency-Weighted Data
频率加权数据
json
{
"tier_universal": {
"description": "Found in nearly all cases",
"items": { "a": { "frequency": 0.95 }, "b": { "frequency": 0.90 } }
},
"tier_common": {
"description": "Found in most cases",
"items": { "c": { "frequency": 0.70 } }
},
"tier_rare": {
"description": "Unusual but attested",
"items": { "d": { "frequency": 0.15 } }
}
}json
{
"tier_universal": {
"description": "几乎在所有场景中出现",
"items": { "a": { "frequency": 0.95 }, "b": { "frequency": 0.90 } }
},
"tier_common": {
"description": "在大多数场景中出现",
"items": { "c": { "frequency": 0.70 } }
},
"tier_rare": {
"description": "不常见但有实例",
"items": { "d": { "frequency": 0.15 } }
}
}Diagnostic Process for Building Skills
技能构建诊断流程
When creating a new skill:
创建新技能时:
1. Identify the Problem Space
1. 确定问题领域
- What problems does this skill diagnose?
- What are the symptoms a user would notice?
- How does this connect to existing skills?
- 该技能要诊断哪些问题?
- 用户会注意到哪些症状?
- 它与现有技能有何关联?
2. Define States
2. 定义状态
- Create 3-7 distinct states
- Each state needs: symptoms, key questions, interventions
- States should be mutually exclusive but cover the space
- 创建3-7个不同的状态
- 每个状态需包含:症状、关键问题、干预方案
- 状态应互斥且覆盖整个问题领域
3. Design Tools
3. 设计工具
- What can scripts do better than LLM judgment?
- Randomization? Structure generation? Validation?
- What data does the script need?
- 哪些工作脚本比LLM判断更擅长?
- 随机化?结构生成?验证?
- 脚本需要哪些数据?
4. Map Integrations
4. 映射集成关系
- Which other skills does this connect to?
- What states in other skills lead here?
- What states here lead elsewhere?
- 与哪些其他技能相连?
- 其他技能的哪些状态指向此处?
- 此处的哪些状态指向其他技能?
5. Validate Completeness
5. 验证完整性
Run to check:
validate-skill.ts- Required frontmatter fields
- State definitions with all components
- Script documentation
- Integration references
运行检查:
validate-skill.ts- 必填前置字段
- 包含所有组件的状态定义
- 脚本文档
- 集成引用
Available Tools
可用工具
scaffold.ts
scaffold.ts
Generates skill directory structure and template files.
bash
undefined生成技能目录结构和模板文件。
bash
undefinedCreate new skill scaffolding
创建新技能脚手架
deno run --allow-read --allow-write scripts/scaffold.ts skill-name
deno run --allow-read --allow-write scripts/scaffold.ts skill-name
With type specification
指定技能类型
deno run --allow-read --allow-write scripts/scaffold.ts skill-name --type diagnostic
deno run --allow-read --allow-write scripts/scaffold.ts skill-name --type diagnostic
Preview without writing
预览而不写入文件
deno run --allow-read scripts/scaffold.ts skill-name --dry-run
undefineddeno run --allow-read scripts/scaffold.ts skill-name --dry-run
undefinedvalidate-skill.ts
validate-skill.ts
Checks skill completeness and pattern conformance.
bash
undefined检查技能完整性和模式合规性。
bash
undefinedValidate a skill
验证单个技能
deno run --allow-read scripts/validate-skill.ts ../worldbuilding
deno run --allow-read scripts/validate-skill.ts ../worldbuilding
Validate all skills in fiction cluster
验证fiction集群中的所有技能
deno run --allow-read scripts/validate-skill.ts --all
deno run --allow-read scripts/validate-skill.ts --all
JSON output for CI
输出JSON格式用于CI
deno run --allow-read scripts/validate-skill.ts ../conlang --json
undefineddeno run --allow-read scripts/validate-skill.ts ../conlang --json
undefinedAnti-Patterns
反模式
The Feature List Skill
功能清单式技能
Problem: Skill is a list of things it can do, not a diagnostic framework.
Fix: Restructure around problem states. What are users stuck on?
问题: 技能是功能列表,而非诊断框架。
修复方案: 围绕问题状态重构。用户卡在了什么地方?
The Kitchen Sink
包罗万象
Problem: Skill tries to do too much, covers multiple problem domains.
Fix: Split into focused skills. One skill = one diagnostic space.
问题: 技能试图涵盖多个问题领域,功能过于繁杂。
修复方案: 拆分为专注的技能。一个技能对应一个诊断领域。
The Script Without Skill
无技能支撑的脚本
Problem: Script exists but no SKILL.md explains when to use it.
Fix: Every script belongs to a skill with documented purpose.
问题: 存在脚本,但没有SKILL.md说明使用时机。
修复方案: 每个脚本都属于一个有文档记录用途的技能。
The Orphan Skill
孤立技能
Problem: Skill doesn't reference or get referenced by other skills.
Fix: Add integration section. Map state transitions to/from other skills.
问题: 技能未引用其他技能,也未被其他技能引用。
修复方案: 添加集成部分。映射与其他技能的状态转换关系。
The Clone Skill
克隆技能
Problem: Skill duplicates another skill's states with different names.
Fix: Merge or clearly differentiate the problem spaces.
问题: 技能复制了另一个技能的状态,仅名称不同。
修复方案: 合并或明确区分问题领域。
Verification (Oracle)
验证(预言机)
This section documents what this skill can reliably verify vs. what requires human judgment.
See for background on oracles.
organization/architecture/context-packet-architecture.md本节记录该技能可可靠验证的内容,以及需要人工判断的内容。
有关预言机的背景知识,请参阅。
organization/architecture/context-packet-architecture.mdWhat This Skill Can Verify
可验证内容
- Structural completeness - validate-skill.ts checks required sections exist (High confidence)
- State naming conventions - Validates pattern (High confidence)
{ABBREV}{N}: Name - Frontmatter presence - Required type/mode fields present (High confidence)
- Section presence - Anti-patterns, Integration Graph, Output Persistence exist (High confidence)
- State component structure - Symptoms/Questions/Interventions present per state (Medium confidence)
- 结构完整性 - validate-skill.ts检查必填部分是否存在(高可信度)
- 状态命名规范 - 验证模式(高可信度)
{ABBREV}{N}: Name - 前置内容存在性 - 必填的类型/模式字段是否存在(高可信度)
- 部分存在性 - 反模式、集成图谱、输出持久化部分是否存在(高可信度)
- 状态组件结构 - 每个状态是否包含症状/问题/干预方案(中等可信度)
What Requires Human Judgment
需要人工判断的内容
- State quality - Are states mutually exclusive and comprehensive? (Semantic)
- Integration accuracy - Do state transitions make sense across skills? (Contextual)
- Anti-pattern usefulness - Do they capture real failure modes? (Experiential)
- Example relevance - Do examples match real use cases? (Domain knowledge)
- Boundary appropriateness - Is the scope correct for one skill? (Design judgment)
- 状态质量 - 状态是否互斥且全面?(语义层面)
- 集成准确性 - 跨技能的状态转换是否合理?(上下文层面)
- 反模式实用性 - 是否捕捉了真实的失败模式?(经验层面)
- 示例相关性 - 示例是否匹配实际用例?(领域知识层面)
- 边界合理性 - 技能的范围是否合适?(设计判断层面)
Available Validation Scripts
可用验证脚本
| Script | Verifies | Confidence |
|---|---|---|
| validate-skill.ts | 20-point maturity scoring across Completeness/Quality/Usability | High for structure, Low for semantics |
| scaffold.ts | Generated files match expected structure | High |
| 脚本 | 验证内容 | 可信度 |
|---|---|---|
| validate-skill.ts | 从完整性/质量/易用性三个维度进行20分成熟度评分 | 结构检查可信度高,语义检查可信度低 |
| scaffold.ts | 生成的文件是否符合预期结构 | 高 |
Oracle Limitations
预言机局限性
The validate-skill.ts script:
- Cannot detect duplicated skill coverage (The Clone Skill anti-pattern)
- Cannot detect scope creep (The Kitchen Sink anti-pattern)
- Cannot verify integration bidirectionality (must check both skills manually)
- Reports presence, not quality - a section existing doesn't mean it's good
validate-skill.ts脚本:
- 无法检测 重复的技能覆盖(克隆技能反模式)
- 无法检测 范围蔓延(包罗万象反模式)
- 无法验证 集成的双向性(必须手动检查两个技能)
- 仅报告存在性,不报告质量 - 部分存在不代表内容质量合格
Feedback Loop
反馈循环
This section documents how outputs persist and inform future sessions.
See for background on feedback loops.
organization/architecture/context-packet-architecture.md本节记录输出如何持久化并为后续会话提供信息。
有关反馈循环的背景知识,请参阅。
organization/architecture/context-packet-architecture.mdSession Persistence
会话持久化
- Output location: (directory structure)
skills/{cluster}/{skill-name}/ - What to save: SKILL.md, scripts/, data/, templates/
- Naming pattern: Skill name becomes directory name
- 输出位置: (目录结构)
skills/{cluster}/{skill-name}/ - 保存内容: SKILL.md、scripts/、data/、templates/
- 命名模式: 技能名称作为目录名
Cross-Session Learning
跨会话学习
- Before starting: Check if a skill for this problem space already exists
- If prior skill exists: Extend rather than duplicate; check integration graph
- What feedback improves this skill:
- New anti-patterns discovered during skill creation
- State naming collisions found
- Integration patterns that work well
- 开始前: 检查该问题领域是否已有技能
- 如果存在现有技能: 扩展而非重复;检查集成图谱
- 可改进技能的反馈:
- 技能创建过程中发现的新反模式
- 发现的状态命名冲突
- 有效的集成模式
Improvement Triggers
改进触发条件
- When validate-skill.ts reveals common failures → Update maturity criteria
- When skill creation struggles → Add to anti-patterns
- When integration mapping is unclear → Improve Integration Graph section
- 当validate-skill.ts发现常见失败时 → 更新成熟度标准
- 当技能创建遇到困难时 → 添加到反模式
- 当集成映射不清晰时 → 改进集成图谱部分
Design Constraints
设计约束
This section documents preconditions and boundaries.
See for background on constraints.
organization/architecture/context-packet-architecture.md本节记录前提条件和边界。
有关约束的背景知识,请参阅。
organization/architecture/context-packet-architecture.mdThis Skill Assumes
技能假设
- User has a clear problem domain to address (not vague "make a skill")
- Problem domain has identifiable states (symptoms a user would notice)
- Some automation is possible (script + LLM split makes sense)
- 用户有明确的问题领域要解决(而非模糊的“创建一个技能”)
- 问题领域有可识别的状态(用户会注意到的症状)
- 部分工作可自动化(脚本+LLM的分工合理)
This Skill Does Not Handle
技能不处理的场景
- Framework development (higher abstraction) - Route to: framework-development methodology
- Single-use scripts (no diagnostic model) - Route to: simple script writing
- Skills without states (pure generators) - Route to: generator template (simpler structure)
- 框架开发(更高抽象层级) - 路由至:framework-development方法论
- 一次性脚本(无诊断模型) - 路由至:简单脚本编写
- 无状态的技能(纯生成器) - 路由至:生成器模板(更简单的结构)
Degradation Signals
退化信号
Signs this skill is being misapplied:
- Cannot identify 3+ distinct states for the problem space
- All "states" are really parameters to a single generator
- No connection to existing skills makes sense (orphan problem space)
- Problem space overlaps significantly with existing skill
技能被误用的迹象:
- 无法为问题领域识别3个以上不同的状态
- 所有“状态”实际上是单个生成器的参数
- 与现有技能无合理连接(孤立问题领域)
- 问题领域与现有技能严重重叠
Example: Building a New Skill
示例:构建新技能
Request: "Create a skill for diagnosing dialogue problems"
需求: "创建一个诊断对话问题的技能"
Step 1: Identify Problem Space
步骤1:确定问题领域
Dialogue problems are distinct from scene-sequencing (structure) and character-arc (transformation). This is about how characters speak.
对话问题与场景排序(结构)和角色弧光(转变)不同,它关注角色的说话方式。
Step 2: Define States
步骤2:定义状态
- D1: No Dialogue (narrative summary only)
- D2: Same-Voice Characters (everyone sounds identical)
- D3: On-the-Nose Dialogue (no subtext)
- D4: Talking Heads (dialogue without context)
- D5: Functional-Only Dialogue (moves plot, reveals nothing)
- D1:无对话(仅叙事总结)
- D2:角色声音一致(所有人的语气都相同)
- D3:直白对话(无潜台词)
- D4:对话脱离场景(无上下文)
- D5:功能性对话(仅推动情节,无其他信息)
Step 3: Design Tools
步骤3:设计工具
Script: - generates voice differentiation questionnaire
Data: - regional, class, personality markers
voice-check.tsspeech-patterns.json脚本: - 生成声音差异化问卷
数据: - 地域、阶层、性格标记
voice-check.tsspeech-patterns.jsonStep 4: Map Integrations
步骤4:映射集成关系
- From story-sense State 5.5 (dialogue-specific issues)
- To character-arc (voice reflects character growth)
- To worldbuilding (speech reflects culture)
- 来自story-sense的状态5.5(对话特定问题)
- 指向character-arc(声音反映角色成长)
- 指向worldbuilding(语言反映文化)
Step 5: Generate Scaffolding
步骤5:生成脚手架
bash
deno run --allow-read --allow-write scripts/scaffold.ts dialogue --type diagnosticbash
deno run --allow-read --allow-write scripts/scaffold.ts dialogue --type diagnosticOutput Persistence
输出持久化
This skill writes primary output to files so work persists across sessions.
该技能将主要输出写入文件,以便跨会话保留工作成果。
Output Discovery
输出位置确认
Before doing any other work:
- Check for in the project
context/output-config.md - If found, look for this skill's entry
- If not found or no entry for this skill, ask the user first:
- "Where should I save output from this skill-builder session?"
- Suggest: as the standard skill location
skills/{cluster}/{skill-name}/
- Store the user's preference:
- In if context network exists
context/output-config.md - In at project root otherwise
.skill-builder-output.md
- In
在开始任何工作之前:
- 检查项目中是否存在
context/output-config.md - 如果存在,查找该技能的条目
- 如果不存在或无该技能的条目,先询问用户:
- "我应该将本次Skill-Builder会话的输出保存到哪里?"
- 建议:作为标准技能存储位置
skills/{cluster}/{skill-name}/
- 保存用户的偏好:
- 如果存在上下文网络,保存到
context/output-config.md - 否则保存到项目根目录的
.skill-builder-output.md
- 如果存在上下文网络,保存到
Primary Output
主要输出
For this skill, persist:
- Skill scaffolding - SKILL.md, scripts/, templates/, data/
- State definitions - the diagnostic model
- Script templates - generated utility scripts
- Integration map - connections to other skills
对于本技能,需持久化:
- 技能脚手架 - SKILL.md、scripts/、templates/、data/
- 状态定义 - 诊断模型
- 脚本模板 - 生成的实用脚本
- 集成图谱 - 与其他技能的连接
Conversation vs. File
对话与文件的分工
| Goes to File | Stays in Conversation |
|---|---|
| Generated SKILL.md | Discussion of problem space |
| Script templates | State definition iteration |
| Data file stubs | Integration planning |
| Validation results | Real-time feedback |
| 存入文件 | 保留在对话中 |
|---|---|
| 生成的SKILL.md | 问题领域的讨论 |
| 脚本模板 | 状态定义的迭代过程 |
| 数据文件存根 | 集成规划 |
| 验证结果 | 实时反馈 |
File Naming
文件命名
Pattern: (directory structure)
Example:
skills/{cluster}/{skill-name}/skills/fiction/dialogue/模式:(目录结构)
示例:
skills/{cluster}/{skill-name}/skills/fiction/dialogue/What You Do NOT Do
禁止行为
- You do not build skills without clear problem states
- You do not create scripts without SKILL.md documentation
- You do not duplicate existing skill coverage
- You do not skip integration mapping
- You build the framework; the user decides what skills to create
- 不为有明确问题状态的场景构建技能
- 不创建无SKILL.md文档的脚本
- 不重复现有技能的覆盖范围
- 不跳过集成映射
- 你构建框架;用户决定创建哪些技能
Integration with Other Skills
与其他技能的集成
With list-builder (fiction cluster)
与list-builder(fiction集群)
Use list-builder quality criteria for any data files:
- Validate list maturity before marking skill production-ready
- Follow dimensional frameworks for list variety
对任何数据文件使用list-builder的质量标准:
- 在标记技能为生产就绪前,验证列表成熟度
- 遵循维度框架以保证列表多样性
Cross-Cluster Skills
跨集群技能
Skills can reference skills in other clusters:
- Document integration in both skills
- Use full path references when crossing clusters
技能可以引用其他集群的技能:
- 在两个技能中都记录集成关系
- 跨集群时使用完整路径引用
Cluster Conventions
集群规范
When building skills within a cluster:
- Set in frontmatter to the parent skill
cluster - Add integration tables mapping states between skills
- Follow the cluster's established patterns for scripts and data
在集群内构建技能时:
- 在前置内容中设置为父技能
cluster - 添加集成表以映射技能间的状态转换
- 遵循集群已有的脚本和数据模式