design-protocol 1.0.0

package/skills/dp-prd/SKILL.md

@@ -0,0 +1,201 @@
+---
+name: dp-prd
+description: >
+  Generate industry-standard PRDs for product managers and designers. Trigger when someone mentions
+  writing, creating, updating, or improving a PRD, product spec, requirements, or feature brief.
+  Also trigger for PM phrases: "document this feature", "write up a product spec", "create requirements
+  for X", "spec out a new feature". Also trigger for designer phrases: "document this component/screen/
+  flow/pattern", "spec out this interaction", "formalise this design", "write up requirements for this
+  design". Also trigger immediately when the user types /prd or /dp:prd — jump straight to
+  Phase 1 initiation. Supports new PRDs, updates to existing ones, stakeholder-ready output and
+  Claude Code-ready specs. Always use this skill — don't generate a PRD without it.
+---
+
+# PRD Generator Skill
+
+A guided, interview-driven skill for creating complete, industry-standard Product Requirements Documents.
+Supports new creation, updates to existing PRDs, multiple output formats, optional competitive research,
+and dual-audience output (stakeholder-ready or Claude Code-ready).
+
+---
+
+## Phase 1 — Initiation
+
+When the skill is triggered, run through the initiation checklist in a **single, conversational message**.
+Do NOT ask these one by one in separate turns. Group them naturally.
+
+### 1.1 Detect mode
+
+First, check whether the user is:
+- **Creating a new PRD** from scratch
+- **Updating an existing PRD** (they paste or upload an existing doc)
+
+If updating, ask them to share the existing PRD content before proceeding.
+Then identify which sections need adding, revising, or expanding, and only interview for those gaps.
+
+### 1.2 Initiation questions (ask all at once)
+
+Ask the following in one friendly, well-structured message:
+
+**A. User persona**
+Who are you?
+- Product Manager
+- Designer / UX Lead
+- Both / cross-functional team
+- Other (ask them to describe)
+
+This determines which interview questions are asked and how deep design considerations go.
+
+**B. Output format**
+What format do you need?
+- Word document (.docx) — for sharing with stakeholders
+- HTML artifact — rendered beautifully in Claude, shareable as link
+- Markdown — for Notion, Confluence, GitHub, or copy-paste
+- Claude Code–ready spec — structured for direct use as a Claude Code prompt/spec file
+
+Note: the user can request multiple formats. Generate all requested.
+
+**C. Primary audience**
+Who is this PRD primarily written for?
+- Executive / leadership stakeholders
+- Engineering team
+- Design team
+- Claude Code (AI-assisted implementation)
+- Mixed audience (ask them to specify)
+
+If **Claude Code** is selected (or is one of the audiences), enable the technical spec layer —
+see `references/claude-code-spec.md` for requirements.
+
+**D. Tone & voice**
+What tone should the document use?
+- Formal / enterprise
+- Startup / direct
+- Ask Claude to match the company's existing documentation style (they can paste an example)
+
+**E. Competitive research**
+Do you want competitive/market research included?
+- No research needed
+- Light scan (3–5 competitors, quick feature comparison)
+- Deep dive (positioning, pricing, differentiators, SWOT, market signals)
+
+If yes to either research option, Claude will run web searches before generating the PRD.
+
+**F. PRD type**
+What kind of PRD is this?
+- New product / v1
+- New feature on existing product
+- Improvement / iteration on existing feature
+- Discovery / exploratory (hypothesis-driven, less defined)
+
+---
+
+## Phase 2 — Interview
+
+Once initiation is complete, conduct a structured interview to gather content for each PRD section.
+Read `references/interview-questions.md` to get the full question bank.
+
+### Pre-generation mandatory checks
+
+Before proceeding to Phase 4 (draft generation), verify:
+
+**Check A — Component inventory (if Designer persona + Claude Code audience):**
+Has the user provided a component list with Figma names mapped to CSS token names?
+If not: pause and ask before generating. The spec will be unusable without it.
+
+**Check B — Sharing strategy (if any requirement involves sharing/exporting):**
+Has the user confirmed how sharing should work (public link / password / expiring / internal / none)?
+If not: ask before generating. Never assume a sharing approach.
+
+Both checks can be done in a single follow-up message if needed — don't make it feel like a blocker, just frame it as "two quick things before I generate."
+
+### Interview rules
+
+- Group questions by section cluster — don't ask section by section rigidly
+- Keep the tone conversational, not form-like
+- If user persona is **Designer**, go deeper on design considerations, component references, and accessibility
+- If user persona is **PM**, go deeper on goals, metrics, constraints, and stakeholder alignment
+- If audience is **Claude Code**, go deeper on acceptance criteria, technical constraints, API/component contracts
+- Always allow the user to say "skip this section" or "I don't know yet" — mark skipped sections as `[TBD — to be completed]`
+- After the interview, summarise what you've captured and ask for confirmation before generating
+
+### Interview clusters
+
+Run these clusters in order, but merge naturally if answers overlap:
+
+1. **Context cluster** — product name, owner, team, stakeholders, target date, PRD type
+2. **Problem cluster** — problem statement, why now, who's affected, evidence/data
+3. **User cluster** — target users, personas, JTBD, pain points, user research available
+4. **Goals cluster** — objectives, success metrics, KPIs/OKRs, SMART goals
+5. **Requirements cluster** — functional requirements, user stories, non-functional requirements
+6. **Design cluster** — UX considerations, Figma links, accessibility requirements, design principles, component references
+7. **Scope cluster** — what's in scope, what's explicitly out of scope, MoSCoW prioritisation if needed
+8. **Risk cluster** — assumptions, constraints, dependencies, known risks, open questions
+9. **Release cluster** — release criteria, rollout plan, phasing, comms plan
+
+---
+
+## Phase 3 — Research (if opted in)
+
+If the user requested competitive or market research in initiation:
+
+1. Use `web_search` to find competitors, similar products, and market signals
+2. Search for: `[product category] competitors 2025`, `[feature name] industry benchmark`, `[product name] vs [competitor]`
+3. Compile findings into a **Competitive Landscape** section with:
+   - Competitor table (name, key features, positioning, pricing if available)
+   - Feature gap analysis (what competitors do that this PRD does or doesn't address)
+   - Market signals (trends, customer expectations, industry direction)
+   - SWOT summary (if deep dive was selected)
+4. Insert this section after the Problem Statement in the final PRD
+
+---
+
+## Phase 4 — Draft Generation
+
+Generate the full PRD based on interview answers and research.
+Read `references/section-templates.md` for the exact structure and formatting of each section.
+
+### Format rules
+
+**For .docx output:** Read `/mnt/skills/public/docx/SKILL.md` before generating.
+**For HTML artifact:** Produce a beautifully formatted, self-contained HTML page with a sidebar TOC, clean typography, and section anchors.
+**For Markdown:** Use clean heading hierarchy (H1 title, H2 sections, H3 subsections). Compatible with Notion, Confluence, and GitHub.
+**For Claude Code spec:** Read `references/claude-code-spec.md` and produce the structured spec variant. This is a separate file/section, not a replacement for the full PRD.
+
+### Quality checklist before outputting
+
+Before finalising the draft, verify:
+- [ ] Every section has content or is explicitly marked `[TBD]`
+- [ ] Success metrics are measurable (not vague like "improve user experience")
+- [ ] Functional requirements are written as user-facing outcomes, not implementation details
+- [ ] If Claude Code audience: acceptance criteria are present and testable
+- [ ] Scope section explicitly lists at least 2–3 out-of-scope items
+- [ ] At least one open question is captured
+- [ ] Tone matches the user's choice from initiation
+
+---
+
+## Phase 5 — Refinement Loop
+
+After generating the draft, explicitly invite the user to refine it.
+
+Say something like:
+> "Here's your PRD draft. You can ask me to:
+> - **Expand** any section with more detail
+> - **Rewrite** a section in a different tone or structure
+> - **Add** a section that's missing
+> - **Convert** to a different format (e.g. 'give me the Claude Code spec version')
+> - **Update** with new information you have
+> - **Run research** on a specific competitor or feature area
+> - **Score** requirements using RICE or MoSCoW prioritisation"
+
+Support all of these refinement actions without restarting the full interview.
+
+---
+
+## Reference files
+
+Read these when needed — do not load all at once:
+
+- `references/interview-questions.md` — Full question bank per section, per persona
+- `references/section-templates.md` — Exact structure and formatting for each PRD section
+- `references/claude-code-spec.md` — Instructions for generating the Claude Code–ready spec variant

package/skills/dp-prd/references/claude-code-spec.md

@@ -0,0 +1,107 @@
+# Claude Code–Ready Spec Format
+
+When the user selects "Claude Code" as a primary audience, generate a **separate structured spec file**
+alongside (or instead of) the full stakeholder PRD. This spec is designed to be used as a prompt
+or context file fed directly into Claude Code.
+
+---
+
+## What makes a spec Claude Code–ready
+
+Claude Code works best when given:
+1. **Precise functional scope** — what to build, not how to build it
+2. **Acceptance criteria** — testable conditions in Given/When/Then format
+3. **Component/API contracts** — what exists, what needs to be created
+4. **Design system references** — exact token names, component names, Figma links
+5. **Technical constraints** — stack, libraries, patterns to follow
+6. **File/folder structure hints** — where new code should live
+7. **Example inputs/outputs** — concrete examples reduce ambiguity
+
+---
+
+## Claude Code Spec Template
+
+```markdown
+# [Feature Name] — Implementation Spec
+Generated from PRD v[X.X] | [Date]
+
+## Overview
+[2–3 sentences: what to build and why. Keep it tight.]
+
+## Stack & Constraints
+- Framework: Next.js (latest stable)
+- Styling: Tailwind CSS + CSS custom properties (design tokens)
+- Design system: Custom designOS — tokens follow `--[component]-[variant]-[modifier]` convention (e.g. `--button-primary`, `--color-brand-500`)
+- State management: [confirm per feature — React Context / Zustand]
+- Key libraries already in use: [list any additional]
+- DO NOT use: inline styles, hardcoded colour values, non-token references
+
+## Design References
+- Figma file: [URL — paste from Figma]
+- Component names to use: [exact Figma component names — ask designer to list]
+- Token references: CSS custom properties e.g. `--button-primary`, `--color-surface`, `--spacing-md`
+- Responsive breakpoints: Tailwind defaults unless overridden in config
+
+## Features to Implement
+
+### Feature 1: [Name]
+**Description:** [What this feature does]
+**Location:** [File path or component to create/modify]
+
+**Acceptance Criteria:**
+- Given [user is on X screen], when [they do Y], then [Z happens]
+- Given [edge case], when [action], then [expected behaviour]
+- Given [error state], when [it occurs], then [error is handled by...]
+
+**Inputs:** [Props, API params, user inputs]
+**Outputs:** [Return values, UI changes, side effects]
+**API / Data:** [Endpoint, payload shape, response shape]
+
+### Feature 2: [Name]
+[Same structure]
+
+## Components to Create
+
+| Component Name | File Path | Props | Notes |
+|----------------|-----------|-------|-------|
+| [Name] | [path] | [prop: type] | |
+
+## API Contracts
+
+### [Endpoint name]
+- Method: [GET / POST / PUT / DELETE]
+- Path: [/api/...]
+- Request body: [shape]
+- Response: [shape]
+- Error states: [400, 401, 404, 500 — expected handling]
+
+## State Shape (if applicable)
+```typescript
+interface [FeatureName]State {
+  [field]: [type];
+}
+```
+
+## Test Cases to Write
+- Unit: [what to unit test]
+- Integration: [what integration scenarios to cover]
+- E2E: [what user flows to test end-to-end]
+
+## Out of Scope for This Implementation
+[Explicit list — prevents Claude Code from over-building]
+
+## Open Technical Questions
+[Anything unresolved that the developer or Claude Code should flag before proceeding]
+```
+
+---
+
+## Instructions for Claude when generating this spec
+
+1. **Be explicit about file paths** — Claude Code works better with concrete locations
+2. **Use TypeScript types** if the codebase uses TypeScript
+3. **Reference exact component/token names** from the design system — don't describe visually
+4. **Write acceptance criteria in Given/When/Then** — this maps to test generation
+5. **Include error states and edge cases** explicitly — they're often missed in PRDs
+6. **Mark genuinely unknown things as `[TBD — ask before implementing]`** rather than guessing
+7. **Keep the spec focused** — include only what Claude Code needs, not stakeholder context

package/skills/dp-prd/references/interview-questions.md

@@ -0,0 +1,158 @@
+# PRD Interview Question Bank
+
+This file contains the full question bank, organised by section cluster and user persona.
+Claude should select questions contextually — not ask every question — and adapt based on answers given.
+
+---
+
+## Cluster 1 — Context
+
+Ask everyone:
+- What is the name of the product or feature you're building?
+- Who is the PM / owner of this PRD?
+- Who are the key stakeholders who need to sign off?
+- What is the target release date or timeline?
+- Is this a new product, new feature, improvement, or discovery?
+- Are there any related PRDs, specs, or documents I should be aware of?
+
+---
+
+## Cluster 2 — Problem Statement
+
+Core questions (everyone):
+- What problem are you solving? Describe it in 2–3 sentences.
+- Who is experiencing this problem?
+- What evidence do you have that this is a real problem? (data, research, complaints, metrics)
+- Why is this problem worth solving now?
+- What happens if you don't solve it?
+
+Deeper for PM persona:
+- What is the business cost of this problem today?
+- Is this problem growing, stable, or declining in frequency?
+- Have you tried to solve this before? What happened?
+
+---
+
+## Cluster 3 — Target Users & Personas
+
+Core questions (everyone):
+- Who are the primary users of this product/feature?
+- Can you describe 1–2 key personas? (role, goal, pain point)
+- What is the user trying to accomplish? (job-to-be-done)
+- What does success look like from the user's perspective?
+- Do you have any existing user research, interviews, or data to reference?
+
+Deeper for Designer persona:
+- Are there different user skill levels to account for? (novice vs power user)
+- Are there accessibility requirements for specific user groups?
+- What devices or contexts will users be in when using this?
+- Are there any emotional states or stress scenarios to design for?
+
+---
+
+## Cluster 4 — Goals & Success Metrics
+
+Core questions (everyone):
+- What are the top 2–3 goals for this initiative?
+- How will you know if this is successful? What does "done well" look like?
+- What metrics will you track? (e.g. conversion rate, task completion time, NPS, retention)
+- Do you have OKRs or KPIs this initiative is tied to?
+- What does failure look like, and what's the threshold that would cause you to pivot?
+
+For PM persona:
+- Are there business metrics (revenue, cost, efficiency) this needs to move?
+- What is the target improvement you're aiming for, and over what timeframe?
+- How will you measure the metric before and after? Do you have a baseline?
+
+---
+
+## Cluster 5 — Functional Requirements
+
+Core questions (everyone):
+- What are the core features or capabilities this product/feature must have?
+- Walk me through how a user would interact with this feature from start to finish.
+- What are the must-have requirements vs. nice-to-haves?
+- Are there any specific user actions, workflows, or states the feature needs to support?
+- Are there edge cases or error states you need to handle?
+
+For Claude Code audience (technical spec layer):
+- What are the acceptance criteria for each requirement? (Given/When/Then format preferred)
+- What APIs, services, or data sources does this need to integrate with?
+- Are there specific components, libraries, or design system elements to use?
+- What are the input/output contracts for key interactions?
+- Are there state management or data persistence requirements?
+- What error handling behaviour is expected?
+- **Sharing & collaboration:** If this feature involves sharing content or outputs with other users, how should sharing work? Choose one:
+  - Public link (anyone with the link can view — no auth required)
+  - Password-protected link
+  - Expiring link (define TTL: 24h / 7 days / 30 days)
+  - Internal only (requires login to the same account/org)
+  - No sharing needed
+  
+  Note for Claude: Never default silently to a sharing approach. If sharing is part of any requirement, this question is mandatory before spec generation.
+
+---
+
+## Cluster 6 — Non-Functional Requirements
+
+Core questions (everyone):
+- Are there performance requirements? (load time, response time, throughput)
+- Are there accessibility standards to meet? (WCAG 2.1 AA, APCA, etc.)
+- Are there security or privacy requirements? (auth, data handling, compliance)
+- Are there scalability requirements? (user volume, data volume)
+- Are there browser/device/OS compatibility requirements?
+- Are there internationalisation or localisation requirements?
+
+---
+
+## Cluster 7 — Design Considerations
+
+Ask if user persona is Designer or Mixed:
+- Do you have Figma files, prototypes, or mockups to reference? (paste links)
+- What design system or component library should be used?
+- Are there specific design principles or brand guidelines to follow?
+- Are there interaction patterns or animations to consider?
+- What are the key screens or flows that need to be designed?
+- Are there existing patterns in the product this should align with or intentionally diverge from?
+- Are there responsive/adaptive design requirements?
+
+Ask if audience includes Claude Code:
+- **Component inventory (required):** Please list every component from your design system that this feature will use. For each, provide the exact Figma component name and its CSS custom property token (e.g. `Button/Primary` → `--button-primary`, `Card/Surface` → `--color-surface`). Claude will use these exact names in the spec — no placeholders.
+- Are there any net-new components that don't exist in the design system yet and need to be created for this feature?
+- Are there specific Tailwind utility classes that pair with these components?
+- Is there a design handoff format preference? (e.g. annotated Figma, Storybook, component spec)
+
+Note for Claude: If the user is a Designer persona and the audience includes Claude Code, this component inventory question is MANDATORY — do not proceed to draft generation without it. If the user skips it, remind them that without exact component names the spec will contain placeholders that Claude Code cannot act on.
+
+---
+
+## Cluster 8 — Scope
+
+Core questions (everyone):
+- What is explicitly in scope for this release?
+- What is explicitly out of scope? (be specific — this prevents scope creep)
+- Are there related features or improvements you're intentionally deferring?
+- Is there a phased delivery plan? What goes in v1 vs. later?
+- Do you want to apply MoSCoW prioritisation? (Must have / Should have / Could have / Won't have)
+
+---
+
+## Cluster 9 — Risks, Assumptions & Dependencies
+
+Core questions (everyone):
+- What assumptions are you making that could turn out to be wrong?
+- What are the biggest risks to delivering this successfully?
+- What are the dependencies? (other teams, APIs, infrastructure, legal, third-party services)
+- What are the known constraints? (budget, timeline, technical debt, compliance)
+- What open questions still need to be answered before or during development?
+
+---
+
+## Cluster 10 — Release & Rollout
+
+Core questions (everyone):
+- What are the release criteria? (what must be true before you ship?)
+- Do you plan a phased rollout? (beta, limited release, full launch)
+- Who needs to be notified or involved at launch? (comms, sales, support, legal)
+- Is there a rollback plan if something goes wrong?
+- Are there launch dependencies? (marketing, legal approval, partner readiness)

package/skills/dp-prd/references/section-templates.md

@@ -0,0 +1,231 @@
+# PRD Section Templates
+
+This file defines the structure and formatting for each section of the generated PRD.
+Use these as the canonical output format across all delivery formats (docx, HTML, markdown).
+
+---
+
+## Document Header
+
+```
+[Product/Feature Name] — Product Requirements Document
+Version: [1.0 / 2.0 / etc.]
+Status: [Draft / In Review / Approved]
+Owner: [Name, Role]
+Last Updated: [Date]
+Stakeholders: [Names and roles]
+```
+
+---
+
+## Section 1 — Overview
+
+Short executive summary (3–5 sentences max). Answer:
+- What is this?
+- Why are we building it?
+- Who is it for?
+- When is it expected to ship?
+
+---
+
+## Section 2 — Problem Statement
+
+**The Problem**
+[2–4 sentences describing the problem clearly]
+
+**Why Now**
+[Why is this the right time to solve it? Market signal, business pressure, user demand?]
+
+**Evidence**
+[Data, research, quotes, or signals that validate the problem exists]
+
+**Impact of Not Solving**
+[What happens if we don't address this?]
+
+---
+
+## Section 3 — Target Users & Personas
+
+For each persona, use this structure:
+
+**Persona Name** *(e.g. "The Enterprise Account Manager")*
+- Role: [job title / description]
+- Goal: [what they're trying to accomplish]
+- Pain Point: [what frustrates them today]
+- Job-to-be-done: [When I ______, I want to ______, so I can ______]
+
+---
+
+## Section 4 — Goals & Success Metrics
+
+**Objectives**
+[List 2–4 clear objectives this initiative must achieve]
+
+**Success Metrics**
+
+| Metric | Baseline | Target | Timeframe |
+|--------|----------|--------|-----------|
+| [metric name] | [current value] | [goal] | [when] |
+
+**Connected OKRs / KPIs**
+[Link to parent OKR or business KPI if applicable]
+
+**Definition of Failure**
+[What threshold would trigger a pivot or stop?]
+
+---
+
+## Section 5 — Functional Requirements
+
+For each requirement:
+
+**REQ-[N]: [Short Title]**
+- Description: [What the feature does, written from the user's perspective]
+- Priority: [Must Have / Should Have / Could Have / Won't Have]
+- User Story: As a [persona], I want to [action], so that [outcome]
+- Acceptance Criteria:
+  - Given [context], when [action], then [result]
+  - Given [context], when [action], then [result]
+- Notes: [edge cases, dependencies, open questions]
+
+---
+
+## Section 6 — Non-Functional Requirements
+
+**Performance**
+[Load time, response time, throughput targets]
+
+**Accessibility**
+[WCAG level, APCA targets, specific requirements]
+
+**Security & Privacy**
+[Auth requirements, data handling, compliance (GDPR, CCPA, etc.)]
+
+**Scalability**
+[User volume, data volume, concurrency]
+
+**Compatibility**
+[Browsers, devices, OS, screen sizes]
+
+**Localisation**
+[Languages, date/currency formats, RTL support if needed]
+
+---
+
+## Section 7 — Design Considerations
+
+**Design System / Component Library**
+[Name of design system, version, link to Figma]
+
+**Key Screens / Flows**
+[List of screens or flows that need design work, with Figma links where available]
+
+**Design Principles to Apply**
+[List 2–4 principles relevant to this feature]
+
+**Accessibility Requirements**
+[Specific design-level accessibility requirements: colour contrast ratios, focus states, touch targets, etc.]
+
+**Responsive Behaviour**
+[How the feature adapts across breakpoints]
+
+**Open Design Questions**
+[Unresolved design decisions that need exploration]
+
+---
+
+## Section 8 — Scope
+
+**In Scope**
+- [Item 1]
+- [Item 2]
+- [Item 3]
+
+**Out of Scope**
+- [Item 1 — and why if useful]
+- [Item 2]
+
+**Deferred to Later**
+- [Item 1 — target milestone/version]
+
+**MoSCoW Summary** *(if applicable)*
+
+| Must Have | Should Have | Could Have | Won't Have (this release) |
+|-----------|-------------|------------|--------------------------|
+| [req] | [req] | [req] | [req] |
+
+---
+
+## Section 9 — Competitive Landscape *(if research was requested)*
+
+**Overview**
+[2–3 sentence market context]
+
+**Competitor Comparison**
+
+| Competitor | Key Features | Positioning | Pricing | Notable Gap |
+|------------|-------------|-------------|---------|-------------|
+| [name] | [features] | [positioning] | [pricing] | [gap] |
+
+**Feature Gap Analysis**
+[What do competitors do that this PRD addresses? What do they do that we're not addressing?]
+
+**SWOT Summary** *(if deep dive was selected)*
+
+| Strengths | Weaknesses | Opportunities | Threats |
+|-----------|-----------|---------------|---------|
+| | | | |
+
+---
+
+## Section 10 — Risks, Assumptions & Dependencies
+
+**Assumptions**
+- [Assumption 1 — what would need to be true for this to succeed]
+
+**Known Risks**
+
+| Risk | Likelihood | Impact | Mitigation |
+|------|-----------|--------|------------|
+| [risk] | High/Med/Low | High/Med/Low | [mitigation] |
+
+**Dependencies**
+
+| Dependency | Owner | Status | Notes |
+|------------|-------|--------|-------|
+| [dep name] | [team/person] | [status] | |
+
+**Open Questions**
+
+| # | Question | Owner | Due |
+|---|----------|-------|-----|
+| 1 | [question] | [name] | [date] |
+
+---
+
+## Section 11 — Release Criteria & Rollout
+
+**Release Criteria**
+The following must be true before shipping:
+- [ ] [Criterion 1]
+- [ ] [Criterion 2]
+- [ ] [Criterion 3]
+
+**Rollout Plan**
+- Phase 1: [description, audience, timeline]
+- Phase 2: [description, audience, timeline]
+- Full release: [timeline]
+
+**Launch Dependencies**
+[Anything that must happen before or alongside launch: legal sign-off, marketing assets, support docs, etc.]
+
+**Rollback Plan**
+[How to revert if something goes wrong post-launch]
+
+---
+
+## Appendix — Revision History
+
+| Version | Date | Author | Changes |
+|---------|------|--------|---------|
+| 1.0 | [date] | [name] | Initial draft |