@winspan/claude-forge 9.2.0 → 9.12.0

package/dist/skills/distilled/distilled-verification-before-completion.md

@@ -10,110 +10,110 @@ rubric_version: 2
 distilled_from:
   - upstream: https://github.com/obra/superpowers.git
     license: MIT
-    commit: unknown
+    commit: f2cbfbefebbfef77321e4c9abc9e949826bea9d7
     paths:
       - verification-before-completion/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - django-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - laravel-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - quarkus-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - springboot-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - verification-loop/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - verification-loop/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - laravel-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - quarkus-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - springboot-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - verification-loop/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - django-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - laravel-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - springboot-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - verification-loop/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - verification-loop/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - django-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - laravel-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - quarkus-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - springboot-verification/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - verification-loop/SKILL.md
-distilled_at: '2026-05-29T08:11:27.303Z'
+distilled_at: '2026-06-15T00:59:08.307Z'
 distilled_by: claude-code skill-distiller agent
 it_universal_score: 5
 it_universal_dims:
@@ -123,81 +123,91 @@ it_universal_dims:
   d4: 1
   d5: 1
 it_universal_rationale: >-
-  Purely behavioral/process methodology with no language, toolchain, or repo-structure dependencies
-  — applies identically to any codebase or project.
+  Language-neutral, tool-chain-neutral verification discipline with zero repo-specific references;
+  the Gate Function and rationalization tables transfer directly to any codebase or workflow.
 ---
 
 # Verification Before Completion
 
 ## When to use
-- Before claiming any work is "done", "fixed", "passing", or "complete"
-- Before committing, pushing, or opening a pull request
-- Before expressing satisfaction ("Great!", "Done!", "All good!")
-- Before delegating to another agent and trusting its self-report
-- Before moving to the next task in any project
+- Before claiming "tests pass", "build succeeds", "bug is fixed", or "done"
+- Before committing, opening a PR, or marking a task complete
+- Before expressing any satisfaction or moving to the next task
+- After delegating work to a sub-agent that reports success
 
 ## Core idea
 
-Claiming success without fresh evidence is dishonest, not efficient. The only valid
-basis for a completion claim is the **output you just read** from a verification
-command you **just ran**. Prior runs, intuition, and agent self-reports are not
-evidence. This is a non-negotiable gate: run → read → claim, in that order, with no
-shortcuts. The rule applies to exact phrases, paraphrases, and any implication of
-correctness — "spirit over letter" means rewording the claim doesn't escape the rule.
+Claiming work is complete without fresh evidence is dishonesty, not efficiency. The only valid basis for a success claim is the **actual output of the relevant command run in the current context**. Prior runs, agent self-reports, confidence, and partial checks are not substitutes. Every rationalization for skipping verification is a known failure mode; name it, then reject it.
 
-## Steps
+The rule applies to exact phrases, paraphrases, and any implication of success — spirit over letter.
 
-**The Gate Function — execute before any success claim:**
+## The Gate Function
 
-1. **IDENTIFY** — What command proves this specific claim? Name it explicitly.
-2. **RUN** — Execute the full command now, in this message, fresh.
-3. **READ** — Read the complete output; check exit code; count failures.
-4. **VERIFY** — Does the output actually confirm the claim?
-   - If NO → state the actual status with the evidence you have
-   - If YES → continue to step 5
-5. **CLAIM** — State the claim and quote or cite the confirming output.
+Before making **any** status claim or completion statement, execute all five steps:
+
+1. **IDENTIFY** — What command produces evidence for this claim?
+2. **RUN** — Execute it fully (no cached output, no partial scope)
+3. **READ** — Examine the complete output; check exit code; count failures
+4. **VERIFY** — Does the output confirm the claim?
+   - If NO → state actual status with the evidence
+   - If YES → state the claim *with* the evidence attached
+5. **THEN** — Only now make the claim
 
 Skipping any step = asserting without evidence.
 
