mcp-server-agents-md/src/tools.ts

A unified MCP server for managing agent definition Markdown files (rules, workflows, subagents, claude.md, cursorrule, windsurfrule etc). Write once, use everywhere.

// This file is auto-generated by generate-tools.js. Do not edit manually.
// Generated at: 2025-08-21T02:06:29.025Z

import type { Tool } from '@modelcontextprotocol/sdk/types.js';

export interface AgentMetaInfo {
  name: string;
  description: string;
  /** Triggers quickly allow LLM to identify calling tools, which is more accurate than natural language prompts. */
  trigger: string;
}

export interface AgentToolMetadata {
  tool: Tool;
  prompt: string;
  metaInfo: AgentMetaInfo;
}

export const agentTools: Record<string, AgentToolMetadata> = {
  "add_to_changelog": {
    "tool": {
      "name": "add_to_changelog",
      "description": "Update the project's CHANGELOG.md file with a new entry. It can be triggered by commands one of \"cc:changelog\",\"cc:add-to-changelog\",\"cc:update-changelog\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Add to Changelog\n\nUpdate the project's CHANGELOG.md file with a new entry.\n\n## Usage\n\n`/add-to-changelog <version> <change_type> <message>`\n\n## Parameters\n\n- `<version>`: Version number (e.g., \"1.1.0\")\n- `<change_type>`: One of: \"added\", \"changed\", \"deprecated\", \"removed\", \"fixed\", \"security\"\n- `<message>`: Description of the change\n\n## Examples\n\n- `/add-to-changelog 1.1.0 added \"New markdown to BlockDoc conversion feature\"`\n- `/add-to-changelog 1.0.2 fixed \"Bug in HTML renderer causing incorrect output\"`\n\n## Steps\n\n1. Check for existing CHANGELOG.md or create if missing\n2. Find or create section for the specified version\n3. Add the new entry under the appropriate change type\n4. Format according to Keep a Changelog conventions\n5. Write the updated changelog back to file\n6. Optionally commit the changes with appropriate message\n\n## Format\n\nFollow [Keep a Changelog](https://keepachangelog.com) format:\n\n- Group changes by type\n- List changes as bullet points\n- Include date for version sections\n- Keep entries concise but descriptive\n",
    "metaInfo": {
      "name": "add_to_changelog",
      "description": "Update the project's CHANGELOG.md file with a new entry.",
      "trigger": "changelog,add-to-changelog,update-changelog"
    }
  },
  "analyze_issue": {
    "tool": {
      "name": "analyze_issue",
      "description": "Fetch GitHub issue details and create a comprehensive implementation specification. It can be triggered by commands one of \"cc:issue-report\",\"cc:analyze-issue\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Analyze Issue\n\nFetch GitHub issue details and create a comprehensive implementation specification.\n\n## Template Sections\n\n### 1. Issue Summary\n\nBrief overview of the issue\n\n### 2. Problem Statement\n\nClear definition of what needs to be solved\n\n### 3. Technical Approach\n\nHigh-level solution approach and architecture decisions\n\n### 4. Implementation Plan\n\nStep-by-step breakdown of implementation tasks\n\n### 5. Test Plan\n\nTesting strategy and test cases to write\n\n### 6. Files to Modify\n\nList of existing files that need changes\n\n### 7. Files to Create\n\nNew files that need to be created\n\n### 8. Existing Utilities to Leverage\n\nProject utilities/helpers that can be reused\n\n### 9. Success Criteria\n\nMeasurable criteria for completion\n\n### 10. Out of Scope\n\nWhat won't be addressed in this implementation\n\n## Process\n\n1. Fetch issue details using `gh issue view <issue_number>`\n2. Review related code and project structure\n3. Analyze requirements thoroughly\n4. Create detailed technical specification\n5. Follow strict TDD principles, KISS approach\n6. Enforce 300-line file limit where applicable\n7. Output the full technical specification for review\n",
    "metaInfo": {
      "name": "analyze_issue",
      "description": "Fetch GitHub issue details and create a comprehensive implementation specification.",
      "trigger": "issue-report,analyze-issue"
    }
  },
  "bug_fix": {
    "tool": {
      "name": "bug_fix",
      "description": "Streamline bug fixing workflow from issue creation to pull request. It can be triggered by commands one of \"cc:bugfix\",\"cc:code-bugfix\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Bug Fix\n\nStreamline bug fixing workflow from issue creation to pull request.\n\n## Process\n\n### Before Starting\n\n1. **GitHub**: Create an issue with a short descriptive title\n2. **Git**: Create and checkout a feature branch (`git checkout -b fix/<issue-description>`)\n\n### Fix the Bug\n\n1. Reproduce the issue\n2. Write failing test that demonstrates the bug\n3. Implement the fix\n4. Verify test passes\n5. Run full test suite\n6. Review code changes\n\n### On Completion\n\n1. **Git**: Commit with descriptive message referencing the issue\n   - Format: `fix: <description> (#<issue-number>)`\n2. **Git**: Push the branch to remote repository\n3. **GitHub**: Create PR and link the issue\n   - Use \"Fixes #<issue-number>\" in PR description\n   - Add relevant labels and reviewers\n\n## Best Practices\n\n- Keep changes focused on the specific bug\n- Include regression tests\n- Update documentation if behavior changes\n- Consider edge cases and related issues\n",
    "metaInfo": {
      "name": "bug_fix",
      "description": "Streamline bug fixing workflow from issue creation to pull request.",
      "trigger": "bugfix,code-bugfix"
    }
  },
  "check": {
    "tool": {
      "name": "check",
      "description": "Perform comprehensive code quality and security checks. It can be triggered by commands one of \"cc:check\",\"cc:code-check\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Check\n\nPerform comprehensive code quality and security checks.\n\n## Primary Task\n\nRun `npm run check` (or project-specific check command) and resolve any resulting errors.\n\n## Important\n\n- DO NOT commit any code during this process\n- DO NOT change version numbers\n- Focus only on fixing issues identified by checks\n\n## Common Checks Include\n\n1. **Linting**: Code style and syntax errors\n2. **Type Checking**: TypeScript/Flow type errors\n3. **Unit Tests**: Failing test cases\n4. **Security Scan**: Vulnerability detection\n5. **Code Formatting**: Style consistency\n6. **Build Verification**: Compilation errors\n\n## Process\n\n1. Run the check command\n2. Analyze output for errors and warnings\n3. Fix issues in priority order:\n   - Build-breaking errors first\n   - Test failures\n   - Linting errors\n   - Warnings\n4. Re-run checks after each fix\n5. Continue until all checks pass\n\n## For Different Project Types\n\n- **JavaScript/TypeScript**: `npm run check` or `yarn check`\n- **Python**: `black`, `isort`, `flake8`, `mypy`\n- **Rust**: `cargo check`, `cargo clippy`\n- **Go**: `go vet`, `golint`\n- **Swift**: `swift-format`, `swiftlint`\n",
    "metaInfo": {
      "name": "check",
      "description": "Perform comprehensive code quality and security checks.",
      "trigger": "check,code-check"
    }
  },
  "clean": {
    "tool": {
      "name": "clean",
      "description": "Fix all code formatting and quality issues in the entire codebase. It can be triggered by commands one of \"cc:clean\",\"cc:code-clean\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Clean\n\nFix all code formatting and quality issues in the entire codebase.\n\n## Python Projects\n\nFix all `black`, `isort`, `flake8`, and `mypy` issues\n\n### Steps\n\n1. **Format with Black**: `black .`\n2. **Sort imports with isort**: `isort .`\n3. **Fix flake8 issues**: `flake8 . --extend-ignore=E203`\n4. **Resolve mypy type errors**: `mypy .`\n\n## JavaScript/TypeScript Projects\n\nFix all ESLint, Prettier, and TypeScript issues\n\n### Steps\n\n1. **Format with Prettier**: `npx prettier --write .`\n2. **Fix ESLint issues**: `npx eslint . --fix`\n3. **Check TypeScript**: `npx tsc --noEmit`\n\n## General Process\n\n1. Run automated formatters first\n2. Fix remaining linting issues manually\n3. Resolve type checking errors\n4. Verify all tools pass with no errors\n5. Review changes before committing\n\n## Common Issues\n\n- Import order conflicts between tools\n- Line length violations\n- Unused imports/variables\n- Type annotation requirements\n- Missing return types\n- Inconsistent quotes/semicolons\n",
    "metaInfo": {
      "name": "clean",
      "description": "Fix all code formatting and quality issues in the entire codebase.",
      "trigger": "clean,code-clean"
    }
  },
  "code_analysis": {
    "tool": {
      "name": "code_analysis",
      "description": "Perform advanced code analysis with multiple inspection options. It can be triggered by commands one of \"cc:code-analysis\",\"cc:code-report\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Code Analysis\n\nPerform advanced code analysis with multiple inspection options.\n\n## Analysis Menu\n\n### 1. Knowledge Graph Generation\n\n- Map relationships between components\n- Visualize dependencies\n- Identify architectural patterns\n\n### 2. Code Quality Evaluation\n\n- Complexity metrics\n- Maintainability index\n- Technical debt assessment\n- Code duplication detection\n\n### 3. Performance Analysis\n\n- Identify bottlenecks\n- Memory usage patterns\n- Algorithm complexity\n- Database query optimization\n\n### 4. Security Review\n\n- Vulnerability scanning\n- Input validation checks\n- Authentication/authorization review\n- Sensitive data handling\n\n### 5. Architecture Review\n\n- Design pattern adherence\n- SOLID principles compliance\n- Coupling and cohesion analysis\n- Module boundaries\n\n### 6. Test Coverage Analysis\n\n- Coverage percentages\n- Untested code paths\n- Test quality assessment\n- Missing edge cases\n\n## Process\n\n1. Select analysis type based on need\n2. Run appropriate tools and inspections\n3. Generate comprehensive report\n4. Provide actionable recommendations\n5. Prioritize improvements by impact\n\n## Output Format\n\n- Executive summary\n- Detailed findings\n- Risk assessment\n- Improvement roadmap\n- Code examples where relevant\n",
    "metaInfo": {
      "name": "code_analysis",
      "description": "Perform advanced code analysis with multiple inspection options.",
      "trigger": "code-analysis,code-report"
    }
  },
  "fast_git_commit": {
    "tool": {
      "name": "fast_git_commit",
      "description": "Generate 3 commit message suggestions based on the staged changes. It can be triggered by commands one of \"cc:fast-commit\",\"cc:fast-git-commit\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Fast Commit Task\n\nGenerate 3 commit message suggestions based on the staged changes, then automatically use the first suggestion without user confirmation.\n\nFollow conventional commit format with appropriate emojis and create descriptive messages that explain the purpose of changes. Skip the manual message selection step to streamline the commit process.\n\n## Steps\n\n1. Run `git status` to see staged changes\n2. Generate 3 commit message suggestions following conventional commit format\n3. Automatically select the first suggestion\n4. Execute `git commit -m` with the selected message\n5. Exclude Claude co-authorship footer from commits\n\n## Commit Types\n\n- ✨ feat: New features\n- 🐛 fix: Bug fixes\n- 📝 docs: Documentation changes\n- ♻️ refactor: Code restructuring\n- 🧑‍💻 chore: Tooling and maintenance\n- 🎨 style: Code formatting, missing semicolons, etc.\n- ⚡️ perf: Performance improvements\n- ✅ test: Adding or correcting tests\n",
    "metaInfo": {
      "name": "fast_git_commit",
      "description": "Generate 3 commit message suggestions based on the staged changes.",
      "trigger": "fast-commit,fast-git-commit"
    }
  },
  "git_commit": {
    "tool": {
      "name": "git_commit",
      "description": "Create well-formatted commits with conventional commit messages and emojis. It can be triggered by commands one of \"cc:commit\",\"cc:git-commit\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Commit\n\nCreate well-formatted commits with conventional commit messages and emojis.\n\n## Features\n\n- Runs pre-commit checks by default (lint, build, generate docs)\n- Automatically stages files if none are staged\n- Uses conventional commit format with descriptive emojis\n- Suggests splitting commits for different concerns\n\n## Usage\n\n- `/commit` - Standard commit with pre-commit checks\n- `/commit --no-verify` - Skip pre-commit checks\n\n## Commit Types\n\n- ✨ feat: New features\n- 🐛 fix: Bug fixes\n- 📝 docs: Documentation changes\n- ♻️ refactor: Code restructuring without changing functionality\n- 🎨 style: Code formatting, missing semicolons, etc.\n- ⚡️ perf: Performance improvements\n- ✅ test: Adding or correcting tests\n- 🧑‍💻 chore: Tooling, configuration, maintenance\n- 🚧 wip: Work in progress\n- 🔥 remove: Removing code or files\n- 🚑 hotfix: Critical fixes\n- 🔒 security: Security improvements\n\n## Process\n\n1. Check for staged changes (`git status`)\n2. If no staged changes, review and stage appropriate files\n3. Run pre-commit checks (unless --no-verify)\n4. Analyze changes to determine commit type\n5. Generate descriptive commit message\n6. Include scope if applicable: `type(scope): description`\n7. Add body for complex changes explaining why\n8. Execute commit\n\n## Best Practices\n\n- Keep commits atomic and focused\n- Write in imperative mood (\"Add feature\" not \"Added feature\")\n- Explain why, not just what\n- Reference issues/PRs when relevant\n- Split unrelated changes into separate commits\n",
    "metaInfo": {
      "name": "git_commit",
      "description": "Create well-formatted commits with conventional commit messages and emojis.",
      "trigger": "commit,git-commit"
    }
  },
  "create_docs": {
    "tool": {
      "name": "create_docs",
      "description": "Create comprehensive documentation for specified components or features. It can be triggered by commands one of \"cc:create-docs\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Create Docs\n\nCreate comprehensive documentation for specified components or features.\n\n## Analysis Areas\n\n1. Code structure and purpose\n2. Inputs, outputs, and behavior\n3. User interaction flows\n4. Edge cases and error handling\n5. Integration points with other components/systems\n\n## Documentation Template\n\n### Overview\n\nBrief 1-2 paragraph overview explaining purpose and value\n\n### Usage\n\nHow to use this component/feature with examples\n\n### API / Props / Parameters\n\nDetailed specification of interfaces\n\n### Component Hierarchy\n\nStructure and relationships (if applicable)\n\n### State Management\n\nHow state is handled and flows through the system\n\n### Behavior\n\nExpected behavior in different scenarios\n\n### Error Handling\n\nHow errors are caught, handled, and reported\n\n### Performance Considerations\n\nOptimization notes and performance characteristics\n\n### Accessibility\n\nAccessibility features and compliance\n\n### Testing\n\nHow to test this component/feature\n\n### Related Components/Features\n\nLinks to related documentation\n\n## Process\n\n1. Analyze the target code thoroughly\n2. Identify all public interfaces\n3. Document expected behaviors\n4. Include code examples\n5. Add diagrams where helpful\n6. Follow project documentation standards\n7. Ensure clarity, completeness, and actionability\n\n## Output Formats\n\n- Markdown for general documentation\n- JSDoc/TSDoc for code comments\n- API documentation format\n- README files\n- Architecture decision records (ADRs)\n",
    "metaInfo": {
      "name": "create_docs",
      "description": "Create comprehensive documentation for specified components or features.",
      "trigger": "create-docs"
    }
  },
  "implement_task": {
    "tool": {
      "name": "implement_task",
      "description": "Approach task implementation methodically with careful planning and execution. It can be triggered by commands one of \"cc:task\",\"cc:implement-task\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Implement Task\n\nApproach task implementation methodically with careful planning and execution.\n\n## Process\n\n### 1. Think Through Strategy\n\n- Understand the complete requirement\n- Identify key components needed\n- Consider dependencies and constraints\n- Plan the implementation approach\n\n### 2. Evaluate Approaches\n\n- List possible implementation strategies\n- Compare pros and cons of each\n- Consider:\n  - Performance implications\n  - Maintainability\n  - Scalability\n  - Code reusability\n  - Testing complexity\n\n### 3. Consider Tradeoffs\n\n- Short-term vs long-term benefits\n- Complexity vs simplicity\n- Performance vs readability\n- Flexibility vs focused solution\n- Time to implement vs perfect solution\n\n### 4. Implementation Steps\n\n1. Break down into subtasks\n2. Start with core functionality\n3. Implement incrementally\n4. Test each component\n5. Integrate components\n6. Add error handling\n7. Optimize if needed\n8. Document decisions\n\n### 5. Best Practices\n\n- Write tests first (TDD approach)\n- Keep functions small and focused\n- Use meaningful names\n- Comment complex logic\n- Handle edge cases\n- Consider future maintenance\n\n## Checklist\n\n- [ ] Requirements fully understood\n- [ ] Approach documented\n- [ ] Tests written\n- [ ] Code implemented\n- [ ] Edge cases handled\n- [ ] Documentation updated\n- [ ] Code reviewed\n- [ ] Performance acceptable\n",
    "metaInfo": {
      "name": "implement_task",
      "description": "Approach task implementation methodically with careful planning and execution.",
      "trigger": "task,implement-task"
    }
  },
  "mermaid": {
    "tool": {
      "name": "mermaid",
      "description": "Generate Mermaid diagrams for visualizing code structure and relationships. It can be triggered by commands one of \"cc:mermaid\",\"cc:create-mermaid\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Mermaid Diagram Generation\n\nGenerate Mermaid diagrams for visualizing code structure and relationships.\n\n## Common Diagram Types\n\n### 1. Entity Relationship Diagrams\n\nFor database schemas and data models:\n\n```\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n```\n\n### 2. Flow Charts\n\nFor process and logic flow:\n\n```\nflowchart TD\n    A[Start] --> B{Decision}\n    B -->|Yes| C[Process]\n    B -->|No| D[End]\n```\n\n### 3. Sequence Diagrams\n\nFor interaction flows:\n\n```\nsequenceDiagram\n    Client->>Server: Request\n    Server->>Database: Query\n    Database-->>Server: Result\n    Server-->>Client: Response\n```\n\n### 4. Class Diagrams\n\nFor object-oriented design:\n\n```\nclassDiagram\n    class Animal {\n        +name: string\n        +age: int\n        +makeSound()\n    }\n```\n\n## Process\n\n1. Analyze source files (SQL, code, docs)\n2. Extract entities and relationships\n3. Generate appropriate diagram type\n4. Include relevant properties/methods\n5. Validate syntax with mermaid compiler\n6. Save to specified location\n\n## Validation\n\nRun `npx -p @mermaid-js/mermaid-cli mmdc -i <input>.md -o test.md`\n\n## Best Practices\n\n- Keep diagrams focused and readable\n- Use consistent naming conventions\n- Group related entities\n- Add labels to relationships\n- Include cardinality where relevant\n- Use subgraphs for organization\n- Add styling for clarity\n",
    "metaInfo": {
      "name": "mermaid",
      "description": "Generate Mermaid diagrams for visualizing code structure and relationships.",
      "trigger": "mermaid,create-mermaid"
    }
  },
  "update_docs": {
    "tool": {
      "name": "update_docs",
      "description": "Generate LLM-optimized documentation with concrete file references and flexible formatting. It can be triggered by commands one of \"cc:update-docs\"",
      "inputSchema": {
        "type": "object",
        "properties": {
          "userInput": {
            "type": "string",
            "description": "Input for the agent task"
          }
        },
        "required": []
      }
    },
    "prompt": "\n# Update Documentation\n\nYou will generate LLM-optimized documentation with concrete file references and flexible formatting.\n\n## Your Task\n\nCreate documentation that allows humans and LLMs to:\n\n- **Understand project purpose** - what the project does and why\n- **Get architecture overview** - how the system is organized\n- **Build on all platforms** - build instructions with file references\n- **Add features/subsystems** - following established patterns with examples\n- **Debug applications** - troubleshoot issues with specific file locations\n- **Test and add tests** - run existing tests and create new ones\n- **Deploy and distribute** - package and deploy the software\n\n## Required Documentation Structure\n\nEach document MUST include:\n\n1. **Timestamp Header** - Hidden comment with last update timestamp\n2. **Brief Overview** (2-3 paragraphs max)\n3. **Key Files & Examples** - Concrete file references for each major topic\n4. **Common Workflows** - Practical guidance with file locations\n5. **Reference Information** - Quick lookup tables with file paths\n\n## Timestamp Format\n\nEach generated file MUST start with:\n\n```\n<!-- Generated: YYYY-MM-DD HH:MM:SS UTC -->\n```\n\n## Process\n\nYou will:\n\n1. **Analyze the codebase systematically** across 7 key areas (merging development+patterns)\n2. **Create or update docs** in `docs/*.md` with concrete file references\n3. **Synthesize final documentation** into a minimal, LLM-friendly README.md\n4. **Eliminate all duplication** across files\n\n## Analysis Methodology\n\nFor each area, agents should:\n\n1. **Examine key files**: Look for build configs, test files, deployment scripts, main source files\n2. **Extract file references**: Note specific files, line numbers, and examples\n3. **Identify patterns**: Find repeated structures, naming conventions, common workflows\n4. **Make content LLM-friendly**: Token-efficient, reference-heavy, practical examples\n\n## Specific File Requirements\n\nIssue the following Task calls in parallel:\n\n**Project Overview** (`docs/project-overview.md`):\nSTRUCTURE:\n\n- Overview: What the project is, core purpose, key value proposition (2-3 paragraphs)\n- Key Files: Main entry points and core configuration files\n- Technology Stack: Core technologies with specific file examples\n- Platform Support: Requirements with platform-specific file locations\n\n**Architecture** (`docs/architecture.md`):\nSTRUCTURE:\n\n- Overview: High-level system organization (2-3 paragraphs)\n- Component Map: Major components with their source file locations\n- Key Files: Core headers and implementations with brief descriptions\n- Data Flow: How information flows with specific function/file references\n\n**Build System** (`docs/build-system.md`):\nSTRUCTURE:\n\n- Overview: Build system with file references to main build configuration\n- Build Workflows: Common tasks with specific commands and config files\n- Platform Setup: Platform-specific requirements with file paths\n- Reference: Build targets, presets, and troubleshooting with file locations\n\n**Testing** (`docs/testing.md`):\nSTRUCTURE:\n\n- Overview: Testing approach with test file locations\n- Test Types: Different test categories with specific file examples\n- Running Tests: Commands with file paths and expected outputs\n- Reference: Test file organization and build system test targets\n\n**Development** (`docs/development.md`):\nSTRUCTURE:\n\n- Overview: Development environment, code style, patterns (merge with old patterns.md if exists)\n- Code Style: Conventions with specific file examples (show actual code from codebase)\n- Common Patterns: Implementation patterns with file references and examples from the codebase\n- Workflows: Development tasks with concrete file locations and examples\n- Reference: File organization, naming conventions, common issues with specific files\n\n**Deployment** (`docs/deployment.md`):\nSTRUCTURE:\n\n- Overview: Packaging and distribution with script references\n- Package Types: Different packages with build targets and output locations\n- Platform Deployment: Platform-specific packaging with file paths\n- Reference: Deployment scripts, output locations, server configurations\n\n**Files Catalog** (`docs/files.md`):\nSTRUCTURE:\n\n- Overview: Comprehensive file catalog with descriptions and relationships (2-3 paragraphs)\n- Core Source Files: Main application logic with purpose descriptions\n- Platform Implementation: Platform-specific code with interface mappings\n- Build System: Build configuration and helper modules\n- Configuration: Assets, scripts, configs - Supporting files and their roles\n- Reference: File organization patterns, naming conventions, dependency relationships\n\n## Critical Requirements\n\n### LLM-OPTIMIZED FORMAT\n\n- **Token efficient**: Avoid redundant explanations, focus on essential information\n- **Concrete file references**: Always include specific file paths, line numbers when helpful\n- **Flexible formatting**: Use subsections, code blocks, examples instead of rigid step-by-step\n- **Pattern examples**: Show actual code from the codebase, not generic examples\n\n### NO DUPLICATION\n\n- Each piece of information appears in EXACTLY ONE file\n- Build information only in build-system.md\n- Code style and patterns only in development.md\n- Deployment information only in deployment.md\n- Cross-references using: \"See [docs/filename.md](docs/filename.md)\"\n\n### FILE REFERENCE FORMAT\n\nAlways include specific file references:\n\n```\n**Core System** - Core implementation in src/core.h (lines 15-45), platform backends in src/platform/\n\n**Build Configuration** - Main build file (lines 67-89), configuration files\n\n**Module Management** - Interface in src/module.h, implementation in src/module.c (key_function at line 134)\n```\n\n### PRACTICAL EXAMPLES\n\nUse actual code from the codebase:\n\n```c\n// From src/example.h:23-27\ntypedef struct {\n    bool active;\n    void *data;\n    int count;\n} ExampleState;\n```\n\n## Final Steps\n\nAfter all tasks complete:\n\n1. **Read all `docs/*.md` files** and create README.md with:\n   - Project description (2-3 sentences max)\n   - Key entry points and core configuration files\n   - Quick build commands\n   - Documentation links with brief descriptions of what LLMs will find useful\n   - Keep it under 50 lines total\n\n2. **Duplication check**: Scan all files and remove any duplicated information\n\n3. **File reference check**: Ensure all file paths are accurate and helpful\n\n## Agent Instructions\n\nEach agent must:\n\n1. **Read existing file** if it exists to understand current content\n2. **Analyze relevant codebase files** systematically\n3. **Extract specific file references** throughout analysis:\n   - Note important headers, source files, configuration files\n   - Include line numbers for key functions/sections when helpful\n   - Reference actual code examples from the codebase\n4. **Create LLM-friendly content**:\n   - Token-efficient writing (no redundant explanations)\n   - Concrete file paths and examples throughout\n   - Flexible formatting (subsections, code blocks, practical guidance)\n   - Focus on what LLMs need to understand and work with the code\n5. **Include practical workflows** with specific file references\n6. **Create reference sections** with file locations and line numbers\n7. **Update timestamp** at the top with current UTC time\n8. **Read generated file** and revise for accuracy and completeness\n\n**Success criteria**: Each file should be a practical reference that helps LLMs quickly understand the codebase and find the right files for specific tasks.\n\n**Special note for development.md**: Merge content from both old development.md and patterns.md (if they exist) into a single comprehensive development guide with implementation patterns.\n\nThe coordinating agent must:\n\n1. Wait for all agents to complete\n2. Read all generated files\n3. Remove any duplication found\n4. Create a minimal, LLM-optimized README.md with key file references\n5. **Update README.md timestamp** with current UTC time\n6. Delete docs/patterns.md if it exists since it's merged into development.md\n\n## Files Agent Instructions\n\nThe Files agent should create a minimal, token-efficient file catalog:\n\n1. **Discover files**: Use Glob and LS to find all source files, configs, and build files\n2. **Group by function**: Organize files into logical categories (core, platform, build, tests, config)\n3. **Brief descriptions**: One line per significant file describing its primary purpose\n4. **Key entry points**: Highlight main files, build configs, and important headers\n5. **Dependencies**: Note major relationships between file groups\n\n**Format**: Concise lists with file paths and single-sentence descriptions. Focus on helping LLMs quickly locate functionality, not comprehensive documentation.\n\n**Success criteria**: LLMs can quickly find \"where is the main entry point\", \"which files handle X\", \"what are the key headers\" without reading detailed descriptions.\n",
    "metaInfo": {
      "name": "update_docs",
      "description": "Generate LLM-optimized documentation with concrete file references and flexible formatting.",
      "trigger": "update-docs"
    }
  }
};