@drafthq/draft 3.6.0 → 3.7.1

package/core/templates/intake-questions.md

@@ -28,17 +28,20 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ## Phase 1: Initial Context
 
 ### Question 1.1: Existing Documentation
+>
 > Start here. Gather any existing context before diving in.
 
 **Ask:**
 > "Do you have existing documentation for this work? (PRD, RFC, design doc, Jira ticket, or any notes)"
 
 **If yes:**
+
 - Request the document or key excerpts
 - Ingest and extract: goals, requirements, constraints, open questions
 - Summarize: "I've extracted [X, Y, Z]. I notice [gap] isn't covered yet."
 
 **If no:**
+
 - Acknowledge: "No problem. Let's build this from scratch together."
 - Proceed to Phase 2
 
@@ -49,10 +52,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ## Phase 2: Problem Space
 
 ### Question 2.1: Problem Definition
+
 **Ask:**
 > "What problem are we solving?"
 
 **After response, contribute:**
+
 - Pattern recognition: "This sounds similar to [industry pattern]..."
 - Domain concepts: Reference Jobs-to-be-Done, DDD problem space if relevant
 - Clarifying probe: "When you say [X], do you mean [A] or [B]?"
@@ -62,10 +67,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 2.2: Urgency & Impact
+
 **Ask:**
 > "Why does this problem matter now? What happens if we don't solve it?"
 
 **After response, contribute:**
+
 - Validate urgency: Is this symptom or root cause?
 - Impact analysis: Who's affected? How severely?
 - Reference: 5 Whys technique if they're describing symptoms
@@ -75,10 +82,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 2.3: Users & Workarounds
+
 **Ask:**
 > "Who experiences this pain? How do they currently cope?"
 
 **After response, contribute:**
+
 - User segmentation: Are there different user types with different needs?
 - Workaround analysis: Current workarounds often reveal requirements
 - Prior art: "Similar products handle this by [X]..."
@@ -88,10 +97,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 2.4: Scope Boundary
+
 **Ask:**
 > "What's the scope boundary? Where does this problem end and adjacent problems begin?"
 
 **After response, contribute:**
+
 - Identify adjacent problems that should NOT be solved here
 - Reference: Bounded Context (DDD)
 - Flag scope creep risks: "I'd suggest explicitly excluding [X]..."
@@ -104,6 +115,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 
 **Summarize:**
 > "Here's what we've established about the problem:
+>
 > - Problem: [summary]
 > - Why now: [summary]
 > - Users: [summary]
@@ -118,10 +130,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ## Phase 3: Solution Space
 
 ### Question 3.1: Simplest Solution
+
 **Ask:**
 > "What's the simplest version that solves this problem?"
 
 **After response, contribute:**
+
 - MVP identification: What's truly essential vs nice-to-have?
 - Gold-plating risks: "We could simplify by [X]..."
 - Reference: YAGNI, Walking Skeleton, Tracer Bullet (Pragmatic Programmer)
@@ -131,10 +145,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 3.2: Approach Rationale
+
 **Ask:**
 > "Why this approach over alternatives?"
 
 **After response, contribute:**
+
 - Present 2-3 alternative approaches with trade-offs
 - Reference: Architecture Decision Records pattern
 - Probe: "Have you considered [alternative]? Trade-off would be [X]..."
@@ -144,10 +160,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 3.3: Explicit Non-Goals
+
 **Ask:**
 > "What are we explicitly NOT doing? What should be out of scope?"
 
 **After response, contribute:**
+
 - Suggest common scope creep items to exclude
 - Reference: Anti-goals pattern, MoSCoW prioritization
 - "I'd recommend also excluding [X] to keep scope tight..."
@@ -157,10 +175,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 3.4: Architecture Fit
+
 **Ask:**
 > "How does this fit with the current architecture?"
 
 **After response, contribute:**
+
 - Cross-reference `draft/.ai-context.md` (or `draft/architecture.md`) for integration points
 - Identify affected modules/components
 - Reference: Clean Architecture boundaries, module coupling
@@ -171,10 +191,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 3.5: Reusable Patterns
+
 **Ask:**
 > "What existing patterns or components can we leverage?"
 
 **After response, contribute:**
