Vibe Coding with Control: A Workflow with Cline

# Blueprint Maintainance

**Objective:** Read, Create, maintain and modify `blueprint.md` that outlines project's architecture, design decisions, core logic, and file references to guide development and onboarding.

**Trigger:** Whenever a new task starts, ask the user if you should read the blueprint, and according to the response read it. Or, when a significant milestone or a set of related architectural changes within a task is complete, and before moving to a distinctly new phase or feature set, or just before the intended final `attempt_completion`. This offer should be made after the relevant changes are understood by the user. If further significant architectural changes are requested after a blueprint update offer, the offer should be made again once those subsequent changes are complete.

**Process:**
- **At the Start**
1. **Ask User if you should read the blueprint file:** Use the `ask_followup_question` tool, whenever a new task is assigned, to check with the user if you should read the blueprint.
2. **Follow user directives:** Per the provided responose, if directed, read the blueprint file, if not, skip and continue with the task.

- **Before Completion**
1.  **Offer Blueprint Changes via Tool:** Use the `ask_followup_question` tool as the final step before the intended `attempt_completion`. The tool use should be similar to:
    ```xml
    <ask_followup_question>
    <question>I've completed the planned steps for the task. Before I finalize with attempt_completion, would you like me to analyse the changes made and suggest potential updates to the blueprint docs?</question>
    <options>["Yes, Propose updates for Blueprint", "No, complete the task now"]</options>
    </ask_followup_question>
    ```
2.  **Await User Choice:**
    *   If the user selects **"No, complete the task now"**: Proceed immediately with the `attempt_completion` tool.
    *   If the user selects **"Yes, identify changes"**: Proceed to step 3.
3.  **If User Chooses Update:**
    a.  **Identify Changes:** Check if the changes affect architecture, logic, structure, stack, design system, or external integrations. For every significant update, create a 1-3 sentence summary of what changed and why, being concise and clear.
    b.  **Read Existing Blueprint:** If `blueprint.md` exists in the current repo, Identify the corresponding section(s) in the document that need to be updated. If it doesn't exist, create a new document.
    c.  **Formulate & Propose Changes:** Generate specific, actionable changes for the *content* of the `blueprint.md` document. Prioritize changes directly addressing non-trivial updates. Use `replace_in_file` diff blocks when practical, otherwise describe changes clearly.
    d.  **Await User Action on Suggestions:** Ask the user if they agree with the proposed changes and if they'd like me to apply them *now* using the appropriate tool (`replace_in_file` or `write_to_file`). **Crucially, wait for explicit user approval before applying any changes to the blueprint document.** Apply changes if approved.
    e.  **Update Logs:** Log updates at the bottom of the document, under `Updates Log` header, in the following format, `**TimeStamp**: Single line reflecting the change`, to maintain update history, then proceed to `attempt_completion`.

**Constraint:** Do not offer updates if:
*   The updates are trivial (e.g., typo fixes, comment formatting etc)
*   The current mode is PLAN MODE (update offer should only happen in ACT mode just before completion).

# Complex Task Breakdown Rule

**Objective:** For complex tasks, propose breaking them down into smaller, verifiable steps and manage execution step-by-step with user verification.

**Trigger:** When a task plan is generated that involves multiple steps, modifications of multiple files, and high estimated lines of code (LOC), and before asking the user to toggle to ACT mode.

**Process:**

1.  **Propose Breakdown:** Use `ask_followup_question` to ask the user if they want to break down the task.
    ```xml
    <ask_followup_question>
    <question>This task appears complex, involving multiple steps and file modifications. Would you like me to break it down into smaller, independently verifiable steps and work through them one by one?</question>
    <options>["Yes, break it down", "No, proceed with the full plan"]</options>
    </ask_followup_question>
    ```
2.  **Await User Choice:**
    *   If user selects **"No, proceed with the full plan"**: Acknowledge and proceed with the original plan, asking the user to toggle to ACT mode.
    *   If user selects **"Yes, break it down"**: Proceed to step 3.
3.  **Breakdown and Document:**
    a.  Analyze the complex plan and break it into smaller, atomic steps.
    b.  Create a temporary Markdown file in `/tmp` (e.g., `/tmp/cline_task_breakdown_[timestamp].md`) listing the broken-down steps with brief descriptions and required context.
    c.  Inform the user that the breakdown document has been created and list the first step.
