to-prd

Stars9

Forks0

UpdatedJune 23, 2026 at 14:59

Synthesize the current conversation into a PRD saved under docs/. Use after discussing a feature or change with the agent — no interview, just capture what has already been decided, surface open questions, and write the document. Trigger when the user says "write a PRD", "document this", "save this as a spec", or after a design discussion that needs to be captured before implementation starts.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

thejoaov

thejoaov/tray-link

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Project Management SpecialistsBusiness and Financial Operations Occupations·SOC 13-1082

SKILL.md

readonly

name	to-prd
description	Synthesize the current conversation into a PRD saved under docs/. Use after discussing a feature or change with the agent — no interview, just capture what has already been decided, surface open questions, and write the document. Trigger when the user says "write a PRD", "document this", "save this as a spec", or after a design discussion that needs to be captured before implementation starts.

This skill synthesizes what has already been discussed into a PRD. Do NOT interview the user — capture and structure what you already know from the conversation and codebase.

Process

Explore the codebase to understand the current state of the areas touched by this feature, if you haven't already. Note the existing modules, boundaries, and naming conventions — use them throughout the document.
Identify the seams — the points in the codebase where this feature will connect to existing code. Prefer existing seams to new ones. The fewer seams, the better; the ideal is one. State which packages and layers are involved (packages/api, packages/db, apps/web, etc.).
Write the PRD using the template below. Save it to docs/[feature-name]/prd.md. Create the directory if it doesn't exist.
Surface open questions at the end of the document — anything unresolved, ambiguous, or requiring a product decision. Do not block writing the PRD on these; surface them so the user can address them separately.

Template

---
created_at: "YYYY-MM-DD HH:MM:SS"
last_modified_at: "YYYY-MM-DD HH:MM:SS"
---

# PRD — [Feature Name]

## Problem Statement

What problem does this solve? Describe it from the user's perspective, not the implementation's.

## Solution

What will be built? Describe it from the user's perspective.

## User Stories

A numbered list covering all aspects of the feature. Be exhaustive.

1. As a [actor], I want [capability], so that [benefit].
2. ...

## Implementation Decisions

The modules and boundaries involved. Do not include file paths or code snippets unless a specific shape (schema, type, state machine) was already decided in the conversation — if so, include only the decision-relevant parts.

- **Packages touched:** `packages/api`, `packages/db`, etc.
- **New procedures / endpoints:** ...
- **Schema changes:** ...
- **Auth / permission requirements:** ...
- **Architectural decisions already made:** ...

## Testing Decisions

- Which behavior will be tested (external-facing, not implementation details)
- Which modules will have tests
- Prior art in the codebase for similar tests

## Out of Scope

What is explicitly not included in this PRD.

## Open Questions

- [Question requiring product or technical decision]
- ...

## Rectifications

- [No rectifications yet]

Rules

Save location: always docs/[feature-name]/prd.md. Create docs/ at the project root if it doesn't exist.
Frontmatter HELMET: always include created_at and last_modified_at timestamps.
Non-destructive updates: if the PRD already exists and you are updating it, never delete old requirements. Wrap deprecated text in slashes (e.g. /old text/) and append to the ## Rectifications section with a date and rationale.
Domain vocabulary: use the project's existing naming conventions — package names, entity names, service names. Do not invent new terms.
No time estimates: do not include story points, hours, or deadlines.

More from this repository

same repository

ai-release-notes

thejoaov/tray-link

Use when setting up or improving a GitHub Actions release workflow that generates release notes automatically using an LLM. Covers resolving the git tag range between releases, collecting commits, calling the Gemini API to group and summarize changes, stripping markdown fencing artifacts, and falling back to a plain commit list when no API key is available. Trigger when the user asks about automated release notes, AI changelog generation, or GitHub Actions release workflow.

2026-06-239

draft-first-approval

thejoaov/tray-link

Use when implementing any agent action that has an irreversible or externally visible side effect — sending a message, email, or notification; posting to a public channel; making a payment; deploying to production; deleting data; or calling a third-party API that cannot be undone. The agent must always draft and present the action for explicit user approval before executing it. Trigger when the user asks the agent to send, post, deploy, delete, or perform any action whose side effects cannot be rolled back.

2026-06-239

electron-tray-app

