@amsterdamdatalabs/enact-extensions 0.1.42 → 0.1.47

package/extensions/enact-wiki/skills/enact-wiki/references/ingest.md

@@ -1,62 +0,0 @@
----
-last_update: 2026-04-30T00:00:00+00:00
----
-
-# Ingest — Add content to the wiki
-
-## Ingest
-
-Ingest one source file. Two raw layers, two destinations:
-
-| Source | Destination |
-|---|---|
-| `raw/sources/` (PDF, documents) | `wiki/sources/<slug>.md` — one summary page |
-| `raw/sessions/` (AI transcripts) | `wiki/entities/`, `wiki/concepts/`, `wiki/syntheses/`, `wiki/comparisons/`, `wiki/questions/` — never `wiki/sources/` |
-
-CLI shortcut (raw/sources/ only):
-```bash
-enact-wiki ingest <path>
-```
-Agent workflow (all sources): follow the **Ingest Workflow** in `CLAUDE.md`.
-
-Session rules: trust frontmatter · summarise, don't copy verbatim · extract entities, decisions, questions, comparisons, syntheses · transcript stays on `sessions.html`
-
-## Sync
-
-Import agent transcripts into the wiki. Full pipeline:
-
-```text
-~/.codex/sessions → raw/sessions/ → Ingest Workflow → enact-wiki dream run → enact-wiki build
-```
-
-```bash
-enact-wiki sync [vault-root]
-```
-Flags: `--dry-run` · `--all-workspaces` · `--workspace <slug>` · `--adapter <name>` · `--strict` · `--build`
-
-If 0 new sessions: report "wiki is already up to date" and stop.
-If 1+ new sessions: ingest each, then run `enact-wiki dream run`.
-Append: `## [YYYY-MM-DD] sync | <N> sessions ingested`
-
-Hook: `scripts/hooks/session-start.sh` auto-triggers `/wiki-sync` when `raw/sessions/` changes.
-
-## Update
-
-Surgical single-page edit without full re-ingest:
-
-```bash
-/wiki-update <page-path> [reason]
-```
-
-Use when: source changed · stale claim · bump `last_update` · add contradiction.
-Do NOT use for bulk changes — use `/wiki-ingest` or `/wiki-sync`.
-
-Hard rules: never overwrite contradictions (add `## Contradictions` instead) · keep frontmatter intact · stop and re-run ingest if you need to rewrite >30% of the page.
-
-## Shared rules
-
-1. `raw/` is immutable — never modify files there.
-2. No silent overwrites — conflicting claims → `## Contradictions`.
-3. Every page has `## Connections` with at least one `[[wikilink]]`.
-4. Frontmatter is authoritative — always populate `title`, `type`, `last_update`, `confidence`, `status`.
-5. `wiki/sources/` is for `raw/sources/` only. Session content → `comparisons|concepts|entities|questions|syntheses`.

package/extensions/enact-wiki/skills/enact-wiki/references/manage.md