+
 - Search codebase context for reusable patterns
 - Suggest tech-stack.md conventions to follow
 - Reference: DRY, existing abstractions
@@ -188,6 +210,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 
 **Summarize:**
 > "Here's the proposed solution:
+>
 > - Approach: [summary]
 > - Why this approach: [rationale]
 > - Not doing: [non-goals]
@@ -203,10 +226,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ## Phase 4: Risk & Constraints
 
 ### Question 4.1: What Could Go Wrong
+
 **Ask:**
 > "What could go wrong with this approach?"
 
 **After response, contribute:**
+
 - Surface risks user may not have considered
 - Security: Reference OWASP Top 10 if relevant
 - Performance: Identify potential bottlenecks
@@ -218,10 +243,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 4.2: Dependencies & Blockers
+
 **Ask:**
 > "What dependencies or blockers exist? (External APIs, other teams, data, infrastructure)"
 
 **After response, contribute:**
+
 - Identify external dependencies and their reliability
 - Team dependencies: Who else needs to be involved?
 - Data dependencies: What data do we need? Where does it come from?
@@ -232,10 +259,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 4.3: Assumptions
+
 **Ask:**
 > "What assumptions are we making? Why might this fail?"
 
 **After response, contribute:**
+
 - List implicit assumptions explicitly
 - Fact-check against `draft/tech-stack.md` and `draft/.ai-context.md`
 - Reference: Pre-mortem technique
@@ -246,10 +275,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 4.4: Constraints
+
 **Ask:**
 > "What constraints must we operate within? (Timeline, tech limitations, compliance, performance requirements)"
 
 **After response, contribute:**
+
 - Identify tech constraints from tech-stack.md
 - Performance requirements: Latency, throughput, scale
 - Compliance: GDPR, SOC2, industry-specific
@@ -260,10 +291,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 4.5: Security & Compliance
+
 **Ask:**
 > "Are there security or compliance considerations?"
 
 **After response, contribute:**
+
 - Flag relevant OWASP concerns
 - Data privacy: PII handling, encryption, access control
 - Authentication/authorization patterns
@@ -277,6 +310,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 
 **Summarize:**
 > "Key risks and constraints identified:
+>
 > - Risks: [list]
 > - Dependencies: [list]
 > - Assumptions: [list]
@@ -292,10 +326,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ## Phase 5: Success Criteria
 
 ### Question 5.1: Definition of Done
+
 **Ask:**
 > "How do we know this is complete? What must be true when we're done?"
 
 **After response, contribute:**
+
 - Suggest measurable acceptance criteria
 - Convert vague criteria to testable outcomes
 - Reference: SMART criteria, Given-When-Then format
@@ -306,10 +342,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 5.2: Verification Strategy
+
 **Ask:**
 > "How will we verify it works correctly?"
 
 **After response, contribute:**
+
 - Suggest testing strategies appropriate to feature type
 - Reference: Test pyramid, TDD practices
 - Integration testing: What integration points need testing?
@@ -320,10 +358,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 5.3: Stakeholder Acceptance
+
 **Ask:**
 > "What would make stakeholders accept this? What does success look like to them?"
 
 **After response, contribute:**
+
 - Align with product.md goals
 - Suggest demo scenarios
 - Reference: Stakeholder analysis, acceptance criteria patterns
@@ -337,6 +377,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 
 **Summarize:**
 > "Success criteria defined:
+>
 > - Done when: [criteria list]
 > - Verified by: [testing approach]
 > - Stakeholders accept when: [demo scenarios]
@@ -360,11 +401,13 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 > Ready to finalize this spec, or any changes needed?"
 
 **If changes needed:**
+
 - Discuss specific sections
 - Update spec-draft.md
 - Return to this review step
 
 **If confirmed:**
+
 - Promote spec-draft.md → spec.md
 - Announce: "Spec finalized. Now let's create the implementation plan."
 
@@ -374,6 +417,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 
 **After spec is finalized, propose plan structure:**
 > "Based on the spec, I propose these phases:
+>
 > - Phase 1: [name] — [goal]
 > - Phase 2: [name] — [goal]
 > - Phase 3: [name] — [goal]
@@ -382,6 +426,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 > Does this phasing make sense, or should we adjust?"
 
 **After confirmation:**
