full-output-enforcement

A deliverable is complete when each item the request named is present in full and nothing was silently dropped. Partial work declared finished is the defect this skill exists to stop. The enemy is the convenient shortcut: an ellipsis standing where code belongs, a "similar to above" covering for the seventh item, a list quietly shedding entries, a stub dressed as finished work.

Completeness is a contract. Run the procedure below before handing a deliverable back. The standard is observable: scan the artifact for banned shortcuts, count delivered items against requested items, and confirm no stub claims completion. Read the completeness rules for the contract, the banned-shortcut catalog, the large-output protocol, and a worked truncated-vs-complete contrast.

Steps

1. List the requested items. Enumerate what the request named (each file, each function, each list entry, each section) as an explicit checklist. A deliverable cannot be checked complete against an unstated scope, so the checklist is the first artifact. Done when the requested-item count is written down.

2. Deliver each item in full. Write every listed item end to end, with no body deferred to a later turn and no placeholder standing in for content. The completeness rules name the banned shortcuts: ellipsis-omission, "fill in the rest", "similar to above", silent list-dropping, a stub presented as complete. Done when each checklist item has a full body, not a promise of one.

3. Split large output into complete pieces. Output too large for one message gets divided across files or messages, each piece whole on its own, never a fragment that trails into an ellipsis. State plainly what remains and continue until the checklist is exhausted. The large-output protocol governs the split. Done when every piece stands complete and the remainder is named.

4. Scan for banned shortcuts. Search the artifact for the omission markers: ... inside code standing for skipped lines, the phrases "rest of the code" / "fill in" / "similar to above" / "repeat for", and any function body that is a stub where the request asked for an implementation. Done when no ellipsis-omission and no shortcut phrase remains.

5. Count delivered against requested. Compare the delivered-item count to the checklist from step 1: a request for N items is met by N delivered items, with the tedious ones included. Scope that shrank between request and delivery is the finding. Done when delivered count equals requested count.

6. Verify claimed done equals observed done. Confirm each item said to be finished is finished in the artifact itself; claimed completion without an observable body is the failure named in verification-before-completion. A stub, a pass-body marker, or a "left as an exercise" is not done. Done when every completion claim is backed by a full body in the deliverable.

7. Report against the three criteria. State the verdict on each: no ellipsis-omission remains, every requested item is present, no stub is presented as done. A failed criterion blocks the hand-off and sends the deliverable back to step 2. Done when all three criteria read pass.