-**TDD Red-Green cycle (regression tests):**
-1. Write the regression test
-2. Run it → must **pass** against the fixed code
-3. Temporarily revert the fix → run again → must **fail**
-4. Restore the fix → run again → must **pass**
-5. Only now claim "regression test verified"
+## Common Claim → Required Evidence
+
+| Claim | What actually proves it | What does NOT prove it |
+|---|---|---|
+| Tests pass | Test runner: 0 failures, 0 errors | Previous run; "should pass" |
+| Linter clean | Linter output: 0 issues | Partial file check |
+| Build succeeds | Build command exits 0 | Linter passing; logs look fine |
+| Bug fixed | Original symptom reproduced and passes | Code changed; assumed fixed |
+| Regression test valid | Red → Green cycle verified | Test written but not inverted |
+| Agent completed task | VCS diff shows expected changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist verified | All tests passing |
+
+## Red Flags — Stop Immediately
+
+- Hedging words: "should", "probably", "seems to", "I think"
+- Expressing satisfaction before running verification ("Great!", "Done!", "Perfect!")
+- About to commit or push without having run the check
+- Trusting a delegated agent's self-report without inspecting artifacts
+- Reasoning "partial check is sufficient"
+- Feeling tired and wanting the work to be over
+
+## Rationalization Table
+
+| Excuse heard | Correct response |
+|---|---|
+| "Should work now" | RUN the command |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently via VCS diff |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words, rule doesn't apply" | Spirit over letter |
+
+## Steps (TDD Red-Green Pattern)
+
+When writing a regression test, full verification requires a **red-green cycle**:
 
-## Common failure patterns
+1. Write the test
+2. Run → must **pass** (green, with fix in place)
+3. Temporarily revert the fix
+4. Run → must **fail** (red — confirms test is meaningful)
+5. Restore fix
+6. Run → must **pass** again
 
-| Claim | Requires | Not sufficient |
-|-------|----------|----------------|
-| "Tests pass" | Test runner output: 0 failures | Previous run / "should pass" |
-| "Linter clean" | Linter output: 0 errors | Partial check / extrapolation |
-| "Build succeeds" | Build command: exit 0 | Linter passing / logs look good |
-| "Bug fixed" | Original symptom reproduced and passes | Code changed, assumed fixed |
-| "Agent completed" | VCS diff shows expected changes | Agent self-report of success |
-| "Requirements met" | Line-by-line checklist against spec | Tests passing alone |
+Skipping the red phase means the test may not actually catch the bug.
 
 ## Anti-patterns
 
-- **Hedging language as a loophole**: "should work", "probably passes", "seems fine"
-  — these are completion claims without evidence, not honest uncertainty.
-- **Trusting agent success reports**: sub-agents have no penalty for false positives;
-  always verify independently via diff or re-running the command yourself.
-- **Partial verification**: linter passing ≠ compiler passing ≠ tests passing ≠
-  requirements met. Each claim needs its own command.
-- **Fatigue exceptions**: exhaustion is not a reason to skip verification; it is
-  exactly when false-positive claims are most likely.
-- **"Just this once"**: there are no exceptions; the first exception breaks the trust
-  the rule is designed to protect.
-- **Rationalization table** (internal check before claiming):
-
-  | Excuse | Correct response |
-  |--------|-----------------|
-  | "I'm confident" | Confidence ≠ evidence — run the command |
-  | "Linter passed" | Linter ≠ compiler — run the build |
-  | "Agent said success" | Verify independently |
-  | "Partial check is enough" | Partial proves nothing |
-  | "Different words so rule doesn't apply" | Spirit over letter |
+- Claiming success based on a run from an earlier message or session
+- Saying "looks good" after reading code without executing it
+- Committing in the same step as implementation without a separate verify step
+- Conflating "agent reports done" with "work is verified done"
+- Using softer phrasing ("it appears to be working") to sidestep the rule — the spirit still applies
 
 ## References
 - Upstream: https://github.com/obra/superpowers.git

package/dist/skills/distilled/distilled-writing-skills.md

