agentsclimarketplace

Devrites api interface

Skill ViktorsBaikers/DevRites/pack/.claude/skills/devrites-api-interface

Stop your AI from shipping half-baked code. A disciplined senior-engineer workflow for Claude Code (spec, vet, build, prove, review, seal, ship) that keeps each feature's state on disk, catches spec drift mid-build, gates every phase on your project's principles, and refuses to claim "done" without proof.

Install
npx -y skills add ViktorsBaikers/DevRites --skill devrites-api-interface

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Design stable API/interface contracts before implementation: REST/GraphQL endpoints, module boundaries, type contracts, FE/BE splits. Use when the user says "design the API" or a slice crosses a boundary. Not for helpers.

SKILL.md

3.8 KB, as published. Nobody here has run it

devrites-api-interface: contract before implementation

When a slice crosses a boundary (FE/BE, service/service, module/module) or exposes a public interface, define the contract first so both sides can proceed and the interface stays stable.

Define the contract first

  • Shape: request/response or function signature; field names, types, optionality, units. Follow the project's existing naming and conventions.
  • Status & errors: success codes, error codes, error body shape, validation messages. Errors are part of the contract, not an afterthought.
  • Semantics: idempotency, pagination, ordering, nullability, side effects.
  • Versioning/compat: is this new or a change to an existing contract? A breaking change to an existing consumer is a user decision (and a drift event if unplanned).

Stability principles

  • Design for the caller. The interface should make the common case easy and the wrong call hard.
  • Prefer addition over modification. A new field is additive and optional; changing a field's type or removing one is a breaking change. You can add later. You can't un-ship a shape consumers already read (observable behavior is the contract: deprecation.md Hyrum's law).
  • One-Version Rule. Design as if only one version of this interface will ever exist: extend the single contract rather than fork a v2 you then maintain in parallel. Forking multiplies the surface and breeds diamond-dependency conflicts; bump a version only when an addition genuinely can't stay backward-compatible.
  • Match existing endpoints/modules in style: don't introduce a competing convention.
  • Validate at the boundary, and only there (untrusted → trusted); don't trust caller-supplied trust signals (IDs, roles). Validation does not belong between two internal typed functions, on your own database's data, or in a utility already called by validated code. A check inside the trusted core hides the bug in the boundary that should have caught it. A third-party API response is external input: always untrusted. (Three-tier boundary: security.md; see rite-review/reference/security-review.md.)

Type craft: make the wrong call unrepresentable

  • Brand your ids. A bare string/number id is assignable to any other id, so the compiler won't stop you passing a userId where a taskId is due. Give each a nominal brand (type TaskId = string & { readonly __brand: 'TaskId' }) and the mix-up becomes a type error, not a production incident.
  • Model variants as discriminated unions, each state carrying only its own fields, so an impossible combination can't be constructed in the first place.

Enables the split

A clear contract lets /rite-plan split proceed: the backend slice can land against the contract with a stub consumer; the frontend slice can build against a mock or the real contract. Neither side blocks on the other.

Doubt the contract

Before standing the interface, run devrites-doubt: boundary decisions are exactly the non-trivial kind worth an adversarial check.

Done when

The contract is complete only when every field carries a type + optionality + unit, every success and error status code is enumerated with its error-body shape, the devrites-doubt verdict is accept, and the contract + rationale are recorded in decisions.md. A contract that pins only the happy-path shape is not done.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.