Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →ontology-of-everything/concept-prd
Generates PRD files from a confirmed concept model only when the user explicitly invokes $concept-prd. / 仅在用户显式调用 $concept-prd 时转录概念 PRD。
Passed 21 of 23 test cases with the skill, and 7 of 23 without it.
and 20 more in the full report
14 fixed7 passed either way2 still failing0 broke1 errored
Tokens, turns and time describe resource use, not a dollar price.
One of 14 test cases the skill fixed. Same model, same prompt, with and without the skill.
$concept-prd We are performing our team's very first concept PRD transcription for a resource reservation system. Which specific reference file from the specification documentation suite should we inspect for guidance on initial concept transcription?
| Checked | Without skill | With skill |
|---|---|---|
| References references/example-reserving.md for initial transcription guidance. | Missed | Passed |
The instructions your model reads when the skill loads.
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.
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.
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.
Choose locations — Use the following layout. Stage centrally only until modules exist.
docs/prd/README.md
<module>/CONCEPT.md or docs/prd/concepts/<name>.md
<syncs>/SYNCS.md or docs/prd/SYNCS.md
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.
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
test cases passed, vs 7 / 23 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.