PRDs & Spec Writing
Writing a spec is mostly retrieval. Before you can write a sentence you have to remember what the customer said in that call, find the Slack thread where the auth approach got settled, dig out the constraint engineering raised in a comment, and check what the last PRD decided about edge cases. Two hours of that, and then the actual writing starts. It is the reason PRDs get written late, get written thin, or get skipped in favour of a ticket and a hope.
Skynet already holds that context. Discovery notes, tickets, past specs, and decisions from your channels sit in one memory, so the first draft arrives with the research folded in rather than waiting on you to go find it.
How it works
Teach it your format
Point the agent at a few PRDs your team likes. It picks up the structure and the level of detail you expect — your sections, your tone, not a generic template downloaded from somewhere.
Draft from real context
Describe the feature and the agent assembles the rest: the problem statement grounded in actual customer quotes, the goals tied to your OKRs, the constraints engineering already raised, the decisions already made elsewhere.
Mark the gaps honestly
Where the agent does not know something, it says so and asks rather than inventing a requirement. Open questions get listed at the top, which is where a spec’s real value usually is anyway.
Break it into stories
Once the spec settles, the agent turns it into user stories with acceptance criteria and can file them in your tracker for review. The spec and the tickets stop being two disconnected documents.
Build it from a prompt
You bring the idea and the judgment. It brings the retrieval and the typing.
The value is that specs get written at all — properly, with the research attached, while the idea is fresh. Your time goes into the decisions the document exists to record instead of into the archaeology needed before you can start recording them.