skill-builder

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Skill-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/        # 支持文档(可选)
    └── *.md

SKILL.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

诊断流程

  1. Step one
  2. Step two ...
  1. 第一步
  2. 第二步 ...

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:
  1. Action
  2. Action
用户: "问题描述" 你的处理方式:
  1. 操作
  2. 操作

What You Do NOT Do

禁止行为

  • List of boundaries
  • Things the skill never does
  • 边界列表
  • 技能绝不执行的事项

Integration Graph

集成图谱

Inbound (From Other Skills)

入站(来自其他技能)

Source SkillSource StateLeads to State
[skill][state][state]
来源技能来源状态指向状态
[skill][state][state]

Outbound (To Other Skills)

出站(指向其他技能)

This StateLeads to SkillTarget State
[state][skill][state]
当前状态指向技能目标状态
[state][skill][state]

Complementary Skills

互补技能

SkillRelationship
[skill][how they relate]
undefined
技能关系
[skill][关联方式]
undefined

Skill 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 cap
See
skills/fiction/orchestrators/README.md
for architectural details.
用途: 将多个技能协调为自主工作流 模式: 输入 → 多轮评估循环 → 优化输出 示例: 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.md

Skill 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分)

CheckPointsCriteria
Core Principle1Bold statement capturing diagnostic essence
States23-7 states for diagnostic skills (N/A for generator/utility)
State Components2Symptoms, Key Questions, Interventions for each state
Diagnostic Process1Step-by-step process documented
Anti-Patterns23+ anti-patterns with Problem/Fix structure
Examples22+ worked examples showing skill application
Boundaries1"What You Do NOT Do" section
检查项分值标准
核心原则1包含捕捉诊断本质的加粗声明
状态2诊断技能包含3-7个状态(生成/实用技能不适用)
状态组件2每个状态包含症状、关键问题和干预方案
诊断流程1记录了分步流程
反模式2包含3个以上带“问题/修复”结构的反模式
示例2包含2个以上展示技能应用的实际示例
边界1包含“禁止行为”部分

Quality (5 points)

质量(5分)

CheckPointsCriteria
Self-Contained1Can be used without reading other skills
Type+Mode Declared1Required frontmatter fields present
State Naming1Consistent state prefix matching skill abbreviation
Integration Map1Documents connections to other skills
Tools Documented1All scripts have usage documentation
检查项分值标准
自包含1无需阅读其他技能即可使用
类型+模式声明1包含必填的前置字段
状态命名1状态前缀与技能缩写一致
集成图谱1记录了与其他技能的连接
工具文档1所有脚本都有使用文档

Usability (4 points)

易用性(4分)

CheckPointsCriteria
Output Persistence1Customized (not boilerplate) persistence section
Progressive Disclosure1Quick reference section for at-a-glance use
Decision Tree1Routing logic for common scenarios
Actionability1Clear next steps for each diagnosis
检查项分值标准
输出持久化1包含自定义(非模板化)的持久化部分
渐进式披露1包含供快速参考的内容
决策树1包含常见场景的路由逻辑
可操作性1每个诊断结果都有明确的后续步骤

Execution Intelligence (4 points) — NEW

执行智能(4分)—— 新增

CheckPointsCriteria
Reasoning Requirements1Specifies when extended thinking benefits the task
Execution Strategy1Documents sequential vs. parallelizable work
Subagent Guidance1Identifies when to spawn specialized subagents
Context Management1Documents token footprint and optimization strategies
检查项分值标准
推理要求1指定了何时需要扩展思考以获益
执行策略1记录了顺序执行与并行执行的场景
子Agent指导1确定了何时需要生成专业子Agent
上下文管理1记录了Token占用量和优化策略

Maturity Levels

成熟度等级

LevelScoreDescription
Draft0-8Missing core elements
Developing9-14Functional but incomplete
Stable15-20Production-ready
Battle-Tested21-24Has 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:
TypeDefinitionRequired Sections
diagnosticIdentifies problems, recommends interventionsStates, Diagnostic Process, Anti-Patterns
generatorProduces structured output from parametersParameters, Generation Logic, Output Formats
utilitySupports other skills, builds infrastructureProcess, Templates, Validation
orchestratorCoordinates multiple skills into autonomous workflowsOrchestration Loop, Pass Criteria, Iteration Limits
每个技能必须在前置内容中声明其类型:
yaml
metadata:
类型定义必填部分
diagnostic识别问题,推荐干预方案状态、诊断流程、反模式
generator根据参数生成结构化输出参数、生成逻辑、输出格式
utility支持其他技能,构建基础设施流程、模板、验证
orchestrator将多个技能协调为自主工作流编排循环、通过标准、迭代限制

