@vooster/mcp-preview

Reads the PRD (Product Requirements Document) for the connected project.

Updates completion details for a task already in DONE status after additional work ## PURPOSE & USE CASES This tool is specifically for updating task completion information when: - Additional debugging or bug fixes were performed - Code was refactored or optimized after initial completion - Documentation was added or improved - Test coverage was expanded - Performance improvements were made - Technical debt was addressed ## CRITICAL REQUIREMENTS ### Pre-Validation - [ ] Task MUST already be in DONE status - [ ] Additional work MUST have been performed since original completion - [ ] Updates should reflect the cumulative state (original + new work) ### Required Fields (ALL are mandatory) **1. completionDetails** (Updated markdown summary): Include BOTH original and additional work: ``` [One-line summary reflecting all work done] ## Description [Original implementation description] Additional work: [What was done in this update] ## Modified Files - [file]: [original changes + new changes] - [file]: [original changes + new changes] [Include all files touched, both originally and in update] ``` **2. confidenceLevel** (Updated 1-10 rating): Re-evaluate considering the impact of additional work: - Did debugging fix critical issues? (increase score) - Did refactoring simplify complexity? (increase score) - Were new edge cases discovered? (may decrease score) - Was technical debt reduced? (increase score) **3. confidenceDetails** (Updated justification): Explain how additional work changed the quality: - What specific improvements were made - How the changes impact reliability/maintainability - Any new risks or trade-offs introduced - Overall before/after comparison ## USAGE GUIDELINES ### When to Use - After fixing bugs in completed tasks - After refactoring completed code - After improving performance of done features - After adding tests to completed work - After addressing code review feedback ### When NOT to Use - For tasks not yet in DONE status (use update_task_status instead) - For changing task requirements or scope - For completely rewriting functionality - When no actual code changes were made ## EXAMPLES ### Example 1: Post-debugging Update ``` completionDetails: "Implemented and debugged user authentication system ## Description Originally created JWT-based login/logout functionality. Additional work: Fixed token refresh race condition, added proper error handling for network failures. ## Modified Files - auth.ts: JWT logic + fixed race condition in refresh flow - api-client.ts: Added retry logic with exponential backoff - auth.test.ts: Added test cases for edge cases" confidenceLevel: 9 (increased from 7) confidenceDetails: "Initial implementation was functional but had a critical race condition in token refresh that could cause authentication failures. This has been completely resolved. Added comprehensive error handling and retry logic makes the system much more robust. Test coverage increased from 70% to 95%." ``` ### Example 2: Post-refactoring Update ``` completionDetails: "Built and refactored shopping cart functionality ## Description Originally implemented cart CRUD operations with local state management. Additional work: Extracted cart logic to custom hooks, added optimistic updates, improved type safety. ## Modified Files - Cart.tsx: Simplified component using new useCart hook - hooks/useCart.ts: New centralized cart management - cartTypes.ts: Consolidated type definitions - CartItem.tsx: Refactored to use new patterns" confidenceLevel: 8 (increased from 6) confidenceDetails: "Refactoring significantly improved code organization and reusability. Cart logic is now properly encapsulated and easier to test. Optimistic updates provide better UX. Some complexity added with the hook pattern but overall maintainability greatly improved." ```

Lists all projects for the user

Lists all tasks for the connected project

## Description Manually adds new tasks to the currently connected project. ## Must - Do not add tasks that are already in the project. - Be sure that the user requested to add new tasks. - If tasks are not requested but would be beneficial to add, ask the user for confirmation before adding them. - If you think debugging is needed, ask the user for confirmation before adding them. - If user requested to add debugging tasks, set depedencyIds field as taskIds of related implementation tasks. (string array)

Automatically updates completed tasks to DONE status through codebase analysis. ## Core Usage Conditions - **Use only when explicitly requested by user**: Use only when requested with phrases like 'update task list based on codebase', 'sync codebase', 'auto-update completed tasks', etc. - **Korean Request Detection**: Recognize and call when the following Korean expressions are used: - "코드베이스를 기준으로 태스크 목록 업데이트해줘" - "코드베이스와 태스크 동기화해줘" - "완료된 태스크들 자동으로 업데이트해줘" - "구현된 기능들 태스크 상태 반영해줘" - "코드 기준으로 태스크 상태 맞춰줘" ## Functionality Analyzes the codebase to find tasks corresponding to already implemented features and updates them to DONE status. ## Required Parameters - **taskIds**: Array of completed task IDs (e.g., ["T-001", "T-002", "T-003"]) ## Auto-Set Values - **completionDetails**: "Completed through codebase synchronization" - **confidenceLevel**: 9 (high confidence) - **confidenceDetails**: "Implementation confirmed in codebase" ## Use Cases 1. Synchronize existing implemented features with task status after connecting new project 2. Resolve inconsistencies between actual implementation status and task status during development 3. Batch process completed tasks that team members didn't manually update ## Important Notes - This tool does not run automatically and requires explicit user request - Only pass tasks that have confirmed implementation in the codebase - Can process multiple tasks at once

