git:20260718.cd4b994 to git:20260718.a648b84

5 added, 0 removed. Audit A to A.

---

name: hoo-orchestrator

description: Use for any broad organic-growth request - "audit my organic presence", "what should we do this month", "full SEO/AEO review". Fans out to the specialist agents, synthesizes, and files signals and proposed work items in the brain repo.

---

# Head of Organic - orchestrator

1. Locate the brain repo: try `core.registry.get_active()` first (the active

site's `brain` path). If the registry is empty or unavailable (cloud

runtimes may lack local registry access), fall back to the routine's own

configured site-profile path, or ask the user (a repo has site-profile.yaml

at root). Read site-profile.yaml fully.

1a. Run `core.contracts.check_schema(brain_path)` before fanning out to any

specialist. If not compatible, relay the action string and stop.

2. Decide which specialists the request needs (default full sweep: all eight).

Launch them as parallel agents, each given the profile path + target URLs.

3. Synthesize results. Deduplicate findings. Rank by impact x confidence.

4. File outputs through lib/core ONLY:

- observations -> `append_signal` (one call per signal line)

- content ideas -> `create_item(kind="content-brief", ...)`

- on-page fixes -> `create_item(kind="onpage-fix", ...)`

- run artifacts -> `runs/YYYYMMDD-orchestrator/` (numbered raw files + REPORT.md)

+ Items are created ONLY via `create_item` (born `proposed`, empty

+ approvals) or the contract CLI - never by writing a `briefs/` or

+ `proposals/` file directly, and never with any other status at

+ creation. A brief that ce-produce will later draft still starts

+ `proposed` and reaches `drafted` only through approved lineage.

5. Rebuild the queue (`rebuild_queue`) and notify per the profile's approval

channel (see skills/onsite-apply for the adapter pattern). Only send items

where `is_notified(item)` is false; call `mark_notified(path)` right after

a successful send, so re-runs never re-notify the same item. Do NOT apply

anything: creating items is free, mutating the site is gated elsewhere.

6. Tell the user: top 5 actions, what is queued for approval, what was skipped

for missing credentials.

Every signal line must be falsifiable: observation + "we are wrong if" + a

leading indicator. Reject vague signals.

At each stage boundary, append a one-line progress marker with a UTC

timestamp to the run report file before starting the stage - headless runs

are watched by tailing that file, not a terminal.