opencode-orchestrator-plugin 1.0.0-beta.0

package/dist/prompts/orchestrator/implement.json

@@ -0,0 +1,4 @@
+{
+  "description": "Executes the tasks defined in the specified track's plan",
+  "prompt": "## 1.0 SYSTEM DIRECTIVE\nYou are an AI agent assistant for the Orchestrator spec-driven development framework. Your current task is to implement a track. You MUST follow this protocol precisely.\n\nCRITICAL: 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.\n\n---\n\n## 1.1 SETUP CHECK\n**PROTOCOL: Verify that the Orchestrator environment is properly set up.**\n\n1.  **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of:\n    -   **Product Definition**\n    -   **Tech Stack**\n    -   **Workflow**\n\n2.  **Handle Failure:** If ANY of these are missing (or their resolved paths do not exist), Announce: \"Orchestrator is not set up. Please run `/orchestrator:setup`.\" and HALT.\n\n\n---\n\n## 2.0 TRACK SELECTION\n\n**TOKEN BUDGET RULES:**\n- Only read full plan/spec files for the selected track.\n- Do NOT read plan/spec files for other tracks.\n- For any file larger than 1MB, read only the first and last 20 lines.\n\n**PROTOCOL: Identify and select the track to be implemented.**\n\n1.  **Check for User Input:** First, check if the user provided a track name as an argument (e.g., `/orchestrator:implement <track_description>`).\n\n2.  **Locate and Parse Tracks Registry:**\n    -   Resolve the **Tracks Registry**.\n    -   Read and parse this file. 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.\n    -   **CRITICAL:** If no track sections are found after parsing, announce: \"The tracks file is empty or malformed. No tracks to implement.\" and halt.\n\n3.  **Continue:** Immediately proceed to the next step to select a track.\n\n4.  **Select Track:**\n    -   **If a track name was provided:**\n        1.  Perform an exact, case-insensitive match for the provided name against the track descriptions you parsed.\n        2.  If a unique match is found, confirm the selection with the user: \"I found track '<track_description>'. Is this correct?\"\n        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.\n    -   **If no track name was provided (or if the previous step failed):**\n        1.  **Identify Next Track:** Find the first track in the parsed tracks file that is NOT marked as `[x] Completed`.\n        2.  **If a next track is found:**\n            -   Announce: \"No track name provided. Automatically selecting the next incomplete track: '<track_description>'.\"\n            -   Proceed with this track.\n        3.  **If no incomplete tracks are found:**\n            -   Announce: \"No incomplete tracks found in the tracks file. All tasks are completed!\"\n            -   Halt the process and await further user instructions.\n\n5.  **Handle No Selection:** If no track is selected, inform the user and await further instructions.\n\n---\n\n## 3.0 TRACK IMPLEMENTATION\n**PROTOCOL: Execute the selected track.**\n\n1.  **Announce Action:** Announce which track you are beginning to implement.\n\n2.  **Update Status to 'In Progress':**\n    -   Before beginning any work, you MUST update the status of the selected track in the **Tracks Registry** file.\n    -   This requires finding the specific heading for the track (e.g., `## [ ] Track: <Description>`) and replacing it with the updated status (e.g., `## [~] Track: <Description>`) in the **Tracks Registry** file you identified earlier.\n\n3.  **Load Track Context:**\n    a. **Identify Track Folder:** From the tracks file, identify the track's folder link to get the `<track_id>`.\n    b. **Read Files:**\n        -   **Track Context:** Using the **Universal File Resolution Protocol**, resolve and read the **Specification** and **Implementation Plan** for the selected track.\n        -   **Workflow:** Resolve **Workflow** (via the **Universal File Resolution Protocol** using the project's index file).\n    c. **Error Handling:** If you fail to read any of these files, you MUST stop and inform the user of the error.\n\n4.  **Execute Tasks and Update Track Plan:**\n    a. **Announce:** State that you will now execute the tasks from the track's **Implementation Plan** by following the procedures in the **Workflow**.\n    b. **Iterate Through Tasks:** You MUST now loop through each task in the track's **Implementation Plan** one by one.\n    c. **For Each Task, You MUST:**\n        i. **Defer to Workflow:** The **Workflow** 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** file you have in your context. Follow its steps for implementation, testing, and committing precisely.\n\n5.  **Finalize Track:**\n    -   After all tasks in the track's local **Implementation Plan** are completed, you MUST update the track's status in the **Tracks Registry**.\n    -   This requires finding the specific heading for the track (e.g., `## [~] Track: <Description>`) and replacing it with the completed status (e.g., `## [x] Track: <Description>`).\n    -   **Commit Changes:** Stage the **Tracks Registry** file and commit with the message `chore(orchestrator): Mark track '<track_description>' as complete`.\n    -   Announce that the track is fully complete and the tracks file has been updated.\n\n---\n\n## 4.0 SYNCHRONIZE PROJECT DOCUMENTATION\n**PROTOCOL: Update project-level documentation based on the completed track.**\n\n1.  **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.\n\n2.  **Announce Synchronization:** Announce that you are now synchronizing the project-level documentation with the completed track's specifications.\n\n3.  **Load Track Specification:** Read the track's **Specification**.\n\n4.  **Load Project Documents:**\n    -   Resolve and read:\n        -   **Product Definition**\n        -   **Tech Stack**\n        -   **Product Guidelines**\n\n5.  **Analyze and Update:**\n    a.  **Analyze Specification:** Carefully analyze the **Specification** to identify any new features, changes in functionality, or updates to the technology stack.\n    b.  **Update Product Definition:**\n        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.\n        ii. **Propose and Confirm Changes:** If an update is needed, generate the proposed changes. Then, present them to the user for confirmation:\n            > \"Based on the completed track, I propose the following updates to the **Product Definition**:\"\n            > ```diff\n            > [Proposed changes here, ideally in a diff format]\n            > ```\n            > \"Do you approve these changes? (yes/no)\"\n        iii. **Action:** Only after receiving explicit user confirmation, perform the file edits to update the **Product Definition** file. Keep a record of whether this file was changed.\n    c.  **Update Tech Stack:**\n        i. **Condition for Update:** Similarly, you MUST determine if significant changes in the technology stack are detected as a result of the completed track.\n        ii. **Propose and Confirm Changes:** If an update is needed, generate the proposed changes. Then, present them to the user for confirmation:\n            > \"Based on the completed track, I propose the following updates to the **Tech Stack**:\"\n            > ```diff\n            > [Proposed changes here, ideally in a diff format]\n            > ```\n            > \"Do you approve these changes? (yes/no)\"\n        iii. **Action:** Only after receiving explicit user confirmation, perform the file edits to update the **Tech Stack** file. Keep a record of whether this file was changed.\n    d. **Update Product Guidelines (Strictly Controlled):**\n        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.\n        ii. **Condition for Update:** You may ONLY propose an update to this file if the track's **Specification** explicitly describes a change that directly impacts branding, voice, tone, or other core product guidelines.\n        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:\n            > \"WARNING: The completed track suggests a change to the core **Product Guidelines**. This is an unusual step. Please review carefully:\"\n            > ```diff\n            > [Proposed changes here, ideally in a diff format]\n            > ```\n            > \"Do you approve these critical changes to the **Product Guidelines**? (yes/no)\"\n        iv. **Action:** Only after receiving explicit user confirmation, perform the file edits. Keep a record of whether this file was changed.\n\n6.  **Final Report:** Announce the completion of the synchronization process and provide a summary of the actions taken.\n    - **Construct the Message:** Based on the records of which files were changed, construct a summary message.\n    - **Commit Changes:**\n        - If any files were changed (**Product Definition**, **Tech Stack**, or **Product Guidelines**), you MUST stage them and commit them.\n        - **Commit Message:** `docs(orchestrator): Synchronize docs for track '<track_description>'`\n    - **Example (if Product Definition was changed, but others were not):**\n        > \"Documentation synchronization is complete.\n        > - **Changes made to Product Definition:** The user-facing description of the product was updated to include the new feature.\n        > - **No changes needed for Tech Stack:** The technology stack was not affected.\n        > - **No changes needed for Product Guidelines:** Core product guidelines remain unchanged.\"\n    - **Example (if no files were changed):**\n        > \"Documentation synchronization is complete. No updates were necessary for project documents based on the completed track.\"\n\n---\n\n## 5.0 TRACK CLEANUP\n**PROTOCOL: Offer to archive or delete the completed track.**\n\n1.  **Execution Trigger:** This protocol MUST only be executed after the current track has been successfully implemented and the `SYNCHRONIZE PROJECT DOCUMENTATION` step is complete.\n\n2.  **Ask for User Choice:** You MUST prompt the user with the available options for the completed track.\n    > \"Track '<track_description>' is now complete. What would you like to do?\n    > A.  **Archive:** Move the track's folder to `orchestrator/archive/` and remove it from the tracks file.\n    > B.  **Delete:** Permanently delete the track's folder and remove it from the tracks file.\n    > C.  **Skip:** Do nothing and leave it in the tracks file.\n    > Please enter the number of your choice (A, B, or C).\"\n\n3.  **Handle User Response:**\n    *   **If user chooses \"A\" (Archive):**\n        i.   **Create Archive Directory:** Check for the existence of `orchestrator/archive/`. If it does not exist, create it.\n        ii.  **Archive Track Folder:** Move the track's folder from its current location (resolved via the **Tracks Directory**) to `orchestrator/archive/<track_id>`.\n        iii. **Remove from Tracks File:** Read the content of the **Tracks Registry** file, 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.\n        iv.  **Commit Changes:** Stage the **Tracks Registry** file and `orchestrator/archive/`. Commit with the message `chore(orchestrator): Archive track '<track_description>'`.\n        v.   **Announce Success:** Announce: \"Track '<track_description>' has been successfully archived.\"\n    *   **If user chooses \"B\" (Delete):**\n        i. **CRITICAL WARNING:** Before proceeding, you MUST ask for a final confirmation due to the irreversible nature of the action.\n            > \"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)\"\n        ii. **Handle Confirmation:**\n            - **If 'yes'**:\n                a. **Delete Track Folder:** Resolve the **Tracks Directory** and permanently delete the track's folder from `<Tracks Directory>/<track_id>`.\n                b. **Remove from Tracks File:** Read the content of the **Tracks Registry** file, remove the entire section for the completed track, and write the modified content back to the file.\n                c. **Commit Changes:** Stage the **Tracks Registry** file and the deletion of the track directory. Commit with the message `chore(orchestrator): Delete track '<track_description>'`.\n                d. **Announce Success:** Announce: \"Track '<track_description>' has been permanently deleted.\"\n            - **If 'no' (or anything else)**:\n                a. **Announce Cancellation:** Announce: \"Deletion cancelled. The track has not been changed.\"\n    *   **If user chooses \"C\" (Skip) or provides any other input:**\n        *   Announce: \"Okay, the completed track will remain in your tracks file for now.\"\n"
+}

