@totaland/create-starter-kit 1.0.0 → 2.0.1

package/templates/backend/.github/prompts/typescript-mcp-server-generator.prompt.md

@@ -0,0 +1,90 @@
+---
+mode: 'agent'
+description: 'Generate a complete MCP server project in TypeScript with tools, resources, and proper configuration'
+---
+
+# Generate TypeScript MCP Server
+
+Create a complete Model Context Protocol (MCP) server in TypeScript with the following specifications:
+
+## Requirements
+
+1. **Project Structure**: Create a new TypeScript/Node.js project with proper directory structure
+2. **NPM Packages**: Include @modelcontextprotocol/sdk, zod@3, and either express (for HTTP) or stdio support
+3. **TypeScript Configuration**: Proper tsconfig.json with ES modules support
+4. **Server Type**: Choose between HTTP (with Streamable HTTP transport) or stdio-based server
+5. **Tools**: Create at least one useful tool with proper schema validation
+6. **Error Handling**: Include comprehensive error handling and validation
+
+## Implementation Details
+
+### Project Setup
+- Initialize with `npm init` and create package.json
+- Install dependencies: `@modelcontextprotocol/sdk`, `zod@3`, and transport-specific packages
+- Configure TypeScript with ES modules: `"type": "module"` in package.json
+- Add dev dependencies: `tsx` or `ts-node` for development
+- Create proper .gitignore file
+
+### Server Configuration
+- Use `McpServer` class for high-level implementation
+- Set server name and version
+- Choose appropriate transport (StreamableHTTPServerTransport or StdioServerTransport)
+- For HTTP: set up Express with proper middleware and error handling
+- For stdio: use StdioServerTransport directly
+
+### Tool Implementation
+- Use `registerTool()` method with descriptive names
+- Define schemas using zod for input and output validation
+- Provide clear `title` and `description` fields
+- Return both `content` and `structuredContent` in results
+- Implement proper error handling with try-catch blocks
+- Support async operations where appropriate
+
+### Resource/Prompt Setup (Optional)
+- Add resources using `registerResource()` with ResourceTemplate for dynamic URIs
+- Add prompts using `registerPrompt()` with argument schemas
+- Consider adding completion support for better UX
+
+### Code Quality
+- Use TypeScript for type safety
+- Follow async/await patterns consistently
+- Implement proper cleanup on transport close events
+- Use environment variables for configuration
+- Add inline comments for complex logic
+- Structure code with clear separation of concerns
+
+## Example Tool Types to Consider
+- Data processing and transformation
+- External API integrations
+- File system operations (read, search, analyze)
+- Database queries
+- Text analysis or summarization (with sampling)
+- System information retrieval
+
+## Configuration Options
+- **For HTTP Servers**: 
+  - Port configuration via environment variables
+  - CORS setup for browser clients
+  - Session management (stateless vs stateful)
+  - DNS rebinding protection for local servers
+  
+- **For stdio Servers**:
+  - Proper stdin/stdout handling
+  - Environment-based configuration
+  - Process lifecycle management
+
+## Testing Guidance
+- Explain how to run the server (`npm start` or `npx tsx server.ts`)
+- Provide MCP Inspector command: `npx @modelcontextprotocol/inspector`
+- For HTTP servers, include connection URL: `http://localhost:PORT/mcp`
+- Include example tool invocations
+- Add troubleshooting tips for common issues
+
+## Additional Features to Consider
+- Sampling support for LLM-powered tools
+- User input elicitation for interactive workflows
+- Dynamic tool registration with enable/disable capabilities
+- Notification debouncing for bulk updates
+- Resource links for efficient data references
+
+Generate a complete, production-ready MCP server with comprehensive documentation, type safety, and error handling.

package/templates/backend/.github/prompts/update-implementation-plan.prompt.md

