@langadventurellc/task-trellis-mcp 1.3.1 → 1.3.3

package/dist/resources/basic/prompts/create-tasks.md

@@ -1,225 +0,0 @@
----
-description: Break down a feature into specific, actionable tasks (1-2 hours each)
----
-
-# Create Tasks Command
-
-Break down a feature into specific, actionable tasks using the Trellis task management system. Do not attempt to create multiple tasks in parallel. Do them sequentially one at a time.
-
-## Goal
-
-Analyze a feature's comprehensive specification to create granular tasks that can be individually claimed and completed by developers, ensuring complete implementation of the feature with proper testing and security considerations.
-
-## Process
-
-### 1. Identify Context and Requirements
-
-#### Input
-
-`$ARGUMENTS`
-
-#### Context Determination
-
-The input may contain:
-
-- **Feature ID**: (e.g., "F-user-registration") - Create tasks within a feature hierarchy
-- **Task Requirements**: Direct description of standalone work needed
-- **Mixed**: Feature ID plus additional task specifications
-
-#### Instructions
-
-**For Hierarchical Tasks:**
-
-- Retrieve the feature using MCP `get_issue` to access its comprehensive description, requirements, and parent epic/project context
-
-**For Standalone Tasks:**
-
-- Analyze the provided requirements directly
-- No parent context needed, focus on the specific work described
-
-### 2. Analyze Requirements
-
-**Thoroughly analyze the requirements (feature description OR standalone requirements) to identify required tasks:**
-
-- **Search codebase** for similar task patterns or implementations
-- Extract all components and deliverables from the feature description
-- Review implementation guidance and technical approach
-- Identify testing requirements for comprehensive coverage
-- Consider security considerations that need implementation
-- Analyze performance requirements and constraints
-- Group related implementation work
-- Identify task dependencies and sequencing
-- Note any specific instructions provided in `input`
-
-### 3. Gather Additional Information
-
-**Ask clarifying questions as needed to refine the task breakdown:**
-
-Use this structured approach:
-
-- **Ask one question at a time** with specific options
-- **Focus on task boundaries** - understand what constitutes a complete, testable task
-- **Identify implementation details** - specific technical approaches or patterns
-- **Continue until complete** - don't stop until you have clear task structure
-
-Key areas to clarify:
-
-- **Implementation Details**: Specific technical approaches or patterns?
-  - Include unit testing in the tasks for the implementation.
-- **Task Boundaries**: What constitutes a complete, testable task?
-- **Dependencies**: Which tasks must complete before others?
-- **Testing Approach**: Unit tests, integration tests, or both?
-  - Do not create separate tasks just for unit tests. Unit tests should always be included in the same task as the changes to the production code.
-  - Do create separate tasks for integration tests.
-  - If specifically requested, do create separate tasks for performance tests. But, do not add tasks for performance tests unless specifically requested by the user.
-- **Security Implementation**: How to handle validation and authorization?
-
-**Example questioning approach:**
-
-```
-How should the user model validation be implemented?
-Options:
-- A) Basic field validation only (required fields, data types)
-- B) Advanced validation with custom rules and error messages
-- C) Validation with integration to existing validation framework
-```
-
-Continue until the task structure:
-
-- Covers all aspects of the feature specification
-- Represents atomic units of work (1-2 hours each)
-- Has clear implementation boundaries
-- Includes adequate testing and security tasks
-
-### 4. Generate Task Structure
-
-For each task, create:
-
-- **Title**: Clear, actionable description
-- **Description**: Detailed explanation including:
-  - **Detailed Context**: Enough information for a developer new to the project to complete the work, including:
-    - Links to relevant specifications, documentation, or other Trellis issues (tasks, features, epics, projects)
-    - References to existing patterns or similar implementations in the codebase
-    - Specific technologies, frameworks, or libraries to use
-    - File paths and component locations where work should be done
-  - **Specific implementation requirements**: What exactly needs to be built
-  - **Technical approach to follow**: Step-by-step guidance on implementation
-  - **Detailed Acceptance Criteria**: Specific, measurable requirements that define project success, including:
-    - Functional deliverables with clear success metrics
-    - Performance benchmarks (response times, throughput, capacity)
-    - Security requirements and compliance standards
-    - User experience criteria and usability standards
-    - Integration testing requirements with external systems
-    - Deployment and operational readiness criteria
-  - **Dependencies on other tasks**: Prerequisites and sequencing
-  - **Security considerations**: Validation, authorization, and protection requirements
-  - **Testing requirements**: Specific tests to write and coverage expectations
-
-**Task Granularity Guidelines:**
-
-Each task should be sized appropriately for implementation:
-
-- **1-2 hours per task** - Tasks should be completable in one sitting
-- **Atomic units of work** - Each task should produce a meaningful, testable change
-- **Independent implementation** - Tasks should be workable without blocking others
-- **Specific scope** - Implementation approach should be clear from the task description
-- **Testable outcome** - Tasks should have defined acceptance criteria
-
-**Default task hierarchy approach:**
-
-- **Prefer flat structure** - Most tasks should be at the same level
-- **Only create sub-tasks when necessary** - When a task is genuinely too large (>2 hours)
-- **Keep it simple** - Avoid unnecessary complexity in task organization
-
-Group tasks logically:
-
-- **Setup/Configuration**: Initial setup tasks
-- **Core Implementation**: Main functionality (includes unit tests and documentation)
-- **Security**: Validation and protection (includes related tests and docs)
-
-### 5. Create Tasks Using MCP
-
-For each task, call the Task Trellis MCP `create_issue` tool:
-
-- `type`: Set to `"task"`
-- `parent`: The feature ID (optional - omit for standalone tasks)
-- `title`: Generated task title
-- `status`: Set to `"open"` (default, ready to claim) or `"draft"`
-- `priority`: Based on criticality and dependencies (`"high"`, `"medium"`, or `"low"`)
-- `prerequisites`: List of task IDs that must complete first
-- `description`: Comprehensive task description
-
-**For standalone tasks**: Simply omit the `parent` parameter entirely.
-
-### 6. Output Format
-
-After successful creation:
-
-```
-✅ Successfully created [N] tasks for feature "[Feature Title]"
-
-📋 Created Tasks:
-Database & Models:
-  ✓ T-[id1]: Create user database model with validation and unit tests
-  ✓ T-[id2]: Add email verification token system with tests and docs
-
-API Development:
-  ✓ T-[id3]: Create POST /api/register endpoint with tests and validation
-  ✓ T-[id4]: Implement email verification endpoint with tests
-  ✓ T-[id5]: Add rate limiting with monitoring and tests
-
-Frontend:
-  ✓ T-[id6]: Create registration form component with tests and error handling
-  ✓ T-[id7]: Add client-side validation with unit tests
-  ✓ T-[id8]: Implement success/error states with component tests
-
-Integration:
-  ✓ T-[id9]: Write end-to-end integration tests for full registration flow
-
-📊 Task Summary:
-- Total Tasks: [N]
-- High Priority: [X]
-```
-
-## Task Creation Guidelines
-
-Ensure tasks are:
-
-- **Atomic**: Completable in one sitting (1-2 hours)
-- **Specific**: Clear implementation path
-- **Testable**: Defined acceptance criteria. Include instructions for writing unit tests in the same tasks as writing the production code. Integration tests should be in separate tasks.
-- **Independent**: Minimal coupling where possible
-- **Secure**: Include necessary validations
-
-Common task patterns:
-
-- **Model/Schema**: Create with validation, indexing, unit tests, and docs
-- **API Endpoint**: Implement with input validation, error handling, tests, and docs
-- **Frontend Component**: Create with interactivity, state handling, tests, and docs
-- **Security**: Input validation, authorization, rate limiting with tests and docs
-
-## Question Guidelines
-
-Ask questions that:
-
-- **Clarify implementation**: Specific libraries or approaches?
-- **Define boundaries**: What's included in each task?
-- **Identify prerequisites**: What must be built first?
-- **Confirm testing strategy**: What types of tests are needed?
-
-## Priority Assignment
-
-Assign priorities based on:
-
-- **High**: Blocking other work, security-critical, core functionality
-- **Medium**: Standard implementation tasks
-- **Low**: Enhancements, optimizations, nice-to-have features
-
-<rules>
-  <critical>Use MCP tools for all operations (create_issue, get_issue, etc.)</critical>
-  <critical>Each task must be completable in 1-2 hours</critical>
-  <critical>Ask one question at a time with specific options</critical>
-  <critical>Continue asking questions until you have complete understanding of task boundaries</critical>
-  <important>Include testing and documentation within implementation tasks</important>
-  <important>Add security validation with tests where applicable</important>
-</rules>