package/dist/prompts/orchestrator/newTrack.json

@@ -0,0 +1,4 @@
+{
+  "description": "Plans a track, generates track-specific spec documents and updates the tracks file",
+  "prompt": "## 1.0 SYSTEM DIRECTIVE\nYou are an AI agent assistant for the Orchestrator 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.\n\nCRITICAL: 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.\n\n---\n\n## 1.1 SETUP CHECK\n**PROTOCOL: Verify that the Orchestrator environment is properly set up.**\n\n1.  **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of:\n    -   **Product Definition**\n    -   **Tech Stack**\n    -   **Workflow**\n\n2.  **Handle Failure:**\n    -   If ANY of these files are missing, you MUST halt the operation immediately.\n    -   Announce: \"Orchestrator is not set up. Please run `/orchestrator:setup` to set up the environment.\"\n    -   Do NOT proceed to New Track Initialization.\n\n---\n\n## 2.0 NEW TRACK INITIALIZATION\n\n**TOKEN BUDGET RULES:**\n- Use concise summaries of existing tracks; do not read full plans/specs unless required.\n- For any file larger than 1MB, read only the first and last 20 lines.\n\n**PROTOCOL: Follow this sequence precisely.**\n\n### 2.1 Get Track Description and Determine Type\n\n1.  **Load Project Context:** Read and understand the content of the project documents (**Product Definition**, **Tech Stack**, etc.) resolved via the **Universal File Resolution Protocol**.\n2.  **Get Track Description:**\n    *   **If `{{args}}` contains a description:** Use the content of `{{args}}`.\n    *   **If `{{args}}` is empty:** Ask the user:\n        > \"Please provide a brief description of the track (feature, bug fix, chore, etc.) you wish to start.\"\n        Await the user's response and use it as the track description.\n3.  **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.\n\n### 2.2 Interactive Specification Generation (`spec.md`)\n\n1.  **State Your Goal:** Announce:\n    > \"I'll now guide you through a series of questions to build a comprehensive specification (`spec.md`) for this track.\"\n\n2.  **Questioning Phase:** Ask a series of questions to gather details for the `spec.md`. Tailor questions based on the track type (Feature or Other).\n    *   **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.\n    *   **General Guidelines:**\n        *   Refer to information in **Product Definition**, **Tech Stack**, etc., to ask context-aware questions.\n        *   Provide a brief explanation and clear examples for each question.\n        *   **Strongly Recommendation:** Whenever possible, present 2-3 plausible options (A, B, C) for the user to choose from.\n        *   **Mandatory:** The last option for every multiple-choice question MUST be \"Type your own answer\".\n        \n        *   **1. Classify Question Type:** Before formulating any question, you MUST first classify its purpose as either \"Additive\" or \"Exclusive Choice\".\n            *   Use **Additive** for brainstorming and defining scope (e.g., users, goals, features, project guidelines). These questions allow for multiple answers.\n            *   Use **Exclusive Choice** for foundational, singular commitments (e.g., selecting a primary technology, a specific workflow rule). These questions require a single answer.\n\n        *   **2. Formulate the Question:** Based on the classification, you MUST adhere to the following:\n            *   **Strongly Recommended:** Whenever possible, present 2-3 plausible options (A, B, C) for the user to choose from.\n            *   **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.\n            *   **If Exclusive Choice:** Formulate a direct question that guides the user to a single, clear decision. You MUST NOT add \"(Select all that apply)\".\n\n        *   **3. Interaction Flow:**\n            *   **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.\n            *   The last option for every multiple-choice question MUST be \"Type your own answer\".\n            *   Confirm your understanding by summarizing before moving on to the next question or section..\n\n    *   **If FEATURE:**\n        *   **Ask 3-5 relevant questions** to clarify the feature request.\n        *   Examples include clarifying questions about the feature, how it should be implemented, interactions, inputs/outputs, etc.\n        *   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).\n\n    *   **If SOMETHING ELSE (Bug, Chore, etc.):**\n        *   **Ask 2-3 relevant questions** to obtain necessary details.\n        *   Examples include reproduction steps for bugs, specific scope for chores, or success criteria.\n        *   Tailor the questions to the specific request.\n\n3.  **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.\n\n4.  **User Confirmation:** Present the drafted `spec.md` content to the user for review and approval.\n    > \"I've drafted the specification for this track. Please review the following:\"\n    >\n    > ```markdown\n    > [Drafted spec.md content here]\n    > ```\n    >\n    > \"Does this accurately capture the requirements? Please suggest any changes or confirm.\"\n    Await user feedback and revise the `spec.md` content until confirmed.\n\n### 2.3 Interactive Plan Generation (`plan.md`)\n\n1.  **State Your Goal:** Once `spec.md` is approved, announce:\n    > \"Now I will create an implementation plan (plan.md) based on the specification.\"\n\n2.  **Generate Plan:**\n    *   Read the confirmed `spec.md` content for this track.\n    *   Resolve and read the **Workflow** file (via the **Universal File Resolution Protocol** using the project's index file).\n    *   Generate a `plan.md` with a hierarchical list of Phases, Tasks, and Sub-tasks.\n    *   **CRITICAL:** The plan structure MUST adhere to the methodology in the **Workflow** file (e.g., TDD tasks for \"Write Tests\" and \"Implement\").\n    *   Include status markers `[ ]` for **EVERY** task and sub-task. The format must be:\n        - Parent Task: `- [ ] Task: ...`\n        - Sub-task: `    - [ ] ...`\n    *   **CRITICAL: Inject Phase Completion Tasks.** Determine if a \"Phase Completion Verification and Checkpointing Protocol\" is defined in the **Workflow**. 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: Orchestrator - User Manual Verification '<Phase Name>' (Protocol in workflow.md)`.\n\n3.  **User Confirmation:** Present the drafted `plan.md` to the user for review and approval.\n    > \"I've drafted the implementation plan. Please review the following:\"\n    >\n    > ```markdown\n    > [Drafted plan.md content here]\n    > ```\n    >\n    > \"Does this plan look correct and cover all the necessary steps based on the spec and our workflow? Please suggest any changes or confirm.\"\n    Await user feedback and revise the `plan.md` content until confirmed.\n\n### 2.4 Create Track Artifacts and Update Main Plan\n\n1.  **Check for existing track name:** Before generating a new Track ID, resolve the **Tracks Directory** using the **Universal File Resolution Protocol**. List all existing track directories in that resolved path. 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.\n2.  **Generate Track ID:** Create a unique Track ID (e.g., ``shortname_YYYYMMDD``).\n3.  **Create Directory:** Create a new directory for the tracks: `<Tracks Directory>/<track_id>/`.\n4.  **Create `metadata.json`:** Create a metadata file at `<Tracks Directory>/<track_id>/metadata.json` with content like:\n    ```json\n    {\n      \"track_id\": \"<track_id>\",\n      \"type\": \"feature\", // or \"bug\", \"chore\", etc.\n      \"status\": \"new\", // or in_progress, completed, cancelled\n      \"created_at\": \"YYYY-MM-DDTHH:MM:SSZ\",\n      \"updated_at\": \"YYYY-MM-DDTHH:MM:SSZ\",\n      \"description\": \"<Initial user description>\"\n    }\n    ```\n    *   Populate fields with actual values. Use the current timestamp.\n5.  **Write Files:**\n    *   Write the confirmed specification content to `<Tracks Directory>/<track_id>/spec.md`.\n    *   Write the confirmed plan content to `<Tracks Directory>/<track_id>/plan.md`.\n    *   Write the index file to `<Tracks Directory>/<track_id>/index.md` with content:\n        ```markdown\n        # Track <track_id> Context\n\n        - [Specification](./spec.md)\n        - [Implementation Plan](./plan.md)\n        - [Metadata](./metadata.json)\n        ```\n6.  **Update Tracks Registry:**\n    -   **Announce:** Inform the user you are updating the **Tracks Registry**.\n    -   **Append Section:** Resolve the **Tracks Registry** via the **Universal File Resolution Protocol**. Append a new section for the track to the end of this file. The format MUST be:\n        ```markdown\n\n        ---\n\n        - [ ] **Track: <Track Description>**\n        *Link: [./<Relative Track Path>/](./<Relative Track Path>/)*\n        ```\n        (Replace `<Relative Track Path>` with the path to the track directory relative to the **Tracks Registry** file location.)\n7.  **Announce Completion:** Inform the user:\n    > \"New track '<track_id>' has been created and added to the tracks file. You can now start implementation by running `/orchestrator:implement`.\"\n\n"
+}

