develop

Files (3)

• REVIEW.md
• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Develop

## 1. Establish the scope

Read the request, its spec or tickets, and the documented standards the
review will hold the change to. Resolve ambiguities that would change
observable behavior. Stay on the current branch unless the user asks
otherwise; preserve unrelated changes and existing staging. Pin the review
base before editing and record pre-existing changes.

## 2. Implement

**Encode meaning and invariants in the model.** Use types, APIs, and
enforced constraints to express distinctions callers would otherwise need to
remember: units, identities, valid states, and permitted operations. Prefer
representations that prevent misuse over conventions, repeated checks, or
tests that merely detect it. Validate external inputs at the boundary.

**Shape the code for its production callers.** Choose the cleanest design
for the code that runs, then bring the tests to it. When that design breaks
an existing test that pins internal structure rather than a contract,
rewrite the test against the contract. Reach behavior and resolve
uncertainty through real runs and throwaway probes; add a seam only tests use
when nothing else can reach it, and name it in the report.

Continue until the requested behavior is implemented through the agreed
interfaces.

## 3. Establish correctness

Verify the change against real behavior with existing tests, a real run, or
throwaway tests and probes. Derive expected results from the requirements,
reviewed examples, or a trusted reference, rather than the implementation's
current output. Choose cases that distinguish plausible mistakes. Fix defects
the checks expose, record what each check showed, and delete the throwaway
code.

A new test encodes your reading of the requirements, the same reading the
implementation encodes. Retain one only when the user asks for a test.
Propose a test only where a regression would go unnoticed by types, existing
tests, or a quick real run, and an incidental edit, made while changing
nearby code for another reason, could bring it back. Propose every test that
meets this, each on its own line: the contract, the incidental edit that
would break it, and how you verified it now.

Continue until the relevant tests pass after the fixes; record pre-existing
failures separately.

## 4. Review and finish

Follow [FINAL-REVIEW.md](FINAL-REVIEW.md) for fresh reviews against the spec
and the documented standards. Keep the reviewed files unchanged while
reviewers work.

Assess each finding against its evidence. Fix confirmed issues and record why
others do not apply. Send fixes back to the affected reviewers, including the
other axis when a fix changes what it reviewed. Close findings on the final
state; a report about an earlier version is not final verification.

Run the repository's required checks on the final state. Leave the task's edits
uncommitted and unstaged unless the user asks otherwise. Report the changes,
including fixes beyond the request, what each check showed, each review's
outcome, test proposals, and any remaining limits. If a required check or a
review cannot complete, report that gap and leave the task open.

From lithammer/ai, MIT.

More from lithammer/ai