@bridge_gpt/mcp-server 0.1.8 → 0.1.9

package/README.md

@@ -10,7 +10,7 @@ From your **project root**, install the MCP server and scaffold slash commands:
 
 ```bash
 npm i @bridge_gpt/mcp-server
-npx @bridge_gpt/mcp-server --init
+npx -y @bridge_gpt/mcp-server --init
 ```
 
 `--init` must be run from the directory containing your `package.json`. It:
@@ -36,6 +36,8 @@ Add the following to your editor's MCP configuration file, pasting in the API ke
 <details>
 <summary><strong>Claude Code (.mcp.json)</strong></summary>
 
+The `--init` command (step 1) detects Claude Code and creates a `.mcp.json` at your project root with placeholder values. Open it and replace `your-repo` and `your-api-key` with your actual values from step 2:
+
 ```json
 {
   "mcpServers": {
@@ -52,16 +54,6 @@ Add the following to your editor's MCP configuration file, pasting in the API ke
   }
 }
 ```
-
-Or via CLI:
-
-```bash
-claude mcp add bridge-api -- npx -y @bridge_gpt/mcp-server \
-  --env BAPI_BASE_URL=https://bridgegpt-api.com \
-  --env BAPI_REPO_NAME=your-repo \
-  --env BAPI_API_KEY=your-api-key \
-  --env BAPI_DOCS_DIR=docs/tmp
-```
 </details>
 
 <details>
@@ -157,70 +149,171 @@ If you're the first person to install Bridge API on your project, run the `/lear
 
 You only need to do this once per project — the learned standards persist for all team members.
 
