kf-g-agent-orchestrator

orchestrator（orchestrator-workers）

Terminology

• Launch batch: A group of workers that the orchestrator launches simultaneously in a single decision
• orchestrator cycle: One cycle from worker launch → receiving results → integration → next decision
• Re-delegation: Redoing a worker for the same purpose (including resume)
• Delegation instruction: Structured prompt that the orchestrator passes when launching a worker

Assumptions

• worker: Refers to subagents.
• worker skill: .agents/skills/kf-g-agent-worker-common/(Common rules for all workers).
• Delegation instruction template: references/delegation-instruction.md（orchestrator → worker）。

orchestrator rules

orchestrator は Only worker delegation and design/planning based on its reports is performed. Exploration, implementation, and verification of the target repository are delegated to workers.

• Delegate all actual work to workers
• 1 to 5 workers per worker launch process (follow the splitting policy). Launch only 1 worker for the same question
• Parallel only when safe (read-only, or file ownership is separated)

Splitting policy

Before launching, enumerate independent work units, and if there is no duplicate reference, dependency, or forced splitting, launch with that number (upper limit 5).

Examples of independent work units: Investigation of different files / directories / URLs, implementation of multiple files with no dependencies, different verification targets.

Launch count

1. Count independent units
2. ≥5 → Launch the top 5 by priority (the rest in the next cycle)
3. 1–4 → Launch with that number (do not split to reach 5)
4. 1 → 1 worker

Conditions for keeping it below 5(splitting prohibited when applicable):

• Duplicate reference to the same file / same URL or website
• Cannot be parallelized due to sequential dependency
• Work is small and parallelization cost > benefit
• Artificial subdivision (e.g., duplicating consideration of wording in the same file across multiple workers)

"5 if possible": Independent units ≥5 and not falling under the above prohibitions → prioritize 5 workers. If not applicable → 1–4 is acceptable; do not forcibly increase to 5.

Ownership separation: Separate the reference scope for investigation, file ownership for implementation, and verification target for each worker. Launch the verification worker separately after implementation integration.

What the orchestrator may do

• Creation of design, plan, and policy
• Read the metadata of this skill and the delegation instruction template
• Check the name / description of the skill passed to the worker

Do not directly explore or read files in the target repository; delegate to an exploration worker.

Workflow (example)

1. If requirements are ambiguous, confirm the goal and completion conditions with the user
2. Before delegation, determine the skill each worker should reference from name / description and specify it in the delegation instruction
3. Integrate worker reports. Resolve contradictions first
4. Fix the design and scope before implementation
5. After implementation, always launch a verification worker and independently confirm the implementation worker's claims
6. Final answer to the user with evidence and remaining risks

orchestrator delegating to workers

Delegate the next task to a worker. No exceptions based on scale or simplicity.

• browser operations (including cursor-ide-browser MCP)
• WebSearch / WebFetch
• Read / Glob / Grep / code exploration
• Shell / command execution
• File editing/deletion
• Running tests, lint, and verification
• Launching built-in subagents (Task tool)
• All actual investigation, implementation, and verification work falling under the above

Skill selection (orchestrator)

The orchestrator selects the skills to pass to the worker and lists them in the delegation instruction.

1. Delegation instruction skills に must kf-g-agent-worker-common include (in exceptional cases, only none is allowed)
2. List each skill with {name} — {path} (path required)
3. List only the skills necessary for the task
4. The worker references only the listed skills

If the worker requests needs-escalation additional skills, the orchestrator reselects and redelegates.

Upper limit

• Launch batch: up to 5 workers
• Redelegation: up to once per worker
• orchestrator cycle: normally 3 (investigation → implementation → verification). For a total exceeding 5, or additional cycles after a verification failure, obtain user approval

Worker selection

Purpose	worker	Execution
Web fetch, file reading, code exploration	/research-worker	Parallel allowed, background allowed
Editing following an approved design	/implementation-worker	Parallel only when there is no file overlap
Independent confirmation of claims, diffs, and tests	/verification-worker	After implementation
Work that does not fit the defined workers (browser, Shell, mixed work, etc.)	/general-worker	Follow permissions / scope

Selection priority: if a specialized worker (research / implementation / verification) fits, choose the specialized worker. Only when none applies, use /general-worker .

worker model

When launching a worker subagent,model is determined in the following priority order.

1. The target worker's agent definition（.agents/{worker名}.md）の frontmatter に model exists → use it
2. model model undefined → .agents/general-worker.md の frontmatter model as fallback

• When launching a worker, the orchestrator specifies model according to the above priority order
• Do not write the fallback source model name as a fixed value in this skill (refer to.agents/general-worker.md )

Delegation procedure

1. Write the worker delegation instruction (seedelegation-instruction.md ). Pass only the necessary facts. When running multiple workers in parallel, explicitly state file / URL ownership in the constraints' 並列競合メモ Specify file / URL ownership in
2. Explicit launch: /research-worker ...、/general-worker ...、/implementation-worker ...、/verification-worker ...
3. For additional input, resume(agent ID) takes priority. Avoid unnecessary cold starts
4. If the report has deficiencies (budget overrun, missing rationale, prompt repetition, unauthorized skill references, missing worker skill, output format violation), reissue the delegation instruction or fix via resume

Integrated output (for users)

• Work performed
• Key design decisions
• Basis (path, URL, test results)
• Verification results
• Remaining risks and follow-up

Keep the orchestrator's explanation brief. Leave worker details to the structured report.