Generate a cursor rule named `implementation-workflow.mdc`, under the `.cursor/rules/workflows` directory. This rule will provide a systematic workflow for implementing tasks on a software project. The rule should be generic and reusable across different projects. It needs to accommodate various naming conventions for project documentation. For instance, design documentation might be in a system-wide `DESIGN.adoc` or a task-specific `DESIGN-[task_identifier].adoc`. Similarly, task lists might be in a system-wide `TASKS.adoc` or a task-specific `TASKS-[task_identifier].adoc`. The rule should refer to these documents generically (e.g., "the relevant design document(s)", "the active task list document"). The generated rule **must** include the following key sections with the specified details: 1. **Implementation Process:** * Guidance to implement tasks sequentially as ordered in the active task list document, respecting any task grouping specified therein. * Instruction to always cross-reference relevant design document(s) for technical implementation details and product requirement document(s) (if available) for context. * Clear definition and explanation of task status updates within the task list document. Emphasize the precise order of status changes: * `⬜` (Pending): Default status for a new or untouched task. * `⭕` (Pending Approval): Status achieved **only after** a task's initial implementation is complete and it is ready for user review. A task transitions from `⬜` to `⭕`. * `✅` (Completed): Status achieved **only after** a task marked `⭕` has been explicitly reviewed and approved by the user. A task transitions from `⭕` to `✅`. * `❌` (Failed): Status if a task implementation is deemed unsuccessful or is rejected after review. A task typically transitions from `⬜` or `⭕` to `❌`. * `❓` (Needs Clarification): Status if more information or input is required from the user before or during task implementation. A task can transition from `⬜` to `❓`. * Reiterate that a task's status changes from `⬜` to `⭕` immediately after its implementation is complete, signifying it's ready for review. 2. **Implementation Checklist:** * A step-by-step checklist to be followed for each task: 1. Identify the next pending (`⬜`) task from the active task list document, strictly following the documented sequence and any specified grouping. 2. Thoroughly research requirements by consulting relevant design document(s) and any associated product requirement document(s). 3. Implement the solution, adhering meticulously to the technical specifications, architectural guidelines, and design patterns detailed in the design document(s). 4. Once initial implementation is verifiably complete, immediately update the task's status in the active task list document from `⬜` to `⭕` (Pending Approval). 5. **CRITICAL**: Explicitly request user review of the implemented task. This request must be clear and direct (e.g., "The implementation for task '[task_name]' is complete and now marked as 'Pending Approval'. Would you like to review this implementation before I proceed to the next task?"). 6. Patiently wait for explicit user approval. Do not proceed with new tasks while awaiting review unless otherwise directed. 7. Upon receiving unambiguous, explicit user approval, the very next action is to update the task's status in the active task list document from `⭕` to `✅` (Completed). 3. **Code Standards:** * A general directive to rigorously adhere to all established coding best practices, style guides, and quality standards specific to the project. * Instruction to ensure complete consistency with any code examples, architectural patterns, or idioms provided in the relevant design document(s). * A reminder that all developed modules, classes, functions, or components must precisely match their specified responsibilities and interfaces as outlined in the design documentation. 4. **User Approval Protocol:** * **NON-NEGOTIABLE MANDATE**: Under no circumstances proceed to the next task or consider a currently implemented task fully finalized (`✅`) without obtaining explicit, unambiguous approval from the user for the work done on the task marked `⭕`. * Clearly state that multiple review-feedback-revision cycles are expected and normal. Be prepared to receive detailed feedback, make all necessary revisions diligently, and resubmit for approval after each iteration. * Instruct to implement ALL requested changes thoroughly and accurately. After revisions, the task remains `⭕` and requires a new request for approval. * Define what constitutes explicit approval (e.g., direct affirmative statements like "approved," "this looks good, proceed," "LGTM, move on," "changes accepted"). * If user feedback is provided but lacks a clear statement of approval, the task status remains `⭕`. Do NOT interpret feedback as implicit approval. In such cases, STOP and explicitly seek clarification regarding approval status (e.g., "Thank you for this feedback. I will make these adjustments. To confirm, once these changes are made, will the task be considered approved, or is there a further review step?"). * Advise to provide a concise summary of the implementation or changes made when requesting review, to facilitate an efficient review process for the user. * The first and immediate action after receiving explicit user approval for a task currently in the `⭕` (Pending Approval) state is to update its status to `✅` (Completed) in the active task list document. Only then can the next task be considered. The task order, priority, and grouping are to be strictly and solely derived from the active task list document itself. The core focus of the generated rule must be on the unyielding adherence to the documented implementation flow, the precise order and criteria for task status transitions (especially `⬜` → `⭕` → `✅`), and the paramount, non-negotiable importance of the user approval step before any task is marked complete or new work is begun.