@@ -1,34 +0,0 @@
----
-last_update: 2026-04-30T00:00:00+00:00
----
-
-# Manage — CLI commands and operations
-
-## Command surface
-
-| Command | Usage | Notes |
-|---|---|---|
-| `init` | `enact-wiki init [target-dir] [vault-name] --only claude,codex,cursor,gemini,opencode,pi,hooks,docs` | `--only` required; surfaces: `claude`,`codex`,`cursor`,`gemini`,`opencode`,`pi`,`hooks`,`docs`; include `codex` whenever `opencode` is present; flags: `--list-surfaces`, `--skip <csv>`, `--workspace nested|independent`; `schema.md` is always written |
-| `build` | `enact-wiki build [--strict]` | Compiles `raw/` + `wiki/` → `site/`: `index.html`, `sessions.html`, `graph.html`, `graph-explorer.json`, `graph.jsonld`, `llms.txt`, `llms-full.txt`, `search-index.json`, `sitemap.xml`, `rss.xml`, `robots.txt`, `ai-readme.md`, `manifest.json`, per-page `wiki/<dir>/<slug>.html|txt|json` |
-| `serve` | `enact-wiki serve` | Starts local HTTP server for `site/`; binds to `127.0.0.1` by default |
-| `lint` | `enact-wiki lint [--strict]` | Finds orphans, broken `[[wikilinks]]`, contradictions, stale pages; must pass before `build` or `export` |
-| `check-links` | `enact-wiki check-links` | Verifies every `[[wikilink]]` and external link resolves |
-| `all` | `enact-wiki all [--strict]` | Full pipeline: `lint` → `build` → `check-links` → `export`; canonical ready-to-publish command after `/wiki-sync` |
-| `export` | `enact-wiki export` | Writes `llms.txt`, `llms-full.txt`, `search-index.json`, `sitemap.xml`, `rss.xml`, `robots.txt`, `ai-readme.md`, `manifest.json` |
-| `export-marp` | `enact-wiki export-marp . <topic> [--out ./marp/<deck>.md]` | Exports a Marp-compatible slide deck |
-| `export-obsidian` | `enact-wiki export-obsidian . --vault <ABSOLUTE_OBSIDIAN_VAULT_PATH> [--subfolder "Enact Wiki"]` | Recreates export subfolder on each run; exported pages include `## Source`; see `../../../../../enact-docs/05-operations/memory/obsidian-integration.md` |
-| `export-qmd` | `enact-wiki export-qmd . [--out ./qmd]` | Flat filenames: `<wikiDir>__<slug>.qmd`; rewrites target cleanly; see `../../../../../enact-docs/05-operations/memory/qmd-export.md` |
-| `doctor` | `enact-wiki doctor` | Health-checks the installation |
-| `adapters` | `enact-wiki adapters` | Shows which agent stores are wired and configured |
-| `mcp` | `enact-wiki mcp .` | Starts the MCP server on stdio; parity reference: `../../../../../enact-docs/04-contracts/memory/agent-surface-parity.md` |
-| `link-obsidian` | `enact-wiki link-obsidian . --vault <ABSOLUTE_OBSIDIAN_VAULT_PATH> [--subfolder "Enact Wiki"]` | Sets up Obsidian vault linking |
-| `watch` | `enact-wiki watch` | File-system watcher for auto-triggering sync/ingest |
-
-## Operational notes
-
-- `build --strict`, `lint --strict`, and `all --strict` treat info-severity lint findings as blocking or fatal depending on the command.
-- If `build` fails, run `enact-wiki lint` first, then `enact-wiki check-links`.
-- `lint` workflow: run `lint` → `check-links` → inspect `^## Contradictions` → check stale summaries → check missing entity pages → output grouped report → optionally save `wiki/lint-report.md`.
-- `serve` exposes `site/`; for LAN sharing, explicitly bind to `0.0.0.0` via `enact-wiki serve --help`.
-- Global flag: `--vault <path>` runs vault-aware commands against a specific vault root instead of cwd.
-- Sync-specific cross-reference: adapter filtering and workspace flags are documented in `references/ingest.md`.

package/extensions/enact-wiki/skills/enact-wiki/references/query.md

@@ -1,59 +0,0 @@
----
-last_update: 2026-04-30T00:00:00+00:00
----
-
-# Query — Retrieve and synthesise answers from the wiki
-
-## Query
-
-Answer a question by querying the wiki. Use when the user asks about their own past work or vaulted knowledge.
-
-```bash
-enact-wiki query --mode=search --top-k=8 --quiet "<question>"
-enact-wiki query --mode=answer --top-k=8 --quiet "<question>"
-```
-
-Workflow: read `wiki/index.md` + root `overview.md` → run CLI query for shortlist → read candidates → synthesise answer with `[[wikilink]]` citations → offer to save substantial answers to `wiki/syntheses/<slug>.md` → append `## [YYYY-MM-DD] query | <short question>`.
-
-Fallback: "I don't see anything about this in your wiki yet." → suggest `/wiki-sync` → offer general knowledge explicitly marked as such.
-
-Two modes:
-- `--mode=search` → ranked retrieval hits (paths). Use for debugging and bulk lookups.
-- `--mode=answer` → synthesised answer with citations. Use when the user expects a response.
-
-JSON for integrations: `enact-wiki query --mode=search --json "<question>"`
-
-Don't do: invent wiki pages · conflate general knowledge with wiki content · over-cite · write walls of text.
-
-## Search
-
-Simple BM25 keyword search:
-```bash
-enact-wiki search <term>
-```
-Use for quick ad-hoc lookups. For research with synthesis and citations, use `query --mode=answer`.
-
-## Read
-
-Read a wiki page directly:
-```bash
-enact-wiki read <slug-or-path>
-```
-
-## Graph
-
-Show wikilink neighbourhood for one page:
-```bash
-enact-wiki graph <slug>
-```
-Reports inbound links (which pages reference this page) and outbound links (what this page references). Broken edges → cross-check with `/wiki-lint`. Orphan (zero inbound) → suggest `/wiki-lint` for a wider report.
-
-## Reflect
-
-Read-only meta-pass over the whole wiki — look for patterns, gaps, and improvement opportunities:
-```bash
-/wiki-reflect [focus-area]
-```
-Optional focus: `patterns` · `gaps` · `quality` · `contradictions` · or omit for a general pass.
-
-Hard rules: don't edit pages during reflection (propose changes, get approval) · cite `[[wikilinks]]` for what the wiki says vs. your own interpretation · be specific ("47 Callebaut recipes, strong on ganache, zero on tempering" not "chocolate coverage is fine").

