Initial commit

commands/commit.md

@@ -0,0 +1,39 @@
+---
+description: "Analyzes code changes and generates a conventional commit message."
+argument-hint: ""
+---
+
+# /commit
+
+This command analyzes staged and unstaged changes to generate a high-quality commit message that follows the project's existing style.
+
+## When to use
+
+- **Use when:** The user wants to commit their changes, e.g., "commit my work", "create a commit".
+- **Suggest when:** The user indicates they have finished a task or a set of changes.
+- **Example:** "User: I'm done with the changes for the login page." -> Assistant suggests `/commit`.
+- **Example:** "User: wrap this up" -> Assistant suggests `/commit`.
+
+## Actions
+
+1.  **Step 1: Gather Git Information**
+
+    - Use a `worker` agent to run the following commands in parallel:
+      - `git diff --staged` (to see staged changes)
+      - `git diff` (to see unstaged changes)
+      - `git status` (to see current branch and file status)
+      - `git log --oneline -10` (to understand the project's commit message style)
+
+2.  **Step 2: Analyze Changes and Generate Message**
+
+    - If there are no changes, inform the user and stop.
+    - If there are only unstaged changes, ask the user if they want to stage files first.
+    - Based on the git information, generate a commit message that:
+      - Follows the project's historical style (e.g., conventional commits, emoji usage).
+      - Accurately and concisely describes the changes.
+      - Explains the "why" behind the change, not just the "what".
+
+3.  **Step 3: Propose and Commit**
+    - Use the `AskUserQuestion` tool to present the generated message to the user.
+    - Ask if they want to use the message to commit, edit it, or cancel.
+    - If the user agrees to commit, run the `git commit -m "<message>"` command.

commands/initDoc.md

@@ -0,0 +1,46 @@
+---
+description: Generate great doc system for this project
+---
+
+## Actions
+
+0. STEP 0:
+
+   - Obtain the current project structure.
+   - Read key files, such as various README.md / package.json / go.mod / pyproject.toml ...
+
+1. **Step 1: Global Investigation (using `scout`)**
+
+   - Launch concurrent `scout` agents to explore the codebase and produce reports.
+
+2. **Step 2: Propose Core Concepts & Get User Selection**
+
+   - After scouting is complete, perform a synthesis step: Read all scout reports and generate a list of _candidate_ core concepts (e.g., "Authentication", "Billing Engine", "API Gateway").
+   - Use the `AskUserQuestion` tool to present this list to the user as a multiple-choice question: "I've analyzed the project and found these potential core concepts. Please select the ones you want to document now:".
+
+3.  **Step 3: Generate Concise Foundational Documents**
+    - In parallel, launch dedicated `recorder` agents to create essential, project-wide documents.
+    - **Task for Recorder A (Project Overview):** "Create `overview/project-overview.md`. Analyze all scout reports to define the project's purpose, primary function, and tech stack."
+    - **Task for Recorder B (Coding Conventions):** "Create a *concise* `reference/coding-conventions.md`. Analyze project config files (`.eslintrc`, `.prettierrc`) and extract only the most important, high-level rules."
+    - **Task for Recorder C (Git Conventions):** "Create a *concise* `reference/git-conventions.md`. Analyze `git log` to infer and document the primary branch strategy and commit message format."
+    - **Mode:** These recorders MUST operate in `content-only` mode.
+
+4. **Step 4: Document User-Selected Concepts**
+
+   - Based on the user's selection from Step 2, for each _selected_ concept, concurrently invoke a `recorder` agent.
+   - The prompt for this `recorder` will be highly specific to control scope and detail:
+     "**Task:** Holistically document the **`<selected_concept_name>`**.
+     **1. Read all relevant scout reports and source code...**
+     **2. Generate a small, hierarchical set of documents:**
+     - **Optionally, create ONE `overview` document** if the concept is large enough to require its own high-level summary (e.g., `overview/authentication-overview.md`).
+     - **Create 1-2 primary `architecture` documents.** This is mandatory and should be the core 'LLM Retrieval Map'.
+     - **Create 1-2 primary `guide` documents** that explain the most common workflow for this concept (e.g., `how-to-authenticate-a-user.md`).
+     - **Optionally, create 1-2 concise `reference` documents** ONLY if there are critical, well-defined data structures or API specs. Do not create reference docs for minor details.
+       **3. Operate in `content-only` mode.**"
+
+5. **Step 5: Final Indexing**
+
+   - After all `recorder` agents from both Step 3 and Step 4 have completed, invoke a single `recorder` in `full` mode to build the final `index.md` from scratch.
+
+6. **Step 6: Cleanup**
+   - Delete the temporary scout reports in `/llmdoc/agent/`.

commands/reviewPR.md

@@ -0,0 +1,41 @@
+---
+description: "Conducts an automated review of a GitHub Pull Request."
+argument-hint: "[PR number or URL]"
+---
+
+# /reviewPR
+
+This command conducts a comprehensive review of a GitHub Pull Request. If no PR number or URL is provided as an argument (`$1`), it attempts to find the PR associated with the current git branch.
+
+## When to use
+
+- **Use when:** The user explicitly asks to review a pull request, e.g., "review this PR", "can you check PR #123?".
+- **Suggest when:** The user mentions merging code, a pull request, or asks for a code quality check on a branch that has an open PR.
+- **Example:** "User: My feature is ready for review." -> Assistant checks for a PR and suggests `/reviewPR`.
+- **Example:** "User: /reviewPR 123"
+
+## Actions
+
+1.  **Step 1: Obtain PR Information**
+
+    - If an argument (`$1`) is provided, use it as the PR identifier.
+    - If no argument is provided, use a `worker` agent to run `gh pr status` to find the current branch's PR number.
+    - If no PR is found, inform the user and stop.
+    - Use a `worker` agent to run `gh pr view <PR_NUMBER> --json ...` and `gh pr diff <PR_NUMBER>` in parallel to fetch PR details.
+
+2.  **Step 2: Parallel Analysis Phase**
+
+    - Deploy `investigator` agents concurrently to analyze different aspects of the PR:
+    - **Investigator A (Code Quality):** Analyze style inconsistencies, complexity, duplication, naming, and error handling.
+    - **Investigator B (Architecture):** Verify alignment with project structure, new dependencies, design patterns, and separation of concerns.
+    - **Investigator C (Tests & Docs):** Check for appropriate test coverage and documentation updates.
+
+3.  **Step 3: Synthesize and Generate Report**
+
+    - Integrate the findings from all investigators.
+    - Categorize issues by severity (Critical, Important, Suggestion).
+    - Generate a structured review comment in Markdown format, including a summary, detailed recommendations, and an overall assessment.
+
+4.  **Step 4: Submit Review**
+    - Use the `AskUserQuestion` tool to show the generated review to the user and ask for confirmation before submitting.
+    - If confirmed, use a `worker` agent to run `gh pr review <PR_NUMBER> --<state> --body "<comment>"` to post the review to GitHub.

commands/updateDoc.md

@@ -0,0 +1,39 @@
+---
+description: "Updates the documentation based on recent code changes."
+argument-hint: "[Optional: specific update instructions]"
+---
+
+# /updateDoc
+
+This command updates the project's documentation to reflect recent code changes. If specific instructions are provided, it follows them. Otherwise, it analyzes the latest `git diff` to determine what needs updating.
+
+## When to use
+
+- **Use when:** The user wants to update the documentation after making code changes.
+- **Suggest when:** A feature has been implemented or a bug has been fixed, and the user indicates the task is complete.
+- **Example:** "User: I've just pushed the changes, please update the docs."
+- **Example:** "User: The refactor is done." -> Assistant suggests `/updateDoc`.
+
+## Actions
+
+1.  **Step 1: Analyze Changes**
+    - If arguments (`$ARGUMENTS`) are provided, use them as the high-level description of what changed.
+    - If no arguments are provided, run `git diff HEAD` to get recent code changes.
+
+2.  **Step 2: Synthesize Impacted Concepts**
+    - Perform a synthesis step: Analyze the `git diff` or user's description to identify which core concepts, features, or foundational conventions have been affected.
+    - For example, a change to `.eslintrc` impacts "Coding Conventions". A change to `src/services/authService.js` impacts the "Authentication System" concept.
+    - Create a list of all impacted concepts/conventions.
+
+3.  **Step 3: Concurrent Document Updates (using `recorder` in `content-only` mode)**
+    - For each impacted concept identified in Step 2, concurrently invoke a `recorder` agent.
+    - The prompt for each will be:
+      "**Task:** The **`<concept_name>`** has been updated.
+      **1. Analyze these changes:** `<relevant part of git diff or user description>`.
+      **2. Read the existing `llmdoc` documentation thoroughly** to understand what documents are impacted by the changes.
+      **3. Holistically update all relevant documents** to reflect the changes, ensuring they remain accurate and consistent. You may need to create, modify, or even delete documents.
+      **4. Apply the 'Principle of Minimality':** Your updates must be as concise as possible. Use the fewest words necessary to describe the change. Do not write long-winded explanations.
+      **5. You MUST operate in `content-only` mode.**"
+
+4.  **Step 4: Final Indexing (using a single `recorder`)**
+    - After all `recorder` agents from Step 3 have completed, invoke a **single** `recorder` agent with the task: "The documentation has been updated. Please re-scan the `/llmdoc` directory and ensure the `index.md` is fully consistent and up-to-date. Operate in `full` mode."

commands/what.md

@@ -0,0 +1,33 @@
+---
+description: "Clarifies a vague user request by asking clarifying questions."
+argument-hint: ""
+---
+
+# /what
+
+This command is used internally when a user's request is too vague to be acted upon. It reads the project documentation to understand the context and then asks the user targeted, option-based questions to clarify their intent.
+
+## When to use
+
+- **Use when:** This command is typically used by the main assistant AI, not directly by the user. It's triggered when the user's prompt is ambiguous (e.g., "fix it", "add a thing").
+- **Goal:** To turn a vague request into a concrete, actionable plan.
+
+## Actions
+
+1.  **Step 1: Gather Context**
+
+    - Read the documentation index at `<projectRootPath>/llmdoc/index.md` and other high-level documents to understand the project's purpose, architecture, and features.
+
+2.  **Step 2: Formulate Clarifying Questions**
+
+    - Based on the documentation and the user's vague request, formulate a set of clarifying questions.
+    - The questions should be option-based whenever possible to guide the user toward a specific outcome. For example, instead of "What do you want to do?", ask "Are you trying to: (a) Add a new API endpoint, (b) Modify an existing feature, or (c) Fix a bug?".
+
+3.  **Step 3: Ask the User**
+
+    - Use the `AskUserQuestion` tool to present the questions to the user.
+
+4.  **Step 4: Formulate Investigation Task**
+    - Based on the user's clarified response, your goal is to formulate a set of concrete **investigation questions**.
+    - **Do NOT jump to a solution.** The purpose of this command is to clarify "what the user wants to know", not "how to implement it".
+    - Invoke the `/withScout` command with the clear, factual questions you have formulated. For example, if the user now wants to "add a user endpoint", the next step is to ask `/withScout` to investigate "What is the current API routing structure?" and "What conventions are used for defining data models?".

commands/withScout.md

@@ -0,0 +1,46 @@
+---
+description: "Handles a complex task by first investigating the codebase, then executing a plan."
+argument-hint: "[A complex goal or task]"
+---
+
+# /withScout
+
+This command handles complex tasks by breaking them down into an investigation phase and an execution phase. It uses `investigator` agents to gather information before deciding on a plan of action.
+
+## When to use
+
+- **Use when:** The user has a complex request that requires understanding the codebase before changes can be made.
+- **Suggest when:** A user's request cannot be fulfilled without first gathering information from multiple files or parts of the codebase.
+- **Example:** "User: Add a JWT token refresh feature."
+- **Example:** "User: Figure out our project's auth logic and then add a new endpoint."
+
+## Actions
+
+This command follows an **Investigate -> Synthesize -> Iterate/Execute** workflow.
+
+1.  **Step 1: Deconstruct & Plan**
+
+    - Break down the user's primary goal into a set of clear, independently investigable questions.
+    - Assign each set of questions to a different `investigator` agent (e.g., Frontend Investigator, Backend Investigator).
+
+2.  **Step 2: Parallel Investigation**
+
+    - Use the `Task` tool to launch multiple `investigator` agents concurrently.
+    - Each investigator will research its assigned questions and return a direct markdown report.
+
+3.  **Step 3: Synthesize & Evaluate**
+
+    - Combine the reports from all investigators to form a holistic view of the system.
+    - Identify key connections, knowledge gaps, or conflicts in the information.
+
+4.  **Step 4: Iterate or Execute**
+
+    - **If information is insufficient (Iterate):** Formulate a new, more specific round of research questions and go back to Step 2.
+    - **If information is sufficient (Execute):** Proceed to the Action Phase (Step 5).
+
+5.  **Step 5: Action Phase**
+
+    - Based on the comprehensive information gathered, create a plan and use `worker` agents to execute the user's final request (e.g., implement the feature, fix the bug).
+
+6.  **Step 6: Summarize & Report**
+    - When delivering the final result, explain the investigation process, the key findings, and the actions taken to achieve the outcome.