---
description:
globs:
alwaysApply: false
---
# Execute Planned Task Commits from GitHub Issue


**Your Primary Goal: Systematically execute the step-by-step plan defined in a specified GitHub issue (the issue number is provided by the user). Create each commit as planned and verify its success.**

## File Existence Check

Verify that the provided issue exists before starting:

```bash
ls . docs
```

If the issue is missing or inaccessible, stop and notify the user.

## Workflow for Each Commit in the Issue:

1.  **Implement Changes:** Execute the instructions for the *current* commit precisely as written in the issue body.
2.  **Verify Thoroughly:** BEFORE committing, perform **ALL** specified **Verification** steps for that commit. Confirm successful completion of each verification step.
3.  **Commit Changes:** Stage all implemented changes. Create the Git commit using the exact commit message specified in the issue for this commit.
4.  **Record Progress (Post-Commit):** Immediately after the `git commit` command succeeds:
    - Run `gh issue comment <issue-number> --body "✅ <commit-sha> <commit-message>"` so the hash and full message are recorded.
    - **Example Comment:** `✅ a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 feat: add login (#42)`
5.  **Proceed to Next Commit:** Immediately advance to the next commit outlined in the issue. **Do not ask for feedback or confirmation.** Continue this cycle until all commits in the issue are processed.

## Definition of "Task Completion"

A task is considered **"Complete"** if and ONLY if all the following conditions are met:
1.  **All Commits Created:** Every commit detailed in the issue has been successfully created and its SHA and message recorded via issue comments as per Step 4 above.
2.  **Tests Pass:** All automated tests relevant to the changes made pass successfully.
3.  **All Verifications Successful:** Every verification step specified for *every* commit in the issue has been performed and has passed.

## Actions After Entire Task is Complete:

1.  **Invoke Project Update Rule:** Once the entire task is Complete (as defined above), you MUST then load and meticulously follow all instructions within the `.cursor/rules/project-update-rules.mdc` file.
2.  **Provide Feedback (to `project-update-rules.mdc`):** When prompted by the `project-update-rules.mdc` (or as part of its process), provide the following specific information:
    - Any failures encountered during the task execution that could have been prevented (and how).
    - Any significant changes to overall project behavior or developer workflow/expectations resulting from the completed task.

## Strict Output Constraints:

- **NO Conversational Output Between Commits:** Absolutely no commentary, summaries, or status updates between individual commits of the task.
- **Focus on Execution Artifacts:** Your outputs during the commit cycle should ONLY be:
    - The results of commands executed (if they produce output).
    - The diffs of file changes applied.
    - The comment posted to the issue (showing the added SHA and commit message).
- **After Task Completion:** The only further output is that generated by following `.cursor/rules/project-update-rules.mdc`.
- **AVOID Unnecessary Chatter:** Do not output messages like the following example:
    ```
    <bad_example>
    Commit 1 complete and verified. Tests green. Verification successful.
    Moving to Commit 2 now.
    </bad_example>
    ```

**REMEMBER: Execute the task plan with precision. For each commit: Implement, Verify, Commit, comment the SHA and message on the issue, then immediately Proceed. No chatter. Once all commits are done and verified, trigger the project update rule.**