RIPR-PROP-NNNN: Title

May 20, 2026 ยท View on GitHub

Status: proposed

Owner:

Created: YYYY-MM-DD

Target campaign:

Linked specs:

Linked ADRs:

Linked work items:

Support-tier impact:

Policy impact:

Problem

What repo-level or product-level problem are we solving? Frame it in terms of the user, integration, or maintainer pain that motivates the change.

Users and surfaces

Who benefits, and which surfaces does this touch?

  • CLI
  • LSP / editor extension
  • generated GitHub CI
  • reviewers
  • coding agents (Codex, Kiro, Claude Code, Cursor, generic)
  • maintainers

Success criteria

What must be true when this is done? Express each criterion so a reviewer can decide pass or fail without re-reading the prose.

Proposed shape

What is the recommended design? Keep this short; the behavior contract belongs in the linked specs, not here.

Alternatives considered

What did we evaluate and reject, and why? Note anything that should not be re-litigated later without new evidence.

Behavior specs to create or update

  • RIPR-SPEC-NNNN

Architecture decisions needed

  • ADR needed? yes / no

Implementation campaign shape

What are the PR-sized slices? Each slice should follow the scoped PR contract.

  1. scope/slice-name

Evidence plan

What fixtures, tests, goldens, metrics, docs, receipts, and output contracts are required?

Risks

What can go wrong? Include rollout risk, schema-fork risk, scope creep, and adoption risk.

Non-goals

What is explicitly out of scope for this proposal? Linked specs may further narrow non-goals for individual behaviors.

Exit criteria

When can this proposal be closed, accepted, or superseded? Name the artifacts that prove the work landed.