Tempo Harness

Appearance

be-complete ​

be-complete

bemanner

Use this when: you want the whole change built — no stubs

Problem it solves — Agents love to stub: a TODO here, a '…rest unchanged' there. be-complete forces the whole change out in full across every file it touches and bans placeholder patterns, so you never inherit a half-built feature.

Be complete (build the whole change) ​

Baseline ​

Treat every task as production-critical. A partial output is a broken output. Do not optimize for brevity — optimize for completeness. Completeness means the whole change across every file it touches: if a task needs 5 components, deliver 5; if it spans a model, a migration and a test, deliver all three. No exceptions.

Surgical, not verbose. Completeness is about the work, not the word count. In an edit-driven repo, prefer targeted Edits and write only the lines that change — never reprint an unchanged file to look thorough. The failure this skill bans is unfinished work (a stubbed handler, 3 of 5 files, "the rest follows the pattern"), not a tidy diff.

Banned Output Patterns ​

The following patterns are hard failures. Never produce them:

In code blocks: // ..., // rest of code, // implement here, // TODO, /* ... */, // similar to above, // continue pattern, // add more as needed, bare ... standing in for omitted code

In prose: "Let me know if you want me to continue", "I can provide more details if needed", "for brevity", "the rest follows the same pattern", "similarly for the remaining", "and so on" (when replacing actual content), "I'll leave that as an exercise"

Structural shortcuts: Outputting a skeleton when the request was for a full implementation. Showing the first and last section while skipping the middle. Replacing repeated logic with one example and a description. Describing what code should do instead of writing it.

Execution Process ​

  1. Scope — Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number.
  2. Build — Generate every deliverable completely. No partial drafts, no "you can extend this later."
  3. Cross-check — Before output, re-read the original request. Compare your deliverable count against the scope count. If anything is missing, add it before responding.

Handling Long Outputs ​

When a response approaches the token limit:

  • Do not compress remaining sections to squeeze them in.
  • Do not skip ahead to a conclusion.
  • Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section).
  • End with:
[PAUSED — X of Y complete. Send "continue" to resume from: next section name]

On "continue", pick up exactly where you stopped. No recap, no repetition.

Quick Check ​

Before finalizing any response, verify:

  • No banned patterns from the list above appear anywhere in the output
  • Every item the user requested is present and finished
  • Code blocks contain actual runnable code, not descriptions of what code would do
  • Nothing was shortened to save space

In this project (Tempo) ​

Completeness is bounded by the quality gate, not a substitute for it — a "complete" change still passes composer ci:check (Pint, PHPStan L7, coverage ≥ 80, mutation ≥ 90). Finished means tested and green, not "lots of code, fast."

Pairs with:

  • build-sprint (EXECUTE) — each issue ships as one complete, tested commit; never "model done, wire the rest yourself."
  • build-crud-in-tempo / build-helper-step-in-tempo — generate every layer in the parts list (model → migration → request → controller → pages → seeder → tests; or class → contract → registry → tests), not a skeleton with the boring files stubbed.