4.  **Execute Steps Iteratively:**
    a.  Work on the current step using appropriate tools in ACT mode.
    b.  Upon completion of a step's implementation:
        i.  Identify a verification method (e.g., "Check the console for log messages from function X", "Verify component Y renders correctly in the browser", "Run test Z").
        ii. Use `ask_followup_question` to inform the user of the verification method and ask for confirmation that the step works.
        ```xml
        <ask_followup_question>
        <question>Step [step_number] is complete. Please verify the implementation by [verification_method]. Has this step been successfully verified?</question>
        <options>["Yes, verified", "No, there's an issue"]</options>
        </ask_followup_question>
        ```
    c.  **Await User Verification:**
        i.  If user selects **"No, there's an issue"**: Troubleshoot the issue based on user feedback. Once resolved, re-request verification.
        ii. If user selects **"Yes, verified"**: Mark the step as complete in the temporary document (optional, but good practice). Proceed to the next step in the document. If there are more steps, inform the user of the next step. If all steps are complete, proceed to step 5.
5.  **Completion:** Once all steps are verified, inform the user that the broken-down task is complete and proceed with the final `attempt_completion`. Mention the temporary file and suggest its deletion.

# General Debugging Strategy

**Objective:** Provide a structured approach for diagnosing and resolving various types of software issues, from logical errors to state synchronization problems.

**Trigger:** When a user reports unexpected behavior, errors, or inconsistencies in the application.

**Process:**

1.  **Understand the Problem:**
    *   Clarify the exact symptoms and reproduction steps from the user.
    *   Formulate a clear hypothesis about the potential cause of the issue (e.g., "Incorrect data processing," "UI not updating correctly," "API call failing," "State synchronization problem").
2.  **Plan Diagnostic Logging/Inspection:**
    *   Identify key areas in the code relevant to the hypothesis (e.g., function inputs/outputs, state variables, API responses, component lifecycle methods).
    *   Use `console.log` (or equivalent debugging tools like breakpoints) to output:
        *   Relevant variable values at different stages.
        *   Execution flow indicators (e.g., "Entering function X," "Exiting loop Y").
        *   Timestamps (if timing is suspected).
        *   The specific code location for clarity.
    *   For UI issues, consider using browser developer tools to inspect element properties, styles, and component states.
    *   When using custom UI components, always consult their interface/props definitions to ensure correct usage.
    *   When working with state management libraries like Redux, ensure that components using hooks like `useSelector` or `useDispatch` are properly wrapped within the Redux `Provider`.
3.  **Instruct User to Reproduce and Provide Information:**
    *   Ask the user to reproduce the issue with the added logging/inspection steps enabled.
    *   Request the full console output, network tab details, or screenshots as relevant to the problem.
4.  **Analyze Information and Confirm Hypothesis:**
    *   Examine the provided logs and other diagnostic information.
    *   Compare observed behavior with expected behavior based on the hypothesis.
    *   Confirm or refine the hypothesis based on the evidence.
5.  **Propose Fix (Only After Confirmation):**
    *   If the hypothesis is confirmed, propose a targeted fix that directly addresses the identified root cause.
    *   If the hypothesis is not confirmed, iterate by refining the hypothesis and diagnostic steps.

# Self-Improving Cline Reflection

**Objective:** Offer opportunities to continuously improve `.clinerules` based on user interactions and feedback.

**Trigger:** Just before the intended final `attempt_completion` for any task that involved user feedback provided at any point during the conversation, or involved multiple non-trivial steps (e.g., multiple file edits, complex logic generation).

**Process:**

1.  **Offer Reflection via Tool:** Use the `ask_followup_question` tool as the final step before the intended `attempt_completion`. The tool use should be similar to:
    ```xml
    <ask_followup_question>
    <question>I've completed the planned steps for the task. Before I finalize with attempt_completion, would you like me to reflect on our interaction and suggest potential improvements to the active `.clinerules`?</question>
    <options>["Yes, reflect first", "No, complete the task now"]</options>
    </ask_followup_question>
    ```
2.  **Await User Choice:**
    *   If the user selects **"No, complete the task now"**: Proceed immediately with the `attempt_completion` tool.
    *   If the user selects **"Yes, reflect first"**: Proceed to step 3.
3.  **If User Chooses Reflection:**
    a.  **Review Interaction:** Synthesize all feedback provided by the user throughout the entire conversation history for the task. Analyze how this feedback relates to the active `.clinerules` and identify areas where modified instructions could have improved the outcome or better aligned with user preferences.
    b.  **Identify Active Rules:** List the specific global and workspace `.clinerules` files active during the task.
    c.  **Formulate & Propose Improvements:** Generate specific, actionable suggestions for improving the *content* of the relevant active rule files. Prioritize suggestions directly addressing user feedback. Use `replace_in_file` diff blocks when practical, otherwise describe changes clearly.
    d.  **Await User Action on Suggestions:** Ask the user if they agree with the proposed improvements and if they'd like me to apply them *now* using the appropriate tool (`replace_in_file` or `write_to_file`). Apply changes if approved, then proceed to `attempt_completion`.

**Constraint:** Do not offer reflection if:
*   No `.clinerules` were active.
*   The task was very simple and involved no feedback.
*   The current mode is PLAN MODE (reflection offer should only happen in ACT mode just before completion).