@@ -0,0 +1,175 @@
+---
+name: distilled-writing-skills
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: writing-skills (score 4/5)'
+keywords:
+  - writing
+  - skills
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/obra/superpowers.git
+    license: MIT
+    commit: f2cbfbefebbfef77321e4c9abc9e949826bea9d7
+    paths:
+      - writing-skills/SKILL.md
+distilled_at: '2026-06-15T01:00:38.805Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 4
+it_universal_dims:
+  d1: 1
+  d2: 0.5
+  d3: 1
+  d4: 0.5
+  d5: 1
+it_universal_rationale: >-
+  TDD-for-documentation methodology and description-field optimization (CSO) are language-neutral
+  and applicable to any AI agent skill authoring workflow, regardless of codebase or toolchain.
+---
+
+# Writing Agent Skills (TDD for Process Documentation)
+
+## When to use
+- Creating a new skill document for an AI agent
+- Editing or refactoring an existing skill that agents seem to ignore
+- Verifying a skill actually changes agent behavior before deploying it
+- Debugging why an agent skips or misreads a skill (description optimization)
+- Deciding whether something belongs in a skill vs. a repo-level convention file
+
+## Core idea
+
+Writing skills is **TDD applied to process documentation**. Like software TDD, you first run
+a baseline scenario (RED: watch the agent violate the rule *without* the skill), then write
+the skill (GREEN: agent now complies), then close loopholes found through additional tests
+(REFACTOR). If you skipped the baseline, you don't know whether the skill targets the real
+failure mode. The key artifact is a `SKILL.md` with two critical elements: a precise
+frontmatter `description` that drives **discovery**, and a concise body that drives
+**compliance**. Both must be correct; a great body behind a misleading description is never
+loaded.
+
+## Steps
+
+### 1. RED — establish baseline
+Before writing anything, run a pressure scenario with a subagent. Document the exact
+rationalizations the agent uses to justify the violation. These become the specific failure
+modes the skill must address.
+
+### 2. Write the skill
+
+Create `skills/<skill-name>/SKILL.md` (flat namespace; all skills live in one searchable
+directory):
+
+```markdown
+---
+name: Skill-Name-With-Hyphens
+description: Use when [specific triggering conditions, symptoms, situations]
+---
+
+# Skill Name
+
+## Overview
+Core principle in 1-2 sentences.
+
+## When to Use
+- Symptom A
+- Symptom B
+- NOT when: [counter-indicators]
+
+## Core Pattern
+Before/after comparison or concrete steps.
+
+## Common Mistakes
+What goes wrong + fixes.
+```
+
+**Frontmatter rules:**
+- `name`: letters, numbers, hyphens only (no parentheses or special chars)
+- `description`: **triggering conditions only** — see §Description Anti-patterns below
+- Total frontmatter ≤ 1 024 characters
+
+### 3. GREEN — verify compliance
+Re-run the same pressure scenario with the skill present. Agent should comply. If it still
+violates, sharpen the `description` or tighten the body.
+
+### 4. REFACTOR — close loopholes
+Observe new rationalizations the agent invents. Plug each one. Repeat until no new failure
+modes emerge.
+
+## Description Anti-patterns — CSO Critical
+
+The `description` field is how an agent decides *whether to load* the skill at all. A bad
+description is the #1 reason skills are ignored.
+
+> **Rule: Description = When to Use. NOT What the Skill Does.**
+
+If the description summarises the skill's workflow, the agent may follow that summary
+*instead of* reading the full body. Observed failure: description said "code review between
+tasks" → agent did ONE review and never consulted the two-stage flowchart in the body.
+
+```yaml
+# ❌ BAD: summarises workflow — agent skips body
+description: Use when executing plans - dispatches subagent per task with review between tasks
+
+# ❌ BAD: too much process detail
+description: Use for TDD — write test first, watch it fail, write minimal code, refactor
+
+# ✅ GOOD: triggering conditions only, no workflow
+description: Use when executing implementation plans with independent tasks
+
+# ✅ GOOD: problem-focused triggers
+description: Use when tests have race conditions, timing dependencies, or pass/fail inconsistently
+```
+
+Additional description rules:
+- Start with `Use when…`
+- Write in third person (injected into system prompts)
+- Describe the *problem* (race conditions, inconsistent state), not language-specific
+  symptoms (unless the skill itself is tech-specific — then be explicit)
+- Under 500 characters if possible
+
+## When NOT to create a skill
+
+| Situation | Better home |
+|---|---|
+| One-off solution for a single task | Session notes / inline comment |
+| Standard practice documented elsewhere | Link to that source |
+| Repo-specific conventions | Your repo's convention file (e.g., `CLAUDE.md`, `AGENTS.md`) |
+| Mechanical constraint enforceable by linting/CI | Automate it — save skills for judgment calls |
+
+## Token efficiency
+
+Always-loaded skills consume context in **every conversation**. Keep them tight:
+
+- Always-loaded / getting-started skills: < 150 words each
+- Other frequently-loaded skills: < 500 words
+- Move exhaustive flag lists to `--help`; reference the command rather than duplicating it
+- Cross-reference other skills by name instead of repeating their content
+- One excellent code example beats several mediocre ones
+
+## Naming conventions
+
+Prefer **verb-first gerunds** — active, describes the action being taken:
+
+| ✅ Good | ❌ Bad |
+|---|---|
+| `condition-based-waiting` | `async-test-helpers` |
+| `root-cause-tracing` | `debugging-techniques` |
+| `flatten-with-flags` | `data-structure-refactoring` |
+| `creating-skills` | `skill-creation` |
+
+## Anti-patterns
+
+- **Skipping baseline** — writing a skill without watching the agent fail first means you
+  don't know what failure mode you're actually solving
+- **Workflow summary in description** — causes agent to follow the description shortcut
+  instead of reading the body
+- **Over-documenting** — bloated skills inflate context cost and reduce compliance; every
+  word in a frequently-loaded skill has a runtime price
+- **Project-specific content in skills** — repo paths, local tool names, environment
+  variables; these belong in your repo's convention file, not a reusable skill
+- **Force-loading via direct file links (`@file`)** — burns context before it's needed;
+  reference skill names instead and let the agent decide when to load
+- **Flowcharts for linear instructions** — use numbered lists; reserve flowcharts for
+  non-obvious decision branches where early exit is the common error
+
+## References
+- Upstream: https://github.com/obra/superpowers.git

