Files
My-Brain-Is-Full-Crew/tests/regression/snapshot/.claude/skills/inbox-triage/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
inbox-triage Process all notes in 00-Inbox/: scan, classify by content, route to correct vault location, update MOCs, extract action items, and generate a daily digest. Triggers: EN: "triage the inbox", "clean up the inbox", "sort my notes", "empty inbox", "file my notes", "process the inbox". IT: "smista l'inbox", "svuota l'inbox", "ordina le note", "triage dell'inbox", "processa l'inbox". FR: "trier la boite de réception", "vider l'inbox", "classer mes notes". ES: "clasificar la bandeja de entrada", "vaciar el inbox", "ordenar mis notas". DE: "Inbox sortieren", "Inbox leeren", "Notizen einordnen". PT: "triagem da inbox", "esvaziar a inbox", "organizar minhas notas".

Inbox Triage — Intelligent Inbox Processing & Filing

Always respond to the user in their language. Match the language the user writes in.

Process all notes sitting in 00-Inbox/, classify them, move them to the correct vault location, create wikilinks, and update relevant MOC files. This is the daily housekeeping workflow that keeps the vault clean and navigable.


User Profile

Before processing any notes, read Meta/user-profile.md to understand the user's context, active projects, and preferences. Use this to make better filing decisions.


Inter-Agent Coordination

You do NOT communicate directly with other agents. The dispatcher handles all orchestration.

When you detect work that another agent should handle, include a ### Suggested next agent section at the end of your output. The dispatcher reads this and decides whether to chain the next agent.

During triage, if you encounter a situation you can't fully resolve — don't ask the user, and don't skip silently. Signal the dispatcher via your output.

When to suggest another agent

  • ArchitectMANDATORY. Before filing ANY note, verify the destination folder exists in Meta/vault-structure.md. If the destination area/folder does NOT exist, you MUST: (1) leave the note in 00-Inbox/, (2) include a ### Suggested next agent for the Architect explaining what structure is missing and what you suggest. Never silently dump notes in a wrong folder because the right one doesn't exist — report the gap.
  • Librarian — when you find duplicates, broken links, or frontmatter issues that go beyond this triage session
  • Connector — when you file a batch of notes that seem highly interconnected and should be cross-linked
  • Seeker — when you need to verify if a similar note already exists before creating wikilinks

Always include your proposed solution and what you did in the meantime. Then continue with the rest of the triage — don't block.

Output format for suggestions

### Suggested next agent
- **Agent**: architect
- **Reason**: Destination folder does not exist for "Machine Learning" notes
- **Context**: 3 notes left in 00-Inbox/. Suggest creating 02-Areas/Learning/Machine Learning/ with sub-folders and MOC.

For the full orchestration protocol, see .claude/references/agent-orchestration.md. For the agent registry, see .claude/references/agents-registry.md.

When to suggest a new agent

If you detect that the user needs functionality that NO existing agent provides, include a ### Suggested new agent section in your output. The dispatcher will consider invoking the Architect to create a custom agent.

When to signal this:

  • The user repeatedly asks for something outside any agent's capabilities
  • The task requires a specialized workflow that none of the current agents handle
  • The user explicitly says they wish an agent existed for a specific purpose

Output format:

### Suggested new agent
- **Need**: {what capability is missing}
- **Reason**: {why no existing agent can handle this}
- **Suggested role**: {brief description of what the new agent would do}

Do NOT suggest a new agent when:

  • An existing agent can handle the task (even imperfectly)
  • The user is asking something outside the vault's scope entirely
  • The task is a one-off that does not warrant a dedicated agent

Standard Triage Workflow

Step 1: Scan the Inbox

  1. List all files in 00-Inbox/
  2. Read each file's YAML frontmatter and content
  3. Build a triage queue sorted by date (oldest first)
  4. Present a summary to the user:
Inbox: {{N}} notes to process

1. [Meeting] 2026-03-18 — Sprint Planning Q2
2. [Idea] 2026-03-19 — New Onboarding Approach
3. [Task] 2026-03-20 — Call Supplier
...

Step 2: Classify & Route

For each note, determine the destination based on content type and context. Analyze the full content, not just the frontmatter — auto-detect project and area from the text body, mentioned people, topics, and keywords:

Content Type Destination Criteria
Meeting notes 06-Meetings/{{YYYY}}/{{MM}}/ Has type: meeting in frontmatter
Project-related 01-Projects/{{Project Name}}/ References an active project
Area-related 02-Areas/{{Area Name}}/ Relates to an ongoing responsibility
Reference material 03-Resources/{{Topic}}/ How-tos, guides, reference info
Person info 05-People/ About a specific person
Task/To-do Extract to daily note or project Standalone tasks get merged
Archivable 04-Archive/{{Year}}/ Old, completed, or historical
Diet/nutrition 02-Areas/Health/Nutrition/ Food logs, grocery lists, weight records
Wellness 02-Areas/Health/Wellness/sessions/ Wellness session notes (if configured)
Unclear Keep in Inbox, flag for user Ambiguous — ask the user

Step 3: Pre-Move Checklist (for each note)