@@ -0,0 +1,157 @@
+---
+mode: 'agent'
+description: 'Update an existing implementation plan file with new or update requirements to provide new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
+---
+# Update Implementation Plan
+
+## Primary Directive
+
+You are an AI agent tasked with updating the implementation plan file `${file}` based on new or updated requirements. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems or humans.
+
+## Execution Context
+
+This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification.
+
+## Core Requirements
+
+- Generate implementation plans that are fully executable by AI agents or humans
+- Use deterministic language with zero ambiguity
+- Structure all content for automated parsing and execution
+- Ensure complete self-containment with no external dependencies for understanding
+
+## Plan Structure Requirements
+
+Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared.
+
+## Phase Architecture
+
+- Each phase must have measurable completion criteria
+- Tasks within phases must be executable in parallel unless dependencies are specified
+- All task descriptions must include specific file paths, function names, and exact implementation details
+- No task should require human interpretation or decision-making
+
+## AI-Optimized Implementation Standards
+
+- Use explicit, unambiguous language with zero interpretation required
+- Structure all content as machine-parseable formats (tables, lists, structured data)
+- Include specific file paths, line numbers, and exact code references where applicable
+- Define all variables, constants, and configuration values explicitly
+- Provide complete context within each task description
+- Use standardized prefixes for all identifiers (REQ-, TASK-, etc.)
+- Include validation criteria that can be automatically verified
+
+## Output File Specifications
+
+- Save implementation plan files in `/plan/` directory
+- Use naming convention: `[purpose]-[component]-[version].md`
+- Purpose prefixes: `upgrade|refactor|feature|data|infrastructure|process|architecture|design`
+- Example: `upgrade-system-command-4.md`, `feature-auth-module-1.md`
+- File must be valid Markdown with proper front matter structure
+
+## Mandatory Template Structure
+
+All implementation plans must strictly adhere to the following template. Each section is required and must be populated with specific, actionable content. AI agents must validate template compliance before execution.
+
+## Template Validation Rules
+
+- All front matter fields must be present and properly formatted
+- All section headers must match exactly (case-sensitive)
+- All identifier prefixes must follow the specified format
+- Tables must include all required columns
+- No placeholder text may remain in the final output
+
+## Status
+
+The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): `Completed` (bright green badge), `In progress` (yellow badge), `Planned` (blue badge), `Deprecated` (red badge), or `On Hold` (orange badge). It should also be displayed as a badge in the introduction section.
+
+```md
+---
+goal: [Concise Title Describing the Package Implementation Plan's Goal]
+version: [Optional: e.g., 1.0, Date]
+date_created: [YYYY-MM-DD]
+last_updated: [Optional: YYYY-MM-DD]
+owner: [Optional: Team/Individual responsible for this spec]
+status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
+tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
+---
+
+# Introduction
+
+![Status: <status>](https://img.shields.io/badge/status-<status>-<status_color>)
+
+[A short concise introduction to the plan and the goal it is intended to achieve.]
+
+## 1. Requirements & Constraints
+
+[Explicitly list all requirements & constraints that affect the plan and constrain how it is implemented. Use bullet points or tables for clarity.]
+
+- **REQ-001**: Requirement 1
+- **SEC-001**: Security Requirement 1
+- **[3 LETTERS]-001**: Other Requirement 1
+- **CON-001**: Constraint 1
+- **GUD-001**: Guideline 1
+- **PAT-001**: Pattern to follow 1
+
+## 2. Implementation Steps
+
+### Implementation Phase 1
+
+- GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
+
+| Task | Description | Completed | Date |
+|------|-------------|-----------|------|
+| TASK-001 | Description of task 1 | ✅ | 2025-04-25 |
+| TASK-002 | Description of task 2 | |  |
+| TASK-003 | Description of task 3 | |  |
+
+### Implementation Phase 2
+
+- GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
+
+| Task | Description | Completed | Date |
+|------|-------------|-----------|------|
+| TASK-004 | Description of task 4 | |  |
+| TASK-005 | Description of task 5 | |  |
+| TASK-006 | Description of task 6 | |  |
+
+## 3. Alternatives
+
+[A bullet point list of any alternative approaches that were considered and why they were not chosen. This helps to provide context and rationale for the chosen approach.]
+
+- **ALT-001**: Alternative approach 1
+- **ALT-002**: Alternative approach 2
+
+## 4. Dependencies
+
+[List any dependencies that need to be addressed, such as libraries, frameworks, or other components that the plan relies on.]
+
+- **DEP-001**: Dependency 1
+- **DEP-002**: Dependency 2
+
+## 5. Files
+
+[List the files that will be affected by the feature or refactoring task.]
+
+- **FILE-001**: Description of file 1
+- **FILE-002**: Description of file 2
+
+## 6. Testing
+
+[List the tests that need to be implemented to verify the feature or refactoring task.]
+
+- **TEST-001**: Description of test 1
+- **TEST-002**: Description of test 2
+
+## 7. Risks & Assumptions
+
+[List any risks or assumptions related to the implementation of the plan.]
+
+- **RISK-001**: Risk 1
+- **ASSUMPTION-001**: Assumption 1
+
+## 8. Related Specifications / Further Reading
+
+[Link to related spec 1]
+[Link to relevant external documentation]
+```