package/extensions/enact-wiki/skills/search-lab/SKILL.md

@@ -1,57 +0,0 @@
----
-name: search-lab
-description: Analyze search-lab benchmark artifacts and propose reviewable improvements to search quality, query expansion, wiki content, and configuration.
----
-
-# search-lab
-
-Use when you have search-lab outputs to review: `agent-summary.md`, `analysis-report.json`, `proposals.json`, `benchmark.json`, or `.dossier.json` files.
-
-## Typical flow
-
-```bash
-enact-wiki search-lab benchmark
-enact-wiki search-lab export .enact/wiki/search-lab/runs/<timestamp>/
-enact-wiki search-lab analyze .enact/wiki/search-lab/runs/<timestamp>/
-```
-
-## Inputs
-
-- `agent-summary.md`
-- `analysis-report.json`
-- `proposals.json`
-- `benchmark.json`
-- one or more `.dossier.json` files
-
-## Outputs
-
-Produce concise, ranked proposals for:
-1. config tuning (`memory.toml` changes)
-2. query expansion improvements
-3. benchmark additions
-4. wiki/content/link improvements
-
-## Review frame
-
-For each issue, identify likely cause, then propose:
-- `type`: `config` | `expansion` | `benchmark` | `wiki`
-- `confidence`: 0-1
-- `effort`: `quick` | `medium` | `large`
-- `impact`: `high` | `medium` | `low`
-- `implementation`: concrete diff, TOML snippet, file path, or link suggestion
-
-Prioritize by: impact ↓, effort ↑, confidence ↓.
-
-## Agent rules
-
-- Prefer existing CLI-generated proposal artifacts when present; refine them instead of starting from scratch.
-- Read the benchmark/dossier artifacts first, then inspect current `memory.toml`.
-- Propose minimal, reviewable changes.
-- Do not auto-apply broad changes without review.
-
-## References
-
-- `src/lib/search-lab-types.ts`
-- `src/lib/search-lab.ts`
-- `src/cli/commands/search-lab.ts`
-- `../../../README.md`

package/extensions/enact-wiki/skills/search-lab/scripts/analyze.ts

@@ -1,23 +0,0 @@
-export interface SearchLabQuickSummary {
-  topIssues: string[]
-  recommendationCount: number
-}
-
-/**
- * Minimal helper for future skill-side analysis wrappers.
- * Kept intentionally small so the bootstrap skill can evolve
- * without coupling itself tightly to engine internals.
- */
-export function summarizeSearchLabIssues(issues: string[]): SearchLabQuickSummary {
-  const counts = new Map<string, number>()
-  for (const issue of issues) counts.set(issue, (counts.get(issue) ?? 0) + 1)
-  const topIssues = [...counts.entries()]
-    .sort((a, b) => b[1] - a[1])
-    .slice(0, 5)
-    .map(([issue]) => issue)
-
-  return {
-    topIssues,
-    recommendationCount: topIssues.length,
-  }
-}

package/extensions/enact-wiki/skills/wiki/SKILL.md

