When a file is removed from the repo (agents, references, or skills),
the updater now renames it with a "-DEPRECATED" suffix and prepends
a "DEPRECATED DO NOT USE" header instead of silently leaving it.
updateme.sh:
- Core agents in .claude/agents/ that no longer exist in the repo
get renamed to {name}-DEPRECATED.md with deprecation header
(custom agents are never touched)
- References in .claude/references/ that no longer exist in the repo
get the same treatment
- The entire .claude/skills/ directory (removed from the project)
gets renamed to .claude/skills-DEPRECATED/ with deprecation headers
on each SKILL.md
- Summary now reports deprecated file count
launchme.sh:
- Added confirmation prompt before overwriting existing installation
- Skills generation and copying kept intact (generate-skills.py runs
first, then copies to .claude/skills/)
launchme.sh:
- Detects if .claude/ or CLAUDE.md already exist in the vault
- Shows the user what will be overwritten
- Asks for explicit confirmation before proceeding
- Clarifies that custom agents and vault notes are never touched
updateme.sh:
- Asks for confirmation before overwriting core files
- Same clarification about custom agents being preserved
The frontmatter description uses the user's language (for trigger
matching), but the agent body (system prompt) must always be in
English for better LLM instruction-following performance. The agent
still responds in the user's language at runtime thanks to the
language matching rule.
The Architect was copying the multilingual pattern from core agents
and adding translations in 6+ languages to custom agent descriptions.
Custom agents should have their description and trigger phrases
written exclusively in the language the user speaks. Reinforced
this rule in both the generation instructions and the validation
rules section.
The Architect was generating custom agents immediately from a single
user message instead of going through the 5-phase conversation flow.
Added explicit blocking instructions at three points:
- Section intro: "NEVER create an agent in one shot"
- Before the conversation phases: "Do NOT generate the agent
immediately, even if the request seems clear"
- Explicit rule: "You are NOT allowed to create the agent file
until Phase 5"
- Reinforced one-question-per-message rule
README.md:
- Badge changed from "8 Agents" to "8+ Agents"
- Added custom agents as point 4 of "What makes this different",
positioned right after the main pitch for maximum visibility
- Includes a table of real-life scenarios (budget tracking, journaling,
paper reading, project monitoring, client deadline management)
- Links to Terms of Use for the responsibility disclaimer
CONTRIBUTING.md:
- Renamed "Propose a new crew member" to "Propose a new core crew
member" with a note that users can create custom agents via Architect
- Added "Custom agents vs. core agents" section explaining the
distinction between personal custom agents and project-shipped
core agents
TERMS_OF_USE.md:
- Added new Section 9 "Custom Agents" with full disclaimer: custom
agents are entirely the user's creation and responsibility, no
warranty on their behavior, author accepts no liability
- Updated Section 7 (Limitation of Liability) to reference custom
agents explicitly
- Renumbered sections 9-11 to 10-12
- Changed "The ONLY agents you may use are these 8" to acknowledge
that custom agents created by the Architect are also valid
- Added row 9+ to the routing priority table for custom agents
(always lower priority than core 8)
- Added section 9 "CUSTOM AGENTS" with routing logic: when no core
agent matches, check agents-registry.md for custom agents
- Added check for "Suggested new agent" signals in the multi-agent
routing decision flow (step 6)
The Architect can now create, edit, and remove custom agents through
an extended conversational flow with the user.
Changes to the frontmatter:
- Added trigger phrases for custom agent creation in 6 languages
("create a new agent", "custom agent", "crea un nuovo agente", etc.)
New section "Custom Agent Creation" with:
- 5-phase conversation flow (Understanding, Capabilities, Output,
Advanced, Confirmation) where the Architect asks one question at
a time and adapts follow-ups based on user answers
- Agent file generation following references/agent-template.md
- Automatic updates to agents-registry.md and agents.md
- Management commands: edit, remove, list custom agents
- Validation rules: no name conflicts with core 8, minimal tool
permissions by default, mandatory coordination sections
- Quality standards: Core Responsibilities must be detailed enough
to produce a production-quality agent
Also added the "Suggested new agent" subsection (same as other agents).
Each agent now has a "When to suggest a new agent" subsection inside
its Inter-Agent Coordination block. When an agent detects that the
user needs functionality that no existing agent can handle, it
outputs a "Suggested new agent" section with:
- Need: what capability is missing
- Reason: why no existing agent covers it
- Suggested role: what the new agent would do
The dispatcher reads this and asks the user if they want the
Architect to create a custom agent for the detected need.
Agents are also told when NOT to suggest a new agent (existing
agent can handle it, one-off task, outside vault scope).
agents-registry.md:
- Added "Custom Agents" section with rules for how custom agents
are added to the registry (naming, priority, creation flow)
- Custom agents always have lower priority than core 8
- Names must be lowercase with hyphens, no conflicts with core names
agents.md:
- Added "Custom Agents" section explaining what they are, how they
coordinate with core agents, and how to create/edit/remove them
agent-orchestration.md:
- Added "Suggested new agent" signal format so agents can flag when
the user needs functionality that no existing agent provides
- Added step in Dispatcher Decision Logic to check for this signal
- Added "Custom Agent Lifecycle" section covering creation, discovery,
routing, chaining, maintenance, and deletion
New file: references/agent-template.md
This is a reference document that the Architect reads when generating
custom agents. It defines the exact structure every agent must follow:
YAML frontmatter format, required sections (Language, User Profile,
Inter-Agent Coordination, Core Responsibilities, Operational Rules),
placeholder tokens, and inline conventions (naming rules, tool
permissions, multilingual triggers).
The template is not an agent itself. It is a structural guide that
ensures custom agents are generated with the same quality and
consistency as the core 8.
- generate-skills.py now respects SKILLS_DIR env var
- launchme.sh and updateme.sh generate into mktemp -d, copy to vault,
then clean up — no more untracked skills/ left in the repo
- Warn the user when python3 is missing so Cowork/Desktop users know
why .claude/skills/ is absent
- Remove "message board archival" from Librarian responsibilities
- Rename "Who to Message for What" → "When to Suggest Another Agent"
- Replace "Message to" column with "Suggest"
- Move coordination explanation above the table
- Update intro line to reflect dispatcher model
- Fix call-chain example consistency in CLAUDE.md and agent-orchestration.md
(chain lists already-invoked agents, "step N" matches chain length + 1)
- Renumber architect.md Task Checklist (was skipping 3) and replace
"Leave messages" step with dispatcher-driven "Suggested next agent"
- Replace "Leave a message to the Sorter" with signal via Suggested next agent
- Clarify "Do NOT write to other agents' files" → only prompt/config files
(.claude/agents/*.md), normal vault edits still allowed
- Fix agent count 10→8 in docs/getting-started.md
- Initialize SKILL_COUNT before conditional block in launchme.sh
README:
- Removed the "Skills" section since skills/ no longer exists
- Updated the project structure tree to reflect the current layout
- Clarified that agents are discovered natively by Claude Code
CONTRIBUTING:
- Replaced all references to "inter-agent messaging" with the new
coordination protocol (agent-orchestration.md)
- Updated the agent writing guidelines to use "Suggested next agent"
output format instead of the old shared file approach
What changed in every agent file:
- Removed the "Inter-agent messaging" section that referenced the
old shared file protocol (Meta/agent-messages.md)
- Added a "Suggested next agent" output block so agents can signal
follow-up work to the dispatcher without invoking other agents
- Simplified the prompts by removing routing logic that is now
handled centrally by CLAUDE.md
The agents no longer know about each other. They just do their job
and report what else might need attention. The dispatcher decides
whether to chain another agent.
Before this change, agents communicated directly with each other by
writing to a shared file (Meta/agent-messages.md), following the
protocol in references/inter-agent-messaging.md. This was fragile
and hard to control.
Now the dispatcher (CLAUDE.md) is the only coordinator. Agents do
not talk to each other. Instead, when an agent detects work for
another agent (e.g. missing vault structure, orphan notes), it
outputs a "Suggested next agent" section. The dispatcher reads it,
validates it against the agents-registry, and decides whether to
chain the next agent.
New files added:
- references/agent-orchestration.md: the new coordination protocol,
including call chain tracking, anti-recursion rules, and a max
depth of 3 agents per user request
- references/agents-registry.md: a capability registry that maps
each agent to its inputs, outputs, and chaining suggestions
Deleted:
- references/inter-agent-messaging.md: the old peer-to-peer protocol
The skills/ folder contained 8 SKILL.md files (one per agent) that
were auto-generated wrappers. They duplicated the same logic already
present in the agent files under agents/.
Claude Code discovers agents natively from .claude/agents/ by reading
their YAML frontmatter (name, description, tools, model), so the
skills layer was redundant and has been removed.
