v0.9.1

v0.9.1 — Master Orchestrator Rule

Released: 2026-04-22 Theme: The main agent stops doing the work. It only delegates.

TL;DR

For any strong-work mission (multi-file change, migration, perf hunt, security audit, new feature, deep research), the main agent becomes an orchestrator only. It cannot read source files beyond top-level indexes, cannot write code, cannot run tests. It narrows scope, dispatches a specialist, synthesizes the result. Seven new specialist agents carry the actual execution.

Why this rule exists

Before v0.9.1, the main agent did both planning and execution. That produced a pattern the author observed repeatedly: the agent would load a dozen files to "understand context", form hypotheses from half-loaded fragments, then implement based on polluted reasoning. Half-loaded files + partial greps + intermediate hypotheses → hallucination.

Isolation = clean handoffs = fewer hallucinations. This is Kasidit Rule 1 (one mission, one focus) applied at the orchestration layer.

What changed

The Master Orchestrator Rule

When a mission qualifies as strong work, the master agent is forbidden from:

• ❌ Writing code
• ❌ Editing files
• ❌ Running tests or servers
• ❌ Reading source files beyond the top-level index set (CLAUDE.md, PATTERNS.md, DESIGN_SYSTEM.md, สารบัญ, .kasidit/knowledge/ index)
• ❌ Searching / grepping / globbing beyond initial scope detection
• ❌ Fetching docs (delegate to deep-researcher)
• ❌ Writing migrations (delegate to migration-specialist)

The master may only:

• ✓ Narrow the mission and confirm scope with user
• ✓ Detect domain and tier
• ✓ Read the top-level index set
• ✓ Pick the specialist from the registry
• ✓ Write the dispatch brief
• ✓ Synthesize specialist outputs into a user-facing report
• ✓ Decide next step

If the master catches itself doing forbidden work, it stops and spawns a specialist with the accumulated context.

Seven new specialist agents

Agent	Trigger	Scope
bug-hunter	error / crash / wrong output / regression	root-cause + minimal fix; mandatory git log --grep / git log -S
architect-planner	new feature / refactor > 2 files	plan only; no code; lists trade-offs + open questions
perf-profiler	slow / N+1 / high cost / pre-scale	measure first; rank by impact × confidence; top 5 only; does not optimize
test-writer	add tests / regression after fix / coverage gap	one target per call; regression case mandatory after bug fix
refactor-surgeon	extract / rename / split / inline	zero behavior change; test-parity verified
deep-researcher	library / API / framework research	trust hierarchy (source → official docs → release notes → blogs); caches to .kasidit/knowledge/
migration-specialist	schema change / framework upgrade / backfill	expand-contract phases; rollback per phase; risk classification GREEN/YELLOW/RED

Plus the three pre-existing agents (code-reviewer, security-auditor, legacy-specialist), the registry is 10 specialists.

Dispatch brief format

Every specialist invocation must pass a structured brief:

MISSION: <one sentence, verifiable outcome>
INPUTS:
  - <file paths, symptoms, measurements, versions>
CONSTRAINTS:
  - <deadline, compat, perf budget>
EXPECTED OUTPUT:
  - <matches the agent's documented output block>
PRIOR CONTEXT:
  - <findings from earlier specialists, if any>

No brief → no dispatch. This prevents "do stuff" prompts from reaching specialists with ambiguous scope.

Anti-pattern additions

Four new entries in the anti-pattern list:

• ❌ Master agent writing code on a strong-work mission
• ❌ Master reading source files beyond the top-level index
• ❌ Invoking a specialist without a dispatch brief
• ❌ Specialist working outside its documented scope

What changed vs v0.9.0

• Added: Master Orchestrator Rule section in SKILL.md
• Added: 7 specialist agent markdown files under plugins/kasidit/agents/
• Reframed: the old "Multi-Agent Orchestration (v3)" section is now treated as an implementation detail of the master rule — the "how" under the master's "when"
• Anti-patterns: +4 entries

Breaking changes

None for users. For custom workflows that called the main agent to do heavy work directly: expect the agent to refuse and delegate. This is the intended behavior.

Migration

No user action required. On next mission that qualifies as strong work, the master will narrow then spawn a specialist. If you want to force the old behavior (main agent does everything), you can — just phrase the request narrowly enough that it does not qualify as strong work ("trivial one-line fix on a single file" is the documented exception).

See also

• Multi Agent Orchestration — how specialists run under the hood
• v0.9.0 — the release this builds on
• v0.9.2 — the next release