القائمة
Turns the current conversation context into a PRD and publishes it as a GitHub issue (or a markdown file). Use when the user wants to create a PRD from the current context.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Query or contribute to syv.ai's shared company brain — the private 1brain GitHub repo (kunder, tilbud, teknik, strategi, wiki) — from any session, regardless of the current directory. Bootstraps a local clone when needed. Use when the user asks what syv.ai knows about a client or topic ("hvad ved vi om Krifa?", "har vi løst noget lignende før?"), wants something added to the brain ("tilføj til hjernen", mødenoter, læringer, nye dokumenter), or mentions 1brain or hjernen. All brain content is in Danish.
Write a syv.ai client proposal (tilbud, forslag, offer, PoC-beskrivelse, bud på udbud) in the company's fixed format and style, and render it as a branded PDF. Works from any session — bootstraps the private 1brain repo where the full proposal skill, templates and Typst PDF pipeline live. Trigger on opgavebeskrivelser, kravspecifikationer, SKI-udbud, RFPs and "lav et tilbud til …", also when the word "tilbud" isn't used directly.
Interviews the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when the user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Zooms out to give broader context or a higher-level perspective on a section of code. Use when you're unfamiliar with an area of code or need to understand how it fits into the bigger picture.
How to add or restyle a D3 diagram in the playbook docs (MkDocs Material). Use for any flowchart, diagram, chart, or graphic in docs/.
Use when a plan is multi-file, architecture-heavy, data-heavy, UI-heavy, ambiguous, or risky enough that the wrong direction would be expensive to undo. Renders the plan as a single self-contained HTML review surface — diagrams, file maps, annotated code, open questions — opened in the browser, with decisions captured in the terminal.
| name | to-prd |
| description | Turns the current conversation context into a PRD and publishes it as a GitHub issue (or a markdown file). Use when the user wants to create a PRD from the current context. |
This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.
By default, the project tracks issues on GitHub via the gh CLI. Publish the PRD as a new GitHub issue.
Fallback: if gh is not available, or the repo has no GitHub remote, write the PRD as a markdown file under docs/prd/<slug>.md instead (where <slug> is a short kebab-case name for the feature). Tell the user where you wrote it.
If the project has a CONTEXT.md, glossary, or similar, use its vocabulary throughout the PRD.
Explore the repo to understand the current state of the codebase, if you haven't already. Respect any ADRs in the area you're touching.
Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can.
Check with the user that these seams match their expectations.
Write the PRD using the template below, then publish it: create a GitHub issue with gh issue create (use the PRD as the issue body), or, in the fallback case, write it to docs/prd/<slug>.md. No triage labels are required — just create the issue/file.
The problem that the user is facing, from the user's perspective.
The solution to the problem, from the user's perspective.
A LONG, numbered list of user stories. Each user story should be in the format of:
This list of user stories should be extremely extensive and cover all aspects of the feature.
A list of implementation decisions that were made. This can include:
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
A list of testing decisions that were made. Include:
A description of the things that are out of scope for this PRD.
Any further notes about the feature.
