To prd
Strata — a self-measuring skills framework for Claude Code & Codex: best-of-breed engineering skills stacked by altitude, where every skill has to prove it moves a measured number.
npx -y skills add Yco-0314/strata --skill to-prdAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 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
Turn the current conversation into a PRD and publish it to the project issue tracker — synthesis of what you've already discussed, not a fresh interview.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.7 KB, as published. Nobody here has run it
To PRD — L2 (user-invoked)
Take the current conversation and codebase understanding and produce a PRD. Do not
re-interview the user — synthesize what you already know. If there is a genuine gap that
changes the shape of the feature, invoke the grilling primitive to close just that gap,
then continue.
Issue tracker
Default: local markdown under .scratch/<feature>/. Write the PRD to
.scratch/<feature>/prd.md. (GitHub Issues / Linear are configurable later via a setup
skill; this default needs no configuration and matches the repo convention.)
Process
- Explore the repo to understand the current state if you haven't. Use the project's
CONTEXT.mdglossary vocabulary throughout, and respect any ADRs indocs/adr/for the area you're touching. - Sketch the seams where the feature will be tested. Prefer existing seams; use the highest seam possible; the fewer new seams the better (ideal: one). Check the seams match the user's expectations before writing.
- Write the PRD with the template below, then publish it to the tracker and mark it
ready-for-agent(no further triage needed).
L0 ponytail applies: keep the PRD lean. A long user-story list is fine; speculative
scope is not. Cut anything you'd flag as YAGNI in code.
Problem Statement
The problem the user faces, from the user's perspective.
Solution
The solution, from the user's perspective.
User Stories
A long, numbered list, each: As an <actor>, I want a <feature>, so that <benefit>.
Cover all aspects of the feature.
Implementation Decisions
Modules built/modified, their interfaces, technical clarifications, architectural decisions, schema changes, API contracts, specific interactions. No file paths or code snippets (they go stale) — exception: a prototype-derived snippet that encodes a decision more precisely than prose (state machine, reducer, schema, type shape); inline only the decision-rich part and note it came from a prototype.
Testing Decisions
What makes a good test (test external behavior, not implementation details), which modules are tested, and prior art for those tests in the codebase.
Out of Scope
What is deliberately excluded.
Further Notes
Anything else.
</prd-template>Hand off to to-issues to slice the PRD into grabbable work.