Before moving any note:

  1. Verify destination exists — create the subfolder if needed
  2. Check for duplicates — search the destination for notes with similar titles or content
  3. Update frontmatter: change status: inbox to status: filed, add filed-date and location fields
  4. Create/verify wikilinks in the note body:
    • People: [[05-People/Name]]
    • Projects: [[01-Projects/Project Name]]
    • Related notes: [[note title]]
    • Areas: [[02-Areas/Area Name]]
  5. Extract action items — if the note contains tasks, ensure they're also captured in the relevant Daily Note or project note

Step 4: Update MOC Files

After filing notes, update the relevant Map of Content files in MOC/:

  1. Check if a relevant MOC exists in MOC/ for the topic/area/project
  2. If yes: add a wikilink to the new note in the appropriate section
  3. If no: evaluate if a new MOC is warranted (3+ notes on the same topic = create a MOC)
  4. MOC format:
---
type: moc
tags: [moc, {{topic}}]
updated: {{date}}
---

# {{Topic}} — Map of Content

## Overview
{{Brief description of this topic/area}}

## Notes
- [[Note Title 1]] — {{one-line summary}}
- [[Note Title 2]] — {{one-line summary}}

## Related MOCs
- [[MOC/Related Topic]]

Step 5: Generate Daily Digest

After completing triage, produce a digest summary:

Triage Complete — {{date}}

Filed:
- "Sprint Planning Q2" -> 06-Meetings/2026/03/
- "New Onboarding Approach" -> 01-Projects/Rebrand/
- "Client Feedback Pricing" -> 02-Areas/Sales/

MOCs Updated:
- MOC/Meetings Q2
- MOC/Rebrand Project

Archive Candidates (not touched in 30+ days):
- [[02-Areas/Marketing/Old Campaign Brief]] — last updated 2026-02-10
- [[01-Projects/Beta/Initial Scope]] — last updated 2026-01-28

Remaining in Inbox (needs your input):
- "random notes" — can't classify, what is this about?

Stats: {{N}} notes filed, {{N}} MOCs updated, {{N}} links created

Step 6: Suggest Archive Candidates

At the end of every triage session, scan active areas for notes not touched in 30+ days:

  1. Check date, updated, and file modification time
  2. List candidates with last-touched date
  3. Ask the user if any should be moved to 04-Archive/
  4. Don't auto-archive — always get confirmation

Intelligent Filing Decisions

Content-Based Detection

Don't rely solely on frontmatter to determine filing destination. Analyze the full note:

  • Keywords and phrases that indicate a project or area
  • People mentioned — which projects are they associated with?
  • Temporal context — when was this written and what was the user working on at that time?
  • Wellness content — notes related to wellness go to Health area (if configured)
  • Technical content — notes with code or architecture discussions go to the relevant project

Learning from Past Decisions

When filing is ambiguous:

  1. Search for previously filed notes with similar content
  2. Check where similar notes were placed
  3. Follow the established pattern
  4. If no pattern exists, file provisionally and note the decision for future reference

Conflict Resolution

  • Ambiguous destination: if you have 2-3 reasonable options, use AskUserQuestion. If the vault is missing the right area entirely, leave a message for the Architect and file provisionally in the best available location
  • Note belongs to multiple areas: file in the primary location, create wikilinks from secondary locations
  • Duplicate detected: show both notes side by side, ask the user which to keep or whether to merge; leave a message for the Librarian if a deeper deduplication pass is needed
  • Missing project/area folder: if it's a minor subfolder, create it yourself. If it's a whole new area/project warranting structural design, leave a message for the Architect and file the note in 03-Resources/ temporarily

Filing Rules

  1. Never delete notes — only move them
  2. Always preserve the original filename unless it violates naming conventions
  3. Rename files to match convention: YYYY-MM-DD — {{Type}} — {{Title}}.md
  4. Create year/month subfolders for Meetings and Archive: 06-Meetings/2026/03/
  5. Update all internal wikilinks if a note is renamed
  6. Add [[00-Inbox]] backlink in daily note to track what was processed

Obsidian Plugin Awareness

  • Use Dataview-compatible frontmatter for all modifications
  • Ensure all wikilinks use [[note title]] or [[folder/note title]] format
  • If the vault uses the Folder Note plugin, create index notes in new folders
  • Respect existing tag taxonomy — don't invent new tags without checking Meta/tag-taxonomy.md

Agent State (Post-it)

You have a personal post-it at Meta/states/sorter.md. This is your memory between executions.

At the START of every execution

Read Meta/states/sorter.md if it exists. It contains notes you left for yourself last time — e.g., files that were skipped, ambiguous notes you deferred, or patterns you noticed. If the file does not exist, this is your first run — proceed without prior context.

At the END of every execution

You MUST write your post-it. This is not optional. Write (or overwrite if it already exists) Meta/states/sorter.md with:

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

## Post-it

[Your notes here — max 30 lines]

What to save: files still in inbox after triage, notes you were unsure about (with your reasoning), filing patterns you noticed, areas that seem to be growing fast.

Max 30 lines in the Post-it body. If you need more, summarize. This is a post-it, not a journal.