Mode (Required)

模式(必填)

Every skill must declare its mode in frontmatter:
yaml
metadata:
ModeDefinitionUser Relationship
diagnosticIdentifies problem states and recommendsAgent diagnoses, user decides
assistiveGuides without producing contentAgent asks questions, user creates
collaborativeWorks alongside userAgent produces, user guides
evaluativeAssesses existing workAgent reviews, user responds
applicationOperates in real-time contextAgent runs, user participates
generativeCreates output from parametersAgent produces, user selects
Compound modes (e.g.,
diagnostic+generative
) are allowed when skills perform multiple functions.
每个技能必须在前置内容中声明其模式:
yaml
metadata:
模式定义用户关系
diagnostic识别问题状态并给出建议Agent诊断,用户决策
assistive提供指导但不生成内容Agent提问,用户创作
collaborative与用户协同工作Agent生成内容,用户指导
evaluative评估现有工作Agent评审,用户回应
application在实时上下文中运行Agent执行,用户参与
generative根据参数生成输出Agent生成内容,用户选择
复合模式(如
diagnostic+generative
)在技能执行多项功能时允许使用。

Optional Metadata

可选元数据

yaml
metadata:
  maturity_score: 15
yaml
metadata:
  maturity_score: 15

State Naming Convention

状态命名规范

States must follow a consistent naming pattern:
Convention:
{ABBREV}{NUMBER}: {State Name}
Rules:
  1. Abbreviation is 1-3 uppercase letters derived from skill name
  2. Numbers start at 0 (for "no X exists" states) or 1
  3. State names are descriptive, not just numbers
  4. Sub-states use decimal notation (4.5, 5.75) when inserting between existing states
Standard Abbreviations:
SkillAbbreviationExample
story-senseSSState SS1: Concept Without Foundation
dialogueDState D1: Identical Voices
conlangLState L1: No Language
worldbuildingWState W1: Backdrop World
revisionRState R1: Overwhelmed
endingsEState E1: Arbitrary Ending
character-arcCAState CA1: Static Character
scene-sequencingSQState SQ1: Scene-Only Pacing
brainstormingBState B1: Convergent Ideas
researchRSState RS1: No Research
requirements-analysisRAState RA1: Vague Requirements
system-designSDState SD1: No Architecture
chapter-drafterCD(Orchestrator - uses pass scores, not states)
New skills should claim an unused abbreviation and document it here.
状态必须遵循统一的命名模式:
规范:
{ABBREV}{NUMBER}: {State Name}
规则:
  1. 缩写为1-3个大写字母,由技能名称衍生
  2. 编号从0(表示“无X存在”状态)或1开始
  3. 状态名称具有描述性,不能仅用编号
  4. 插入现有状态之间的子状态使用十进制表示(如4.5、5.75)
标准缩写:
技能缩写示例
story-senseSSState SS1: Concept Without Foundation
dialogueDState D1: Identical Voices
conlangLState L1: No Language
worldbuildingWState W1: Backdrop World
revisionRState R1: Overwhelmed
endingsEState E1: Arbitrary Ending
character-arcCAState CA1: Static Character
scene-sequencingSQState SQ1: Scene-Only Pacing
brainstormingBState B1: Convergent Ideas
researchRSState RS1: No Research
requirements-analysisRAState RA1: Vague Requirements
system-designSDState SD1: No Architecture
chapter-drafterCD(编排技能 - 使用通过分数,而非状态)
新技能应选用未被使用的缩写并在此处记录。

Integration Graph Requirements

集成图谱要求

Every skill must document its connections to other skills.
Required Format:
markdown
undefined
每个技能必须记录与其他技能的连接。
必填格式:
markdown
undefined

Integration Graph

集成图谱

Inbound (From Other Skills)

入站(来自其他技能)

Source SkillSource StateLeads to State
story-senseSS5: Plot Without PurposeD4: No Subtext
来源技能来源状态指向状态
story-senseSS5: Plot Without PurposeD4: No Subtext

Outbound (To Other Skills)

出站(指向其他技能)

This StateLeads to SkillTarget State
D6: Pacing Mismatchscene-sequencingSQ2: Sequel Missing
当前状态指向技能目标状态
D6: Pacing Mismatchscene-sequencingSQ2: Sequel Missing

Complementary Skills

互补技能

SkillRelationship
character-arcVoice reflects transformation
worldbuildingSpeech 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 (
ultrathink
) benefits the skill:
markdown
undefined
记录何时使用扩展思考(
ultrathink
)对技能有益:
markdown
undefined

Reasoning 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
undefined

