harness-englisted

# Harness Engineering Use this skill to make an agent-run project easier to start, steer, verify, resume, and improve. Favor local project artifacts over chat-only guidance. ## Core stance - Build a harness only around a real workflow the user wants repeated. - Keep the injected instruction file short: it should be a table of contents, not an encyclopedia. - Move durable knowledge into repo-local docs, scripts, checks, and templates. - Encode high-value judgment as mechanical checks when possible. - Every harness component should earn its keep through a clearer start, safer edit, stronger verification, or better handoff. ## First pass 1. Inspect the project locally: root files, existing docs, package scripts, tests, git state, and any existing session/progress files. 2. Identify the agent's repeated failure mode or bottleneck: startup, context discovery, feature selection, verification, review, handoff, architecture drift, or cleanup. 3. Choose the smallest harness surface that fixes that bottleneck. 4. Add or edit only the earmarked artifact. Do not scatter duplicate instructions. 5. Verify the harness by running the cheapest check that proves a future agent can follow it. ## Harness artifacts Use these only when they fit the project: - `AGENTS.md`: short operating map, source-of-truth pointers, definition of done, and project-specific guardrails. - `init.sh`: one command for setup/baseline verification/startup hints. It should print the cwd and fail clearly. - `prog