• .sync-state.json

  must exist in the repo root (create from template if missing)

• .sync-state.json#eve_horizon_path

  must point to a readable eve-horizon Git checkout

• .sync-map.json

  must exist in the repo root

• Distill only shipped platform behavior. Plans marked Implemented/Complete describe shipped features.
• Do not carry roadmap content into skillpacks. Ignore plans marked Proposed/Draft and sections like

  Planned (Not Implemented)

  ,

  What's next

  , or "current vs planned" framing.
• Keep

  eve-work/eve-read-eve-docs/SKILL.md

  task-first: route by intent, load only the minimal reference files needed.
• Keep reference docs scoped and actionable — curated distillations, not copies.

git -C "$HORIZON_PATH" log --oneline "$LAST_SYNCED_COMMIT"..HEAD

• feat:

  — new capabilities (primary interest)

• fix:

  — bugfixes that may affect documented behavior

• docs:

  — documentation changes (check if they describe already-shipped features)

• chore:

  /

  refactor:

  — usually no skillpack impact, but note removals

git -C "$HORIZON_PATH" diff --stat "$LAST_SYNCED_COMMIT"..HEAD -- docs/plans/

sed -n '1,20p' "$HORIZON_PATH/docs/plans/<plan-file>.md"

• Shipped: Status contains

  Implemented

  ,

  Complete

  , or

  Done

  — these are the primary source of truth for new capabilities
• In progress: Status contains

  In Progress

  ,

  Partially Implemented

  — note for awareness but don't distill unfinished work
• Proposed/Draft: Status contains

  Proposed

  ,

  Plan

  ,

  Draft

  ,

  Ready to build

  — skip entirely
• Removed: Plan files deleted in this range — something was deprecated or abandoned

1. Does an existing reference already cover this area? → Worker updates it
2. Is this a new primitive that needs its own reference? → Worker creates it
3. Was something removed? → Worker cleans stale content from affected references

eve-work/eve-read-eve-docs/SKILL.md

reference_docs

.sync-map.json

eve-work/eve-read-eve-docs/SKILL.md

• New entries in the Task Router
• New entries in the Index
• New rows in the Intent Coverage Matrix
• New trigger keywords in the frontmatter
• Removal of stale entries for deprecated capabilities

.sync-map.json

skill_triggers

composite_triggers

• eve-se/eve-manifest-authoring

  — if manifest shape changed

• eve-se/eve-deploy-debugging

  — if deploy/infra behavior changed

• eve-se/eve-auth-and-secrets

  — if auth model changed

• eve-work/eve-agent-memory

  — if storage primitives changed

• eve-design/eve-fullstack-app-design

  — if app patterns changed

• Title:

  Update <target-file>: <capability name>

• Description — everything a worker needs to operate independently:
  • The eve-horizon repo path resolved from

    .sync-state.json#eve_horizon_path

  • The commit range:

    <last_synced_commit>..HEAD

  • Which plan(s) to read (the shipped plans relevant to this update)
  • Which source files to diff or read (code, system docs)
  • The target file path to update or create
  • Whether this is a reference doc update, skill update, new reference, or removal
  • The appropriate worker instructions from below

Update sync state and produce report

eve-work/eve-read-eve-docs

• Run state-today compliance scan for eve-read-eve-docs

• Validate progressive-access routing in eve-read-eve-docs/SKILL.md

• Update .sync-map.json with any new reference doc mappings

1. The plan file(s) to read — these are the primary source of truth
2. The git diff command for relevant code/doc changes
3. The target file to read and modify
4. The capability summary from Phase 2
5. The appropriate worker instructions from below

Your primary sources are shipped plans (marked Implemented/Complete) and code changes. System docs are secondary — they may lag behind or be absent.

1. Read the plan(s) listed in your task — understand what shipped and why.
2. Read the current reference doc you're updating.
3. Run the git diff for relevant source files (code, system docs).
4. If the plan references specific CLI commands or APIs, verify they exist:
   bash

   test -f "$HORIZON_PATH/packages/cli/src/commands/<name>.ts"

5. Distill the shipped capability into the reference doc:
   • What it does (from plan + code)
   • How to use it (CLI commands, manifest config, API calls)
   • Key constraints or requirements
6. Exclude roadmap content. Only document what is implemented.
7. Edit the existing file; do not rewrite from scratch.
8. Preserve existing structure, voice, and formatting.

1. Read the plan(s) that describe this capability.
2. Check for any system doc coverage at

   $HORIZON_PATH/docs/system/<name>.md

   (may not exist).
3. Read the CLI command source at

   $HORIZON_PATH/packages/cli/src/commands/<name>.ts

   if relevant.
4. Create a reference doc that follows the conventions of existing references in

   eve-work/eve-read-eve-docs/references/

   .
5. Include: purpose, CLI commands/flags, manifest config if relevant, key behaviors, constraints.
6. Keep it concise and agent-actionable. These are distillations, not documentation copies.
7. State-today only — no planned/roadmap content.

