Big Swing

Use GitHub as the durable coordination layer for a long-running goal. If the user explicitly names another issue-and-review system, adapt the same workflow there; otherwise use GitHub issues and PRs. For GitHub work, prefer the gh CLI for issue and PR operations; use another available GitHub interface only when gh is unavailable.

Principles

• The harness goal is the overall objective; GitHub is the durable state that survives handoffs.
• One issue should be one independently implementable unit of work.
• Issues are context delivery. A fresh agent should be able to implement an issue without hidden chat history; links supplement context but do not replace it.
• PRs are the reviewer interface. An issue is not done until its PR has passed independent review and merged.
• Keep PRs small enough to review deeply. Split or re-scope work that becomes diffuse.
• Keep the progress tracker issue authoritative: current plan, shared context, issue checklist, and final status.
• Do not worry about backward compatibility unless explicitly told to. Do not add compatibility shims, preserve legacy behavior, or constrain the design for hypothetical old callers unless the user or tracker requires it.
• Be willing to take a big swing when the plan is sound. Prefer the cohesive, modern solution over timid incremental patches; confidence must come from repo context, validation, and review.

Templates

Load references/templates.md when creating or updating the progress tracker, implementation issues, or PR descriptions.