@@ -1,42 +0,0 @@
----
-name: wiki
-description: "Wiki-style reference lookup and persistence via the enact-wiki provider. Use when durable project documentation or knowledge retrieval is needed."
----
-
-# Wiki
-
-## Purpose
-Provides access to the project's durable wiki and knowledge base via the enact-wiki MCP server. This skill does not re-implement wiki storage or retrieval — it delegates all operations to enact-wiki tools. Research artifacts and analysis outputs can be persisted to the wiki via this skill.
-
-## Use When
-- Looking up a documented decision, design, or reference
-- Research findings should be persisted as a durable wiki entry
-- Checking "does the wiki have anything on X?"
-
-## Workflow
-1. Identify the query or document to persist.
-2. Delegate the operation to the enact-wiki provider using its wiki MCP tools.
-   - For a lookup: invoke the enact-wiki wiki query tool with the search term.
-   - For a write: invoke the enact-wiki wiki add tool with the content and title.
-   - For a list: invoke the enact-wiki wiki list tool.
-   - For a read of a specific entry: invoke the enact-wiki wiki read tool with the entry identifier.
-3. If the operation returns content, present it directly without reformatting.
-4. If persisting a research artifact (e.g., from `.enact/loop/research/` or `.enact/factory/security/`), read the file first, then pass the content to the enact-wiki wiki add tool.
-5. Wiki state is owned by the enact-wiki provider — do not store wiki content locally as a substitute.
-
-## State Contract
-- Reads: enact-wiki wiki store (via MCP tool calls), local research files when persisting
-- Writes: enact-wiki wiki store (via MCP tool calls); no local wiki shadow files
-
-## Dependencies
-- Requires enact-wiki MCP server to be connected. If it is not available, report that and stop.
-
-## Activation
-
-Invoke with `$wiki` or `$enact-wiki:wiki`. The skill delegates all operations to enact-wiki MCP tools — no durable workflow state is started automatically.
-
-## Final Check
-- The query returned a result or a clear "not found" from enact-wiki
-- For writes, the enact-wiki tool confirmed the entry was saved
-- No wiki content was stored locally as a substitute for the enact-wiki store
-- If enact-wiki was unavailable, the caller was notified explicitly

package/extensions/net-revenue-management/.agents/plugin.json

@@ -1,40 +0,0 @@
-{
-  "name": "net-revenue-management",
-  "version": "0.1.0",
-  "description": "Revenue Growth Management modelling for CPG pricing events — models P&L cascades, elasticity-based volume responses, retailer terms risks, and scenario comparisons on Meridian Confections UK Premium Snacks data.",
-  "author": {
-    "name": "Amsterdam Data Labs"
-  },
-  "license": "UNLICENSED",
-  "keywords": [
-    "rgm",
-    "revenue",
-    "pricing",
-    "cpg",
-    "analytics",
-    "mcp"
-  ],
-  "targets": [
-    "claude",
-    "codex",
-    "cursor",
-    "enact"
-  ],
-  "skills": "./skills/",
-  "mcpServers": "./.mcp.json",
-  "interface": {
-    "displayName": "Net Revenue Management",
-    "shortDescription": "RGM modelling: elasticity, P&L cascades, retailer risk.",
-    "longDescription": "Model price-event impacts across 14 SKUs in the Meridian Confections UK Premium Snacks range (January 2026). Covers own-price elasticity, P&L waterfall bridges for conservative/base/optimistic scenarios, Asda delisting-risk detection, split pricing strategies by segment, and a full four-option scenario comparison table.",
-    "developerName": "Amsterdam Data Labs",
-    "category": "Finance",
-    "capabilities": [
-      "Read",
-      "Interactive"
-    ]
-  },
-  "factory": {
-    "firstParty": false,
-    "operatorScope": "global"
-  }
-}

package/extensions/net-revenue-management/.mcp.json

@@ -1,9 +0,0 @@
-{
-  "mcpServers": {
-    "net_revenue_rgm": {
-      "command": "uvx",
-      "args": ["net-revenue-rgm"],
-      "env": {}
-    }
-  }
-}

package/extensions/net-revenue-management/skills/net-revenue-risks/SKILL.md