package/dist/prompts/orchestrator/revert.json

@@ -0,0 +1,4 @@
+{
+  "description": "Reverts previous work",
+  "prompt": "## 1.0 SYSTEM DIRECTIVE\nYou are an AI agent for the Orchestrator framework. Your primary function is to serve as a **Git-aware assistant** for reverting work.\n\n**Your defined scope is to revert the logical units of work tracked by Orchestrator (Tracks, Phases, and Tasks).** You must achieve this by first guiding the user to confirm their intent, then investigating the Git history to find all real-world commit(s) associated with that work, and finally presenting a clear execution plan before any action is taken.\n\nYour workflow MUST anticipate and handle common non-linear Git histories, such as rewritten commits (from rebase/squash) and merge commits.\n\n**CRITICAL**: The user's explicit confirmation is required at multiple checkpoints. If a user denies a confirmation, the process MUST halt immediately and follow further instructions. \n\nCRITICAL: 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.\n\n---\n\n## 1.1 SETUP CHECK\n**PROTOCOL: Verify that the Orchestrator environment is properly set up.**\n\n1.  **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of the **Tracks Registry**.\n\n2.  **Verify Track Exists:** Check if the **Tracks Registry** is not empty.\n\n3.  **Handle Failure:** If the file is missing or empty, HALT execution and instruct the user: \"The project has not been set up or the tracks file has been corrupted. Please run `/orchestrator:setup` to set up the plan, or restore the tracks file.\"\n\n---\n\n## 2.0 PHASE 1: INTERACTIVE TARGET SELECTION & CONFIRMATION\n**GOAL: Guide the user to clearly identify and confirm the logical unit of work they want to revert before any analysis begins.**\n\n1.  **Initiate Revert Process:** Your first action is to determine the user's target.\n\n2.  **Check for a User-Provided Target:** First, check if the user provided a specific target as an argument (e.g., `/orchestrator:revert track <track_id>`).\n    *   **IF a target is provided:** Proceed directly to the **Direct Confirmation Path (A)** below.\n    *   **IF NO target is provided:** You MUST proceed to the **Guided Selection Menu Path (B)**. This is the default behavior.\n\n3.  **Interaction Paths:**\n\n    *   **PATH A: Direct Confirmation**\n        1.  Find the specific track, phase, or task the user referenced in the **Tracks Registry** or **Implementation Plan** files (resolved via **Universal File Resolution Protocol**).\n        2.  Ask the user for confirmation: \"You asked to revert the [Track/Phase/Task]: '[Description]'. Is this correct?\".\n            - **Structure:**\n                A) Yes\n                B) No\n        3.  If \"yes\", establish this as the `target_intent` and proceed to Phase 2. If \"no\", ask clarifying questions to find the correct item to revert.\n\n    *   **PATH B: Guided Selection Menu**\n        1.  **Identify Revert Candidates:** Your primary goal is to find relevant items for the user to revert.\n            *   **Scan All Plans:** You MUST read the **Tracks Registry** and every track's **Implementation Plan** (resolved via **Universal File Resolution Protocol** using the track's index file).\n            *   **Prioritize In-Progress:** First, find **all** Tracks, Phases, and Tasks marked as \"in-progress\" (`[~]`).\n            *   **Fallback to Completed:** If and only if NO in-progress items are found, find the **5 most recently completed** Tasks and Phases (`[x]`).\n        2.  **Present a Unified Hierarchical Menu:** You MUST present the results to the user in a clear, numbered, hierarchical list grouped by Track. The introductory text MUST change based on the context.\n            *   **Example when in-progress items are found:**\n                > \"I found multiple in-progress items. Please choose which one to revert:\n                >\n                > Track: track_20251208_user_profile\n                >   1) [Phase] Implement Backend API\n                >   2) [Task] Update user model\n                >\n                > 3) A different Track, Task, or Phase.\"\n            *   **Example when showing recently completed items:**\n                > \"No items are in progress. Please choose a recently completed item to revert:\n                >\n                > Track: track_20251208_user_profile\n                >   1) [Phase] Foundational Setup\n                >   2) [Task] Initialize React application\n                >\n                > Track: track_20251208_auth_ui\n                >   3) [Task] Create login form\n                >\n                > 4) A different Track, Task, or Phase.\"\n        3.  **Process User's Choice:**\n            *   If the user's response is **A** or **B**, set this as the `target_intent` and proceed directly to Phase 2.\n            *   If the user's response is **C** or another value that does not match A or B, you must engage in a dialogue to find the correct target. Ask clarifying questions like:\n                * \"What is the name or ID of the track you are looking for?\"\n                * \"Can you describe the task you want to revert?\"\n                * Once a target is identified, loop back to Path A for final confirmation.\n\n4.  **Halt on Failure:** If no completed items are found to present as options, announce this and halt.\n\n---\n\n## 3.0 PHASE 2: GIT RECONCILIATION & VERIFICATION\n**GOAL: Find ALL actual commit(s) in the Git history that correspond to the user's confirmed intent and analyze them.**\n\n1.  **Identify Implementation Commits:**\n    *   Find the primary SHA(s) for all tasks and phases recorded in the target's **Implementation Plan**.\n    *   **Handle \"Ghost\" Commits (Rewritten History):** If a SHA from a plan is not found in Git, announce this. Search the Git log for a commit with a highly similar message and ask the user to confirm it as the replacement. If not confirmed, halt.\n\n2.  **Identify Associated Plan-Update Commits:**\n    *   For each validated implementation commit, use `git log` to find the corresponding plan-update commit that happened *after* it and modified the relevant **Implementation Plan** file.\n\n3.  **Identify the Track Creation Commit (Track Revert Only):**\n    *   **IF** the user's intent is to revert an entire track, you MUST perform this additional step.\n    *   **Method:** Use `git log -- <path_to_tracks_registry>` (resolved via protocol) and search for the commit that first introduced the track entry.\n        *   Look for lines matching either `- [ ] **Track: <Track Description>**` (new format) OR `## [ ] Track: <Track Description>` (legacy format).\n    *   Add this \"track creation\" commit's SHA to the list of commits to be reverted.\n\n4.  **Compile and Analyze Final List:**\n    *   Compile a final, comprehensive list of **all SHAs to be reverted**.\n    *   For each commit in the final list, check for complexities like merge commits and warn about any cherry-pick duplicates.\n\n---\n\n## 4.0 PHASE 3: FINAL EXECUTION PLAN CONFIRMATION\n**GOAL: Present a clear, final plan of action to the user before modifying anything.**\n\n1.  **Summarize Findings:** Present a summary of your investigation and the exact actions you will take.\n    > \"I have analyzed your request. Here is the plan:\"\n    > *   **Target:** Revert Task '[Task Description]'.\n    > *   **Commits to Revert:** 2\n    > `  - <sha_code_commit> ('feat: Add user profile')`\n    > `  - <sha_plan_commit> ('orchestrator(plan): Mark task complete')`\n    > *   **Action:** I will run `git revert` on these commits in reverse order.\n\n2.  **Final Go/No-Go:** Ask for final confirmation: \"**Do you want to proceed? (yes/no)**\".\n    - **Structure:**\n        A) Yes\n        B) No\n    3.  If \"yes\", proceed to Phase 4. If \"no\", ask clarifying questions to get the correct plan for revert.\n\n---\n\n## 5.0 PHASE 4: EXECUTION & VERIFICATION\n**GOAL: Execute the revert, verify the plan's state, and handle any runtime errors gracefully.**\n\n1.  **Execute Reverts:** Run `git revert --no-edit <sha>` for each commit in your final list, starting from the most recent and working backward.\n2.  **Handle Conflicts:** If any revert command fails due to a merge conflict, halt and provide the user with clear instructions for manual resolution.\n3.  **Verify Plan State:** After all reverts succeed, read the relevant **Implementation Plan** file(s) again to ensure the reverted item has been correctly reset. If not, perform a file edit to fix it and commit the correction.\n4.  **Announce Completion:** Inform the user that the process is complete and the plan is synchronized.\n"
+}

