Merge pull request #51 from gemini-cli-extensions/fix-checkbox-issue

fix: standardize Markdown checkbox format for tracks and plans

Author: moisgobg

commands/conductor/newTrack.toml

@@ -92,7 +92,9 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     *   Read the selected workflow file from `conductor/workflow.md`.
     *   Generate a `plan.md` with a hierarchical list of Phases, Tasks, and Sub-tasks.
     *   **CRITICAL:** The plan structure MUST adhere to the methodology in the workflow file (e.g., TDD tasks for "Write Tests" and "Implement").
-    *   Include status markers `[ ]` for each task/sub-task.
+    *   Include status markers `[ ]` for **EVERY** task and sub-task. The format must be:
+        - Parent Task: `- [ ] Task: ...`
+        - Sub-task: `    - [ ] ...`
     *   **CRITICAL: Inject Phase Completion Tasks.** Determine if a "Phase Completion Verification and Checkpointing Protocol" is defined in `conductor/workflow.md`. If this protocol exists, then for each **Phase** that you generate in `plan.md`, you MUST append a final meta-task to that phase. The format for this meta-task is: `- [ ] Task: Conductor - User Manual Verification '<Phase Name>' (Protocol in workflow.md)`.
 
 3.  **User Confirmation:** Present the drafted `plan.md` to the user for review and approval.
@@ -127,13 +129,10 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     *   Write the confirmed plan content to `conductor/tracks/<track_id>/plan.md`.
 6.  **Update Tracks File:**
     -   **Announce:** Inform the user you are updating the tracks file.
-    -   **Append Section:** Append a new section for the track to the end of `conductor/tracks.md`. The format MUST be:
+    -   **Append Section:** Append a new item to the track list in `conductor/tracks.md`. The format MUST be:
         ```markdown
-
-        ---
-
-        ## [ ] Track: <Track Description>
-        *Link: [./conductor/tracks/<track_id>/](./conductor/tracks/<track_id>/)*
+        - [ ] **Track: <Track Description>**
+          *Link: [./conductor/tracks/<track_id>/](./conductor/tracks/<track_id>/)*
         ```
         (Replace placeholders with actual values)
 7.  **Announce Completion:** Inform the user:

commands/conductor/revert.toml

@@ -84,7 +84,8 @@ Your workflow MUST anticipate and handle common non-linear Git histories, such a
 
 3.  **Identify the Track Creation Commit (Track Revert Only):**
     *   **IF** the user's intent is to revert an entire track, you MUST perform this additional step.
-    *   **Method:** Use `git log -- conductor/tracks.md` and search for the commit that first introduced the `## [ ] Track: <Track Description>` line for the target track into the tracks file.
+    *   **Method:** Use `git log -- conductor/tracks.md` and search for the commit that first introduced the track entry.
+        *   Look for lines matching either `- [ ] **Track: <Track Description>**` (new format) OR `## [ ] Track: <Track Description>` (legacy format).
     *   Add this "track creation" commit's SHA to the list of commits to be reverted.
 
 4.  **Compile and Analyze Final List:**

commands/conductor/setup.toml

@@ -385,15 +385,18 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
 
     ---
 
-    ## [ ] Track: <Track Description>
-    *Link: [./conductor/tracks/<track_id>/](./conductor/tracks/<track_id>/)*
+    - [ ] **Track: <Track Description>**
+      *Link: [./conductor/tracks/<track_id>/](./conductor/tracks/<track_id>/)*
     ```
 3.  **Generate Track Artifacts:**
     a. **Define Track:** The approved title is the track description.
     b. **Generate Track-Specific Spec & Plan:**
         i. Automatically generate a detailed `spec.md` for this track.
         ii. Automatically generate a `plan.md` for this track.
             - **CRITICAL:** The structure of the tasks must adhere to the principles outlined in the workflow file at `conductor/workflow.md`. For example, if the workflow specificies Test-Driven Development, each feature task must be broken down into a "Write Tests" sub-task followed by an "Implement Feature" sub-task.
+            - **CRITICAL:** Include status markers `[ ]` for **EVERY** task and sub-task. The format must be:
+                - Parent Task: `- [ ] Task: ...`
+                - Sub-task: `    - [ ] ...`
             - **CRITICAL: Inject Phase Completion Tasks.** You MUST read the `conductor/workflow.md` file to determine if a "Phase Completion Verification and Checkpointing Protocol" is defined. If this protocol exists, then for each **Phase** that you generate in `plan.md`, you MUST append a final meta-task to that phase. The format for this meta-task is: `- [ ] Task: Conductor - User Manual Verification '<Phase Name>' (Protocol in workflow.md)`. You MUST replace `<Phase Name>` with the actual name of the phase.
     c. **Create Track Artifacts:**
         i. **Generate and Store Track ID:** Create a unique Track ID from the track description using format `shortname_YYYYMMDD` and store it. You MUST use this exact same ID for all subsequent steps for this track.

commands/conductor/status.toml

@@ -33,6 +33,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 ### 2.1 Read Project Plan
 1.  **Locate and Read:** Read the content of the `conductor/tracks.md` file.
 2.  **Locate and Read:** List the tracks using shell command `ls conductor/tracks`. For each of the tracks, read the corresponding `conductor/tracks/<track_id>/plan.md` file.
+    *   **Parsing Logic:** When reading `conductor/tracks.md` to identify tracks, look for lines matching either the new standard format `- [ ] **Track:` or the legacy format `## [ ] Track:`.
 
 ### 2.2 Parse and Summarize Plan
 1.  **Parse Content:**