@@ -1,30 +0,0 @@
----
-name: net-revenue-risks
-description: Surface retailer terms risks, Asda delisting exposure, and Asda non-compliance impact for a CPG pricing event. Grounded in Meridian Confections UK Premium Snacks January 2026 data.
----
-
-## Net Revenue Risk Assessment
-
-Use this skill to identify and quantify risks associated with a pricing event before committing to a recommendation.
-
-### Workflow
-
-1. **Check retailer terms** — call `check_retailer_terms` (optionally filtered by `accounts`) to surface SKUs where the new RSP breaches the Asda 15p own-label price-gap policy. Galaxy Sharing 150g and 200g are flagged at Asda; combined exposure ~£643K.
-
-2. **Model Asda non-compliance** — call `model_asda_non_compliance` with `hold_weeks` (1–13) to quantify Q1 net revenue lost if Asda delays compliance. At a full 13-week hold the loss ≈ −£210K vs full compliance.
-
-3. **Get all identified risks** — call `get_risks` to return the complete risk register: Asda delisting (~£643K), Tesco MFC clause, and the Jan W1 timing upside (+£340K opportunity).
-
-### Key thresholds
-
-- **Asda price-gap policy**: 15p branded-above-own-label threshold. A +5% RSP increase on Galaxy Sharing bags breaches this, triggering a delisting review.
-- **Asda hold breakeven**: Every additional week of hold costs ~£16K net revenue on the sharing segment.
-- **Split mitigation**: Applying only +3% to sharing SKUs keeps Galaxy Sharing 150g/200g below the 15p gap threshold, protecting the Asda account while still delivering ~+£1.92M net revenue impact range-wide.
-
-### Example prompts
-
-- "What is the total Asda delisting risk for the +5% price event?"
-- "Model 8 weeks of Asda non-compliance on sharing SKUs."
-- "Show all risks for the January 2026 price event, ordered by severity."
-
-> **Draft note**: skill body is a starter draft for review. Validate risk thresholds and non-compliance formula against future data refreshes.

package/extensions/net-revenue-management/skills/net-revenue-scenario/SKILL.md

@@ -1,31 +0,0 @@
----
-name: net-revenue-scenario
-description: Model pricing scenarios for a CPG price event using Revenue Growth Management tools. Covers full-range and split price increases, P&L waterfall cascades, and volume response across SKU segments.
----
-
-## Net Revenue Scenario Modelling
-
-Use this skill to model the financial impact of a pricing event on the Meridian Confections UK Premium Snacks range (January 2026, 14 SKUs).
-
-### Workflow
-
-1. **Load the elasticity model** — call `load_elasticity_model` first. This grounds all subsequent tools in the actual SKU economics (own-price elasticity coefficients, RSP, net price, gross margin %).
-
-2. **Model volume response** — call `calculate_volume_response` with the target `price_delta_pct` (e.g. `5.0` for Full 5%) and optionally filter by `segments` (`["premium","sharing","standard"]`).
-
-3. **Run the P&L cascade** — call `run_pl_cascade` with `scenario` set to one of:
-   - `"conservative"` — lower list-price step, more volume drag
-   - `"base"` — the reference scenario (net revenue impact +£2.1M)
-   - `"optimistic"` — tighter volume response, fuller recovery
-
-4. **Model a split increase** — if Asda delisting risk is a concern, call `model_split_scenario` with a lower `sharing_pct` (e.g. `3.0`) to keep Galaxy Sharing bags below the 15p Asda price-gap policy threshold while applying the full increase to premium and standard SKUs.
-
-5. **Compare all options** — call `get_scenario_comparison` to return the four strategic options (Full 5%, Split recommended, Phased Q1/Q2, No change) with net revenue, GM%, EBITDA, and risk level.
-
-### Example prompts
-
-- "Model a +5%/+3% split scenario: premium at 5%, sharing at 3%."
-- "What is the net revenue impact of the optimistic base scenario?"
-- "Compare all four pricing options for the January 2026 price event."
-
-> **Draft note**: skill body is a starter draft for review. Refine tool call sequences and example prompts based on actual agent testing.

package/extensions/plugin-dev/.agents/plugin.json

