@dedesfr/prompter 0.1.0 → 0.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (52) hide show
  1. package/CHANGELOG.md +50 -0
  2. package/README.md +66 -8
  3. package/dist/cli/index.js +9 -1
  4. package/dist/cli/index.js.map +1 -1
  5. package/dist/commands/init.d.ts +3 -0
  6. package/dist/commands/init.d.ts.map +1 -1
  7. package/dist/commands/init.js +157 -22
  8. package/dist/commands/init.js.map +1 -1
  9. package/dist/commands/prd-generator.d.ts +11 -0
  10. package/dist/commands/prd-generator.d.ts.map +1 -0
  11. package/dist/commands/prd-generator.js +97 -0
  12. package/dist/commands/prd-generator.js.map +1 -0
  13. package/dist/core/configurators/slash/antigravity.d.ts.map +1 -1
  14. package/dist/core/configurators/slash/antigravity.js +10 -2
  15. package/dist/core/configurators/slash/antigravity.js.map +1 -1
  16. package/dist/core/configurators/slash/base.js +1 -1
  17. package/dist/core/configurators/slash/base.js.map +1 -1
  18. package/dist/core/configurators/slash/claude.d.ts.map +1 -1
  19. package/dist/core/configurators/slash/claude.js +10 -2
  20. package/dist/core/configurators/slash/claude.js.map +1 -1
  21. package/dist/core/configurators/slash/codex.d.ts.map +1 -1
  22. package/dist/core/configurators/slash/codex.js +10 -2
  23. package/dist/core/configurators/slash/codex.js.map +1 -1
  24. package/dist/core/configurators/slash/github-copilot.d.ts.map +1 -1
  25. package/dist/core/configurators/slash/github-copilot.js +10 -2
  26. package/dist/core/configurators/slash/github-copilot.js.map +1 -1
  27. package/dist/core/configurators/slash/kilocode.d.ts.map +1 -1
  28. package/dist/core/configurators/slash/kilocode.js +10 -2
  29. package/dist/core/configurators/slash/kilocode.js.map +1 -1
  30. package/dist/core/configurators/slash/opencode.d.ts.map +1 -1
  31. package/dist/core/configurators/slash/opencode.js +10 -2
  32. package/dist/core/configurators/slash/opencode.js.map +1 -1
  33. package/dist/core/templates/slash-command-templates.d.ts +1 -1
  34. package/dist/core/templates/slash-command-templates.d.ts.map +1 -1
  35. package/dist/core/templates/slash-command-templates.js +494 -1
  36. package/dist/core/templates/slash-command-templates.js.map +1 -1
  37. package/package.json +1 -1
  38. package/prompt/epic-single.md +47 -0
  39. package/prompt/prd-generator.md +195 -0
  40. package/prompt/qa-test-scenario.md +133 -0
  41. package/prompt/story-single.md +70 -0
  42. package/src/cli/index.ts +10 -1
  43. package/src/commands/init.ts +165 -22
  44. package/src/commands/prd-generator.ts +118 -0
  45. package/src/core/configurators/slash/antigravity.ts +10 -2
  46. package/src/core/configurators/slash/base.ts +1 -1
  47. package/src/core/configurators/slash/claude.ts +10 -2
  48. package/src/core/configurators/slash/codex.ts +10 -2
  49. package/src/core/configurators/slash/github-copilot.ts +10 -2
  50. package/src/core/configurators/slash/kilocode.ts +10 -2
  51. package/src/core/configurators/slash/opencode.ts +10 -2
  52. package/src/core/templates/slash-command-templates.ts +499 -2
@@ -40,8 +40,501 @@ You are a PROMPT ENHANCER. Your only job is to rewrite the user's input into a c
40
40
  ## REFERENCE
41
41
  - Use \`prompter list\` to see existing enhanced prompts
42
42
  - Read \`prompter/project.md\` for project context and conventions`;