package/dist/skills/registry.d.ts

@@ -13,12 +13,10 @@ export interface Skill {
     isBuiltin?: boolean;
     description?: string;
     /**
-     * Phase 7 — Skill ↔ Agent pairing.
-     * When set, UserPromptHandler step 4 emits a "强烈建议 Task spawn <agent>"
-     * directive AND writes a `workflow_recommendations` row (source='skill_pairing')
-     * instead of injecting the skill content directly. The agent name MUST match
-     * a `.claude/agents/<spawn_agent>.md` file so Phase 5's mismatch-deny rule
-     * has a concrete target to enforce on PreToolUse.
+     * Phase 7 — Skill ↔ Agent pairing (frontmatter field, parse-only).
+     * The push-injection path that consumed this (skill_pairing directive +
+     * workflow_recommendations write) was deleted with spec 1200 / decision
+     * fe6f98cd; the field is still parsed so frontmatter round-trips cleanly.
      */
     spawn_agent?: string;
     /**
@@ -41,9 +39,12 @@ export interface Skill {
  * `config.skill_matching.api_key` was removed from the `ForgeConfig` JSON
  * schema in D R-D; daemon still grep-warns the raw yaml on startup.
  *
- * BREAKING: users that previously enjoyed AI-powered semantic skill
- * recommendations now get keyword-only matching (the existing
- * `matchKeywords` fallback, which already covered the unconfigured case).
+ * Dead-code removal (2026-06-10, decision ed98c8e8): the keyword-matching
+ * API (`match` / `matchWithConfidence` / `matchWithDetails` / private
+ * `matchKeywords`) and the keyword scoring helper file were deleted — the
+ * skill push route is gone; skills are now pull-only via MCP
+ * (`skill-list` / `skill-invoke`), which only need `getAll` / `get` /
+ * `getManifest` / `reload`.
  */
 export declare class SkillRegistry {
     private skills;
@@ -63,47 +64,6 @@ export declare class SkillRegistry {
      * 2. Directory: ~/.claude/skills/skill-name/SKILL.md (agent-skills format)
      */
     private scan;
-    /**
-     * Match a prompt against skill keywords.
-     *
-     * Post D R-B (spec 0902): semantic / AI matching has been removed. Only
-     * the keyword path runs. The result `source` is therefore always
-     * `'keyword'`.
-     */
-    match(prompt: string, keywords?: string[], context?: {
-        recentFiles?: string[];
-    }): Promise<Skill | null>;
-    /**
-     * Like match(), but also returns the confidence score (0-100) so callers
-     * can compare across alternatives (e.g. agent vs skill routing).
-     *
-     * Post D R-B: only keyword matching remains; `source` is always
-     * `'keyword'`. The literal-union return type is preserved for caller
-     * compatibility — `'semantic'` is no longer emitted but kept in the type
-     * so older code paths that pattern-match on it still compile until R-D.
-     */
-    matchWithConfidence(prompt: string, keywords?: string[], context?: {
-        recentFiles?: string[];
-    }): Promise<{
-        skill: Skill;
-        confidence: number;
-        source: 'semantic' | 'keyword';
-    } | null>;
-    /**
-     * Keyword-based matching (fallback method)
-     * Supports fallback to description-based substring matching when keywords are empty
-     */
-    private matchKeywords;
-    /**
-     * Match with full result details (for debugging/logging)
-     */
-    matchWithDetails(prompt: string, keywords?: string[], context?: {
-        recentFiles?: string[];
-    }): Promise<{
-        skill: Skill;
-        confidence: number;
-        matchedKeywords: string[];
-    }[]>;
     /** Return all loaded skills */
     getAll(): Skill[];
     /**

package/dist/skills/registry.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"registry.d.ts","sourceRoot":"","sources":["../../src/skills/registry.ts"],"names":[],"mappings":"AAWA,MAAM,WAAW,KAAK;IACpB,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,MAAM,CAAC;IACb,QAAQ,EAAE,MAAM,EAAE,CAAC;IACnB,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,MAAM,CAAC;IACb;;;;;OAKG;IACH,SAAS,CAAC,EAAE,OAAO,CAAC;IACpB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;;;;;OAOG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;;;OAKG;IACH,kBAAkB,CAAC,EAAE,MAAM,CAAC;CAC7B;AAED;;;;;;;;;;;;;;;GAeG;AACH,qBAAa,aAAa;IACxB,OAAO,CAAC,MAAM,CAAiC;;IAO/C;;;OAGG;IACH,OAAO,CAAC,mBAAmB;IAK3B;;;;;;;;OAQG;IACH,OAAO,CAAC,IAAI;IA6HZ;;;;;;OAMG;IACG,KAAK,CAAC,MAAM,EAAE,MAAM,EAAE,QAAQ,GAAE,MAAM,EAAO,EAAE,OAAO,CAAC,EAAE;QAAE,WAAW,CAAC,EAAE,MAAM,EAAE,CAAA;KAAE,GAAG,OAAO,CAAC,KAAK,GAAG,IAAI,CAAC;IAKjH;;;;;;;;OAQG;IACG,mBAAmB,CACvB,MAAM,EAAE,MAAM,EACd,QAAQ,GAAE,MAAM,EAAO,EACvB,OAAO,CAAC,EAAE;QAAE,WAAW,CAAC,EAAE,MAAM,EAAE,CAAA;KAAE,GACnC,OAAO,CAAC;QAAE,KAAK,EAAE,KAAK,CAAC;QAAC,UAAU,EAAE,MAAM,CAAC;QAAC,MAAM,EAAE,UAAU,GAAG,SAAS,CAAA;KAAE,GAAG,IAAI,CAAC;IASvF;;;OAGG;YACW,aAAa;IA8D3B;;OAEG;IACG,gBAAgB,CAAC,MAAM,EAAE,MAAM,EAAE,QAAQ,GAAE,MAAM,EAAO,EAAE,OAAO,CAAC,EAAE;QAAE,WAAW,CAAC,EAAE,MAAM,EAAE,CAAA;KAAE;;;;;IAkCpG,+BAA+B;IAC/B,MAAM,IAAI,KAAK,EAAE;IAIjB;;;;;;;OAOG;IACH,GAAG,CAAC,EAAE,EAAE,MAAM,GAAG,KAAK,GAAG,SAAS;IAIlC;;OAEG;IACH,WAAW,IAAI,KAAK,CAAC;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAC;QAAC,WAAW,EAAE,MAAM,CAAC;QAAC,QAAQ,EAAE,MAAM,EAAE,CAAA;KAAE,CAAC;IAS3F,mCAAmC;IACnC,MAAM,IAAI,IAAI;CAIf"}
+{"version":3,"file":"registry.d.ts","sourceRoot":"","sources":["../../src/skills/registry.ts"],"names":[],"mappings":"AAUA,MAAM,WAAW,KAAK;IACpB,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,MAAM,CAAC;IACb,QAAQ,EAAE,MAAM,EAAE,CAAC;IACnB,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,MAAM,CAAC;IACb;;;;;OAKG;IACH,SAAS,CAAC,EAAE,OAAO,CAAC;IACpB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;;;OAKG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;;;OAKG;IACH,kBAAkB,CAAC,EAAE,MAAM,CAAC;CAC7B;AAED;;;;;;;;;;;;;;;;;;GAkBG;AACH,qBAAa,aAAa;IACxB,OAAO,CAAC,MAAM,CAAiC;;IAO/C;;;OAGG;IACH,OAAO,CAAC,mBAAmB;IAK3B;;;;;;;;OAQG;IACH,OAAO,CAAC,IAAI;IA6HZ,+BAA+B;IAC/B,MAAM,IAAI,KAAK,EAAE;IAIjB;;;;;;;OAOG;IACH,GAAG,CAAC,EAAE,EAAE,MAAM,GAAG,KAAK,GAAG,SAAS;IAIlC;;OAEG;IACH,WAAW,IAAI,KAAK,CAAC;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAC;QAAC,WAAW,EAAE,MAAM,CAAC;QAAC,QAAQ,EAAE,MAAM,EAAE,CAAA;KAAE,CAAC;IAS3F,mCAAmC;IACnC,MAAM,IAAI,IAAI;CAIf"}