@@ -1,41 +0,0 @@
-{
-  "name": "plugin-dev",
-  "version": "0.1.0",
-  "description": "Toolkit for authoring Enact plugins: scaffold and validate agents, skills, hooks, and MCP integrations from an ENACT-native source manifest with Claude Code, Codex, and Cursor projections.",
-  "author": {
-    "name": "amsterdamdatalabs"
-  },
-  "homepage": "https://amsterdamdatalabs.com",
-  "repository": "https://dev.azure.com/amsterdamdatalabs/enact/_git/enact-os",
-  "license": "UNLICENSED",
-  "keywords": [
-    "enact",
-    "plugin",
-    "manifest",
-    "validation"
-  ],
-  "targets": [
-    "claude",
-    "codex",
-    "cursor",
-    "enact"
-  ],
-  "skills": "./skills/",
-  "agents": "./agents/",
-  "interface": {
-    "displayName": "Plugin Dev",
-    "shortDescription": "Scaffold and validate ENACT-native plugins with Claude Code, Codex, and Cursor projections.",
-    "developerName": "Amsterdam Data Labs",
-    "category": "Developer Tools",
-    "capabilities": [
-      "multi-platform manifests",
-      "plugin validation",
-      "skills authoring",
-      "agents authoring"
-    ]
-  },
-  "factory": {
-    "firstParty": true,
-    "operatorScope": "global"
-  }
-}

package/extensions/plugin-dev/agents/agent-creator.md