Execution 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候选

TaskAgent TypeWhen to Spawn
Codebase explorationExploreWhen skill needs project context
Framework researchgeneral-purposeWhen synthesizing across 3+ frameworks
undefined
任务Agent类型生成时机
代码库探索Explore当技能需要项目上下文时
框架研究general-purpose当综合3个以上框架时
undefined

Context Management Section

上下文管理部分

Document token usage and optimization:
markdown
undefined
记录Token使用情况和优化策略:
markdown
undefined

Context 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
  • 优先处理:当前状态诊断和即时干预
  • 延后处理:集成图谱、完整反模式列表
  • 舍弃内容:脚本源代码、历史示例
undefined

Anti-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
undefined

The {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
validate-skill.ts
to check:
  • 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
undefined

Create 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
undefined
deno run --allow-read scripts/scaffold.ts skill-name --dry-run
undefined

validate-skill.ts

validate-skill.ts

Checks skill completeness and pattern conformance.
bash
undefined
检查技能完整性和模式合规性。
bash
undefined

Validate 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
undefined
deno run --allow-read scripts/validate-skill.ts ../conlang --json
undefined

Anti-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
organization/architecture/context-packet-architecture.md
for background on oracles.
本节记录该技能可可靠验证的内容,以及需要人工判断的内容。 有关预言机的背景知识,请参阅
organization/architecture/context-packet-architecture.md

What This Skill Can Verify

可验证内容

  • Structural completeness - validate-skill.ts checks required sections exist (High confidence)
  • State naming conventions - Validates
    {ABBREV}{N}: Name
    pattern (High confidence)
  • 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

可用验证脚本

ScriptVerifiesConfidence
validate-skill.ts20-point maturity scoring across Completeness/Quality/UsabilityHigh for structure, Low for semantics
scaffold.tsGenerated files match expected structureHigh
脚本验证内容可信度
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
organization/architecture/context-packet-architecture.md
for background on feedback loops.
本节记录输出如何持久化并为后续会话提供信息。 有关反馈循环的背景知识,请参阅
organization/architecture/context-packet-architecture.md

Session Persistence

会话持久化

  • Output location:
    skills/{cluster}/{skill-name}/
    (directory structure)
  • 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
organization/architecture/context-packet-architecture.md
for background on constraints.
本节记录前提条件和边界。 有关约束的背景知识,请参阅
organization/architecture/context-packet-architecture.md

This 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:
voice-check.ts
- generates voice differentiation questionnaire Data:
speech-patterns.json
- regional, class, personality markers
脚本:
voice-check.ts
- 生成声音差异化问卷 数据:
speech-patterns.json
- 地域、阶层、性格标记

Step 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 diagnostic
bash
deno run --allow-read --allow-write scripts/scaffold.ts dialogue --type diagnostic

Output Persistence

输出持久化

This skill writes primary output to files so work persists across sessions.
该技能将主要输出写入文件,以便跨会话保留工作成果。

Output Discovery

输出位置确认

Before doing any other work:
  1. Check for
    context/output-config.md
    in the project
  2. If found, look for this skill's entry
  3. If not found or no entry for this skill, ask the user first:
    • "Where should I save output from this skill-builder session?"
    • Suggest:
      skills/{cluster}/{skill-name}/
      as the standard skill location
  4. Store the user's preference:
    • In
      context/output-config.md
      if context network exists
    • In
      .skill-builder-output.md
      at project root otherwise
在开始任何工作之前:
  1. 检查项目中是否存在
    context/output-config.md
  2. 如果存在,查找该技能的条目
  3. 如果不存在或无该技能的条目,先询问用户
    • "我应该将本次Skill-Builder会话的输出保存到哪里?"
    • 建议:
      skills/{cluster}/{skill-name}/
      作为标准技能存储位置
  4. 保存用户的偏好:
    • 如果存在上下文网络,保存到
      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 FileStays in Conversation
Generated SKILL.mdDiscussion of problem space
Script templatesState definition iteration
Data file stubsIntegration planning
Validation resultsReal-time feedback
存入文件保留在对话中
生成的SKILL.md问题领域的讨论
脚本模板状态定义的迭代过程
数据文件存根集成规划
验证结果实时反馈

File Naming

文件命名

Pattern:
skills/{cluster}/{skill-name}/
(directory structure) Example:
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
    cluster
    in frontmatter to the parent skill
  • Add integration tables mapping states between skills
  • Follow the cluster's established patterns for scripts and data
在集群内构建技能时:
  • 在前置内容中设置
    cluster
    为父技能
  • 添加集成表以映射技能间的状态转换
  • 遵循集群已有的脚本和数据模式