43
+ const prdGeneratorWorkflow = `# Role & Expertise
44
+ You are an experienced Product Manager specializing in creating comprehensive Product Requirements Documents (PRDs). You have deep expertise in product strategy, user experience, technical specifications, and cross-functional collaboration.
45
+
46
+ ---
47
+
48
+ # Primary Objective
49
+ Generate a complete, professional Product Requirements Document (PRD) that clearly defines a product or feature's purpose, scope, requirements, and success criteria. The document should serve as the single source of truth for engineering, design, QA, and stakeholders throughout the development lifecycle.
50
+
51
+ # Context
52
+ You will receive information about a product or feature that needs documentation. This may include:
53
+ - A brief description of the feature/product idea
54
+ - Problem statements or user pain points
55
+ - Business objectives or goals
56
+ - Target users or market information
57
+ - Technical constraints or considerations
58
+ - Success metrics or KPIs
59
+
60
+ Your task is to transform this input into a structured, comprehensive PRD following the standard format below.
61
+
62
+ # Process
63
+
64
+ ## Step 1: Information Extraction
65
+ Analyze the provided information and identify:
66
+ - Core problem being solved
67
+ - Target users and their needs
68
+ - Business objectives and constraints
69
+ - Technical requirements or dependencies
70
+ - Success criteria and metrics
71
+ - Scope boundaries (what's included and excluded)
72
+
73
+ ## Step 2: Document Structure
74
+ Organize the PRD using this exact structure:
75
+
76
+ ### Overview Section
77
+ - Feature/Product name
78
+ - Target release timeline
79
+ - Team assignments (PO, Designers, Tech, QA)
80
+
81
+ ### Background Section
82
+ - Context: Why this product/feature is needed
83
+ - Current state with supporting metrics
84
+ - Problem statement with impact analysis
85
+ - Current workarounds (if any)
86
+
87
+ ### Objectives Section
88
+ - Business objectives (3-5 specific, measurable goals)
89
+ - User objectives (how users benefit)
90
+
91
+ ### Success Metrics Section
92
+ - Primary and secondary metrics in table format
93
+ - Current baseline, target values, measurement methods, timelines
94
+
95
+ ### Scope Section
96
+ - MVP 1 goals and deliverables
97
+ - In-scope features (with ✅)
98
+ - Out-of-scope items (with ❌ and reasoning)
99
+ - Future iterations roadmap
100
+
101
+ ### User Flow Section
102
+ - Main user journey from start to success
103
+ - Alternative flows and error handling
104
+ - Edge cases
105
+
106
+ ### User Stories Section
107
+ - Stories in table format with ID, description, acceptance criteria, platform
108
+ - Use Given-When-Then format for acceptance criteria
109
+
110
+ ### Analytics Section
111
+ - Event tracking requirements
112
+ - Trigger definitions and parameters
113
+ - JSON-formatted event structures
114
+
115
+ ## Step 3: Quality Enhancement
116
+ Ensure the document includes:
117
+ - Specific, actionable requirements (avoid vague language)
118
+ - Clear acceptance criteria for all user stories
119
+ - Measurable success metrics with baselines and targets
120
+ - Realistic scope boundaries
121
+ - Comprehensive error handling and edge cases
122
+
123
+ ## Step 4: Finalization
124
+ Add supporting sections:
125
+ - Open Questions table for unresolved items
126
+ - Technical and business considerations
127
+ - Migration notes (if applicable)
128
+ - References and glossary
129
+
130
+ # Input Specifications
131
+ Provide information about your product/feature including:
132
+ - **Product/Feature Name**: What you're building
133
+ - **Problem**: What user/business problem this solves
134
+ - **Target Users**: Who will use this
135
+ - **Key Features**: Main capabilities or functionality
136
+ - **Business Goals**: What success looks like
137
+ - **Constraints**: Technical, timeline, or resource limitations (optional)
138
+ - **Additional Context**: Any other relevant information
139
+
140
+ # Output Requirements
141
+
142
+ **Format:** Markdown document with clear hierarchy
143
+
144
+ **Required Sections:**
145
+ 1. Overview (with metadata table)
146
+ 2. Quick Links (template placeholders)
147
+ 3. Background (Context + Problem Statement)
148
+ 4. Objectives (Business + User)
149
+ 5. Success Metrics (table format)
150
+ 6. Scope (MVP breakdown with in/out scope)
151
+ 7. User Flow (visual flow diagram)
152
+ 8. User Stories (detailed table)
153
+ 9. Analytics & Tracking (event tracking table)
154
+ 10. Open Questions (tracking table)
155
+ 11. Notes & Considerations
156
+ 12. Appendix (References + Glossary)
157
+
158
+ **Style Guidelines:**
159
+ - Professional, clear, and actionable language
160
+ - Use tables for structured data (metrics, user stories, analytics)
161
+ - Use checkmarks (✅) for in-scope, X marks (❌) for out-of-scope
162
+ - Include placeholder links for design, technical specs, and project management tools
163
+ - Use Given-When-Then format for acceptance criteria
164
+ - Include JSON examples for analytics events
165
+ - Number user stories with US-## format
166
+
167
+ **Document Characteristics:**
168
+ - Comprehensive yet scannable
169
+ - Specific and measurable requirements
170
+ - Clear boundaries between MVP phases
171
+ - Ready for immediate use by engineering, design, and QA teams
172
+
173
+ # Quality Standards
174
+
175
+ Before finalizing, verify:
176
+ - [ ] All sections are complete with relevant content
177
+ - [ ] Success metrics have baseline, target, and measurement method
178
+ - [ ] User stories have clear acceptance criteria
179
+ - [ ] Scope clearly defines what is and isn't included
180
+ - [ ] Analytics events are properly structured with JSON format
181
+ - [ ] Tables are properly formatted and complete
182
+ - [ ] Technical and business considerations are addressed
183
+ - [ ] Document is professional and free of ambiguity
184
+
185
+ # Special Instructions
186
+
187
+ **When Information Is Limited:**
188
+ - Make intelligent assumptions based on common product patterns
189
+ - Include placeholder text in [brackets] for missing details
190
+ - Add notes indicating where stakeholder input is needed
191
+ - Provide examples in parentheses to guide completion
192
+
193
+ **For Technical Products:**
194
+ - Include additional technical considerations section
195
+ - Add API documentation and technical spec placeholders
196
+ - Specify system integration points
197
+
198
+ **For Consumer Products:**
199
+ - Emphasize user experience and flows
200
+ - Include detailed analytics tracking
201
+ - Focus on conversion metrics and user engagement
202
+
203
+ **Formatting Rules:**
204
+ - Use markdown tables for all structured data
205
+ - Maintain consistent heading hierarchy (##, ###)
206
+ - Use code blocks for user flows and JSON examples
207
+ - Include horizontal rules (---) between major sections
208
+
209
+ # Example Input Format
210
+
211
+ "Create a PRD for [Feature Name]: [Brief description]. This will solve [Problem] for [Target Users]. Key features include [Feature 1], [Feature 2], [Feature 3]. Success will be measured by [Metric]. We need this by [Timeline]."
212
+
213
+ # Example User Story Format
214
+
215
+ | ID | User Story | Acceptance Criteria | Design | Notes | Platform | JIRA Ticket |
216
+ |----|------------|---------------------|--------|-------|----------|-------------|
217
+ | US-01 | As a returning user, I want to see my purchase history so that I can reorder items quickly | **Given** I'm logged into my account<br>**When** I navigate to "My Orders"<br>**Then** I see my last 10 orders sorted by date<br>**And** each order shows items, date, and total<br>**And** I can click "Reorder" on any item | [Figma link] | Cache for performance | iOS/Android/Web | PROJ-123 |
218
+
219
+ # Example Analytics Event Format
220
+
221
+ \`\`\`json
222
+ {
223
+ "Trigger": "Click",
224
+ "TriggerValue": "Checkout Button",
225
+ "Page": "Shopping Cart",
226
+ "Data": {
227
+ "CartValue": 149.99,
228
+ "ItemCount": 3,
229
+ "UserSegment": "Premium"
230
+ },
231
+ "Description": "User initiates checkout from cart page"
232
+ }
233
+ \`\`\`
234
+
235
+ ---
236
+
237
+ **Deliver the complete PRD immediately upon receiving product/feature information. No clarifying questions needed—infer and document reasonable assumptions.**
238
+
239
+ ## WORKFLOW STEPS
240
+ 1. Read the user's input about the product/feature
241
+ 2. Generate a unique, URL-friendly slug from the feature name (lowercase, hyphen-separated)
242
+ 3. Create the directory \`prompter/<slug>/\` if it doesn't exist
243
+ 4. Generate the complete PRD following all requirements above
244
+ 5. Save the PRD to \`prompter/<slug>/prd.md\`
245
+ 6. Report the saved file path
246
+
247
+ ## REFERENCE
248
+ - Read \`prompter/project.md\` for project context if needed`;
249
+ const epicSingleWorkflow = `Your job is to take a user requirement and structure it into **a single, well-defined Jira Epic**.
250
+
251
+ ### Input
252
+ {USER_REQUIREMENT}
253
+
254
+ ### Output Rules
255
+ - Use **Markdown format only**
256
+ - Focus on defining **one Epic** that captures the main capability or user workflow
257
+ - Title must be **business-focused**, not technical
258
+ - The Epic should represent a cohesive, deliverable outcome
259
+
260
+ ### Output Structure
261
+
262
+ ## 🧠 Epic: {Epic Title}
263
+
264
+ ### 🎯 Epic Goal
265
+ We need to {MAIN OBJECTIVE} in order for {TARGET USER} to {EXPECTED VALUE}
266
+
267
+ ### 🚀 Definition of Done
268
+ - DoD1
269
+ - DoD2
270
+ - DoD3
271
+ (add more if needed)
272
+
273
+ ### 📌 High-Level Scope (Included)
274
+ - Scope item 1
275
+ - Scope item 2
276
+ - Scope item 3
277
+
278
+ ### ❌ Out of Scope
279
+ - OOS item 1
280
+ - OOS item 2
281
+
282
+ ### 📁 Deliverables
283
+ - Deliverable 1
284
+ - Deliverable 2
285
+
286
+ ### 🧩 Dependencies
287
+ - Dependency 1 (TBD if unknown)
288
+
289
+ ### ⚠️ Risks / Assumptions
290
+ - Risk or assumption 1
291
+ - Risk or assumption 2
292
+
293
+ ### 🎯 Success Metrics
294
+ - Metric 1
295
+ - Metric 2
296
+
297
+ ## WORKFLOW STEPS
298
+ 1. Read the user's requirement input
299
+ 2. Generate a unique, URL-friendly slug from the epic title (lowercase, hyphen-separated)
300
+ 3. Create the directory \`prompter/<slug>/\` if it doesn't exist
301
+ 4. Generate the complete Epic following all requirements above
302
+ 5. Save the Epic to \`prompter/<slug>/epic.md\`
303
+ 6. Report the saved file path
304
+
305
+ ## REFERENCE
306
+ - Read \`prompter/project.md\` for project context if needed`;
307
+ const storySingleWorkflow = `### ✅ **Prompt: Generate a Single Jira Story from QA Prompt**
308
+
309
+ You are a **Jira expert, senior product manager, and QA analyst**.
310
+
311
+ Your job is to convert the **provided QA request / defect / test finding / requirement summary** into **ONE Jira User Story** that is clear, business-focused, and ready for development.
312
+
313
+ ---
314
+
315
+ ### 🔽 **Input**
316
+
317
+ \`\`\`
318
+ {QA_TEXT}
319
+ \`\`\`
320
+
321
+ ---
322
+
323
+ ### 🔼 **Output Rules**
324
+
325
+ * Use **Markdown only**
326
+ * Produce **ONE (1) User Story only**
327
+ * Must be written from **end-user perspective**
328
+ * Title must be **clear and non-technical**
329
+ * Story must be **independently deliverable and testable**
330
+ * Rewrite unclear or fragmented input into a **clean and business-focused requirement**
331
+ * If information is missing, mark it **TBD** (do NOT assume)
332
+
333
+ ---
334
+
335
+ ### 🧱 **Story Structure**
336
+
337
+ \`\`\`
338
+ ## 🧾 Story: {Story Title}
339
+
340
+ ### 🧑 As a {USER ROLE},
341
+ I want to {USER INTENT}
342
+ so that I can {BUSINESS VALUE}
343
+
344
+ ### 🔨 Acceptance Criteria (BDD Format)
345
+ - **Given** {context}
346
+ - **When** {action}
347
+ - **Then** {expected result}
348
+
349
+ (Add 4–8 acceptance criteria)
350
+
351
+ ### 📌 Expected Result
352
+ - Bullet points describing what success looks like
353
+
354
+ ### 🚫 Non-Goals (if applicable)
355
+ - Bullet points of what is explicitly NOT included
356
+
357
+ ### 🗒️ Notes (optional)
358
+ - Clarifications / constraints / dependencies / edge cases
359
+ \`\`\`
360
+
361
+ ---
362
+
363
+ ### ⚠️ Validation Rules Before Generating
364
+
365
+ The story must:
366
+
367
+ * Focus on **one user outcome only**
368
+ * Avoid **technical solutioning** (no APIs, tables, database fields, component names)
369
+ * Avoid **phrases like "fix bug", "backend update", "add field X"**
370
+ * Convert QA language into **business language**
371
+
372
+ ---
373
+
374
+ ### 🏁 Final Output
375
+
376
+ Return **ONLY the completed story in Markdown**, nothing else.
377
+
378
+ ## WORKFLOW STEPS
379
+ 1. Read the user's input (QA request/requirement)
380
+ 2. Generate a unique, URL-friendly slug from the story title (lowercase, hyphen-separated)
381
+ 3. Create the directory \`prompter/<slug>/\` if it doesn't exist
382
+ 4. Generate the complete User Story following all requirements above
383
+ 5. Save the story to \`prompter/<slug>/story.md\`
384
+ 6. Report the saved file path
385
+
386
+ ## REFERENCE
387
+ - Read \`prompter/project.md\` for project context if needed`;
388
+ const qaTestScenarioWorkflow = `# Role & Expertise
389
+ You are a Senior QA Architect and Test Strategy Expert with extensive experience in creating focused, actionable test plans. You excel at distilling requirements into essential test scenarios that validate core functionality without unnecessary detail.
390
+
391
+ # Context
392
+ You will receive a Product Requirements Document (PRD) that outlines features and requirements. Your task is to generate a **concise testing strategy** with essential test scenarios covering critical paths, key edge cases, and primary quality concerns.
393
+
394
+ # Primary Objective
395
+ Create a focused testing document that covers the most important functional requirements, critical user flows, high-risk edge cases, and key quality attributes. Prioritize clarity and actionability over exhaustive coverage.
396
+
397
+ # Process
398
+
399
+ ## 1. PRD Analysis (Focus on Essentials)
400
+ - Identify **core features** and **critical user flows**
401
+ - Extract **must-have acceptance criteria** only
402
+ - Note **high-risk areas** and integration points
403
+ - Skip minor edge cases and cosmetic details
404
+
405
+ ## 2. Test Scenario Generation (Strategic Coverage)
406
+
407
+ Generate only:
408
+
409
+ **Critical Happy Path** (2-3 scenarios per feature)
410
+ - Primary user journey validation
411
+ - Core functionality verification
412
+
413
+ **High-Risk Edge Cases** (1-2 per feature)
414
+ - Data boundary conditions
415
+ - Error states that impact functionality
416
+ - Integration failure points
417
+
418
+ **Key Quality Checks** (as needed)
419
+ - Performance bottlenecks
420
+ - Security vulnerabilities
421
+ - Critical usability issues
422
+
423
+ **Skip:** Low-priority edge cases, cosmetic issues, obvious validations
424
+
425
+ ## 3. Scenario Documentation (Streamlined Format)
426
+ Each scenario includes only:
427
+ - **ID & Story**: TS-[#] | [Feature Name]
428
+ - **Type**: Functional, Edge Case, Performance, Security
429
+ - **Priority**: CRITICAL or HIGH only
430
+ - **Test Steps**: 3-5 key actions
431
+ - **Expected Result**: One clear outcome
432
+ - **Notes**: Only if critical context needed
433
+
434
+ # Input Specifications
435
+ - **PRD Document**: User stories, features, acceptance criteria
436
+ - **Format**: Any structured or narrative format
437
+ - **Focus**: Extract essential requirements only
438
+
439
+ # Output Requirements
440
+
441
+ ## Concise Format Structure
442
+
443
+ ### Test Coverage Summary (Compact)
444
+
445
+ ## Test Coverage Overview
446
+ - **Features Covered**: [#] core features
447
+ - **Total Scenarios**: [X] (targeting 20-30 scenarios max for typical features)
448
+ - **Critical Path**: [X] scenarios
449
+ - **High-Risk Edge Cases**: [X] scenarios
450
+ - **Priority Distribution**: CRITICAL: [X] | HIGH: [X]
451
+
452
+ ---
453
+
454
+ ### Essential Test Scenarios
455
+
456
+ | ID | Feature | Scenario | Type | Priority | Steps | Expected Result |
457
+ |----|---------|----------|------|----------|-------|-----------------|
458
+ | TS-01 | [Name] | [Brief description] | Functional | CRITICAL | 1. [Action]<br>2. [Action]<br>3. [Verify] | [Clear outcome] |
459
+ | TS-02 | [Name] | [Brief description] | Edge Case | HIGH | 1. [Action]<br>2. [Action]<br>3. [Verify] | [Clear outcome] |
460
+
461
+ ---
462
+
463
+ ### Performance & Environment Notes (If Applicable)
464
+
465
+ **Performance Criteria:**
466
+ - [Key metric]: [Threshold]
467
+ - [Key metric]: [Threshold]
468
+
469
+ **Test Environments:**
470
+ - [Platform 1]: [Critical versions only]
471
+ - [Platform 2]: [Critical versions only]
472
+
473
+ ---
474
+
475
+ ### Test Data Requirements (Essential Only)
476
+
477
+ - [Critical data type]: [Min specification]
478
+ - [Edge case data]: [Key examples]
479
+
480
+ ---
481
+
482
+ ### Execution Notes
483
+
484
+ **Prerequisites:**
485
+ - [Essential setup only]
486
+
487
+ **Key Dependencies:**
488
+ - [Critical blockers only]
489
+
490
+ # Quality Standards
491
+
492
+ - **Focus on risk**: Cover high-impact scenarios, skip obvious validations
493
+ - **Be concise**: 3-5 test steps maximum per scenario
494
+ - **Prioritize ruthlessly**: Only CRITICAL and HIGH priority items
495
+ - **Target scope**: 15-30 scenarios for typical features, 30-50 for complex products
496
+ - **Clear outcomes**: One measurable result per scenario
497
+
498
+ # Special Instructions
499
+
500
+ ## Brevity Rules
501
+ - **Omit** detailed preconditions unless critical
502
+ - **Omit** low-priority scenarios entirely
503
+ - **Omit** obvious test data specifications
504
+ - **Omit** exhaustive device/browser matrices (note key platforms only)
505
+ - **Combine** related scenarios where logical
506
+
507
+ ## Prioritization (Strict)
508
+ Include only:
509
+ - **CRITICAL**: Core functionality, security, data integrity
510
+ - **HIGH**: Primary user flows, high-risk integrations
511
+ - **OMIT**: Medium/Low priority items
512
+
513
+ ## Smart Assumptions
514
+ - Standard validation (email format, required fields) is assumed tested
515
+ - Basic UI functionality is assumed working
516
+ - Focus on **what could break** or **what's unique** to this feature
517
+
518
+ # Output Delivery
519
+
520
+ Generate a **concise** testing document (targeting 50-150 lines for simple features, 150-300 for complex features). Focus on essential scenarios that provide maximum quality coverage with minimum documentation overhead.
521
+
522
+ ## WORKFLOW STEPS
523
+ 1. Read the user's input (PRD or requirements)
524
+ 2. Generate a unique, URL-friendly slug from the feature name (lowercase, hyphen-separated)
525
+ 3. Create the directory \`prompter/<slug>/\` if it doesn't exist
526
+ 4. Generate the complete QA test scenarios following all requirements above
527
+ 5. Save the test scenarios to \`prompter/<slug>/qa-test-scenarios.md\`
528
+ 6. Report the saved file path
529
+
530
+ ## REFERENCE
531
+ - Read \`prompter/project.md\` for project context if needed`;
43
532
  export const slashCommandBodies = {
44
- enhance: enhanceWorkflow
533
+ enhance: enhanceWorkflow,
534
+ 'prd-generator': prdGeneratorWorkflow,
535
+ 'epic-single': epicSingleWorkflow,
536
+ 'story-single': storySingleWorkflow,
537
+ 'qa-test-scenario': qaTestScenarioWorkflow
45
538
  };
