oh-my-codex-cli 0.1.0

package/README.zh.md

@@ -0,0 +1,145 @@
+简体中文 | [English](README.md)
+
+# oh-my-codex
+
+[![License: MIT](https://img.shields.io/badge/License-MIT-green.svg)](https://opensource.org/licenses/MIT)
+
+**面向 Codex CLI 的原生 subagent 工作流。**
+
+*少调 prompt，多交付。*
+
+本项目参考 **oh‑my‑claudecode**，并结合 **oh‑my‑opencode**、**everything‑claude‑code** 的经验，
+但完全**针对 Codex 架构重建**。
+
+---
+
+## 安装
+
+**通过 npm 全局安装**
+```bash
+npm install -g oh-my-codex-cli
+omcodex setup
+```
+
+**通过 npm 一次性执行**
+```bash
+npx oh-my-codex-cli setup
+```
+
+**推荐（一键安装）**
+```bash
+./scripts/install-codex.sh --all
+```
+
+强制覆盖安装：
+```bash
+./scripts/install-codex-force.sh --all
+```
+
+增量安装（跳过已存在文件）：
+```bash
+./scripts/install-codex-incremental.sh --all
+```
+
+安装内容包括：
+- **Skills** → `~/.codex/skills/`
+- **角色 Prompt** → `~/.codex/prompts/`
+- **Rules** → `~/.codex/rules/`
+- **MCP 配置 + Plan 模式** → `~/.codex/config.toml`
+
+**项目级安装**
+```bash
+./scripts/install-codex.sh --all --project
+```
+
+---
+
+## 安装后你能获得什么
+
+- **执行模式**：`autopilot`, `ralph`, `ultrawork`, `ultraqa`, `ultrapilot`, `swarm`, `pipeline`, `ecomode`
+- **规划与质量**：`plan`, `review`, `analyze`, `tdd`, `code-review`, `security-review`, `build-fix`, `verify`, `eval`
+- **角色 Prompt 目录**：`architect`, `planner`, `executor`（安装到 `.codex/prompts/`）
+- **学习与上下文**：`continuous-learning`, `strategic-compact`, `iterative-retrieval`, `verification-loop`
+- **原生 subagent 编排**：核心 skill 统一使用 `spawn_agent` + `send_input` + `wait` + `close_agent`
+- **自动技能路由**：`omcodex route "<task>"` 自动推荐最匹配的 skill（含置信度）
+- **事件驱动 team 自动推进**：`omcodex team start "<task>" --auto` 可按 notify 事件推进阶段
+- **通知扩展**：`omcodex notify`（事件驱动通知扩展，不是拦截执行）
+- **规则与守护**：编码 / 安全 / 测试 / 性能 / Git 工作流
+- **Plan 模式已开启**（Codex 0.9+）
+
+---
+
+## Codex vs Claude Code（高层对比）
+
+| 能力 | Claude Code（oh‑my‑claudecode） | Codex（oh‑my‑codex） |
+|---|---|---|
+| Skills 工作流 | ✅ | ✅（主方式） |
+| 原生 subagent 执行 | ✅ | ✅ |
+| Plan 模式 | ⚠️ 插件驱动 | ✅ 原生（0.9+ 配置开启） |
+| MCP 支持 | ✅ | ✅（config.toml/CLI） |
+
+---
+
+## 典型使用场景
+
+- **快速交付功能** → `autopilot: add OAuth login + tests`
+- **持续完成模式** → `ralph: refactor auth until tests pass`
+- **高并行思考** → `ultrawork: fix all lint + type errors`
+- **质量闭环** → `ultraqa: run tests and fix until green`
+- **纯规划** → `plan: design a scalable API for X`
+
+---
+
+## 规则模板（Rules）
+
+可选规则模板，复制到 `.codex/rules/` 使用：
+- `agents.md`, `coding-style.md`, `git-workflow.md`, `notify.md`
+- `patterns.md`, `performance.md`, `security.md`, `testing.md`
+- `dev.md`, `research.md`, `review.md`
+
+一键安装 rules：
+```bash
+./scripts/install-codex.sh --rules
+```
+
+---
+
+## Skill 治理
+
+在发布或合并 skill 文档变更前，先运行治理门禁：
+
+```bash
+npm run governance:skills
+npm run governance:skills:llm
+npm run eval:skills
+```
+
+这个命令会阻断以下高风险残留：
+- 旧的 slash 命令写法（例如 `Run: /verify`）
+- plugin 专用运行指令（例如 `cc --plugin-dir`）
+- 旧式任务 API 示例（`Task(...)` 语法）
+
+详细规则见 `docs/SKILL_GOVERNANCE.md`。
+
+---
+
+
+## 快速开始
+
+```
+autopilot: build a REST API for managing tasks
+```
+
+---
+
+## 文档
+
+- `docs/CODEX.md`
+- `docs/ALIGNMENT.md`
+- `docs/NOTIFY.md`
+
+---
+
+## 许可
+
+MIT

package/bin/omcodex.js

@@ -0,0 +1,8 @@
+#!/usr/bin/env node
+/* eslint-disable no-console */
+const { main } = require('../src/cli/index');
+
+main(process.argv.slice(2)).catch((error) => {
+  console.error(error instanceof Error ? error.message : String(error));
+  process.exit(1);
+});

package/commands/conductor/implement.toml

@@ -0,0 +1,358 @@
+description = "Executes the tasks defined in the specified track's plan"
+prompt = """
+## 1.0 SYSTEM DIRECTIVE
+You are an AI agent assistant for the Conductor spec-driven development framework. Your current task is to implement a track. You MUST follow this protocol precisely.
+
+CRITICAL: You must validate the success of every tool call. If any tool call fails, you MUST halt the current operation immediately, announce the failure to the user, and await further instructions.
+
+---
+
+## 1.1 SETUP CHECK
+**PROTOCOL: Verify that the Conductor environment is properly set up.**
+
+1.  **Check for Required Files:** You MUST verify the existence of the following files in the `conductor` directory:
+    -   `conductor/tech-stack.md`
+    -   `conductor/workflow.md`
+    -   `conductor/product.md`
+
+2.  **Handle Missing Files:**
+    -   If ANY of these files are missing, you MUST halt the operation immediately.
+    -   Announce: "Conductor is not set up. Please run `/conductor:setup` to set up the environment."
+    -   Do NOT proceed to Track Selection.
+
+---
+
+## 2.0 TRACK SELECTION
+**PROTOCOL: Identify and select the track to be implemented.**
+
+1.  **Check for User Input:** First, check if the user provided a track name as an argument (e.g., `/conductor:implement <track_description>`).
+
+2.  **Parse Tracks File:** Read and parse the tracks file at `conductor/tracks.md`. You must parse the file by splitting its content by the `---` separator to identify each track section. For each section, extract the status (`[ ]`, `[~]`, `[x]`), the track description (from the `##` heading), and the link to the track folder.
+    -   **CRITICAL:** If no track sections are found after parsing, announce: "The tracks file is empty or malformed. No tracks to implement." and halt.
+
+3.  **Continue:** Immediately proceed to the next step to select a track.
+
+4.  **Select Track:**
+    -   **If a track name was provided:**
+        1.  Perform an exact, case-insensitive match for the provided name against the track descriptions you parsed.
+        2.  If a unique match is found, confirm the selection with the user: "I found track '<track_description>'. Is this correct?"
+        3.  If no match is found, or if the match is ambiguous, inform the user and ask for clarification. Suggest the next available track as below.
+    -   **If no track name was provided (or if the previous step failed):**
+        1.  **Identify Next Track:** Find the first track in the parsed tracks file that is NOT marked as `[x] Completed`.
+        2.  **If a next track is found:**
+            -   Announce: "No track name provided. Automatically selecting the next incomplete track: '<track_description>'."
+            -   Proceed with this track.
+        3.  **If no incomplete tracks are found:**
+            -   Announce: "No incomplete tracks found in the tracks file. All tasks are completed!"
+            -   Halt the process and await further user instructions.
+
+5.  **Handle No Selection:** If no track is selected, inform the user and await further instructions.
+
+---
+
+## 3.0 TRACK IMPLEMENTATION
+**PROTOCOL: Execute the selected track.**
+
+1.  **Announce Action:** Announce which track you are beginning to implement.
+
+2.  **Update Status to 'In Progress':**
+    -   Before beginning any work, you MUST update the status of the selected track in the `conductor/tracks.md` file.
+    -   This requires finding the specific heading for the track (e.g., `## [ ] Track: <Description>`) and replacing it with the updated status (e.g., `## [~] Track: <Description>`).
+
+3.  **Load Track Context:**
+    a. **Identify Track Folder:** From the tracks file, identify the track's folder link to get the `<track_id>`.
+    b. **Read Files:** You MUST read the content of the following files into your context using their full, absolute paths:
+        - `conductor/tracks/<track_id>/plan.md`
+        - `conductor/tracks/<track_id>/spec.md`
+        - `conductor/workflow.md`
+    c. **Error Handling:** If you fail to read any of these files, you MUST stop and inform the user of the error.
+
+4.  **Execute Tasks and Update Track Plan:**
+    a. **Announce:** State that you will now execute the tasks from the track's `plan.md` by following the procedures in `workflow.md`.
+    b. **Iterate Through Tasks:** You MUST now loop through each task in the track's `plan.md` one by one.
+    c. **For Each Task, You MUST:**
+        i. **Defer to Workflow:** The `workflow.md` file is the **single source of truth** for the entire task lifecycle. You MUST now read and execute the procedures defined in the "Task Workflow" section of the `workflow.md` file you have in your context. Follow its steps for implementation, testing, and committing precisely.
+
+5.  **Verification Checkpoint:**
+    -   After all tasks in the track's local `plan.md` are marked `[x]`, DO NOT mark track as complete yet.
+    -   Proceed to Verification Protocol (section 5.5) before finalization.
+
+---
+
+## 5.5 VERIFICATION PROTOCOL (DOUBLE-TAP)
+**PROTOCOL: Spawn independent verification agent with disjoint context.**
+
+**CRITICAL: This creates a separate LLM context with NO exposure to implementation bias.**
+
+1.  **Execution Trigger:** After all tasks in `plan.md` are marked `[x]`, but BEFORE updating `conductor/tracks.md` to `[x]`.
+
+2.  **Prepare Verification Payload:**
+    You MUST gather the following for the verification agent:
+    a. **Spec content:** Full text of `conductor/tracks/<track_id>/spec.md`
+    b. **Current file tree:** `git ls-tree -r HEAD` (all files in current state)
+    c. **Relevant file contents:** Read actual current content of files touched by this track
+    d. **Tech stack:** `conductor/tech-stack.md`
+    e. **Product context:** `conductor/product.md`
+    f. **Test files:** Current test file contents
+
+3.  **Detect Platform:**
+    Determine which platform you are running on:
+    - **Claude/OpenCode:** You have access to the `Task` tool
+    - **Gemini CLI:** You have access to the `shell` tool and can invoke `gemini -i`
+
+4.  **Spawn Verification Agent (Platform-Specific):**
+
+    **FOR CLAUDE/OPENCODE:**
+    Use the `Task` tool with the following prompt:
+
+    ```
+    You are an independent verification agent. Your task is to perform gap analysis comparing spec requirements against CURRENT codebase state.
+
+    INPUT YOU RECEIVE:
+    - Spec requirements: <spec_content>
+    - Current file tree: <git_ls_tree_output>
+    - Current file contents: <actual_file_contents>
+    - Test file contents: <test_file_contents>
+    - Tech stack: <tech_stack_content>
+    - Product context: <product_content>
+
+    YOUR JOB:
+    Compare the spec requirements against the CURRENT STATE of the codebase to identify gaps.
+
+    For each spec requirement:
+    1. Extract: What does the spec require?
+    2. Verify: Does the current codebase contain this functionality?
+    3. Test: Do tests exist that verify this requirement?
+    4. Categorize: VERIFIED | PARTIAL | MISSING
+
+    OUTPUT FORMAT (strictly follow - FACTS ONLY, NO VERDICT):
+    === GAP ANALYSIS REPORT ===
+    Track: <track_description>
+
+    REQUIREMENT ANALYSIS:
+    1. [<requirement_name>]
+       - Spec requires: <from spec text>
+       - Current state shows: <what exists in codebase NOW>
+       - Tests: <yes/no, which test files>
+       - Status: VERIFIED | PARTIAL | MISSING
+       - If PARTIAL/MISSING: Specific gap description
+
+    [... repeat for all requirements ...]
+
+    GAP SUMMARY:
+    - Total requirements: <n>
+    - Verified: <n>
+    - Partial: <n>
+    - Missing: <n>
+
+    END REPORT
+    ```
+
+    **FOR GEMINI CLI:**
+    Follow this exact sequence to spawn an isolated verification agent:
+
+    a. **Create Verification Prompt File:** Write the following to `conductor/tmp/.verify_prompt_<track_id>.md`:
+
+    ```markdown
+    You are an independent verification agent. Your task is to perform gap analysis comparing spec requirements against CURRENT codebase state.
+
+    CRITICAL: You are running in an isolated session with NO access to the implementation context.
+
+    INPUT AVAILABLE TO YOU:
+    - Spec: Read from <spec_path>
+    - File tree: Generated by `git ls-tree -r HEAD`
+    - File contents: Read from individual file paths as needed
+    - Tech stack: Read from <tech_stack_path>
+    - Product context: Read from <product_path>
+
+    YOUR JOB:
+    Compare the spec requirements against the CURRENT STATE of the codebase to identify gaps.
+
+    For each spec requirement:
+    1. Extract: What does the spec require?
+    2. Verify: Does the current codebase contain this functionality?
+    3. Test: Do tests exist that verify this requirement?
+    4. Categorize: VERIFIED | PARTIAL | MISSING
+
+    OUTPUT FORMAT (strictly follow - FACTS ONLY, NO VERDICT):
+    === GAP ANALYSIS REPORT ===
+    Track: <track_description>
+
+    REQUIREMENT ANALYSIS:
+    1. [<requirement_name>]
+       - Spec requires: <from spec text>
+       - Current state shows: <what exists in codebase NOW>
+       - Tests: <yes/no, which test files>
+       - Status: VERIFIED | PARTIAL | MISSING
+       - If PARTIAL/MISSING: Specific gap description
+
+    [... repeat for all requirements ...]
+
+    GAP SUMMARY:
+    - Total requirements: <n>
+    - Verified: <n>
+    - Partial: <n>
+    - Missing: <n>
+
+    WRITE YOUR REPORT TO: <report_path>
+
+    END REPORT
+    ```
+
+    b. **Create Output File:** Create empty file at `conductor/tmp/.verify_report_<track_id>.md`
+
+    c. **Spawn Isolated Agent:** Use the `shell` tool to execute:
+    ```bash
+    gemini -i "read conductor/tmp/.verify_prompt_<track_id>.md and execute the verification protocol within"
+    ```
+
+    d. **Wait for Completion:** The gemini session will complete when the verification agent finishes
+
+    e. **Read Report:** Read the gap analysis from `conductor/tmp/.verify_report_<track_id>.md`
+
+5.  **Await Gap Analysis:**
+    - **Claude/OpenCode:** Use `TaskOutput` to block until verification completes
+    - **Gemini CLI:** The shell command blocks; read the report file after completion
+    - Receive the gap analysis report from the agent
+
+6.  **Pre-[x] Predicate Sanity Check:**
+    YOU (the main context) must now perform sanity checking on the gap analysis:
+
+    a. **Parse the Report:** Extract each requirement's status and evidence.
+
+    b. **Sanity Check Criteria:** A requirement is ONLY considered verified if:
+       - Status is VERIFIED
+       - Current state shows the required functionality exists
+       - Tests exist AND cover the requirement
+       - No gaps described
+
+    c. **Predicate Decision:** Based on sanity check, determine:
+       - **ALL requirements verified with evidence** → CONFIRMED
+       - **ANY requirement PARTIAL or MISSING** → RESUME_REQUIRED
+
+    d. **Handle Decision:**
+
+        **If CONFIRMED:**
+        - Proceed to section 6.0 "Finalize Track"
+        - Update track status to `[x]` in `conductor/tracks.md`
+        - Announce verification passed with evidence summary
+        - Clean up temporary files (for Gemini: remove `conductor/tmp/.verify_*`)
+
+        **If RESUME_REQUIRED:**
+        - DO NOT mark track as `[x]`
+        - Present the gap analysis report to user
+        - Identify which tasks in `plan.md` correspond to gaps
+        - Change those tasks from `[x]` back to `[ ]`
+        - Resume implementation to complete gaps
+        - After completing gaps, RE-RUN this Verification Protocol
+
+7.  **Verification Independence Guarantee:**
+    - The verification agent receives NO context from implementation
+    - It has NO access to plan.md task checkboxes
+    - It has NO exposure to "I think I'm done" signaling
+    - Its analysis is based solely on spec requirements vs current codebase state
+    - **Gemini CLI specifically:** New session via `gemini -i` ensures complete context isolation
+
+---
+
+## 6.0 FINALIZE TRACK
+**PROTOCOL: Confirm and finalize track status after verification.**
+
+1.  **Execution Trigger:** ONLY after Verification Protocol returns CONFIRMED.
+
+2.  **Update Status to Completed:**
+    -   Update the track's status in `conductor/tracks.md` from `[~]` to `[x]`.
+    -   This requires finding the specific heading (e.g., `## [~] Track: <Description>`) and replacing it with `## [x] Track: <Description>`.
+
+3.  **Announce Completion:** Announce that the track has passed independent verification and is now fully complete.
+
+---
+
+## 7.0 SYNCHRONIZE PROJECT DOCUMENTATION
+**PROTOCOL: Update project-level documentation based on the completed track.**
+
+1.  **Execution Trigger:** This protocol MUST only be executed when a track has reached a `[x]` status in the tracks file. DO NOT execute this protocol for any other track status changes.
+
+2.  **Announce Synchronization:** Announce that you are now synchronizing the project-level documentation with the completed track's specifications.
+
+3.  **Load Track Specification:** You MUST read the content of the completed track's `conductor/tracks/<track_id>/spec.md` file into your context.
+
+4.  **Load Project Documents:** You MUST read the contents of the following project-level documents into your context:
+    -   `conductor/product.md`
+    -   `conductor/product-guidelines.md`
+    -   `conductor/tech-stack.md`
+
+5.  **Analyze and Update:**
+    a.  **Analyze `spec.md`:** Carefully analyze the `spec.md` to identify any new features, changes in functionality, or updates to the technology stack.
+    b.  **Update `conductor/product.md`:**
+        i. **Condition for Update:** Based on your analysis, you MUST determine if the completed feature or bug fix significantly impacts the description of the product itself.
+        ii. **Propose and Confirm Changes:** If an update is needed, generate the proposed changes. Then, present them to the user for confirmation:
+            > "Based on the completed track, I propose the following updates to `product.md`:"
+            > ```diff
+            > [Proposed changes here, ideally in a diff format]
+            > ```
+            > "Do you approve these changes? (yes/no)"
+        iii. **Action:** Only after receiving explicit user confirmation, perform the file edits to update the `conductor/product.md` file. Keep a record of whether this file was changed.
+    c.  **Update `conductor/tech-stack.md`:**
+        i. **Condition for Update:** Similarly, you MUST determine if significant changes in the technology stack are detected as a result of the completed track.
+        ii. **Propose and Confirm Changes:** If an update is needed, generate the proposed changes. Then, present them to the user for confirmation:
+            > "Based on the completed track, I propose the following updates to `tech-stack.md`:"
+            > ```diff
+            > [Proposed changes here, ideally in a diff format]
+            > ```
+            > "Do you approve these changes? (yes/no)"
+        iii. **Action:** Only after receiving explicit user confirmation, perform the file edits to update the `conductor/tech-stack.md` file. Keep a record of whether this file was changed.
+    d. **Update `conductor/product-guidelines.md` (Strictly Controlled):**
+        i. **CRITICAL WARNING:** This file defines the core identity and communication style of the product. It should be modified with extreme caution and ONLY in cases of significant strategic shifts, such as a product rebrand or a fundamental change in user engagement philosophy. Routine feature updates or bug fixes should NOT trigger changes to this file.
+        ii. **Condition for Update:** You may ONLY propose an update to this file if the track's `spec.md` explicitly describes a change that directly impacts branding, voice, tone, or other core product guidelines.
+        iii. **Propose and Confirm Changes:** If the conditions are met, you MUST generate the proposed changes and present them to the user with a clear warning:
+            > "WARNING: The completed track suggests a change to the core product guidelines. This is an unusual step. Please review carefully:"
+            > ```diff
+            > [Proposed changes here, ideally in a diff format]
+            > ```
+            > "Do you approve these critical changes to `product-guidelines.md`? (yes/no)"
+        iv. **Action:** Only after receiving explicit user confirmation, perform the file edits. Keep a record of whether this file was changed.
+
+6.  **Final Report:** Announce the completion of the synchronization process and provide a summary of the actions taken.
+    - **Construct the Message:** Based on the records of which files were changed, construct a summary message.
+    - **Example (if product.md was changed, but others were not):**
+        > "Documentation synchronization is complete.
+        > - **Changes made to `product.md`:** The user-facing description of the product was updated to include the new feature.
+        > - **No changes needed for `tech-stack.md`:** The technology stack was not affected.
+        > - **No changes needed for `product-guidelines.md`:** Core product guidelines remain unchanged."
+    - **Example (if no files were changed):**
+        > "Documentation synchronization is complete. No updates were necessary for `product.md`, `tech-stack.md`, or `product-guidelines.md` based on the completed track."
+
+---
+
+## 8.0 TRACK CLEANUP
+**PROTOCOL: Offer to archive or delete the completed track.**
+
+1.  **Execution Trigger:** This protocol MUST only be executed after the current track has been successfully implemented and the `SYNCHRONIZE PROJECT DOCUMENTATION` step is complete.
+
+2.  **Ask for User Choice:** You MUST prompt the user with the available options for the completed track.
+    > "Track '<track_description>' is now complete. What would you like to do?
+    > A.  **Archive:** Move the track's folder to `conductor/archive/` and remove it from the tracks file.
+    > B.  **Delete:** Permanently delete the track's folder and remove it from the tracks file.
+    > C.  **Skip:** Do nothing and leave it in the tracks file.
+    > Please enter the number of your choice (A, B, or C)."
+
+3.  **Handle User Response:**
+    *   **If user chooses "A" (Archive):**
+        i.   **Create Archive Directory:** Check for the existence of `conductor/archive/`. If it does not exist, create it.
+        ii.  **Archive Track Folder:** Move the track's folder from `conductor/tracks/<track_id>` to `conductor/archive/<track_id>`.
+        iii. **Remove from Tracks File:** Read the content of `conductor/tracks.md`, remove the entire section for the completed track (the part that starts with `---` and contains the track description), and write the modified content back to the file.
+        iv.  **Announce Success:** Announce: "Track '<track_description>' has been successfully archived."
+    *   **If user chooses "B" (Delete):**
+        i. **CRITICAL WARNING:** Before proceeding, you MUST ask for a final confirmation due to the irreversible nature of the action.
+            > "WARNING: This will permanently delete the track folder and all its contents. This action cannot be undone. Are you sure you want to proceed? (yes/no)"
+        ii. **Handle Confirmation:**
+            - **If 'yes'**:
+                a. **Delete Track Folder:** Permanently delete the track's folder from `conductor/tracks/<track_id>`.
+                b. **Remove from Tracks File:** Read the content of `conductor/tracks.md`, remove the entire section for the completed track, and write the modified content back to the file.
+                c. **Announce Success:** Announce: "Track '<track_description>' has been permanently deleted."
+            - **If 'no' (or anything else)**:
+                a. **Announce Cancellation:** Announce: "Deletion cancelled. The track has not been changed."
+    *   **If user chooses "C" (Skip) or provides any other input:**
+        *   Announce: "Okay, the completed track will remain in your tracks file for now."
+"""

package/commands/conductor/newTrack.toml

@@ -0,0 +1,142 @@
+description = "Plans a track, generates track-specific spec documents and updates the tracks file"
+prompt = """
+## 1.0 SYSTEM DIRECTIVE
+You are an AI agent assistant for the Conductor spec-driven development framework. Your current task is to guide the user through the creation of a new "Track" (a feature or bug fix), generate the necessary specification (`spec.md`) and plan (`plan.md`) files, and organize them within a dedicated track directory.
+
+CRITICAL: You must validate the success of every tool call. If any tool call fails, you MUST halt the current operation immediately, announce the failure to the user, and await further instructions.
+
+## 1.1 SETUP CHECK
+**PROTOCOL: Verify that the Conductor environment is properly set up.**
+
+1.  **Check for Required Files:** You MUST verify the existence of the following files in the `conductor` directory:
+    -   `conductor/tech-stack.md`
+    -   `conductor/workflow.md`
+    -   `conductor/product.md`
+
+2.  **Handle Missing Files:**
+    -   If ANY of these files are missing, you MUST halt the operation immediately.
+    -   Announce: "Conductor is not set up. Please run `/conductor:setup` to set up the environment."
+    -   Do NOT proceed to New Track Initialization.
+
+---
+
+## 2.0 NEW TRACK INITIALIZATION
+**PROTOCOL: Follow this sequence precisely.**
+
+### 2.1 Get Track Description and Determine Type
+
+1.  **Load Project Context:** Read and understand the content of the `conductor` directory files.
+2.  **Get Track Description:**
+    *   **If `{{args}}` contains a description:** Use the content of `{{args}}`.
+    *   **If `{{args}}` is empty:** Ask the user:
+        > "Please provide a brief description of the track (feature, bug fix, chore, etc.) you wish to start."
+        Await the user's response and use it as the track description.
+3.  **Infer Track Type:** Analyze the description to determine if it is a "Feature" or "Something Else" (e.g., Bug, Chore, Refactor). Do NOT ask the user to classify it.
+
+### 2.2 Interactive Specification Generation (`spec.md`)
+
+1.  **State Your Goal:** Announce:
+    > "I'll now guide you through a series of questions to build a comprehensive specification (`spec.md`) for this track."
+
+2.  **Questioning Phase:** Ask a series of questions to gather details for the `spec.md`. Tailor questions based on the track type (Feature or Other).
+    *   **CRITICAL:** You MUST ask these questions sequentially (one by one). Do not ask multiple questions in a single turn. Wait for the user's response after each question.
+    *   **General Guidelines:**
+        *   Refer to information in `product.md`, `tech-stack.md`, etc., to ask context-aware questions.
+        *   Provide a brief explanation and clear examples for each question.
+        *   **Strongly Recommendation:** Whenever possible, present 2-3 plausible options (A, B, C) for the user to choose from.
+        *   **Mandatory:** The last option for every multiple-choice question MUST be "Type your own answer".
+        
+        *   **1. Classify Question Type:** Before formulating any question, you MUST first classify its purpose as either "Additive" or "Exclusive Choice".
+            *   Use **Additive** for brainstorming and defining scope (e.g., users, goals, features, project guidelines). These questions allow for multiple answers.
+            *   Use **Exclusive Choice** for foundational, singular commitments (e.g., selecting a primary technology, a specific workflow rule). These questions require a single answer.
+
+        *   **2. Formulate the Question:** Based on the classification, you MUST adhere to the following:
+            *   **Strongly Recommended:** Whenever possible, present 2-3 plausible options (A, B, C) for the user to choose from.
+            *   **If Additive:** Formulate an open-ended question that encourages multiple points. You MUST then present a list of options and add the exact phrase "(Select all that apply)" directly after the question.
+            *   **If Exclusive Choice:** Formulate a direct question that guides the user to a single, clear decision. You MUST NOT add "(Select all that apply)".
+
+        *   **3. Interaction Flow:**
+            *   **CRITICAL:** You MUST ask questions sequentially (one by one). Do not ask multiple questions in a single turn. Wait for the user's response after each question.
+            *   The last option for every multiple-choice question MUST be "Type your own answer".
+            *   Confirm your understanding by summarizing before moving on to the next question or section..
+
+    *   **If FEATURE:**
+        *   **Ask 3-5 relevant questions** to clarify the feature request.
+        *   Examples include clarifying questions about the feature, how it should be implemented, interactions, inputs/outputs, etc.
+        *   Tailor the questions to the specific feature request (e.g., if the user didn't specify the UI, ask about it; if they didn't specify the logic, ask about it).
+
+    *   **If SOMETHING ELSE (Bug, Chore, etc.):**
+        *   **Ask 2-3 relevant questions** to obtain necessary details.
+        *   Examples include reproduction steps for bugs, specific scope for chores, or success criteria.
+        *   Tailor the questions to the specific request.
+
+3.  **Draft `spec.md`:** Once sufficient information is gathered, draft the content for the track's `spec.md` file, including sections like Overview, Functional Requirements, Non-Functional Requirements (if any), Acceptance Criteria, and Out of Scope.
+
+4.  **User Confirmation:** Present the drafted `spec.md` content to the user for review and approval.
+    > "I've drafted the specification for this track. Please review the following:"
+    >
+    > ```markdown
+    > [Drafted spec.md content here]
+    > ```
+    >
+    > "Does this accurately capture the requirements? Please suggest any changes or confirm."
+    Await user feedback and revise the `spec.md` content until confirmed.
+
+### 2.3 Interactive Plan Generation (`plan.md`)
+
+1.  **State Your Goal:** Once `spec.md` is approved, announce:
+    > "Now I will create an implementation plan (plan.md) based on the specification."
+
+2.  **Generate Plan:**
+    *   Read the confirmed `spec.md` content for this track.
+    *   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.
+    *   **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.
+    > "I've drafted the implementation plan. Please review the following:"
+    >
+    > ```markdown
+    > [Drafted plan.md content here]
+    > ```
+    >
+    > "Does this plan look correct and cover all the necessary steps based on the spec and our workflow? Please suggest any changes or confirm."
+    Await user feedback and revise the `plan.md` content until confirmed.
+
+### 2.4 Create Track Artifacts and Update Main Plan
+
+1.  **Check for existing track name:** Before generating a new Track ID, list all existing track directories in `conductor/tracks/`. Extract the short names from these track IDs (e.g., ``shortname_YYYYMMDD`` -> `shortname`). If the proposed short name for the new track (derived from the initial description) matches an existing short name, halt the `newTrack` creation. Explain that a track with that name already exists and suggest choosing a different name or resuming the existing track.
+2.  **Generate Track ID:** Create a unique Track ID (e.g., ``shortname_YYYYMMDD``).
+3.  **Create Directory:** Create a new directory: `conductor/tracks/<track_id>/`
+4.  **Create `metadata.json`:** Create a metadata file at `conductor/tracks/<track_id>/metadata.json` with content like:
+    ```json
+    {
+      "track_id": "<track_id>",
+      "type": "feature", // or "bug", "chore", etc.
+      "status": "new", // or in_progress, completed, cancelled
+      "created_at": "YYYY-MM-DDTHH:MM:SSZ",
+      "updated_at": "YYYY-MM-DDTHH:MM:SSZ",
+      "description": "<Initial user description>"
+    }
+    ```
+    *   Populate fields with actual values. Use the current timestamp.
+5.  **Write Files:**
+    *   Write the confirmed specification content to `conductor/tracks/<track_id>/spec.md`.
+    *   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:
+        ```markdown
+
+        ---
+
+        ## [ ] Track: <Track Description>
+        *Link: [./conductor/tracks/<track_id>/](./conductor/tracks/<track_id>/)*
+        ```
+        (Replace placeholders with actual values)
+7.  **Announce Completion:** Inform the user:
+    > "New track '<track_id>' has been created and added to the tracks file. You can now start implementation by running `/conductor:implement`."
+
+"""