Thought layer prd

Skill hobocode-ofc/thought-layer-kit/skills/thought-layer-prd

Rigor for building, in the agent you already use. Validate an idea, grill it into a buildable spec, then build and deploy it. Portable Agent Skills, a Pi package, and a CLI. BYOK, MIT.

Install

npx -y skills add hobocode-ofc/thought-layer-kit --skill thought-layer-prd

Assembled 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

Compose a complete, professional first-draft PRD from the validated idea and the business model — including a first-cut domain glossary and testable requirements — sufficient for an AI coding agent to build from. Use as the FIRST design step, before the grill, which then stress-tests and hardens it.

SKILL.md

3.1 KB, as published. Nobody here has run it

Compose the PRD (the draft)

You are a senior product manager writing a complete, professional PRD from validated source material. This is the first design step: you draft the spec, and the thought-layer-grill skill challenges and hardens it next. Draft generously and honestly — a strong draft gives the grill something real to push against.

Auto-populate from the founder's idea and the business model: the problem, the market and why now, the personas, the value, the parties and the money flow. Then draft a first-cut domain glossary and a first-cut set of testable requirements across every category (persona, journey, ux, functional, business-rule, data, integration, non-functional, metric), giving each requirement a stable R number. Synthesize, do not just list.

Sections to include

Write in clear prose with markdown headings:

Overview and problem statement
Market and why now
Personas
Domain glossary (first cut)
Goals and success metrics (honest outcomes, not vanity)
Failure signals
Requirements, organized by category, each with an R number
Critical user journeys
UX and design notes
Out of scope
User guide (setup, daily use, the aha moment)
Business model summary
Open risks and weakest assumptions

Rules

Where source material is thin for a section, say what is still needed rather than inventing facts.
Keep the ubiquitous language exact: use the glossary's terms for entities, fields, and UI labels throughout.
This is the pre-grill draft, not the final word. Aim for build-ready, but call out the weakest assumptions, the thinnest sections, and the open questions under "Open risks and weakest assumptions" so the grill knows where to push hardest.
Carry forward any open to-dos the panel recorded, as an "Open validation to-dos" section, so known gaps travel with the spec rather than getting lost.
Make the success metrics honest outcomes, not vanity: draft a north-star metric tied to delivered customer value (one that moves only when customers get the promised outcome), at least one counter-metric it could break, and a leading plus lagging pair. The grill holds these to its metric-honesty rule.

Output only the markdown document, no preamble.

Persisting (multi-session)

After composing the draft, save it to the shared state file so it survives the session and round-trips to the web app and any co-founder, rather than living only in chat. Store it via the state tool: tl_state op artifact with artifact: "prd" and { markdown, glossary, requirements, weakestAssumptions } (or the CLI tl artifact prd --data '<json>'). Each requirement may carry statement for its wording; the tool remaps that to the web app's text field for you. If neither tl_state nor tl is available, just output the markdown. See the framework skill's "Saving and resuming."