edsger 0.77.0 → 0.79.0

package/dist/phases/output-contracts.js

@@ -1,1201 +0,0 @@
-/* eslint-disable max-lines */
-/**
- * Output format contracts for each phase.
- * These define the JSON structure that LLM responses must follow.
- * They are appended to the SKILL.md prompt and are NOT user-overridable,
- * ensuring json-extractor.ts and llm-responses.ts can always parse the output.
- */
-export const OUTPUT_CONTRACTS = {
-    'issue-analysis': `
-**CRITICAL - Result Format**:
-
-You MUST emit your response in TWO distinct blocks, in this order:
-
-1. The execution plan, wrapped in sentinel markers (NOT inside any code fence):
-
-<<<EXECUTION_PLAN>>>
-# Execution Plan
-
-## Issue type
-<bug | feature | refactor | infra | spike | docs | hybrid>
-
-## Summary
-<2-3 sentences>
-
-## Artifacts (in execution order)
-
-### 1. <artifact-name>
-**Why**: <why this issue needs this artifact>
-**Success criteria**: <concrete, issue-specific>
-**Depends on**: <none | previous artifact name>
-
-### 2. <artifact-name>
-...
-
-## Risks / open questions
-- <thing a human should resolve>
-- <...>
-<<<END_EXECUTION_PLAN>>>
-
-2. A JSON metadata block (a fenced \`\`\`json code block) describing status, summary, and checklist results. The JSON does NOT include the plan text — the plan lives between the sentinels above.
-
-\`\`\`json
-{
-  "analysis": {
-    "issue_id": "ISSUE_ID_PLACEHOLDER",
-    "status": "success",
-    "summary": "1-2 sentence summary of the plan you produced",
-    "checklist_item_results": [
-      {
-        "checklist_item_id": "EXACT_CHECKLIST_ITEM_UUID_FROM_ID_FIELD",
-        "is_passed": true,
-        "value": "Result value based on item type (boolean, text, number, etc.)",
-        "notes": "Optional notes about this specific checklist item"
-      }
-    ],
-    "recommendations": "Additional recommendations for the issue (optional)"
-  }
-}
-\`\`\`
-
-**Why two blocks?** The plan is markdown; embedding it inside a JSON string field requires escaping every newline and quote, which models frequently get wrong. Sentinels keep the markdown raw.
-
-**CRITICAL - Plan quality requirements**:
-- Success criteria MUST be issue-specific. Generic criteria ("comprehensive coverage", "follows INVEST") are NOT acceptable - they are the same for every issue and provide no signal.
-- Artifact list MUST justify what's included AND what's skipped. A trivial bug fix should explicitly skip user stories with a one-line reason.
-- Length target: 200-600 words for the markdown plan. Concise > exhaustive.
-- The plan must be sequenceable: a downstream agent reading artifact 1 should be able to start work without further planning.
-
-**STRUCTURAL REQUIREMENTS**:
-- Emit the plan FIRST (sentinels), THEN the JSON block. Do NOT interleave.
-- Do NOT put the plan inside a code fence — only between the sentinel markers.
-- Do NOT include any text outside the two blocks.
-
-MANDATORY: If checklists are provided in the context, include checklist_item_results for ALL checklist items. Use the exact UUIDs from "ID:" fields. Missing any item fails the pipeline.
-`,
-    'user-stories-analysis': `
-**CRITICAL - Result Format**:
-You MUST return ONLY a JSON object. Do NOT include any explanatory text before or after the JSON. Return ONLY the JSON in this EXACT format:
-
-\`\`\`json
-{
-  "analysis": {
-    "issue_id": "ISSUE_ID_PLACEHOLDER",
-    "status": "success",
-    "summary": "Brief summary of the user stories created and their coverage",
-    "id_prefix": "XX",
-    "created_user_stories": [
-      {
-        "title": "XX-001: Shortname Here",
-        "description": "**Category**: [Functional Area Name]\\n\\n**User Story**: As a **[role]**, I would like **[goal]** so that **[benefit]**.\\n\\n**Description**: [Detailed 2-4 sentence description explaining what this story covers, how it integrates with existing functionality, and why it matters.]\\n\\n**Requirements**:\\n- [Specific testable requirement 1]\\n- [Specific testable requirement 2]\\n- [Specific testable requirement 3]\\n- [Specific testable requirement 4]\\n- [Specific testable requirement 5]",
-        "status": "draft",
-        "differentiation": "REQUIRED: Explain how this differs from existing user stories."
-      }
-    ],
-    "deleted_user_story_ids": [
-      "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d"
-    ],
-    "deletion_reasons": {
-      "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d": "Duplicate of story XX-003"
-    },
-    "checklist_item_results": [
-      {
-        "checklist_item_id": "EXACT_CHECKLIST_ITEM_UUID_FROM_ID_FIELD",
-        "is_passed": true,
-        "value": "Result value",
-        "notes": "Optional notes"
-      }
-    ],
-    "recommendations": "Additional recommendations"
-  }
-}
-\`\`\`
-
-MANDATORY: If checklists are provided, you MUST include checklist_item_results for ALL checklist items.
-
-**CRITICAL DELETION FORMAT**:
-- deleted_user_story_ids array MUST contain ONLY UUIDs
-- Do NOT put reasons or text in the array - only UUID strings
-- Put all deletion reasons in the deletion_reasons object
-
-**Differentiation Requirement**:
-- The "differentiation" field is MANDATORY for every new user story
-- You MUST explain WHY this item is NOT a duplicate of existing items
-- If there are no existing items, write: "First item for this issue"
-- Generic explanations are NOT acceptable - be specific
-`,
-    'test-cases-analysis': `
-**CRITICAL - Result Format**:
-You MUST return ONLY a JSON object. Do NOT include any explanatory text. Return ONLY the JSON:
-
-\`\`\`json
-{
-  "analysis": {
-    "issue_id": "ISSUE_ID_PLACEHOLDER",
-    "status": "success",
-    "summary": "Brief summary of test cases created and coverage",
-    "created_test_cases": [
-      {
-        "name": "Test case name - descriptive of what is tested",
-        "description": "**Preconditions**:\\n- [Precondition 1]\\n- [Precondition 2]\\n\\n**Test Steps**:\\n1. [Step 1]\\n2. [Step 2]\\n3. [Step 3]\\n\\n**Expected Results**:\\n- [Expected result 1]\\n- [Expected result 2]\\n\\n**Postconditions**:\\n- [System state after test]\\n\\n**Related User Stories**: [Story IDs]",
-        "is_critical": true,
-        "differentiation": "REQUIRED: Explain how this differs from existing test cases."
-      }
-    ],
-    "deleted_test_case_ids": [
-      "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d"
-    ],
-    "deletion_reasons": {
-      "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d": "Duplicate of test case X"
-    },
-    "checklist_item_results": [
-      {
-        "checklist_item_id": "EXACT_CHECKLIST_ITEM_UUID_FROM_ID_FIELD",
-        "is_passed": true,
-        "value": "Result value",
-        "notes": "Optional notes"
-      }
-    ],
-    "recommendations": "Additional test strategy recommendations"
-  }
-}
-\`\`\`
-
-MANDATORY: If checklists are provided, you MUST include checklist_item_results for ALL checklist items.
-
-**CRITICAL DELETION FORMAT**:
-- deleted_test_case_ids array MUST contain ONLY UUIDs
-- Put all deletion reasons in the deletion_reasons object
-
-**Differentiation Requirement**:
-- The "differentiation" field is MANDATORY for every new test case
-- You MUST explain WHY this test is NOT a duplicate
-- Generic explanations are NOT acceptable - be specific
-`,
-    'issue-analysis-verification': `
-**CRITICAL - Output Format**:
-You MUST respond with a JSON object in this EXACT format:
-
-\`\`\`json
-{
-  "verification": {
-    "all_verified": true,
-    "total_items": 0,
-    "confirmed_count": 0,
-    "rejected_count": 0,
-    "uncertain_count": 0,
-    "item_verifications": [
-      {
-        "checklist_item_id": "uuid-of-the-checklist-item-being-verified",
-        "is_satisfied": true,
-        "verification_status": "confirmed",
-        "verification_reason": "Detailed explanation of your verification decision against this checklist item — what in the plan satisfies it (or fails to)",
-        "concerns": ["Optional array of specific gaps in the plan against this requirement"],
-        "improvement_suggestions": ["Specific, actionable changes to the plan for rejected/uncertain items"]
-      }
-    ],
-    "summary": "Overall summary of plan-quality findings",
-    "overall_suggestions": ["High-level changes to the plan if there are failures"]
-  }
-}
-\`\`\`
-
-**You are verifying the EXECUTION PLAN, not generated artifacts**:
-- The plan is a markdown document describing which artifacts to build, in what order, with what success criteria.
-- For each checklist item, decide whether the **plan itself** addresses it.
-- Concrete improvement suggestions should target specific sections of the plan, e.g.:
-  - "Make success criterion for artifact 'test cases' specific to the rate-limit path"
-  - "Add a 'Risks' entry for the unknown auth provider rollout"
-  - "Issue type is 'feature' but description is a bug report — reclassify"
-- Do NOT suggest writing user stories or test cases yourself. Suggest plan changes only.
-
-verification_status must be one of: confirmed | rejected | uncertain.
-`,
-    task: `
-## Output
-When done, provide a brief summary of what you accomplished for this task.
-`,
-    'analyze-logs': `
-Return your analysis as JSON in this exact format:
-\`\`\`json
-{
-  "summary": "Brief summary of what the user did and any issues found",
-  "feedbacks": [
-    {
-      "category": "bug|feature_request|improvement|question|other",
-      "title": "Short descriptive title (max 200 chars)",
-      "description": "Detailed description of the issue or suggestion (max 5000 chars)",
-      "priority": "low|medium|high|critical"
-    }
-  ]
-}
-\`\`\`
-
-If no issues are found, return:
-\`\`\`json
-{
-  "summary": "User session appears normal with no issues detected",
-  "feedbacks": []
-}
-\`\`\`
-`,
-    'bug-fixing': `
-**CRITICAL - Result Format**:
-You MUST end your response with a JSON object containing the bug fix results in this EXACT format:
-
-\`\`\`json
-{
-  "fix_result": {
-    "issue_id": "ISSUE_ID_PLACEHOLDER",
-    "attempt_number": 1,
-    "summary": "Brief description of what was fixed",
-    "files_modified": ["file1.ts", "file2.tsx"],
-    "tests_passed": true,
-    "fixes_applied": [
-      {
-        "issue": "Description of the issue",
-        "fix": "Description of how it was fixed",
-        "file": "path/to/file.ts"
-      }
-    ],
-    "remaining_issues": ["Any issues that could not be resolved"],
-    "recommendations": "Additional recommendations for the development team"
-  }
-}
-\`\`\`
-`,
-    'code-testing': `
-**CRITICAL - Result Format**:
-You MUST end your response with a JSON object containing the test results in this EXACT format:
-
-\`\`\`json
-{
-  "code_test_result": {
-    "issue_id": "ISSUE_ID_PLACEHOLDER",
-    "branch_name": "dev/issue-name",
-    "commit_hash": "abc123def456",
-    "summary": "Brief description of tests written",
-    "test_files_created": ["test-file1.test.ts", "test-file2.test.tsx"],
-    "test_files_modified": ["existing-test1.test.ts"],
-    "total_tests_written": 25,
-    "tests_passing": true,
-    "test_coverage": "Description of what functionality is covered by tests",
-    "status": "success",
-    "notes": "Any important notes about the tests"
-  }
-}
-\`\`\`
-`,
-    'functional-testing': `
-**CRITICAL - Result Format**:
-You MUST end your response with a JSON object containing the test results in this EXACT format:
-
-\`\`\`json
-{
-  "test_result": {
-    "issue_id": "ISSUE_ID_PLACEHOLDER",
-    "test_run_id": "unique-test-run-id",
-    "status": "passed",
-    "summary": "Brief summary of testing results",
-    "tests_executed": [
-      {
-        "test_case_id": "test-case-1",
-        "test_name": "Test case name",
-        "status": "passed",
-        "details": "Specific details about what was tested and verified"
-      }
-    ],
-    "critical_issues_found": [],
-    "non_critical_issues_found": [],
-    "test_coverage": "Description of what functionality was tested",
-    "recommendations": "Any recommendations for improving the issue"
-  }
-}
-\`\`\`
-`,
-    'technical-design-verification': `
-**CRITICAL - Output Format**:
-You MUST respond with a JSON object in this EXACT format:
-
-\`\`\`json
-{
-  "verification": {
-    "all_verified": true/false,
-    "total_items": number,
-    "confirmed_count": number,
-    "rejected_count": number,
-    "uncertain_count": number,
-    "item_verifications": [
-      {
-        "checklist_item_id": "uuid",
-        "is_satisfied": true/false,
-        "verification_status": "confirmed|rejected|uncertain",
-        "verification_reason": "Detailed explanation of your verification decision",
-        "concerns": ["Optional array of specific concerns or gaps found"],
-        "improvement_suggestions": ["Specific, actionable suggestions for improvement (for rejected/uncertain items)"]
-      }
-    ],
-    "feedbacks_verified": true/false,
-    "total_feedbacks": number,
-    "feedbacks_confirmed_count": number,
-    "feedbacks_rejected_count": number,
-    "feedbacks_uncertain_count": number,
-    "feedback_verifications": [
-      {
-        "feedback_id": "uuid",
-        "feedback_title": "title",
-        "is_addressed": true/false,
-        "verification_status": "confirmed|rejected|uncertain",
-        "verification_reason": "Detailed explanation of whether the feedback was addressed",
-        "concerns": ["Optional array of specific concerns"],
-        "improvement_suggestions": ["Specific suggestions for addressing this feedback (for rejected/uncertain items)"]
-      }
-    ],
-    "summary": "Overall summary of verification findings (include both checklist and feedback results)",
-    "overall_suggestions": ["High-level suggestions for improving the overall design (if there are failures)"]
-  }
-}
-\`\`\`
-
-**IMPORTANT**:
-- If feedbacks are provided, you MUST include feedback_verifications for ALL feedbacks
-- Each feedback must be verified to check if it was properly addressed in the technical design
-- For feedbacks, check if the specific concern or requirement mentioned in the feedback has been incorporated into the design
-
-**For rejected/uncertain items**: Provide specific, actionable improvement_suggestions such as:
-- "Add architectural diagram showing component interactions"
-- "Include detailed API specifications for X endpoint"
-- "Expand security considerations to cover Y attack vector"
-- "Add database schema design for Z table"
-`,
-    'code-implementation-verification': `
-**CRITICAL - Result Format**:
-You MUST return ONLY a JSON object with your verification results. Do NOT include any explanatory text before or after the JSON. Return ONLY the JSON in this EXACT format:
-
-\`\`\`json
-{
-  "verification_result": {
-    "overall_status": "passed" | "failed" | "partial",
-    "summary": "Brief summary of verification findings",
-    "confirmed_count": 0,
-    "rejected_count": 0,
-    "uncertain_count": 0,
-    "item_verifications": [
-      {
-        "checklist_item_id": "EXACT_CHECKLIST_ITEM_UUID",
-        "is_satisfied": true | false,
-        "verification_status": "confirmed" | "rejected" | "uncertain",
-        "verification_reason": "Detailed explanation of why this status was assigned",
-        "concerns": ["Specific concern 1", "Specific concern 2"],
-        "improvement_suggestions": ["Actionable suggestion 1", "Actionable suggestion 2"]
-      }
-    ],
-    "overall_suggestions": ["General improvement suggestion 1", "General improvement suggestion 2"]
-  }
-}
-\`\`\`
-
-IMPORTANT: Return ONLY the JSON above. Do not add any text explaining your verification process or findings. The JSON should be the complete and only content of your response.
-`,
-    'app-store-generation': `
-**CRITICAL - Result Format**:
-Return ONLY a JSON object. No text before or after.
-
-\`\`\`json
-{
-  "app_store": {
-    "listings": {
-      "en-US": {
-        "app_name": "Product Name",
-        "subtitle": "Short value proposition",
-        "promotional_text": "Highlight a current promotion, new issue, or seasonal message (170 chars max)",
-        "short_description": "One-liner for Google Play (80 chars max)",
-        "description": "Full store description with issues and benefits",
-        "keywords": "keyword1,keyword2,keyword3",
-        "whats_new": "Latest improvements and fixes",
-        "primary_category": "Category",
-        "secondary_category": "Category"
-      }
-    },
-    "screenshots": [
-      {
-        "feature_highlight": "Issue being showcased",
-        "headline": "Bold 2-5 Word Headline",
-        "subheadline": "Supporting detail line (optional)",
-        "background_gradient": "linear-gradient(135deg, #667eea 0%, #764ba2 100%)",
-        "text_color": "#ffffff",
-        "device_frame": "iphone|ipad|browser|macbook",
-        "html_template": "<html>...(complete self-contained HTML page showing the app mock with realistic data)...</html>"
-      }
-    ]
-  }
-}
-\`\`\`
-`,
-    'growth-analysis': `
-**CRITICAL - Result Format**:
-You MUST return ONLY a JSON object. Do NOT include any text before or after the JSON.
-
-\`\`\`json
-{
-  "analysis": {
-    "product_id": "PRODUCT_ID",
-    "status": "success",
-    "analysis_content": "Comprehensive analysis summary including product positioning, target audience insights, and growth strategy overview",
-    "target_channels": [
-      {
-        "name": "Channel name (e.g., twitter, reddit, hackernews, linkedin, blog, producthunt, devto, discord, email, youtube)",
-        "reason": "Why this channel is recommended for this product",
-        "audience": "Description of the target audience on this channel",
-        "priority": "high|medium|low"
-      }
-    ],
-    "content_suggestions": [
-      {
-        "channel": "channel_name",
-        "title": "Content title or headline",
-        "content": "The full content piece ready to be published or adapted",
-        "rationale": "Why this content will resonate with the audience on this channel",
-        "video_plan": {
-          "should_generate_video": true,
-          "video_reason": "Why video enhances this content (or why text-only is better)",
-          "scenes": [
-            {
-              "order": 1,
-              "page_path": "/dashboard",
-              "description": "What this scene shows",
-              "transcript": "The narration script for this scene, written in a natural, engaging tone",
-              "duration": 8,
-              "device_frame": "browser|macbook|iphone|none (optional, auto-detected if omitted)",
-              "frame_background": "CSS gradient or color for the area behind the device (optional, default: gradient)",
-              "frame_browser_url": "URL to show in browser address bar (optional, only for browser frame)",
-              "viewport_width": 1280,
-              "viewport_height": 720,
-              "html_template": "<html><head><style>...</style></head><body>...complete self-contained HTML with realistic mock data...</body></html>"
-            }
-          ]
-        }
-      }
-    ],
-    "search_context": "Summary of current trends and context that informed this analysis"
-  }
-}
-\`\`\`
-
-**Video Plan Guidelines**:
-- "should_generate_video": set to true ONLY when video genuinely adds value
-- "video_reason": always explain your reasoning for the video decision
-- "scenes": provide 3-6 scenes for a 30-90 second video
-- "transcript": write natural, engaging narration (not robotic or overly formal)
-- "html_template": complete HTML page with inline styles, realistic data, professional design
-- Use modern CSS (flexbox, grid, gradients) for polished look
-- Include realistic mock data: real-looking names, dates, metrics, charts
-- Each template should visually represent the product's actual UI/issues
-- "device_frame": choose the most appropriate device for each scene:
-  - Use "macbook" for showcasing full desktop workflows or dashboards
-  - Use "iphone" for mobile-first issues or responsive design demos (set viewport_width: 390, viewport_height: 844)
-  - Use "browser" (default) for web app screenshots with Chrome-style address bar
-  - Mix device types within a video for variety (e.g., show desktop then mobile)
-- "frame_background": customize the gradient/color behind the device (e.g., "linear-gradient(135deg, #667eea 0%, #764ba2 100%)")
-- "frame_browser_url": set a realistic URL for browser frames (e.g., "app.yourproduct.com/dashboard")
-- If should_generate_video is false, scenes array should be empty
-`,
-    'user-psychology': `
-**CRITICAL - Result Format**:
-You MUST return ONLY a JSON object inside a \`\`\`json code block. Do NOT include any text before or after the JSON.
-
-\`\`\`json
-{
-  "analysis": {
-    "product_id": "PRODUCT_ID",
-    "status": "success",
-    "analysis_content": "3-4 sentence executive summary of who these users are and what they really care about. Concrete, not generic.",
-    "target_personas": [
-      {
-        "name": "Asha, the burned-out solo founder",
-        "archetype": "One-line description of who they are and what they do",
-        "demographics": {
-          "role": "Solo founder of a 1-5 person SaaS",
-          "seniority": "5-10 years experience",
-          "context": "Other specifics that matter (team size, tools, stage, etc.)"
-        },
-        "goals": ["Goal 1", "Goal 2"],
-        "frustrations": ["Frustration 1 in their voice", "Frustration 2"],
-        "values": "What they believe makes them good at their job",
-        "decision_drivers": ["What tips them toward yes", "Another driver"],
-        "anti_persona_note": "Who looks similar but is the wrong fit",
-        "evidence": "Which feature/file/context-line supports this persona"
-      }
-    ],
-    "jobs_to_be_done": [
-      {
-        "statement": "When [situation], I want to [motivation], so I can [outcome].",
-        "type": "functional|emotional|social",
-        "current_alternatives": ["Competitor / spreadsheet / nothing"],
-        "switching_cost": "What makes it hard to switch",
-        "persona": "Which persona this job belongs to (name from target_personas)"
-      }
-    ],
-    "pain_points": [
-      {
-        "pain": "Single sentence in the user's voice",
-        "trigger": "What event makes the pain acute",
-        "severity": "critical|chronic|occasional",
-        "evidence": "Which feature, file, or context line implies this pain"
-      }
-    ],
-    "motivations": {
-      "autonomy": "How the product serves their need for control / removes oversight (or 'not addressed')",
-      "competence": "How the product makes them feel capable",
-      "relatedness": "How the product connects them to others or signals belonging"
-    },
-    "behavior_triggers": [
-      {
-        "behavior": "Specific desired action (e.g., 'invite first teammate')",
-        "motivation_level": "high|medium|low",
-        "motivation_reason": "Why",
-        "ability_barrier": "What is hard about doing it",
-        "prompt": "What cue would trigger this right now",
-        "recommendation": "Concrete change to lift motivation, reduce barrier, or improve prompt"
-      }
-    ],
-    "messaging_angles": [
-      {
-        "angle_name": "Short label",
-        "hook": "The headline in 10-15 words, in the user's voice",
-        "persona": "Persona name this speaks to",
-        "job": "JTBD statement (or short reference) this answers",
-        "psychological_lever": "loss_aversion|social_proof|identity_affirmation|curiosity_gap|status|reciprocity|other",
-        "why_it_works": "One sentence on the lever"
-      }
-    ]
-  }
-}
-\`\`\`
-
-**Required field rules**:
-- 3-5 personas (collapse overlapping ones)
-- 4-8 jobs_to_be_done — cover at least one emotional and one social job, not just functional
-- 3-8 pain_points
-- behavior_triggers should target 3-5 high-value actions (signup, activation, retention, expansion)
-- 3-6 messaging_angles, each tied to a real persona + job
-
-**Anti-rules — these fail validation**:
-- No placeholder text ([role], [insert benefit], "users want to be productive")
-- No demographic-only personas — psychographics or skip the field
-- No "users struggle with X" phrasing in pain_points — write in the user's voice
-- No JTBD that is just a feature description ("user wants to use Feature Y")
-`,
-    'intelligence-analysis': `
-**Output Format**:
-Return a JSON object inside a \`\`\`json code block with this exact structure:
-
-\`\`\`json
-{
-  "analysis": {
-    "product_id": "the-product-id",
-    "report_type": "competitive",
-    "title": "Competitive Intelligence Report — [Product Name] — [Date]",
-    "summary": "2-3 sentence executive summary of key findings",
-    "full_report": "Full markdown report with sections: Executive Summary, Competitor Overview, Issue Comparison, Pricing Comparison, Market Positioning, Threats & Opportunities, Recommendations",
-    "key_findings": [
-      {
-        "finding": "Specific finding with evidence",
-        "severity": "critical|important|fyi",
-        "category": "competitive|market|product|pricing"
-      }
-    ],
-    "recommendations": [
-      {
-        "action": "Specific actionable recommendation",
-        "priority": "high|medium|low",
-        "effort": "small|medium|large",
-        "impact": "high|medium|low",
-        "rationale": "Why this matters, with evidence"
-      }
-    ],
-    "competitor_highlights": [
-      {
-        "competitor_name": "Name",
-        "highlight": "What happened or what stands out",
-        "sentiment": "threat|opportunity|neutral"
-      }
-    ],
-    "market_signals": [
-      {
-        "source": "reddit|hn|twitter|producthunt|blog|app_store",
-        "signal": "What was observed",
-        "relevance": "high|medium|low",
-        "url": "source URL if available"
-      }
-    ],
-    "trends": [
-      {
-        "trend": "Description of trend",
-        "direction": "up|down|stable",
-        "evidence": "What data supports this"
-      }
-    ],
-    "discovered_competitors": [
-      {
-        "name": "Competitor Name",
-        "url": "https://...",
-        "app_store_url": "https://... or null",
-        "play_store_url": "https://... or null",
-        "description": "One-line description",
-        "category": "Market category",
-        "discovery_reason": "Why this is a competitor — be specific"
-      }
-    ],
-    "competitor_snapshots": [
-      {
-        "competitor_id": "UUID of the competitor (use the Competitor ID from context for confirmed competitors, or null for newly discovered)",
-        "competitor_name": "Exact name as provided in context or discovered_competitors",
-        "issues": [{"name": "Issue", "description": "What it does", "is_new": false}],
-        "pricing": {"tiers": [{"name": "Free", "price": "$0", "issues": ["..."]}], "model": "freemium"},
-        "tech_stack": ["React", "Node.js"],
-        "app_rating": 4.5,
-        "app_review_count": 1234,
-        "app_version": "2.1.0",
-        "recent_reviews": [{"rating": 5, "title": "Great app", "body": "...", "date": "2026-03-20"}],
-        "social_mentions": {"reddit": 15, "hn": 3, "twitter": 42},
-        "changes_detected": [{"type": "new_feature", "description": "Added AI assistant"}]
-      }
-    ]
-  }
-}
-\`\`\`
-`,
-    'code-implementation': `
-**CRITICAL - Result Format**:
-You MUST end your response with a JSON object containing the implementation results in this EXACT format:
-
-\`\`\`json
-{
-  "implementation_result": {
-    "issue_id": "ISSUE_ID_PLACEHOLDER",
-    "branch_name": "dev/issue-name",
-    "commit_hash": "abc123def456",
-    "summary": "Brief description of what was implemented",
-    "files_created": ["new-file1.ts", "new-file2.tsx"],
-    "files_modified": ["existing-file1.ts", "existing-file2.tsx"],
-    "user_stories_implemented": ["story-id-1", "story-id-2"],
-    "test_cases_passing": ["test-case-1", "test-case-2"],
-    "status": "success",
-    "notes": "Any important notes about the implementation"
-  }
-}
-\`\`\`
-`,
-    'pr-execution': `
-## Output
-
-After creating all branches, respond with:
-
-\`\`\`json
-{
-  "execution_result": {
-    "status": "success",
-    "branches_created": ["pr/ISSUE_ID/1-desc", "pr/ISSUE_ID/2-desc"],
-    "summary": "Brief description of what was done"
-  }
-}
-\`\`\`
-
-If any branch fails, include the error but continue with remaining branches:
-
-\`\`\`json
-{
-  "execution_result": {
-    "status": "partial",
-    "branches_created": ["pr/ISSUE_ID/1-desc"],
-    "branches_failed": [{"branch": "pr/ISSUE_ID/2-desc", "error": "..."}],
-    "summary": "..."
-  }
-}
-\`\`\`
-`,
-    'incremental-sync': `
-## Output
-
-After updating all branches, respond with:
-
-\`\`\`json
-{
-  "execution_result": {
-    "status": "success",
-    "branches_updated": ["pr/ISSUE_ID/1-desc", "pr/ISSUE_ID/2-desc"],
-    "summary": "Brief description of what was done"
-  }
-}
-\`\`\`
-`,
-    'technical-design': `
-**CRITICAL - Result Format**:
-You MUST return ONLY a JSON object with your technical design results. Do NOT include any explanatory text before or after the JSON. Return ONLY the JSON in this EXACT format:
-
-\`\`\`json
-{
-  "technical_design_result": {
-    "issue_id": "ISSUE_ID_PLACEHOLDER",
-    "status": "success",
-    "summary": "Brief summary of what was accomplished",
-    "technical_design": "The complete technical design document in markdown format",
-    "checklist_item_results": [
-      {
-        "checklist_item_id": "EXACT_CHECKLIST_ITEM_UUID_FROM_ID_FIELD",
-        "is_passed": true,
-        "value": "Result value based on item type (boolean, text, number, etc.)",
-        "notes": "Optional notes about this specific checklist item"
-      }
-    ],
-    "recommendations": "Additional recommendations for implementation"
-  }
-}
-\`\`\`
-
-MANDATORY: If checklists are provided in the context, you MUST include checklist_item_results for ALL checklist items. Every checklist item ID must be addressed - either passed or with explanation in notes why it cannot be satisfied. Missing any checklist item will cause the pipeline to fail.
-
-IMPORTANT: In the checklist context, look for lines that say "ID: [UUID]" in the items list - use these exact UUIDs as checklist_item_id values. Do NOT use the item title or description as the checklist_item_id.
-`,
-    autonomous: `
-**CRITICAL - Result Format**:
-You MUST end your response with a JSON object in this EXACT format:
-
-\`\`\`json
-{
-  "autonomous_result": {
-    "issue_id": "ISSUE_ID",
-    "task_type": "issue|bugfix|refactor|test|docs|chore",
-    "summary": "Brief description of what was done",
-    "files_modified": ["file1.ts", "file2.tsx"],
-    "commit_hash": "abc123..."
-  }
-}
-\`\`\`
-`,
-    'branch-planning': `
-## CRITICAL - Output Format
-
-You MUST return ONLY a JSON object with your branch planning results.
-Do NOT include any explanatory text, summary, or commentary before or after the JSON.
-Return ONLY the JSON in this EXACT format:
-
-\`\`\`json
-{
-  "branch_planning_result": {
-    "issue_id": "ISSUE_ID",
-    "status": "success",
-    "summary": "Brief summary of the branch planning",
-    "total_branches": <number>,
-    "estimated_complexity": "low|medium|high",
-    "branches": [
-      {
-        "name": "Short descriptive name",
-        "description": "Detailed description of what this branch implements",
-        "branch_name": "dev/ISSUE_ID/1-short-name",
-        "depends_on_branch_name": null,
-        "scope": [
-          "List of specific items to implement"
-        ],
-        "acceptance_criteria": [
-          "Criteria that must be met for this branch to be complete"
-        ]
-      }
-    ],
-    "rationale": "Explanation of why the issue was split this way"
-  }
-}
-\`\`\`
-`,
-    'pr-splitting': `
-## CRITICAL - Output Format
-
-You MUST return ONLY a JSON object with your PR splitting results.
-Do NOT include any explanatory text, summary, or commentary before or after the JSON.
-Return ONLY the JSON in this EXACT format:
-
-\`\`\`json
-{
-  "pr_splitting_result": {
-    "issue_id": "ISSUE_ID",
-    "status": "success",
-    "summary": "Brief summary of the PR splitting strategy",
-    "total_prs": <number>,
-    "pull_requests": [
-      {
-        "sequence": 1,
-        "name": "Short descriptive name",
-        "description": "What this PR covers and why it's grouped this way",
-        "branch_name": "pr/ISSUE_ID/1-short-name",
-        "depends_on_branch_name": null,
-        "files": [
-          {"path": "src/db/users.ts", "change_type": "added"},
-          {"path": "src/types/user.ts", "change_type": "modified"}
-        ],
-        "scope": ["List of specific items in this PR"],
-        "acceptance_criteria": ["Criteria for this PR to be complete"]
-      }
-    ],
-    "rationale": "Explanation of why the code was split this way"
-  }
-}
-\`\`\`
-`,
-    'code-refine': `
-**CRITICAL - Result Format**:
-You MUST end your response with a JSON object containing the code refine results in this EXACT format:
-
-\`\`\`json
-{
-  "refine_result": {
-    "issue_id": "ISSUE_ID_PLACEHOLDER",
-    "summary": "Brief description of changes made",
-    "files_modified": ["file1.ts", "file2.tsx"],
-    "commits_created": 1,
-    "feedback_addressed": [
-      {
-        "comment_id": "Comment reference or ID",
-        "issue": "Description of the reviewer's concern",
-        "resolution": "Description of how it was addressed",
-        "files": ["path/to/file.ts"]
-      }
-    ]
-  }
-}
-\`\`\`
-`,
-    'code-refine-with-checklists': `
-**CRITICAL - Result Format**:
-You MUST end your response with a JSON object containing the code refine results in this EXACT format:
-
-\`\`\`json
-{
-  "refine_result": {
-    "issue_id": "ISSUE_ID_PLACEHOLDER",
-    "summary": "Brief description of changes made",
-    "files_modified": ["file1.ts", "file2.tsx"],
-    "commits_created": 1,
-    "feedback_addressed": [
-      {
-        "comment_id": "Comment reference or ID",
-        "issue": "Description of the reviewer's concern",
-        "resolution": "Description of how it was addressed",
-        "files": ["path/to/file.ts"]
-      }
-    ],
-    "checklist_item_results": [
-      {
-        "checklist_item_id": "EXACT_CHECKLIST_ITEM_UUID_FROM_ID_FIELD",
-        "is_passed": true,
-        "value": "Result value based on item type (boolean, text, number, etc.)",
-        "notes": "Optional notes about this specific checklist item"
-      }
-    ]
-  }
-}
-\`\`\`
-`,
-    'screen-flow': `
-**CRITICAL — How to return the result**:
-
-Return the extraction by calling the MCP tool
-\`mcp__screen-flow__submit_screen_flow\` **exactly once** with these arguments:
-
-- \`summary\` — 1-3 sentence narrative of what kind of app this is and its primary user flows
-- \`nodes\` — array of ScreenSchema objects (every user-facing screen, modal, drawer, tab, or named state)
-- \`edges\` — array of ScreenEdge objects (transitions between screens)
-- \`theme?\` — the product's visual design tokens \`{ primary?, neutral?, radius?, font? }\`, read from the **user-facing frontend**. When the product spans several repos, decide which one renders the UI users actually see (look for Tailwind config, global CSS variables like \`--primary\`/\`--radius\`, or a design-tokens file) and read its tokens — ignore backend/infra repos. Omit any field you can't determine, and omit \`theme\` entirely if there is no frontend.
-
-The tool validates the arguments against the schema. If it returns an error,
-fix the issue it describes and call the tool again. After a successful call,
-end your turn — do not also paste the same data as a fenced text block.
-
-You can also call \`mcp__screen-flow__record_progress({ phase, message })\` at
-each phase boundary (detection / routing / screens / transitions / submission)
-to keep the user informed during long runs. This is observability only — it
-does not affect the extraction.
-
-ScreenSchema fields:
-- \`slug\` (unique within the diagram), \`name\`, \`route?\`, \`file?\`
-- \`kind\`: one of \`page\`, \`modal\`, \`drawer\`, \`tab\`, \`state\`
-- \`layout\`: one of \`centered\`, \`sidebar\`, \`split\`, \`list-detail\`, \`tabs\`, \`stacked\`
-- \`header?\`: \`{ title, subtitle?, back?, actions?: [{ label, variant?, icon? }] }\`
-- \`body\`: array of sections; each section \`type\` is one of \`form\`, \`list\`, \`card-grid\`, \`table\`, \`kanban\`, \`text\`, \`image\`, \`chart\`, \`stats\`, \`empty-state\`, \`tabs\`, \`custom\`
-
-ScreenEdge fields:
-- \`fromSlug\`, \`toSlug\` (both MUST appear in nodes), \`triggerLabel\`, \`triggerFile?\`
-- \`kind\`: one of \`navigate\`, \`modal\`, \`redirect\`, \`back\`
-
-Schematic example of the tool call:
-
-\`\`\`
-submit_screen_flow({
-  summary: "Two-screen demo: sign in then land on home.",
-  nodes: [
-    { slug: "login", name: "Login", route: "/signin", file: "src/pages/Login.tsx",
-      kind: "page", layout: "centered",
-      header: { title: "Sign in", actions: [{ label: "Sign up", variant: "ghost" }] },
-      body: [{ type: "form", submitLabel: "Sign in", fields: [
-        { label: "Email", kind: "email", required: true },
-        { label: "Password", kind: "password", required: true }
-      ]}]
-    },
-    { slug: "home", name: "Home", route: "/", file: "src/pages/Home.tsx",
-      kind: "page", layout: "sidebar", body: [] }
-  ],
-  edges: [
-    { fromSlug: "login", toSlug: "home", triggerLabel: "Submit credentials",
-      triggerFile: "src/pages/Login.tsx", kind: "navigate" }
-  ]
-})
-\`\`\`
-`,
-    'data-flow': `
-**CRITICAL — How to return the result**:
-
-Return the extraction by calling the MCP tool
-\`mcp__data-flow__submit_data_flow\` **exactly once** with three arguments:
-
-- \`summary\` — 1-3 sentence narrative of what this system does with data and its primary pipelines
-- \`nodes\` — array of DataNodeSchema objects (every source / dataset / transform / sink / queue / model)
-- \`edges\` — array of DataEdge objects (connections, with direction = data movement)
-
-The tool validates the arguments against the schema. If it returns an error,
-fix the issue it describes and call the tool again. After a successful call,
-end your turn — do not also paste the same data as a fenced text block.
-
-You can also call \`mcp__data-flow__record_progress({ phase, message })\` at
-each phase boundary (detection / enumeration / nodes / edges / submission)
-to keep the user informed during long runs. This is observability only — it
-does not affect the extraction.
-
-DataNodeSchema fields:
-- \`slug\` (unique within the diagram), \`name\`, \`kind\`, \`file?\`
-- \`kind\`: one of \`source\`, \`dataset\`, \`transform\`, \`sink\`, \`queue\`, \`model\`
-- \`description?\`: one-sentence summary
-- \`tech?\`: technology / format hint (e.g. \`postgres\`, \`parquet\`, \`kafka\`, \`openai-api\`)
-- \`schedule?\`: for transforms (e.g. \`cron 0 0 * * *\`, \`on-event\`, \`manual\`, \`continuous\`)
-- \`inputs?\` / \`outputs?\`: arrays of \`{ name, type?, required?, description? }\`
-- \`sample?\`: \`{ columns: [string], rows: [[string]] }\` — at most 4 sample rows for datasets
-- \`stats?\`: array of \`{ label, value }\` (volume, latency, count hints)
-
-DataEdge fields:
-- \`fromSlug\` (upstream), \`toSlug\` (downstream) — both MUST appear in nodes
-- \`kind\`: one of \`data\`, \`event\`, \`control\`, \`derives\`
-- \`label?\`: free-form descriptor (e.g. \`nightly batch\`, \`on user signup\`)
-- \`sourceFile?\`: file containing the read/write/trigger code
-
-Edge direction convention: fromSlug is upstream (data origin), toSlug is downstream
-(data destination). A transform that reads from a dataset and writes to a queue
-produces two edges: \`dataset → transform\` (kind: data) and \`transform → queue\`
-(kind: event).
-
-Schematic example of the tool call:
-
-\`\`\`
-submit_data_flow({
-  summary: "Nightly product-feed pipeline: scrape vendor sites, normalize, write to Postgres, publish change events to Kafka.",
-  nodes: [
-    { slug: "vendor-scrape", name: "Vendor scraper", kind: "source",
-      file: "src/scrape/vendor.ts", tech: "playwright",
-      schedule: "cron 0 0 * * *",
-      outputs: [{ name: "html", type: "string" }, { name: "url", type: "string" }] },
-    { slug: "normalize", name: "Normalize products", kind: "transform",
-      file: "src/etl/normalize.ts", tech: "node",
-      inputs: [{ name: "html", type: "string" }],
-      outputs: [{ name: "sku", type: "string" }, { name: "price", type: "decimal" }] },
-    { slug: "products", name: "products", kind: "dataset",
-      file: "supabase/migrations/0001_products.sql", tech: "postgres",
-      sample: { columns: ["sku", "price"], rows: [["ABC-1", "9.99"]] } },
-    { slug: "change-events", name: "product.changed", kind: "queue",
-      file: "src/queues/products.ts", tech: "kafka" }
-  ],
-  edges: [
-    { fromSlug: "vendor-scrape", toSlug: "normalize", kind: "data",
-      label: "raw HTML", sourceFile: "src/etl/normalize.ts" },
-    { fromSlug: "normalize", toSlug: "products", kind: "data",
-      label: "upsert", sourceFile: "src/etl/normalize.ts" },
-    { fromSlug: "products", toSlug: "change-events", kind: "event",
-      label: "on row change", sourceFile: "src/queues/products.ts" }
-  ]
-})
-\`\`\`
-`,
-    'er-diagram': `
-**CRITICAL — How to return the result**:
-
-Return the extraction by calling the MCP tool
-\`mcp__er-diagram__submit_er_diagram\` **exactly once** with three arguments:
-
-- \`summary\` — 1-3 sentence narrative of the data model (core entities + relationships)
-- \`entities\` — array of ErEntity objects (every table / view / enum / junction)
-- \`relations\` — array of ErRelation objects (foreign-key / inheritance edges)
-
-The tool validates the arguments against the schema. If it returns an error,
-fix the issue it describes and call the tool again. After a successful call,
-end your turn — do not also paste the same data as a fenced text block.
-
-You can also call \`mcp__er-diagram__record_progress({ phase, message })\` at
-each phase boundary (detection / enumeration / entities / relations / submission)
-to keep the user informed during long runs. This is observability only — it
-does not affect the extraction.
-
-ErEntity fields:
-- \`slug\` (unique within the diagram), \`name\`, \`kind\`, \`file?\`
-- \`kind\`: one of \`entity\`, \`view\`, \`enum\`, \`junction\`
-- \`description?\`: one-sentence summary
-- \`columns?\`: array of \`{ name, type?, isPrimaryKey?, isForeignKey?, isNullable?, isUnique?, description?, references? }\`
-  - \`references\`: for FKs, \`target-entity-slug.column\` (e.g. \`users.id\`)
-- \`stats?\`: array of \`{ label, value }\` (row counts, cardinality hints)
-
-ErRelation fields:
-- \`fromSlug\` (child / FK holder), \`toSlug\` (parent / referenced) — both MUST appear in entities
-- \`kind\`: one of \`one-to-one\`, \`one-to-many\`, \`many-to-many\`, \`inherits\`
-- \`label?\`: free-form descriptor (e.g. \`placed by\`, \`belongs to\`)
-- \`sourceColumn?\` / \`targetColumn?\`: the FK column and the referenced column
-- \`sourceFile?\`: file containing the FK constraint / association
-
-Direction convention: fromSlug holds the foreign key (child / "many" side),
-toSlug is the referenced entity (parent / "one" side). \`orders.user_id → users.id\`
-becomes \`{ fromSlug: "orders", toSlug: "users", kind: "one-to-many" }\`.
-
-Schematic example of the tool call:
-
-\`\`\`
-submit_er_diagram({
-  summary: "Storefront schema: users place orders made of order-items that reference products; roles are linked to users through a junction table.",
-  entities: [
-    { slug: "users", name: "users", kind: "entity",
-      file: "db/migrations/0001_users.sql",
-      columns: [
-        { name: "id", type: "uuid", isPrimaryKey: true },
-        { name: "email", type: "varchar(255)", isUnique: true },
-        { name: "created_at", type: "timestamptz" }
-      ] },
-    { slug: "orders", name: "orders", kind: "entity",
-      file: "db/migrations/0002_orders.sql",
-      columns: [
-        { name: "id", type: "uuid", isPrimaryKey: true },
-        { name: "user_id", type: "uuid", isForeignKey: true, references: "users.id" },
-        { name: "status", type: "order_status" }
-      ] },
-    { slug: "order-status", name: "order_status", kind: "enum",
-      file: "db/migrations/0002_orders.sql" }
-  ],
-  relations: [
-    { fromSlug: "orders", toSlug: "users", kind: "one-to-many",
-      label: "placed by", sourceColumn: "user_id", targetColumn: "id",
-      sourceFile: "db/migrations/0002_orders.sql" }
-  ]
-})
-\`\`\`
-`,
-    'sequence-diagram': `
-**CRITICAL — How to return the result**:
-
-Return the extraction by calling the MCP tool
-\`mcp__sequence-diagram__submit_sequence_diagram\` **exactly once** with three arguments:
-
-- \`summary\` — 1-3 sentence narrative naming the scenario, the participants, and the outcome
-- \`participants\` — array of SequenceParticipant objects (every lifeline)
-- \`messages\` — array of SequenceMessage objects, each with an explicit \`order\`
-
-The tool validates the arguments against the schema. If it returns an error,
-fix the issue it describes and call the tool again. After a successful call,
-end your turn — do not also paste the same data as a fenced text block.
-
-You can also call \`mcp__sequence-diagram__record_progress({ phase, message })\`
-at each phase boundary (detection / enumeration / participants / messages /
-submission) to keep the user informed during long runs. This is observability
-only — it does not affect the extraction.
-
-A sequence diagram captures ONE scenario. Map a single end-to-end flow of control.
-
-SequenceParticipant fields:
-- \`slug\` (unique within the diagram), \`name\`, \`kind\`, \`file?\`
-- \`kind\`: one of \`actor\`, \`service\`, \`component\`, \`database\`, \`queue\`, \`external\`
-- \`description?\`: one-sentence role summary
-
-SequenceMessage fields:
-- \`fromSlug\` (sender), \`toSlug\` (receiver) — both MUST appear in participants
-- \`kind\`: one of \`sync\`, \`async\`, \`return\`, \`self\`
-- \`order\`: **1-based integer** position in the execution timeline (do not skip or reuse numbers)
-- \`label?\`: the call / message text (\`POST /login\`, \`validateToken(jwt)\`, \`rows\`)
-- \`sourceFile?\`: file (+ line) where the call happens
-
-Order convention: number messages in real execution order; a \`return\` comes
-after the \`sync\` call it answers. A \`self\` message has \`fromSlug === toSlug\`.
-
-Schematic example of the tool call:
-
-\`\`\`
-submit_sequence_diagram({
-  summary: "Email/password login: the browser posts credentials to AuthService, which verifies them against the users table and issues a JWT.",
-  participants: [
-    { slug: "user", name: "User", kind: "actor" },
-    { slug: "auth-service", name: "AuthService", kind: "service",
-      file: "src/routes/auth.ts" },
-    { slug: "users", name: "users", kind: "database",
-      file: "db/migrations/0001_users.sql" }
-  ],
-  messages: [
-    { fromSlug: "user", toSlug: "auth-service", kind: "sync", order: 1,
-      label: "POST /login {email, password}", sourceFile: "src/routes/auth.ts" },
-    { fromSlug: "auth-service", toSlug: "users", kind: "sync", order: 2,
-      label: "SELECT … WHERE email = ?", sourceFile: "src/routes/auth.ts" },
-    { fromSlug: "users", toSlug: "auth-service", kind: "return", order: 3,
-      label: "user row" },
-    { fromSlug: "auth-service", toSlug: "auth-service", kind: "self", order: 4,
-      label: "verifyPassword()" },
-    { fromSlug: "auth-service", toSlug: "user", kind: "return", order: 5,
-      label: "200 {token}" }
-  ]
-})
-\`\`\`
-`,
-    'state-diagram': `
-**CRITICAL — How to return the result**:
-
-Call \`mcp__state-diagram__submit_state_diagram\` **exactly once** with:
-- \`summary\` — what this state machine models
-- \`nodes\` — states: \`{ slug, name, kind, file?, description?, onEntry?, onExit?, activity? }\`; \`kind\` ∈ \`initial\` | \`state\` | \`final\` | \`choice\` | \`composite\` (exactly one \`initial\`)
-- \`edges\` — transitions: \`{ fromSlug, toSlug, kind: "transition", label?, sourceFile? }\`; put \`trigger [guard] / action\` in \`label\`
-
-Every fromSlug / toSlug MUST reference a node slug. The tool validates; on error,
-fix and call again. You may call \`mcp__state-diagram__record_progress\` for status.
-`,
-    'class-diagram': `
-**CRITICAL — How to return the result**:
-
-Call \`mcp__class-diagram__submit_class_diagram\` **exactly once** with:
-- \`summary\` — the core types and how they relate
-- \`nodes\` — \`{ slug, name, kind, file?, description?, stereotype?, attributes?: [{ name, type?, visibility?, isStatic? }], methods?: [{ name, params?, returnType?, visibility?, isStatic?, isAbstract? }] }\`; \`kind\` ∈ \`class\` | \`interface\` | \`abstract\` | \`enum\`
-- \`edges\` — \`{ fromSlug, toSlug, kind, label?, sourceFile? }\`; \`kind\` ∈ \`inheritance\` | \`implementation\` | \`composition\` | \`aggregation\` | \`association\` | \`dependency\` (fromSlug = child/owner/dependent)
-
-Every fromSlug / toSlug MUST reference a node slug. The tool validates; on error,
-fix and call again. You may call \`mcp__class-diagram__record_progress\` for status.
-`,
-    'architecture-diagram': `
-**CRITICAL — How to return the result**:
-
-Call \`mcp__architecture-diagram__submit_architecture_diagram\` **exactly once** with:
-- \`summary\` — the architecture and its main building blocks
-- \`nodes\` — components: \`{ slug, name, kind, file?, description?, tech?, responsibilities?: [string] }\`; \`kind\` ∈ \`module\` | \`service\` | \`package\` | \`ui\` | \`datastore\` | \`external\`
-- \`edges\` — dependencies: \`{ fromSlug, toSlug, kind, label?, sourceFile? }\`; \`kind\` ∈ \`depends-on\` | \`calls\` | \`imports\` | \`data\` (fromSlug = depender)
-
-Every fromSlug / toSlug MUST reference a node slug. The tool validates; on error,
-fix and call again. You may call \`mcp__architecture-diagram__record_progress\` for status.
-`,
-    flowchart: `
-**CRITICAL — How to return the result**:
-
-Call \`mcp__flowchart__submit_flowchart\` **exactly once** with:
-- \`summary\` — the process this flowchart captures
-- \`nodes\` — steps: \`{ slug, name, kind, file?, description? }\`; \`kind\` ∈ \`start\` | \`end\` | \`process\` | \`decision\` | \`io\` | \`subroutine\` (exactly one \`start\`)
-- \`edges\` — \`{ fromSlug, toSlug, kind, label?, sourceFile? }\`; \`kind\` ∈ \`flow\` | \`branch\` (branch edges out of a \`decision\` set \`label\` to "yes"/"no"/condition)
-
-Every fromSlug / toSlug MUST reference a node slug. The tool validates; on error,
-fix and call again. You may call \`mcp__flowchart__record_progress\` for status.
-`,
-};