RIPP v1.0 Specification

This page mirrors the SPEC.md from the repository.


RIPP v1.0 Specification

Regenerative Intent Prompting Protocol

Version: 1.0.0
Status: Stable
Date: 2025-12-13


Abstract

The Regenerative Intent Prompting Protocol (RIPP) is a structured format for capturing feature requirements, system design decisions, and implementation contracts in a machine-readable, human-reviewable format. RIPP packets serve as executable specifications that preserve original intent while enabling rapid iteration, automated validation, and safe production deployment.

For the complete specification, see the SPEC.md on GitHub.


Quick Reference

Required Metadata

ripp_version: '1.0'
packet_id: 'unique-feature-identifier'
title: 'Brief feature title'
created: '2025-12-13'
updated: '2025-12-13'
status: 'draft | approved | implemented | deprecated'
level: 1 | 2 | 3

Level 1 Sections (Minimum)

Level 2 Sections (Add to Level 1)

Level 3 Sections (Add to Level 2)


Core Concepts

What RIPP Is

RIPP is a specification format for documenting features, APIs, and system changes. A RIPP packet is a structured document that describes what a feature does, how it works, what can go wrong, and how to verify it.

What RIPP Is Not

Why RIPP Exists

Modern software development faces intent erosion: ideas conceived with clear purpose often degrade during implementation. RIPP solves this by making the feature specification the primary artifact.


File Naming Conventions

RIPP packet files must follow this convention:

<feature-identifier>.ripp.{yaml|json}

Examples:


Validation

All RIPP packets must validate against the JSON Schema:

ripp validate <file-or-directory>

Exit codes:

Schema location: schema/ripp-1.0.schema.json


Protocol Status

v1.0 Stable — The RIPP v1.0 specification is stable and ready for production use.


Design Principles

  1. Explicit over implicit: All requirements must be written down
  2. Reviewable before buildable: Specs are reviewed before code
  3. Machine-readable, human-first: Structure serves humans, not parsers
  4. Fail-safe defaults: Encourage secure and resilient patterns
  5. Progressive disclosure: Start simple, add rigor as needed

Full Specification

For the complete, detailed specification including all section requirements, validation rules, and normative references, see:

SPEC.md on GitHub →