Task Mode

Task Mode is Navigator’s workflow coordinator. It decides how much process a request needs — and gets out of the way when the answer is “none.”

The problem it solves

Before Task Mode, Navigator had three workflow systems that didn’t know about each other:

Skills (frontend-component, backend-endpoint, etc.) carry their own mini-workflows — Step 1 through Step 7.
Loop Mode ran a separate phase system, INIT through COMPLETE.
CLAUDE.md documented a workflow that nothing actually enforced.

When more than one of these tried to drive at the same time, they conflicted. Task Mode is the single entry point that routes a request to exactly one of them. And as of v7, the routing itself is no longer a prose instruction: activation scoring runs at prompt time in the hook runtime, so it happens whether or not the model remembers to do it.

The decision tree

Every request flows through one branch:


User Request
    ↓
TASK MODE (auto-detect)
    ├─ Trivial?          → Direct execution (no overhead)
    ├─ Skill matches?    → Defer to the skill (it has a workflow)
    └─ Substantial,
       no skill match?   → Task Mode phases

Trivial — a typo fix, a one-line change, or anything you frame as “quick” / “just do” — runs directly. No phases, no banners.
A skill matches — “create a component”, “add an endpoint”, “write a migration” — Task Mode steps aside and lets the skill run its own workflow.
Substantial work with no matching skill — refactors, cross-system changes, vague requirements needing research — gets the Task Mode phases.

Complexity is scored from the request: multi-file scope, planning language, and cross-system reach push it up; a single named file or “quick” pull it down. Substantial work crosses the configured threshold (0.5 by default). The scoring runs on UserPromptSubmit via the prompt_gate op — off-switch workflow_enforcer_hook.enabled in .agent/.nav-config.json. Since v7.7.0 the keyword score can be overridden by the opt-in typed judge: a four-level complexity rubric answered by TypeSafe Jev replaces the keyword sum when the model is confident, and the keywords answer otherwise.

The phases

When Task Mode activates, it provides phase guidance rather than strict gating:


RESEARCH → PLAN → IMPL → VERIFY → COMPLETE

RESEARCH explores the codebase (via the Task agent), PLAN drafts the approach, IMPL makes the changes, VERIFY runs tests and simplification, and COMPLETE hands off to the autonomous completion protocol. This is guidance, not gating — the v6 mandate to render a WORKFLOW CHECK block before every task is retired; progress is tracked by the runtime, not by blocks the model must remember to print.

Why “defer to skills” matters

This is the rule that keeps two systems from fighting. A skill like frontend-component already encodes the right workflow for its job. If Task Mode layered its own phases on top, you’d get duplicated structure and conflicting instructions. So when a skill matches, Task Mode announces it and exits — the skill owns the work. (Set defer_to_skills: false to force phases anyway.)

Task Mode vs Loop Mode

They solve different problems and can run together:

Aspect	Task Mode	Loop Mode
Activation	Auto-detected from complexity	Explicit trigger (“run until done”)
Iteration	None — one pass through phases	Iterates until the exit gate clears
Skill coordination	Defers to matching skills	Independent
Best for	Features	Autonomous / unattended work

When both are active, Loop Mode wraps Task Mode — each iteration advances through the phases.

Hooks as Runtime — the v7 runtime that scores prompts
Task Mode configuration — full config key reference
Loop Mode — the autonomous-iteration companion
nav-workflow skill — the skill that implements Task Mode