@@ -1,199 +0,0 @@
----
-name: agent-creator
-description: Use this agent when the user asks to "create an agent", "generate an agent", "build a new agent", "make me an agent that...", or describes agent functionality they need. Trigger when user wants to create autonomous agents for plugins. Examples:
-
-<example>
-Context: User wants to create a code review agent
-user: "Create an agent that reviews code for quality issues"
-assistant: "I'll use the agent-creator agent to generate the agent configuration."
-<commentary>
-User requesting new agent creation, trigger agent-creator to generate it.
-</commentary>
-</example>
-
-<example>
-Context: User describes needed functionality
-user: "I need an agent that generates unit tests for my code"
-assistant: "I'll use the agent-creator agent to create a test generation agent."
-<commentary>
-User describes agent need, trigger agent-creator to build it.
-</commentary>
-</example>
-
-<example>
-Context: User wants to add agent to plugin
-user: "Add an agent to my plugin that validates configurations"
-assistant: "I'll use the agent-creator agent to generate a configuration validator agent."
-<commentary>
-Plugin development with agent addition, trigger agent-creator.
-</commentary>
-</example>
-
-<example>
-Context: User describes needing autonomous functionality while discussing plugin development
-user: "My plugin needs something to automatically review code after I write it"
-assistant: "I'll use the agent-creator agent to generate a code review agent for your plugin."
-<commentary>
-User describes agent-like functionality need without explicitly requesting agent creation, proactively trigger agent-creator.
-</commentary>
-</example>
-
-# Explicit sonnet for complex agent generation reasoning
-model: sonnet
-color: magenta
-tools: Write, Read, Glob
-skills: agent-development
----
-
-You are an elite AI agent architect specializing in crafting high-performance agent configurations. Your expertise lies in translating user requirements into precisely-tuned agent specifications that maximize effectiveness and reliability.
-
-**Important Context**: You may have access to project-specific instructions from CLAUDE.md files and other context that may include coding standards, project structure, and custom requirements. Consider this context when creating agents to ensure they align with the project's established patterns and practices.
-
-When a user describes what they want an agent to do, you will:
-
-1. **Extract Core Intent**: Identify the fundamental purpose, key responsibilities, and success criteria for the agent. Look for both explicit requirements and implicit needs. Consider any project-specific context from CLAUDE.md files. For agents that are meant to review code, you should assume that the user is asking to review recently written code and not the whole codebase, unless the user has explicitly instructed you otherwise.
-
-2. **Design Expert Persona**: Create a compelling expert identity that embodies deep domain knowledge relevant to the task. The persona should inspire confidence and guide the agent's decision-making approach.
-
-3. **Architect Comprehensive Instructions**: Develop a system prompt that:
-   - Establishes clear behavioral boundaries and operational parameters
-   - Provides specific methodologies and best practices for task execution
-   - Anticipates edge cases and provides guidance for handling them
-   - Incorporates any specific requirements or preferences mentioned by the user
-   - Defines output format expectations when relevant
-   - Aligns with project-specific coding standards and patterns from CLAUDE.md
-
-4. **Optimize for Performance**: Include:
-   - Decision-making frameworks appropriate to the domain
-   - Quality control mechanisms and self-verification steps
-   - Efficient workflow patterns
-   - Clear escalation or fallback strategies
-
-5. **Create Identifier**: Design a concise, descriptive identifier that:
-   - Uses lowercase letters, numbers, and hyphens only
-   - Is typically 2-4 words joined by hyphens
-   - Clearly indicates the agent's primary function
-   - Is memorable and easy to type
-   - Avoids generic terms like "helper" or "assistant"
-
-6. **Craft Triggering Examples**: Create 2-4 `<example>` blocks showing:
-   - Different phrasings for same intent
-   - Both explicit and proactive triggering
-   - Context, user message, assistant invocation, commentary
-   - Why the agent should trigger in each scenario
-   - Show assistant using the Agent tool to launch the agent
-
-**Agent Creation Process:**
-
-1. **Understand Request**: Analyze user's description of what agent should do
-
-2. **Design Agent Configuration**:
-   - **Identifier**: Create concise, descriptive name (lowercase, hyphens, 3-50 chars)
-   - **Description**: Write triggering conditions starting with "Use this agent when..."
-   - **Examples**: Create 2-4 `<example>` blocks with:
-     ```
-     <example>
-     Context: [Situation that should trigger agent]
-     user: "[User message]"
-     assistant: "I'll use the [agent-name] agent to [what it does]."
-     <commentary>
-     [Why agent should trigger]
-     </commentary>
-     </example>
-     ```
-   - **System Prompt**: Create comprehensive instructions with:
-     - Role and expertise
-     - Core responsibilities (numbered list)
-     - Detailed process (step-by-step)
-     - Quality standards
-     - Output format
-     - Edge case handling
-
-3. **Select Configuration**:
-   - **Model**: Use `inherit` unless user specifies (sonnet for complex, haiku for simple)
-   - **Color**: Choose appropriate color:
-     - blue/cyan: Analysis, review
-     - green: Generation, creation
-     - yellow: Validation, caution
-     - red: Security, critical
-     - magenta: Transformation, creative
-   - **Tools**: Recommend minimal set needed, or omit for full access
-   - **Skills**: Include relevant skills if agent needs domain expertise
-   - **Permission Mode**: Set if agent needs special permissions (acceptEdits, dontAsk, plan)
-
-4. **Generate Agent File**: Use Write tool to create `agents/[identifier].md`:
-
-   ```markdown
-   ---
-   name: [identifier]
-   description: [Use this agent when... Examples: <example>...</example>]
-   model: inherit
-   color: [chosen-color]
-   tools: Tool1, Tool2 # Optional
-   skills: # Optional - load domain skills
-     - skill-name
-   permissionMode: acceptEdits # Optional - for auto-accepting edits
-   ---
-
-   [Complete system prompt]
-   ```
-
-5. **Explain to User**: Provide summary of created agent:
-   - What it does
-   - When it triggers
-   - Where it's saved
-   - How to test it
-   - Suggest running validation: `Use the plugin-validator agent to check the plugin structure`
-
-**Quality Standards:**
-
-- Identifier follows naming rules (lowercase, hyphens, 3-50 chars)
-- Description has strong trigger phrases and 2-4 examples
-- Examples show both explicit and proactive triggering
-- System prompt is comprehensive (500-3,000 words)
-- System prompt has clear structure (role, responsibilities, process, output)
-- Model choice is appropriate
-- Tool selection follows least privilege
-- Color choice matches agent purpose
-
-**Output Format:**
-Create agent file, then provide summary:
-
-```markdown
-## Agent Created: [identifier]
-
-### Configuration
-
-- **Name:** [identifier]
-- **Triggers:** [When it's used]
-- **Model:** [choice]
-- **Color:** [choice]
-- **Tools:** [list or "all tools"]
-
-### File Created
-
-`agents/[identifier].md` ([word count] words)
-
-### How to Use
-
-This agent will trigger when [triggering scenarios].
-
-Test it by: [suggest test scenario]
-
-Validate with: `scripts/validate-agent.sh agents/[identifier].md`
-
-### Next Steps
-
-[Recommendations for testing, integration, or improvements]
-```
-
-**Edge Cases:**
-
-- Vague user request: Ask clarifying questions before generating
-- Conflicts with existing agents: Note conflict, suggest different scope/name
-- Very complex requirements: Break into multiple specialized agents
-- User wants specific tool access: Honor the request in agent configuration
-- User specifies model: Use specified model instead of inherit
-- First agent in plugin: Create agents/ directory first
-
-This agent automates agent creation using the proven patterns from Claude Code's internal implementation, making it easy for users to create high-quality autonomous agents.