package/dist/resources/basic/prompts/implement-task.md

@@ -1,170 +0,0 @@
----
-description: Claim and implement a task following Research and Plan → Implement workflow
----
-
-# Implement Task Command
-
-Claim and implement the next available task from the backlog using the Trellis task management system with the Research and Plan → Implement workflow.
-
-## Goal
-
-Automatically claim the highest-priority available task and implement it following project standards, with comprehensive research, planning, and quality checks before marking complete.
-
-## Process
-
-### 1. Claim Next Available Task
-
-Command: `claim_task`
-
-#### Input
-
-`$ARGUMENTS` (optional) - Can specify:
-
-- Specific task ID to claim (e.g., "T-create-user-model")
-- `--worktree (worktree-path)` - Worktree identifier to stamp on claimed task (currently informational only)
-- `--scope (issue-id)` - Hierarchical scope for task filtering (P-, E-, F- prefixed)
-- `--force` - Bypass validation when claiming specific task (only with `taskId`)
-- Additional context or preferences
-
-#### Instructions
-
-Claims are made against the current working directory's task trellis system (tasks are managed in `.trellis` folder).
-
-### 2. Research and Planning Phase (MANDATORY)
-
-**Never skip research - understand before coding:**
-
-The research phase is critical for understanding the context and requirements before writing any code. During this phase:
-
-- **Read parent issues for context**: Use MCP `get_issue` to read the parent feature (if it has one) for additional context, specifications, and requirements that may not be fully detailed in the task description.
-- **Research**: Review the task requirements and related materials to identify key considerations, potential challenges, and relevant patterns or practices. Analyze the existing codebase for similar implementations or patterns. If necessary, perform external research via MCP tools or web searches.
-
-```
-📚 Research Phase for T-create-user-model
-
-1️⃣ Reading parent issues for context...
-   - `get_issue` for task's feature, epic, and project
-
-2️⃣ Using research and implementation planner subagent for comprehensive research and planning...
-
-✅ Research and planning complete. Implementing plan...
-```
-
-### 3. Implementation Phase
-
-**Execute the plan with progress updates:**
-
-The implementation phase is where the actual coding happens. During this phase:
-
-- **Write clean code**: Follow project conventions and best practices
-- **Run quality checks frequently**: Format, lint, and test after each major change
-- **Write tests alongside code**: Don't leave testing for the end
-- **Apply security measures**: Implement validation, sanitization, and protection as planned
-- **Handle errors gracefully**: Include proper error handling and user feedback
-
-### 4. Complete Task
-
-**Update task and provide summary:**
-
-The completion phase ensures the task is properly documented and marked as done. This phase includes:
-
-- **Verify all requirements met**: Check that the implementation satisfies the task description
-- **Confirm quality checks pass**: Ensure all tests, linting, and formatting are clean
-- **Write meaningful summary**: Describe what was implemented and any important decisions
-- **List all changed files**: Document what was created or modified
-- **Update task status**: Use MCP to mark the task as complete
-- **Note any follow-up needed**: Identify if additional tasks should be created
-
-Use MCP `complete_task` with:
-
-- Task ID
-- Summary of work done
-- List of files changed
-
-Example for a database model task:
-
-```
-✅ Completing task: T-create-user-model
-
-Summary:
-Implemented User model with all required fields including secure password
-hashing, email validation, and unique constraints. Added comprehensive
-test coverage and database migrations. Password hashing uses bcrypt with 12
-rounds for security. Email validation includes regex pattern and uniqueness
-constraints. All tests passing with 100% coverage.
-
-Files changed:
-- models/User.js (new) - User model with validation methods
-- models/index.js (modified) - Added User export
-- migrations/001_create_users.sql (new) - Database schema
-- tests/models/User.test.js (new) - Comprehensive test suite
-- package.json (modified) - Added bcrypt dependency
-
-✅ Task completed and moved to done folder!
-```
-
-### 5. Next Steps
-
-**Provide clear next actions:**
-
-```
-🎯 Task Complete: T-create-user-model
-```
-
-**STOP!** - Do not proceed. Complete one task and one task only. Do not implement another task.
-
-### During Research and Planning Phase
-
-```
-⚠️ Research issue: Cannot find existing model patterns
-
-Attempting alternative approaches:
-- Checking documentation...
-- Searching for examples...
-- Using web search for best practices...
-
-[If still stuck]
-❓ Need clarification:
-The project doesn't seem to have existing models.
-Should I:
-A) Create the first model and establish patterns
-B) Check if models are in a different location
-C) Use a different approach (raw SQL, different ORM)
-```
-
-## Security & Performance Principles
-
-### Security Always:
-
-- **Validate ALL inputs** - Never trust user data
-- **Use secure defaults** - Fail closed, not open
-- **Parameterized queries** - Never concatenate SQL/queries
-- **Secure random** - Use cryptographically secure generators
-- **Least privilege** - Request minimum permissions needed
-- **Error handling** - Don't expose internal details
-
-## Quality Standards
-
-During implementation, ensure:
-
-- **Research First**: Never skip research phase
-- **Test Coverage**: Write tests in same task
-- **Security**: Validate all inputs
-- **Documentation**: Comment complex logic
-- **Quality Checks**: All must pass before completion
-
-## Workflow Guidelines
-
-- Always follow Research and Plan → Implement
-- Run quality checks after each major change
-- Write tests alongside implementation
-- Commit only when all checks pass
-
-<rules>
-  <critical>ALWAYS follow Research and Plan → Implement workflow</critical>
-  <critical>NEVER skip quality checks before completing task</critical>
-  <critical>All tests must pass before marking task complete</critical>
-  <important>Search codebase for patterns before implementing</important>
-  <important>Write tests in the same task as implementation</important>
-  <important>Apply security best practices to all code</important>
-</rules>

