MCP Task Orchestrator · Field guidePlate 9 of 9
Friction noticed during work becomes a tracked item. Friction that recurs becomes a trend. A trend seen twice becomes a concrete proposal to change the config, and a person decides whether to adopt it.
A plugin hook watches advance_item and complete_tree. A run counts as finished when a parent reaches terminal by cascade, or complete_tree completes at least one item. What happens next is set by retrospective.mode in the project config.
nudge, the defaultThe session is told a retrospective is suggested and given the command to run. The user decides.
dispatchOnce at least dispatchThreshold items (default 3) have reached terminal, the orchestrator launches one background retrospective agent at the next pause in the run. Smaller runs still get a nudge.
offNothing is emitted. Retrospectives run only when someone invokes /task-orchestrator:session-retrospective.
A single item finishing on its own does not trigger straight away. It is recorded, and a hook at the end of the turn nudges once. After a retrospective runs, a cooldown (default 30 minutes) stops repeat prompts for the same work.
It reads the session-tracking note on each item of the run (up to 20), plus the optional delegation-metadata note recording which model did the work. Then it scores five things.
The result is a retrospective item under the Session Retrospectives container, with queue notes session-metrics, workflow-evaluation and improvement-signals, and a work note actions-taken written last.
title: trend: thin-review-checklist — review notes
restate the plan instead of checking it
summary: Reviewers copy acceptance criteria without
evidence. Sessions: 2. Last seen: 2026-09-30.
tags: retrospective-trend,note-quality
notes: evidence-2026-09-24-4c1e (work)
evidence-2026-09-30-b07a (work)
The short key in the title is the trend's identity. A new finding is matched to an existing key first, then by search when the match is uncertain.
Each session that sees the finding again adds one evidence note and increments the count. The summary is rewritten to stay short.
A trend at Sessions: 2 or more graduates. Trend items are never started or completed. They are cancelled when archived.
The example values are illustrative. The format is the skill's own.
A proposal is a work item with three required notes, one per phase: proposal, adoption-decision and outcome-verification. Pick a scope and a decision to see where it ends up.
A project proposal changes one project's schemas or workflow. A global proposal changes the shared server config or the plugin itself.
An observation is a small item recording something the tooling got wrong or made hard. Each is its own root, low priority, tagged agent-observation plus one kind.
Before one is created, the backlog is searched for the same issue, so repeats add context to an existing item. They stay outside every project because tool friction is not specific to one codebase.
| Process schema | Notes, by phase |
|---|---|
agent-observation | queue observation-detail · work resolution (optional) |
session-retrospective | queue session-metrics, workflow-evaluation, improvement-signals · work actions-taken |
improvement-proposal | queue proposal · work adoption-decision · review outcome-verification |
container | Manual lifecycle, so a container never closes when its children do. |
These four schemas are this project's global config: the floor every project sharing the server inherits. That is how the loop works across repositories with no per-project setup.