Reads detailed information of a specific task

Updates the status of a task (BACKLOG | IN_PROGRESS | DONE) ## CRITICAL REQUIREMENTS ### Pre-Validation Checklist - [ ] Verify task acceptance criteria are fully met before marking as DONE - [ ] If uncertain about completion quality, ASK USER FOR CONFIRMATION before proceeding ### Status-Specific Requirements #### DONE Status - MANDATORY Fields When updating status to DONE, you MUST provide ALL three additional fields: **1. completionDetails** (Markdown format): Structure your response exactly as follows: ``` [One-line summary of completed work] ## Description [Detailed description of implementation, approach, and key decisions] ## Modified Files - [filename]: [brief description of changes] - [filename]: [brief description of changes] - [filename]: [brief description of changes] - [filename]: [brief description of changes] - [filename]: [brief description of changes] ``` **2. confidenceLevel** (1-10 integer): Rate the implementation quality considering: - Bug probability (10 = zero bugs expected, 1 = major bugs likely) - Requirement coverage (10 = 100% fulfilled, 1 = major gaps) - Code quality (10 = production-ready, 1 = requires major rework) - Scope adherence (lower score if significant deviation from original aiPrompt) **3. confidenceDetails** (Detailed explanation): Provide specific justification covering: - Implementation strengths and technical decisions - Potential risks, concerns, or areas needing attention - Alignment with original task requirements vs actual delivery - Testing performed or validation steps taken - Recommendations for follow-up work if applicable ### Quality Assurance - Be brutally honest in assessments - this data is used for project quality tracking - Lower confidence scores for scope creep beyond original requirements - Include specific technical details that justify your confidence rating - Consider both immediate functionality and long-term maintainability ### Error Prevention - Missing any DONE-required field will result in API error - Incomplete or vague descriptions reduce project tracking effectiveness - Overly optimistic confidence ratings can mask technical debt

Modifies existing task information (summary, aiPrompt, importance, urgency, complexity) ## Description Updates one or more fields of an existing task. All fields except taskId are optional. ## Parameters - **taskId** (required): ID of the task to modify (e.g., T-001) - **summary** (optional): New task summary/title - **aiPrompt** (optional): New detailed description/prompt for the task - **importance** (optional): New importance level (MUST, SHOULD, COULD, WONT) - **urgency** (optional): New urgency level (1-10) - **complexity** (optional): New complexity level (1-10) ## Use Cases - Update task description after requirements change - Adjust priority (importance/urgency) based on new information - Refine task details for better clarity - Correct mistakes in task information ## Important Notes - Cannot modify task status (use update_task_status instead) - Cannot modify dependencies (requires separate tool) - Only modifies provided fields, others remain unchanged

Gets the next priority task for the connected project based on importance, urgency, and creation date. ## Important Instructions When this tool returns a task: 1. **Check the task status** - IF status = "IN_PROGRESS", THEN evaluate if the task is actually completed - IF sub-tasks are not all "DONE", THEN implement remaining sub-tasks first. when you finish each sub-task, call update_subtask_status to update the status to "DONE" 2. **For IN_PROGRESS tasks** - Analyze the task's acceptance criteria - Verify if all requirements are met - IF the task is completed: a. Call update_task_status to update status to "DONE" b. Call get_next_task again to fetch the next priority task - IF the task is NOT completed: - Continue working on the current task 3. **Expected workflow** - get_next_task → check status → if IN_PROGRESS and completed → update_task_status(DONE) → get_next_task (repeat)

Updates the status of a sub-task (BACKLOG | IN_PROGRESS | DONE) ## Must - Make sure the sub-task UID is correct and belongs to the specified task. - If you want to move to DONE, **be sure** that the sub-task's acceptance criteria is met perfectly. If you can't be sure, ask the user to confirm.

Downloads all tasks in the connected project as local files. ## Purpose Creates a complete local backup of all project tasks with individual files and metadata. ## Output Files - **Individual Task Files**: `.vooster/tasks/[taskId].txt` - Complete task information including description, status, dependencies - Formatted for easy reading and reference - **Metadata File**: `.vooster/tasks.json` - Task count and download timestamp - Summary of all tasks with key information - JSON format for programmatic access ## Use Cases - **Project Backup**: Create local backup of all task information - **Documentation**: Export tasks for project documentation - **Offline Reference**: Access task details without internet connection - **Analysis**: Analyze project scope and task distribution - **Migration**: Prepare task data for migration to other systems ## Prerequisites - Valid API key configured - Run from project root directory