thejoaov/tray-link

Use when building or extending an Electron system tray application. Covers tray window creation, smart window positioning relative to the tray icon (top/bottom/left/right detection, multi-monitor, Linux fallback), macOS Dock hiding, always-on-top pop-up window behavior, blur-to-hide with cursor-in-tray guard, right-click context menu, and IPC handles for programmatic show/hide. Trigger when the user asks about Electron tray, menu bar app, system tray window, popover window positioning, or macOS menu bar app.

2026-06-239

feature-management

thejoaov/tray-link

Full lifecycle for planning and documenting a new feature. Use when starting a new feature, writing a PRD from scratch with an interview, creating a technical spike for unknowns, or generating an implementation task checklist. Covers the spike → PRD → tasks workflow with versioned, non-destructive documents under docs/[feature-name]/. Trigger when the user says "plan a feature", "let's start a new feature", "write a spike", "create tasks for this", or when entering Plan mode.

2026-06-239

monorepo-architecture

thejoaov/tray-link

Use when setting up, organizing, or reasoning about a TypeScript monorepo. Covers workspace managers (Bun, pnpm), Turborepo pipelines and caching, package boundary conventions (apps/packages/tooling tiers), dependency management with catalogs and version pinning, shared tooling packages, and cross-workspace build orchestration. Trigger when the user asks about monorepo structure, where to add a new package, how to configure Turborepo tasks, or how to manage shared dependencies.

2026-06-239

name	to-prd
description	Synthesize the current conversation into a PRD saved under docs/. Use after discussing a feature or change with the agent — no interview, just capture what has already been decided, surface open questions, and write the document. Trigger when the user says "write a PRD", "document this", "save this as a spec", or after a design discussion that needs to be captured before implementation starts.

This skill synthesizes what has already been discussed into a PRD. Do NOT interview the user — capture and structure what you already know from the conversation and codebase.

Process

Explore the codebase to understand the current state of the areas touched by this feature, if you haven't already. Note the existing modules, boundaries, and naming conventions — use them throughout the document.
Identify the seams — the points in the codebase where this feature will connect to existing code. Prefer existing seams to new ones. The fewer seams, the better; the ideal is one. State which packages and layers are involved (packages/api, packages/db, apps/web, etc.).
Write the PRD using the template below. Save it to docs/[feature-name]/prd.md. Create the directory if it doesn't exist.
Surface open questions at the end of the document — anything unresolved, ambiguous, or requiring a product decision. Do not block writing the PRD on these; surface them so the user can address them separately.

Template

---
created_at: "YYYY-MM-DD HH:MM:SS"
last_modified_at: "YYYY-MM-DD HH:MM:SS"
---

# PRD — [Feature Name]

## Problem Statement

What problem does this solve? Describe it from the user's perspective, not the implementation's.

## Solution

What will be built? Describe it from the user's perspective.

## User Stories

A numbered list covering all aspects of the feature. Be exhaustive.

1. As a [actor], I want [capability], so that [benefit].
2. ...

## Implementation Decisions

The modules and boundaries involved. Do not include file paths or code snippets unless a specific shape (schema, type, state machine) was already decided in the conversation — if so, include only the decision-relevant parts.

- **Packages touched:** `packages/api`, `packages/db`, etc.
- **New procedures / endpoints:** ...
- **Schema changes:** ...
- **Auth / permission requirements:** ...
- **Architectural decisions already made:** ...

## Testing Decisions

- Which behavior will be tested (external-facing, not implementation details)
- Which modules will have tests
- Prior art in the codebase for similar tests

## Out of Scope

What is explicitly not included in this PRD.

## Open Questions

- [Question requiring product or technical decision]
- ...

## Rectifications

- [No rectifications yet]

Rules

Save location: always docs/[feature-name]/prd.md. Create docs/ at the project root if it doesn't exist.
Frontmatter HELMET: always include created_at and last_modified_at timestamps.
Non-destructive updates: if the PRD already exists and you are updating it, never delete old requirements. Wrap deprecated text in slashes (e.g. /old text/) and append to the ## Rectifications section with a date and rationale.
Domain vocabulary: use the project's existing naming conventions — package names, entity names, service names. Do not invent new terms.
No time estimates: do not include story points, hours, or deadlines.