Close The Loop

Close the Loop

Purpose

Use this skill when a feature has already gone through multiple implementation and review cycles and the work is starting to loop.

The objective is to close the implementation cycle without turning every review observation into additional scope.

This skill should:

1. reconstruct the agreed feature contract;
2. identify remaining genuine defects;
3. fix only issues required by that contract;
4. avoid nice-to-haves and speculative improvements;
5. run relevant validation;
6. perform one final read-only acceptance review;
7. give a clear final go/no-go decision.

When to use

Use this skill when the user asks things such as:

• "close the loop"
• "finish this feature"
• "one more review"
• "fix the remaining issues and tell me if we're done"
• "Codex is going in circles"
• "stop finding new nice-to-haves"
• "fix only the real remaining bugs"
• "are we ready to merge?"
• "perform a final acceptance review"

It is especially relevant when multiple previous review/fix iterations have already happened.

Do not use this workflow for the first implementation or first substantive design review of a feature.

Core principle

Judge the implementation against the agreed requirements, not against every possible improvement.

A better, more scalable, more observable, more defensive, or cleaner implementation being possible does not make the current implementation defective.

It is valid and preferred to conclude that no defects remain.

Do not manufacture findings merely because a review was requested.

Step 1 — Reconstruct the agreed contract

Review the current conversation, requested feature, previous design decisions, accepted trade-offs, existing code, and relevant documentation.

Create a concise acceptance contract from:

• functionality explicitly requested by the user;
• design decisions explicitly agreed with the user;
• bugs/findings the user explicitly requested to fix;
• existing behavior that must remain intact;
• documented API/runtime contracts affected by the feature.

Do not silently introduce new requirements.

Do not reopen previously accepted decisions just because another design is possible.

Step 2 — Triage remaining findings

Classify each remaining finding as:

Must fix

A concrete violation of:

• the agreed feature design;
• explicit requested behavior;
• an existing relied-upon contract;
• security;
• data integrity;
• correctness;
• lifecycle/resource accounting;
• deployment/startup behavior;
• or another clear production invariant.

Non-blocking defect

A real correctness issue that does not prevent the feature from being safely shipped.

Hardening

A useful defensive or robustness improvement without a current contract violation.

Nice-to-have

Examples:

• additional metadata;
• more logging or observability;
• cleaner abstractions;
• extra configuration;
• broader use-case support;
• speculative edge-case protection;
• unrelated performance optimization;
• stylistic consistency;
• architectural improvements with no concrete current failure.

Future work / accepted limitation

A deliberate trade-off or capability outside the agreed feature scope.

Defect test

Before classifying anything as a defect, answer:

1. What exact agreed requirement or invariant does this violate?
2. What concrete production failure can result?
3. Is the issue caused by or materially affected by the current feature?

If questions 1 and 2 cannot be answered clearly, do not classify it as a defect.

Put it under Hardening, Nice-to-have, or Future work instead.

Step 3 — Fix only required issues

Implement only Must fix findings.

A very small adjacent non-blocking defect may be fixed if it is directly caused by the same change and fixing it clearly reduces risk.

Do not:

• redesign working components;
• refactor unrelated code;
• broaden feature scope;
• add unrelated capabilities;
• implement speculative hardening;
• implement backlog items;
• reopen accepted design decisions.

Prefer the smallest robust change consistent with the existing architecture and project conventions.

Preserve existing comments.

Preserve existing successful public behavior unless the agreed contract explicitly changes it.

Step 4 — Add regression coverage

For every Must fix issue:

• identify the concrete failure scenario;
• add or update a test that would have failed before the fix;
• verify the intended behavior after the fix.

Avoid speculative test expansion unrelated to the fixes.