diff --git a/README.md b/README.md index fb629739..e7e8f0d5 100644 --- a/README.md +++ b/README.md @@ -43,6 +43,7 @@ When you run `/conductor:setup`, Conductor helps you define the core components - **Workflow**: Set team preferences (e.g. TDD, commit strategy). Uses [workflow.md](templates/workflow.md) as a customizable template. **Generated Artifacts:** +- `conductor/index.md` - `conductor/product.md` - `conductor/product-guidelines.md` - `conductor/tech-stack.md` diff --git a/commands/conductor/implement.toml b/commands/conductor/implement.toml index acf789b5..0a494c2b 100644 --- a/commands/conductor/implement.toml +++ b/commands/conductor/implement.toml @@ -27,7 +27,11 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai 2. **Locate and Parse Tracks Registry:** - Resolve the **Tracks Registry**. - - 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. + - 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:** + - **Status:** Identify the status (`[ ]`, `[~]`, `[x]`) from the track entry. + - **Track Description:** Identify the description. Look for lines matching either the standard format `- [ ] **Track: **` OR the heading format `## [ ] Track: `. + - **Link:** Extract the link to the track folder (e.g., `[./path/](./path/)` or similar). - **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. @@ -73,7 +77,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai 2. **Update Status to 'In Progress':** - Before beginning any work, you MUST update the status of the selected track in the **Tracks Registry** file. - - This requires finding the specific heading for the track (e.g., `## [ ] Track: `) and replacing it with the updated status (e.g., `## [~] Track: `) in the **Tracks Registry** file you identified earlier. + - This requires finding the specific entry for the track (e.g., `## [ ] Track: ` or `- [ ] **Track: **`) and replacing it with the updated status (e.g., `## [~] Track: ` or `- [~] **Track: **`) in the **Tracks Registry** file you identified earlier. 3. **Load Track Context:** a. **Identify Track Folder:** From the tracks file, identify the track's folder link to get the ``. @@ -91,7 +95,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai 5. **Finalize Track:** - After all tasks in the track's local **Implementation Plan** are completed, you MUST update the track's status in the **Tracks Registry**. - - This requires finding the specific heading for the track (e.g., `## [~] Track: `) and replacing it with the completed status (e.g., `## [x] Track: `). + - This requires finding the specific entry for the track (e.g., `## [~] Track: ` or `- [~] **Track: **`) and replacing it with the completed status (e.g., `## [x] Track: ` or `- [x] **Track: **`). - **Commit Changes:** Stage the **Tracks Registry** file and commit with the message `chore(conductor): Mark track '' as complete`. - Announce that the track is fully complete and the tracks file has been updated. diff --git a/commands/conductor/setup.toml b/commands/conductor/setup.toml index 5d6fed89..b52f568e 100644 --- a/commands/conductor/setup.toml +++ b/commands/conductor/setup.toml @@ -60,10 +60,10 @@ PLAN MODE PROTOCOL: This setup process runs entirely within Plan Mode. While in ### 2.0 Project Inception 1. **Detect Project Maturity:** - - **Classify Project:** Determine if the project is "Brownfield" (Existing) or "Greenfield" (New) based on the following indicators: + - **Classify Project:** Determine if the project is "Brownfield" (Existing) or "Greenfield" (New) based on the following indicators. **CRITICAL: Limit your search to the root and one level deep (maxdepth 2) to avoid performance issues in large repositories.** - **Brownfield Indicators:** - - Check for dependency manifests: `package.json`, `pom.xml`, `requirements.txt`, `go.mod`, `Cargo.toml`. - - Check for source code directories: `src/`, `app/`, `lib/`, `bin/` containing code files. + - Check for dependency manifests at the root or one level deep: `package.json`, `pom.xml`, `requirements.txt`, `go.mod`, `Cargo.toml`. + - Check for common source code directories at the root: `src/`, `app/`, `lib/`, `bin/`. - If a `.git` directory exists, execute `git status --porcelain`. Ignore changes within the `conductor/` directory. If there are *other* uncommitted changes, it may be Brownfield. - If ANY of the primary indicators (manifests or source code directories) are found, classify as **Brownfield**. - **Greenfield Condition:** @@ -99,10 +99,10 @@ PLAN MODE PROTOCOL: This setup process runs entirely within Plan Mode. While in - **2.1 File Size and Relevance Triage:** 1. **Respect Ignore Files:** Before scanning any files, you MUST check for the existence of `.geminiignore` and `.gitignore` files. If either or both exist, you MUST use their combined patterns to exclude files and directories from your analysis. The patterns in `.geminiignore` should take precedence over `.gitignore` if there are conflicts. This is the primary mechanism for avoiding token-heavy, irrelevant files like `node_modules`. - 2. **Efficiently List Relevant Files:** To list the files for analysis, you MUST use a command that respects the ignore files. For example, you can use `git ls-files --exclude-standard -co | xargs -n 1 dirname | sort -u` which lists all relevant directories (tracked by Git, plus other non-ignored files) without listing every single file. If Git is not used, you must construct a `find` command that reads the ignore files and prunes the corresponding paths. - 3. **Fallback to Manual Ignores:** ONLY if neither `.geminiignore` nor `.gitignore` exist, you should fall back to manually ignoring common directories. Example command: `ls -lR -I 'node_modules' -I '.m2' -I 'build' -I 'dist' -I 'bin' -I 'target' -I '.git' -I '.idea' -I '.vscode'`. + 2. **Efficiently List Relevant Files:** To list the files for analysis, you MUST use a command that respects the ignore files. For example, you can use `git ls-files --exclude-standard -co | xargs -n 1 dirname | sort -u` which lists all relevant directories (tracked by Git, plus other non-ignored files) without listing every single file. If Git is not used, you must construct an efficient `find` command that reads the ignore files and prunes the corresponding paths (limit depth to 3). + 3. **Fallback to Manual Ignores:** ONLY if neither `.geminiignore` nor `.gitignore` exist, you should fall back to manually ignoring common directories using an efficient, depth-limited command. **CRITICAL: Avoid recursive listings like `ls -R` or `Get-ChildItem -Recurse` without strict depth limits or pruning in large projects.** Example (PowerShell): `Get-ChildItem -Path . -Depth 2 -Exclude "node_modules", ".git", "build", "dist", "bin", "target", ".idea", ".vscode"`. 4. **Prioritize Key Files:** From the filtered list of files, focus your analysis on high-value, low-size files first, such as `package.json`, `pom.xml`, `requirements.txt`, `go.mod`, and other configuration or manifest files. - 5. **Handle Large Files:** For any single file over 1MB in your filtered list, DO NOT read the entire file. Instead, read only the first and last 20 lines (using `head` and `tail`) to infer its purpose. + 5. **Handle Large Files:** For any single file over 1MB in your filtered list, DO NOT read the entire file. Instead, read only the first and last 20 lines (using `head` and `tail` or PowerShell equivalents) to infer its purpose. - **2.2 Extract and Infer Project Context:** 1. **Strict File Access:** DO NOT ask for more files. Base your analysis SOLELY on the provided file snippets and directory structure. diff --git a/templates/code_styleguides/cpp.md b/templates/code_styleguides/cpp.md index 37fb2100..65f01a91 100644 --- a/templates/code_styleguides/cpp.md +++ b/templates/code_styleguides/cpp.md @@ -102,9 +102,8 @@ - **Sizeof:** Prefer `sizeof(varname)` over `sizeof(type)`. - **Friends:** Allowed, usually defined in the same file. - **Boost:** Use only approved libraries (e.g., Call Traits, Compressed Pair, BGL, Property Map, Iterator, etc.). -- **Aliases:** Use `using` instead of `typedef`. Public aliases must be documented. +- **Aliases:** Use `using` instead of `typedef`. Public aliases must be documented, and intent should be clear. Do not use in public API solely for convenience. - **Ownership:** Single fixed owner. Transfer via smart pointers. -- **Aliases:** Document intent. Don't use in public API for convenience. `using` > `typedef`. - **Switch:** Always include `default`. Use `[[fallthrough]]` for explicit fallthrough. - **Comments:** Document File, Class, Function (params/return). Use `//` or `/* */`. Implementation comments for tricky code. `TODO(user):` format.