| name | fulmen |
| description | Orchestrate the Fulmen multi-agent harness: planner -> critic -> explorer -> worker -> verifier -> optional assembler. Use when the user invokes Fulmen or a task benefits from delegated subagent work. |
Fulmen
When the user invokes /fulmen with a task, or otherwise explicitly asks to use
Fulmen or subagents, you are the orchestrator. Run the sequence below. Do not
skip steps without stating why.
Fulmen uses these subagent roles: planner, critic, explorer, worker,
verifier, and assembler.
Claude Platform Notes
Fulmen defines no Claude-specific reasoning-effort override. Use the platform's
normal agent invocation behavior unless a supported Claude setting is explicitly
available in the current environment.
Step 0 - Mode Decision
Assess the task complexity:
- Lightweight: well-understood task, narrow scope, no strategic ambiguity -
jump to Lightweight Mode.
- Full: unclear scope, strategic choices, significant risk, or multiple
moving parts - proceed with Step 1.
Step 1 - Write the Fulmen Brief
Synthesize the user's task into a structured brief. Fill unknown fields with
not specified or a clearly labeled assumption. Ask one clarifying question only
when proceeding could change the intended outcome.
## Fulmen Brief
**Goal**: [one sentence: what should be accomplished]
**Constraints**: [hard limits: what cannot change, what is off-limits]
**Definition of done**: [how to know the task is complete]
**Out of scope**: [explicit exclusions]
**File scope** (if known): [directories, files, or modules in play]
Share the brief as a concise progress update. Ask the user only if a missing
field creates a real risk of doing the wrong work; otherwise proceed.
Step 2 - Spawn Planner
Invoke the planner agent. Pass the full Fulmen brief as its input. Wait only
when the next step is blocked on its result.
The planner returns a numbered plan with assumptions and resources listed.
Step 3 - Spawn Critic
Invoke the critic agent after the planner completes. Pass both the Fulmen brief
and the planner's output.
The critic returns a structured problem list: risks, scope violations, missing
constraints, and unstated dependencies.
Step 4 - Integrate
Resolve the plan against the critic's problem list and produce a working plan.
For each problem raised, mitigate, accept, or revise the plan before proceeding.
Step 5 - Spawn Explorer
Distill from the working plan a single scoped question about the codebase or
system. Invoke explorer with that question only. Do not pass the full plan or
Fulmen brief.
The explorer returns structured findings: files, functions, dependencies, and
gaps.
Step 6 - Spawn Worker
From the working plan and explorer findings, distill the scope-limited
implementation task. Invoke worker with:
- what to implement, specific and bounded
- which files are in scope
- a disjoint write scope: exact files or directories the worker owns and may edit
- definition of done from the Fulmen brief
Do not pass the full plan. Pass only the relevant slice.
Step 7 - Verify
For non-trivial code changes, invoke verifier with:
- the Fulmen brief
- the worker completion report
- changed paths
- relevant explorer findings
- the behavior being claimed as complete
Tell the verifier it is read-only and must not edit files.
Skip verifier only for doc-only changes, purely mechanical edits, or tasks where
independent verification would add no useful evidence. State when it is skipped.
Step 8 - Assemble (Conditional)
If worker and verifier output is complex, multi-part, or needs reconciliation,
invoke assembler with the relevant explorer, worker, and verifier outputs.
If the outputs are already clear and complete, skip assembler.
Step 9 - Return
Review the final output against the Fulmen brief. Confirm definition of done,
scope boundaries, critic risks, and verifier findings before reporting back.
Lightweight Mode
Use when scope is narrow and planning overhead is not warranted.
- Write a short scope note.
- Invoke
explorer with a scoped question.
- Invoke
worker with the bounded task and explorer findings.
- Invoke
verifier for non-trivial code changes.
- Review output against the scope note and report to the user.