+
 - Build out detailed plan-draft.md with tasks
 - Present for review
 - On confirmation: promote plan-draft.md → plan.md

package/core/templates/jira.md

@@ -28,11 +28,12 @@ labels: # Labels to apply to all created issues
 # Jira Story Template (Minimal)
 
 ## Summary
+
 [Brief, descriptive title]
 
 ## Description
 
-```
+```text
 h3. Description:
 
 Problem Statement:
@@ -68,7 +69,7 @@ Use Cases:
 
 ## Acceptance Criteria
 
-```
+```text
 - [ ] [Criterion 1: Specific, testable requirement]
 - [ ] [Criterion 2: Specific, testable requirement]
 - [ ] [Criterion 3: Specific, testable requirement]
@@ -77,35 +78,42 @@ Use Cases:
 ## Required Fields
 
 ### Standard Fields
+
 - **Issue Type:** Story
 - **Priority:** Medium
 - **Components:** [Component name]
 - **Fix Version/s:** [Version or master]
 
 ### People
+
 - **Assignee:** [Your email]
 - **Product Owner:** [PO email]
 - **Tech Lead:** [Tech lead email]
 - **Scrum Master:** [Scrum master email]
 
 ### Team
+
 - **Developers:** [List developer emails]
 - **Reviewers:** [List reviewer emails]
 
 ### Story Details
+
 - **Story Points:** [1/2/3/5/8/13]
 - **Work Type:** Operational Excellence
 - **Sub-Team:** [Sub-team name]
 - **Organization:** R&D
 
 ### Development Status
+
 - **Development Status:** Not-Started
 
 ### Security
+
 - **Requires Security Review:** Yes/No
 - **Security Review Status:** Review Needed
 
 ### Quality Gates
+
 - [ ] Tasks complete
 - [ ] Functional Testing complete
 - [ ] 100% code unit tested or Automated
@@ -113,6 +121,7 @@ Use Cases:
 - [ ] i18n impact review
 
 ### Other
+
 - **Risk Assessment:** Toss Up
 - **Priority Level:** Normal
 - **Category:** Uncategorized

package/core/templates/lld.md

