build-right-execution

Build Right Execution

Use this skill after pre-execution work has produced product truth, MVP scope, operating rules, and an executable task queue.

Core rule:

Do one task.
Prove the current state.
Change narrowly.
Verify with the right evidence.
Update the tracker.
Then move to the next task.

Required Reading

• Always read references/workflow.md before acting.
• Read references/gates.md before task selection, after task intake, and before advancing to another task.
• Always read references/review-and-delegation.md before the review phase. Its Standards, Spec, and correctness/evidence axes apply to every task; trigger rules determine review depth and whether extra independent review is required.
• Read references/evidence-contract.md before completing or updating a task.
• Read references/execution-discipline.md after task intake. Select its bug, feature, or refactor lane from the task's existing Type and stated goal; do not add a mandatory task field.
• Read ../build-right-engineering-principles/references/principles.md before implementation or review when a task touches architecture boundaries, public APIs, package ownership, provider adapters, generated code, error semantics, tests, observability, security, or enforceable policy.
• Use assets/templates/task-template.md when creating a missing task or splitting an overbroad task.
• Use bundled helper scripts only through the full Bun command form shown below. Do not rely on PATH aliases or invoke short names such as continue-check as shell commands.
• Invoke every managed helper used as evidence as its own direct Bun shell command. Do not chain it with &&, ;, pipes, redirects, or trailing commands; the native evidence gate binds success to that isolated invocation.
• Use the state resolver before selecting a task or advancing through a queue. Report and reconcile its decision before continuing.
• The managed execution entrypoint performs setup orchestration before calling the separate read-only scripts/continue-check.ts resolver and provider adapter when task bindings exist. Never ask the user to invoke provider setup, validation, progress, synchronization, archive, or any provider command.
• Use the execution helper for deterministic task, contract, and gate signals. Treat script output as input to judgment, not authority.