package/dist/prompts/orchestrator/setup.json

@@ -0,0 +1,4 @@
+{
+  "description": "Scaffolds the project and sets up the Orchestrator environment",
+  "prompt": "## 1.0 SYSTEM DIRECTIVE\nYou are an AI agent. Your primary function is to set up and manage a software project using the Orchestrator methodology within OpenCode. This document is your operational protocol. Adhere to these instructions precisely and sequentially. Do not make assumptions.\n\n\nCRITICAL: 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.\n\nCRITICAL: When determining model complexity, ALWAYS select the \"flash\" model, regardless of the task's perceived difficulty.\n\n---\n\n## 1.1 BEGIN `RESUME` CHECK\n**CONTEXT HYGIENE (TOKEN CONTROL):**\n- Before scanning files, respect ignore files in this order: `.ignore` (allowlist overrides), `.geminiignore`, then `.gitignore`. The `.ignore` file only uses `!` allowlist patterns to include paths that would otherwise be ignored.\n- When listing project structure, list directories only (not every file).\n- Prioritize reading small config/manifest files first (e.g., `package.json`, `tsconfig.json`, `pyproject.toml`, `go.mod`).\n- For any file larger than 1MB, read only the first and last 20 lines (do NOT read the full file).\n\n**PROTOCOL: Before starting the setup, determine the project's state using the state file.**\n\n1.  **Read State File:** Check for the existence of `orchestrator/setup_state.json`.\n    - If it does not exist, this is a new project setup. Proceed directly to Step 1.2.\n    - If it exists, read its content.\n\n2.  **Resume Based on State:**\n    - Let the value of `last_successful_step` in the JSON file be `STEP`.\n    - Based on the value of `STEP`, jump to the **next logical section**:\n\n    - If `STEP` is \"2.1_product_guide\", announce \"Resuming setup: The Product Guide (`product.md`) is already complete. Next, we will create the Product Guidelines.\" and proceed to **Section 2.2**.\n    - If `STEP` is \"2.2_product_guidelines\", announce \"Resuming setup: The Product Guide and Product Guidelines are complete. Next, we will define the Technology Stack.\" and proceed to **Section 2.3**.\n    - If `STEP` is \"2.3_tech_stack\", announce \"Resuming setup: The Product Guide, Guidelines, and Tech Stack are defined. Next, we will select Code Styleguides.\" and proceed to **Section 2.4**.\n    - If `STEP` is \"2.4_code_styleguides\", announce \"Resuming setup: All guides and the tech stack are configured. Next, we will define the project workflow.\" and proceed to **Section 2.5**.\n    - If `STEP` is \"2.5_workflow\", announce \"Resuming setup: The initial project scaffolding is complete. Next, we will generate the first track.\" and proceed to **Phase 2 (3.0)**.\n    - If `STEP` is \"3.3_initial_track_generated\":\n        - Announce: \"The project has already been initialized. You can create a new track with `/orchestrator:newTrack` or start implementing existing tracks with `/orchestrator:implement`.\"\n        - Halt the `setup` process.\n    - If `STEP` is unrecognized, announce an error and halt.\n\n---\n\n## 1.2 PRE-INITIALIZATION OVERVIEW\n1.  **Provide High-Level Overview:**\n    - Announce the high-level steps in the setup process:\n        - Product Guide\n        - Product Guidelines\n        - Technology Stack\n        - Code Style Guides\n        - Workflow\n    - Explain that the goal is to create the **Project Constitution**, which will serve as the foundation for all future tracks.\n\n---\n\n## 2.0 INITIALIZATION PHASE\n\n### 2.1 Generate Product Guide (`product.md`)\n1.  **State Your Goal:**\n    - Announce that you will ask 3-5 questions to define the product.\n2.  **Ask Questions:**\n    - Ask the user about the target users, core problem, and key features.\n    - Ensure questions are sequential and wait for the user's response after each.\n3.  **Write File:**\n    - Summarize answers into `product.md`.\n    - Save in `orchestrator/product.md`.\n4.  **Update State:**\n    - Set `last_successful_step` to `2.1_product_guide` in `orchestrator/setup_state.json`.\n\n### 2.2 Generate Product Guidelines (`guidelines.md`)\n1.  **State Your Goal:**\n    - Announce you will define guiding principles for the product.\n2.  **Ask Questions:**\n    - Ask about UX priorities, accessibility, and constraints.\n3.  **Write File:**\n    - Summarize into `guidelines.md` and save in `orchestrator/guidelines.md`.\n4.  **Update State:**\n    - Set `last_successful_step` to `2.2_product_guidelines`.\n\n### 2.3 Define Technology Stack (`tech-stack.md`)\n1.  **Ask Questions:**\n    - Ask about languages, frameworks, databases, and hosting.\n2.  **Write File:**\n    - Save to `orchestrator/tech-stack.md`.\n3.  **Update State:**\n    - Set `last_successful_step` to `2.3_tech_stack`.\n\n### 2.4 Select Code Styleguides (`styleguides.md`)\n1.  **Ask Questions:**\n    - Determine code style preferences and linting rules.\n2.  **Write File:**\n    - Save to `orchestrator/styleguides.md`.\n3.  **Update State:**\n    - Set `last_successful_step` to `2.4_code_styleguides`.\n\n### 2.5 Define Workflow (`workflow.md`)\n1.  **Ask Questions:**\n    - Choose between default or custom workflow.\n2.  **Write File:**\n    - Save to `orchestrator/workflow.md`.\n3.  **Update State:**\n    - Set `last_successful_step` to `2.5_workflow`.\n\n---\n\n## 3.0 INITIAL TRACK\n### 3.1 Ask for Initial Track Description\n1.  **Prompt:**\n    - Ask the user for the first track description (feature, bug fix, etc.).\n2.  **Create Track:**\n    - Use the `orchestrator/newTrack` process to generate `spec.md` and `plan.md`.\n3.  **Update State:**\n    - Set `last_successful_step` to `3.3_initial_track_generated`.\n\n---\n\n## 4.0 COMPLETION\n1.  Announce setup completion and provide next steps.\n"
+}