-## Commands & Pipelines
+## Pipelines
+
+Pipelines are declarative, multi-step workflows that your AI agent executes step-by-step. Each pipeline is a JSON recipe that chains MCP tool calls and free-form agent tasks, with variable substitution, per-step error handling, and optional approval gates. Bridge ships with built-in pipelines; you can also write your own (see [Custom Pipelines](#custom-pipelines)).
+
+| Pipeline | Description | Invoke with |
+|---|---|---|
+| `implement-ticket` | Generate a plan, execute the implementation, commit, open a PR, and monitor CI | `/implement-ticket PROJ-123` |
+| `review-ticket` | Two-round ticket quality review: clarifying questions and critique from multiple providers | `/review-ticket PROJ-123` |
+| `learn-repository` | Analyze codebase architecture, testing patterns, review standards, and documentation conventions, then upload to Bridge | `/learn-repository` |
+| `pr-ticket` | Commit changes and open a pull request | `/create-pr PROJ-123` |
+| `check-ci-ticket` | Commit, open a PR, then monitor CI checks until they pass or fail | `/check-ci PROJ-123` |
+
+## Commands
 
-Slash commands are available after running `--init`. Invoke them from your AI assistant's chat.
+Commands are slash commands you invoke from your AI assistant's chat. Most orchestrate multi-step workflows; some are simple single-action utilities. Run `--init` to scaffold them into your project.
 
 | Command | Description |
 |---|---|
-| `/explore-ticket` | Free-form codebase exploration — searches code, runs research, writes analysis with implementation options |
-| `/review-ticket PROJ-123` | Two-round ticket quality review with clarifying questions and critiques from multiple LLM providers |
-| `/implement-ticket PROJ-123` | End-to-end implementation — generates a plan, executes it, commits, opens a PR, monitors CI |
-| `/learn-repository` | Teaches Bridge API about your codebase by analyzing architecture, testing, and review patterns |
+| `/check-ci [PROJ-123]` | Monitor CI checks for the current branch, triage failures, apply fixes, and report results |
+| `/check-parse-status` | Check whether a background repository parse job is still running |
+| `/clarify-ticket PROJ-123` | Generate clarifying questions for a ticket and save them locally |
+| `/code-ticket PROJ-123` | Download the implementation plan and questions, then execute the plan inline |
+| `/commit-ticket PROJ-123` | Stage, commit, and push changes; transition Jira status; post a smoke-test comment |
+| `/create-pr PROJ-123` | Commit staged changes and open a pull request |
+| `/critique-ticket PROJ-123` | Generate a ticket quality critique and save it locally |
+| `/explore-ticket [PROJ-123]` | Free-form codebase exploration — searches code, surfaces implementation options and questions |
+| `/implement-ticket PROJ-123` | Full end-to-end implementation: plan → code → commit → PR → CI |
+| `/learn-repository` | Teach Bridge API about your codebase (architecture, testing, review patterns) |
+| `/parse-repository` | Queue a background job to index the repository for Bridge AI agents |
+| `/plan-ticket PROJ-123` | Generate an AI implementation plan and save it locally |
+| `/reimplement-ticket PROJ-123` | Follow-up implementation pass using previous implementation context |
+| `/review-ticket PROJ-123` | Two-round ticket quality review with critiques from multiple LLM providers |
+| `/run-tests` | Run the full test suite, triage failures, and classify issues as test bugs vs. implementation bugs |
+| `/scan-tickets` | Sync recently-updated Jira tickets and backfill workflow timestamps |
+| `/teach-bridge` | Update a Bridge API configuration field via natural-language instructions |
+| `/update-ticket PROJ-123` | Fetch clarifying questions and critique, then rewrite the ticket description and push to Jira |
+| `/write-ticket` | Draft a new Jira ticket from a prompt and upload it |
+
+> Commands are designed for Claude Code. Other editors may support slash commands differently — check your editor's documentation for how to invoke prompt files.
 
 ## Available Tools
 
+MCP tools are the low-level primitives Bridge exposes to your AI assistant. You don't call them directly — ask your AI assistant to perform the task you need, or compose them into a custom pipeline.
+
+### Connectivity
+
+| Tool | Description |
+|---|---|
+| `ping` | Verify connectivity and confirm your API key is valid |
+
+### Jira Tickets
+
 | Tool | Description |
 |---|---|
-| `ping` | Health check — verify connectivity and API key |
-| `get_project_standards` | Retrieve configured coding standards |
-| `get_tickets` | Search and list Jira tickets |
+| `get_tickets` | Search and list Jira tickets by query, status, or date |
 | `get_ticket` | Get full details for a single ticket |
 | `create_ticket` | Create a new Jira ticket |
-| `add_comment` | Add a comment to a ticket |
+| `add_comment` | Post a comment on a ticket |
 | `update_ticket_description` | Replace a ticket's description |
-| `upload_attachment` | Upload a file as an attachment to a Jira ticket |
-| `request_plan_generation` | Generate an AI implementation plan (async) |
+| `upload_attachment` | Upload a file as a ticket attachment |
+
+### AI Generation
+
+Async tools follow a request/get pattern: call the `request_*` tool to kick off generation, then call the matching `get_*` tool to retrieve the result (or pass `wait_for_result: true` to poll automatically).
+
+| Tool | Description |
+|---|---|
+| `request_plan_generation` | Request an AI-generated implementation plan |
 | `get_plan` | Retrieve a generated implementation plan |
-| `request_architecture` | Generate an AI architecture plan (async) |
+| `request_architecture` | Request an AI-generated architecture plan |
 | `get_architecture` | Retrieve a generated architecture plan |
-| `request_clarifying_questions` | Generate clarifying questions for a ticket (async) |
+| `request_clarifying_questions` | Request clarifying questions for a ticket |
 | `get_clarifying_questions` | Retrieve generated clarifying questions |
-| `request_ticket_critique` | Generate a ticket quality critique (async) |
+| `request_ticket_critique` | Request a ticket quality critique |
 | `get_ticket_critique` | Retrieve a generated ticket critique |
-| `request_reimplement_context` | Request reimplementation context (async) |
-| `get_reimplement_context` | Retrieve reimplementation context |
-| `request_deep_research` | Run deep research on a query (async) |
+| `request_reimplement_context` | Request context assembly for a follow-up implementation |
+| `get_reimplement_context` | Retrieve assembled reimplementation context |
+| `request_deep_research` | Submit a deep research query |
 | `get_deep_research` | Retrieve deep research results |
-| `parse_repository` | Parse and index a repository (async) |
-| `get_parse_status` | Check repository parse status |
-| `regenerate_directory_map` | Regenerate the repository directory map |
+
+### Ticket Lifecycle
+
+| Tool | Description |
+|---|---|
 | `track_ticket` | Register a ticket for lifecycle tracking |
-| `update_ticket_state` | Update ticket lifecycle timestamps |
-| `get_ticket_state` | Get ticket tracking state and timestamps |
-| `list_config_fields` | List available configuration fields |
-| `get_config_field` | Get a configuration field value |
-| `update_config_field` | Update a configuration field |
-| `get_my_role` | Check role and permissions for the current API key |
-| `get_jira_transitions` | List available Jira status transitions |
-| `update_jira_status` | Transition a ticket to a new status |
+| `update_ticket_state` | Update workflow timestamps for a tracked ticket |
+| `get_ticket_state` | Get workflow state and timestamps for a tracked ticket |
+
+### Jira Status
+
+| Tool | Description |
+|---|---|
+| `get_jira_transitions` | List available status transitions for a ticket |
+| `update_jira_status` | Transition a ticket to a new Jira status |
 | `resolve_target_status` | Resolve the post-PR target status for a project |
-| `create_pull_request` | Create a pull request |
-| `resolve_ci_checks` | Discover and classify CI checks |
-| `poll_ci_checks` | Poll CI check status |
-| `get_docs_dir` | Return the configured docs directory path |
-| `list_pipelines` | List available pipeline recipes |
-| `get_pipeline_recipe` | Retrieve a resolved pipeline recipe |
+
+### Configuration
+
+| Tool | Description |
+|---|---|
+| `get_project_standards` | Retrieve configured coding standards and architecture guidelines |
+| `list_config_fields` | List all available configuration fields |
+| `get_config_field` | Read the current value of a configuration field |
+| `update_config_field` | Update a configuration field |
+| `get_my_role` | Check the role and permissions for the current API key |
+
+### Repository & CI
+
+| Tool | Description |
+|---|---|
+| `parse_repository` | Queue a background job to parse and index the repository |
+| `get_parse_status` | Check whether a repository parse is in progress |
+| `regenerate_directory_map` | Regenerate the repository directory map |
+| `create_pull_request` | Create a pull request on GitHub or Bitbucket |
+| `resolve_ci_checks` | Discover and classify CI checks for a commit |
+| `poll_ci_checks` | Poll the current status of CI checks |
+
+### Pipelines
+
+| Tool | Description |
+|---|---|
+| `get_docs_dir` | Return the configured local docs directory path |
+| `list_pipelines` | List available pipeline recipes with names and descriptions |
+| `get_pipeline_recipe` | Retrieve a fully resolved pipeline recipe with variables substituted |
 
 ## Custom Pipelines
 
-You can create your own pipelines by placing JSON files in `.bridge/pipelines/` (or the directory specified by `BAPI_PIPELINES_DIR`). Custom pipelines are loaded at server startup and appear alongside bundled pipelines in `list_pipelines`.
+You can create your own pipelines by adding JSON files to `.bridge/pipelines/`. Running `--init` scaffolds this directory with a `README.md` and an example pipeline to get you started.
+
+The easiest way to write a custom pipeline is to describe what you want to automate to your AI coding agent and have it draft the JSON for you. The schema is straightforward, and agents like Claude Code understand it well — just describe the steps you want, and the agent will produce a working pipeline file.
+
+**What you can build:**
+
+- Any sequence of Bridge MCP tool calls and free-form agent tasks
+- Parameterized workflows using variables (e.g., `{ticket_key}`)
+- Approval gates that pause for user confirmation before sensitive steps
+- Per-step error handling — halt immediately or warn and continue
+
+**Ideas for custom pipelines:**
+
+- A standup pipeline that fetches your open tickets and summarizes their status
+- A ticket triage pipeline that runs critiques on a batch of new tickets
+- A pre-merge checklist that runs tests, checks linting, and posts a summary comment
 
-1. Run `npx @bridge_gpt/mcp-server --init` to scaffold the directory structure with a README and example pipeline.
-2. Add pipeline JSON files to `.bridge/pipelines/`.
-3. Optionally add instruction markdown files to `.bridge/instructions/` and reference them via `instruction_file` in your pipeline steps.
+**Step types:**
 
-If a custom pipeline has the same key as a bundled pipeline, it overrides the bundled one (a warning is logged at startup).
+| Type | What it does |
+|---|---|
+| `mcp_call` | Calls an MCP tool with the given params |
+| `agent_task` | Gives the AI a free-form instruction (inline or from a file in `.bridge/instructions/`) |
+
+Variables are declared in the `variables` array and referenced as `{variable_name}` in params and instructions. Each step supports `on_error: "halt"` (default) or `"warn_and_continue"`, and `requires_approval: true` to pause before execution.
+
+**System variables:**
+
+Two variables are automatically available in every pipeline without declaring them:
+
+| Variable | What it does |
+|---|---|
+| `{provider}` | Routes AI generation to a specific LLM provider (`openai`, `anthropic`, or `gemini`). Pass it through to any `request_*` tool param to control which provider handles that step. Omit it (or leave it empty) to use the project default. |
+| `{second_opinion}` | Runs AI generation through a different provider than the default, acting as a cross-check. Set to `"auto"` to let Bridge pick the second provider automatically. When set, it takes precedence over `{provider}`. Use this when you want two independent AI perspectives on the same task — for example, running clarifying questions and a critique twice (once with each provider) produces better results than a single pass. |
+
+See `.bridge/pipelines/README.md` for the full schema reference.
+
+If a custom pipeline has the same key as a built-in pipeline, the custom version takes precedence (a warning is logged at startup).
 
 ## Environment Variables
 
@@ -232,19 +325,3 @@ If a custom pipeline has the same key as a bundled pipeline, it overrides the bu
 | `BAPI_PROJECT_ROOT` | No | _(auto-set by --init)_ | Absolute path to project root. Anchors `BAPI_DOCS_DIR` and `BAPI_PIPELINES_DIR` resolution |
 | `BAPI_DOCS_DIR` | No | `docs/tmp` | Local directory for saving plans, critiques, and research reports |
 | `BAPI_PIPELINES_DIR` | No | `.bridge/pipelines` | Directory for user-defined custom pipeline JSON files |
-
-## Publishing
-
-This package uses tag-based publishing. To release a new version:
-
-```bash
-cd mcp_server
-npm version patch    # creates tag mcp-server/v0.1.x
-git push --follow-tags
-```
-
-The GitHub Actions workflow triggers on `mcp-server/v*` tags and publishes to npm with provenance.
-
-## License
-
-MIT

package/build/agent-utils.js

@@ -0,0 +1,110 @@
+/**
+ * Agent utility functions for reconstructing and translating agent definitions
+ * across different IDE platforms.
+ */
+// Deterministic key order: known fields first, then remaining sorted alphabetically
+const SCHEMA_KEY_ORDER = ["name", "description", "model", "tools"];
+// Claude Code-specific fields that have no Copilot equivalent
+const COPILOT_STRIPPED_FIELDS = new Set([
+    "memory", "hooks", "permissionMode", "skills", "isolation",
+    "maxTurns", "color", "effort", "background", "disallowedTools",
+]);
+// Characters that require YAML quoting
+const YAML_SPECIAL = /[:#{}[\]\n"'|>@`!&*?,]/;
+function quoteYamlValue(value) {
+    if (YAML_SPECIAL.test(value)) {
+        return JSON.stringify(value);
+    }
+    return value;
+}
+function orderedKeys(frontmatter) {
+    const keys = Object.keys(frontmatter);
+    const ordered = [];
+    // Add schema-ordered keys first (if present)
+    for (const key of SCHEMA_KEY_ORDER) {
+        if (keys.includes(key))
+            ordered.push(key);
+    }
+    // Add remaining keys sorted alphabetically
+    const remaining = keys.filter(k => !SCHEMA_KEY_ORDER.includes(k)).sort();
+    ordered.push(...remaining);
+    return ordered;
+}
+function serializeFrontmatter(frontmatter, keys) {
+    const lines = [];
+    for (const key of keys) {
+        const value = frontmatter[key];
+        if (typeof value === "string") {
+            lines.push(`${key}: ${quoteYamlValue(value)}`);
+        }
+        else if (typeof value === "boolean" || typeof value === "number") {
+            lines.push(`${key}: ${value}`);
+        }
+        else {
+            // Arrays or objects — use JSON.stringify for safety
+            lines.push(`${key}: ${JSON.stringify(value)}`);
+        }
+    }
+    return lines.join("\n");
+}
+/**
+ * Reconstruct a Claude Code-native agent markdown file from parsed frontmatter and body.
+ */
+export function reconstructAgentMarkdown(frontmatter, body) {
+    const keys = orderedKeys(frontmatter);
+    const yaml = serializeFrontmatter(frontmatter, keys);
+    return `---\n${yaml}\n---\n${body}`;
+}
+/**
+ * Translate a Claude Code agent definition into GitHub Copilot .agent.md format.
+ *
+ * - model: always set to "Auto" (Copilot doesn't support shorthands)
+ * - mcpServers -> mcp-servers
+ * - tools: comma-separated string -> YAML block array
+ * - Claude Code-specific fields are stripped
+ */
+export function translateAgentToCopilot(frontmatter, body) {
+    const translated = {};
+    for (const [key, value] of Object.entries(frontmatter)) {
+        // Strip Claude Code-specific fields
+        if (COPILOT_STRIPPED_FIELDS.has(key))
+            continue;
+        if (key === "model") {
+            translated["model"] = "Auto";
+        }
+        else if (key === "mcpServers") {
+            translated["mcp-servers"] = value;
+        }
+        else if (key === "tools" && typeof value === "string") {
+            // Convert comma-separated tools to array for YAML block format
+            translated["tools"] = value.split(",").map(t => t.trim()).filter(Boolean);
+        }
+        else {
+            translated[key] = value;
+        }
+    }
+    // Build frontmatter with deterministic key ordering
+    const keys = orderedKeys(translated);
+    const lines = [];
+    for (const key of keys) {
+        const value = translated[key];
+        if (Array.isArray(value)) {
+            // YAML block array format
+            lines.push(`${key}:`);
+            for (const item of value) {
+                lines.push(`  - ${quoteYamlValue(String(item))}`);
+            }
+        }
+        else if (typeof value === "string") {
+            lines.push(`${key}: ${quoteYamlValue(value)}`);
+        }
+        else if (typeof value === "boolean" || typeof value === "number") {
+            lines.push(`${key}: ${value}`);
+        }
+        else {
+            lines.push(`${key}: ${JSON.stringify(value)}`);
+        }
+    }
+    const yaml = lines.join("\n");
+    return `---\n${yaml}\n---\n${body}`;
+}

package/build/agents.generated.js

@@ -0,0 +1,13 @@
+// AUTO-GENERATED — do not edit manually. Regenerate with: npm run build
+// This file is produced by scripts/bundle-agents.js
+export const AGENTS = {
+    "jira-ticket-writer": {
+        "frontmatter": {
+            "name": "jira-ticket-writer",
+            "description": "Use this agent when the user describes a problem, feature request, bug, or improvement and wants a structured Jira ticket written as a markdown file. This agent performs deep codebase research before writing the ticket to ensure requirements reference existing code, patterns, and extension points.\\n\\nExamples:\\n\\n<example>\\nContext: The user describes a feature they want to add to the project.\\nuser: \"We need to add rate limiting to our LLM integration so we don't exceed provider quotas\"\\nassistant: \"I'll use the Task tool to launch the jira-ticket-writer agent to research the codebase and create a structured Jira ticket for this feature.\"\\n<commentary>\\nSince the user is describing a problem/feature that needs a Jira ticket, use the jira-ticket-writer agent to research the codebase thoroughly and produce a well-structured ticket with code references.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user wants a ticket for a bug fix.\\nuser: \"There's an issue where custom object iterators aren't being closed properly in some of our job scripts, can you write a ticket for that?\"\\nassistant: \"I'll use the Task tool to launch the jira-ticket-writer agent to investigate which job scripts have this issue and create a detailed Jira ticket.\"\\n<commentary>\\nThe user explicitly wants a Jira ticket written. Use the jira-ticket-writer agent so it can scan the relevant job scripts, identify the specific files and functions affected, and produce a ticket with precise code references.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user describes an improvement they want.\\nuser: \"We should add support for a new LLM provider - Mistral - to our integration cartridge\"\\nassistant: \"Let me use the Task tool to launch the jira-ticket-writer agent to research the existing LLM integration architecture and write a comprehensive Jira ticket for adding Mistral support.\"\\n<commentary>\\nThe user wants a new feature added. The jira-ticket-writer agent will research the existing LLM client architecture, provider patterns, service definitions, and normalization helpers to write a ticket that references all the specific files and patterns that need to be extended.\\n</commentary>\\n</example>",
+            "model": "opus",
+            "color": "blue"
+        },
+        "body": "\nYou are an elite software engineering project manager and technical analyst with deep expertise in codebase archaeology and Jira ticket crafting. You excel at understanding complex codebases, identifying relevant existing code, and translating problem descriptions into precisely-scoped, actionable Jira tickets that engineers can pick up and execute with minimal ambiguity.\n\n## Your Mission\n\nGiven a problem description from the user, you will:\n1. Conduct thorough codebase research to understand the existing architecture, patterns, and relevant code\n2. Write a structured Jira ticket as a new markdown file that references specific files, functions, and patterns from the codebase\n\n## Phase 1: Deep Codebase Research\n\nThis is the most critical phase. You MUST spend significant time here before writing anything. Do NOT rush this phase.\n\n### Research Protocol\n\n1. **Understand the Problem Space**: Re-read the user's problem description carefully. Identify the domain, the affected areas, and the type of change needed (new feature, bug fix, refactor, enhancement).\n\n2. **Map the Relevant Architecture**: \n   - Search for files, modules, and directories related to the problem domain\n   - Read the key source files thoroughly — do not skim\n   - Trace code paths: how does data flow through the relevant parts of the system?\n   - Identify controller -> helper -> service -> model chains if applicable\n\n3. **Identify Extension Points**:\n   - What existing code can be reused or extended?\n   - What patterns does the codebase already use for similar functionality?\n   - Are there helper functions, utilities, or base classes that should be leveraged?\n   - Are there configuration files, metadata definitions, or templates that need modification?\n\n4. **Identify Constraints**:\n   - What conventions does the project follow? (Check CLAUDE.md, README, existing patterns)\n   - What testing patterns are used?\n   - Are there ES5 limitations, specific framework patterns, or platform constraints?\n\n5. **Catalog Your Findings**: Keep mental notes of every relevant file path, function name, pattern, and architectural decision you discover. You will reference these in the ticket.\n\n### Research Depth Guidelines\n- Read at least 5-15 relevant source files in full, more if the problem is complex\n- Follow import chains to understand dependencies\n- Check test files to understand expected behaviors and testing patterns\n- Review configuration and metadata files if relevant\n- Search for TODO comments, known limitations, or related existing issues in the code\n\n## Phase 2: Write the Jira Ticket\n\nAfter completing research, create a new markdown file with the ticket. Use the naming convention `tickets/TICKET-<short-descriptive-name>.md`. If the `tickets/` directory does not exist, create it.\n\n### Ticket Structure\n\nThe markdown file MUST contain exactly these sections:\n\n```markdown\n# [Concise Title Describing the Task]\n\n## Summary\n\n[2-4 sentences describing what this task is about, why it matters, and the high-level approach. Be specific — reference the actual system components involved.]\n\n## Requirements\n\n[Numbered list of specific, actionable requirements. Each requirement should be a clear unit of work.]\n\n1. **[Requirement Title]**: [Description of what needs to be done.]\n   - *Relevant code*: `path/to/file.js` — `functionName()` [brief note on how this code relates]\n   - *Relevant code*: `path/to/other/file.js` — [brief note]\n\n2. **[Requirement Title]**: [Description]\n   - *Relevant code*: ...\n\n[Continue for all requirements]\n\n## Acceptance Criteria\n\n[Checklist format using markdown checkboxes. Each criterion is a testable, verifiable condition.]\n\n- [ ] [Specific, testable criterion]\n- [ ] [Another criterion]\n- [ ] [Continue as needed]\n```\n\n### Writing Guidelines\n\n**Summary**:\n- Be concrete, not abstract. Name the actual components, cartridges, or subsystems involved.\n- State the \"why\" — what problem does this solve or what value does it add?\n- Mention the general technical approach if it's clear from the research.\n\n**Requirements**:\n- Each requirement should represent a logical unit of work\n- Order requirements in a logical implementation sequence when possible\n- ALWAYS cite relevant existing files and functions when they exist. Use exact file paths relative to the project root.\n- Explain HOW the existing code relates: \"extend this function\", \"follow this pattern\", \"reuse this helper\", \"modify this configuration\"\n- If a requirement involves creating new files, suggest where they should live based on existing project structure conventions\n- Be specific about what needs to change vs. what needs to be created new\n- Include requirements for tests, documentation, and configuration/metadata changes if applicable\n\n**Acceptance Criteria**:\n- Every criterion must be independently verifiable\n- Cover functional requirements, edge cases, testing, and non-functional requirements\n- Include criteria for backwards compatibility if relevant\n- Include criteria for test coverage\n- Use checkbox format (`- [ ]`) so engineers can track progress\n\n## Quality Standards\n\n- **No vague language**: Replace \"should handle errors properly\" with \"should catch LLM provider timeouts and return a normalized error response with errorType 'TimeoutError'\"\n- **No assumptions without evidence**: Only reference code you actually read during research. If you're unsure about something, say so explicitly in the ticket.\n- **Appropriate scope**: The ticket should represent a coherent, deliverable unit of work. If the problem is too large, note that it may need to be broken into sub-tasks, but still write the parent ticket.\n- **Developer empathy**: Write as if the developer picking this up has general project knowledge but hasn't recently worked on this specific area. Give them enough context to get started quickly.\n\n## Important Reminders\n\n- Do NOT skip or abbreviate the research phase. The quality of the ticket depends entirely on the depth of your codebase understanding.\n- Do NOT make up file paths or function names. Only reference code you have actually found and read.\n- DO create the markdown file — do not just output the content to the chat. Write it to disk.\n- If the project has specific conventions (from CLAUDE.md or similar), ensure your ticket's requirements align with those conventions.\n"
+    }
+};