46
539
  export function getSlashCommandBody(id) {
47
540
  return slashCommandBodies[id];
@@ -1 +1 @@
1
- {"version":3,"file":"slash-command-templates.js","sourceRoot":"","sources":["../../../src/core/templates/slash-command-templates.ts"],"names":[],"mappings":"AAEA,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mEAyC2C,CAAC;AAEpE,MAAM,CAAC,MAAM,kBAAkB,GAAmC;IAC9D,OAAO,EAAE,eAAe;CAC3B,CAAC;AAEF,MAAM,UAAU,mBAAmB,CAAC,EAAkB;IAClD,OAAO,kBAAkB,CAAC,EAAE,CAAC,CAAC;AAClC,CAAC;AAED,MAAM,OAAO,eAAe;IACxB,MAAM,CAAC,mBAAmB,CAAC,EAAkB;QACzC,OAAO,mBAAmB,CAAC,EAAE,CAAC,CAAC;IACnC,CAAC;CACJ"}
1
+ {"version":3,"file":"slash-command-templates.js","sourceRoot":"","sources":["../../../src/core/templates/slash-command-templates.ts"],"names":[],"mappings":"AAEA,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mEAyC2C,CAAC;AAEpE,MAAM,oBAAoB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;6DA6MgC,CAAC;AAE9D,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;6DAyDkC,CAAC;AAE9D,MAAM,mBAAmB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;6DAgFiC,CAAC;AAE9D,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;6DA+I8B,CAAC;AAE9D,MAAM,CAAC,MAAM,kBAAkB,GAAmC;IAC9D,OAAO,EAAE,eAAe;IACxB,eAAe,EAAE,oBAAoB;IACrC,aAAa,EAAE,kBAAkB;IACjC,cAAc,EAAE,mBAAmB;IACnC,kBAAkB,EAAE,sBAAsB;CAC7C,CAAC;AAEF,MAAM,UAAU,mBAAmB,CAAC,EAAkB;IAClD,OAAO,kBAAkB,CAAC,EAAE,CAAC,CAAC;AAClC,CAAC;AAED,MAAM,OAAO,eAAe;IACxB,MAAM,CAAC,mBAAmB,CAAC,EAAkB;QACzC,OAAO,mBAAmB,CAAC,EAAE,CAAC,CAAC;IACnC,CAAC;CACJ"}
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@dedesfr/prompter",
3
- "version": "0.1.0",
3
+ "version": "0.3.0",
4
4
  "description": "Enhance prompts directly in your AI coding workflow",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",
@@ -0,0 +1,47 @@
1
+ Your job is to take a user requirement and structure it into **a single, well-defined Jira Epic**.
2
+
3
+ ### Input
4
+ {USER_REQUIREMENT}
5
+
6
+ ### Output Rules
7
+ - Use **Markdown format only**
8
+ - Focus on defining **one Epic** that captures the main capability or user workflow
9
+ - Title must be **business-focused**, not technical
10
+ - The Epic should represent a cohesive, deliverable outcome
11
+
12
+ ### Output Structure
13
+
14
+ ## 🧠 Epic: {Epic Title}
15
+
16
+ ### 🎯 Epic Goal
17
+ We need to {MAIN OBJECTIVE} in order for {TARGET USER} to {EXPECTED VALUE}
18
+
19
+ ### 🚀 Definition of Done
20
+ - DoD1
21
+ - DoD2
22
+ - DoD3
23
+ (add more if needed)
24
+
25
+ ### 📌 High-Level Scope (Included)
26
+ - Scope item 1
27
+ - Scope item 2
28
+ - Scope item 3
29
+
30
+ ### ❌ Out of Scope
31
+ - OOS item 1
32
+ - OOS item 2
33
+
34
+ ### 📁 Deliverables
35
+ - Deliverable 1
36
+ - Deliverable 2
37
+
38
+ ### 🧩 Dependencies
39
+ - Dependency 1 (TBD if unknown)
40
+
41
+ ### ⚠️ Risks / Assumptions
42
+ - Risk or assumption 1
43
+ - Risk or assumption 2
44
+
45
+ ### 🎯 Success Metrics
46
+ - Metric 1
47
+ - Metric 2