* 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>
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 .platform/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:
- 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. - Ask ONE question using
AskUserQuestion - Read the user's answer
- 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. - Ask the NEXT question using
AskUserQuestion - Repeat steps 2-4 until ALL phases are complete
- 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
AskUserQuestioncall. 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
-
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.
-
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
-
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
-
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.
- Read-only: tools =
-
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.
-
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/or03-Resources/ - If unsure, default to
00-Inbox/for output
- Output to
Phase 3: Output and Coordination
-
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
-
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
-
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 Setupsection in the agent with:- How to detect first run (e.g., check if
Meta/{agent-name}-config.mdexists) - 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)
-
External tools or MCP servers? Only ask if the agent interacts with external services. If the user doesn't need this, skip entirely.
-
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
- Summarize everything back to the user in a clear, structured format
- Ask for confirmation or corrections
- Generate the agent file following
.platform/references/agent-template.md:- IMPORTANT: The
descriptionfield 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
- IMPORTANT: The
- Save the file to
.platform/agents/{name}.md - Update the registry: add a new row to
.platform/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) - Update the directory: add a new section under "Custom Agents" in
.platform/references/agents.md— insert it between the<!-- MBIFC:CUSTOM_AGENTS_START -->and<!-- MBIFC:CUSTOM_AGENTS_END -->markers in that file - Log the creation in
Meta/agent-log.md - 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 agentsubsection - Always write the description and triggers ONLY in the user's language (no multilingual translations)