---
name: ontology-of-everything-concept-prd
description: "Transcribes a confirmed concept model into traceable PRD and colocated specification files only when the user explicitly invokes $concept-prd. Use to preserve purposes, behavior, synchronizations, assumptions, exclusions, open decisions, and acceptance provenance without redesigning the model."
license: "Apache-2.0"
metadata:
  decimalai-skill-id: "369a342b-0e5e-4ea3-915b-6078c66b8ca5"
  decimalai-version-id: "ee192c37-b2e9-489a-8b8a-49c74e88c179"
  decimalai-version: "3"
  decimalai-body-sha256: "618e87a9c66ab9d3911ebd9f5b3fcd3eb4b75e06f768fec320321f71075233ad"
  decimalai-name: "ontology-of-everything/concept-prd"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "documentation"
  decimalai-source: "https://app.decimal.ai/s/ontology-of-everything-concept-prd@3/SKILL.md"
---
# Concept PRD

Focus: how can a confirmed model be persisted without losing purpose, behavior, or acceptance
traceability? Run only on explicit `$concept-prd` invocation. Input includes concepts,
synchronizations, dependencies, exclusions, and open decisions. Route model gaps to `concept-design`
and code realization to `concept-implementation`.

## Transcription Principles

CONCEPT owns the confirmed concept contract, SYNCS the coordination, and the overall PRD global
relations. Keep one authoritative location per element. Preserve both arguments and assumptions:
contract → OP → concept purpose; selection/sync → application scenario → application purpose.
Derive acceptance with provenance; complete files cannot repair model gaps.

**Synchronization may restrict behavior, never extend the contract**: record application restrictions
in SYNCS/the overall PRD while preserving the concept's allowed behavior. Flag contract-violating
coordination as a model gap for design revision.

## Transcribe

1. **Verify input** — Read the confirmed model, requirement sources, and existing documents. Inspect
   code only for module locations and indexing facts. Never let implementation differences silently
   rewrite the model.
2. **Choose locations** — Use the following layout. Stage centrally only until modules exist.

   ```text
   docs/prd/README.md
   <module>/CONCEPT.md or docs/prd/concepts/<name>.md
   <syncs>/SYNCS.md or docs/prd/SYNCS.md
   ```

3. **Write the overall PRD** — Preserve application purpose, end-to-end scenarios and their
   concept/sync basis, misfits, concept index with purpose and links, synchronization graph, product
   dependencies and subsets, exclusions, and open decisions. Put cross-concept assumptions and
   arguments here.
4. **Write specifications and acceptance** — Read `references/spec-format.md` and
   `references/templates.md`. Preserve the four CONCEPT sections, concept-local assumptions, and
   purpose argument; put application context in notes. Transcribe app/include/sync into one SYNCS
   file grouped by entry point or rule responsibility with `// flow:`. Derive acceptance separately
   from concept OPs, application scenarios, and behavioral contracts, each with provenance. Mark
   missing application goals as open rather than constructing them from concept purposes.
5. **Update consistently** — Make minimal edits to existing documents, refresh indexes and derived
   diagrams, and preserve human-maintained content. Leave implementation-time migration and sync
   package splitting to `concept-implementation`.

Completion requires one authoritative location per model element; no lost definitions, relations,
assumptions, exclusions, or open decisions; independent CONCEPT sections; application instantiation
in SYNCS rather than legacy interactions/dependencies sections; acceptance linked to OP, application
scenario, or contract evidence; real sync declarations for every parameter, binding, and output;
preserved reachable failure behavior and empty-query semantics; and valid global links.

For the first transcription read `references/example-reserving.md`; for specification sources read
`references/sources.md`.