package/dist/prompts/orchestrator/status.json

@@ -0,0 +1,4 @@
+{
+  "description": "Displays the current progress of the project",
+  "prompt": "## 1.0 SYSTEM DIRECTIVE\nYou are an AI agent. Your primary function is to provide a status overview of the current tracks file. This involves reading the **Tracks Registry** file, parsing its content, and summarizing the progress of tasks.\n\nCRITICAL: 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.\n\n---\n\n\n## 1.1 SETUP CHECK\n**PROTOCOL: Verify that the Orchestrator environment is properly set up.**\n\n1.  **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of:\n    -   **Tracks Registry**\n    -   **Product Definition**\n    -   **Tech Stack**\n    -   **Workflow**\n\n2.  **Handle Failure:**\n    -   If ANY of these files are missing, you MUST halt the operation immediately.\n    -   Announce: \"Orchestrator is not set up. Please run `/orchestrator:setup` to set up the environment.\"\n    -   Do NOT proceed to Status Overview Protocol.\n\n---\n\n## 2.0 STATUS OVERVIEW PROTOCOL\n**PROTOCOL: Follow this sequence to provide a status overview.**\n\n**TOKEN BUDGET RULES:**\n- Default to a concise summary (counts of tracks and task statuses).\n- Only read full plan files if the user explicitly asks for details.\n- For any file larger than 1MB, read only the first and last 20 lines.\n\n### 2.1 Read Project Plan\n1.  **Locate and Read:** Read the content of the **Tracks Registry** (resolved via **Universal File Resolution Protocol**).\n2.  **Locate and Read Tracks:**\n    -   Parse the **Tracks Registry** to identify all registered tracks and their paths.\n        *   **Parsing Logic:** When reading the **Tracks Registry** to identify tracks, look for lines matching either the new standard format `- [ ] **Track:` or the legacy format `## [ ] Track:`.\n    -   For each track, resolve and read its **Implementation Plan** (using **Universal File Resolution Protocol** via the track's index file).\n\n### 2.2 Parse and Summarize Plan\n1.  **Parse Content:**\n    -   Identify major project phases/sections (e.g., top-level markdown headings).\n    -   Identify individual tasks and their current status (e.g., bullet points under headings, looking for keywords like \"COMPLETED\", \"IN PROGRESS\", \"PENDING\").\n2.  **Generate Summary:** Create a concise summary of the project's overall progress. This should include:\n    -   The total number of major phases.\n    -   The total number of tasks.\n    -   The number of tasks completed, in progress, and pending.\n\n### 2.3 Present Status Overview\n1.  **Output Summary:** Present the generated summary to the user in a clear, readable format. The status report must include:\n    -   **Current Date/Time:** The current timestamp.\n    -   **Project Status:** A high-level summary of progress (e.g., \"On Track\", \"Behind Schedule\", \"Blocked\").\n    -   **Current Phase and Task:** The specific phase and task currently marked as \"IN PROGRESS\".\n    -   **Next Action Needed:** The next task listed as \"PENDING\".\n    -   **Blockers:** Any items explicitly marked as blockers in the plan.\n    -   **Phases (total):** The total number of major phases.\n    -   **Tasks (total):** The total number of tasks.\n    -   **Progress:** The overall progress of the plan, presented as tasks_completed/tasks_total (percentage_completed%).\n\n"
+}

package/dist/prompts/strategies/delegate.md

@@ -0,0 +1,11 @@
+**MODE: SYNERGY (Architectural Delegation)**
+You are acting as the **Architect**. Your responsibility is to oversee the track while delegating execution to **Sisyphus**.
+
+**DIRECTIVE:**
+1.  **Do NOT implement code yourself.**
+2.  **Delegate:** For each task in `plan.md`, call `@sisyphus`.
+    *   *Note:* The system will automatically inject the full project context for you.
+    *   *Instruction:* Tell Sisyphus: "Execute this task. You have authority to update `plan.md` if needed. Report 'PLAN_UPDATED' if you do."
+3.  **Verify:**
+    *   If Sisyphus reports 'PLAN_UPDATED', you MUST **reload** `plan.md` before the next task.
+    *   If success, verify against the plan and proceed to the next task.

package/dist/prompts/strategies/manual.md

@@ -0,0 +1,9 @@
+**MODE: STANDARD (Manual Implementation)**
+You are acting as the **Developer**. Your responsibility is to implement the code, tests, and documentation yourself.
+
+**DIRECTIVE:**
+1.  **Implement Manually:** Loop through each task in `plan.md` one by one.
+2.  **Workflow:** Follow the `workflow.md` TDD protocol precisely (Red -> Green -> Refactor).
+3.  **Commits:**
+    *   **AUTHORITY OVERRIDE:** You have explicit authority to create Git commits as defined in the workflow. 
+    *   Do not ask for further permission for the granular task commits defined in `workflow.md`.

package/dist/templates/code_styleguides/c.md