package/templates/backend/.github/prompts/update-markdown-file-index.prompt.md

@@ -0,0 +1,76 @@
+---
+mode: 'agent'
+description: 'Update a markdown file section with an index/table of files from a specified folder.'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
+---
+# Update Markdown File Index
+
+Update markdown file `${file}` with an index/table of files from folder `${input:folder}`.
+
+## Process
+
+1. **Scan**: Read the target markdown file `${file}` to understand existing structure
+2. **Discover**: List all files in the specified folder `${input:folder}` matching pattern `${input:pattern}`
+3. **Analyze**: Identify if an existing table/index section exists to update, or create new structure
+4. **Structure**: Generate appropriate table/list format based on file types and existing content
+5. **Update**: Replace existing section or add new section with file index
+6. **Validate**: Ensure markdown syntax is valid and formatting is consistent
+
+## File Analysis
+
+For each discovered file, extract:
+
+- **Name**: Filename with or without extension based on context
+- **Type**: File extension and category (e.g., `.md`, `.js`, `.py`)
+- **Description**: First line comment, header, or inferred purpose
+- **Size**: File size for reference (optional)
+- **Modified**: Last modified date (optional)
+
+## Table Structure Options
+
+Choose format based on file types and existing content:
+
+### Option 1: Simple List
+
+```markdown
+## Files in ${folder}
+
+- [filename.ext](path/to/filename.ext) - Description
+- [filename2.ext](path/to/filename2.ext) - Description
+```
+
+### Option 2: Detailed Table
+
+| File | Type | Description |
+|------|------|-------------|
+| [filename.ext](path/to/filename.ext) | Extension | Description |
+| [filename2.ext](path/to/filename2.ext) | Extension | Description |
+
+### Option 3: Categorized Sections
+
+Group files by type/category with separate sections or sub-tables.
+
+## Update Strategy
+
+- 🔄 **Update existing**: If table/index section exists, replace content while preserving structure
+- ➕ **Add new**: If no existing section, create new section using best-fit format
+- 📋 **Preserve**: Maintain existing markdown formatting, heading levels, and document flow
+- 🔗 **Links**: Use relative paths for file links within the repository
+
+## Section Identification
+
+Look for existing sections with these patterns:
+
+- Headings containing: "index", "files", "contents", "directory", "list"
+- Tables with file-related columns
+- Lists with file links
+- HTML comments marking file index sections
+
+## Requirements
+
+- Preserve existing markdown structure and formatting
+- Use relative paths for file links
+- Include file descriptions when available
+- Sort files alphabetically by default
+- Handle special characters in filenames
+- Validate all generated markdown syntax