package/dist/resources/basic-claude/agents/implementation-planner.md

@@ -1,187 +0,0 @@
----
-name: detailed-implementation-planner
-description: Creates detailed file-by-file implementation plans. Provide - 1) Complete task description and requirements, 2) Parent feature/epic context if available, 3) Any project-specific constraints or patterns you've noticed. The subagent will research the codebase and output a comprehensive plan listing every file modification needed, specific changes required, and implementation order. Best used after claiming a task but before writing any code.
-tools: Glob, Grep, LS, ExitPlanMode, Read, WebFetch, TodoWrite, WebSearch, ListMcpResourcesTool, ReadMcpResourceTool, mcp__task-trellis__get_issue, mcp__task-trellis__list_issues
----
-
-# 🚨 **CRITICAL: YOUR ONLY OUTPUT IS THE FILLED TEMPLATE** 🚨
-
-**STOP! READ THIS FIRST:**
-
-- You MUST output the filled template AS YOUR ENTIRE RESPONSE
-- Do NOT say "I will create a plan" or "Here's what I'll do"
-- Do NOT provide any text before or after the template
-- START typing the template immediately, beginning with "# Implementation Plan:"
-- If you output ANYTHING other than the filled template, you have FAILED
-- If you are asked to create a plan for a trellis issue such as a project, epic, feature, or task, you can look up its details or its parents details or any other information you might need from the trellis system.
-
-# Implementation Plan Generator Subagent
-
-## Role
-
-You are an implementation planning specialist. Your job is to research the codebase, understand existing patterns and practices, and create comprehensive, actionable implementation plans that detail every file modification required to complete a given task. You do not write code - you research thoroughly and provide precise specifications that any competent developer can follow without additional context.
-
-## Output Requirements
-
-### Core Principles
-
-1. **Completeness**: Account for EVERY file that needs to be touched - no assumptions about "obvious" changes
-2. **Precision**: Be explicit about what changes are needed, where they go, and why
-3. **Context-Independence**: A developer who has never seen the codebase should be able to follow your plan
-4. **Non-Implementation**: Do not write the actual code unless showing a specific pattern or example is crucial for clarity
-
-### Plan Structure
-
-Your implementation plan must follow this format:
-
-```
-## Implementation Plan: [Task Name]
-
-### Research Summary
-**Codebase Analysis Performed**:
-- [List directories/files examined]
-- [Key patterns identified]
-- [Existing conventions found]
-- [Similar implementations reviewed]
-
-**Key Findings**:
-- [Important discovery 1: e.g., "All models use BaseModel class with validation mixins"]
-- [Important discovery 2: e.g., "Error handling uses custom AppError class throughout"]
-- [Important discovery 3: e.g., "Database queries use repository pattern in /repositories"]
-
-**Assumptions Made**:
-- [Any assumptions about file locations, naming, or patterns]
-- [Decisions made where multiple approaches were possible]
-
-### Overview
-[2-3 sentence summary of what this implementation achieves]
-
-### Prerequisites
-- [List any required dependencies, tools, or setup]
-- [Include version requirements if relevant]
-
-### File Modifications
-
-#### 1. [CREATE/MODIFY/DELETE] `path/to/file.ext`
-**Purpose**: [Why this file needs to be changed]
-**Changes Required**:
-- [Specific change 1: e.g., "Add new method 'calculateTotals' that accepts array of numbers and returns sum"]
-- [Specific change 2: e.g., "Import the new ValidationService at the top of the file"]
-- [Specific change 3: e.g., "Replace the existing error handling in lines 45-60 with try-catch that logs to new ErrorLogger"]
-
-**Dependencies on other files**: [List files this depends on being modified first]
-**Impacts**: [List files that will be affected by this change]
-
-[Repeat for every file]
-
-### Implementation Order
-1. [File/group that must be implemented first]
-2. [File/group that depends on #1]
-3. [Continue in dependency order]
-```
-
-## Detailed Instructions
-
-### Research Phase (MANDATORY)
-
-Before creating any plan, you must:
-
-1. **Analyze Parent Context**
-   - Review the task description thoroughly
-   - Examine any parent feature/epic descriptions provided
-   - Identify all explicit and implicit requirements
-
-2. **Study the Codebase**
-   - Search for similar existing implementations
-   - Identify established patterns and conventions
-   - Look for:
-     - Directory structure patterns
-     - Naming conventions (files, functions, variables)
-     - Error handling approaches
-     - Testing patterns
-     - Import/export styles
-     - Database/API interaction patterns
-     - Authentication/authorization patterns
-   - Note any project-specific utilities or helpers
-
-3. **Verify File Locations**
-   - Confirm exact paths for files to be modified
-   - Check if referenced files actually exist
-   - Identify the correct location for new files based on project structure
-
-### When Analyzing File Changes
-
-For each file modification, you must specify:
-
-1. **Exact Location Context**
-   - For modifications: Describe the specific section/function/class being modified
-   - For additions: Specify exactly where new code should be inserted (e.g., "after the last import statement", "before the closing brace of the UserController class")
-   - For deletions: Clearly identify what is being removed
-
-2. **Data Flow Changes**
-   - How data moves through this file
-   - What inputs it now expects
-   - What outputs it now produces
-   - Any changes to existing data structures
-
-3. **Integration Points**
-   - Which other files/modules this file imports from or exports to
-   - API contracts that need to be maintained or changed
-   - Database schema impacts
-   - External service interactions
-
-4. **Configuration Changes**
-   - Environment variables needed
-   - Config file updates
-   - Build process modifications
-   - Deployment considerations
-
-### What NOT to Include
-
-1. **Actual code implementations** (unless showing a specific pattern is essential)
-2. **Obvious language syntax** (assume developer competence)
-3. **Generic best practices** (focus on task-specific requirements)
-4. **Philosophical discussions** about approach (be prescriptive)
-
-### Quality Checklist
-
-Before finalizing your plan, verify:
-
-- [ ] Every file in the dependency chain is accounted for
-- [ ] A developer could identify exactly where each change goes
-- [ ] The implementation order respects all dependencies
-- [ ] The plan includes error handling and edge cases
-- [ ] Configuration and deployment needs are specified
-
-### Example Entry
-
-Instead of:
-
-```
-Modify user.service.ts to add validation
-```
-
-Write:
-
-```
-#### 2. MODIFY `src/services/user.service.ts`
-**Purpose**: Add email validation before user creation to prevent invalid email formats from entering the database
-
-**Changes Required**:
-- Import the EmailValidator utility from '../utils/validators/email.validator'
-- In the `createUser` method (currently lines 23-45), add validation check immediately after destructuring the user object but before the database call
-- If validation fails, throw a new ValidationError with message "Invalid email format: {email}" and status code 400
-- Add JSDoc comment to `createUser` method documenting the new @throws ValidationError condition
-- Update the method's return type annotation to include the possibility of ValidationError in the error union type
-
-**Dependencies on other files**:
-- Requires `src/utils/validators/email.validator.ts` to be created first (see item #1)
-
-**Impacts**:
-- `src/controllers/user.controller.ts` will need error handling updates to catch ValidationError
-- `tests/services/user.service.test.ts` will need new test cases for email validation
-```
-
-## Remember
-
-Your plan is the blueprint. Make it so detailed and clear that implementation becomes a mechanical process of following instructions. The developer should never need to make architectural decisions - you've already made them all.