Files
My-Brain-Is-Full-Crew/tests/regression/snapshot/.claude/skills/create-agent/SKILL.md
Giacomo Nunziati 53b605379e feat: multi-platform adapter architecture (Claude Code, Gemini CLI, OpenCode) (#32)
* Fix istall/update scripts

* test: capture pre-refactor install snapshot for regression

Adds take-snapshot.sh script and the resulting snapshot/ directory,
capturing the exact vault state produced by launchme.sh before the
framework-agnosticity refactor begins.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* Summary: Refactor agents/skills/hooks/mcp in agentic-platform-agnostic templates.

refactor: rename source CLAUDE.md → DISPATCHER.md (framework-neutral)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

refactor: convert agent frontmatter from tools: to neutral capabilities:

Replace Claude Code-specific `tools:` frontmatter with framework-agnostic
`mode: subagent` and `capabilities: [...]` in all 8 agent files.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

refactor: add neutral hook trigger manifests (.hook.yaml)

refactor: hooks read neutral JSON schema (args.* instead of tool_input.*)

refactor: convert .mcp.json to neutral mcp/servers.yaml

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* Implement agentic-platform adapters skeleton.

build: add adapters/lib.sh skeleton with vocabulary constants

test: bash test runner for adapter helpers

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(adapters): parse_frontmatter helper with tests

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(adapters): parse_capabilities helper with tests

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(adapters): should_include helper with tests

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(adapters): parse_hook_yaml helper with tests

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(adapters): agent_body helper with tests

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(adapters): enumerate_agents and enumerate_hooks helpers

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* Implement agentic-platform adapter for Claude Code.

build(adapters): claude-code adapter skeleton with capability/event tables

build(claude-code): adapter_translate_dispatcher with test

build(claude-code): adapter_translate_references with test

build(claude-code): adapter_translate_skills with tests

build(claude-code): adapter_translate_agents with capability→tools mapping

build(claude-code): hook wrapper template (CC native → neutral schema)

build(claude-code): adapter_translate_hooks with wrapper generation

build(claude-code): adapter_translate_mcp with hand-rolled YAML parser

build(claude-code): adapter_finalize and complete adapter_build wiring

build: scripts/build.sh dispatches to per-framework adapter

Also fix adapter_translate_hooks and adapter_translate_agents to use
while-read loops (avoiding word-splitting on paths with spaces) and
guard grep calls with || true to survive set -eo pipefail when hooks
have no match-tool field. Remove scripts/build.sh from .gitignore.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* Refactor install/update scripts to support agentic-platform agnosticity.

refactor(lib.sh): generalize install_claude_md → install_dispatcher

New signature takes the full destination path instead of just the vault
dir, allowing callers to install CLAUDE.md, AGENTS.md, or any dispatcher
file to an explicit location.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(launchme): support --framework flag, build dist/ before install

Add --framework and --target arg parsing. Run build.sh before installing
to populate dist/<framework>/. All install_* calls now read from
dist/<framework>/ instead of the raw source dirs. MCP is now handled
automatically by the adapter (no interactive prompt). Replaced
install_claude_md with install_dispatcher.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(updateme): support --framework flag, build dist/ before update

Add --framework and --target arg parsing. Run build.sh before installing
to populate dist/<framework>/. All install_* calls now read from
dist/<framework>/ instead of raw source dirs. Replaced install_claude_md
with install_dispatcher.

Also fix set -e compatibility in lib.sh: add || true to all conditional
[[ ... ]] && info "..." logging lines so they don't abort the script
when VERBOSE_COPY=0.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* test: regression runner diffs dist/claude-code against pre-refactor snapshot

- Add tests/regression/run.sh that builds dist/claude-code and compares
  against snapshot, excluding runtime-only artifacts (.mbifc-manifest,
  .mcp.json, .claude-plugin/plugin.json)
- Fix adapters/lib.sh agent_body: preserve '---' section dividers in body
  (awk now only skips '---' while still inside frontmatter, fm < 2)
- Fix adapters/claude-code/adapter.sh: change 'read' capability to expand
  to only 'Read', appending 'Glob, Grep' at end of tools list to match
  snapshot ordering
- Update snapshot to reflect intentional refactor changes: hook JSON schema
  (.args.* instead of .tool_input.*), wrapper scripts, settings.json with
  wrapper paths, and consistent tool ordering for postman/sorter

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* Implement opencode adapter.

Co-Authored-By: win0na <winnie@winneon.moe>

feat(lib.sh): add install_plugins helper for opencode JS plugins

build(adapters): opencode adapter skeleton with capability/event tables

build(opencode): adapter_translate_dispatcher (DISPATCHER.md → AGENTS.md)

build(opencode): adapter_translate_references and adapter_translate_skills

Implements Task 4 and Task 5:
- adapter_translate_references: Copies reference markdown files to .opencode/references/
- adapter_translate_skills: Copies skill SKILL.md files to .opencode/skills/<name>/ with exclude filtering

Both functions respect framework filtering via should_include().

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(opencode): adapter_translate_agents with capability→permission mapping

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(opencode): bash-executor template for spawning hook scripts

build(opencode): plugin-stub template for mbifc-hooks.js

build(opencode): adapter_translate_hooks with JS plugin generation

Implements _oc_hook_registry_json and adapter_translate_hooks in the
opencode adapter. Copies hook scripts to .opencode/hooks/, generates a
single .opencode/plugins/mbifc-hooks.js by inlining bash-executor.js and
synthesising a hook registry from *.hook.yaml files. Uses python3 for
template substitution to safely handle multi-line JS content. Adds 3
unit tests (copies scripts, registry entries, noop when no hooks dir).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(opencode): adapter_translate_mcp with local/remote handling

build(opencode): adapter_finalize and complete adapter_build wiring

Add adapter_finalize placeholder and wire adapter_translate_mcp into
adapter_build; add end-to-end integration test (14/14 pass).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(launchme): branch on --framework for opencode install layout

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(updateme): branch on --framework for opencode install layout

Mirror the same case "$FRAMEWORK" block from launchme.sh: framework-specific
DIST_COMPONENTS_DIR, VAULT_COMPONENTS_DIR, DISPATCHER_SRC/DST, MCP_SRC/DST,
HAS_PLUGINS; conditional install_plugins; conditional install_settings;
framework-aware vault-setup check; framework-neutral summary messages.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* Fix adapters to follow the same template.

fix: restore adapter_build() contract, revert function renames

Both adapters now export adapter_build() and adapter_translate_*() as
the uniform public contract. scripts/build.sh sources one adapter and
calls adapter_build uniformly. Private helpers (_oc_*) and vocabulary
tables (cc_capability_to_tools, oc_capability_to_permission, etc.)
retain their prefixes. CC regression and OC unit tests all pass.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

fix(tests): restore test_oc_ prefix on adapter_build end-to-end test

* Fix agent format in opencode adapter

* refactor: rename --framework to --platform across all scripts and tests

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* Modify generic name for model tiers

Co-Authored-By: win0na <winnie@winneon.moe>

refactor: neutral model vocabulary (low/mid/high) in source agents

feat(claude-code): cc_model_to_native() maps low/mid/high to haiku/sonnet/opus

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(opencode): update oc_model_to_provider() for low/mid/high vocabulary

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* Add gemini-cli adapter

Co-Authored-By: win0na <winnie@winneon.moe>

build(gemini-cli): adapter skeleton with capability/event/model tables

build(gemini-cli): adapter_translate_dispatcher (DISPATCHER.md → GEMINI.md)

build(gemini-cli): adapter_translate_references and adapter_translate_skills

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(gemini-cli): adapter_translate_agents with capability→tools mapping

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(gemini-cli): adapter_translate_hooks with wrapper scripts

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

feat(install): add gemini-cli platform to launchme.sh and updateme.sh

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* Implement preserving config merge for opencode.

Co-Authored-By: win0na <winnie@winneon.moe>

feat(opencode): config-merge.sh with formatting-preserving JSON merge

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

build(opencode): source config-merge.sh from adapter

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(install): use oc_config_merge for opencode.json instead of overwrite

Source config-merge.sh from install scripts for opencode platform so
user keys in opencode.json are preserved on reinstall and update.
Fix in-place merge by writing to a temp file before moving to output.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* Add mcp files to gitignore.

* Fix claude-specific references in agents, skills and references

* Fix: remove claude-specific reference from hooks.

build: add platform_dir and dispatcher_name to all hook wrapper/plugin templates

feat(hooks): platform-aware path checks using platform_dir and dispatcher_name from JSON input

test: update regression snapshot for platform-aware hook wrappers and scripts

* Added interactive platform choice in launchme, and platform auto-detection in updateme.

* Fix: remove claude-specific references from documentation

* Update documentation to reflect the new platform-agnostic architecture

* fix: address Copilot review feedback on PR #32

- tests/run.sh: check source return code, report failures
- tests/regression/run.sh: use mktemp + trap cleanup instead of fixed /tmp paths
- tests/regression/run.sh: include .mcp.json in regression comparison
- tests/regression/take-snapshot.sh: use --platform flag instead of stale scripted input
- adapters/opencode/templates/plugin-stub.js.tmpl: include stdout in hook block error message

* fix: address Copilot review round 2

- config-merge.sh: reword comment to only promise indentation preservation (not full formatting)
- take-snapshot.sh: copy required artifacts explicitly, optional ones with existence check
- adapters/lib.sh: document parse_hook_yaml single-trigger limitation

* fix: address Copilot review round 3

- adapters/opencode/adapter.sh: replace python3 template substitution with
  pure bash (while-read loop with case matching), removing python3 dependency
- adapters/lib.sh: should_include now falls back to plain YAML key read for
  files without frontmatter delimiters (fixes hook .yaml exclude: support)

* fix: address Copilot review round 4

- scripts/launchme.sh: fix double-dot in FW_DIR_NAME display (basename
  already includes the dot, e.g. ".claude")
- scripts/launchme.sh: replace undefined MCP_ANSWER with check on MCP_DST
  existence for summary banner

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-10 23:28:28 +02:00

11 KiB
Executable File

name, description
name description
create-agent Create a new custom agent from scratch. Runs a 6-phase interview to understand purpose, capabilities, triggers, output format, and coordination rules, then generates the agent file. Triggers: EN: "create a new agent", "custom agent", "I need a new agent", "build an agent", "new crew member". IT: "crea un nuovo agente", "agente personalizzato", "nuovo membro del crew". FR: "créer un nouvel agent", "agent personnalisé". ES: "crear un nuevo agente", "agente personalizado". DE: "neuen Agenten erstellen". PT: "criar um novo agente".

Create Agent — Custom Agent Creation Skill

You are the Architect running the Custom Agent Creation flow. You guide the user through a detailed, multi-step conversation to produce a production-quality agent.

NEVER create an agent in one shot. No matter how specific the user's request seems, you MUST have a full conversation first. The quality of the agent depends entirely on how well you understand the user's needs, and you cannot understand them from a single message.

Before starting, read .claude/references/agent-template.md to understand the standard structure every agent must follow.

Golden Rule: Language

Always respond to the user in their language. Match the language the user writes in. If the user writes in Italian, respond in Italian. If they write in Japanese, respond in Japanese. This skill file is written in English for universality, but your output adapts to the user.


HARD CONSTRAINT — MANDATORY STEP-BY-STEP PROTOCOL

You MUST use the AskUserQuestion tool for EVERY question in every phase. This is not optional. This is how the conversation works:

  1. BEFORE the first question: read your post-it (Meta/states/architect.md). If it contains an active agent-creation flow with collected answers, resume from the recorded phase — do NOT restart. If no post-it exists or no active flow, start from Phase 1.
  2. Ask ONE question using AskUserQuestion
  3. Read the user's answer
  4. Write your post-it immediately — save the current phase, agent name, and ALL collected answers so far to Meta/states/architect.md. This is critical: you may be re-invoked at any point and must be able to resume.
  5. Ask the NEXT question using AskUserQuestion
  6. Repeat steps 2-4 until ALL phases are complete
  7. Only THEN generate the agent file

Post-it Protocol

At the START of every execution, read Meta/states/architect.md (if it exists). Check if there is an active agent-creation flow with collected answers. If there is, resume from the recorded phase — do NOT restart the flow from scratch.

At the END of every execution (and after every answer), write your post-it to Meta/states/architect.md:

---
agent: architect
last-run: "{{ISO timestamp}}"
---

## Post-it

### Active flow: agent-creation
### Current phase: {{current phase name}}
### Collected answers:
- purpose: {{answer or PENDING}}
- name: {{answer or PENDING}}
- triggers: {{answer or PENDING}}
- permissions: {{answer or PENDING}}
- shell-commands: {{answer or PENDING}}
- folders: {{answer or PENDING}}
- output-format: {{answer or PENDING}}
- coordination: {{answer or PENDING}}
- first-run: {{answer or PENDING}}
- external-tools: {{answer or PENDING}}
- template: {{answer or PENDING}}
- confirmation: {{yes/no or PENDING}}

Fields marked PENDING are questions you have NOT asked yet. When you are re-invoked, read the current phase and resume from there. Do NOT re-ask questions that already have answers.


PHASE CHECKLIST

Before writing the agent .md file, verify you have checked off ALL of these. If even ONE is missing, go back and ask.

[ ] Phase 1 — Q1: What should this agent do? (purpose)
[ ] Phase 1 — Q2: What would you name it? (codename)
[ ] Phase 1 — Q3: When should this agent activate? (6-8 trigger phrases)
[ ] Phase 2 — Q4: Does it need to create or modify notes? (permissions)
[ ] Phase 2 — Q5: Does it need shell commands? (only if relevant)
[ ] Phase 2 — Q6: Which vault folders does it work with?
[ ] Phase 3 — Q7: What kind of output does it produce? (format)
[ ] Phase 3 — Q8: Which other agents might need to act after it?
[ ] Phase 4 — Q9: First-run setup — what should it ask/create on first use?
[ ] Phase 5 — Q10: External tools/MCP? (only if relevant)
[ ] Phase 5 — Q11: Dedicated template? (only if relevant)
[ ] Phase 6 — Summary presented AND user confirmation collected

After each question, your NEXT action MUST be asking the NEXT question on the checklist. There are ZERO exceptions. NEVER jump to file generation before Phase 6.

RULES — VIOLATION OF ANY RULE IS A CRITICAL FAILURE:

  • ONE question per AskUserQuestion call. Never bundle 2+ questions.
  • NEVER skip a phase or a question. Follow the checklist above top to bottom. Phase 5 questions can be skipped ONLY if clearly irrelevant based on previous answers.
  • NEVER generate the agent file before Phase 6 confirmation. If you catch yourself writing the file before the user confirms the summary, STOP. You are doing it wrong.
  • NEVER assume answers. Even if the user's initial request seems detailed, you still ask every question. The user's first message is not a substitute for the conversation.
  • NEVER output all questions as text. The questions below are for YOU to ask one at a time, not to display to the user as a list.
  • NEVER jump from Phase 4 to file generation. Phase 5 and Phase 6 are mandatory intermediate steps.

Phase 1: Understanding the Need

  1. What should this agent do? Ask the user to describe the agent's purpose in a sentence or two. If the answer is vague, ask clarifying questions until you have a clear picture.

  2. What would you name it? Ask for a short codename (like "scribe" or "postman"). Rules:

    • Must be lowercase, hyphens only
    • Must NOT conflict with the 8 core names: architect, scribe, sorter, seeker, connector, librarian, transcriber, postman
    • If the user picks a conflicting name, explain why and suggest alternatives
    • Keep it to 1-2 words
  3. When should this agent activate? Ask the user for example phrases they would say to invoke this agent. You need at least 6-8 trigger phrases. Help the user brainstorm by suggesting examples based on their description.

Phase 2: Capabilities and Permissions

  1. Does this agent need to create or modify notes? Based on the answer:

    • Read-only: tools = Read, Glob, Grep
    • Creates notes: tools = Read, Write, Glob, Grep
    • Modifies existing notes: tools = Read, Write, Edit, Glob, Grep
    • Do NOT ask about tools directly. Ask about what the agent DOES and infer the tools.
  2. Does this agent need to run shell commands? Only ask this if the agent's purpose involves filesystem operations (moving files, creating folders). Most agents do NOT need Bash.

  3. Which vault folders does this agent work with? Ask where it reads from and where it writes to. Common patterns:

    • Output to 00-Inbox/ (most common)
    • Read from specific areas like 02-Areas/Health/ or 03-Resources/
    • If unsure, default to 00-Inbox/ for output

Phase 3: Output and Coordination

  1. What kind of output does this agent produce? Ask about:

    • Note format (what frontmatter fields, what sections)
    • File naming convention (follow the vault's existing pattern)
    • Whether it needs a dedicated template
  2. After this agent finishes, which other agents might need to act? Help the user think about this with examples:

    • "If it creates notes, the Sorter might need to file them"
    • "If it finds connections, the Connector might need to link them"
    • "If it detects missing structure, the Architect should be notified"

Phase 4: First Run Setup

  1. What should this agent do the very first time it runs? Every agent needs a first-run onboarding. Ask the user:

    • "When this agent runs for the first time, what does it need to know from you? What questions should it ask?"
    • "Does it need to create any folders, config files, or templates before it can start working?"
    • "Should it scan existing notes in the vault to bootstrap itself?"

    Based on the answers, write a ## First Run Setup section in the agent with:

    • How to detect first run (e.g., check if Meta/{agent-name}-config.md exists)
    • The questions to ask the user
    • What to create (config file, folders, templates, welcome note)
    • Rule that the onboarding never repeats unless the user asks to reconfigure

Phase 5: Advanced (only ask if relevant based on previous answers)

  1. External tools or MCP servers? Only ask if the agent interacts with external services. If the user doesn't need this, skip entirely.

  2. Dedicated template? Only ask if the agent produces structured notes with a consistent format. If yes, create the template in Templates/.

Phase 6: Confirmation and Generation

  1. Summarize everything back to the user in a clear, structured format
  2. Ask for confirmation or corrections
  3. Generate the agent file following .claude/references/agent-template.md:
    • IMPORTANT: The description field in the frontmatter must be written ONLY in the user's language. Do NOT add translations in other languages. Do NOT copy the multilingual pattern from core agents. If the user speaks Italian, the entire description and all trigger phrases are in Italian. Period.
    • IMPORTANT: The body of the agent (everything after the frontmatter ---) must ALWAYS be written in English, regardless of the user's language. This is for performance: LLMs follow instructions more reliably in English. The agent will still respond to the user in their language thanks to the "Always respond in the user's language" rule.
    • Fill in the Inter-Agent Coordination section with the specific agents this one should suggest
    • Write a detailed Core Responsibilities section (this is what makes the agent good or bad)
    • Include concrete examples and templates for any notes the agent creates
  4. Save the file to .claude/agents/{name}.md
  5. Update the registry: add a new row to .claude/references/agents-registry.md — insert it between the <!-- MBIFC:CUSTOM_AGENTS_START --> and <!-- MBIFC:CUSTOM_AGENTS_END --> markers in the Registry table (after the postman row)
  6. Update the directory: add a new section under "Custom Agents" in .claude/references/agents.md — insert it between the <!-- MBIFC:CUSTOM_AGENTS_START --> and <!-- MBIFC:CUSTOM_AGENTS_END --> markers in that file
  7. Log the creation in Meta/agent-log.md
  8. Report to the user: "Your new agent {name} is now active. You can try it by saying one of your trigger phrases."

Quality Standards

A custom agent is only as good as its instructions. Ensure:

  • The Core Responsibilities section is at least 20-30 lines long with specific, actionable instructions
  • Every note type the agent creates has a frontmatter template
  • Edge cases are addressed (what happens when input is ambiguous? when data is missing?)
  • The agent has clear operational rules

Validation Rules

  • Never create an agent with the same name as a core agent
  • Never grant Bash access unless the agent genuinely needs filesystem operations
  • Always include the Inter-Agent Coordination section (it is mandatory, not optional)
  • Always include the ### When to suggest a new agent subsection
  • Always write the description and triggers ONLY in the user's language (no multilingual translations)