[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JQF5F76DSRDM0WR1CBE8ZJ":3,"skill-same:01M6JQF5F76DSRDM0WR1CBE8ZJ":98},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":6,"updatedAt":65,"install":66,"resources":79},"01M6JQF5F76DSRDM0WR1CBE8ZJ","skill_forge",null,"Use when creating new Rune skills, editing existing skills, or verifying skill quality before deployment. Applies TDD discipline to skill authoring — test before write, verify before ship.","LongLeo287\u002FOmniClaw","LongLeo287","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141803367?v=4","01M6JK75C62VCNZKR5BRZ386YV","LongLeo","01M6JK75GQ78TSP1ZPXNKK3MCH",9,"MIT","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fskill_forge\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"forge","skill forge","write","Existing","l2","opus","authoring","creation","discipline","use","edit","tdd","read","editing","quality","Bash","ship","deployment","skill authoring","test","2026-11-10 10:12:30",false,"---\nname: skill_forge\n\ndescription: Use when creating new Rune skills, editing existing skills, or verifying skill quality before deployment. Applies TDD discipline to skill authoring — test before write, verify before ship.\nmetadata:\n  author: runedev\n  version: \"1.7.0\"\n  layer: L2\n  model: opus\n  group: creation\n  tools: \"Read, Write, Edit, Bash, Glob, Grep\"\n---\n\n# skill-forge\n\n## Purpose\n\nThe skill that builds skills. Applies Test-Driven Development to skill authoring: write a pressure test first, watch agents fail without the skill, write the skill to fix those failures, then close loopholes until bulletproof. Ensures every Rune skill is battle-tested before it enters the mesh.\n\n## Triggers\n\n- `\u002Frune skill-forge` — manual invocation to create or edit a skill\n- Auto-trigger: when user says \"create a skill\", \"new skill\", \"add skill to rune\"\n- Auto-trigger: when editing any `skills\u002F*\u002FSKILL.md` file\n\n## Calls (outbound)\n\n- `scout` (L3): scan existing skills for patterns and naming conventions\n- `plan` (L2): structure complex skills with multiple phases\n- `hallucination-guard` (L3): verify referenced skills\u002Ftools actually exist\n- `verification` (L3): validate SKILL.md format compliance\n- `journal` (L3): record skill creation decisions in ADR\n\n## Called By (inbound)\n\n- `cook` (L1): when the feature being built IS a new skill\n- `scaffold` (L1): when scaffolded project includes custom skills\n\n## References\n\n- `references\u002Fclaude-skill-reference.md` — Claude Code skill system: frontmatter fields, variables, shell injection, invocation control matrix, skill type patterns (task\u002Fresearch\u002Fknowledge\u002Fdynamic), file structure, and quality checklist. Load when creating or editing any skill.\n\n## Workflow\n\n### Phase 1 — DISCOVER\n\nBefore writing anything, understand the landscape:\n\n1. **Scan existing skills** via `scout` — is this already covered?\n2. **Check for overlap** — will this duplicate or conflict with existing skills?\n3. **Identify layer** — L1 (orchestrator), L2 (workflow hub), L3 (utility)?\n4. **Identify mesh connections** — what calls this? What does this call?\n\n\u003CHARD-GATE>\nIf a skill with >70% overlap already exists → extend it, don't create new.\nThe mesh grows stronger by deepening connections, not by adding nodes.\n\u003C\u002FHARD-GATE>\n\n### Phase 2 — RED (Baseline Test)\n\n**Write the test BEFORE writing the skill.**\n\nCreate a pressure scenario that exposes the problem the skill solves:\n\n```markdown\n## Pressure Scenario: [skill-name]\n\n### Setup\n[Describe the situation an agent faces]\n\n### Pressures (combine 2-3)\n- Time pressure: \"This is urgent, just do it\"\n- Sunk cost: \"I already wrote 200 lines, can't restart\"\n- Complexity: \"Too many moving parts to follow process\"\n- Authority: \"Senior dev says skip testing\"\n- Exhaustion: \"We're 50 tool calls deep\"\n\n### Expected Failure (without skill)\n[What the agent will probably do wrong]\n\n### Success Criteria (with skill)\n[What the agent should do instead]\n```\n\nRun the scenario with a subagent WITHOUT the skill. Document:\n- **Exact behavior** — what did the agent do?\n- **Rationalizations** — verbatim excuses for skipping discipline\n- **Failure point** — where exactly did it go wrong?\n\n\u003CHARD-GATE>\nYou MUST observe at least one failure before writing the skill.\nNo failure observed = you don't understand the problem well enough to write the solution.\n\u003C\u002FHARD-GATE>\n\n### Phase 3 — GREEN (Write Minimal Skill)\n\nWrite the SKILL.md addressing ONLY the failures observed in Phase 2.\n\nFollow `docs\u002FSKILL-TEMPLATE.md` format. Required sections:\n\n| Section | Required | Purpose |\n|---|---|---|\n| Frontmatter | YES | Name, description, metadata |\n| Purpose | YES | One paragraph, ecosystem role |\n| Triggers | YES | When to invoke |\n| Calls \u002F Called By | YES | Mesh connections (control flow) |\n| Data Flow | YES | Feeds Into \u002F Fed By \u002F Feedback Loops (data flow) |\n| Workflow | YES | Step-by-step execution |\n| Output Format | YES | Structured, parseable output |\n| Constraints | YES | 3-7 MUST\u002FMUST NOT rules |\n| Sharp Edges | YES | Known failure modes |\n| Self-Validation | YES | Domain-specific QA checklist (per-skill, not centralized) |\n| Done When | YES | Verifiable completion criteria |\n| Cost Profile | YES | Token estimate |\n| Mesh Gates | L1\u002FL2 only | Progression guards |\n\n#### SKILL.md Anatomy — WHY vs HOW Split\n\nA skill file answers WHY and WHEN — not HOW. Code examples, syntax references, and implementation patterns belong in separate files:\n\n```\nskills\u002F[name]\u002F\n├── SKILL.md          ← WHY: purpose, triggers, constraints, sharp edges (~150-300 lines)\n├── references\u002F       ← HOW: code patterns, syntax tables, API examples\n│   ├── patterns.md   ← Implementation patterns with code blocks\n│   └── gotchas.md    ← Language\u002Fframework-specific pitfalls\n└── scripts\u002F          ← WHAT: deterministic operations (shell, node)\n```\n\n**Rules:**\n1. SKILL.md MUST NOT contain code blocks longer than 10 lines — move to `references\u002F`\n2. One excellent inline example (≤10 lines) is OK for clarity — more than that is a smell\n3. Format templates (Output Format section) are NOT code — they stay in SKILL.md\n4. Pressure test scenarios (Phase 2) are NOT code — they stay in SKILL.md\n5. If a skill has >3 code blocks → create `references\u002F` and extract them\n\n**Why this matters:** Code blocks in SKILL.md inflate context tokens on EVERY invocation. References are loaded only when needed. A 500-line SKILL.md with 200 lines of code examples should be a 300-line SKILL.md + a 200-line references file.\n\n\u003CHARD-GATE>\nCode blocks in SKILL.md > 10 lines = review failure.\nExtract to references\u002F or scripts\u002F. No exceptions.\n\u003C\u002FHARD-GATE>\n\n#### Frontmatter Rules\n\n```yaml\n---\nname: kebab-case-max-64-chars    # letters, numbers, hyphens only\ndescription: Use when [specific triggers]. [Symptoms that signal this skill applies].\nmetadata:\n  layer: L1|L2|L3\n  model: haiku|sonnet|opus       # haiku=scan, sonnet=code, opus=architecture\n  group: [see template]\n---\n```\n\n**Description rules (CSO Discipline):**\n- MUST start with \"Use when...\"\n- MUST describe triggering conditions, NOT workflow\n- MUST be third person\n- MUST NOT summarize what the skill does internally\n- AI reads description → decides whether to invoke → if description contains workflow summary, AI skips reading the full SKILL.md content (it thinks it already knows)\n- Test: if you can execute the skill from the description alone, the description leaks too much\n\nBad: \"Analyzes code quality through 6-step process: scan files, check patterns, run linters, compare metrics, generate report, suggest fixes\"\nGood: \"Use when code changes need quality review before commit. Symptoms: PR ready, refactor complete, pre-release check.\"\n\n```yaml\n# BAD: Summarizes workflow — agent reads description, skips full content\ndescription: TDD workflow that writes tests first, then code, then refactors\n\n# GOOD: Only triggers — agent must read full content to know workflow\ndescription: Use when implementing any feature or bugfix, before writing code\n```\n\n**Why this matters:** When description summarizes the workflow, agents take the shortcut — they follow the description and skip the full SKILL.md. Tested and confirmed.\n\n#### Writing Constraints\n\nEvery constraint MUST block a specific failure mode observed in Phase 2:\n\n```markdown\n# BAD: Generic rule\n1. MUST write good code\n\n# GOOD: Blocks specific failure with consequence\n1. MUST run tests after each fix — batch-and-pray causes cascading regressions\n```\n\n#### Anti-Rationalization Table\n\nCapture every excuse from Phase 2 baseline testing:\n\n```markdown\n| Excuse | Reality |\n|--------|---------|\n| \"[verbatim excuse from test]\" | [why it's wrong + what to do instead] |\n```\n\n### Phase 4 — VERIFY (Green Check)\n\nRun the SAME pressure scenario from Phase 2, now WITH the skill loaded.\n\nCheck:\n- Does the agent follow the skill's workflow?\n- Are all constraints respected under pressure?\n- Does the output match the defined format?\n\n\u003CHARD-GATE>\nIf agent still fails with skill loaded → skill is insufficient.\nGo back to Phase 3, strengthen the weak section. Do NOT ship.\n\u003C\u002FHARD-GATE>\n\n### Phase 5 — REFACTOR (Close Loopholes)\n\nRun additional pressure scenarios with varied pressures. For each new failure:\n\n1. Identify the rationalization\n2. Add it to the anti-rationalization table\n3. Add explicit constraint or sharp edge\n4. Re-run verification\n\nRepeat until no new failures emerge in 2 consecutive test runs.\n\n#### Pressure Types for Test Scenarios\n\nBest tests combine 3+ pressures simultaneously:\n\n| Pressure | Example Scenario |\n|----------|------------------|\n| Time | \"Emergency deployment, deadline in 30 min\" |\n| Sunk cost | \"Already wrote 200 lines, can't restart\" |\n| Authority | \"Senior dev says skip testing\" |\n| Economic | \"Customer churning, ship now or lose $50k MRR\" |\n| Exhaustion | \"50 tool calls deep, context filling up\" |\n| Social | \"Looking dogmatic by insisting on process\" |\n| Pragmatic | \"Being practical vs being pedantic\" |\n\n#### Scenario Quality Requirements\n\n1. **Concrete A\u002FB\u002FC options** — force explicit choice (no \"I'd ask the user\" escape hatch)\n2. **Real constraints** — specific times, actual consequences, named files\n3. **Real file paths** — `\u002Ftmp\u002Fpayment-system` not \"a project\"\n4. **\"Make agent ACT\"** — \"What do you do?\" not \"What should you do?\"\n5. **No easy outs** — every option has a cost\n\n#### Meta-Testing (When GREEN Isn't Working)\n\nIf the agent keeps failing even WITH the skill loaded, ask: \"How could that skill have been written differently to make the correct option crystal clear?\"\n\nThree possible responses:\n1. \"Skill was clear, I chose to ignore it\" → foundational principle needed (stronger HARD-GATE)\n2. \"Skill should have said X explicitly\" → add that exact phrasing verbatim\n3. \"I didn't see section Y\" → reorganize for discoverability (move up, add header)\n\n#### Bulletproof Criteria\n\nA skill is bulletproof when:\n- Agent chooses correct option under maximum pressure (3+ pressures combined)\n- Agent CITES skill sections as justification for its choice\n- Agent ACKNOWLEDGES the temptation but follows the rule anyway\n\n#### Persuasion Principles for Skill Language\n\nResearch (Meincke et al., 2025, 28,000 conversations) shows 33% → 72% compliance with these techniques:\n\n| Principle | Application | Use For |\n|-----------|-------------|---------|\n| Authority | \"YOU MUST\", imperative language | Eliminates decision fatigue, safety-critical rules |\n| Commitment | Explicit announcements + tracked choices | Creates accountability trail |\n| Scarcity | Time-bound requirements, \"before proceeding\" | Triggers immediate action |\n| Social Proof | \"Every time\", universal statements | Documents what prevents failures |\n| Unity | \"We're building quality\" language | Shared identity, quality goals |\n\n**Prohibited in skills:**\n- **Liking** (\"Great job following the process!\") → creates sycophancy\n- **Reciprocity** (\"I helped you, now follow the rules\") → feels manipulative\n\n**Ethical test**: Would this serve the user's genuine interests if they fully understood the technique?\n\n### Phase 5.5 — SECURITY MODEL\n\nEvery skill that touches external systems, user data, or destructive operations MUST define an explicit Security Model section. This is a contract — not aspirational, but testable.\n\n**Add to SKILL.md after Sharp Edges:**\n\n```markdown\n## Security Model\n\n### Trust Boundaries\n- [What this skill reads] — e.g., \"Reads .env files, user source code, git history\"\n- [What this skill writes] — e.g., \"Writes to .rune\u002F only, never modifies source code\"\n- [What this skill executes] — e.g., \"Runs npm test, never runs arbitrary shell commands\"\n\n### This Skill Will NEVER\n- [Explicit denial 1] — e.g., \"Execute user-provided strings as shell commands\"\n- [Explicit denial 2] — e.g., \"Read or log credential files (.env, secrets.json)\"\n- [Explicit denial 3] — e.g., \"Send data to external endpoints\"\n\n### Threat Surface\n| Threat | Mitigated By |\n|--------|-------------|\n| Prompt injection via user input | Input validated before processing |\n| Credential exposure in output | Secrets pattern detection before emit |\n| Destructive operation on wrong target | Confirmation gate before delete\u002Foverwrite |\n```\n\n**When to require Security Model:**\n- Skill uses `Bash` tool → REQUIRED (can execute arbitrary commands)\n- Skill reads `.env` or credentials → REQUIRED\n- Skill writes\u002Fdeletes files outside `.rune\u002F` → REQUIRED\n- Skill calls external APIs or MCP tools → REQUIRED\n- Skill is read-only analysis (review, audit, scout) → OPTIONAL but recommended\n\n**Eval integration**: Phase 7 evals for skills with Security Model MUST include:\n- E05: Attempt to make skill execute unintended command\n- E06: Attempt to make skill expose credentials in output\n- E07: Attempt to make skill write outside its declared boundary\n\nIf Security Model is required but missing → Phase 7 EVAL HARD-GATE blocks ship.\n\n### Phase 6 — INTEGRATE\n\nWire the skill into the mesh:\n\n1. **Update `docs\u002FARCHITECTURE.md`** — add to correct layer\u002Fgroup table\n2. **Update `CLAUDE.md`** — increment skill count, add to layer list\n3. **Add mesh connections** — update SKILL.md of skills that should call\u002Fbe called by this one\n4. **Map data flow** — identify which skills consume this skill's output (Feeds Into) and which skills' outputs this skill needs (Fed By). Look for feedback loops where two skills refine each other's work\n5. **Write Self-Validation** — 3-5 domain-specific checks unique to this skill's output. Ask: \"What quality issues can ONLY this skill catch?\"\n6. **Verify no conflicts** — new skill's output format compatible with consumers?\n\n### Phase 6.5 — EXTENSION AUTHORING (if building an extension, not a skill)\n\nExtensions augment existing skills with optional capabilities. Unlike skills (standalone workflow units) or packs (domain bundles), extensions ADD features to skills that already exist — without modifying the core skill file.\n\n#### Extension vs Skill vs Pack\n\n| Concept | Purpose | Modifies Core? | Self-contained? |\n|---------|---------|----------------|-----------------|\n| **Skill** | Standalone workflow unit (SKILL.md) | N\u002FA — IS core | Yes |\n| **Pack** | Domain bundle of skills (PACK.md) | No — bundles existing | Yes |\n| **Extension** | Augments existing skill with new capability | No — additive only | Yes — own dir with install\u002Funinstall |\n\n#### Extension Directory Structure\n\n```\nextensions\u002F\u003Cextension-name>\u002F\n├── EXTENSION.md           # Manifest: what it extends, how, dependencies\n├── install.sh             # Unix installer (non-destructive MCP merge)\n├── install.ps1            # Windows installer\n├── uninstall.sh           # Clean removal\n├── uninstall.ps1          # Clean removal (Windows)\n├── skills\u002F\n│   └── \u003Cskill-name>\u002F\n│       └── SKILL.md       # New skill added by extension\n├── agents\u002F                # Optional subagent definitions\n│   └── \u003Cagent-name>.md\n├── references\u002F            # Domain knowledge loaded by extension skills\n│   └── \u003Ctopic>.md\n├── scripts\u002F               # Executable utilities\n│   └── \u003Cscript>.py|.sh\n└── docs\u002F\n    └── SETUP.md           # Extension-specific configuration guide\n```\n\n#### EXTENSION.md Manifest\n\n```yaml\n---\nname: \"\u003Cextension-name>\"\nextends: \"\u003Ctarget-skill-or-pack>\"\ndescription: \"What capability this extension adds\"\nrequires:\n  - mcp: \"\u003Cmcp-server-name>\"        # Optional: MCP server dependency\n  - skill: \"\u003Crequired-skill-name>\"   # Required core skill\ninstall_method: \"non-destructive\"    # MUST be non-destructive\n---\n```\n\n#### Extension Rules\n\n1. **Non-destructive install** — extension MUST NOT modify existing skill files. It adds new files alongside.\n2. **Self-contained** — removing the extension directory restores the system to its pre-install state.\n3. **MCP merge** — if the extension adds MCP tools, install script MUST merge into settings.json without overwriting existing entries.\n4. **Fallback graceful** — if the MCP server or external dependency is unavailable, the extension skill MUST degrade gracefully (report unavailability, don't crash).\n5. **Cost awareness** — if the extension calls paid APIs, the extension skill MUST warn before expensive operations and track usage.\n6. **Pre-flight check** — extension skill Step 1 MUST verify dependencies are available before executing.\n\n#### When to Build an Extension (vs a Skill or Pack)\n\n- Build an **extension** when: the capability requires an external API\u002FMCP, is optional, and augments an existing skill\n- Build a **skill** when: the capability is self-contained and fits a layer in the mesh\n- Build a **pack** when: you're bundling multiple related skills for a domain\n\n### Phase 7 — EVAL (Behavior Tests)\n\nBefore shipping, write **Eval Scenarios** — behavior tests for the SKILL.md itself. These are \"unit tests for skill files, not code.\"\n\nSave evals to `skills\u002F\u003Cname>\u002Fevals.md`. Minimum 4 evals per skill:\n\n| Eval ID | Category | Required? |\n|---------|----------|-----------|\n| E01 | Happy path — core workflow | YES |\n| E02 | Edge case — unusual\u002Fempty input | YES |\n| E03 | Adversarial — pressure scenario | YES |\n| E04 | Jailbreak\u002Finjection attempt | YES for security-critical skills |\n\nEach eval follows the format defined in `rune:test` → \"Skill Behavior Tests\" section:\n- **Prompt**: exact situation the agent faces\n- **Expected Reasoning**: step-by-step reasoning agent SHOULD follow\n- **Must Include**: what the output MUST contain or do\n- **Must NOT**: anti-patterns the output MUST NOT produce\n\nRun each eval with a subagent. An eval FAILS if the agent produces a Must NOT output.\n\n**Pre-ship gate**: At least E01–E03 must PASS before committing. Security-critical skills (touching auth\u002Fsecrets\u002Fdestructive ops) require 8+ evals including jailbreak and credential-leak scenarios.\n\nAlso run the **Skill Content Security Guard** (sentinel Step 3.5) on the new SKILL.md content before commit — blocks destructive ops, prompt injection, and jailbreak patterns embedded in skill instructions.\n\n\u003CHARD-GATE>\nNo evals.md → skill is behavior-untested. Do NOT ship untested skills.\nEval file with 0 passing evals = same as no evals.\n\u003C\u002FHARD-GATE>\n\n### Phase 8 — SHIP\n\n```bash\ngit add skills\u002F[skill-name]\u002FSKILL.md\ngit add skills\u002F[skill-name]\u002Fevals.md\ngit add docs\u002FARCHITECTURE.md CLAUDE.md\n# Add any updated existing skills\ngit commit -m \"feat: add [skill-name] — [one-line purpose]\"\n```\n\n## Skill Quality Checklist\n\n**Format:**\n- [ ] Name is kebab-case, max 64 chars, letters\u002Fnumbers\u002Fhyphens only\n- [ ] Description starts with \"Use when...\", does NOT summarize workflow\n- [ ] All template sections present\n- [ ] Constraints are specific (not generic \"write good code\")\n- [ ] Sharp edges have severity + mitigation\n\n**Content:**\n- [ ] Baseline test run BEFORE skill was written\n- [ ] At least one observed failure documented\n- [ ] Anti-rationalization table from real test failures\n- [ ] Mesh connections bidirectional (calls AND called-by both updated)\n- [ ] Data flow mapped (Feeds Into \u002F Fed By \u002F Feedback Loops)\n- [ ] Self-Validation has 3-5 domain-specific checks (not generic)\n- [ ] Output format is structured and parseable by other skills\n- [ ] `evals.md` written with at least 3 passing eval scenarios (E01 happy-path, E02 edge-case, E03 adversarial)\n- [ ] Skill Content Security Guard passed (sentinel Step 3.5 — no destructive ops or injection patterns in SKILL.md)\n\n**Architecture:**\n- [ ] Layer assignment correct (L1=orchestrate, L2=workflow, L3=utility)\n- [ ] Model assignment correct (haiku=scan, sonnet=code, opus=architect)\n- [ ] No >70% overlap with existing skills\n- [ ] ARCHITECTURE.md updated\n- [ ] CLAUDE.md updated\n\n**Extension-specific (if building an extension):**\n- [ ] EXTENSION.md manifest present with extends, requires, install_method\n- [ ] install.sh + install.ps1 tested (non-destructive merge)\n- [ ] uninstall.sh + uninstall.ps1 tested (clean removal)\n- [ ] Extension skill has dependency pre-flight check (Step 1)\n- [ ] Fallback behavior documented when external dependency unavailable\n- [ ] Cost warning present if extension calls paid APIs\n\n## Adapting Existing Skills\n\nWhen editing, not creating:\n\n\u003CHARD-GATE>\nSame TDD cycle applies to edits.\n1. Write a test that exposes the gap in the current skill\n2. Run baseline — confirm the skill fails on this scenario\n3. Edit the skill to address the gap\n4. Verify the edit fixes the gap WITHOUT breaking existing behavior\n\u003C\u002FHARD-GATE>\n\n\"Just adding a section\" is not an excuse to skip testing.\n\n## Token Efficiency Guidelines\n\nSkills are loaded into context when invoked. Every word costs tokens.\n\n| Skill Type | Target | Notes |\n|---|---|---|\n| L3 utility (haiku) | \u003C300 words | Runs frequently, keep lean |\n| L2 workflow hub | \u003C500 words | Moderate frequency |\n| L1 orchestrator | \u003C800 words | Runs once per workflow |\n| Reference sections | Extract to separate file | >100 lines → own file |\n\nTechniques:\n- Reference `--help` instead of documenting all flags\n- Cross-reference other skills instead of repeating content\n- One excellent example > three mediocre ones\n- Inline code only if \u003C50 lines, otherwise separate file\n\n## Output Format\n\n```\n## Skill Forge Report\n- **Skill**: [name] (L[layer])\n- **Action**: CREATE | EDIT\n- **Status**: SHIPPED | NEEDS_WORK | BLOCKED\n\n### Baseline Test\n- Scenario: [test scenario description]\n- Result WITHOUT skill: [observed failure]\n- Result WITH skill: [observed success or remaining gap]\n\n### Quality Checklist\n- Format: [pass\u002Ffail count]\n- Content: [pass\u002Ffail count]\n- Architecture: [pass\u002Ffail count]\n\n### Files Created\u002FModified\n- skills\u002F[name]\u002FSKILL.md — [created | modified]\n- docs\u002FARCHITECTURE.md — [updated | skipped]\n- CLAUDE.md — [updated | skipped]\n\n### Mesh Impact\n- New connections: [count] ([list of skills])\n- Bidirectional check: PASS | FAIL\n- Data flow mapped: [count] feeds-into, [count] fed-by, [count] feedback loops\n- Self-Validation: [count] domain-specific checks written\n```\n\n## Constraints\n\n1. MUST run baseline test BEFORE writing skill — no skill without observed failure\n2. MUST verify skill fixes the observed failures — green check required before ship\n3. MUST NOT create skill with >70% overlap with existing — extend instead\n4. MUST follow SKILL-TEMPLATE.md format — all required sections present\n5. MUST update ARCHITECTURE.md and CLAUDE.md on every new skill\n6. MUST NOT ship skill that fails its own pressure test\n7. MUST write description as triggers only — never summarize workflow in description\n\n## Sharp Edges\n\n| Failure Mode | Severity | Mitigation |\n|---|---|---|\n| Writing skill without baseline test | CRITICAL | Phase 2 HARD-GATE: must observe failure first |\n| Description summarizes workflow → agents skip content | HIGH | Phase 3 description rules: \"Use when...\" triggers only |\n| New skill duplicates existing skill | HIGH | Phase 1 HARD-GATE: >70% overlap → extend, don't create |\n| Skill passes test but breaks mesh connections | MEDIUM | Phase 6 integration: verify output compatibility |\n| Editing skill without testing the edit | MEDIUM | Adapting section: same TDD cycle for edits |\n| Overly verbose skill burns context tokens | MEDIUM | Token efficiency guidelines: layer-based word targets |\n| Code blocks in SKILL.md bloat every invocation | HIGH | WHY vs HOW split: SKILL.md ≤10-line code blocks, extract rest to references\u002F |\n| Writing skill without TDD (no observed failures first) | CRITICAL | Skill TDD: RED (run scenario WITHOUT skill → document failures) → GREEN (write skill targeting failures) → REFACTOR (find bypasses → add blocks) |\n| Description leaks workflow → agent skips full content | HIGH | CSO Discipline: description = triggers only. Test: can you execute from description alone? If yes, it leaks too much |\n| Self-Validation copies completion-gate checks | HIGH | Self-Validation is DOMAIN-specific: \"assertions per test\", \"dependency ordering\". NOT generic: \"tests pass\", \"build succeeds\" — those belong to completion-gate |\n| Data Flow confused with Calls | MEDIUM | Calls = runtime invocation (skill A calls skill B). Feeds Into = artifact persistence (skill A writes .rune\u002FX.md, skill B reads it later). If it's a direct function call → Calls. If it's via files\u002Fcontext → Data Flow |\n| Feedback Loop missing one direction | MEDIUM | Every Feedback Loop ↻ must document BOTH directions: what A sends to B AND what B sends back to A. One-way = Feeds Into, not a loop |\n\n## Done When\n\n- Baseline test documented with observed failures (TDD RED phase)\n- SKILL.md follows template format completely\n- Skill passes pressure test (agent complies with skill loaded)\n- No new failures in 2 consecutive varied-pressure test runs\n- Mesh connections wired (ARCHITECTURE.md, CLAUDE.md, related skills)\n- Git committed with conventional commit message\n\n## Returns\n\n| Artifact | Format | Location |\n|----------|--------|----------|\n| New or updated skill file | Markdown (SKILL.md) | `skills\u002F\u003Cname>\u002FSKILL.md` |\n| Eval scenarios | Markdown | `skills\u002F\u003Cname>\u002Fevals.md` |\n| Reference files (if needed) | Markdown | `skills\u002F\u003Cname>\u002Freferences\u002F` |\n| Architecture docs update | Markdown | `docs\u002FARCHITECTURE.md` |\n| Skill Forge Report | Markdown | inline |\n\n## Cost Profile\n\n~3000-8000 tokens per skill creation (opus for Phase 2-5 reasoning, haiku for scout\u002Fverification). Most cost is in the iterative test-refine loop (Phase 4-5). Budget 2-4 test iterations per skill.\n\n**Scope guardrail:** skill-forge authors and tests skill files — it does not implement the features those skills describe.\n","# skill-forge\n\n## Purpose\n\nThe skill that builds skills. Applies Test-Driven Development to skill authoring: write a pressure test first, watch agents fail without the skill, write the skill to fix those failures, then close loopholes until bulletproof. Ensures every Rune skill is battle-tested before it enters the mesh.\n\n## Triggers\n\n- `\u002Frune skill-forge` — manual invocation to create or edit a skill\n- Auto-trigger: when user says \"create a skill\", \"new skill\", \"add skill to rune\"\n- Auto-trigger: when editing any `skills\u002F*\u002FSKILL.md` file\n\n## Calls (outbound)\n\n- `scout` (L3): scan existing skills for patterns and naming conventions\n- `plan` (L2): structure complex skills with multiple phases\n- `hallucination-guard` (L3): verify referenced skills\u002Ftools actually exist\n- `verification` (L3): validate SKILL.md format compliance\n- `journal` (L3): record skill creation decisions in ADR\n\n## Called By (inbound)\n\n- `cook` (L1): when the feature being built IS a new skill\n- `scaffold` (L1): when scaffolded project includes custom skills\n\n## References\n\n- `references\u002Fclaude-skill-reference.md` — Claude Code skill system: frontmatter fields, variables, shell injection, invocation control matrix, skill type patterns (task\u002Fresearch\u002Fknowledge\u002Fdynamic), file structure, and quality checklist. Load when creating or editing any skill.\n\n## Workflow\n\n### Phase 1 — DISCOVER\n\nBefore writing anything, understand the landscape:\n\n1. **Scan existing skills** via `scout` — is this already covered?\n2. **Check for overlap** — will this duplicate or conflict with existing skills?\n3. **Identify layer** — L1 (orchestrator), L2 (workflow hub), L3 (utility)?\n4. **Identify mesh connections** — what calls this? What does this call?\n\n\u003CHARD-GATE>\nIf a skill with >70% overlap already exists → extend it, don't create new.\nThe mesh grows stronger by deepening connections, not by adding nodes.\n\u003C\u002FHARD-GATE>\n\n### Phase 2 — RED (Baseline Test)\n\n**Write the test BEFORE writing the skill.**\n\nCreate a pressure scenario that exposes the problem the skill solves:\n\n```markdown\n## Pressure Scenario: [skill-name]\n\n### Setup\n[Describe the situation an agent faces]\n\n### Pressures (combine 2-3)\n- Time pressure: \"This is urgent, just do it\"\n- Sunk cost: \"I already wrote 200 lines, can't restart\"\n- Complexity: \"Too many moving parts to follow process\"\n- Authority: \"Senior dev says skip testing\"\n- Exhaustion: \"We're 50 tool calls deep\"\n\n### Expected Failure (without skill)\n[What the agent will probably do wrong]\n\n### Success Criteria (with skill)\n[What the agent should do instead]\n```\n\nRun the scenario with a subagent WITHOUT the skill. Document:\n- **Exact behavior** — what did the agent do?\n- **Rationalizations** — verbatim excuses for skipping discipline\n- **Failure point** — where exactly did it go wrong?\n\n\u003CHARD-GATE>\nYou MUST observe at least one failure before writing the skill.\nNo failure observed = you don't understand the problem well enough to write the solution.\n\u003C\u002FHARD-GATE>\n\n### Phase 3 — GREEN (Write Minimal Skill)\n\nWrite the SKILL.md addressing ONLY the failures observed in Phase 2.\n\nFollow `docs\u002FSKILL-TEMPLATE.md` format. Required sections:\n\n| Section | Required | Purpose |\n|---|---|---|\n| Frontmatter | YES | Name, description, metadata |\n| Purpose | YES | One paragraph, ecosystem role |\n| Triggers | YES | When to invoke |\n| Calls \u002F Called By | YES | Mesh connections (control flow) |\n| Data Flow | YES | Feeds Into \u002F Fed By \u002F Feedback Loops (data flow) |\n| Workflow | YES | Step-by-step execution |\n| Output Format | YES | Structured, parseable output |\n| Constraints | YES | 3-7 MUST\u002FMUST NOT rules |\n| Sharp Edges | YES | Known failure modes |\n| Self-Validation | YES | Domain-specific QA checklist (per-skill, not centralized) |\n| Done When | YES | Verifiable completion criteria |\n| Cost Profile | YES | Token estimate |\n| Mesh Gates | L1\u002FL2 only | Progression guards |\n\n#### SKILL.md Anatomy — WHY vs HOW Split\n\nA skill file answers WHY and WHEN — not HOW. Code examples, syntax references, and implementation patterns belong in separate files:\n\n```\nskills\u002F[name]\u002F\n├── SKILL.md          ← WHY: purpose, triggers, constraints, sharp edges (~150-300 lines)\n├── references\u002F       ← HOW: code patterns, syntax tables, API examples\n│   ├── patterns.md   ← Implementation patterns with code blocks\n│   └── gotchas.md    ← Language\u002Fframework-specific pitfalls\n└── scripts\u002F          ← WHAT: deterministic operations (shell, node)\n```\n\n**Rules:**\n1. SKILL.md MUST NOT contain code blocks longer than 10 lines — move to `references\u002F`\n2. One excellent inline example (≤10 lines) is OK for clarity — more than that is a smell\n3. Format templates (Output Format section) are NOT code — they stay in SKILL.md\n4. Pressure test scenarios (Phase 2) are NOT code — they stay in SKILL.md\n5. If a skill has >3 code blocks → create `references\u002F` and extract them\n\n**Why this matters:** Code blocks in SKILL.md inflate context tokens on EVERY invocation. References are loaded only when needed. A 500-line SKILL.md with 200 lines of code examples should be a 300-line SKILL.md + a 200-line references file.\n\n\u003CHARD-GATE>\nCode blocks in SKILL.md > 10 lines = review failure.\nExtract to references\u002F or scripts\u002F. No exceptions.\n\u003C\u002FHARD-GATE>\n\n#### Frontmatter Rules\n\n```yaml\n---\nname: kebab-case-max-64-chars    # letters, numbers, hyphens only\ndescription: Use when [specific triggers]. [Symptoms that signal this skill applies].\nmetadata:\n  layer: L1|L2|L3\n  model: haiku|sonnet|opus       # haiku=scan, sonnet=code, opus=architecture\n  group: [see template]\n---\n```\n\n**Description rules (CSO Discipline):**\n- MUST start with \"Use when...\"\n- MUST describe triggering conditions, NOT workflow\n- MUST be third person\n- MUST NOT summarize what the skill does internally\n- AI reads description → decides whether to invoke → if description contains workflow summary, AI skips reading the full SKILL.md content (it thinks it already knows)\n- Test: if you can execute the skill from the description alone, the description leaks too much\n\nBad: \"Analyzes code quality through 6-step process: scan files, check patterns, run linters, compare metrics, generate report, suggest fixes\"\nGood: \"Use when code changes need quality review before commit. Symptoms: PR ready, refactor complete, pre-release check.\"\n\n```yaml\n# BAD: Summarizes workflow — agent reads description, skips full content\ndescription: TDD workflow that writes tests first, then code, then refactors\n\n# GOOD: Only triggers — agent must read full content to know workflow\ndescription: Use when implementing any feature or bugfix, before writing code\n```\n\n**Why this matters:** When description summarizes the workflow, agents take the shortcut — they follow the description and skip the full SKILL.md. Tested and confirmed.\n\n#### Writing Constraints\n\nEvery constraint MUST block a specific failure mode observed in Phase 2:\n\n```markdown\n# BAD: Generic rule\n1. MUST write good code\n\n# GOOD: Blocks specific failure with consequence\n1. MUST run tests after each fix — batch-and-pray causes cascading regressions\n```\n\n#### Anti-Rationalization Table\n\nCapture every excuse from Phase 2 baseline testing:\n\n```markdown\n| Excuse | Reality |\n|--------|---------|\n| \"[verbatim excuse from test]\" | [why it's wrong + what to do instead] |\n```\n\n### Phase 4 — VERIFY (Green Check)\n\nRun the SAME pressure scenario from Phase 2, now WITH the skill loaded.\n\nCheck:\n- Does the agent follow the skill's workflow?\n- Are all constraints respected under pressure?\n- Does the output match the defined format?\n\n\u003CHARD-GATE>\nIf agent still fails with skill loaded → skill is insufficient.\nGo back to Phase 3, strengthen the weak section. Do NOT ship.\n\u003C\u002FHARD-GATE>\n\n### Phase 5 — REFACTOR (Close Loopholes)\n\nRun additional pressure scenarios with varied pressures. For each new failure:\n\n1. Identify the rationalization\n2. Add it to the anti-rationalization table\n3. Add explicit constraint or sharp edge\n4. Re-run verification\n\nRepeat until no new failures emerge in 2 consecutive test runs.\n\n#### Pressure Types for Test Scenarios\n\nBest tests combine 3+ pressures simultaneously:\n\n| Pressure | Example Scenario |\n|----------|------------------|\n| Time | \"Emergency deployment, deadline in 30 min\" |\n| Sunk cost | \"Already wrote 200 lines, can't restart\" |\n| Authority | \"Senior dev says skip testing\" |\n| Economic | \"Customer churning, ship now or lose $50k MRR\" |\n| Exhaustion | \"50 tool calls deep, context filling up\" |\n| Social | \"Looking dogmatic by insisting on process\" |\n| Pragmatic | \"Being practical vs being pedantic\" |\n\n#### Scenario Quality Requirements\n\n1. **Concrete A\u002FB\u002FC options** — force explicit choice (no \"I'd ask the user\" escape hatch)\n2. **Real constraints** — specific times, actual consequences, named files\n3. **Real file paths** — `\u002Ftmp\u002Fpayment-system` not \"a project\"\n4. **\"Make agent ACT\"** — \"What do you do?\" not \"What should you do?\"\n5. **No easy outs** — every option has a cost\n\n#### Meta-Testing (When GREEN Isn't Working)\n\nIf the agent keeps failing even WITH the skill loaded, ask: \"How could that skill have been written differently to make the correct option crystal clear?\"\n\nThree possible responses:\n1. \"Skill was clear, I chose to ignore it\" → foundational principle needed (stronger HARD-GATE)\n2. \"Skill should have said X explicitly\" → add that exact phrasing verbatim\n3. \"I didn't see section Y\" → reorganize for discoverability (move up, add header)\n\n#### Bulletproof Criteria\n\nA skill is bulletproof when:\n- Agent chooses correct option under maximum pressure (3+ pressures combined)\n- Agent CITES skill sections as justification for its choice\n- Agent ACKNOWLEDGES the temptation but follows the rule anyway\n\n#### Persuasion Principles for Skill Language\n\nResearch (Meincke et al., 2025, 28,000 conversations) shows 33% → 72% compliance with these techniques:\n\n| Principle | Application | Use For |\n|-----------|-------------|---------|\n| Authority | \"YOU MUST\", imperative language | Eliminates decision fatigue, safety-critical rules |\n| Commitment | Explicit announcements + tracked choices | Creates accountability trail |\n| Scarcity | Time-bound requirements, \"before proceeding\" | Triggers immediate action |\n| Social Proof | \"Every time\", universal statements | Documents what prevents failures |\n| Unity | \"We're building quality\" language | Shared identity, quality goals |\n\n**Prohibited in skills:**\n- **Liking** (\"Great job following the process!\") → creates sycophancy\n- **Reciprocity** (\"I helped you, now follow the rules\") → feels manipulative\n\n**Ethical test**: Would this serve the user's genuine interests if they fully understood the technique?\n\n### Phase 5.5 — SECURITY MODEL\n\nEvery skill that touches external systems, user data, or destructive operations MUST define an explicit Security Model section. This is a contract — not aspirational, but testable.\n\n**Add to SKILL.md after Sharp Edges:**\n\n```markdown\n## Security Model\n\n### Trust Boundaries\n- [What this skill reads] — e.g., \"Reads .env files, user source code, git history\"\n- [What this skill writes] — e.g., \"Writes to .rune\u002F only, never modifies source code\"\n- [What this skill executes] — e.g., \"Runs npm test, never runs arbitrary shell commands\"\n\n### This Skill Will NEVER\n- [Explicit denial 1] — e.g., \"Execute user-provided strings as shell commands\"\n- [Explicit denial 2] — e.g., \"Read or log credential files (.env, secrets.json)\"\n- [Explicit denial 3] — e.g., \"Send data to external endpoints\"\n\n### Threat Surface\n| Threat | Mitigated By |\n|--------|-------------|\n| Prompt injection via user input | Input validated before processing |\n| Credential exposure in output | Secrets pattern detection before emit |\n| Destructive operation on wrong target | Confirmation gate before delete\u002Foverwrite |\n```\n\n**When to require Security Model:**\n- Skill uses `Bash` tool → REQUIRED (can execute arbitrary commands)\n- Skill reads `.env` or credentials → REQUIRED\n- Skill writes\u002Fdeletes files outside `.rune\u002F` → REQUIRED\n- Skill calls external APIs or MCP tools → REQUIRED\n- Skill is read-only analysis (review, audit, scout) → OPTIONAL but recommended\n\n**Eval integration**: Phase 7 evals for skills with Security Model MUST include:\n- E05: Attempt to make skill execute unintended command\n- E06: Attempt to make skill expose credentials in output\n- E07: Attempt to make skill write outside its declared boundary\n\nIf Security Model is required but missing → Phase 7 EVAL HARD-GATE blocks ship.\n\n### Phase 6 — INTEGRATE\n\nWire the skill into the mesh:\n\n1. **Update `docs\u002FARCHITECTURE.md`** — add to correct layer\u002Fgroup table\n2. **Update `CLAUDE.md`** — increment skill count, add to layer list\n3. **Add mesh connections** — update SKILL.md of skills that should call\u002Fbe called by this one\n4. **Map data flow** — identify which skills consume this skill's output (Feeds Into) and which skills' outputs this skill needs (Fed By). Look for feedback loops where two skills refine each other's work\n5. **Write Self-Validation** — 3-5 domain-specific checks unique to this skill's output. Ask: \"What quality issues can ONLY this skill catch?\"\n6. **Verify no conflicts** — new skill's output format compatible with consumers?\n\n### Phase 6.5 — EXTENSION AUTHORING (if building an extension, not a skill)\n\nExtensions augment existing skills with optional capabilities. Unlike skills (standalone workflow units) or packs (domain bundles), extensions ADD features to skills that already exist — without modifying the core skill file.\n\n#### Extension vs Skill vs Pack\n\n| Concept | Purpose | Modifies Core? | Self-contained? |\n|---------|---------|----------------|-----------------|\n| **Skill** | Standalone workflow unit (SKILL.md) | N\u002FA — IS core | Yes |\n| **Pack** | Domain bundle of skills (PACK.md) | No — bundles existing | Yes |\n| **Extension** | Augments existing skill with new capability | No — additive only | Yes — own dir with install\u002Funinstall |\n\n#### Extension Directory Structure\n\n```\nextensions\u002F\u003Cextension-name>\u002F\n├── EXTENSION.md           # Manifest: what it extends, how, dependencies\n├── install.sh             # Unix installer (non-destructive MCP merge)\n├── install.ps1            # Windows installer\n├── uninstall.sh           # Clean removal\n├── uninstall.ps1          # Clean removal (Windows)\n├── skills\u002F\n│   └── \u003Cskill-name>\u002F\n│       └── SKILL.md       # New skill added by extension\n├── agents\u002F                # Optional subagent definitions\n│   └── \u003Cagent-name>.md\n├── references\u002F            # Domain knowledge loaded by extension skills\n│   └── \u003Ctopic>.md\n├── scripts\u002F               # Executable utilities\n│   └── \u003Cscript>.py|.sh\n└── docs\u002F\n    └── SETUP.md           # Extension-specific configuration guide\n```\n\n#### EXTENSION.md Manifest\n\n```yaml\n---\nname: \"\u003Cextension-name>\"\nextends: \"\u003Ctarget-skill-or-pack>\"\ndescription: \"What capability this extension adds\"\nrequires:\n  - mcp: \"\u003Cmcp-server-name>\"        # Optional: MCP server dependency\n  - skill: \"\u003Crequired-skill-name>\"   # Required core skill\ninstall_method: \"non-destructive\"    # MUST be non-destructive\n---\n```\n\n#### Extension Rules\n\n1. **Non-destructive install** — extension MUST NOT modify existing skill files. It adds new files alongside.\n2. **Self-contained** — removing the extension directory restores the system to its pre-install state.\n3. **MCP merge** — if the extension adds MCP tools, install script MUST merge into settings.json without overwriting existing entries.\n4. **Fallback graceful** — if the MCP server or external dependency is unavailable, the extension skill MUST degrade gracefully (report unavailability, don't crash).\n5. **Cost awareness** — if the extension calls paid APIs, the extension skill MUST warn before expensive operations and track usage.\n6. **Pre-flight check** — extension skill Step 1 MUST verify dependencies are available before executing.\n\n#### When to Build an Extension (vs a Skill or Pack)\n\n- Build an **extension** when: the capability requires an external API\u002FMCP, is optional, and augments an existing skill\n- Build a **skill** when: the capability is self-contained and fits a layer in the mesh\n- Build a **pack** when: you're bundling multiple related skills for a domain\n\n### Phase 7 — EVAL (Behavior Tests)\n\nBefore shipping, write **Eval Scenarios** — behavior tests for the SKILL.md itself. These are \"unit tests for skill files, not code.\"\n\nSave evals to `skills\u002F\u003Cname>\u002Fevals.md`. Minimum 4 evals per skill:\n\n| Eval ID | Category | Required? |\n|---------|----------|-----------|\n| E01 | Happy path — core workflow | YES |\n| E02 | Edge case — unusual\u002Fempty input | YES |\n| E03 | Adversarial — pressure scenario | YES |\n| E04 | Jailbreak\u002Finjection attempt | YES for security-critical skills |\n\nEach eval follows the format defined in `rune:test` → \"Skill Behavior Tests\" section:\n- **Prompt**: exact situation the agent faces\n- **Expected Reasoning**: step-by-step reasoning agent SHOULD follow\n- **Must Include**: what the output MUST contain or do\n- **Must NOT**: anti-patterns the output MUST NOT produce\n\nRun each eval with a subagent. An eval FAILS if the agent produces a Must NOT output.\n\n**Pre-ship gate**: At least E01–E03 must PASS before committing. Security-critical skills (touching auth\u002Fsecrets\u002Fdestructive ops) require 8+ evals including jailbreak and credential-leak scenarios.\n\nAlso run the **Skill Content Security Guard** (sentinel Step 3.5) on the new SKILL.md content before commit — blocks destructive ops, prompt injection, and jailbreak patterns embedded in skill instructions.\n\n\u003CHARD-GATE>\nNo evals.md → skill is behavior-untested. Do NOT ship untested skills.\nEval file with 0 passing evals = same as no evals.\n\u003C\u002FHARD-GATE>\n\n### Phase 8 — SHIP\n\n```bash\ngit add skills\u002F[skill-name]\u002FSKILL.md\ngit add skills\u002F[skill-name]\u002Fevals.md\ngit add docs\u002FARCHITECTURE.md CLAUDE.md\n# Add any updated existing skills\ngit commit -m \"feat: add [skill-name] — [one-line purpose]\"\n```\n\n## Skill Quality Checklist\n\n**Format:**\n- [ ] Name is kebab-case, max 64 chars, letters\u002Fnumbers\u002Fhyphens only\n- [ ] Description starts with \"Use when...\", does NOT summarize workflow\n- [ ] All template sections present\n- [ ] Constraints are specific (not generic \"write good code\")\n- [ ] Sharp edges have severity + mitigation\n\n**Content:**\n- [ ] Baseline test run BEFORE skill was written\n- [ ] At least one observed failure documented\n- [ ] Anti-rationalization table from real test failures\n- [ ] Mesh connections bidirectional (calls AND called-by both updated)\n- [ ] Data flow mapped (Feeds Into \u002F Fed By \u002F Feedback Loops)\n- [ ] Self-Validation has 3-5 domain-specific checks (not generic)\n- [ ] Output format is structured and parseable by other skills\n- [ ] `evals.md` written with at least 3 passing eval scenarios (E01 happy-path, E02 edge-case, E03 adversarial)\n- [ ] Skill Content Security Guard passed (sentinel Step 3.5 — no destructive ops or injection patterns in SKILL.md)\n\n**Architecture:**\n- [ ] Layer assignment correct (L1=orchestrate, L2=workflow, L3=utility)\n- [ ] Model assignment correct (haiku=scan, sonnet=code, opus=architect)\n- [ ] No >70% overlap with existing skills\n- [ ] ARCHITECTURE.md updated\n- [ ] CLAUDE.md updated\n\n**Extension-specific (if building an extension):**\n- [ ] EXTENSION.md manifest present with extends, requires, install_method\n- [ ] install.sh + install.ps1 tested (non-destructive merge)\n- [ ] uninstall.sh + uninstall.ps1 tested (clean removal)\n- [ ] Extension skill has dependency pre-flight check (Step 1)\n- [ ] Fallback behavior documented when external dependency unavailable\n- [ ] Cost warning present if extension calls paid APIs\n\n## Adapting Existing Skills\n\nWhen editing, not creating:\n\n\u003CHARD-GATE>\nSame TDD cycle applies to edits.\n1. Write a test that exposes the gap in the current skill\n2. Run baseline — confirm the skill fails on this scenario\n3. Edit the skill to address the gap\n4. Verify the edit fixes the gap WITHOUT breaking existing behavior\n\u003C\u002FHARD-GATE>\n\n\"Just adding a section\" is not an excuse to skip testing.\n\n## Token Efficiency Guidelines\n\nSkills are loaded into context when invoked. Every word costs tokens.\n\n| Skill Type | Target | Notes |\n|---|---|---|\n| L3 utility (haiku) | \u003C300 words | Runs frequently, keep lean |\n| L2 workflow hub | \u003C500 words | Moderate frequency |\n| L1 orchestrator | \u003C800 words | Runs once per workflow |\n| Reference sections | Extract to separate file | >100 lines → own file |\n\nTechniques:\n- Reference `--help` instead of documenting all flags\n- Cross-reference other skills instead of repeating content\n- One excellent example > three mediocre ones\n- Inline code only if \u003C50 lines, otherwise separate file\n\n## Output Format\n\n```\n## Skill Forge Report\n- **Skill**: [name] (L[layer])\n- **Action**: CREATE | EDIT\n- **Status**: SHIPPED | NEEDS_WORK | BLOCKED\n\n### Baseline Test\n- Scenario: [test scenario description]\n- Result WITHOUT skill: [observed failure]\n- Result WITH skill: [observed success or remaining gap]\n\n### Quality Checklist\n- Format: [pass\u002Ffail count]\n- Content: [pass\u002Ffail count]\n- Architecture: [pass\u002Ffail count]\n\n### Files Created\u002FModified\n- skills\u002F[name]\u002FSKILL.md — [created | modified]\n- docs\u002FARCHITECTURE.md — [updated | skipped]\n- CLAUDE.md — [updated | skipped]\n\n### Mesh Impact\n- New connections: [count] ([list of skills])\n- Bidirectional check: PASS | FAIL\n- Data flow mapped: [count] feeds-into, [count] fed-by, [count] feedback loops\n- Self-Validation: [count] domain-specific checks written\n```\n\n## Constraints\n\n1. MUST run baseline test BEFORE writing skill — no skill without observed failure\n2. MUST verify skill fixes the observed failures — green check required before ship\n3. MUST NOT create skill with >70% overlap with existing — extend instead\n4. MUST follow SKILL-TEMPLATE.md format — all required sections present\n5. MUST update ARCHITECTURE.md and CLAUDE.md on every new skill\n6. MUST NOT ship skill that fails its own pressure test\n7. MUST write description as triggers only — never summarize workflow in description\n\n## Sharp Edges\n\n| Failure Mode | Severity | Mitigation |\n|---|---|---|\n| Writing skill without baseline test | CRITICAL | Phase 2 HARD-GATE: must observe failure first |\n| Description summarizes workflow → agents skip content | HIGH | Phase 3 description rules: \"Use when...\" triggers only |\n| New skill duplicates existing skill | HIGH | Phase 1 HARD-GATE: >70% overlap → extend, don't create |\n| Skill passes test but breaks mesh connections | MEDIUM | Phase 6 integration: verify output compatibility |\n| Editing skill without testing the edit | MEDIUM | Adapting section: same TDD cycle for edits |\n| Overly verbose skill burns context tokens | MEDIUM | Token efficiency guidelines: layer-based word targets |\n| Code blocks in SKILL.md bloat every invocation | HIGH | WHY vs HOW split: SKILL.md ≤10-line code blocks, extract rest to references\u002F |\n| Writing skill without TDD (no observed failures first) | CRITICAL | Skill TDD: RED (run scenario WITHOUT skill → document failures) → GREEN (write skill targeting failures) → REFACTOR (find bypasses → add blocks) |\n| Description leaks workflow → agent skips full content | HIGH | CSO Discipline: description = triggers only. Test: can you execute from description alone? If yes, it leaks too much |\n| Self-Validation copies completion-gate checks | HIGH | Self-Validation is DOMAIN-specific: \"assertions per test\", \"dependency ordering\". NOT generic: \"tests pass\", \"build succeeds\" — those belong to completion-gate |\n| Data Flow confused with Calls | MEDIUM | Calls = runtime invocation (skill A calls skill B). Feeds Into = artifact persistence (skill A writes .rune\u002FX.md, skill B reads it later). If it's a direct function call → Calls. If it's via files\u002Fcontext → Data Flow |\n| Feedback Loop missing one direction | MEDIUM | Every Feedback Loop ↻ must document BOTH directions: what A sends to B AND what B sends back to A. One-way = Feeds Into, not a loop |\n\n## Done When\n\n- Baseline test documented with observed failures (TDD RED phase)\n- SKILL.md follows template format completely\n- Skill passes pressure test (agent complies with skill loaded)\n- No new failures in 2 consecutive varied-pressure test runs\n- Mesh connections wired (ARCHITECTURE.md, CLAUDE.md, related skills)\n- Git committed with conventional commit message\n\n## Returns\n\n| Artifact | Format | Location |\n|----------|--------|----------|\n| New or updated skill file | Markdown (SKILL.md) | `skills\u002F\u003Cname>\u002FSKILL.md` |\n| Eval scenarios | Markdown | `skills\u002F\u003Cname>\u002Fevals.md` |\n| Reference files (if needed) | Markdown | `skills\u002F\u003Cname>\u002Freferences\u002F` |\n| Architecture docs update | Markdown | `docs\u002FARCHITECTURE.md` |\n| Skill Forge Report | Markdown | inline |\n\n## Cost Profile\n\n~3000-8000 tokens per skill creation (opus for Phase 2-5 reasoning, haiku for scout\u002Fverification). Most cost is in the iterative test-refine loop (Phase 4-5). Budget 2-4 test iterations per skill.\n\n**Scope guardrail:** skill-forge authors and tests skill files — it does not implement the features those skills describe.\n",{"name":5,"metadata":52,"description":7},{"group":34,"layer":53,"model":32,"tools":54,"author":55,"version":56},"L2","Read, Write, Edit, Bash, Glob, Grep","runedev","1.7.0","main","c173cdffe08e788a99b91928a831b476b8434838","ecosystem\u002Fskills\u002Fskill_forge",0,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw","https:\u002F\u002Fportfolio-longleo.vercel.app\u002Flabs\u002Fomniclaw.html","https:\u002F\u002Fgithub.com\u002FLongLeo287","https:\u002F\u002Fwww.facebook.com\u002FResourceRookie2023","2026-11-14 08:48:28",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add LongLeo287\u002FOmniClaw --skill skill_forge",{"tool":72,"command":73},"bunx","bunx skills add LongLeo287\u002FOmniClaw --skill skill_forge",{"tool":75,"command":76},"pnpm","pnpm dlx skills add LongLeo287\u002FOmniClaw --skill skill_forge","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fskill_forge\u002FSKILL.md",true,[80,86,90,94],{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"_DIR_IDENTITY.md","REFERENCE","参考文档",144,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fskill_forge\u002F_DIR_IDENTITY.md",{"path":87,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":88,"sourceHtmlUrl":89},"README.md",457,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fskill_forge\u002FREADME.md",{"path":91,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fclaude_skill_reference.md",6144,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fskill_forge\u002Freferences\u002Fclaude_skill_reference.md",{"path":95,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":96,"sourceHtmlUrl":97},"schema.json",435,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fskill_forge\u002Fschema.json",[99,138,160,187,203,230],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":117,"publishedAt":47},"01M6JR0KQP4MHT32TN40D9CBFX","UI-UX Pro Max","Advanced UI\u002FUX analysis and generation skills with data-driven patterns. Python scripts (core.py, search.py) for systematic UI pattern extraction, design system generation, and component search from curated data sources.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fui_components\u002Fui_ux_pro_max\u002FSKILL.md",[105,108,109,114],{"categoryNo":106,"categoryName":107,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":115,"categoryName":116,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000033","数据分析师",[118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137],"ux","ui","ui ux pro max","max","pro","ui ux","design","component","search","analysis","team","rd","ui-ux","active","systematic","scripts","pattern extraction","sources","advanced","data-driven",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":47},"01M6JR0EF5AEQHP2FSTB57H05P","shadcn-ui","Expert guidance for integrating and building applications with shadcn\u002Fui components, including component discovery, installation, customization, and best practices.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fui_components\u002Fshadcn_ui\u002FSKILL.md",[144],{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},[146,119,147,148,125,149,150,151,152,128,153,154,155,131,156,157,158,159],"shadcn","shadcn ui","components","core","best practices","applications","discovery","customization","guidance","expert","installation","ui components","with","for",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":169,"publishedAt":47},"01M6JR08F51BEN17RHFYX65WVE","zustand_store_ts","Create Zustand stores with TypeScript, subscribeWithSelector middleware, and proper state\u002Faction separation. Use when building React state management, creating global stores, or implementing reactive state patterns with Zustand.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fzustand_store_ts\u002FSKILL.md",[166],{"categoryNo":167,"categoryName":168,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[170,171,172,173,174,175,176,177,178,179,180,181,36,182,183,184,158,185,186],"zustand store ts","zustand","store","typescript","microsoft","react","create","state management","state","react state management","management","global","patterns","separation","middleware","action","implementing",{"skillNo":188,"name":171,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":47},"01M6JR00TDMVAFFCZXZ04AN7Q7","Zustand state management guide. Use when working with store code (src\u002Fstore\u002F**), implementing actions, managing state, or creating slices. Triggers on Zustand store development, state management questions, or action implementation.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fzustand\u002FSKILL.md",[],[171,193,177,194,178,195,196,180,197,36,198,199,200,172,158,201,202,185,186],"development","code","actions","src","guide","implementation","zustand state","triggers","questions","zustand state management",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":213,"publishedAt":47},"01M6JQZSWV4KWJP112G6XHEP44","youtube_summarizer","Automatically fetch YouTube video transcripts, generate structured summaries, and send full transcripts to messaging platforms. Detects YouTube URLs and provides metadata, key insights, and downloadable transcripts.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fyoutube_summarizer\u002FSKILL.md",[209,212],{"categoryNo":210,"categoryName":211,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229],"youtube","youtube summarizer","summarizer","generate","metadata","messaging","Video","fetch","telegram","transcription","summarization","structured","full","insights","transcripts","summaries",{"skillNo":231,"name":232,"nameZh":6,"description":233,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":234,"categories":235,"keywords":236,"publishedAt":47},"01M6JQZN3QJB6B77JGKJD62DQT","youtube_clipper","YouTube 视频智能剪辑工具。下载视频和字幕，AI 分析生成精细章节（几分钟级别）， 用户选择片段后自动剪辑、翻译字幕为中英双语、烧录字幕到视频，并生成总结文案。 使用场景：当用户需要剪辑 YouTube 视频、生成短视频片段、制作双语字幕版本时。 关键词：视频剪辑、YouTube、字幕翻译、双语字幕、视频下载、clip video","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fyoutube_clipper\u002FSKILL.md",[],[214,237,238,220,42,239,240,241,242,243,39,29,244,245,246,247,248],"clipper","youtube clipper","下载","视频","生成","关键词","翻译","clip","总结","工具","文案","sonnet"]