@@ -48,7 +48,7 @@ links:
 <Link to HLD and explain context here>
 
 > See [`./hld.md` §Background](./hld.md#background) for the high-level rationale. Use this section only for component-internal context the HLD doesn't cover.
-
+>
 > **Citations.** Use `path/to/file.ext:LINE` (or `LINE-RANGE`); verifier:
 > `scripts/tools/verify-citations.sh`. Prefer `// DRAFT-CITE: <id>` source
 > anchors over raw line numbers for code that moves often.
@@ -67,6 +67,7 @@ links:
 ## Low Level Design
 
 > **NOTE:**
+>
 > - HLD and Detailed Design covers components and interactions across various services that the feature touches
 > - LLD to be documented here is for each such component and internal implementation
 > - A single doc here can cover all components, or they can be split up, but the key is to ensure every component in every service the design touches has an LLD
@@ -159,6 +160,7 @@ links:
 > deploy-checklist fail on bare prose without diagram blocks.
 
 Examples:
+
 - List of steps to failover a multi-region database cluster
 - Analysis phase of a background data indexing service
 - Transferring session state information between authentication and profile services via a secure messaging protocol
@@ -188,13 +190,14 @@ sequenceDiagram
 
 **Pseudocode:**
 
-```
+```text
 1. validate inputs
 2. ...
 3. return result
 ```
 
 **Edge cases handled:**
+
 - {case 1 — what happens}
 - {case 2 — what happens}
 
@@ -269,9 +272,9 @@ sequenceDiagram
 
 List down all metrics that developers and SREs need to look at to identify issues:
 
-- 
-- 
-- 
+-
+-
+-
 
 ### Alerting Thresholds
 

package/core/templates/okf/concept.md

@@ -60,4 +60,3 @@ okf-validate-quality.sh and therefore does NOT satisfy okf-coverage-check.sh —
 the bundle will not be promoted. Diagram types (Subsystem/Module/Feature/
 Entrypoint) require ≥1 valid Mermaid block and ≥2 x-grounded-paths.
 -->
-

package/core/templates/product.md

@@ -26,10 +26,12 @@ generated_at: "{ISO_TIMESTAMP}"
 ## Target Users
 
 ### Primary Users
+
 - **[User Type 1]**: [What they need, their context]
 - **[User Type 2]**: [What they need, their context]
 
 ### Secondary Users
+
 - **[Admin/Support]**: [Their interaction with the product]
 
 ---
@@ -37,15 +39,18 @@ generated_at: "{ISO_TIMESTAMP}"
 ## Core Features
 
 ### Must Have (P0)
+
 1. **[Feature 1]**: [Brief description]
 2. **[Feature 2]**: [Brief description]
 3. **[Feature 3]**: [Brief description]
 
 ### Should Have (P1)
+
 1. **[Feature 4]**: [Brief description]
 2. **[Feature 5]**: [Brief description]
 
 ### Nice to Have (P2)
+
 1. **[Feature 6]**: [Brief description]
 
 ---
@@ -61,16 +66,16 @@ generated_at: "{ISO_TIMESTAMP}"
 ## Constraints
 
 ### Technical
+
 - [Constraint, e.g., "Must support IE11"]
 - [Constraint, e.g., "API response time < 200ms"]
 
 ### Business
+
 - [Constraint, e.g., "Must comply with GDPR"]
 - [Constraint, e.g., "Budget for external APIs: $X/month"]
 
 ### Timeline
-- [Milestone 1]: [Date]
-- [Milestone 2]: [Date]
 
 ---
 
@@ -93,19 +98,23 @@ Things explicitly out of scope for this product:
 ## Guidelines (Optional)
 
 ### Writing Style
+
 - **Tone:** [professional / casual / technical]
 - **Voice:** [first person "we" / third person "the system" / second person "you"]
 - **Terminology:** [domain-specific terms and definitions]
 
 ### UX Principles
+
 1. [e.g., "Convention over configuration" — minimize required decisions]
 2. [e.g., "Accessible by default" — WCAG AA compliance minimum]
 3. [e.g., "Progressive disclosure" — show complexity only when needed]
 
 ### Error Handling
+
 - **Error message tone:** [helpful / technical / minimal]
 - **User feedback patterns:** [toasts / modals / inline / status bar]
 
 ### Content Standards
+
 - **Date format:** [ISO 8601 / localized / relative]
 - **Internationalization:** [i18n required / English-only / planned]

package/core/templates/rca.md

@@ -64,15 +64,19 @@ generated_at: "{ISO_TIMESTAMP}"
 ## Prevention Items
 
 ### Detection Improvement
+
 - [ ] [monitoring/alerting improvement to catch this sooner]
 
 ### Process Improvement
+
 - [ ] [review/testing improvement to prevent this class of bug]
 
 ### Code Improvement
+
 - [ ] [guard/validation to add in code]
 
 ### Architecture Improvement
+
 - [ ] [structural change if needed to make this class of bug impossible]
 
 ## Proposed Fix
@@ -80,8 +84,10 @@ generated_at: "{ISO_TIMESTAMP}"
 [Brief description of the fix approach — developer reviews before implementation]
 
 **Files to modify:**
+
 - `file1:line` — [change description]
 - `file2:line` — [change description]
 
 **Regression test:**
+
 - [Description of regression test to write — pending developer approval]

package/core/templates/service-index.md

@@ -43,6 +43,7 @@ The following services have not been initialized with `/draft:init`:
 - `[path/to/service]/`
 
 Initialize each one by running `/draft:init` inside its directory — it links the module's graph up to the root spine:
+
 ```bash
 cd [path/to/service] && /draft:init
 ```

package/core/templates/spec.md

@@ -45,6 +45,7 @@ approvers:
 > is rendered from `metadata.json:status`; never edit it inline.
 
 ## Context References
+
 - **Product:** `draft/product.md` — [pending]
 - **Tech Stack:** `draft/tech-stack.md` — [pending]
 - **Architecture:** `draft/.ai-context.md` — [pending]
@@ -59,16 +60,21 @@ approvers:
 > `<!-- VERIFIER:IGNORE END -->` so they don't fail the verifier.
 
 ## Problem Statement
+
 [To be developed through intake conversation]
 
 ## Background & Why Now
+
 [To be developed through intake conversation]
 
 ## Requirements
+
 ### Functional
+
 [To be developed through intake conversation]
 
 ### Non-Functional
+
 [To be developed through intake conversation]
 
 ## Acceptance Criteria
@@ -82,9 +88,11 @@ approvers:
 | AC-2 | _TBD_ac_2_description_ | _TBD_ac_2_test_id_ |
 
 ## Non-Goals
+
 [To be developed through intake conversation]
 
 ## Technical Approach
+
 [To be developed through intake conversation]
 
 ## Eligibility / Cap Policy <!-- OPTIONAL -->
@@ -118,6 +126,7 @@ approvers:
 | QA | _TBD_approver_qa_ | Test plan review | [ ] |
 
 ### Approval Gates
+
 - [ ] Spec approved by Product Owner
 - [ ] Architecture reviewed by Tech Lead
 - [ ] Security review completed (if touching auth, data, or external APIs)
@@ -138,29 +147,35 @@ approvers:
 <!-- Define rollout approach for production delivery -->
 
 ### Rollout Phases
+
 1. **Canary** (1-5% traffic) — Validate core flows, monitor error rates
 2. **Limited GA** (25%) — Expand to subset, watch performance metrics
 3. **Full GA** (100%) — Complete rollout
 
 ### Feature Flags
+
 - Flag name: `[feature_flag_name]`
 - Default: `off`
 - Kill switch: [yes/no]
 
 ### Rollback Plan
+
 - Trigger: [e.g., error rate >1%, latency >500ms p95]
 - Process: [e.g., disable feature flag, revert deployment]
 - Data rollback: [e.g., migration revert script, N/A]
 
 ### Monitoring
+
 - Dashboard: [link or name]
 - Alerts: [e.g., PagerDuty rule for error rate spike]
 - Key metrics: [e.g., error rate, latency, throughput]
 
 ## Open Questions
+
 [Tracked during conversation]
 
 ## Conversation Log
+>
 > Key decisions and reasoning captured during intake.
 
 [Conversation summary will be added here]

package/core/templates/tech-stack.md

@@ -29,12 +29,14 @@ generated_at: "{ISO_TIMESTAMP}"
 ## Frameworks & Libraries
 
 ### Core
+
 | Name | Version | Purpose |
 |------|---------|---------|
 | [Framework] | [Version] | [Purpose] |
 | [Library] | [Version] | [Purpose] |
 
 ### Development
+
 | Name | Version | Purpose |
 |------|---------|---------|
 | [Tool] | [Version] | [Purpose] |
@@ -64,14 +66,17 @@ generated_at: "{ISO_TIMESTAMP}"
 ## Build & Deploy
 
 ### Build
+
 - **Tool**: [Webpack/Vite/esbuild/etc]
 - **Output**: [dist/build/etc]
 
 ### CI/CD
+
 - **Platform**: [GitHub Actions/CircleCI/etc]
 - **Triggers**: [on push, PR, etc]
 
 ### Deployment
+
 - **Target**: [Vercel/AWS/GCP/etc]
 - **Environments**: [dev, staging, prod]
 
@@ -80,18 +85,22 @@ generated_at: "{ISO_TIMESTAMP}"
 ## Code Patterns
 
 ### Architecture
+
 - **Pattern**: [Clean Architecture/MVC/Hexagonal/etc]
 - **Rationale**: [Why this pattern]
 
 ### State Management
+
 - **Approach**: [Redux/Zustand/Context/etc]
 - **Rationale**: [Why this approach]
 
 ### Error Handling
+
 - **Strategy**: [Centralized/per-module/etc]
 - **Logging**: [Tool/service]
 
 ### API Design
+
 - **Style**: [REST/GraphQL/gRPC]
 - **Conventions**: [Naming, versioning]
 
@@ -140,15 +149,18 @@ graph TD
 ## Code Style
 
 ### Linting
+
 - **Tool**: [ESLint/Prettier/etc]
 - **Config**: [.eslintrc / prettier.config.js]
 
 ### Formatting
+
 - **Indentation**: [2 spaces / 4 spaces / tabs]
 - **Line Length**: [80 / 100 / 120]
 - **Quotes**: [single / double]
 
 ### Naming Conventions
+
 - **Files**: [kebab-case / camelCase / PascalCase]
 - **Functions**: [camelCase]
 - **Classes**: [PascalCase]