@dedesfr/prompter 0.6.0 → 0.6.1

package/dist/core/configurators/slash/opencode.js.map

@@ -1 +1 @@
-{"version":3,"file":"opencode.js","sourceRoot":"","sources":["../../../../src/core/configurators/slash/opencode.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,wBAAwB,EAAE,MAAM,WAAW,CAAC;AAGrD,MAAM,UAAU,GAAmC;IAC/C,OAAO,EAAE,uCAAuC;IAChD,eAAe,EAAE,oCAAoC;IACrD,qBAAqB,EAAE,0CAA0C;IACjE,eAAe,EAAE,oCAAoC;IACrD,aAAa,EAAE,kCAAkC;IACjD,cAAc,EAAE,mCAAmC;IACnD,kBAAkB,EAAE,uCAAuC;IAC3D,eAAe,EAAE,oCAAoC;IACrD,cAAc,EAAE,mCAAmC;CACtD,CAAC;AAEF,MAAM,YAAY,GAAmC;IACjD,OAAO,EAAE,0DAA0D;IACnE,eAAe,EAAE,8DAA8D;IAC/E,qBAAqB,EAAE,mEAAmE;IAC1F,eAAe,EAAE,4DAA4D;IAC7E,aAAa,EAAE,0CAA0C;IACzD,cAAc,EAAE,qDAAqD;IACrE,kBAAkB,EAAE,6CAA6C;IACjE,eAAe,EAAE,mEAAmE;IACpF,cAAc,EAAE,mFAAmF;CACtG,CAAC;AAEF,MAAM,OAAO,oBAAqB,SAAQ,wBAAwB;IACrD,MAAM,GAAG,UAAU,CAAC;IACpB,WAAW,GAAG,IAAI,CAAC;IAElB,eAAe,CAAC,EAAkB;QACxC,OAAO,UAAU,CAAC,EAAE,CAAC,CAAC;IAC1B,CAAC;IAES,cAAc,CAAC,EAAkB;QACvC,MAAM,WAAW,GAAG,YAAY,CAAC,EAAE,CAAC,CAAC;QACrC,OAAO,qBAAqB,WAAW,OAAO,CAAC;IACnD,CAAC;CACJ"}
+{"version":3,"file":"opencode.js","sourceRoot":"","sources":["../../../../src/core/configurators/slash/opencode.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,wBAAwB,EAAE,MAAM,WAAW,CAAC;AAGrD,MAAM,UAAU,GAAmC;IAC/C,OAAO,EAAE,uCAAuC;IAChD,eAAe,EAAE,oCAAoC;IACrD,qBAAqB,EAAE,0CAA0C;IACjE,eAAe,EAAE,oCAAoC;IACrD,aAAa,EAAE,kCAAkC;IACjD,cAAc,EAAE,mCAAmC;IACnD,kBAAkB,EAAE,uCAAuC;IAC3D,eAAe,EAAE,oCAAoC;IACrD,cAAc,EAAE,mCAAmC;IACnD,wBAAwB,EAAE,6CAA6C;IACvE,eAAe,EAAE,oCAAoC;IACrD,eAAe,EAAE,oCAAoC;IACrD,eAAe,EAAE,oCAAoC;IACrD,oBAAoB,EAAE,yCAAyC;IAC/D,qBAAqB,EAAE,0CAA0C;CACpE,CAAC;AAEF,MAAM,YAAY,GAAmC;IACjD,OAAO,EAAE,0DAA0D;IACnE,eAAe,EAAE,8DAA8D;IAC/E,qBAAqB,EAAE,mEAAmE;IAC1F,eAAe,EAAE,4DAA4D;IAC7E,aAAa,EAAE,0CAA0C;IACzD,cAAc,EAAE,qDAAqD;IACrE,kBAAkB,EAAE,6CAA6C;IACjE,eAAe,EAAE,mEAAmE;IACpF,cAAc,EAAE,mFAAmF;IACnG,wBAAwB,EAAE,iDAAiD;IAC3E,eAAe,EAAE,+CAA+C;IAChE,eAAe,EAAE,qDAAqD;IACtE,eAAe,EAAE,kDAAkD;IACnE,oBAAoB,EAAE,oDAAoD;IAC1E,qBAAqB,EAAE,gDAAgD;CAC1E,CAAC;AAEF,MAAM,OAAO,oBAAqB,SAAQ,wBAAwB;IACrD,MAAM,GAAG,UAAU,CAAC;IACpB,WAAW,GAAG,IAAI,CAAC;IAElB,eAAe,CAAC,EAAkB;QACxC,OAAO,UAAU,CAAC,EAAE,CAAC,CAAC;IAC1B,CAAC;IAES,cAAc,CAAC,EAAkB;QACvC,MAAM,WAAW,GAAG,YAAY,CAAC,EAAE,CAAC,CAAC;QACrC,OAAO,qBAAqB,WAAW,OAAO,CAAC;IACnD,CAAC;CACJ"}

package/dist/core/prompt-templates.d.ts

@@ -6,5 +6,11 @@ export declare const PRODUCT_BRIEF_TEMPLATE = "# Product Brief (Executive Summar
 export declare const QA_TEST_SCENARIO_TEMPLATE = "# Role & Expertise\nYou 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.\n\n# Context\nYou 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.\n\n# Primary Objective\nCreate 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.\n\n# Process\n\n## 1. PRD Analysis (Focus on Essentials)\n- Identify **core features** and **critical user flows**\n- Extract **must-have acceptance criteria** only\n- Note **high-risk areas** and integration points\n- Skip minor edge cases and cosmetic details\n\n## 2. Test Scenario Generation (Strategic Coverage)\n\nGenerate only:\n\n**Critical Happy Path** (2-3 scenarios per feature)\n- Primary user journey validation\n- Core functionality verification\n\n**High-Risk Edge Cases** (1-2 per feature)\n- Data boundary conditions\n- Error states that impact functionality\n- Integration failure points\n\n**Key Quality Checks** (as needed)\n- Performance bottlenecks\n- Security vulnerabilities\n- Critical usability issues\n\n**Skip:** Low-priority edge cases, cosmetic issues, obvious validations\n\n## 3. Scenario Documentation (Streamlined Format)\nEach scenario includes only:\n- **ID & Story**: TS-[#] | [Feature Name]\n- **Type**: Functional, Edge Case, Performance, Security\n- **Priority**: CRITICAL or HIGH only\n- **Test Steps**: 3-5 key actions\n- **Expected Result**: One clear outcome\n- **Notes**: Only if critical context needed\n\n# Input Specifications\n- **PRD Document**: User stories, features, acceptance criteria\n- **Format**: Any structured or narrative format\n- **Focus**: Extract essential requirements only\n\n# Output Requirements\n\n## Concise Format Structure\n\n### Test Coverage Summary (Compact)\n\n## Test Coverage Overview\n- **Features Covered**: [#] core features\n- **Total Scenarios**: [X] (targeting 20-30 scenarios max for typical features)\n- **Critical Path**: [X] scenarios\n- **High-Risk Edge Cases**: [X] scenarios\n- **Priority Distribution**: CRITICAL: [X] | HIGH: [X]\n\n---\n\n### Essential Test Scenarios\n\n| ID | Feature | Scenario | Type | Priority | Steps | Expected Result |\n|----|---------|----------|------|----------|-------|-----------------|\n| TS-01 | [Name] | [Brief description] | Functional | CRITICAL | 1. [Action]<br>2. [Action]<br>3. [Verify] | [Clear outcome] |\n| TS-02 | [Name] | [Brief description] | Edge Case | HIGH | 1. [Action]<br>2. [Action]<br>3. [Verify] | [Clear outcome] |\n\n---\n\n### Performance & Environment Notes (If Applicable)\n\n**Performance Criteria:**\n- [Key metric]: [Threshold]\n- [Key metric]: [Threshold]\n\n**Test Environments:**\n- [Platform 1]: [Critical versions only]\n- [Platform 2]: [Critical versions only]\n\n---\n\n### Test Data Requirements (Essential Only)\n\n- [Critical data type]: [Min specification]\n- [Edge case data]: [Key examples]\n\n---\n\n### Execution Notes\n\n**Prerequisites:**\n- [Essential setup only]\n\n**Key Dependencies:**\n- [Critical blockers only]\n\n# Quality Standards\n\n- **Focus on risk**: Cover high-impact scenarios, skip obvious validations\n- **Be concise**: 3-5 test steps maximum per scenario\n- **Prioritize ruthlessly**: Only CRITICAL and HIGH priority items\n- **Target scope**: 15-30 scenarios for typical features, 30-50 for complex products\n- **Clear outcomes**: One measurable result per scenario\n\n# Special Instructions\n\n## Brevity Rules\n- **Omit** detailed preconditions unless critical\n- **Omit** low-priority scenarios entirely\n- **Omit** obvious test data specifications\n- **Omit** exhaustive device/browser matrices (note key platforms only)\n- **Combine** related scenarios where logical\n\n## Prioritization (Strict)\nInclude only:\n- **CRITICAL**: Core functionality, security, data integrity\n- **HIGH**: Primary user flows, high-risk integrations\n- **OMIT**: Medium/Low priority items\n\n## Smart Assumptions\n- Standard validation (email format, required fields) is assumed tested\n- Basic UI functionality is assumed working\n- Focus on **what could break** or **what's unique** to this feature\n\n# Output Delivery\n\nGenerate 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.\n";
 export declare const SKILL_CREATOR_TEMPLATE = "# Skill Creator\n\nThis skill provides guidance for creating effective skills.\n\n## About Skills\n\nSkills are modular, self-contained packages that extend Claude's capabilities by providing\nspecialized knowledge, workflows, and tools. Think of them as \"onboarding guides\" for specific\ndomains or tasks\u2014they transform Claude from a general-purpose agent into a specialized agent\nequipped with procedural knowledge that no model can fully possess.\n\n### What Skills Provide\n\n1. Specialized workflows - Multi-step procedures for specific domains\n2. Tool integrations - Instructions for working with specific file formats or APIs\n3. Domain expertise - Company-specific knowledge, schemas, business logic\n4. Bundled resources - Scripts, references, and assets for complex and repetitive tasks\n\n## Core Principles\n\n### Concise is Key\n\nThe context window is a public good. Skills share the context window with everything else Claude needs: system prompt, conversation history, other Skills' metadata, and the actual user request.\n\n**Default assumption: Claude is already very smart.** Only add context Claude doesn't already have. Challenge each piece of information: \"Does Claude really need this explanation?\" and \"Does this paragraph justify its token cost?\"\n\nPrefer concise examples over verbose explanations.\n\n### Set Appropriate Degrees of Freedom\n\nMatch the level of specificity to the task's fragility and variability:\n\n**High freedom (text-based instructions)**: Use when multiple approaches are valid, decisions depend on context, or heuristics guide the approach.\n\n**Medium freedom (pseudocode or scripts with parameters)**: Use when a preferred pattern exists, some variation is acceptable, or configuration affects behavior.\n\n**Low freedom (specific scripts, few parameters)**: Use when operations are fragile and error-prone, consistency is critical, or a specific sequence must be followed.\n\nThink of Claude as exploring a path: a narrow bridge with cliffs needs specific guardrails (low freedom), while an open field allows many routes (high freedom).\n\n### Anatomy of a Skill\n\nEvery skill consists of a required SKILL.md file and optional bundled resources:\n\n```\nskill-name/\n\u251C\u2500\u2500 SKILL.md (required)\n\u2502   \u251C\u2500\u2500 YAML frontmatter metadata (required)\n\u2502   \u2502   \u251C\u2500\u2500 name: (required)\n\u2502   \u2502   \u2514\u2500\u2500 description: (required)\n\u2502   \u2514\u2500\u2500 Markdown instructions (required)\n\u2514\u2500\u2500 Bundled Resources (optional)\n    \u251C\u2500\u2500 scripts/          - Executable code (Python/Bash/etc.)\n    \u251C\u2500\u2500 references/       - Documentation intended to be loaded into context as needed\n    \u2514\u2500\u2500 assets/           - Files used in output (templates, icons, fonts, etc.)\n```\n\n#### SKILL.md (required)\n\nEvery SKILL.md consists of:\n\n- **Frontmatter** (YAML): Contains `name` and `description` fields. These are the only fields that Claude reads to determine when the skill gets used, thus it is very important to be clear and comprehensive in describing what the skill is, and when it should be used.\n- **Body** (Markdown): Instructions and guidance for using the skill. Only loaded AFTER the skill triggers (if at all).\n\n#### Bundled Resources (optional)\n\n##### Scripts (`scripts/`)\n\nExecutable code (Python/Bash/etc.) for tasks that require deterministic reliability or are repeatedly rewritten.\n\n- **When to include**: When the same code is being rewritten repeatedly or deterministic reliability is needed\n- **Example**: `scripts/rotate_pdf.py` for PDF rotation tasks\n- **Benefits**: Token efficient, deterministic, may be executed without loading into context\n- **Note**: Scripts may still need to be read by Claude for patching or environment-specific adjustments\n\n##### References (`references/`)\n\nDocumentation and reference material intended to be loaded as needed into context to inform Claude's process and thinking.\n\n- **When to include**: For documentation that Claude should reference while working\n- **Examples**: `references/finance.md` for financial schemas, `references/mnda.md` for company NDA template, `references/policies.md` for company policies, `references/api_docs.md` for API specifications\n- **Use cases**: Database schemas, API documentation, domain knowledge, company policies, detailed workflow guides\n- **Benefits**: Keeps SKILL.md lean, loaded only when Claude determines it's needed\n- **Best practice**: If files are large (>10k words), include grep search patterns in SKILL.md\n- **Avoid duplication**: Information should live in either SKILL.md or references files, not both. Prefer references files for detailed information unless it's truly core to the skill\u2014this keeps SKILL.md lean while making information discoverable without hogging the context window. Keep only essential procedural instructions and workflow guidance in SKILL.md; move detailed reference material, schemas, and examples to references files.\n\n##### Assets (`assets/`)\n\nFiles not intended to be loaded into context, but rather used within the output Claude produces.\n\n- **When to include**: When the skill needs files that will be used in the final output\n- **Examples**: `assets/logo.png` for brand assets, `assets/slides.pptx` for PowerPoint templates, `assets/frontend-template/` for HTML/React boilerplate, `assets/font.ttf` for typography\n- **Use cases**: Templates, images, icons, boilerplate code, fonts, sample documents that get copied or modified\n- **Benefits**: Separates output resources from documentation, enables Claude to use files without loading them into context\n\n#### What to Not Include in a Skill\n\nA skill should only contain essential files that directly support its functionality. do NOT create extraneous documentation or auxiliary files, including:\n\n- README.md\n- INSTALLATION_GUIDE.md\n- QUICK_REFERENCE.md\n- CHANGELOG.md\n- etc.\n\nThe skill should only contain the information needed for an AI agent to do the job at hand. It should not contain auxilary context about the process that went into creating it, setup and testing procedures, user-facing documentation, etc. Creating additional documentation files just adds clutter and confusion.\n\n### Progressive Disclosure Design Principle\n\nSkills use a three-level loading system to manage context efficiently:\n\n1. **Metadata (name + description)** - Always in context (~100 words)\n2. **SKILL.md body** - When skill triggers (<5k words)\n3. **Bundled resources** - As needed by Claude (Unlimited because scripts can be executed without reading into context window)\n\n#### Progressive Disclosure Patterns\n\nKeep SKILL.md body to the essentials and under 500 lines to minimize context bloat. Split content into separate files when approaching this limit. When splitting out content into other files, it is very important to reference them from SKILL.md and describe clearly when to read them, to ensure the reader of the skill knows they exist and when to use them.\n\n**Key principle:** When a skill supports multiple variations, frameworks, or options, keep only the core workflow and selection guidance in SKILL.md. Move variant-specific details (patterns, examples, configuration) into separate reference files.\n\n**Pattern 1: High-level guide with references**\n\n```markdown\n# PDF Processing\n\n## Quick start\n\nExtract text with pdfplumber:\n[code example]\n\n## Advanced features\n\n- **Form filling**: See [FORMS.md](FORMS.md) for complete guide\n- **API reference**: See [REFERENCE.md](REFERENCE.md) for all methods\n- **Examples**: See [EXAMPLES.md](EXAMPLES.md) for common patterns\n```\n\nClaude loads FORMS.md, REFERENCE.md, or EXAMPLES.md only when needed.\n\n**Pattern 2: Domain-specific organization**\n\nFor Skills with multiple domains, organize content by domain to avoid loading irrelevant context:\n\n```\nbigquery-skill/\n\u251C\u2500\u2500 SKILL.md (overview and navigation)\n\u2514\u2500\u2500 reference/\n    \u251C\u2500\u2500 finance.md (revenue, billing metrics)\n    \u251C\u2500\u2500 sales.md (opportunities, pipeline)\n    \u251C\u2500\u2500 product.md (API usage, features)\n    \u2514\u2500\u2500 marketing.md (campaigns, attribution)\n```\n\nWhen a user asks about sales metrics, Claude only reads sales.md.\n\nSimilarly, for skills supporting multiple frameworks or variants, organize by variant:\n\n```\ncloud-deploy/\n\u251C\u2500\u2500 SKILL.md (workflow + provider selection)\n\u2514\u2500\u2500 references/\n    \u251C\u2500\u2500 aws.md (AWS deployment patterns)\n    \u251C\u2500\u2500 gcp.md (GCP deployment patterns)\n    \u2514\u2500\u2500 azure.md (Azure deployment patterns)\n```\n\nWhen the user chooses AWS, Claude only reads aws.md.\n\n**Pattern 3: Conditional details**\n\nShow basic content, link to advanced content:\n\n```markdown\n# DOCX Processing\n\n## Creating documents\n\nUse docx-js for new documents. See [DOCX-JS.md](DOCX-JS.md).\n\n## Editing documents\n\nFor simple edits, modify the XML directly.\n\n**For tracked changes**: See [REDLINING.md](REDLINING.md)\n**For OOXML details**: See [OOXML.md](OOXML.md)\n```\n\nClaude reads REDLINING.md or OOXML.md only when the user needs those features.\n\n**Important guidelines:**\n\n- **Avoid deeply nested references** - Keep references one level deep from SKILL.md. All reference files should link directly from SKILL.md.\n- **Structure longer reference files** - For files longer than 100 lines, include a table of contents at the top so Claude can see the full scope when previewing.\n\n## Skill Creation Process\n\nSkill creation involves these steps:\n\n1. Understand the skill with concrete examples\n2. Plan reusable skill contents (scripts, references, assets)\n3. Initialize the skill (run init_skill.py)\n4. Edit the skill (implement resources and write SKILL.md)\n5. Package the skill (run package_skill.py)\n6. Iterate based on real usage\n\nFollow these steps in order, skipping only if there is a clear reason why they are not applicable.\n\n### Step 1: Understanding the Skill with Concrete Examples\n\nSkip this step only when the skill's usage patterns are already clearly understood. It remains valuable even when working with an existing skill.\n\nTo create an effective skill, clearly understand concrete examples of how the skill will be used. This understanding can come from either direct user examples or generated examples that are validated with user feedback.\n\nFor example, when building an image-editor skill, relevant questions include:\n\n- \"What functionality should the image-editor skill support? Editing, rotating, anything else?\"\n- \"Can you give some examples of how this skill would be used?\"\n- \"I can imagine users asking for things like 'Remove the red-eye from this image' or 'Rotate this image'. Are there other ways you imagine this skill being used?\"\n- \"What would a user say that should trigger this skill?\"\n\nTo avoid overwhelming users, avoid asking too many questions in a single message. Start with the most important questions and follow up as needed for better effectiveness.\n\nConclude this step when there is a clear sense of the functionality the skill should support.\n\n### Step 2: Planning the Reusable Skill Contents\n\nTo turn concrete examples into an effective skill, analyze each example by:\n\n1. Considering how to execute on the example from scratch\n2. Identifying what scripts, references, and assets would be helpful when executing these workflows repeatedly\n\nExample: When building a `pdf-editor` skill to handle queries like \"Help me rotate this PDF,\" the analysis shows:\n\n1. Rotating a PDF requires re-writing the same code each time\n2. A `scripts/rotate_pdf.py` script would be helpful to store in the skill\n\nExample: When designing a `frontend-webapp-builder` skill for queries like \"Build me a todo app\" or \"Build me a dashboard to track my steps,\" the analysis shows:\n\n1. Writing a frontend webapp requires the same boilerplate HTML/React each time\n2. An `assets/hello-world/` template containing the boilerplate HTML/React project files would be helpful to store in the skill\n\nExample: When building a `big-query` skill to handle queries like \"How many users have logged in today?\" the analysis shows:\n\n1. Querying BigQuery requires re-discovering the table schemas and relationships each time\n2. A `references/schema.md` file documenting the table schemas would be helpful to store in the skill\n\nTo establish the skill's contents, analyze each concrete example to create a list of the reusable resources to include: scripts, references, and assets.\n\n### Step 3: Initializing the Skill\n\nAt this point, it is time to actually create the skill.\n\nSkip this step only if the skill being developed already exists, and iteration or packaging is needed. In this case, continue to the next step.\n\nWhen creating a new skill from scratch, always run the `init_skill.py` script. The script conveniently generates a new template skill directory that automatically includes everything a skill requires, making the skill creation process much more efficient and reliable.\n\nUsage:\n\n```bash\nscripts/init_skill.py <skill-name> --path <output-directory>\n```\n\nThe script:\n\n- Creates the skill directory at the specified path\n- Generates a SKILL.md template with proper frontmatter and TODO placeholders\n- Creates example resource directories: `scripts/`, `references/`, and `assets/`\n- Adds example files in each directory that can be customized or deleted\n\nAfter initialization, customize or remove the generated SKILL.md and example files as needed.\n\n### Step 4: Edit the Skill\n\nWhen editing the (newly-generated or existing) skill, remember that the skill is being created for another instance of Claude to use. Include information that would be beneficial and non-obvious to Claude. Consider what procedural knowledge, domain-specific details, or reusable assets would help another Claude instance execute these tasks more effectively.\n\n#### Learn Proven Design Patterns\n\nConsult these helpful guides based on your skill's needs:\n\n- **Multi-step processes**: See references/workflows.md for sequential workflows and conditional logic\n- **Specific output formats or quality standards**: See references/output-patterns.md for template and example patterns\n\nThese files contain established best practices for effective skill design.\n\n#### Start with Reusable Skill Contents\n\nTo begin implementation, start with the reusable resources identified above: `scripts/`, `references/`, and `assets/` files. Note that this step may require user input. For example, when implementing a `brand-guidelines` skill, the user may need to provide brand assets or templates to store in `assets/`, or documentation to store in `references/`.\n\nAdded scripts must be tested by actually running them to ensure there are no bugs and that the output matches what is expected. If there are many similar scripts, only a representative sample needs to be tested to ensure confidence that they all work while balancing time to completion.\n\nAny example files and directories not needed for the skill should be deleted. The initialization script creates example files in `scripts/`, `references/`, and `assets/` to demonstrate structure, but most skills won't need all of them.\n\n#### Update SKILL.md\n\n**Writing Guidelines:** Always use imperative/infinitive form.\n\n##### Frontmatter\n\nWrite the YAML frontmatter with `name` and `description`:\n\n- `name`: The skill name\n- `description`: This is the primary triggering mechanism for your skill, and helps Claude understand when to use the skill.\n  - Include both what the Skill does and specific triggers/contexts for when to use it.\n  - Include all \"when to use\" information here - Not in the body. The body is only loaded after triggering, so \"When to Use This Skill\" sections in the body are not helpful to Claude.\n  - Example description for a `docx` skill: \"Comprehensive document creation, editing, and analysis with support for tracked changes, comments, formatting preservation, and text extraction. Use when Claude needs to work with professional documents (.docx files) for: (1) Creating new documents, (2) Modifying or editing content, (3) Working with tracked changes, (4) Adding comments, or any other document tasks\"\n\nDo not include any other fields in YAML frontmatter.\n\n##### Body\n\nWrite instructions for using the skill and its bundled resources.\n\n### Step 5: Packaging a Skill\n\nOnce development of the skill is complete, it must be packaged into a distributable .skill file that gets shared with the user. The packaging process automatically validates the skill first to ensure it meets all requirements:\n\n```bash\nscripts/package_skill.py <path/to/skill-folder>\n```\n\nOptional output directory specification:\n\n```bash\nscripts/package_skill.py <path/to/skill-folder> ./dist\n```\n\nThe packaging script will:\n\n1. **Validate** the skill automatically, checking:\n\n   - YAML frontmatter format and required fields\n   - Skill naming conventions and directory structure\n   - Description completeness and quality\n   - File organization and resource references\n\n2. **Package** the skill if validation passes, creating a .skill file named after the skill (e.g., `my-skill.skill`) that includes all files and maintains the proper directory structure for distribution. The .skill file is a zip file with a .skill extension.\n\nIf validation fails, the script will report the errors and exit without creating a package. Fix any validation errors and run the packaging command again.\n\n### Step 6: Iterate\n\nAfter testing the skill, users may request improvements. Often this happens right after using the skill, with fresh context of how the skill performed.\n\n**Iteration workflow:**\n\n1. Use the skill on real tasks\n2. Notice struggles or inefficiencies\n3. Identify how SKILL.md or bundled resources should be updated\n4. Implement changes and test again\n";
 export declare const STORY_SINGLE_TEMPLATE = "### \u2705 **Prompt: Generate a Single Jira Story from QA Prompt**\n\nYou are a **Jira expert, senior product manager, and QA analyst**.\n\nYour 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.\n\n---\n\n### \uD83D\uDD3D **Input**\n\n```\n{QA_TEXT}\n```\n\n---\n\n### \uD83D\uDD3C **Output Rules**\n\n* Use **Markdown only**\n* Produce **ONE (1) User Story only**\n* Must be written from **end-user perspective**\n* Title must be **clear and non-technical**\n* Story must be **independently deliverable and testable**\n* Rewrite unclear or fragmented input into a **clean and business-focused requirement**\n* If information is missing, mark it **TBD** (do NOT assume)\n\n---\n\n### \uD83E\uDDF1 **Story Structure**\n\n```\n## \uD83E\uDDFE Story: {Story Title}\n\n### \uD83E\uDDD1 As a {USER ROLE},\nI want to {USER INTENT}\nso that I can {BUSINESS VALUE}\n\n### \uD83D\uDD28 Acceptance Criteria (BDD Format)\n- **Given** {context}\n- **When** {action}\n- **Then** {expected result}\n\n(Add 4\u20138 acceptance criteria)\n\n### \uD83D\uDCCC Expected Result\n- Bullet points describing what success looks like\n\n### \uD83D\uDEAB Non-Goals (if applicable)\n- Bullet points of what is explicitly NOT included\n\n### \uD83D\uDDD2\uFE0F Notes (optional)\n- Clarifications / constraints / dependencies / edge cases\n```\n\n---\n\n### \u26A0\uFE0F Validation Rules Before Generating\n\nThe story must:\n\n* Focus on **one user outcome only**\n* Avoid **technical solutioning** (no APIs, tables, database fields, component names)\n* Avoid **phrases like \"fix bug\", \"backend update\", \"add field X\"**\n* Convert QA language into **business language**\n\n---\n\n### \uD83C\uDFC1 Final Output\n\nReturn **ONLY the completed story in Markdown**, nothing else.\n";
+export declare const API_CONTRACT_GENERATOR_TEMPLATE = "# API Contract Generator Prompt\n\n# Role & Expertise\nYou are a Senior API Architect and Technical Documentation Specialist with extensive experience in RESTful API design, OpenAPI/Swagger specifications, and translating business requirements into precise technical contracts. You have deep expertise in data modeling, HTTP standards, and enterprise integration patterns.\n\n# Context\nYou will receive a Functional Specification Document (FSD) and an Entity Relationship Diagram (ERD) as inputs. Your task is to synthesize these artifacts into a comprehensive API contract that developers can immediately implement. The API contract must accurately reflect the business logic from the FSD while respecting the data structures defined in the ERD.\n\n# Primary Objective\nGenerate a complete, production-ready API contract in OpenAPI 3.0+ specification format that:\n- Covers all functional requirements from the FSD\n- Aligns data models with the ERD entities and relationships\n- Follows REST best practices and industry standards\n- Is immediately usable for development and API documentation tools\n\n# Process\n\n## Phase 1: Analysis\n1. **FSD Extraction**\n   - Identify all user stories/use cases\n   - Extract business rules and validation requirements\n   - Map functional flows to potential API operations\n   - Note authentication/authorization requirements\n   - Identify error scenarios and edge cases\n\n2. **ERD Interpretation**\n   - Catalog all entities and their attributes\n   - Map data types to API schema types\n   - Identify relationships (1:1, 1:N, M:N)\n   - Note required vs optional fields\n   - Identify unique constraints and keys\n\n3. **Cross-Reference Mapping**\n   - Link FSD operations to ERD entities\n   - Identify CRUD requirements per entity\n   - Map business validations to schema constraints\n   - Determine resource hierarchies and nesting\n\n## Phase 2: API Design\n1. **Resource Modeling**\n   - Define REST resources from entities\n   - Establish URL hierarchy and naming\n   - Determine resource representations (full, summary, reference)\n\n2. **Endpoint Definition**\n   - Map operations to HTTP methods\n   - Define path parameters and query parameters\n   - Establish pagination, filtering, sorting patterns\n\n3. **Schema Development**\n   - Create request/response schemas\n   - Define reusable components\n   - Establish enum types from domain values\n\n4. **Security & Error Handling**\n   - Define authentication schemes\n   - Create standard error response formats\n   - Map business errors to HTTP status codes\n\n## Phase 3: Contract Generation\n1. Compile OpenAPI specification\n2. Add comprehensive descriptions\n3. Include request/response examples\n4. Document edge cases and constraints\n\n# Input Specifications\n\n**Functional Specification Document (FSD):**\n- Business requirements and user stories\n- Functional flows and processes\n- Business rules and validations\n- User roles and permissions\n- Expected system behaviors\n\n**Entity Relationship Diagram (ERD):**\n- Entity names and descriptions\n- Attributes with data types\n- Primary and foreign keys\n- Relationship cardinalities\n- Constraints and indexes\n\n# Output Requirements\n\n**Format:** OpenAPI 3.0+ YAML specification\n\n**Required Sections:**\n\n```yaml\nopenapi: 3.0.x\ninfo:\n  title: [API Name]\n  description: [Comprehensive API description]\n  version: [Version]\n  \nservers:\n  - url: [Base URL patterns]\n\ntags:\n  - [Logical groupings of endpoints]\n\npaths:\n  [All endpoints with full specifications]\n\ncomponents:\n  schemas:\n    [All data models derived from ERD]\n  parameters:\n    [Reusable parameters]\n  responses:\n    [Standard response definitions]\n  securitySchemes:\n    [Authentication methods]\n  examples:\n    [Request/response examples]\n\nsecurity:\n  [Global security requirements]\n```\n\n**Per Endpoint Requirements:**\n- Summary and detailed description\n- Operation ID (for code generation)\n- Tags for grouping\n- All parameters (path, query, header)\n- Request body with schema reference\n- All possible responses (2xx, 4xx, 5xx)\n- Security requirements\n- At least one example per request/response\n\n**Schema Requirements:**\n- All properties with types and descriptions\n- Required fields array\n- Validation constraints (minLength, maxLength, pattern, minimum, maximum, enum)\n- Nullable indicators\n- Example values\n\n# Quality Standards\n\n1. **Completeness**\n   - Every FSD requirement maps to at least one endpoint\n   - Every ERD entity has corresponding schema(s)\n   - All CRUD operations covered where applicable\n\n2. **Consistency**\n   - Uniform naming conventions (camelCase for properties, kebab-case for URLs)\n   - Consistent response structures across endpoints\n   - Standard pagination/filtering patterns\n\n3. **Accuracy**\n   - Data types match ERD definitions\n   - Validations reflect business rules\n   - Relationships properly represented in nested/linked resources\n\n4. **Usability**\n   - Clear, actionable descriptions\n   - Meaningful examples\n   - Logical endpoint organization\n\n5. **Standards Compliance**\n   - Valid OpenAPI 3.0+ syntax\n   - RESTful conventions followed\n   - HTTP semantics correctly applied\n\n# Special Instructions\n\n**Naming Conventions:**\n- Resources: plural nouns (e.g., `/users`, `/orders`)\n- Endpoints: `kebab-case`\n- Schema names: `PascalCase`\n- Properties: `camelCase`\n- Query parameters: `camelCase`\n\n**Standard Patterns to Apply:**\n\n| Operation | Method | Path Pattern | Success Code |\n|-----------|--------|--------------|--------------|\n| List | GET | /resources | 200 |\n| Get One | GET | /resources/{id} | 200 |\n| Create | POST | /resources | 201 |\n| Full Update | PUT | /resources/{id} | 200 |\n| Partial Update | PATCH | /resources/{id} | 200 |\n| Delete | DELETE | /resources/{id} | 204 |\n\n**Pagination Standard:**\n```yaml\nparameters:\n  - name: page\n    in: query\n    schema:\n      type: integer\n      default: 1\n  - name: limit\n    in: query\n    schema:\n      type: integer\n      default: 20\n      maximum: 100\n```\n\n**Error Response Standard:**\n```yaml\nErrorResponse:\n  type: object\n  required:\n    - code\n    - message\n  properties:\n    code:\n      type: string\n    message:\n      type: string\n    details:\n      type: array\n      items:\n        type: object\n        properties:\n          field:\n            type: string\n          issue:\n            type: string\n```\n\n**Relationship Handling:**\n- 1:1 \u2192 Embed or link with reference ID\n- 1:N \u2192 Nested collection endpoint or link array\n- M:N \u2192 Separate join resource or array of references\n\n# Verification Checklist\n\nAfter generating the contract, verify:\n- [ ] All FSD use cases have corresponding endpoints\n- [ ] All ERD entities have schema definitions\n- [ ] All relationships are properly represented\n- [ ] Authentication is defined for protected endpoints\n- [ ] Error responses cover all documented error scenarios\n- [ ] Examples are valid against schemas\n- [ ] Specification validates against OpenAPI 3.0 schema\n";
+export declare const ERD_GENERATOR_TEMPLATE = "# Generated Prompt\n\n# Role & Expertise\nYou are a senior database architect and data modeling specialist with extensive experience in translating business requirements into optimized database designs. You have deep expertise in entity-relationship modeling, normalization theory, and understanding functional specifications across various domains.\n\n# Context\nYou will receive a Functional Specification Document (FSD) that describes system requirements, business processes, user stories, and feature specifications. Your task is to extract all data entities, their attributes, and relationships to produce a comprehensive Entity Relationship Diagram specification.\n\n# Primary Objective\nAnalyze the provided FSD and generate a complete ERD specification that accurately captures all data entities, attributes, relationships, and cardinalities required to support the described functionality.\n\n# Process\n\n## Phase 1: Document Analysis\n1. Read through the entire FSD to understand the system scope\n2. Identify all nouns that represent potential entities (users, products, orders, etc.)\n3. Note all actions and processes that imply relationships between entities\n4. Extract business rules that define constraints and cardinalities\n\n## Phase 2: Entity Identification\n1. List all candidate entities from the document\n2. Eliminate duplicates and synonyms (e.g., \"customer\" and \"client\" may be the same)\n3. Distinguish between entities and attributes (is it a thing or a property of a thing?)\n4. Identify weak entities that depend on other entities for existence\n\n## Phase 3: Attribute Extraction\n1. For each entity, identify all properties mentioned or implied\n2. Determine primary keys (natural or surrogate)\n3. Identify required vs. optional attributes\n4. Note any derived or calculated attributes\n5. Specify data types based on context\n\n## Phase 4: Relationship Mapping\n1. Identify all relationships between entities\n2. Determine cardinality for each relationship (1:1, 1:N, M:N)\n3. Identify participation constraints (mandatory vs. optional)\n4. Name relationships with meaningful verbs\n5. Identify any recursive/self-referencing relationships\n\n## Phase 5: Normalization Review\n1. Verify entities are in at least 3NF\n2. Check for transitive dependencies\n3. Identify any intentional denormalization with justification\n\n# Input Specifications\n- **Document Type:** Functional Specification Document (FSD)\n- **Expected Content:** System overview, user stories, feature descriptions, business rules, workflow descriptions, UI specifications\n- **Format:** Text, markdown, or document content\n\n# Output Requirements\n\n## Section 1: Entity Catalog\n\n| Entity Name | Description | Type | Primary Key |\n|-------------|-------------|------|-------------|\n| [Name] | [Brief description] | [Strong/Weak] | [PK field(s)] |\n\n\n## Section 2: Entity Details\nFor each entity:\n\n### [Entity Name]\n**Description:** [What this entity represents]\n**Type:** Strong Entity / Weak Entity (dependent on: [parent])\n\n**Attributes:**\n| Attribute | Data Type | Constraints | Description |\n|-----------|-----------|-------------|-------------|\n| [name] | [type] | [PK/FK/NOT NULL/UNIQUE] | [description] |\n\n**Business Rules:**\n- [Rule 1]\n- [Rule 2]\n\n## Section 3: Relationship Specifications\n\n| Relationship | Entity A | Entity B | Cardinality | Participation | Description |\n|--------------|----------|----------|-------------|---------------|-------------|\n| [verb phrase] | [Entity] | [Entity] | [1:1/1:N/M:N] | [Total/Partial] | [description] |\n\n\n## Section 4: ERD Notation (Text-Based)\nProvide a PlantUML or Mermaid diagram code that can be rendered:\n\n```\nerDiagram\n    ENTITY1 ||--o{ ENTITY2 : \"relationship\"\n    ENTITY1 {\n        type attribute_name PK\n        type attribute_name\n    }\n```\n\n## Section 5: Design Decisions & Notes\n- Key assumptions made during analysis\n- Alternative modeling options considered\n- Recommendations for implementation\n- Questions or ambiguities requiring clarification\n\n# Quality Standards\n- **Completeness:** All entities implied by the FSD must be captured\n- **Accuracy:** Cardinalities must reflect actual business rules\n- **Clarity:** Entity and relationship names must be self-explanatory\n- **Consistency:** Naming conventions must be uniform throughout\n- **Traceability:** Each entity/relationship should trace back to FSD requirements\n\n# Naming Conventions\n- **Entities:** PascalCase, singular nouns (e.g., `Customer`, `OrderItem`)\n- **Attributes:** snake_case (e.g., `first_name`, `created_at`)\n- **Relationships:** Descriptive verb phrases (e.g., \"places\", \"contains\", \"belongs to\")\n- **Primary Keys:** `id` or `[entity]_id`\n- **Foreign Keys:** `[referenced_entity]_id`\n\n# Special Instructions\n1. If the FSD mentions features without clear data requirements, infer necessary entities\n2. Include audit fields (`created_at`, `updated_at`, `created_by`) for transactional entities\n3. Consider soft delete patterns if deletion is mentioned\n4. Flag any circular dependencies or complex relationships\n5. If user authentication is implied, include standard auth entities (User, Role, Permission)\n6. For any M:N relationships, specify the junction/association entity\n\n# Verification Checklist\nAfter generating the ERD, verify:\n- [ ] Every feature in the FSD can be supported by the data model\n- [ ] All user roles mentioned have corresponding entities or attributes\n- [ ] Workflow states are captured (if applicable)\n- [ ] Reporting requirements can be satisfied by the structure\n- [ ] No orphan entities exist (every entity has at least one relationship)\n\n---\n\n**Now analyze the following Functional Specification Document and generate the complete ERD specification:**\n";
+export declare const FSD_GENERATOR_TEMPLATE = "# Functional Specification Document (FSD) Generator Prompt\n\n# Role & Expertise\nYou are a Senior Technical Business Analyst and Solutions Architect with 15+ years of experience translating Product Requirements Documents into comprehensive Functional Specification Documents. You excel at bridging business vision and technical implementation.\n\n# Context\nYou will receive a Product Requirements Document (PRD) that outlines business objectives, user needs, and high-level product vision. Your task is to transform this into a detailed Functional Specification Document that development teams can use to build the product.\n\n# Primary Objective\nGenerate a complete, implementation-ready Functional Specification Document (FSD) that translates PRD requirements into precise functional specifications, system behaviors, data requirements, and acceptance criteria.\n\n# Process\n1. **Analyze the PRD**\n   - Extract all business requirements and user stories\n   - Identify core features and their priorities\n   - Map user personas to functional needs\n   - Note any constraints, assumptions, and dependencies\n\n2. **Define Functional Requirements**\n   - Convert each PRD item into specific, testable functional requirements\n   - Assign unique identifiers (FR-XXX format)\n   - Establish requirement traceability to PRD sections\n   - Define acceptance criteria for each requirement\n\n3. **Specify System Behavior**\n   - Document user interactions and system responses\n   - Define business rules and validation logic\n   - Specify error handling and edge cases\n   - Detail state transitions where applicable\n\n4. **Design Data Specifications**\n   - Identify data entities and attributes\n   - Define data validation rules\n   - Specify data relationships and constraints\n   - Document data flow between components\n\n5. **Create Interface Specifications**\n   - Define UI functional requirements (not visual design)\n   - Specify API contracts if applicable\n   - Document integration touchpoints\n   - Detail reporting/output requirements\n\n# Input Specifications\n- Product Requirements Document (PRD) in any text format\n- May include: user stories, epics, acceptance criteria, wireframes descriptions, business rules, constraints\n\n# Output Requirements\n\n**Format:** Structured FSD document with clear sections and subsections\n**Style:** Technical but accessible; precise language; no ambiguity\n**Requirement Format:** Each requirement must have ID, description, priority, acceptance criteria, and PRD traceability\n\n## Required FSD Structure:\n\n# Functional Specification Document\n## Document Information\n- Document Title\n- Version\n- Date\n- PRD Reference\n- Author\n- Reviewers/Approvers\n\n## 1. Executive Summary\n[Brief overview of what the system will do functionally]\n\n## 2. Scope\n### 2.1 In Scope\n[Functional boundaries covered by this FSD]\n### 2.2 Out of Scope\n[Explicitly excluded functionality]\n### 2.3 Assumptions\n[Technical and business assumptions]\n### 2.4 Dependencies\n[External systems, teams, or conditions]\n\n## 3. User Roles & Permissions\n| Role | Description | Key Capabilities |\n|------|-------------|------------------|\n[Define each user role and their functional access]\n\n## 4. Functional Requirements\n### 4.1 [Feature/Module Name]\n#### FR-001: [Requirement Title]\n- **Description:** [Detailed functional description]\n- **Priority:** [Must Have / Should Have / Could Have / Won't Have]\n- **PRD Reference:** [Section/Item from PRD]\n- **User Story:** As a [role], I want [capability] so that [benefit]\n- **Business Rules:**\n  - BR-001: [Rule description]\n- **Acceptance Criteria:**\n  - [ ] Given [context], when [action], then [expected result]\n  - [ ] [Additional criteria]\n- **Error Handling:**\n  - [Error condition] \u2192 [System response]\n\n[Repeat for each functional requirement]\n\n## 5. Business Rules Catalog\n| ID | Rule | Applies To | Validation |\n|----|------|------------|------------|\n[Consolidated list of all business rules]\n\n## 6. Data Specifications\n### 6.1 Data Entities\n#### [Entity Name]\n| Field | Type | Required | Validation Rules | Description |\n|-------|------|----------|------------------|-------------|\n\n### 6.2 Data Relationships\n[Entity relationship descriptions or diagram notation]\n\n### 6.3 Data Validation Rules\n[Comprehensive validation logic]\n\n## 7. Interface Specifications\n### 7.1 User Interface Requirements\n[Screen-by-screen functional requirements]\n\n### 7.2 API Specifications (if applicable)\n| Endpoint | Method | Input | Output | Business Logic |\n|----------|--------|-------|--------|----------------|\n\n### 7.3 Integration Requirements\n[Third-party system integration specifications]\n\n## 8. Non-Functional Considerations\n[Performance expectations, security requirements, accessibility needs - as they impact functionality]\n\n## 9. Reporting & Analytics Requirements\n[Functional requirements for reports and dashboards]\n\n## 10. Traceability Matrix\n| PRD Item | FSD Requirement(s) | Priority |\n|----------|-------------------|----------|\n[Map every PRD item to FSD requirements]\n\n## 11. Appendices\n### A. Glossary\n### B. Revision History\n### C. Open Questions/TBD Items\n\n# Quality Standards\n- Every PRD requirement must map to at least one functional specification\n- All requirements must be SMART (Specific, Measurable, Achievable, Relevant, Testable)\n- No ambiguous language (avoid \"should,\" \"might,\" \"could\" - use \"shall,\" \"will,\" \"must\")\n- Each acceptance criterion must be verifiable by QA\n- Business rules must be atomic and non-contradictory\n- Data specifications must cover all functional requirements\n\n# Special Instructions\n- If the PRD is vague on certain aspects, document them in \"Open Questions/TBD Items\"\n- Infer reasonable technical assumptions where PRD is silent, clearly marking them as assumptions\n- Prioritize requirements using MoSCoW method if not specified in PRD\n- Include negative test scenarios in acceptance criteria (what should NOT happen)\n- Flag any PRD inconsistencies or conflicts you identify\n- Use consistent terminology throughout - define terms in glossary\n";
+export declare const TDD_GENERATOR_TEMPLATE = "# Technical Design Document (TDD) Generator Prompt\n\n# Role & Expertise\nYou are a Senior Solutions Architect with 15+ years of experience in enterprise software design, system architecture, and technical documentation. You specialize in translating business requirements into comprehensive technical specifications that development teams can implement directly.\n\n# Context\nYou will receive a Functional Specification Document (FSD) as the primary input, along with supporting artifacts including Entity Relationship Diagrams (ERD), API Contracts, and UI/UX Wireframes. Your task is to synthesize these inputs into a complete Technical Design Document that bridges the gap between business requirements and implementation.\n\n# Primary Objective\nGenerate a comprehensive Technical Design Document (TDD) that provides development teams with all technical specifications, architectural decisions, component designs, and implementation guidance needed to build the system described in the FSD.\n\n# Input Artifacts\n1. **Functional Specification Document (FSD)** - Primary reference for business requirements, user stories, and functional flows\n2. **Entity Relationship Diagram (ERD)** - Database schema, relationships, and data model\n3. **API Contract** - Endpoint specifications, request/response schemas, authentication requirements\n4. **UI/UX Wireframes** - Interface designs, user flows, and interaction patterns\n\n# Processing Approach\n\n## Phase 1: Analysis & Extraction\n1. Parse the FSD to identify:\n   - Core functional requirements\n   - Business rules and constraints\n   - User roles and permissions\n   - Integration points\n   - Non-functional requirements (performance, security, scalability)\n\n2. Analyze the ERD to understand:\n   - Entity definitions and attributes\n   - Relationship cardinalities\n   - Data integrity constraints\n   - Indexing requirements\n\n3. Review API Contract for:\n   - Endpoint inventory\n   - Data transformation requirements\n   - Authentication/authorization flows\n   - Error handling patterns\n\n4. Examine Wireframes to determine:\n   - Component hierarchy\n   - State management needs\n   - Client-side validation rules\n   - User interaction patterns\n\n## Phase 2: Architecture Design\n1. Define system architecture pattern (microservices, monolith, serverless, etc.)\n2. Identify component boundaries and responsibilities\n3. Design data flow and integration patterns\n4. Establish security architecture\n5. Plan scalability and performance strategies\n\n## Phase 3: Document Generation\nSynthesize all analysis into structured TDD sections\n\n# Output Format\n\nGenerate the TDD with the following exact structure:\n\n---\n\n# Technical Design Document\n**Project:** [Extracted from FSD]  \n**Version:** 1.0  \n**Date:** [Current Date]  \n**Author:** [Solutions Architect]  \n**Status:** Draft\n\n---\n\n## 1. Executive Summary\n- Brief overview of the system (2-3 paragraphs)\n- Key technical decisions summary\n- Technology stack overview\n\n## 2. System Architecture\n\n### 2.1 Architecture Overview\n- High-level architecture diagram description\n- Architecture pattern justification\n- Key architectural principles applied\n\n### 2.2 Component Architecture\n| Component | Responsibility | Technology | Dependencies |\n|-----------|---------------|------------|--------------|\n| [Name] | [Description] | [Tech] | [Dependencies] |\n\n### 2.3 Deployment Architecture\n- Environment specifications (Dev, Staging, Production)\n- Infrastructure requirements\n- Containerization/orchestration approach\n\n## 3. Data Architecture\n\n### 3.1 Data Model\n- Entity descriptions with business context\n- Attribute specifications table:\n\n| Entity | Attribute | Type | Constraints | Description |\n|--------|-----------|------|-------------|-------------|\n| [Entity] | [Attr] | [Type] | [Constraints] | [Desc] |\n\n### 3.2 Database Design\n- Database technology selection and justification\n- Schema design decisions\n- Indexing strategy\n- Partitioning/sharding approach (if applicable)\n\n### 3.3 Data Flow\n- Data lifecycle management\n- ETL/data pipeline requirements\n- Caching strategy\n\n## 4. API Design\n\n### 4.1 API Architecture\n- API style (REST, GraphQL, gRPC)\n- Versioning strategy\n- Rate limiting approach\n\n### 4.2 Endpoint Specifications\nFor each endpoint:\n\n**[HTTP Method] [Endpoint Path]**\n- **Purpose:** [Description]\n- **Authentication:** [Required/Optional, Type]\n- **Request:**\n  ```json\n  [Request schema]\n  ```\n- **Response:**\n  ```json\n  [Response schema]\n  ```\n- **Error Codes:** [List with descriptions]\n- **Business Rules:** [Validation and processing rules]\n\n### 4.3 Authentication & Authorization\n- Authentication mechanism\n- Token management\n- Permission model mapping\n\n## 5. Component Design\n\n### 5.1 Backend Services\nFor each service/module:\n\n**[Service Name]**\n- **Responsibility:** [Description]\n- **Interfaces:** [Input/Output]\n- **Dependencies:** [Internal/External]\n- **Key Classes/Functions:**\n  - [Class/Function]: [Purpose]\n- **Design Patterns Applied:** [Patterns]\n\n### 5.2 Frontend Architecture\n- Framework and state management approach\n- Component hierarchy\n- Routing structure\n- Key components mapping to wireframes\n\n| Wireframe Screen | Component(s) | State Requirements | API Calls |\n|------------------|--------------|-------------------|-----------|\n| [Screen] | [Components] | [State] | [APIs] |\n\n### 5.3 Integration Layer\n- External system integrations\n- Message queue design (if applicable)\n- Event-driven components\n\n## 6. Security Design\n\n### 6.1 Security Architecture\n- Security layers overview\n- Threat model summary\n\n### 6.2 Security Controls\n| Control Area | Implementation | Standard/Compliance |\n|--------------|----------------|---------------------|\n| [Area] | [How] | [Standard] |\n\n### 6.3 Data Protection\n- Encryption at rest\n- Encryption in transit\n- PII handling\n- Data masking requirements\n\n## 7. Performance & Scalability\n\n### 7.1 Performance Requirements\n| Metric | Target | Measurement Method |\n|--------|--------|-------------------|\n| [Metric] | [Value] | [How] |\n\n### 7.2 Scalability Design\n- Horizontal scaling approach\n- Load balancing strategy\n- Database scaling plan\n\n### 7.3 Caching Strategy\n- Cache layers\n- Cache invalidation approach\n- Cache key design\n\n## 8. Error Handling & Logging\n\n### 8.1 Error Handling Strategy\n- Error classification\n- Error response format\n- Retry mechanisms\n\n### 8.2 Logging & Monitoring\n- Log levels and standards\n- Structured logging format\n- Monitoring and alerting requirements\n\n## 9. Development Guidelines\n\n### 9.1 Coding Standards\n- Language-specific guidelines\n- Code review requirements\n- Documentation standards\n\n### 9.2 Testing Strategy\n| Test Type | Scope | Coverage Target | Tools |\n|-----------|-------|-----------------|-------|\n| [Type] | [Scope] | [%] | [Tools] |\n\n### 9.3 CI/CD Pipeline\n- Build process\n- Deployment stages\n- Quality gates\n\n## 10. Technical Risks & Mitigations\n\n| Risk | Impact | Probability | Mitigation |\n|------|--------|-------------|------------|\n| [Risk] | High/Med/Low | High/Med/Low | [Strategy] |\n\n## 11. Dependencies & Assumptions\n\n### 11.1 Technical Dependencies\n- Third-party services\n- Libraries and frameworks\n- Infrastructure requirements\n\n### 11.2 Assumptions\n- [List of technical assumptions made]\n\n## 12. Appendices\n\n### Appendix A: Technology Stack\n| Layer | Technology | Version | Justification |\n|-------|------------|---------|---------------|\n| [Layer] | [Tech] | [Ver] | [Why] |\n\n### Appendix B: Glossary\n| Term | Definition |\n|------|------------|\n| [Term] | [Definition] |\n\n### Appendix C: Reference Documents\n- FSD Document Reference\n- ERD Diagram Reference\n- API Contract Reference\n- Wireframe Reference\n\n---\n\n# Quality Standards\n\n1. **Traceability:** Every technical decision must trace back to a functional requirement in the FSD\n2. **Completeness:** All entities from ERD must be addressed; all API endpoints must be detailed\n3. **Consistency:** Naming conventions and patterns must be uniform throughout\n4. **Implementability:** Specifications must be detailed enough for developers to implement without ambiguity\n5. **Maintainability:** Design must consider future extensibility and modification\n\n# Special Instructions\n\n1. **Gap Identification:** If input artifacts have inconsistencies or gaps, document them in a \"Clarification Required\" section\n2. **Technology Inference:** If technology stack isn't specified, recommend appropriate technologies with justification\n3. **Cross-Reference:** Maintain explicit references between TDD sections and source artifacts (e.g., \"Per FSD Section 3.2...\", \"As defined in ERD Entity: User...\")\n4. **Diagrams:** Where visual representation would aid understanding, describe diagrams in detail using text-based formats (ASCII, Mermaid notation)\n5. **Assumptions:** Clearly state all technical assumptions when source documents are ambiguous\n\n# Verification Checklist\nBefore finalizing, verify:\n- [ ] All FSD functional requirements have corresponding technical specifications\n- [ ] All ERD entities are reflected in the data architecture\n- [ ] All API endpoints are fully specified with request/response schemas\n- [ ] All wireframe screens have frontend component mappings\n- [ ] Security considerations address authentication, authorization, and data protection\n- [ ] Non-functional requirements (performance, scalability) are addressed\n- [ ] Technical risks are identified with mitigation strategies\n";
+export declare const TDD_LITE_GENERATOR_TEMPLATE = "# Role & Expertise\nYou are a Senior Technical Architect with 15+ years of experience in enterprise software design, system architecture, and technical documentation. You specialize in producing lean technical design documents that lock critical engineering decisions before development planning.\n\n# Context\nYou will receive a Functional Specification Document (FSD) as the primary input, potentially supplemented by an Entity Relationship Diagram (ERD), API Contract (draft), and UI/UX Wireframes.\n\nYour task is to synthesize these inputs into a **TDD-Lite** that captures only the technical decisions that affect more than one epic or workflow.\n\n# Primary Objective\nGenerate a **TDD-Lite (Lean Technical Design Document)** that locks:\n\n- High-level architecture\n- Module boundaries\n- Workflow implementation strategy\n- Data mutation and consistency rules\n- Background jobs and async rules\n- Caching rules\n- Security and RBAC enforcement points\n- Integration points\n- Technical constraints and invariants\n\nDo NOT generate a full technical specification.\n\n---\n\n# Input Documents (Source of Truth)\n\n1) Functional Specification Document (FSD) \u2014 PRIMARY  \n2) Entity Relationship Diagram (ERD) \u2014 if provided  \n3) API Contract (draft) \u2014 if provided  \n4) UI/UX Wireframes \u2014 optional  \n5) Tech stack assumptions \u2014 optional  \n\n---\n\n# HARD CONSTRAINTS (MUST FOLLOW)\n\n- Do NOT restate PRD, FSD, ERD, API Contract, or Wireframes.\n- Do NOT design UI or list screens.\n- Do NOT list all endpoints or payload schemas.\n- Do NOT define SLAs, performance targets, or observability stacks.\n- Do NOT include implementation phases, timelines, or sprint plans.\n- Do NOT include migration strategies or data retention policies.\n- Do NOT include non-functional requirement tables.\n- Do NOT invent features or workflows not present in FSD.\n\nOnly include decisions that affect **more than one epic or workflow**.\n\n---\n\n# Processing Approach\n\n## Phase 1: Extraction\n- Identify all major workflows from the FSD.\n- Identify all cross-cutting technical concerns (auth, approvals, ledgering, async, caching, integrations).\n- Identify all shared data mutation patterns.\n\n## Phase 2: Synthesis\n- Derive module boundaries.\n- Derive service responsibilities.\n- Derive transaction and consistency rules.\n- Derive async and event usage.\n- Derive caching and security rules.\n\n## Phase 3: Decision Locking\n- Convert the above into explicit technical rules and constraints.\n- Mark assumptions where inputs are missing.\n\n---\n\n# Output Format (STRICT \u2014 FOLLOW EXACTLY)\n\n# Technical Design Document (TDD-Lite)\nProject: {{project_name}}  \nVersion: 0.1  \nDate: {{current_date}}\n\n---\n\n## 1. Architecture Overview\n\n- Frontend: {{framework or N/A}}\n- Backend: {{framework}}\n- Database: {{db}}\n- Cache / Queue: {{redis_or_none}}\n- Storage: {{s3_or_none}}\n- External services: {{if any}}\n\nHigh-level architecture:\n- Bullet list describing component interactions\n- Include a simple Mermaid flowchart\n\n---\n\n## 2. Core Modules & Boundaries\n\nFor each module derived from FSD:\n\n- Module name  \n- Responsibility  \n- What it owns (tables, workflows, jobs)  \n- What it must NOT touch  \n\n---\n\n## 3. Workflow Implementation Notes\n\nFor each major workflow from FSD:\n\n- Workflow name  \n- Service/class responsible  \n- Public methods (create, submit, approve, reject, etc.)  \n- State transitions  \n- Side effects (ledger writes, balance updates, events)  \n- Transaction boundaries  \n\n---\n\n## 4. Data Access Rules (from ERD or inferred)\n\nDefine:\n\n- Which tables are append-only  \n- Which tables are snapshots  \n- Locking rules (SELECT FOR UPDATE, optimistic lock, etc.)  \n- Soft delete rules  \n- Referential integrity rules  \n\nIf ERD is missing, infer and mark as **Inferred**.\n\n---\n\n## 5. Background Jobs & Async Processing\n\nIf any:\n\n- Job name  \n- When it runs  \n- What it does  \n- Idempotency rules  \n- Retry rules  \n\n---\n\n## 6. Caching Rules\n\nDefine:\n\n- What is cached  \n- What must NEVER be cached  \n- TTL rules  \n- Cache busting rules  \n\n---\n\n## 7. Security & RBAC Notes\n\nDefine:\n\n- Role model  \n- Permission enforcement point (backend source of truth)  \n- Workflow-specific role rules (e.g., approval requires Manager)\n\n---\n\n## 8. Integration Points\n\nIf any:\n\n- External system name  \n- Direction (inbound/outbound)  \n- Failure handling rule  \n\n---\n\n## 9. Technical Constraints & Invariants\n\nList rules that must never be violated, e.g.:\n\n- Ledger tables are append-only  \n- Approval actions are idempotent  \n- Stock balance must always equal sum of ledger  \n- Status transitions are one-way  \n\n---\n\n## 10. Open Questions & Assumptions\n\nList:\n\n- Gaps in FSD / ERD / API  \n- Conflicts between documents  \n- Assumptions made to complete this TDD-Lite  \n\n---\n\n# Style & Quality Rules\n\n- Use concise, technical language.\n- Use bullet points, not paragraphs.\n- No fluff, no marketing tone.\n- No repetition of PRD/FSD text.\n- Every section must contain concrete decisions.\n- If information is missing, state an explicit assumption.\n- Never invent new features or workflows.\n\n---\n\n# Self-Verification Checklist\n\nBefore finalizing, verify:\n\n- [ ] Every major workflow from FSD appears in Section 3  \n- [ ] Cross-module decisions appear in Sections 2\u20139  \n- [ ] Async or integrations appear in Sections 5 or 8  \n- [ ] Security rules appear in Section 7  \n- [ ] Data consistency rules appear in Section 4  \n- [ ] Constraints appear in Section 9  \n- [ ] Open questions capture real ambiguities  \n- [ ] No UI, API, or SLA specs are included  \n\n---\n\nNow generate the TDD-Lite using the provided input documents.\n";
+export declare const WIREFRAME_GENERATOR_TEMPLATE = "# UI/UX Wireframe Generation Prompt\n\n# Role & Expertise\nYou are a Senior UI/UX Designer and Product Designer with 15+ years of experience creating wireframes for enterprise applications, SaaS platforms, and complex data-driven systems. You have deep expertise in translating technical specifications into intuitive user interfaces, understanding database relationships, and designing for API-driven architectures.\n\n# Context\nYou will be provided with technical documentation that defines a product's requirements, data structure, and system capabilities. Your task is to generate comprehensive UI/UX wireframes that accurately represent the system's functionality while ensuring optimal user experience.\n\n# Input Documents You Will Receive\n1. **Functional Specification Document (FSD)** - Defines features, user stories, business logic\n2. **Entity Relationship Diagram (ERD)** - Shows data models, relationships, cardinality\n3. **Product Requirements Document (PRD)** - Outlines product goals, user personas, success metrics\n4. **API Contract** - Specifies endpoints, request/response structures, available data\n\n# Primary Objective\nGenerate detailed, annotated wireframes that:\n- Accurately represent all specified functionality\n- Reflect the underlying data model and relationships\n- Support all API operations (CRUD, filters, pagination, etc.)\n- Align with user personas and product goals\n- Follow UX best practices and accessibility standards\n\n# Systematic Process\n\n## Phase 1: Document Analysis\n1. **FSD Analysis**\n   - Extract all user stories and acceptance criteria\n   - Identify primary user flows and edge cases\n   - Map business rules that affect UI behavior\n   - Note validation requirements and error states\n\n2. **ERD Analysis**\n   - Identify all entities that require UI representation\n   - Map relationships (1:1, 1:N, M:N) to UI patterns\n   - Determine required form fields from entity attributes\n   - Identify lookup/reference data for dropdowns/selectors\n\n3. **PRD Analysis**\n   - Extract user personas and their primary goals\n   - Identify key user journeys and success metrics\n   - Note priority features vs. nice-to-haves\n   - Understand product positioning and tone\n\n4. **API Contract Analysis**\n   - Map endpoints to screens/components needed\n   - Identify filterable/sortable fields for list views\n   - Determine pagination approach from API structure\n   - Note response data available for display\n   - Identify required vs. optional fields from request schemas\n\n## Phase 2: Information Architecture\n1. Create sitemap/navigation structure\n2. Define screen inventory\n3. Map user flows between screens\n4. Identify shared components\n\n## Phase 3: Wireframe Generation\nFor each screen, produce:\n- Low-fidelity wireframe layout\n- Component specifications\n- Interaction annotations\n- State variations (empty, loading, error, success)\n- Responsive behavior notes\n\n# Output Format\n\n## For Each Screen/View, Provide:\n\n### [Screen Name]\n\n**Purpose:** [What this screen accomplishes]\n\n**User Story Reference:** [Link to relevant FSD user story]\n\n**API Dependencies:**\n- `GET /endpoint` - [What it provides]\n- `POST /endpoint` - [What it submits]\n\n**Wireframe Description:**\n\n```\n\u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502  [Header/Navigation]                                     \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502                                                          \u2502\n\u2502  [Main Content Area - describe layout]                   \u2502\n\u2502                                                          \u2502\n\u2502  \u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510  \u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510  \u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510      \u2502\n\u2502  \u2502  Component  \u2502  \u2502  Component  \u2502  \u2502  Component  \u2502      \u2502\n\u2502  \u2502  Description\u2502  \u2502  Description\u2502  \u2502  Description\u2502      \u2502\n\u2502  \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518  \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518  \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518      \u2502\n\u2502                                                          \u2502\n\u2502  [Secondary Content / Sidebar if applicable]             \u2502\n\u2502                                                          \u2502\n\u251C\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502  [Footer/Actions]                                        \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n```\n\n**Component Specifications:**\n\n| Component | Type | Data Source (ERD/API) | Behavior |\n|-----------|------|----------------------|----------|\n| [Name] | [Type] | [Field/Endpoint] | [Interaction] |\n\n**Form Fields (if applicable):**\n\n| Field | Type | Validation | ERD Attribute | API Field |\n|-------|------|------------|---------------|-----------|\n| [Name] | [Input type] | [Rules] | [Entity.attribute] | [request.field] |\n\n**States:**\n- **Empty State:** [Description + messaging]\n- **Loading State:** [Skeleton/spinner approach]\n- **Error State:** [Error display pattern]\n- **Success State:** [Confirmation pattern]\n\n**Annotations:**\n1. [Interaction note with numbered reference]\n2. [Accessibility consideration]\n3. [Edge case handling]\n\n**Responsive Behavior:**\n- Desktop (1200px+): [Layout]\n- Tablet (768-1199px): [Adjustments]\n- Mobile (<768px): [Mobile-specific layout]\n\n---\n\n## Complete Deliverables Structure\n\n### 1. Executive Summary\n- Product overview\n- Key user personas summary\n- Primary user journeys identified\n- Screen count and complexity assessment\n\n### 2. Information Architecture\n- Sitemap diagram (ASCII or described)\n- Navigation structure\n- User flow diagrams\n\n### 3. Screen Inventory\n| Screen | Priority | Complexity | Related Entities | Key APIs |\n|--------|----------|------------|------------------|----------|\n\n### 4. Wireframes (per screen using format above)\n\n### 5. Component Library\n- Reusable components identified\n- Pattern specifications\n- Usage guidelines\n\n### 6. Interaction Patterns\n- Navigation patterns\n- Form submission flows\n- Error handling patterns\n- Loading state patterns\n\n### 7. Data Display Patterns\n- List/table views (based on ERD collections)\n- Detail views (based on ERD entities)\n- Relationship displays (based on ERD cardinality)\n\n### 8. Traceability Matrix\n| User Story (FSD) | Screen | ERD Entities | API Endpoints |\n|------------------|--------|--------------|---------------|\n\n# Quality Standards\n\n- [ ] Every FSD user story has corresponding UI representation\n- [ ] All ERD entities with user-facing data have display screens\n- [ ] All API endpoints are utilized in appropriate screens\n- [ ] PRD user personas can complete their primary journeys\n- [ ] Forms include all required fields from API contracts\n- [ ] Validation rules from FSD/API are reflected in form specs\n- [ ] Relationships from ERD are navigable in the UI\n- [ ] Empty, loading, and error states defined for all data-dependent views\n- [ ] Responsive behavior specified for all screens\n- [ ] Accessibility considerations noted\n\n# Special Instructions\n\n1. **Data Relationship Handling:**\n   - 1:1 relationships \u2192 Inline display or expandable sections\n   - 1:N relationships \u2192 List/table with detail view\n   - M:N relationships \u2192 Multi-select interfaces or tagging\n\n2. **API-Driven Patterns:**\n   - Pagination \u2192 Match API pagination style (offset/cursor)\n   - Filtering \u2192 Create filter UI for all filterable API params\n   - Sorting \u2192 Enable sort for all sortable API fields\n   - Search \u2192 Include if API supports search endpoints\n\n3. **Form Generation Logic:**\n   - Required API fields \u2192 Required form fields with validation\n   - Optional API fields \u2192 Optional with clear labeling\n   - Enum fields \u2192 Dropdown/radio based on option count\n   - Reference fields (FK) \u2192 Searchable dropdown with API lookup\n\n4. **Error Handling:**\n   - Map API error responses to user-friendly messages\n   - Include inline validation before submission\n   - Provide recovery paths for all error states\n\n5. **Maintain Traceability:**\n   - Reference specific FSD section numbers\n   - Note ERD entity names in component specs\n   - Include API endpoint paths in screen documentation\n\n---\n\n# Begin Analysis\n\nFirst, I will analyze each provided document systematically, then generate the complete wireframe documentation following this structure.\n\n**Please provide:**\n1. Functional Specification Document (FSD)\n2. Entity Relationship Diagram (ERD)\n3. Product Requirements Document (PRD)\n4. API Contract/Specification\n";
 export declare const PROMPT_TEMPLATES: Record<string, string>;
 //# sourceMappingURL=prompt-templates.d.ts.map

package/dist/core/prompt-templates.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"prompt-templates.d.ts","sourceRoot":"","sources":["../../src/core/prompt-templates.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,qBAAqB,29FA6CjC,CAAC;AAEF,eAAO,MAAM,oBAAoB,kjCA+ChC,CAAC;AAEF,eAAO,MAAM,4BAA4B,ioJAoJxC,CAAC;AAEF,eAAO,MAAM,sBAAsB,s4OAmMlC,CAAC;AAEF,eAAO,MAAM,sBAAsB,y0VAiSlC,CAAC;AAEF,eAAO,MAAM,yBAAyB,8sJAqIrC,CAAC;AAEF,eAAO,MAAM,sBAAsB,osjBA8VlC,CAAC;AAEF,eAAO,MAAM,qBAAqB,o2DAsEjC,CAAC;AAGF,eAAO,MAAM,gBAAgB,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CASnD,CAAC"}
+{"version":3,"file":"prompt-templates.d.ts","sourceRoot":"","sources":["../../src/core/prompt-templates.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,qBAAqB,29FA6CjC,CAAC;AAEF,eAAO,MAAM,oBAAoB,kjCA+ChC,CAAC;AAEF,eAAO,MAAM,4BAA4B,ioJAoJxC,CAAC;AAEF,eAAO,MAAM,sBAAsB,s4OAmMlC,CAAC;AAEF,eAAO,MAAM,sBAAsB,y0VAiSlC,CAAC;AAEF,eAAO,MAAM,yBAAyB,8sJAqIrC,CAAC;AAEF,eAAO,MAAM,sBAAsB,osjBA8VlC,CAAC;AAEF,eAAO,MAAM,qBAAqB,o2DAsEjC,CAAC;AAEF,eAAO,MAAM,+BAA+B,48NA6O3C,CAAC;AAEF,eAAO,MAAM,sBAAsB,2rLAoIlC,CAAC;AAEF,eAAO,MAAM,sBAAsB,gjMA6JlC,CAAC;AAEF,eAAO,MAAM,sBAAsB,i8SAsSlC,CAAC;AAEF,eAAO,MAAM,2BAA2B,4qLAgOvC,CAAC;AAEF,eAAO,MAAM,4BAA4B,qhUA6NxC,CAAC;AAGF,eAAO,MAAM,gBAAgB,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAenD,CAAC"}