repo-synclisted

# Repo Sync Bidirectional sync between a plan document and GitHub issues. Creates, updates, closes, and **enriches** issues so GitHub mirrors the plan's structure and any fresh-context LLM picking up a step has enough context in the issue body to start work. ## Principle: optimize for LLM effectiveness, not human-noise reduction Issue bodies should be substantive. A fresh-context model reading `gh issue view #N` should understand: - What to build (not just a name) - Where in the codebase (specific files) - How to know it's done (concrete acceptance) - What it depends on (prior issues, blocked-by relationships) - Build-phase flags (reviewers, isolation, **`--ui` when frontend is touched**) - Where the canonical design lives (build doc + section anchor) - **Whether the step can run in parallel with neighbors** (declared explicitly, not left for the operator to infer) Lean bodies (just "What to build" and a footer) tax every future session that picks up that issue. Treat enrichment as a first-class output, not optional polish. Issue count and inbox tidiness are human-experience costs the operator is fine paying — don't optimize for them at the expense of the LLM-context-effectiveness above. ## Operator preference (HEAVY) — autonomous + bundled UI + parallel This skill propagates the operator's strong workflow preference through every issue it writes. Three dials, applied to every step body: 1. **Autonomous build readiness.** Step bodies must contain enough acceptance