Cursor rule

1---
2description: How to perform taskmaster related commands
3globs:
4alwaysApply: false
5---
6 
7# Taskmaster Development Workflow
8 
9This guide outlines the standard process for using Taskmaster to manage software development projects. It is written as a set of instructions for you, the AI agent.
10 
11- **Your Default Stance**: For most projects, the user can work directly within the `master` task context. Your initial actions should operate on this default context unless a clear pattern for multi-context work emerges.
12- **Your Goal**: Your role is to elevate the user's workflow by intelligently introducing advanced features like **Tagged Task Lists** when you detect the appropriate context. Do not force tags on the user; suggest them as a helpful solution to a specific need.
13 
14## The Basic Loop
15The fundamental development cycle you will facilitate is:
161.  **`list`**: Show the user what needs to be done.
172.  **`next`**: Help the user decide what to work on.
183.  **`show <id>`**: Provide details for a specific task.
194.  **`expand <id>`**: Break down a complex task into smaller, manageable subtasks.
205.  **Implement**: The user writes the code and tests.
216.  **`update-subtask`**: Log progress and findings on behalf of the user.
227.  **`set-status`**: Mark tasks and subtasks as `done` as work is completed.
238.  **Repeat**.
24 
25All your standard command executions should operate on the user's current task context, which defaults to `master`.
26 
27---
28 
29## Standard Development Workflow Process
30 
31### Simple Workflow (Default Starting Point)
32 
33For new projects or when users are getting started, operate within the `master` tag context:
34 
35-   Start new projects by running `initialize_project` tool / `task-master init` or `parse_prd` / `task-master parse-prd --input='<prd-file.txt>'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to generate initial tasks.json with tagged structure
36-   Begin coding sessions with `get_tasks` / `task-master list` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to see current tasks, status, and IDs
37-   Determine the next task to work on using `next_task` / `task-master next` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc))
38-   Analyze task complexity with `analyze_project_complexity` / `task-master analyze-complexity --research` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) before breaking down tasks
39-   Review complexity report using `complexity_report` / `task-master complexity-report` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc))
40-   Select tasks based on dependencies (all marked 'done'), priority level, and ID order
41-   View specific task details using `get_task` / `task-master show <id>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to understand implementation requirements
42-   Break down complex tasks using `expand_task` / `task-master expand --id=<id> --force --research` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) with appropriate flags like `--force` (to replace existing subtasks) and `--research`
43-   Implement code following task details, dependencies, and project standards
44-   Mark completed tasks with `set_task_status` / `task-master set-status --id=<id> --status=done` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc))
45-   Update dependent tasks when implementation differs from original plan using `update` / `task-master update --from=<id> --prompt="..."` or `update_task` / `task-master update-task --id=<id> --prompt="..."` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc))
46 
47---
48 
49## Leveling Up: Agent-Led Multi-Context Workflows
50 
51While the basic workflow is powerful, your primary opportunity to add value is by identifying when to introduce **Tagged Task Lists**. These patterns are your tools for creating a more organized and efficient development environment for the user, especially if you detect agentic or parallel development happening across the same session.
52 
53**Critical Principle**: Most users should never see a difference in their experience. Only introduce advanced workflows when you detect clear indicators that the project has evolved beyond simple task management.
54 
55### When to Introduce Tags: Your Decision Patterns
56 
57Here are the patterns to look for. When you detect one, you should propose the corresponding workflow to the user.
58 
59#### Pattern 1: Simple Git Feature Branching
60This is the most common and direct use case for tags.
61 
62- **Trigger**: The user creates a new git branch (e.g., `git checkout -b feature/user-auth`).
63- **Your Action**: Propose creating a new tag that mirrors the branch name to isolate the feature's tasks from `master`.
64- **Your Suggested Prompt**: *"I see you've created a new branch named 'feature/user-auth'. To keep all related tasks neatly organized and separate from your main list, I can create a corresponding task tag for you. This helps prevent merge conflicts in your `tasks.json` file later. Shall I create the 'feature-user-auth' tag?"*
65- **Tool to Use**: `task-master add-tag --from-branch`
66 
67#### Pattern 2: Team Collaboration
68- **Trigger**: The user mentions working with teammates (e.g., "My teammate Alice is handling the database schema," or "I need to review Bob's work on the API.").
69- **Your Action**: Suggest creating a separate tag for the user's work to prevent conflicts with shared master context.
70- **Your Suggested Prompt**: *"Since you're working with Alice, I can create a separate task context for your work to avoid conflicts. This way, Alice can continue working with the master list while you have your own isolated context. When you're ready to merge your work, we can coordinate the tasks back to master. Shall I create a tag for your current work?"*
71- **Tool to Use**: `task-master add-tag my-work --copy-from-current --description="My tasks while collaborating with Alice"`
72 
73#### Pattern 3: Experiments or Risky Refactors
74- **Trigger**: The user wants to try something that might not be kept (e.g., "I want to experiment with switching our state management library," or "Let's refactor the old API module, but I want to keep the current tasks as a reference.").
75- **Your Action**: Propose creating a sandboxed tag for the experimental work.
76- **Your Suggested Prompt**: *"This sounds like a great experiment. To keep these new tasks separate from our main plan, I can create a temporary 'experiment-zustand' tag for this work. If we decide not to proceed, we can simply delete the tag without affecting the main task list. Sound good?"*
77- **Tool to Use**: `task-master add-tag experiment-zustand --description="Exploring Zustand migration"`
78 
79#### Pattern 4: Large Feature Initiatives (PRD-Driven)
80This is a more structured approach for significant new features or epics.
81 
82- **Trigger**: The user describes a large, multi-step feature that would benefit from a formal plan.
83- **Your Action**: Propose a comprehensive, PRD-driven workflow.
84- **Your Suggested Prompt**: *"This sounds like a significant new feature. To manage this effectively, I suggest we create a dedicated task context for it. Here's the plan: I'll create a new tag called 'feature-xyz', then we can draft a Product Requirements Document (PRD) together to scope the work. Once the PRD is ready, I'll automatically generate all the necessary tasks within that new tag. How does that sound?"*
85- **Your Implementation Flow**:
86    1.  **Create an empty tag**: `task-master add-tag feature-xyz --description "Tasks for the new XYZ feature"`. You can also start by creating a git branch if applicable, and then create the tag from that branch.
87    2.  **Collaborate & Create PRD**: Work with the user to create a detailed PRD file (e.g., `.taskmaster/docs/feature-xyz-prd.txt`).
88    3.  **Parse PRD into the new tag**: `task-master parse-prd .taskmaster/docs/feature-xyz-prd.txt --tag feature-xyz`
89    4.  **Prepare the new task list**: Follow up by suggesting `analyze-complexity` and `expand-all` for the newly created tasks within the `feature-xyz` tag.
90 
91#### Pattern 5: Version-Based Development
92Tailor your approach based on the project maturity indicated by tag names.
93 
94- **Prototype/MVP Tags** (`prototype`, `mvp`, `poc`, `v0.x`):
95  - **Your Approach**: Focus on speed and functionality over perfection
96  - **Task Generation**: Create tasks that emphasize "get it working" over "get it perfect"
97  - **Complexity Level**: Lower complexity, fewer subtasks, more direct implementation paths
98  - **Research Prompts**: Include context like "This is a prototype - prioritize speed and basic functionality over optimization"
99  - **Example Prompt Addition**: *"Since this is for the MVP, I'll focus on tasks that get core functionality working quickly rather than over-engineering."*
100 
101- **Production/Mature Tags** (`v1.0+`, `production`, `stable`):
102  - **Your Approach**: Emphasize robustness, testing, and maintainability
103  - **Task Generation**: Include comprehensive error handling, testing, documentation, and optimization
104  - **Complexity Level**: Higher complexity, more detailed subtasks, thorough implementation paths
105  - **Research Prompts**: Include context like "This is for production - prioritize reliability, performance, and maintainability"
106  - **Example Prompt Addition**: *"Since this is for production, I'll ensure tasks include proper error handling, testing, and documentation."*
107 
108### Advanced Workflow (Tag-Based & PRD-Driven)
109 
110**When to Transition**: Recognize when the project has evolved (or has initiated a project which existing code) beyond simple task management. Look for these indicators:
111- User mentions teammates or collaboration needs
112- Project has grown to 15+ tasks with mixed priorities
113- User creates feature branches or mentions major initiatives
114- User initializes Taskmaster on an existing, complex codebase
115- User describes large features that would benefit from dedicated planning
116 
117**Your Role in Transition**: Guide the user to a more sophisticated workflow that leverages tags for organization and PRDs for comprehensive planning.
118 
119#### Master List Strategy (High-Value Focus)
120Once you transition to tag-based workflows, the `master` tag should ideally contain only:
121- **High-level deliverables** that provide significant business value
122- **Major milestones** and epic-level features
123- **Critical infrastructure** work that affects the entire project
124- **Release-blocking** items
125 
126**What NOT to put in master**:
127- Detailed implementation subtasks (these go in feature-specific tags' parent tasks)
128- Refactoring work (create dedicated tags like `refactor-auth`)
129- Experimental features (use `experiment-*` tags)
130- Team member-specific tasks (use person-specific tags)
131 
132#### PRD-Driven Feature Development
133 
134**For New Major Features**:
1351. **Identify the Initiative**: When user describes a significant feature
1362. **Create Dedicated Tag**: `add_tag feature-[name] --description="[Feature description]"`
1373. **Collaborative PRD Creation**: Work with user to create comprehensive PRD in `.taskmaster/docs/feature-[name]-prd.txt`
1384. **Parse & Prepare**:
139   - `parse_prd .taskmaster/docs/feature-[name]-prd.txt --tag=feature-[name]`
140   - `analyze_project_complexity --tag=feature-[name] --research`
141   - `expand_all --tag=feature-[name] --research`
1425. **Add Master Reference**: Create a high-level task in `master` that references the feature tag
143 
144**For Existing Codebase Analysis**:
145When users initialize Taskmaster on existing projects:
1461. **Codebase Discovery**: Use your native tools for producing deep context about the code base. You may use `research` tool with `--tree` and `--files` to collect up to date information using the existing architecture as context.
1472. **Collaborative Assessment**: Work with user to identify improvement areas, technical debt, or new features
1483. **Strategic PRD Creation**: Co-author PRDs that include:
149   - Current state analysis (based on your codebase research)
150   - Proposed improvements or new features
151   - Implementation strategy considering existing code
1524. **Tag-Based Organization**: Parse PRDs into appropriate tags (`refactor-api`, `feature-dashboard`, `tech-debt`, etc.)
1535. **Master List Curation**: Keep only the most valuable initiatives in master
154 
155The parse-prd's `--append` flag enables the user to parse multple PRDs within tags or across tags. PRDs should be focused and the number of tasks they are parsed into should be strategically chosen relative to the PRD's complexity and level of detail.
156 
157### Workflow Transition Examples
158 
159**Example 1: Simple → Team-Based**
160```
161User: "Alice is going to help with the API work"
162Your Response: "Great! To avoid conflicts, I'll create a separate task context for your work. Alice can continue with the master list while you work in your own context. When you're ready to merge, we can coordinate the tasks back together."
163Action: add_tag my-api-work --copy-from-current --description="My API tasks while collaborating with Alice"
164```
165 
166**Example 2: Simple → PRD-Driven**
167```
168User: "I want to add a complete user dashboard with analytics, user management, and reporting"
169Your Response: "This sounds like a major feature that would benefit from detailed planning. Let me create a dedicated context for this work and we can draft a PRD together to ensure we capture all requirements."
170Actions:
1711. add_tag feature-dashboard --description="User dashboard with analytics and management"
1722. Collaborate on PRD creation
1733. parse_prd dashboard-prd.txt --tag=feature-dashboard
1744. Add high-level "User Dashboard" task to master
175```
176 
177**Example 3: Existing Project → Strategic Planning**
178```
179User: "I just initialized Taskmaster on my existing React app. It's getting messy and I want to improve it."
180Your Response: "Let me research your codebase to understand the current architecture, then we can create a strategic plan for improvements."
181Actions:
1821. research "Current React app architecture and improvement opportunities" --tree --files=src/
1832. Collaborate on improvement PRD based on findings
1843. Create tags for different improvement areas (refactor-components, improve-state-management, etc.)
1854. Keep only major improvement initiatives in master
186```
187 
188---
189 
190## Primary Interaction: MCP Server vs. CLI
191 
192Taskmaster offers two primary ways to interact:
193 
1941.  **MCP Server (Recommended for Integrated Tools)**:
195    - For AI agents and integrated development environments (like Cursor), interacting via the **MCP server is the preferred method**.
196    - The MCP server exposes Taskmaster functionality through a set of tools (e.g., `get_tasks`, `add_subtask`).
197    - This method offers better performance, structured data exchange, and richer error handling compared to CLI parsing.
198    - Refer to [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for details on the MCP architecture and available tools.
199    - A comprehensive list and description of MCP tools and their corresponding CLI commands can be found in [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc).
200    - **Restart the MCP server** if core logic in `scripts/modules` or MCP tool/direct function definitions change.
201    - **Note**: MCP tools fully support tagged task lists with complete tag management capabilities.
202 
2032.  **`task-master` CLI (For Users & Fallback)**:
204    - The global `task-master` command provides a user-friendly interface for direct terminal interaction.
205    - It can also serve as a fallback if the MCP server is inaccessible or a specific function isn't exposed via MCP.
206    - Install globally with `npm install -g task-master-ai` or use locally via `npx task-master-ai ...`.
207    - The CLI commands often mirror the MCP tools (e.g., `task-master list` corresponds to `get_tasks`).
208    - Refer to [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc) for a detailed command reference.
209    - **Tagged Task Lists**: CLI fully supports the new tagged system with seamless migration.
210 
211## How the Tag System Works (For Your Reference)
212 
213- **Data Structure**: Tasks are organized into separate contexts (tags) like "master", "feature-branch", or "v2.0".
214- **Silent Migration**: Existing projects automatically migrate to use a "master" tag with zero disruption.
215- **Context Isolation**: Tasks in different tags are completely separate. Changes in one tag do not affect any other tag.
216- **Manual Control**: The user is always in control. There is no automatic switching. You facilitate switching by using `use-tag <name>`.
217- **Full CLI & MCP Support**: All tag management commands are available through both the CLI and MCP tools for you to use. Refer to [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc) for a full command list.
218 
219---
220 
221## Task Complexity Analysis
222 
223-   Run `analyze_project_complexity` / `task-master analyze-complexity --research` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) for comprehensive analysis
224-   Review complexity report via `complexity_report` / `task-master complexity-report` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) for a formatted, readable version.
225-   Focus on tasks with highest complexity scores (8-10) for detailed breakdown
226-   Use analysis results to determine appropriate subtask allocation
227-   Note that reports are automatically used by the `expand_task` tool/command
228 
229## Task Breakdown Process
230 
231-   Use `expand_task` / `task-master expand --id=<id>`. It automatically uses the complexity report if found, otherwise generates default number of subtasks.
232-   Use `--num=<number>` to specify an explicit number of subtasks, overriding defaults or complexity report recommendations.
233-   Add `--research` flag to leverage Perplexity AI for research-backed expansion.
234-   Add `--force` flag to clear existing subtasks before generating new ones (default is to append).
235-   Use `--prompt="<context>"` to provide additional context when needed.
236-   Review and adjust generated subtasks as necessary.
237-   Use `expand_all` tool or `task-master expand --all` to expand multiple pending tasks at once, respecting flags like `--force` and `--research`.
238-   If subtasks need complete replacement (regardless of the `--force` flag on `expand`), clear them first with `clear_subtasks` / `task-master clear-subtasks --id=<id>`.
239 
240## Implementation Drift Handling
241 
242-   When implementation differs significantly from planned approach
243-   When future tasks need modification due to current implementation choices
244-   When new dependencies or requirements emerge
245-   Use `update` / `task-master update --from=<futureTaskId> --prompt='<explanation>\nUpdate context...' --research` to update multiple future tasks.
246-   Use `update_task` / `task-master update-task --id=<taskId> --prompt='<explanation>\nUpdate context...' --research` to update a single specific task.
247 
248## Task Status Management
249 
250-   Use 'pending' for tasks ready to be worked on
251-   Use 'done' for completed and verified tasks
252-   Use 'deferred' for postponed tasks
253-   Add custom status values as needed for project-specific workflows
254 
255## Task Structure Fields
256 
257- **id**: Unique identifier for the task (Example: `1`, `1.1`)
258- **title**: Brief, descriptive title (Example: `"Initialize Repo"`)
259- **description**: Concise summary of what the task involves (Example: `"Create a new repository, set up initial structure."`)
260- **status**: Current state of the task (Example: `"pending"`, `"done"`, `"deferred"`)
261- **dependencies**: IDs of prerequisite tasks (Example: `[1, 2.1]`)
262    - Dependencies are displayed with status indicators (✅ for completed, ⏱️ for pending)
263    - This helps quickly identify which prerequisite tasks are blocking work
264- **priority**: Importance level (Example: `"high"`, `"medium"`, `"low"`)
265- **details**: In-depth implementation instructions (Example: `"Use GitHub client ID/secret, handle callback, set session token."`)
266- **testStrategy**: Verification approach (Example: `"Deploy and call endpoint to confirm 'Hello World' response."`)
267- **subtasks**: List of smaller, more specific tasks (Example: `[{"id": 1, "title": "Configure OAuth", ...}]`)
268- Refer to task structure details (previously linked to `tasks.mdc`).
269 
270## Configuration Management (Updated)
271 
272Taskmaster configuration is managed through two main mechanisms:
273 
2741.  **`.taskmaster/config.json` File (Primary):**
275    *   Located in the project root directory.
276    *   Stores most configuration settings: AI model selections (main, research, fallback), parameters (max tokens, temperature), logging level, default subtasks/priority, project name, etc.
277    *   **Tagged System Settings**: Includes `global.defaultTag` (defaults to "master") and `tags` section for tag management configuration.
278    *   **Managed via `task-master models --setup` command.** Do not edit manually unless you know what you are doing.
279    *   **View/Set specific models via `task-master models` command or `models` MCP tool.**
280    *   Created automatically when you run `task-master models --setup` for the first time or during tagged system migration.
281 
2822.  **Environment Variables (`.env` / `mcp.json`):**
283    *   Used **only** for sensitive API keys and specific endpoint URLs.
284    *   Place API keys (one per provider) in a `.env` file in the project root for CLI usage.
285    *   For MCP/Cursor integration, configure these keys in the `env` section of `.cursor/mcp.json`.
286    *   Available keys/variables: See `assets/env.example` or the Configuration section in the command reference (previously linked to `taskmaster.mdc`).
287 
2883.  **`.taskmaster/state.json` File (Tagged System State):**
289    *   Tracks current tag context and migration status.
290    *   Automatically created during tagged system migration.
291    *   Contains: `currentTag`, `lastSwitched`, `migrationNoticeShown`.
292 
293**Important:** Non-API key settings (like model selections, `MAX_TOKENS`, `TASKMASTER_LOG_LEVEL`) are **no longer configured via environment variables**. Use the `task-master models` command (or `--setup` for interactive configuration) or the `models` MCP tool.
294**If AI commands FAIL in MCP** verify that the API key for the selected provider is present in the `env` section of `.cursor/mcp.json`.
295**If AI commands FAIL in CLI** verify that the API key for the selected provider is present in the `.env` file in the root of the project.
296 
297## Determining the Next Task
298 
299- Run `next_task` / `task-master next` to show the next task to work on.
300- The command identifies tasks with all dependencies satisfied
301- Tasks are prioritized by priority level, dependency count, and ID
302- The command shows comprehensive task information including:
303    - Basic task details and description
304    - Implementation details
305    - Subtasks (if they exist)
306    - Contextual suggested actions
307- Recommended before starting any new development work
308- Respects your project's dependency structure
309- Ensures tasks are completed in the appropriate sequence
310- Provides ready-to-use commands for common task actions
311 
312## Viewing Specific Task Details
313 
314- Run `get_task` / `task-master show <id>` to view a specific task.
315- Use dot notation for subtasks: `task-master show 1.2` (shows subtask 2 of task 1)
316- Displays comprehensive information similar to the next command, but for a specific task
317- For parent tasks, shows all subtasks and their current status
318- For subtasks, shows parent task information and relationship
319- Provides contextual suggested actions appropriate for the specific task
320- Useful for examining task details before implementation or checking status
321 
322## Managing Task Dependencies
323 
324- Use `add_dependency` / `task-master add-dependency --id=<id> --depends-on=<id>` to add a dependency.
325- Use `remove_dependency` / `task-master remove-dependency --id=<id> --depends-on=<id>` to remove a dependency.
326- The system prevents circular dependencies and duplicate dependency entries
327- Dependencies are checked for existence before being added or removed
328- Task files are automatically regenerated after dependency changes
329- Dependencies are visualized with status indicators in task listings and files
330 
331## Task Reorganization
332 
333- Use `move_task` / `task-master move --from=<id> --to=<id>` to move tasks or subtasks within the hierarchy
334- This command supports several use cases:
335  - Moving a standalone task to become a subtask (e.g., `--from=5 --to=7`)
336  - Moving a subtask to become a standalone task (e.g., `--from=5.2 --to=7`)
337  - Moving a subtask to a different parent (e.g., `--from=5.2 --to=7.3`)
338  - Reordering subtasks within the same parent (e.g., `--from=5.2 --to=5.4`)
339  - Moving a task to a new, non-existent ID position (e.g., `--from=5 --to=25`)
340  - Moving multiple tasks at once using comma-separated IDs (e.g., `--from=10,11,12 --to=16,17,18`)
341- The system includes validation to prevent data loss:
342  - Allows moving to non-existent IDs by creating placeholder tasks
343  - Prevents moving to existing task IDs that have content (to avoid overwriting)
344  - Validates source tasks exist before attempting to move them
345- The system maintains proper parent-child relationships and dependency integrity
346- Task files are automatically regenerated after the move operation
347- This provides greater flexibility in organizing and refining your task structure as project understanding evolves
348- This is especially useful when dealing with potential merge conflicts arising from teams creating tasks on separate branches. Solve these conflicts very easily by moving your tasks and keeping theirs.
349 
350## Iterative Subtask Implementation
351 
352Once a task has been broken down into subtasks using `expand_task` or similar methods, follow this iterative process for implementation:
353 
3541.  **Understand the Goal (Preparation):**
355    *   Use `get_task` / `task-master show <subtaskId>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to thoroughly understand the specific goals and requirements of the subtask.
356 
3572.  **Initial Exploration & Planning (Iteration 1):**
358    *   This is the first attempt at creating a concrete implementation plan.
359    *   Explore the codebase to identify the precise files, functions, and even specific lines of code that will need modification.
360    *   Determine the intended code changes (diffs) and their locations.
361    *   Gather *all* relevant details from this exploration phase.
362 
3633.  **Log the Plan:**
364    *   Run `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<detailed plan>'`.
365    *   Provide the *complete and detailed* findings from the exploration phase in the prompt. Include file paths, line numbers, proposed diffs, reasoning, and any potential challenges identified. Do not omit details. The goal is to create a rich, timestamped log within the subtask's `details`.
366 
3674.  **Verify the Plan:**
368    *   Run `get_task` / `task-master show <subtaskId>` again to confirm that the detailed implementation plan has been successfully appended to the subtask's details.
369 
3705.  **Begin Implementation:**
371    *   Set the subtask status using `set_task_status` / `task-master set-status --id=<subtaskId> --status=in-progress`.
372    *   Start coding based on the logged plan.
373 
3746.  **Refine and Log Progress (Iteration 2+):**
375    *   As implementation progresses, you will encounter challenges, discover nuances, or confirm successful approaches.
376    *   **Before appending new information**: Briefly review the *existing* details logged in the subtask (using `get_task` or recalling from context) to ensure the update adds fresh insights and avoids redundancy.
377    *   **Regularly** use `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<update details>\n- What worked...\n- What didn't work...'` to append new findings.
378    *   **Crucially, log:**
379        *   What worked ("fundamental truths" discovered).
380        *   What didn't work and why (to avoid repeating mistakes).
381        *   Specific code snippets or configurations that were successful.
382        *   Decisions made, especially if confirmed with user input.
383        *   Any deviations from the initial plan and the reasoning.
384    *   The objective is to continuously enrich the subtask's details, creating a log of the implementation journey that helps the AI (and human developers) learn, adapt, and avoid repeating errors.
385 
3867.  **Review & Update Rules (Post-Implementation):**
387    *   Once the implementation for the subtask is functionally complete, review all code changes and the relevant chat history.
388    *   Identify any new or modified code patterns, conventions, or best practices established during the implementation.
389    *   Create new or update existing rules following internal guidelines (previously linked to `cursor_rules.mdc` and `self_improve.mdc`).
390 
3918.  **Mark Task Complete:**
392    *   After verifying the implementation and updating any necessary rules, mark the subtask as completed: `set_task_status` / `task-master set-status --id=<subtaskId> --status=done`.
393 
3949.  **Commit Changes (If using Git):**
395    *   Stage the relevant code changes and any updated/new rule files (`git add .`).
396    *   Craft a comprehensive Git commit message summarizing the work done for the subtask, including both code implementation and any rule adjustments.
397    *   Execute the commit command directly in the terminal (e.g., `git commit -m 'feat(module): Implement feature X for subtask <subtaskId>\n\n- Details about changes...\n- Updated rule Y for pattern Z'`).
398    *   Consider if a Changeset is needed according to internal versioning guidelines (previously linked to `changeset.mdc`). If so, run `npm run changeset`, stage the generated file, and amend the commit or create a new one.
399 
40010. **Proceed to Next Subtask:**
401    *   Identify the next subtask (e.g., using `next_task` / `task-master next`).
402 
403## Code Analysis & Refactoring Techniques
404 
405- **Top-Level Function Search**:
406    - Useful for understanding module structure or planning refactors.
407    - Use grep/ripgrep to find exported functions/constants:
408      `rg "export (async function|function|const) \w+"` or similar patterns.
409    - Can help compare functions between files during migrations or identify potential naming conflicts.
410 
411---
412*This workflow provides a general guideline. Adapt it based on your specific project needs and team practices.*
413