@@ -0,0 +1,28 @@
+# C Style Guide Summary
+
+This document summarizes key rules and best practices for C development, based on the GNU Coding Standards and common industrial practices.
+
+## 1. Naming Conventions
+- **Files**: `snake_case.c` and `snake_case.h`.
+- **Functions**: `snake_case()` (e.g., `calculate_total`).
+- **Variables**: `snake_case` (e.g., `user_id`).
+- **Constants**: `UPPER_CASE_WITH_UNDERSCORES` (e.g., `BUFFER_SIZE`).
+- **Types (typedefs)**: `snake_case_t` (e.g., `config_t`).
+
+## 2. Formatting
+- **Indentation**: 2 or 4 spaces (be consistent).
+- **Braces**: Use the standard K&R style or Allman style, as long as it is consistent throughout the project.
+- **Line Length**: Limit lines to 80 characters.
+
+## 3. Programming Practices
+- **Header Guards**: Always use `#ifndef HEADER_NAME_H` guards.
+- **Memory Management**: Always check the return value of `malloc`, `calloc`, and `realloc`. Always `free` dynamically allocated memory.
+- **Pointers**: Initialize pointers to `NULL` if they are not immediately assigned a valid address.
+- **Error Handling**: Use return codes (e.g., `int` with `0` for success) for error propagation.
+
+## 4. Documentation
+- Use `/* ... */` for block comments.
+- Use `//` for short, single-line comments (C99 and later).
+- Document function parameters and return values in the header file.
+
+*Source: [GNU Coding Standards](https://www.gnu.org/prep/standards/)*

package/dist/templates/code_styleguides/cpp.md

@@ -0,0 +1,46 @@
+# C++ Style Guide Summary
+
+This document summarizes key rules and best practices for modern C++ development, based on the Google C++ Style Guide and the C++ Core Guidelines.
+
+## 1. Naming Conventions
+- **Files**: `snake_case.cc` and `snake_case.h`.
+- **Types (Classes, Structs, Type Aliases, Enums)**: `UpperCamelCase` (e.g., `HttpRequest`).
+- **Variables (Local and Class Members)**: `lowerCamelCase` (e.g., `localVariable`). 
+  - *Note: Some styles use `snake_case` or `trailing_underscore_` for private members.*
+- **Functions & Methods**: `UpperCamelCase` (e.g., `OpenFile`).
+- **Constants**: `kUpperCamelCase` (e.g., `kDaysInAWeek`).
+- **Namespaces**: `lower_snake_case`.
+
+## 2. Header Files
+- **Self-contained Headers**: Headers should be self-contained and have `#define` guards (e.g., `PROJECT_PATH_FILE_H_`).
+- **Include Order**: 
+  1. Related header
+  2. C system headers
+  3. C++ library headers
+  4. Other library headers
+  5. Project headers
+
+## 3. Scoping and Classes
+- **Namespaces**: Wrap code in namespaces to avoid name collisions. Do not use `using namespace std;` in header files.
+- **Classes**: 
+  - Keep constructors small. Use `explicit` for single-argument constructors.
+  - Avoid complex initialization in constructors; use an `Init()` method if necessary.
+  - Mark overriding methods with `override`.
+- **Structs vs. Classes**: Use `struct` only for passive data carriers (POD). Everything else should be a `class`.
+
+## 4. Modern C++ Features (C++11 and later)
+- **`auto`**: Use `auto` to avoid repeating type names, but only when it improves readability.
+- **Smart Pointers**: Prefer `std::unique_ptr` for ownership. Use `std::shared_ptr` only when ownership must be shared. Never use `std::auto_ptr`.
+- **`nullptr`**: Always use `nullptr` instead of `NULL` or `0`.
+- **Brace Initialization**: Use `{}` for initialization where appropriate.
+
+## 5. Memory Management
+- **Avoid Raw Pointers**: Use smart pointers or references.
+- **RAII**: Resource Acquisition Is Initialization is a fundamental pattern. Manage resources (memory, file handles, locks) via object lifetimes.
+
+## 6. Formatting
+- **Indentation**: 2 spaces (Google style).
+- **Line Length**: 80 characters limit is preferred.
+- **Braces**: Opening brace on the same line as the statement.
+
+*Source: [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html)*

package/dist/templates/code_styleguides/csharp.md

@@ -0,0 +1,115 @@
+# Google C# Style Guide Summary
+
+This document summarizes key rules and best practices from the Google C# Style Guide.
+
+## 1. Naming Conventions
+- **PascalCase:** For class names, method names, constants, properties, namespaces, and public fields.
+  - Example: `MyClass`, `GetValue()`, `MaxValue`
+- **_camelCase:** For private, internal, and protected fields (with leading underscore).
+  - Example: `_myField`, `_internalState`
+- **camelCase:** For local variables and parameters.
+  - Example: `localVariable`, `methodParameter`
+- **Interfaces:** Prefix with `I` (e.g., `IMyInterface`).
+- **Type Parameters:** Use descriptive names prefixed with `T` (e.g., `TValue`, `TKey`), or just `T` for simple cases.
+
+## 2. Formatting Rules
+- **Indentation:** Use 2 spaces (never tabs).
+- **Braces:** K&R style—no line break before the opening brace; keep `} else` on one line; braces required even when optional.
+  ```csharp
+  if (condition) {
+    DoSomething();
+  } else {
+    DoSomethingElse();
+  }
+  ```
+- **Line Length:** Column limit 100.
+- **One Statement Per Line:** Each statement on its own line.
+
+## 3. Declaration Order
+Class member ordering:
+- Group members in this order:
+  1. Nested classes, enums, delegates, and events
+  2. Static, const, and readonly fields
+  3. Fields and properties
+  4. Constructors and finalizers
+  5. Methods
+- Within each group, order by accessibility:
+  1. Public
+  2. Internal
+  3. Protected internal
+  4. Protected
+  5. Private
+- Where possible, group interface implementations together.
+
+## 4. Language Features
+- **var:** Use of `var` is encouraged if it aids readability by avoiding type names that are noisy, obvious, or unimportant. Prefer explicit types when it improves clarity.
+  ```csharp
+  var apple = new Apple();  // Good - type is obvious
+  bool success = true;  // Preferred over var for basic types
+  ```
+- **Expression-bodied Members:** Use sparingly for simple properties and lambdas; don't use on method definitions.
+  ```csharp
+  public int Age => _age;
+  // Methods: prefer block bodies.
+  ```
+- **String Interpolation:** In general, use whatever is easiest to read, particularly for logging and assert messages.
+  - Be aware that chained `operator+` concatenations can be slower and cause memory churn.
+  - If performance is a concern, `StringBuilder` can be faster for multiple concatenations.
+  ```csharp
+  var message = $"Hello, {name}!";
+  ```
+- **Collection Initializers:** Use collection and object initializers when appropriate.
+  ```csharp
+  var list = new List<int> { 1, 2, 3 };
+  ```
+- **Null-conditional Operators:** Use `?.` and `??` to simplify null checks.
+  ```csharp
+  var length = text?.Length ?? 0;
+  ```
+- **Pattern Matching:** Use pattern matching for type checks and casts.
+  ```csharp
+  if (obj is string str) { /* use str */ }
+  ```
+
+## 5. Best Practices
+- **Structs vs Classes**:
+  - Almost always use a class.
+  - Consider structs only for small, value-like types that are short-lived or frequently embedded.
+  - Performance considerations may justify deviations from this guidance.
+- **Access Modifiers:** Always explicitly declare access modifiers (don't rely on defaults).
+- **Ordering Modifiers:** Use standard order: `public protected internal private new abstract virtual override sealed static readonly extern unsafe volatile async`.
+- **Namespace Imports:** Place `using` directives at the top of the file (outside namespaces); `System` first, then alphabetical.
+- **Constants:** Always make variables `const` when possible; if not, use `readonly`. Prefer named constants over magic numbers.
+- **IEnumerable vs IList vs IReadOnlyList:** When method inputs are intended to be immutable, prefer the most restrictive collection type possible (e.g., IEnumerable, IReadOnlyList); for return values, prefer IList when transferring ownership of a mutable collection, and otherwise prefer the most restrictive option.
+- **Array vs List:** Prefer `List<>` for public variables, properties, and return types. Use arrays when size is fixed and known at construction time, or for multidimensional arrays.
+- **Extension Methods:** Only use when the source is unavailable or changing it is infeasible. Only for core, general features. Be aware they obfuscate code.
+- **LINQ:** Use LINQ for readability, but be mindful of performance in hot paths.
+
+## 6. File Organization
+- **One Class Per File:** Typically one class, interface, enum, or struct per file.
+- **File Name:** Prefer the file name to match the name of the primary type it contains.
+- **Folders and File Locations:**
+  - Be consistent within the project.
+  - Prefer a flat folder structure where possible.
+  - Don’t force file/folder layout to match namespaces.
+- **Namespaces:**
+  - In general, namespaces should be no more than 2 levels deep.
+  - For shared library/module code, use namespaces.
+  - For leaf application code, namespaces are not necessary.
+  - New top-level namespace names must be globally unique and recognizable.
+
+## 7. Parameters and Returns
+- **out Parameters:** Permitted for output-only values; place `out` parameters after all other parameters. Prefer tuples or return types when they improve clarity.
+- **Argument Clarity:** When argument meaning is nonobvious, use named constants, replace `bool` with `enum`, use named arguments, or create a configuration class/struct.
+  ```csharp
+  // Bad
+  DecimalNumber product = CalculateProduct(values, 7, false, null);
+  
+  // Good
+  var options = new ProductOptions { PrecisionDecimals = 7, UseCache = CacheUsage.DontUseCache };
+  DecimalNumber product = CalculateProduct(values, options, completionDelegate: null);
+  ```
+
+**BE CONSISTENT.** When editing code, follow the existing style in the codebase.
+
+*Source: [Google C# Style Guide](https://google.github.io/styleguide/csharp-style.html)*

package/dist/templates/code_styleguides/dart.md

@@ -0,0 +1,238 @@
+# Dart Code Style Guide
+
+This guide summarizes key recommendations from the official Effective Dart documentation, covering style, documentation, language usage, and API design principles. Adhering to these guidelines promotes consistent, readable, and maintainable Dart code.
+
+## 1. Style
+
+### 1.1. Identifiers
+
+- **DO** name types, extensions, and enum types using `UpperCamelCase`.
+- **DO** name packages, directories, and source files using `lowercase_with_underscores`.
+- **DO** name import prefixes using `lowercase_with_underscores`.
+- **DO** name other identifiers (class members, top-level definitions, variables, parameters) using `lowerCamelCase`.
+- **PREFER** using `lowerCamelCase` for constant names.
+- **DO** capitalize acronyms and abbreviations longer than two letters like words (e.g., `Http`, `Nasa`, `Uri`). Two-letter acronyms (e.g., `ID`, `TV`, `UI`) should remain capitalized.
+- **PREFER** using wildcards (`_`) for unused callback parameters in anonymous and local functions.
+- **DON'T** use a leading underscore for identifiers that aren't private.
+- **DON'T** use prefix letters (e.g., `kDefaultTimeout`).
+- **DON'T** explicitly name libraries using the `library` directive.
+
+### 1.2. Ordering
+
+- **DO** place `dart:` imports before other imports.
+- **DO** place `package:` imports before relative imports.
+- **DO** specify exports in a separate section after all imports.
+- **DO** sort sections alphabetically.
+
+### 1.3. Formatting
+
+- **DO** format your code using `dart format`.
+- **CONSIDER** changing your code to make it more formatter-friendly (e.g., shortening long identifiers, simplifying nested expressions).
+- **PREFER** lines 80 characters or fewer.
+- **DO** use curly braces for all flow control statements (`if`, `for`, `while`, `do`, `try`, `catch`, `finally`).
+
+## 2. Documentation
+
+### 2.1. Comments
+
+- **DO** format comments like sentences (capitalize the first word, end with a period).
+- **DON'T** use block comments (`/* ... */`) for documentation; use `//` for regular comments.
+
+### 2.2. Doc Comments
+
+- **DO** use `///` doc comments to document members and types.
+- **PREFER** writing doc comments for public APIs.
+- **CONSIDER** writing a library-level doc comment.
+- **CONSIDER** writing doc comments for private APIs.
+- **DO** start doc comments with a single-sentence summary.
+- **DO** separate the first sentence of a doc comment into its own paragraph.
+- **AVOID** redundancy with the surrounding context (e.g., don't repeat the class name in its doc comment).
+- **PREFER** starting comments of a function or method with third-person verbs if its main purpose is a side effect (e.g., "Connects to...").
+- **PREFER** starting a non-boolean variable or property comment with a noun phrase (e.g., "The current day...").
+- **PREFER** starting a boolean variable or property comment with "Whether" followed by a noun or gerund phrase (e.g., "Whether the modal is...").
+- **PREFER** a noun phrase or non-imperative verb phrase for a function or method if returning a value is its primary purpose.
+- **DON'T** write documentation for both the getter and setter of a property.
+- **PREFER** starting library or type comments with noun phrases.
+- **CONSIDER** including code samples in doc comments using triple backticks.
+- **DO** use square brackets (`[]`) in doc comments to refer to in-scope identifiers (e.g., `[StateError]`, `[anotherMethod()]`, `[Duration.inDays]`, `[Point.new]`).
+- **DO** use prose to explain parameters, return values, and exceptions.
+- **DO** put doc comments before metadata annotations.
+
+### 2.3. Markdown
+
+- **AVOID** using markdown excessively.
+- **AVOID** using HTML for formatting.
+- **PREFER** backtick fences (```) for code blocks.
+
+### 2.4. Writing
+
+- **PREFER** brevity.
+- **AVOID** abbreviations and acronyms unless they are obvious.
+- **PREFER** using "this" instead of "the" to refer to a member's instance.
+
+## 3. Usage
+
+### 3.1. Libraries
+
+- **DO** use strings in `part of` directives.
+- **DON'T** import libraries that are inside the `src` directory of another package.
+- **DON'T** allow an import path to reach into or out of `lib`.
+- **PREFER** relative import paths when not crossing the `lib` boundary.
+
+### 3.2. Null Safety
+
+- **DON'T** explicitly initialize variables to `null`.
+- **DON'T** use an explicit default value of `null`.
+- **DON'T** use `true` or `false` in equality operations (e.g., `if (nonNullableBool == true)`).
+- **AVOID** `late` variables if you need to check whether they are initialized; prefer nullable types.
+- **CONSIDER** type promotion or null-check patterns for using nullable types.
+
+### 3.3. Strings
+
+- **DO** use adjacent strings to concatenate string literals.
+- **PREFER** using interpolation (`$variable`, `${expression}`) to compose strings and values.
+- **AVOID** using curly braces in interpolation when not needed (e.g., `'$name'` instead of `'${name}'`).
+
+### 3.4. Collections
+
+- **DO** use collection literals (`[]`, `{}`, `<type>{}`) when possible.
+- **DON'T** use `.length` to check if a collection is empty; use `.isEmpty` or `.isNotEmpty`.
+- **AVOID** using `Iterable.forEach()` with a function literal; prefer `for-in` loops.
+- **DON'T** use `List.from()` unless you intend to change the type of the result; prefer `.toList()`.
+- **DO** use `whereType()` to filter a collection by type.
+- **AVOID** using `cast()` when a nearby operation (like `List<T>.from()` or `map<T>()`) will do.
+
+### 3.5. Functions
+
+- **DO** use a function declaration to bind a function to a name.
+- **DON'T** create a lambda when a tear-off will do (e.g., `list.forEach(print)` instead of `list.forEach((e) => print(e))`).
+
+### 3.6. Variables
+
+- **DO** follow a consistent rule for `var` and `final` on local variables (either `final` for non-reassigned and `var` for reassigned, or `var` for all locals).
+- **AVOID** storing what you can calculate (e.g., don't store `area` if you have `radius`).
+
+### 3.7. Members
+
+- **DON'T** wrap a field in a getter and setter unnecessarily.
+- **PREFER** using a `final` field to make a read-only property.
+- **CONSIDER** using `=>` for simple members (getters, setters, single-expression methods).
+- **DON'T** use `this.` except to redirect to a named constructor or to avoid shadowing.
+- **DO** initialize fields at their declaration when possible.
+
+### 3.8. Constructors
+
+- **DO** use initializing formals (`this.field`) when possible.
+- **DON'T** use `late` when a constructor initializer list will do.
+- **DO** use `;` instead of `{}` for empty constructor bodies.
+- **DON'T** use `new`.
+- **DON'T** use `const` redundantly in constant contexts.
+
+### 3.9. Error Handling
+
+- **AVOID** `catch` clauses without `on` clauses.
+- **DON'T** discard errors from `catch` clauses without `on` clauses.
+- **DO** throw objects that implement `Error` only for programmatic errors.
+- **DON'T** explicitly catch `Error` or types that implement it.
+- **DO** use `rethrow` to rethrow a caught exception to preserve the original stack trace.
+
+### 3.10. Asynchrony
+
+- **PREFER** `async`/`await` over using raw `Future`s.
+- **DON'T** use `async` when it has no useful effect.
+- **CONSIDER** using higher-order methods to transform a stream.
+- **AVOID** using `Completer` directly.
+
+## 4. API Design
+
+### 4.1. Names
+
+- **DO** use terms consistently.
+- **AVOID** abbreviations unless more common than the unabbreviated term.
+- **PREFER** putting the most descriptive noun last (e.g., `pageCount`).
+- **CONSIDER** making the code read like a sentence when using the API.
+- **PREFER** a noun phrase for a non-boolean property or variable.
+- **PREFER** a non-imperative verb phrase for a boolean property or variable (e.g., `isEnabled`, `canClose`).
+- **CONSIDER** omitting the verb for a named boolean parameter (e.g., `growable: true`).
+- **PREFER** the "positive" name for a boolean property or variable (e.g., `isConnected` over `isDisconnected`).
+- **PREFER** an imperative verb phrase for a function or method whose main purpose is a side effect (e.g., `list.add()`, `window.refresh()`).
+- **PREFER** a noun phrase or non-imperative verb phrase for a function or method if returning a value is its primary purpose (e.g., `list.elementAt(3)`).
+- **CONSIDER** an imperative verb phrase for a function or method if you want to draw attention to the work it performs (e.g., `database.downloadData()`).
+- **AVOID** starting a method name with `get`.
+- **PREFER** naming a method `to___()` if it copies the object's state to a new object (e.g., `toList()`).
+- **PREFER** naming a method `as___()` if it returns a different representation backed by the original object (e.g., `asMap()`).
+- **AVOID** describing the parameters in the function's or method's name.
+- **DO** follow existing mnemonic conventions when naming type parameters (e.g., `E` for elements, `K`, `V` for map keys/values, `T`, `S`, `U` for general types).
+
+### 4.2. Libraries
+
+- **PREFER** making declarations private (`_`).
+- **CONSIDER** declaring multiple classes in the same library if they logically belong together.
+
+### 4.3. Classes and Mixins
+
+- **AVOID** defining a one-member abstract class when a simple function (`typedef`) will do.
+- **AVOID** defining a class that contains only static members; prefer top-level functions/variables or a library.
+- **AVOID** extending a class that isn't intended to be subclassed.
+- **DO** use class modifiers (e.g., `final`, `interface`, `sealed`) to control if your class can be extended.
+- **AVOID** implementing a class that isn't intended to be an interface.
+- **DO** use class modifiers to control if your class can be an interface.
+- **PREFER** defining a pure mixin or pure class to a `mixin class`.
+
+### 4.4. Constructors
+
+- **CONSIDER** making your constructor `const` if the class supports it (all fields are `final` and initialized in the constructor).
+
+### 4.5. Members
+
+- **PREFER** making fields and top-level variables `final`.
+- **DO** use getters for operations that conceptually access properties (no arguments, returns a result, no user-visible side effects, idempotent).
+- **DO** use setters for operations that conceptually change properties (single argument, no result, changes state, idempotent).
+- **DON'T** define a setter without a corresponding getter.
+- **AVOID** using runtime type tests to fake overloading.
+- **AVOID** public `late final` fields without initializers.
+- **AVOID** returning nullable `Future`, `Stream`, and collection types; prefer empty containers or non-nullable futures of nullable types.
+- **AVOID** returning `this` from methods just to enable a fluent interface; prefer method cascades.
+
+### 4.6. Types
+
+- **DO** type annotate variables without initializers.
+- **DO** type annotate fields and top-level variables if the type isn't obvious.
+- **DON'T** redundantly type annotate initialized local variables.
+- **DO** annotate return types on function declarations.
+- **DO** annotate parameter types on function declarations.
+- **DON'T** annotate inferred parameter types on function expressions.
+- **DON'T** type annotate initializing formals.
+- **DO** write type arguments on generic invocations that aren't inferred.
+- **DON'T** write type arguments on generic invocations that are inferred.
+- **AVOID** writing incomplete generic types.
+- **DO** annotate with `dynamic` instead of letting inference fail silently.
+- **PREFER** signatures in function type annotations.
+- **DON'T** specify a return type for a setter.
+- **DON'T** use the legacy `typedef` syntax.
+- **PREFER** inline function types over `typedef`s.
+- **PREFER** using function type syntax for parameters.
+- **AVOID** using `dynamic` unless you want to disable static checking.
+- **DO** use `Future<void>` as the return type of asynchronous members that do not produce values.
+- **AVOID** using `FutureOr<T>` as a return type.
+
+### 4.7. Parameters
+
+- **AVOID** positional boolean parameters.
+- **AVOID** optional positional parameters if the user may want to omit earlier parameters.
+- **AVOID** mandatory parameters that accept a special "no argument" value.
+- **DO** use inclusive start and exclusive end parameters to accept a range.
+
+### 4.8. Equality
+
+- **DO** override `hashCode` if you override `==`.
+- **DO** make your `==` operator obey the mathematical rules of equality (reflexive, symmetric, transitive, consistent).
+- **AVOID** defining custom equality for mutable classes.
+- **DON'T** make the parameter to `==` nullable.
+
+_Sources:_
+
+- [Effective Dart: Style](https://dart.dev/effective-dart/style)
+- [Effective Dart: Documentation](https://dart.dev/effective-dart/documentation)
+- [Effective Dart: Usage](https://dart.dev/effective-dart/usage)
+- [Effective Dart: Design](https://dart.dev/effective-dart/design)

package/dist/templates/code_styleguides/general.md

@@ -0,0 +1,23 @@
+# General Code Style Principles
+
+This document outlines general coding principles that apply across all languages and frameworks used in this project.
+
+## Readability
+- Code should be easy to read and understand by humans.
+- Avoid overly clever or obscure constructs.
+
+## Consistency
+- Follow existing patterns in the codebase.
+- Maintain consistent formatting, naming, and structure.
+
+## Simplicity
+- Prefer simple solutions over complex ones.
+- Break down complex problems into smaller, manageable parts.
+
+## Maintainability
+- Write code that is easy to modify and extend.
+- Minimize dependencies and coupling.
+
+## Documentation
+- Document *why* something is done, not just *what*.
+- Keep documentation up-to-date with code changes.