Your primary sources are shipped plans and code changes.

1. Read the plan(s) listed in your task.
2. Read the current SKILL.md you're updating.
3. Update with new commands, changed workflows, or new capabilities.
4. Remove stale content that references deprecated features.
5. Keep state-today only. Ensure progressive disclosure.
6. Maintain imperative voice and conciseness.
7. Edit the existing file; do not rewrite from scratch.

This worker updates the eve-read-eve-docs SKILL.md routing, index, and coverage matrix.

1. Read the current

   eve-work/eve-read-eve-docs/SKILL.md

   .
2. For each new reference doc created by other workers, add:
   • A Task Router entry describing when to load it
   • An Index entry with the file path and one-line description
   • An Intent Coverage Matrix row if it serves a distinct user intent
3. For each removed capability, clean up stale routing entries.
4. Add any new trigger keywords to the YAML frontmatter.
5. Maintain alphabetical or logical ordering within sections.

This is a cross-cutting skill that spans multiple platform primitives. Your job is to validate that the skill's claims match current platform reality.

1. Read the SKILL.md and all files in its

   references/

   directory.
2. Read the shipped plan(s) listed in your task for context on what changed.
3. List current CLI command modules:
   bash

   find "$HORIZON_PATH/packages/cli/src/commands" -maxdepth 1 -name '*.ts' -print | sort

4. Scan the skill for stale claims:
   • "No dedicated X" / "X not available" / "not yet supported" — check if X now exists.
   • "Current Gaps" or "Workarounds" sections — verify each gap is still a gap.
   • Decision tables or comparison matrices — check for missing rows.
   • References to removed features (e.g., inference/ollama/managed-models).
5. If stale claims are found, update the skill. Add new primitives. Remove false gaps.
6. Keep state-today only. Maintain imperative voice and conciseness.
7. Edit existing files; do not rewrite from scratch.

Report what was stale and what you corrected.

Update

.sync-map.json

to reflect new mappings discovered during this sync.

1. Read the current

   .sync-map.json

   .
2. For each new reference doc created, add a

   reference_docs

   entry mapping the source files to the target.
3. For each new skill trigger relationship discovered, add a

   skill_triggers

   entry.
4. For removed source docs, clean up stale mappings.
5. Ensure

   watch_paths

   covers any new directories that should be monitored.

• Distill only shipped behavior from the plan and code
• Edit the existing file; do not rewrite from scratch
• These are curated distillations for agents, not copies
• Keep it concise and actionable

undefined

1. Get current HEAD:
   bash

   git -C "$HORIZON_PATH" rev-parse HEAD

2. Run the state-today check before recording the cascade:
   bash

   ./private-skills/sync-horizon/scripts/check-state-today.sh

3. Update

   .sync-state.json

   :
   • Set

     last_synced_commit

     to the HEAD hash
   • Set

     last_synced_at

     to current ISO timestamp
   • Prepend a sync-log entry, sort entries newest-first, and keep the latest 10
4. Run the complete deterministic checks twice after the state update. The second pass must be a no-op and produce the same successful result:
   bash

   ./private-skills/sync-horizon/scripts/check-state-today.sh
   python3 scripts/check-repository.py
   python3 scripts/check-source-sync.py --source "$HORIZON_PATH"
   
   ./private-skills/sync-horizon/scripts/check-state-today.sh
   python3 scripts/check-repository.py
   python3 scripts/check-source-sync.py --source "$HORIZON_PATH"

• <count> commits synced (<feat count> features, <fix count> fixes)

• <capability>: <one-line summary> (plan status, feat commits)

• <capability> → updated <reference/skill>, because <reason>

• <what was removed/deprecated and cleaned from skills>

• <file>: <what changed and why>

• <file>: <what it covers>

• <skill>: <what changed>

• <new routes, index entries, or coverage matrix rows>

• <new mappings added>

• <pass/fail + scan results>

• <shipped capabilities with no reference doc yet>
• <plan files with no sync-map entry>
• <CLI commands with no documentation coverage>

• <manual follow-up needed>

undefined

• Plans are the primary source of truth for understanding what shipped. System docs are secondary. Code changes are confirmation.
• Orchestrator reads lightweight signals only: commit log, plan headers (first 15-20 lines), file stats, CLI module list. Never full plans, full diffs, or source docs.
• Workers read the heavy content: full plans, code diffs, source docs, target files.
• Worker independence: Each worker prompt must be fully self-contained with plan paths, code paths, target path, capability summary, and update rules.
• Parallelism: All workers launch simultaneously. No worker depends on another worker's output (except the routing update worker, which should launch after reference doc workers finish).
• Edit, don't rewrite: Workers modify existing files incrementally.
• State-today fidelity: Only document shipped, implemented behavior.
• Progressive access: Preserve task-first routing in entry skills and keep deep detail in references.