MediaMetz/gemini-cli
1
0
Fork 0
mirror of https://github.com/google-gemini/gemini-cli.git synced 2026-03-29 07:21:27 -07:00
Code Issues Packages Projects Releases Wiki Activity

feat(cli): integrate conductor as a built-in extension

Browse Source 
- Introduce support for bundled 'builtin' extensions in ExtensionManager
- Migrate conductor extension to packages/core/src/extensions/builtin/conductor
- Add automatic migration logic to cleanup manual conductor installations
- Make extension versioning optional for built-ins, defaulting to CLI version
- Update build and bundle scripts to include builtin extensions
- Enhance documentation to highlight conductor as a core feature
This commit is contained in:
Jerop Kipruto
2026-03-10 20:04:04 -04:00
parent 8615315711
commit e14c698bce
26 changed files with 3077 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

84
packages/cli/src/config/extension-manager.ts
View File

@@ -7,6 +7,7 @@
import * as fs from 'node:fs';
import * as path from 'node:path';
import { stat } from 'node:fs/promises';
import { fileURLToPath } from 'node:url';
import chalk from 'chalk';
import { ExtensionEnablementManager } from './extensions/extensionEnablement.js';
import { type MergedSettings, SettingScope } from './settings.js';
@@ -458,8 +459,8 @@ Would you like to attempt to install via "git clone" instead?`,
newExtensionConfig.name,
hashValue(newExtensionConfig.name),
getExtensionId(newExtensionConfig, installMetadata),
newExtensionConfig.version,
previousExtensionConfig.version,
newExtensionConfig.version ?? 'unknown',
previousExtensionConfig.version ?? 'unknown',
installMetadata.type,
CoreToolCallStatus.Success,
),
@@ -483,7 +484,7 @@ Would you like to attempt to install via "git clone" instead?`,
newExtensionConfig.name,
hashValue(newExtensionConfig.name),
getExtensionId(newExtensionConfig, installMetadata),
newExtensionConfig.version,
newExtensionConfig.version ?? 'unknown',
installMetadata.type,
CoreToolCallStatus.Success,
),
@@ -520,8 +521,8 @@ Would you like to attempt to install via "git clone" instead?`,
config?.name ?? '',
hashValue(config?.name ?? ''),
extensionId ?? '',
newExtensionConfig?.version ?? '',
previousExtensionConfig.version,
newExtensionConfig?.version ?? 'unknown',
previousExtensionConfig.version ?? 'unknown',
installMetadata.type,
CoreToolCallStatus.Error,
),
@@ -533,7 +534,7 @@ Would you like to attempt to install via "git clone" instead?`,
newExtensionConfig?.name ?? '',
hashValue(newExtensionConfig?.name ?? ''),
extensionId ?? '',
newExtensionConfig?.version ?? '',
newExtensionConfig?.version ?? 'unknown',
installMetadata.type,
CoreToolCallStatus.Error,
),
@@ -636,6 +637,68 @@ Would you like to attempt to install via "git clone" instead?`,
(ext): ext is GeminiCLIExtension => ext !== null,
);
let builtinExtensionsDir = path.join(
path.dirname(fileURLToPath(import.meta.url)),
'extensions',
'builtin',
);
if (!fs.existsSync(builtinExtensionsDir)) {
builtinExtensionsDir = path.join(
path.dirname(fileURLToPath(import.meta.url)),
'..',
'..',
'..',
'..',
'core',
'src',
'extensions',
'builtin',
);
}
if (!process.env['VITEST'] && fs.existsSync(builtinExtensionsDir)) {
const builtinSubdirs =
await fs.promises.readdir(builtinExtensionsDir);
const builtinPromises = builtinSubdirs.map((subdir) => {
const extensionDir = path.join(builtinExtensionsDir, subdir);
return this._buildExtension(extensionDir, true);
});
const builtinResolved = await Promise.all(builtinPromises);
for (const builtinExt of builtinResolved) {
if (builtinExt) {
const existingIdx = builtExtensions.findIndex(
(e) => e.name === builtinExt.name,
);
if (existingIdx !== -1) {
// If the user has a manually installed version of the builtin extension, we migrate them.
const manualExt = builtExtensions[existingIdx];
const storage = new ExtensionStorage(
manualExt.installMetadata?.type === 'link'
? manualExt.name
: path.basename(manualExt.path),
);
try {
await fs.promises.rm(storage.getExtensionDir(), {
recursive: true,
force: true,
});
debugLogger.debug(
`Migrated to built-in extension: ${builtinExt.name}. Removed manual installation.`,
);
} catch (e) {
debugLogger.warn(
`Failed to clean up manual installation of ${builtinExt.name}: ${getErrorMessage(e)}`,
);
}
builtExtensions[existingIdx] = builtinExt;
} else {
builtExtensions.push(builtinExt);
}
}
}
}
const seenNames = new Set<string>();
for (const ext of builtExtensions) {
if (seenNames.has(ext.name)) {
@@ -705,6 +768,7 @@ Would you like to attempt to install via "git clone" instead?`,
*/
private async _buildExtension(
extensionDir: string,
isBuiltin = false,
): Promise<GeminiCLIExtension | null> {
try {
const stats = await fs.promises.stat(extensionDir);
@@ -959,7 +1023,9 @@ Would you like to attempt to install via "git clone" instead?`,
return {
name: config.name,
version: config.version,
version:
config.version ??
(isBuiltin ? this.telemetryConfig.getClientVersion() : 'unknown'),
path: effectiveExtensionPath,
contextFiles,
installMetadata,
@@ -1028,9 +1094,9 @@ Would you like to attempt to install via "git clone" instead?`,
const configContent = await fs.promises.readFile(configFilePath, 'utf-8');
// eslint-disable-next-line @typescript-eslint/no-unsafe-type-assertion
const rawConfig = JSON.parse(configContent) as ExtensionConfig;
if (!rawConfig.name || !rawConfig.version) {
if (!rawConfig.name) {
throw new Error(
`Invalid configuration in ${configFilePath}: missing ${!rawConfig.name ? '"name"' : '"version"'}`,
`Invalid configuration in ${configFilePath}: missing "name"`,
);
}
// eslint-disable-next-line @typescript-eslint/no-unsafe-type-assertion

2
packages/cli/src/config/extension.ts
View File

@@ -23,7 +23,7 @@ import type { ExtensionSetting } from './extensions/extensionSettings.js';
*/
export interface ExtensionConfig {
name: string;
version: string;
version?: string;
mcpServers?: Record<string, MCPServerConfig>;
contextFileName?: string | string[];
excludeTools?: string[];

4
packages/core/src/config/config.ts
View File

@@ -1603,6 +1603,10 @@ export class Config implements McpContext, AgentLoopContext {
return this.discoveryMaxDirs;
}
getClientVersion(): string {
return this.clientVersion;
}
getContentGeneratorConfig(): ContentGeneratorConfig {
return this.contentGeneratorConfig;
}

218
packages/core/src/extensions/builtin/conductor/commands/conductor/implement.toml Normal file
View File

@@ -0,0 +1,218 @@
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. **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of:
- **Product Definition**
- **Tech Stack**
- **Workflow**
2. **Handle Failure:** If ANY of these are missing (or their resolved paths do not exist), Announce: "Conductor is not set up. Please run `/conductor:setup`." and HALT.
---
## 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. **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.
- **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, immediately call the `ask_user` tool to confirm the selection (do not repeat the question in the chat):
- **questions:**
- **header:** "Confirm"
- **question:** "I found track '<track_description>'. Is this correct?"
- **type:** "yesno"
3. If no match is found, or if the match is ambiguous, immediately call the `ask_user` tool to inform the user and request the correct track name (do not repeat the question in the chat):
- **questions:**
- **header:** "Clarify"
- **question:** "I couldn't find a unique track matching the name you provided. Did you mean '<next_available_track>'? Or please type the exact track name."
- **type:** "text"
- **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:**
- Immediately call the `ask_user` tool to confirm the selection (do not repeat the question in the chat):
- **questions:**
- **header:** "Next Track"
- **question:** "No track name provided. Would you like to proceed with the next incomplete track: '<track_description>'?"
- **type:** "yesno"
- If confirmed, proceed with this track. Otherwise, immediately call the `ask_user` tool to request the correct track name (do not repeat the question in the chat):
- **questions:**
- **header:** "Clarify"
- **question:** "Please type the exact name of the track you would like to implement."
- **type:** "text"
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 **Tracks Registry** 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>`) 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 `<track_id>`.
b. **Read Files:**
- **Track Context:** Using the **Universal File Resolution Protocol**, resolve and read the **Specification** and **Implementation Plan** for the selected track.
- **Workflow:** Resolve **Workflow** (via the **Universal File Resolution Protocol** using the project's index file).
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 **Implementation Plan** by following the procedures in the **Workflow**.
b. **Iterate Through Tasks:** You MUST now loop through each task in the track's **Implementation Plan** one by one.
c. **For Each Task, You MUST:**
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.
- **CRITICAL:** Every human-in-the-loop interaction, confirmation, or request for feedback mentioned in the **Workflow** (e.g., manual verification plans or guidance on persistent failures) MUST be conducted using the `ask_user` tool.
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: <Description>`) and replacing it with the completed status (e.g., `## [x] Track: <Description>`).
- **Commit Changes:** Stage the **Tracks Registry** file and commit with the message `chore(conductor): Mark track '<track_description>' as complete`.
- Announce that the track is fully complete and the tracks file has been updated.
---
## 4.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:** Read the track's **Specification**.
4. **Load Project Documents:**
- Resolve and read:
- **Product Definition**
- **Tech Stack**
- **Product Guidelines**
5. **Analyze and Update:**
a. **Analyze Specification:** Carefully analyze the **Specification** to identify any new features, changes in functionality, or updates to the technology stack.
b. **Update Product Definition:**
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:
- **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the proposed updates (in a diff format) directly into the `question` field so the user can review them in context.
- **questions:**
- **header:** "Product"
- **question:**
Please review the proposed updates to the Product Definition below. Do you approve?
---
<Insert Proposed product.md Updates/Diff Here>
- **type:** "yesno"
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.
c. **Update Tech Stack:**
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:
- **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the proposed updates (in a diff format) directly into the `question` field so the user can review them in context.
- **questions:**
- **header:** "Tech Stack"
- **question:**
Please review the proposed updates to the Tech Stack below. Do you approve?
---
<Insert Proposed tech-stack.md Updates/Diff Here>
- **type:** "yesno"
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.
d. **Update Product Guidelines (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 **Specification** 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:
- **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the proposed changes (in a diff format) directly into the `question` field, including a clear warning.
- **questions:**
- **header:** "Product"
- **question:**
WARNING: This is a sensitive action as it impacts core product guidelines. Please review the proposed changes below. Do you approve these critical changes?
---
<Insert Proposed product-guidelines.md Updates/Diff Here>
- **type:** "yesno"
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.
- **Commit Changes:**
- If any files were changed (**Product Definition**, **Tech Stack**, or **Product Guidelines**), you MUST stage them and commit them.
- **Commit Message:** `docs(conductor): Synchronize docs for track '<track_description>'`
- **Example (if Product Definition was changed, but others were not):**
> "Documentation synchronization is complete.
> - **Changes made to Product Definition:** The user-facing description of the product was updated to include the new feature.
> - **No changes needed for Tech Stack:** The technology stack was not affected.
> - **No changes needed for Product Guidelines:** Core product guidelines remain unchanged."
- **Example (if no files were changed):**
> "Documentation synchronization is complete. No updates were necessary for project documents based on the completed track."
---
## 5.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:** Immediately call the `ask_user` tool to prompt the user (do not repeat the question in the chat):
- **questions:**
- **header:** "Track Cleanup"
- **question:** "Track '<track_description>' is now complete. What would you like to do?"
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Review", Description: "Run the review command to verify changes before finalizing."
- Label: "Archive", Description: "Move the track's folder to `conductor/archive/` and remove it from the tracks file."
- Label: "Delete", Description: "Permanently delete the track's folder and remove it from the tracks file."
- Label: "Skip", Description: "Do nothing and leave it in the tracks file."
3. **Handle User Response:**
* **If user chooses "Review":**
* Announce: "Please run `/conductor:review` to verify your changes. You will be able to archive or delete the track after the review."
* **If user chooses "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 its current location (resolved via the **Tracks Directory**) to `conductor/archive/<track_id>`.
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.
iv. **Commit Changes:** Stage the **Tracks Registry** file and `conductor/archive/`. Commit with the message `chore(conductor): Archive track '<track_description>'`.
v. **Announce Success:** Announce: "Track '<track_description>' has been successfully archived."
* **If user chooses "Delete":**
i. **CRITICAL WARNING:** Before proceeding, immediately call the `ask_user` tool to ask for final confirmation (do not repeat the warning in the chat):
- **questions:**
- **header:** "Confirm"
- **question:** "WARNING: This will permanently delete the track folder and all its contents. This action cannot be undone. Are you sure?"
- **type:** "yesno"
ii. **Handle Confirmation:**
- **If 'yes'**:
a. **Delete Track Folder:** Resolve the **Tracks Directory** and permanently delete the track's folder from `<Tracks Directory>/<track_id>`.
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.
c. **Commit Changes:** Stage the **Tracks Registry** file and the deletion of the track directory. Commit with the message `chore(conductor): Delete track '<track_description>'`.
d. **Announce Success:** Announce: "Track '<track_description>' has been permanently deleted."
- **If 'no'**:
a. **Announce Cancellation:** Announce: "Deletion cancelled. The track has not been changed."
* **If user chooses "Skip":**
* Announce: "Okay, the completed track will remain in your tracks file for now."
"""

184
packages/core/src/extensions/builtin/conductor/commands/conductor/newTrack.toml Normal file
View File

@@ -0,0 +1,184 @@
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.
PLAN MODE PROTOCOL: Parts of this process run within Plan Mode. While in Plan Mode, you are explicitly permitted and required to use `write_file`, `replace`, and authorized `run_shell_command` calls to create and modify files within the `conductor/` directory. **CRITICAL: You MUST use relative paths starting with `conductor/` (e.g., `conductor/product.md`) for all file operations. Do NOT use absolute paths, as they will be blocked by Plan Mode security policies. REDIRECTION (e.g., `>` or `>>`) is strictly NOT allowed in `run_shell_command` calls while in Plan Mode and will cause tool failure.**
---
## 1.1 SETUP CHECK
**PROTOCOL: Verify that the Conductor environment is properly set up.**
1. **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of:
- **Product Definition**
- **Tech Stack**
- **Workflow**
2. **Handle Failure:**
- 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 project documents (**Product Definition**, **Tech Stack**, etc.) resolved via the **Universal File Resolution Protocol**.
2. **Get Track Description & Enter Plan Mode:**
* **If `{{args}}` is empty:**
1. Call the `enter_plan_mode` tool with the reason: "Defining new track".
2. Ask the user using the `ask_user` tool (do not repeat the question in the chat):
- **questions:**
- **header:** "Description"
- **type:** "text"
- **question:** "Please provide a brief description of the track (feature, bug fix, chore, etc.) you wish to start."
- **placeholder:** "e.g., Implement user authentication"
Await the user's response and use it as the track description.
* **If `{{args}}` contains a description:**
1. Use the content of `{{args}}` as the track description.
2. Call the `enter_plan_mode` tool with the reason: "Defining new track".
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` using the `ask_user` tool. You must batch up to 4 related questions in a single tool call to streamline the process. Tailor questions based on the track type (Feature or Other).
* **CRITICAL:** Wait for the user's response after each `ask_user` tool call.
* **General Guidelines:**
* Refer to information in **Product Definition**, **Tech Stack**, 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 for the user to choose from.
* **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:** Use the `ask_user` tool: Adhere to the following for each question in the `questions` array:
- **header:** Very short label (max 16 chars).
- **type:** "choice", "text", or "yesno".
- **multiSelect:** (Required for type: "choice") Set to `true` for multi-select (additive) or `false` for single-choice (exclusive).
- **options:** (Required for type: "choice") Provide 2-4 options, each with a `label` and `description`. Note that "Other" is automatically added.
- **placeholder:** (For type: "text") Provide a hint.
* **3. Interaction Flow:**
* Wait for the user's response after each `ask_user` tool call.
* If the user selects "Other", use a subsequent `ask_user` tool call with `type: "text"` to get their input if necessary.
* Confirm your understanding by summarizing before moving on to drafting.
* **If FEATURE:**
* **Ask 3-4 relevant questions** to clarify the feature request using the `ask_user` tool.
* 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 using the `ask_user` tool.
* 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:**
- **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
- **questions:**
- **header:** "Confirm Spec"
- **question:**
Please review the drafted Specification below. Does this accurately capture the requirements?
---
<Insert Drafted spec.md Content Here>
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Approve", Description: "The specification looks correct, proceed to planning."
- Label: "Revise", Description: "I want to make changes to the requirements."
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.
* Resolve and read the **Workflow** file (via the **Universal File Resolution Protocol** using the project's index file).
* 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 **EVERY** task and sub-task. The format must be:
- Parent Task: `- [ ] Task: ...`
- Sub-task: ` - [ ] ...`
* **CRITICAL: Inject Phase Completion Tasks.** Determine if a "Phase Completion Verification and Checkpointing Protocol" is defined in 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: Conductor - User Manual Verification '<Phase Name>' (Protocol in workflow.md)`.
3. **User Confirmation:**
- **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
- **questions:**
- **header:** "Confirm Plan"
- **question:**
Please review the drafted Implementation Plan below. Does this look correct and cover all the necessary steps?
---
<Insert Drafted plan.md Content Here>
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Approve", Description: "The plan looks solid, proceed to implementation."
- Label: "Revise", Description: "I want to modify the implementation steps."
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, 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.
2. **Generate Track ID:** Create a unique Track ID (e.g., ``shortname_YYYYMMDD``).
3. **Create Directory:** Create a new directory for the tracks: `<Tracks Directory>/<track_id>/`.
4. **Create `metadata.json`:** Create a metadata file at `<Tracks Directory>/<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 `<Tracks Directory>/<track_id>/spec.md`.
* Write the confirmed plan content to `<Tracks Directory>/<track_id>/plan.md`.
* Write the index file to `<Tracks Directory>/<track_id>/index.md` with content:
```markdown
# Track <track_id> Context
- [Specification](./spec.md)
- [Implementation Plan](./plan.md)
- [Metadata](./metadata.json)
```
6. **Exit Plan Mode:** Call the `exit_plan_mode` tool with the path: `<Tracks Directory>/<track_id>/index.md`.
7. **Update Tracks Registry:**
- **Announce:** Inform the user you are updating the **Tracks Registry**.
- **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:
```markdown
---
- [ ] **Track: <Track Description>**
*Link: [./<Relative Track Path>/](./<Relative Track Path>/)*
```
(Replace `<Relative Track Path>` with the path to the track directory relative to the **Tracks Registry** file location.)
8. **Commit Code Changes:**
- **Announce:** Inform the user you are committing the **Tracks Registry** changes.
- **Commit Changes:** Stage the **Tracks Registry** files and commit with the message `chore(conductor): Add new track '<track_description>'`.
9. **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`."
"""

135
packages/core/src/extensions/builtin/conductor/commands/conductor/revert.toml Normal file
View File

@@ -0,0 +1,135 @@
description = "Reverts previous work"
prompt = """
## 1.0 SYSTEM DIRECTIVE
You are an AI agent for the Conductor framework. Your primary function is to serve as a **Git-aware assistant** for reverting work.
**Your defined scope is to revert the logical units of work tracked by Conductor (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.
Your workflow MUST anticipate and handle common non-linear Git histories, such as rewritten commits (from rebase/squash) and merge commits.
**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.
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. **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of the **Tracks Registry**.
2. **Verify Track Exists:** Check if the **Tracks Registry** is not empty.
3. **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 `/conductor:setup` to set up the plan, or restore the tracks file."
---
## 2.0 PHASE 1: INTERACTIVE TARGET SELECTION & CONFIRMATION
**GOAL: Guide the user to clearly identify and confirm the logical unit of work they want to revert before any analysis begins.**
1. **Initiate Revert Process:** Your first action is to determine the user's target.
2. **Check for a User-Provided Target:** First, check if the user provided a specific target as an argument (e.g., `/conductor:revert track <track_id>`).
* **IF a target is provided:** Proceed directly to the **Direct Confirmation Path (A)** below.
* **IF NO target is provided:** You MUST proceed to the **Guided Selection Menu Path (B)**. This is the default behavior.
3. **Interaction Paths:**
* **PATH A: Direct Confirmation**
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**).
2. Immediately call the `ask_user` tool to confirm the selection (do not repeat the question in the chat):
- **questions:**
- **header:** "Confirm"
- **question:** "You asked to revert the [Track/Phase/Task]: '[Description]'. Is this correct?"
- **type:** "yesno"
3. If "yes", establish this as the `target_intent` and proceed to Phase 2. If "no", immediately call the `ask_user` tool to ask clarifying questions (do not repeat the question in the chat):
- **questions:**
- **header:** "Clarify"
- **question:** "I'm sorry, I misunderstood. Please describe the Track, Phase, or Task you would like to revert."
- **type:** "text"
* **PATH B: Guided Selection Menu**
1. **Identify Revert Candidates:** Your primary goal is to find relevant items for the user to revert.
* **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).
* **Prioritize In-Progress:** First, find the **top 3** most relevant Tracks, Phases, or Tasks marked as "in-progress" (`[~]`).
* **Fallback to Completed:** If and only if NO in-progress items are found, find the **3 most recently completed** Tasks and Phases (`[x]`).
2. **Present a Unified Hierarchical Menu:** Immediately call the `ask_user` tool to present the results (do not list them in the chat first):
- **questions:**
- **header:** "Select Item"
- **question:** "I found multiple in-progress items (or recently completed items). Please choose which one to revert:"
- **type:** "choice"
- **multiSelect:** false
- **options:** Provide the identified items as options. Group them by Track in the description if possible. **CRITICAL:** You MUST limit this array to a maximum of 4 items.
- **Example Option Label:** "[Task] Update user model", **Description:** "Track: track_20251208_user_profile"
- **Example Option Label:** "[Phase] Implement Backend", **Description:** "Track: track_20251208_user_profile"
- **Note:** The "Other" option is automatically added by the tool.
3. **Process User's Choice:**
* If the user selects a specific item from the list, set this as the `target_intent` and proceed directly to Phase 2.
* If the user selects "Other" (automatically added for "choice") or the explicit "Other" option provided, you must engage in a dialogue to find the correct target using `ask_user` tool with a single question of `type: "text"` in the `questions` array.
* Once a target is identified, loop back to Path A for final confirmation.
4. **Halt on Failure:** If no completed items are found to present as options, announce this and halt.
---
## 3.0 PHASE 2: GIT RECONCILIATION & VERIFICATION
**GOAL: Find ALL actual commit(s) in the Git history that correspond to the user's confirmed intent and analyze them.**
1. **Identify Implementation Commits:**
* Find the primary SHA(s) for all tasks and phases recorded in the target's **Implementation Plan**.
* **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.
2. **Identify Associated Plan-Update Commits:**
* 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.
3. **Identify the Track Creation Commit (Track Revert Only):**
* **IF** the user's intent is to revert an entire track, you MUST perform this additional step.
* **Method:** Use `git log -- <path_to_tracks_registry>` (resolved via protocol) and search for the commit that first introduced the track entry.
* Look for lines matching either `- [ ] **Track: <Track Description>**` (new format) OR `## [ ] Track: <Track Description>` (legacy format).
* Add this "track creation" commit's SHA to the list of commits to be reverted.
4. **Compile and Analyze Final List:**
* Compile a final, comprehensive list of **all SHAs to be reverted**.
* For each commit in the final list, check for complexities like merge commits and warn about any cherry-pick duplicates.
---
## 4.0 PHASE 3: FINAL EXECUTION PLAN CONFIRMATION
**GOAL: Present a clear, final plan of action to the user before modifying anything.**
1. **Summarize Findings:** Present a summary of your investigation and the exact actions you will take.
> "I have analyzed your request. Here is the plan:"
> * **Target:** Revert Task '[Task Description]'.
> * **Commits to Revert:** 2
> ` - <sha_code_commit> ('feat: Add user profile')`
> ` - <sha_plan_commit> ('conductor(plan): Mark task complete')`
> * **Action:** I will run `git revert` on these commits in reverse order.
2. **Final Go/No-Go:** Immediately call the `ask_user` tool to ask for final confirmation (do not repeat the question in the chat):
- **questions:**
- **header:** "Confirm Plan"
- **question:** "Do you want to proceed with the drafted plan?"
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Approve", Description: "Proceed with the revert actions."
- Label: "Revise", Description: "I want to change the revert plan."
3. **Process User Choice:**
- If "Approve", proceed to Phase 4.
- If "Revise", immediately call the `ask_user` tool to get the correct plan (do not repeat the question in the chat):
- **questions:**
- **header:** "Revise"
- **question:** "Please describe the changes needed for the revert plan."
- **type:** "text"
---
## 5.0 PHASE 4: EXECUTION & VERIFICATION
**GOAL: Execute the revert, verify the plan's state, and handle any runtime errors gracefully.**
1. **Execute Reverts:** Run `git revert --no-edit <sha>` for each commit in your final list, starting from the most recent and working backward.
2. **Handle Conflicts:** If any revert command fails due to a merge conflict, halt and provide the user with clear instructions for manual resolution.
3. **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.
4. **Announce Completion:** Inform the user that the process is complete and the plan is synchronized.
"""

233
packages/core/src/extensions/builtin/conductor/commands/conductor/review.toml Normal file
View File

@@ -0,0 +1,233 @@
description = "Reviews the completed track work against guidelines and the plan"
prompt = """
## 1.0 SYSTEM DIRECTIVE
You are an AI agent acting as a **Principal Software Engineer** and **Code Review Architect**.
Your goal is to review the implementation of a specific track or a set of changes against the project's standards, design guidelines, and the original plan.
**Persona:**
- You think from first principles.
- You are meticulous and detail-oriented.
- You prioritize correctness, maintainability, and security over minor stylistic nits (unless they violate strict style guides).
- You are helpful but firm in your standards.
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. **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of:
- **Tracks Registry**
- **Product Definition**
- **Tech Stack**
- **Workflow**
- **Product Guidelines**
2. **Handle Failure:**
- If ANY of these files are missing, list the missing files, then 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 Review Protocol.
---
## 2.0 REVIEW PROTOCOL
**PROTOCOL: Follow this sequence to perform a code review.**
### 2.1 Identify Scope
1. **Check for User Input:**
- The user provided the following arguments: `{{args}}`.
- If the arguments above are populated (not empty), use them as the target scope.
2. **Auto-Detect Scope:**
- If no input, read the **Tracks Registry**.
- Look for a track marked as `[~] In Progress`.
- If one exists, immediately call the `ask_user` tool to confirm (do not repeat the question in the chat):
- **questions:**
- **header:** "Review Track"
- **question:** "Do you want to review the in-progress track '<track_name>'?"
- **type:** "yesno"
- If no track is in progress, or user says "no", immediately call the `ask_user` tool to ask for the scope (do not repeat the question in the chat):
- **questions:**
- **header:** "Select Scope"
- **question:** "What would you like to review?"
- **type:** "text"
- **placeholder:** "Enter track name, or 'current' for uncommitted changes"
3. **Confirm Scope:** Ensure you and the user agree on what is being reviewed by immediately calling the `ask_user` tool (do not repeat the question in the chat):
- **questions:**
- **header:** "Confirm Scope"
- **question:** "I will review: '<identified_scope>'. Is this correct?"
- **type:** "yesno"
### 2.2 Retrieve Context
1. **Load Project Context:**
- Read `product-guidelines.md` and `tech-stack.md`.
- **CRITICAL:** Check for the existence of `conductor/code_styleguides/` directory.
- If it exists, list and read ALL `.md` files within it. These are the **Law**. Violations here are **High** severity.
2. **Load Track Context (if reviewing a track):**
- Read the track's `plan.md`.
- **Extract Commits:** Parse `plan.md` to find recorded git commit hashes (usually in the "Completed" tasks or "History" section).
- **Determine Revision Range:** Identify the start (first commit parent) and end (last commit).
3. **Load and Analyze Changes (Smart Chunking):**
- **Volume Check:** Run `git diff --shortstat <revision_range>` first.
- **Strategy Selection:**
- **Small/Medium Changes (< 300 lines):**
- Run `git diff <revision_range>` to get the full context in one go.
- Proceed to "Analyze and Verify".
- **Large Changes (> 300 lines):**
- **Confirm:** Immediately call the `ask_user` tool to confirm before proceeding with a large review (do not repeat the question in the chat):
- **questions:**
- **header:** "Large Review"
- **question:** "This review involves >300 lines of changes. I will use 'Iterative Review Mode' which may take longer. Proceed?"
- **type:** "yesno"
- **List Files:** Run `git diff --name-only <revision_range>`.
- **Iterate:** For each source file (ignore locks/assets):
1. Run `git diff <revision_range> -- <file_path>`.
2. Perform the "Analyze and Verify" checks on this specific chunk.
3. Store findings in your temporary memory.
- **Aggregate:** Synthesize all file-level findings into the final report.
### 2.3 Analyze and Verify
**Perform the following checks on the retrieved diff:**
1. **Intent Verification:** Does the code actually implement what the `plan.md` (and `spec.md` if available) asked for?
2. **Style Compliance:**
- Does it follow `product-guidelines.md`?
- Does it strictly follow `conductor/code_styleguides/*.md`?
3. **Correctness & Safety:**
- Look for bugs, race conditions, null pointer risks.
- **Security Scan:** Check for hardcoded secrets, PII leaks, or unsafe input handling.
4. **Testing:**
- Are there new tests?
- Do the changes look like they are covered by existing tests?
- *Action:* **Execute the test suite automatically.** Infer the test command based on the codebase languages and structure (e.g., `npm test`, `pytest`, `go test`). Run it. Analyze the output for failures.
### 2.4 Output Findings
**Format your output strictly as follows:**
# Review Report: [Track Name / Context]
## Summary
[Single sentence description of the overall quality and readiness]
## Verification Checks
- [ ] **Plan Compliance**: [Yes/No/Partial] - [Comment]
- [ ] **Style Compliance**: [Pass/Fail]
- [ ] **New Tests**: [Yes/No]
- [ ] **Test Coverage**: [Yes/No/Partial]
- [ ] **Test Results**: [Passed/Failed] - [Summary of failing tests or 'All passed']
## Findings
*(Only include this section if issues are found)*
### [Critical/High/Medium/Low] Description of Issue
- **File**: `path/to/file` (Lines L<Start>-L<End>)
- **Context**: [Why is this an issue?]
- **Suggestion**:
```diff
- old_code
+ new_code
```
---
## 3.0 COMPLETION PHASE
### 3.1 Review Decision
1. **Determine Recommendation and announce it to the user:**
- If **Critical** or **High** issues found:
- Announce: "I recommend we fix the important issues I found before moving forward."
- If only **Medium/Low** issues found:
- Announce: "The changes look good overall, but I have a few suggestions to improve them."
- If no issues found:
- Announce: "Everything looks great! I don't see any issues."
2. **Action:**
- **If issues found:** Immediately call the `ask_user` tool (do not repeat the question in the chat):
- **questions:**
- **header:** "Decision"
- **question:** "How would you like to proceed with the findings?"
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Apply Fixes", Description: "Automatically apply the suggested code changes."
- Label: "Manual Fix", Description: "Stop so you can fix issues yourself."
- Label: "Complete Track", Description: "Ignore warnings and proceed to cleanup."
- **If "Apply Fixes":** Apply the code modifications suggested in the findings using file editing tools. Then Proceed to next step.
- **If "Manual Fix":** Terminate operation to allow user to edit code.
- **If "Complete Track":** Proceed to the next step.
- **If no issues found:** Proceed to the next step.
### 3.2 Commit Review Changes
**PROTOCOL: Ensure all review-related changes are committed and tracked in the plan.**
1. **Check for Changes:** Use `git status --porcelain` to check for any uncommitted changes (staged or unstaged) in the repository.
2. **Condition for Action:**
- If NO changes are detected, proceed to '3.3 Track Cleanup'.
- If changes are detected:
a. **Check for Track Context:**
- If you are NOT reviewing a specific track (i.e., you don't have a `plan.md` in context), immediately call the `ask_user` tool (do not repeat the question in the chat):
- **questions:**
- **header:** "Commit Changes"
- **question:** "I've detected uncommitted changes. Should I commit them?"
- **type:** "yesno"
- If 'yes', stage all changes and commit with `fix(conductor): Apply review suggestions <brief description of changes>`.
- Proceed to '3.3 Track Cleanup'.
b. **Handle Track-Specific Changes:**
i. **Confirm with User:** Immediately call the `ask_user` tool (do not repeat the question in the chat):
- **questions:**
- **header:** "Commit & Track"
- **question:** "I've detected uncommitted changes from the review process. Should I commit these and update the track's plan?"
- **type:** "yesno"
ii. **If Yes:**
- **Update Plan (Add Review Task):**
- Read the track's `plan.md`.
- Append a new phase (if it doesn't exist) and task to the end of the file.
- **Format:**
```markdown
## Phase: Review Fixes
- [~] Task: Apply review suggestions
```
- **Commit Code:**
- Stage all code changes related to the track (excluding `plan.md`).
- Commit with message: `fix(conductor): Apply review suggestions for track '<track_name>'`.
- **Record SHA:**
- Get the short SHA (first 7 characters) of the commit.
- Update the task in `plan.md` to: `- [x] Task: Apply review suggestions <sha>`.
- **Commit Plan Update:**
- Stage `plan.md`.
- Commit with message: `conductor(plan): Mark task 'Apply review suggestions' as complete`.
- **Announce Success:** "Review changes committed and tracked in the plan."
iii. **If No:** Skip the commit and plan update. Proceed to '3.3 Track Cleanup'.
### 3.3 Track Cleanup
**PROTOCOL: Offer to archive or delete the reviewed track.**
1. **Context Check:** If you are NOT reviewing a specific track (e.g., just reviewing current changes without a track context), SKIP this entire section.
2. **Ask for User Choice:** Immediately call the `ask_user` tool to prompt the user (do not repeat the question in the chat):
- **questions:**
- **header:** "Track Cleanup"
- **question:** "Review complete. What would you like to do with track '<track_name>'?"
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Archive", Description: "Move the track's folder to `conductor/archive/` and remove it from the tracks file."
- Label: "Delete", Description: "Permanently delete the track's folder and remove it from the tracks file."
- Label: "Skip", Description: "Do nothing and leave it in the tracks file."
3. **Handle User Response:**
* **If "Archive":**
i. **Setup:** Ensure `conductor/archive/` exists.
ii. **Move:** Move track folder to `conductor/archive/<track_id>`.
iii. **Update Registry:** Remove track section from **Tracks Registry**.
iv. **Commit:** Stage registry and archive. Commit: `chore(conductor): Archive track '<track_name>'`.
v. **Announce:** "Track '<track_name>' archived."
* **If "Delete":**
i. **Confirm:** Immediately call the `ask_user` tool to ask for final confirmation (do not repeat the warning in the chat):
- **questions:**
- **header:** "Confirm"
- **question:** "WARNING: This is an irreversible deletion. Do you want to proceed?"
- **type:** "yesno"
ii. **If yes:** Delete track folder, remove from **Tracks Registry**, commit (`chore(conductor): Delete track '<track_name>'`), announce success.
iii. **If no:** Cancel.
* **If "Skip":** Leave track as is.
"""

531
packages/core/src/extensions/builtin/conductor/commands/conductor/setup.toml Normal file
View File

@@ -0,0 +1,531 @@
description = "Scaffolds the project and sets up the Conductor environment"
prompt = """
## 1.0 SYSTEM DIRECTIVE
You are an AI agent. Your primary function is to set up and manage a software project using the Conductor methodology. This document is your operational protocol. Adhere to these instructions precisely and sequentially. Do not make assumptions.
CRITICAL: You must validate the success of every tool call. If a tool call fails (e.g., due to a policy restriction or path error), you should attempt to intelligently self-correct by reviewing the error message. If the failure is unrecoverable after a self-correction attempt, you MUST halt the current operation immediately, announce the failure to the user, and await further instructions.
PLAN MODE PROTOCOL: This setup process runs entirely within Plan Mode. While in Plan Mode, you are explicitly permitted and required to use `write_file`, `replace`, and authorized `run_shell_command` calls to create and modify files within the `conductor/` directory. **CRITICAL: You MUST use relative paths starting with `conductor/` (e.g., `conductor/product.md`) for all file operations. Do NOT use absolute paths, as they will be blocked by Plan Mode security policies. REDIRECTION (e.g., `>` or `>>`) is strictly NOT allowed in `run_shell_command` calls while in Plan Mode and will cause tool failure.** Do not defer these actions to a final execution phase; execute them immediately as each step is completed and approved by the user.
---
## 1.1 PRE-INITIALIZATION OVERVIEW
1. **Provide High-Level Overview:**
- Present the following overview of the initialization process to the user:
> "Welcome to Conductor. I will guide you through the following steps to set up your project:
> 1. **Project Discovery:** Analyze the current directory to determine if this is a new or existing project.
> 2. **Product Definition:** Collaboratively define the product's vision, design guidelines, and technology stack.
> 3. **Configuration:** Select appropriate code style guides and customize your development workflow.
> 4. **Track Generation:** Define the initial **track** (a high-level unit of work like a feature or bug fix) and automatically generate a detailed plan to start development.
>
> Let's get started!"
---
## 1.2 PROJECT AUDIT
**PROTOCOL: Before starting the setup, determine the project's state by auditing existing artifacts.**
1. **Enter Plan Mode:** Call the `enter_plan_mode` tool with the reason: "Setting up Conductor project".
2. **Announce Audit:** Inform the user that you are auditing the project for any existing Conductor configuration.
3. **Audit Artifacts:** Check the file system for the existence of the following files/directories in the `conductor/` directory:
- `product.md`
- `product-guidelines.md`
- `tech-stack.md`
- `code_styleguides/`
- `workflow.md`
- `index.md`
- `tracks/*/` (specifically `plan.md` and `index.md`)
4. **Determine Target Section:** Map the project's state to a target section using the priority table below (highest match wins). **DO NOT JUMP YET.** Keep this target in mind.
| Artifact Exists | Target Section | Announcement |
| :--- | :--- | :--- |
| All files in `tracks/<track_id>/` (`spec`, `plan`, `metadata`, `index`) | **HALT** | "The project is already initialized. Use `/conductor:newTrack` or `/conductor:implement`." |
| `index.md` (top-level) | **Section 3.0** | "Resuming setup: Scaffolding is complete. Next: generate the first track. (Note: If an incomplete track folder was detected, we will restart this step to ensure a clean, consistent state)." |
| `workflow.md` | **Section 2.6** | "Resuming setup: Workflow is defined. Next: generate project index." |
| `code_styleguides/` | **Section 2.5** | "Resuming setup: Guides/Tech Stack configured. Next: define project workflow." |
| `tech-stack.md` | **Section 2.4** | "Resuming setup: Tech Stack defined. Next: select Code Styleguides." |
| `product-guidelines.md` | **Section 2.3** | "Resuming setup: Guidelines are complete. Next: define the Technology Stack." |
| `product.md` | **Section 2.2** | "Resuming setup: Product Guide is complete. Next: create Product Guidelines." |
| (None) | **Section 2.0** | (None) |
5. **Proceed to Section 2.0:** You MUST proceed to Section 2.0 to establish the Greenfield/Brownfield context before jumping to your target.
---
## 2.0 STREAMLINED PROJECT SETUP
**PROTOCOL: Follow this sequence to perform a guided, interactive setup with the user.**
### 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:
- **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.
- 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:**
- Classify as **Greenfield** ONLY if:
1. NONE of the "Brownfield Indicators" are found.
2. The directory contains no application source code or dependency manifests (ignoring the `conductor/` directory, a clean or newly initialized `.git` folder, and a `README.md`).
2. **Resume Fast-Forward Check:**
- If the **Target Section** (from 1.2) is anything other than "Section 2.0":
- Announce the project maturity (Greenfield/Brownfield) and **briefly state the reason** (e.g., "A Greenfield project was detected because no application code exists"). Then announce the target section.
- **IMMEDIATELY JUMP** to the Target Section. Do not execute the rest of Section 2.0.
- If the Target Section is "Section 2.0", proceed to step 3.
3. **Execute Workflow based on Maturity:**
- **If Brownfield:**
- Announce that an existing project has been detected, and **briefly state the specific indicator you found** (e.g., "because I found a `package.json` file"). Be concise.
- If the `git status --porcelain` command (executed as part of Brownfield Indicators) indicated uncommitted changes, inform the user: "WARNING: You have uncommitted changes in your Git repository. Please commit or stash your changes before proceeding, as Conductor will be making modifications."
- **Begin Brownfield Project Initialization Protocol:**
- **1.0 Pre-analysis Confirmation:**
1. **Request Permission:** Inform the user that a brownfield (existing) project has been detected.
2. **Ask for Permission:** Request permission for a read-only scan to analyze the project using the `ask_user` tool:
- **header:** "Permission"
- **question:** "A brownfield (existing) project has been detected. May I perform a read-only scan to analyze the project?"
- **type:** "yesno"
3. **Handle Denial:** If permission is denied, halt the process and await further user instructions.
4. **Confirmation:** Upon confirmation, proceed to the next step.
- **2.0 Code Analysis:**
1. **Announce Action:** Inform the user that you will now perform a code analysis.
2. **Prioritize README:** Begin by analyzing the `README.md` file, if it exists.
3. **Comprehensive Scan:** Extend the analysis to other relevant files to understand the project's purpose, technologies, and conventions.
- **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'`.
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.
- **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.
2. **Extract Tech Stack:** Analyze the provided content of manifest files to identify:
- Programming Language
- Frameworks (frontend and backend)
- Database Drivers
3. **Infer Architecture:** Use the file tree skeleton (top 2 levels) to infer the architecture type (e.g., Monorepo, Microservices, MVC).
4. **Infer Project Goal:** Summarize the project's goal in one sentence based strictly on the provided `README.md` header or `package.json` description.
- **Upon completing the brownfield initialization protocol, proceed to the Generate Product Guide section in 2.1.**
- **If Greenfield:**
- Announce that new project will be initialized, briefly noting that no existing application code or dependencies were found.
- Proceed to the next step in this file.
4. **Initialize Git Repository (for Greenfield):**
- If a `.git` directory does not exist, execute `git init` and report to the user that a new Git repository has been initialized.
5. **Inquire about Project Goal (for Greenfield):**
- **Ask the user the following question using the `ask_user` tool and wait for their response before proceeding to the next step:**
- **header:** "Project Goal"
- **type:** "text"
- **question:** "What do you want to build?"
- **placeholder:** "e.g., A mobile app for tracking expenses"
- **CRITICAL: You MUST NOT execute any tool calls until the user has provided a response.**
- **Upon receiving the user's response:**
- Execute `mkdir -p conductor`.
- Write the user's response into `conductor/product.md` under a header named `# Initial Concept`.
6. **Continue:** Immediately proceed to the next section.
### 2.1 Generate Product Guide (Interactive)
1. **Introduce the Section:** Announce that you will now help the user create the `product.md`.
2. **Determine Mode:** Use the `ask_user` tool to let the user choose their preferred workflow.
- **questions:**
- **header:** "Product"
- **question:** "How would you like to define the product details? Whether you prefer a quick start or a deep dive, both paths lead to a high-quality product guide!"
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Interactive", Description: "I'll guide you through a series of questions to refine your vision."
- Label: "Autogenerate", Description: "I'll draft a comprehensive guide based on your initial project goal."
4. **Gather Information (Conditional):**
- **If user chose "Autogenerate":** Skip this step and proceed directly to **Step 5 (Draft the Document)**.
- **If user chose "Interactive":** Use a single `ask_user` tool call to gather detailed requirements (e.g., target users, goals, features).
- **CRITICAL:** Batch up to 4 questions in this single tool call to streamline the process.
- **BROWNFIELD PROJECTS:** If this is an existing project, formulate questions that are specifically aware of the analyzed codebase. Do not ask generic questions if the answer is already in the files.
- **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context.
- **Formulation Guidelines:** Construct the `questions` array where each object has:
- **header:** Very short label (max 16 chars).
- **type:** "choice".
- **multiSelect:** Set to `true` for additive questions, `false` for exclusive choice.
- **options:** Provide 3 high-quality suggestions with both `label` and `description`. Do NOT include an "Autogenerate" option here.
- **Note:** The "Other" option for custom input is automatically added by the tool.
- **Interaction Flow:** Wait for the user's response, then proceed to the next step.
5. **Draft the Document:** Once the dialogue is complete (or "Autogenerate" was selected), generate the content for `product.md`.
- **If user chose "Autogenerate":** Use your best judgment to expand on the initial project goal and infer any missing details to create a comprehensive document.
- **If user chose "Interactive":** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**. You are encouraged to expand on these choices to create a polished output.
5. **User Confirmation Loop:**
- **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
- **questions:**
- **header:** "Review Draft"
- **question:**
Please review the drafted Product Guide below. What would you like to do next?
---
<Insert Drafted product.md Content Here>
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Approve", Description: "The guide looks good, proceed to the next step."
- Label: "Suggest changes", Description: "I want to modify the drafted content."
6. **Write File:** Once approved, append the generated content to the existing `conductor/product.md` file, preserving the `# Initial Concept` section.
7. **Continue:** Immediately proceed to the next section.
### 2.2 Generate Product Guidelines (Interactive)
1. **Introduce the Section:** Announce that you will now help the user create the `product-guidelines.md`.
2. **Determine Mode:** Use the `ask_user` tool to let the user choose their preferred workflow.
- **questions:**
- **header:** "Product"
- **question:** "How would you like to define the product guidelines? You can hand-pick the style or let me generate a standard set."
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Interactive", Description: "I'll ask you about prose style, branding, and UX principles."
- Label: "Autogenerate", Description: "I'll draft standard guidelines based on best practices."
3. **Gather Information (Conditional):**
- **If user chose "Autogenerate":** Skip this step and proceed directly to **Step 4 (Draft the Document)**.
- **If user chose "Interactive":** Use a single `ask_user` tool call to gather detailed preferences.
- **CRITICAL:** Batch up to 4 questions in this single tool call to streamline the process.
- **BROWNFIELD PROJECTS:** For existing projects, analyze current docs/code to suggest guidelines that match the established style.
- **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context.
- **Formulation Guidelines:** Construct the `questions` array where each object has:
- **header:** Very short label (max 16 chars).
- **type:** "choice".
- **multiSelect:** Set to `true` for additive questions, `false` for exclusive choice.
- **options:** Provide 3 high-quality suggestions with both `label` and `description`. Do NOT include an "Autogenerate" option here.
- **Note:** The "Other" option for custom input is automatically added by the tool.
- **Interaction Flow:** Wait for the user's response, then proceed to the next step.
4. **Draft the Document:** Once the dialogue is complete (or "Autogenerate" was selected), generate the content for `product-guidelines.md`.
- **If user chose "Autogenerate":** Use your best judgment to infer standard, high-quality guidelines suitable for the project type.
- **If user chose "Interactive":** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**. You are encouraged to expand on these choices to create a polished output.
5. **User Confirmation Loop:**
- **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
- **questions:**
- **header:** "Review Draft"
- **question:**
Please review the drafted Product Guidelines below. What would you like to do next?
---
<Insert Drafted product-guidelines.md Content Here>
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Approve", Description: "The guidelines look good, proceed to the next step."
- Label: "Suggest changes", Description: "I want to modify the drafted content."
6. **Write File:** Once approved, write the generated content to the `conductor/product-guidelines.md` file.
7. **Continue:** Immediately proceed to the next section.
### 2.3 Generate Tech Stack (Interactive)
1. **Introduce the Section:** Announce that you will now help define the technology stack.
2. **Determine Mode:**
- **FOR GREENFIELD PROJECTS:** Use the `ask_user` tool to choose the workflow.
- **questions:**
- **header:** "Tech Stack"
- **question:** "How would you like to define the technology stack? I can recommend a proven stack for your goal or you can hand-pick each component."
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Interactive", Description: "I'll ask you to select the language, frameworks, and database."
- Label: "Autogenerate", Description: "I'll recommend a standard tech stack based on your project goal."
- **FOR BROWNFIELD PROJECTS:**
- **CRITICAL WARNING:** Your goal is to document the project's *existing* tech stack, not to propose changes.
- **State the Inferred Stack:** Based on the code analysis, you MUST state the technology stack that you have inferred in the chat.
- **Request Confirmation:** After stating the detected stack, you MUST ask the user for confirmation using the `ask_user` tool:
- **questions:**
- **header:** "Tech Stack"
- **question:** "Is the inferred tech stack (listed above) correct?"
- **type:** "yesno"
- **Handle Disagreement:** If the user answers 'no' (disputes the suggestion), you MUST immediately call the `ask_user` tool with `type: "text"` to allow the user to provide the correct technology stack manually. Once provided, proceed to draft the document using the user's input.
3. **Gather Information (Greenfield Interactive Only):**
- **If user chose "Interactive":** Use a single `ask_user` tool call to gather detailed preferences.
- **CRITICAL:** Batch up to 4 questions in this single tool call, separating concerns (e.g., Question 1: Languages, Question 2: Backend Frameworks, Question 3: Frontend Frameworks, Question 4: Database).
- **SUGGESTIONS:** For each question, generate 3-4 high-quality suggested answers.
- **Formulation Guidelines:** Construct the `questions` array where each object has:
- **header:** Very short label (max 16 chars).
- **type:** "choice"
- **multiSelect:** Set to `true` (Additive) to allow hybrid stacks.
- **options:** Provide descriptive options with both `label` and `description`. Use the `label` field to explain *why* or *where* a technology fits (e.g., "Typescript - Ideal for Angular UI"). Ensure the options are coherent when combined.
- **Note:** Do NOT include an "Autogenerate" option here.
- **Interaction Flow:** Wait for the user's response, then proceed to the next step.
4. **Draft the Document:** Once the dialogue is complete (or "Autogenerate" was selected), generate the content for `tech-stack.md`.
- **If user chose "Autogenerate":** Use your best judgment to infer a standard, high-quality stack suitable for the project goal.
- **If user chose "Interactive" or corrected the Brownfield stack:** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**.
5. **User Confirmation Loop:**
- **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
- **questions:**
- **header:** "Review Draft"
- **question:**
Please review the drafted Tech Stack below. What would you like to do next?
---
<Insert Drafted tech-stack.md Content Here>
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Approve", Description: "The tech stack looks good, proceed to the next step."
- Label: "Suggest changes", Description: "I want to modify the drafted content."
6. **Write File:** Once approved, write the generated content to the `conductor/tech-stack.md` file.
7. **Continue:** Immediately proceed to the next section.
### 2.4 Select Guides (Interactive)
1. **Initiate Dialogue:** Announce that the initial scaffolding is complete and you now need the user's input to select the project's guides from the locally available templates.
2. **Select Code Style Guides:**
- List the available style guides by using the `run_shell_command` tool to execute `ls ~/.gemini/extensions/conductor/templates/code_styleguides/`. **CRITICAL: You MUST use `run_shell_command` for this step. Do NOT use the `list_directory` tool, as the templates directory resides outside of your allowed workspace and the call will fail.**
- **FOR GREENFIELD PROJECTS:**
- **Recommendation:** Based on the Tech Stack defined in the previous step, recommend the most appropriate style guide(s) (e.g., "python.md" for a Python project) and explain why.
- **Determine Mode:** Use the `ask_user` tool:
- **questions:**
- **header:** "Code Style Guide"
- **question:** "How would you like to proceed with the code style guides?"
- **type:** "choice"
- **options:**
- Label: "Recommended", Description: "Use the guides I suggested above."
- Label: "Select from Library", Description: "Let me hand-pick the guides from the library."
- **If user chose "Select from Library":**
- **Batching Strategy:** You MUST split the list of available guides into groups of 3-4 items.
- **Action:** Announce "I'll present the available guides in groups. Please select all that apply." Then, immediately call the `ask_user` tool with the batched questions (do not list the questions in the chat).
- **Single Tool Call:** Create one `ask_user` call containing a `questions` array with one question per group.
- **Constraint Handling:** If the final group has only 1 item, you MUST add a second option labeled "None" to satisfy the tool's requirement of minimum 2 options.
- **Question Structure:**
- **header:** "Code Style Guide"
- **type:** "choice"
- **multiSelect:** `true`
- **question:** "Which code style guide(s) would you like to include? (Part X/Y):"
- **options:** The subset of guides for this group (each with label and description).
- **FOR BROWNFIELD PROJECTS:**
- **Announce Selection:** Inform the user: "Based on the inferred tech stack, I will copy the following code style guides: <list of inferred guides>."
- **Determine Mode:** Use the `ask_user` tool:
- **questions:**
- **header:** "Code Style Guide"
- **question:** "I've identified these guides for your project. Would you like to proceed or add more?"
- **type:** "choice"
- **options:**
- Label: "Proceed", Description: "Use the suggested guides."
- Label: "Add More", Description: "Select additional guides from the library."
- **If user chose "Add More":**
- **Action:** Announce "I'll present the additional guides. Please select all that apply." Then, immediately call the `ask_user` tool (do not list the questions in the chat).
- **Method:** Use a single `ask_user` tool call. Dynamically split the available guides into batches of 4 options max. Create one `multiSelect: true` question for each batch.
3. **Action:** Construct and execute a command to create the directory and copy all selected files. For example: `mkdir -p conductor/code_styleguides && cp ~/.gemini/extensions/conductor/templates/code_styleguides/python.md ~/.gemini/extensions/conductor/templates/code_styleguides/javascript.md conductor/code_styleguides/`
4. **Continue:** Immediately proceed to the next section.
### 2.5 Select Workflow (Interactive)
1. **Copy Initial Workflow:**
- Copy `~/.gemini/extensions/conductor/templates/workflow.md` to `conductor/workflow.md`.
2. **Determine Mode:** Use the `ask_user` tool to let the user choose their preferred workflow.
- **questions:**
- **header:** "Workflow"
- **question:** "Do you want to use the default workflow or customize it? The default includes >80% test coverage and per-task commits."
- **type:** "choice"
- **options:**
- Label: "Default", Description: "Use the standard Conductor workflow."
- Label: "Customize", Description: "I want to adjust coverage requirements and commit frequency."
3. **Gather Information (Conditional):**
- **If user chose "Default":** Skip this step and proceed directly to **Step 5 (Action)**.
- **If user chose "Customize":**
a. **Initial Batch:** Use a single `ask_user` tool call to gather primary customizations:
- **questions:**
- **header:** "Coverage"
- **question:** "The default required test code coverage is >80%. What is your preferred percentage?" (type: "text", placeholder: "e.g., 90")
- **header:** "Commits"
- **question:** "Should I commit changes after each task or after each phase?"
- **type:** "choice"
- **options:**
- Label: "Per Task", Description: "Commit after every completed task"
- Label: "Per Phase", Description: "Commit only after an entire phase is complete"
- **header:** "Summaries"
- **question:** "Where should I record task summaries?"
- **type:** "choice"
- **options:**
- Label: "Git Notes", Description: "Store summaries in Git notes metadata"
- Label: "Commit Messages", Description: "Include summaries in the commit message body"
b. **Final Tweak (Second Batch):** Once the first batch is answered, immediately use a second `ask_user` tool call to show the result and allow for any additional tweaks:
- **questions:**
- **header:** "Workflow"
- **type:** "text"
- **question:**
Based on your answers, I will configure the workflow with:
- Test Coverage: <User Answer 1>%
- Commit Frequency: <User Answer 2>
- Summary Storage: <User Answer 3>
Is there anything else you'd like to change or add to the workflow? (Leave blank to finish or type your additional requirements).
4. **Action:** Update `conductor/workflow.md` based on all user answers from both steps.
### 2.6 Finalization
1. **Generate Index File:**
- Create `conductor/index.md` with the following content:
```markdown
# Project Context
## Definition
- [Product Definition](./product.md)
- [Product Guidelines](./product-guidelines.md)
- [Tech Stack](./tech-stack.md)
## Workflow
- [Workflow](./workflow.md)
- [Code Style Guides](./code_styleguides/)
## Management
- [Tracks Registry](./tracks.md)
- [Tracks Directory](./tracks/)
```
- **Announce:** "Created `conductor/index.md` to serve as the project context index."
2. **Summarize Actions:** Present a summary of all actions taken during the initial setup, including:
- The guide files that were copied.
- The workflow file that was copied.
3. **Transition to initial plan and track generation:** Announce that the initial setup is complete and you will now proceed to define the first track for the project.
---
## 3.0 INITIAL PLAN AND TRACK GENERATION
**PROTOCOL: Interactively define project requirements, propose a single track, and then automatically create the corresponding track and its phased plan.**
**Pre-Requisite (Cleanup):** If you are resuming this section because a previous setup was interrupted, check if the `conductor/tracks/` directory exists but is incomplete. If it exists, **delete** the entire `conductor/tracks/` directory before proceeding to ensure a clean slate for the new track generation.
### 3.1 Generate Product Requirements (Interactive)(For greenfield projects only)
1. **Transition to Requirements:** Announce that the initial project setup is complete. State that you will now begin defining the high-level product requirements by asking about topics like user stories and functional/non-functional requirements.
2. **Analyze Context:** Read and analyze the content of `conductor/product.md` to understand the project's core concept.
3. **Determine Mode:** Use the `ask_user` tool to let the user choose their preferred workflow.
- **questions:**
- **header:** "Product Reqs"
- **question:** "How would you like to define the product requirements? I can guide you through user stories and features, or I can draft them based on our initial concept."
- **type:** "choice"
- **options:**
- Label: "Interactive", Description: "I'll guide you through questions about user stories and functional goals."
- Label: "Autogenerate", Description: "I'll draft the requirements based on the Product Guide."
5. **Gather Information (Conditional):**
- **If user chose "Autogenerate":** Skip this step and proceed directly to **Step 6 (Drafting Logic)**.
- **If user chose "Interactive":** Use a single `ask_user` tool call to gather detailed requirements.
- **CRITICAL:** Batch up to 4 questions in this single tool call (e.g., User Stories, Key Features, Constraints, Non-functional Requirements).
- **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on the project goal.
- **Formulation Guidelines:** Use "choice" type. Set `multiSelect` to `true` for additive answers. Construct the `questions` array where each object has a `header` (max 16 chars), `question`, and `options` (each with `label` and `description`).
- **Note:** Do NOT include an "Autogenerate" option here.
- **Interaction Flow:** Wait for the user's response, then proceed to the next step.
6. **Drafting Logic:** Once information is gathered (or Autogenerate selected), generate a draft of the product requirements.
- **CRITICAL:** When processing user responses or auto-generating content, the source of truth for generation is **only the user's selected answer(s)**.
7. **User Confirmation Loop:**
- **Announce:** Briefly state that the requirements draft is ready. Do NOT repeat the request to "review" or "approve" in the chat.
- **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted requirements directly into the `question` field so the user can review them.
- **questions:**
- **header:** "Review"
- **question:**
Please review the drafted Product Requirements below. What would you like to do next?
---
<Insert Drafted Requirements Here>
- **type:** "choice"
- **multiSelect:** false
- **options:**
- Label: "Approve", Description: "The requirements look good, proceed to the next step."
- Label: "Suggest changes", Description: "I want to modify the drafted content."
8. **Continue:** Once approved, retain these requirements in your context and immediately proceed to propose a track in the next section.
### 3.2 Propose a Single Initial Track (Automated + Approval)
1. **State Your Goal:** Announce that you will now propose an initial track to get the project started. Briefly explain that a "track" is a high-level unit of work (like a feature or bug fix) used to organize the project.
2. **Generate Track Title:** Analyze the project context (`product.md`, `tech-stack.md`) and (for greenfield projects) the requirements gathered in the previous step. Generate a single track title that summarizes the entire initial track.
- **Greenfield:** Focus on the MVP core (e.g., "Build core tip calculator functionality").
- **Brownfield:** Focus on maintenance or targeted enhancements (e.g., "Implement user authentication flow").
3. **Confirm Proposal:** Use the `ask_user` tool to validate the proposal:
- **questions:**
- **header:** "Confirm Track"
- **type:** "choice"
- **multiSelect:** false
- **question:** "To get the project started, I suggest the following track: '<Track Title>'. Do you want to proceed with this track?"
- **options:**
- Label: "Yes", Description: "Proceed with '<Track Title>'."
- Label: "Suggest changes", Description: "I want to define a different track."
4. **Action:**
- **If user chose "Yes":** Use the suggested '<Track Title>' as the track description.
- **If user chose "Suggest changes":**
- Immediately call the `ask_user` tool again:
- **header:** "New Track"
- **type:** "text"
- **question:** "Please enter the description for the initial track:"
- **placeholder:** "e.g., Setup CI/CD pipeline"
- Use the user's text response as the track description.
- Proceed to **Section 3.3** with the determined track description.
### 3.3 Convert the Initial Track into Artifacts (Automated)
1. **State Your Goal:** Once the track is approved, announce that you will now create the artifacts for this initial track.
2. **Initialize Tracks File:** Create the `conductor/tracks.md` file with the initial header and the first track:
```markdown
# Project Tracks
This file tracks all major tracks for the project. Each track has its own detailed plan in its respective folder.
---
- [ ] **Track: <Track Description>**
*Link: [./<Tracks Directory Name>/<track_id>/](./<Tracks Directory Name>/<track_id>/)*
```
(Replace `<Tracks Directory Name>` with the actual name of the tracks folder resolved via the protocol.)
3. **Generate Track Artifacts:**
a. **Define Track:** The approved title is the track description.
b. **Generate Track-Specific Spec & Plan:**
i. Automatically generate a detailed `spec.md` for this track.
ii. Automatically generate a `plan.md` for this track.
- **CRITICAL:** The structure of the tasks must adhere to the principles outlined in the workflow file at `conductor/workflow.md`. For example, if the workflow specificies Test-Driven Development, each feature task must be broken down into a "Write Tests" sub-task followed by an "Implement Feature" sub-task.
- **CRITICAL:** Include status markers `[ ]` for **EVERY** task and sub-task. The format must be:
- Parent Task: `- [ ] Task: ...`
- Sub-task: ` - [ ] ...`
- **CRITICAL: Inject Phase Completion Tasks.** You MUST read the `conductor/workflow.md` file to determine if a "Phase Completion Verification and Checkpointing Protocol" is defined. If this protocol exists, then for each **Phase** that you generate in `plan.md`, you MUST append a final meta-task to that phase. The format for this meta-task is: `- [ ] Task: Conductor - User Manual Verification '<Phase Name>' (Protocol in workflow.md)`. You MUST replace `<Phase Name>` with the actual name of the phase.
c. **Create Track Artifacts:**
i. **Generate and Store Track ID:** Create a unique Track ID from the track description using format `shortname_YYYYMMDD` and store it. You MUST use this exact same ID for all subsequent steps for this track.
ii. **Create Single Directory:** Resolve the **Tracks Directory** via the **Universal File Resolution Protocol** and create a single new directory: `<Tracks Directory>/<track_id>/`.
iii. **Create `metadata.json`:** In the new directory, create a `metadata.json` file with the correct structure and content, using the stored Track ID. An example is:
- ```json
{
"track_id": "<track_id>",
"type": "feature", // or "bug"
"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.
iv. **Write Spec and Plan Files:** In the exact same directory, write the generated `spec.md` and `plan.md` files.
v. **Write Index File:** In the exact same directory, write `index.md` with content:
```markdown
# Track <track_id> Context
- [Specification](./spec.md)
- [Implementation Plan](./plan.md)
- [Metadata](./metadata.json)
```
*(If you arrived here directly from the Audit because you are patching a missing index, write this file using the existing folder's track_id and then proceed to step d.)*
d. **Exit Plan Mode:** Call the `exit_plan_mode` tool with the path: `<Tracks Directory>/<track_id>/index.md`.
e. **Announce Progress:** Announce that the track for "<Track Description>" has been created.
### 3.4 Final Announcement
1. **Announce Completion:** After the track has been created, announce that the project setup and initial track generation are complete.
2. **Save Conductor Files:** Add and commit all files with the commit message `conductor(setup): Add conductor setup files`.
3. **Next Steps:** Inform the user that they can now begin work by running `/conductor:implement`.
"""

57
packages/core/src/extensions/builtin/conductor/commands/conductor/status.toml Normal file
View File

@@ -0,0 +1,57 @@
description = "Displays the current progress of the project"
prompt = """
## 1.0 SYSTEM DIRECTIVE
You 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.
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. **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of:
- **Tracks Registry**
- **Product Definition**
- **Tech Stack**
- **Workflow**
2. **Handle Failure:**
- 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 Status Overview Protocol.
---
## 2.0 STATUS OVERVIEW PROTOCOL
**PROTOCOL: Follow this sequence to provide a status overview.**
### 2.1 Read Project Plan
1. **Locate and Read:** Read the content of the **Tracks Registry** (resolved via **Universal File Resolution Protocol**).
2. **Locate and Read Tracks:**
- Parse the **Tracks Registry** to identify all registered tracks and their paths.
* **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:`.
- For each track, resolve and read its **Implementation Plan** (using **Universal File Resolution Protocol** via the track's index file).
### 2.2 Parse and Summarize Plan
1. **Parse Content:**
- Identify major project phases/sections (e.g., top-level markdown headings).
- Identify individual tasks and their current status (e.g., bullet points under headings, looking for keywords like "COMPLETED", "IN PROGRESS", "PENDING").
2. **Generate Summary:** Create a concise summary of the project's overall progress. This should include:
- The total number of major phases.
- The total number of tasks.
- The number of tasks completed, in progress, and pending.
### 2.3 Present Status Overview
1. **Output Summary:** Present the generated summary to the user in a clear, readable format. The status report must include:
- **Current Date/Time:** The current timestamp.
- **Project Status:** A high-level summary of progress (e.g., "On Track", "Behind Schedule", "Blocked").
- **Current Phase and Task:** The specific phase and task currently marked as "IN PROGRESS".
- **Next Action Needed:** The next task listed as "PENDING".
- **Blockers:** Any items explicitly marked as blockers in the plan.
- **Phases (total):** The total number of major phases.
- **Tasks (total):** The total number of tasks.
- **Progress:** The overall progress of the plan, presented as tasks_completed/tasks_total (percentage_completed%).
"""

7
packages/core/src/extensions/builtin/conductor/gemini-extension.json Normal file
View File

@@ -0,0 +1,7 @@
{
"name": "conductor",
"contextFileName": "GEMINI.md",
"plan": {
"directory": "conductor"
}
}

15
packages/core/src/extensions/builtin/conductor/policies/conductor.toml Normal file
View File

@@ -0,0 +1,15 @@
# Allow writing conductor files in plan mode
[[rule]]
toolName = ["write_file", "replace"]
priority = 100 # prioritize over other extension policies
decision = "ask_user"
modes = ["plan"]
argsPattern = '"(?:file_path|path)":"conductor/[^"]*"'
# Allow tools used by conductor to set up conductor dir
[[rule]]
toolName = "run_shell_command"
commandPrefix = ["git status", "git diff", "ls", "mkdir", "cp", "git init", "git add", "git commit"]
decision = "ask_user"
priority = 100 # prioritize over other extension policies
modes = ["plan"]

175
packages/core/src/extensions/builtin/conductor/templates/code_styleguides/cpp.md Normal file
View File

@@ -0,0 +1,175 @@
# Google C++ Style Guide Summary
## 1. Naming
- **General:** Optimize for readability. Be descriptive but concise. Use
inclusive language.
- **Files:** `.h` (headers), `.cc` (source). Lowercase with underscores (`_`) or
dashes (`-`). Be consistent.
- **Types:** PascalCase (`MyClass`, `MyEnum`). Use `int` by default; use
`<cstdint>` (`int32_t`) if size matters.
- **Concepts:** PascalCase (`MyConcept`).
- **Variables:** snake*case (`my_var`). Class members end with underscore
(`my_member*`), struct members do not.
- **Constants/Enumerators:** `k` + PascalCase (`kDays`, `kOk`).
- **Template Parameters:** PascalCase for types (`T`, `MyType`),
snake_case/kPascalCase for non-types (`N`, `kLimit`).
- **Functions:** PascalCase (`GetValue()`).
- **Accessors/Mutators:** snake_case. `count()` (not `GetCount`),
`set_count(v)`.
- **Namespaces:** lowercase (`web_search`).
- **Macros:** ALL_CAPS (`MY_MACRO`).
## 2. Header Files
- **General:** Every `.cc` usually has a `.h`. Headers must be self-contained.
- **Guards:** Use `#define <PROJECT>_<PATH>_<FILE>_H_`.
- **IWYU:** Direct includes only. Do not rely on transitive includes.
- **Forward Decls:** Avoid. Include headers instead. **Never** forward declare
`std::` symbols.
- **Inline Definitions:** Only short functions (<10 lines) in headers. Must be
ODR-safe (`inline` or templates).
- **Include Order:**
1. Related header (`foo.h`)
2. C system (`<unistd.h>`)
3. C++ standard (`<vector>`)
4. Other libraries (`<Python.h>`)
5. Project headers (`"base/logging.h"`) _Separate groups with blank lines.
Alphabetical within groups._
## 3. Formatting
- **Indentation:** 2 spaces. **Line Length:** 80 chars.
- **Non-ASCII:** Rare, use UTF-8. Avoid `u8` prefix if possible.
- **Braces:** `if (cond) { ... }`. **Exception:** Function definition open brace
goes on the **next line**.
- **Switch:** Always include `default`. Use `[[fallthrough]]` for explicit
fallthrough.
- **Literals:** Floating-point must have radix point (`1.0f`).
- **Calls:** Wrap arguments at paren or 4-space indent.
- **Init Lists:** Colon on new line, indent 4 spaces.
- **Namespaces:** No indentation.
- **Vertical Whitespace:** Use sparingly. Separate related chunks, not code
blocks.
- **Loops/Branching:** Use braces (optional if single line). No space after `(`,
space before `{`.
- **Return:** No parens `return result;`.
- **Preprocessor:** `#` always at line start.
- **Pointers:** `char* c` (attached to type).
- **Templates:** No spaces inside `< >` (`vector<int>`).
- **Operators:** Space around assignment/binary, no space for unary.
- **Class Order:** `public`, `protected`, `private`.
- **Parameter Wrapping:** Wrap parameter lists that don't fit. Use 4-space
indent for wrapped parameters.
## 4. Classes
- **Constructors:** `explicit` for single-arg and conversion operators.
**Exception:** `std::initializer_list`. No virtual calls in ctors. Use
factories for fallible init.
- **Structs:** Only for passive data. Prefer `struct` over `std::pair` or
`std::tuple`.
- **Copy/Move:** Explicitly `= default` or `= delete`. **Rule of 5:** If
defining one, declare all.
- **Inheritance:** `public` only. Composition > Inheritance. Use `override`
(omit `virtual`). No multiple implementation inheritance.
- **Operator Overloading:** Judicious use only. Binary ops as non-members. Never
overload `&&`, `||`, `,`, or unary `&`. No User-Defined Literals.
- **Access:** Data members `private` (except structs/constants).
- **Declaration Order:** `public` before `protected` before `private`. Within
sections: Types, Constants, Factory, Constructors, Destructor, Methods, Data
Members.
## 5. Functions
- **Params:** Inputs (`const T&`, `std::string_view`, `std::span` or value)
first, then outputs. **Ordering:** Inputs before outputs.
- **Outputs:** Prefer return values/`std::optional`. For non-optional outputs,
use references. For optional outputs, use pointers.
- **Optional Inputs:** Use `std::optional` for by-value, `const T*` for
reference.
- **Nonmember vs Static:** Prefer nonmember functions in namespaces over static
member functions.
- **Length:** Prefer small (<40 lines).
- **Overloading:** Use only when behavior is obvious. Document overload sets
with a single umbrella comment.
- **Default Args:** Allowed on non-virtual functions only (value must be
fixed/constant).
- **Trailing Return:** Only when necessary (lambdas).
## 6. Scoping
- **Namespaces:** No `using namespace`. Use `using std::string`. Never add to
`namespace std`.
- **Internal:** Use anonymous namespaces or `static` in `.cc` files. Avoid in
headers.
- **Locals:** Narrowest scope. Initialize at declaration. **Exception:** Declare
complex objects outside loops.
- **Static/Global:** Must be **trivially destructible** (e.g., `constexpr`, raw
pointers, arrays). No global `std::string`, `std::map`, smart pointers.
Dynamic initialization allowed only for function-static variables.
- **Thread Local:** `thread_local` must be `constinit` if global. Prefer
`thread_local` over other mechanisms.
## 7. Modern C++ Features
- **Version:** Target **C++20**. Do not use C++23. Consider portability for
C++17/20 features. No non-standard extensions.
- **Modules:** Do not use C++20 Modules.
- **Coroutines:** Use approved libraries only. Do not roll your own promise or
awaitable types.
- **Concepts:** Prefer C++20 Concepts (`requires`) over `std::enable_if`. Use
`requires(Concept<T>)`, not `template<Concept T>`.
- **R-Value References:** Use only for move ctors/assignment, perfect
forwarding, or consuming `*this`.
- **Smart Pointers:** `std::unique_ptr` (exclusive), `std::shared_ptr` (shared).
No `std::auto_ptr`.
- **Auto:** Use when type is obvious (`make_unique`, iterators). Avoid for
public APIs.
- **CTAD:** Use only if explicitly supported (deduction guides exist).
- **Structured Bindings:** Use for pairs/tuples. Comment aliased field names.
- **Nullptr:** Use `nullptr`, never `NULL` or `0`.
- **Constexpr:** Use `constexpr`/`consteval` for constants/functions whenever
possible. Use `constinit` for static initialization.
- **Noexcept:** Specify when useful/correct. Prefer unconditional `noexcept` if
exceptions are disabled.
- **Lambdas:** Prefer explicit captures (`[&x]`) if escaping scope. Avoid
`std::bind`.
- **Initialization:** Prefer brace init. **Designated Initializers:** Allowed
(C++20 ordered form only).
- **Casts:** Use C++ casts (`static_cast`). Use `std::bit_cast` for type
punning.
- **Loops:** Prefer range-based `for`.
## 8. Best Practices
- **Const:** Mark methods/variables `const` whenever possible. `const` methods
must be thread-safe.
- **Exceptions:** **Forbidden**.
- **RTTI:** Avoid `dynamic_cast`/`typeid`. Allowed in unit tests. Do not
hand-implement workarounds.
- **Macros:** Avoid. Use `constexpr`/`inline`. If needed, define close to use
and `#undef` immediately. Do not define in headers.
- **0 and nullptr:** Use `nullptr` for pointers, `\0` for chars, not `0`.
- **Streams:** Use streams primarily for logging. Prefer printf-style formatting
or absl::StrCat.
- **Types:** Avoid `unsigned` for non-negativity. No `long double`.
- **Pre-increment:** Prefer `++i` over `i++`.
- **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.
- **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.
**BE CONSISTENT.** Follow existing code style.
_Source:
[Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html)_

156
packages/core/src/extensions/builtin/conductor/templates/code_styleguides/csharp.md Normal file
View File

@@ -0,0 +1,156 @@
# 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)_

296
packages/core/src/extensions/builtin/conductor/templates/code_styleguides/dart.md Normal file
View File

@@ -0,0 +1,296 @@
# 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)

29
packages/core/src/extensions/builtin/conductor/templates/code_styleguides/general.md Normal file
View File

@@ -0,0 +1,29 @@
# 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.

85
packages/core/src/extensions/builtin/conductor/templates/code_styleguides/go.md Normal file
View File

@@ -0,0 +1,85 @@
# Effective Go Style Guide Summary
This document summarizes key rules and best practices from the official
"Effective Go" guide for writing idiomatic Go code.
## 1. Formatting
- **`gofmt`:** All Go code **must** be formatted with `gofmt` (or `go fmt`).
This is a non-negotiable, automated standard.
- **Indentation:** Use tabs for indentation (`gofmt` handles this).
- **Line Length:** Go has no strict line length limit. Let `gofmt` handle line
wrapping.
## 2. Naming
- **`MixedCaps`:** Use `MixedCaps` or `mixedCaps` for multi-word names. Do not
use underscores.
- **Exported vs. Unexported:** Names starting with an uppercase letter are
exported (public). Names starting with a lowercase letter are not exported
(private).
- **Package Names:** Short, concise, single-word, lowercase names.
- **Getters:** Do not name getters with a `Get` prefix. A getter for a field
named `owner` should be named `Owner()`.
- **Interface Names:** One-method interfaces are named by the method name plus
an `-er` suffix (e.g., `Reader`, `Writer`).
## 3. Control Structures
- **`if`:** No parentheses around the condition. Braces are mandatory. Can
include an initialization statement (e.g.,
`if err := file.Chmod(0664); err != nil`).
- **`for`:** Go's only looping construct. Unifies `for` and `while`. Use
`for...range` to iterate over slices, maps, strings, and channels.
- **`switch`:** More general than in C. Cases do not fall through by default
(use `fallthrough` explicitly). Can be used without an expression to function
as a cleaner `if-else-if` chain.
## 4. Functions
- **Multiple Returns:** Functions can return multiple values. This is the
standard way to return a result and an error (e.g., `value, err`).
- **Named Result Parameters:** Return parameters can be named. This can make
code clearer and more concise.
- **`defer`:** Schedules a function call to be run immediately before the
function executing `defer` returns. Use it for cleanup tasks like closing
files.
## 5. Data
- **`new` vs. `make`:**
- `new(T)`: Allocates memory for a new item of type `T`, zeroes it, and
returns a pointer (`*T`).
- `make(T, ...)`: Creates and initializes slices, maps, and channels only.
Returns an initialized value of type `T` (not a pointer).
- **Slices:** The preferred way to work with sequences. They are more flexible
than arrays.
- **Maps:** Use the "comma ok" idiom to check for the existence of a key:
`value, ok := myMap[key]`.
## 6. Interfaces
- **Implicit Implementation:** A type implements an interface by implementing
its methods. No `implements` keyword is needed.
- **Small Interfaces:** Prefer many small interfaces over one large one. The
standard library is full of single-method interfaces (e.g., `io.Reader`).
## 7. Concurrency
- **Share Memory By Communicating:** This is the core philosophy. Do not
communicate by sharing memory; instead, share memory by communicating.
- **Goroutines:** Lightweight, concurrently executing functions. Start one with
the `go` keyword.
- **Channels:** Typed conduits for communication between goroutines. Use `make`
to create them.
## 8. Errors
- **`error` type:** The built-in `error` interface is the standard way to handle
errors.
- **Explicit Error Handling:** Do not discard errors with the blank identifier
(`_`). Check for errors explicitly.
- **`panic`:** Reserved for truly exceptional, unrecoverable situations.
Generally, libraries should not panic.
_Source: [Effective Go](https://go.dev/doc/effective_go)_

69
packages/core/src/extensions/builtin/conductor/templates/code_styleguides/html-css.md Normal file
View File

@@ -0,0 +1,69 @@
# Google HTML/CSS Style Guide Summary
This document summarizes key rules and best practices from the Google HTML/CSS
Style Guide.
## 1. General Rules
- **Protocol:** Use HTTPS for all embedded resources.
- **Indentation:** Indent by 2 spaces. Do not use tabs.
- **Capitalization:** Use only lowercase for all code (element names,
attributes, selectors, properties).
- **Trailing Whitespace:** Remove all trailing whitespace.
- **Encoding:** Use UTF-8 (without a BOM). Specify `<meta charset="utf-8">` in
HTML.
## 2. HTML Style Rules
- **Document Type:** Use `<!doctype html>`.
- **HTML Validity:** Use valid HTML.
- **Semantics:** Use HTML elements according to their intended purpose (e.g.,
use `<p>` for paragraphs, not for spacing).
- **Multimedia Fallback:** Provide `alt` text for images and
transcripts/captions for audio/video.
- **Separation of Concerns:** Strictly separate structure (HTML), presentation
(CSS), and behavior (JavaScript). Link to CSS and JS from external files.
- **`type` Attributes:** Omit `type` attributes for stylesheets (`<link>`) and
scripts (`<script>`).
## 3. HTML Formatting Rules
- **General:** Use a new line for every block, list, or table element, and
indent its children.
- **Quotation Marks:** Use double quotation marks (`""`) for attribute values.
## 4. CSS Style Rules
- **CSS Validity:** Use valid CSS.
- **Class Naming:** Use meaningful, generic names. Separate words with a hyphen
(`-`).
- **Good:** `.video-player`, `.site-navigation`
- **Bad:** `.vid`, `.red-text`
- **ID Selectors:** Avoid using ID selectors for styling. Prefer class
selectors.
- **Shorthand Properties:** Use shorthand properties where possible (e.g.,
`padding`, `font`).
- **`0` and Units:** Omit units for `0` values (e.g., `margin: 0;`).
- **Leading `0`s:** Always include leading `0`s for decimal values (e.g.,
`font-size: 0.8em;`).
- **Hexadecimal Notation:** Use 3-character hex notation where possible (e.g.,
`#fff`).
- **`!important`:** Avoid using `!important`.
## 5. CSS Formatting Rules
- **Declaration Order:** Alphabetize declarations within a rule.
- **Indentation:** Indent all block content.
- **Semicolons:** Use a semicolon after every declaration.
- **Spacing:**
- Use a space after a property name's colon (`font-weight: bold;`).
- Use a space between the last selector and the opening brace (`.foo {`).
- Start a new line for each selector and declaration.
- **Rule Separation:** Separate rules with a new line.
- **Quotation Marks:** Use single quotes (`''`) for attribute selectors and
property values (e.g., `[type='text']`).
**BE CONSISTENT.** When editing code, match the existing style.
_Source:
[Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.html)_

74
packages/core/src/extensions/builtin/conductor/templates/code_styleguides/javascript.md Normal file
View File

@@ -0,0 +1,74 @@
# Google JavaScript Style Guide Summary
This document summarizes key rules and best practices from the Google JavaScript
Style Guide.
## 1. Source File Basics
- **File Naming:** All lowercase, with underscores (`_`) or dashes (`-`).
Extension must be `.js`.
- **File Encoding:** UTF-8.
- **Whitespace:** Use only ASCII horizontal spaces (0x20). Tabs are forbidden
for indentation.
## 2. Source File Structure
- New files should be ES modules (`import`/`export`).
- **Exports:** Use named exports (`export {MyClass};`). **Do not use default
exports.**
- **Imports:** Do not use line-wrapped imports. The `.js` extension in import
paths is mandatory.
## 3. Formatting
- **Braces:** Required for all control structures (`if`, `for`, `while`, etc.),
even single-line blocks. Use K&R style ("Egyptian brackets").
- **Indentation:** +2 spaces for each new block.
- **Semicolons:** Every statement must be terminated with a semicolon.
- **Column Limit:** 80 characters.
- **Line-wrapping:** Indent continuation lines at least +4 spaces.
- **Whitespace:** Use single blank lines between methods. No trailing
whitespace.
## 4. Language Features
- **Variable Declarations:** Use `const` by default, `let` if reassignment is
needed. **`var` is forbidden.**
- **Array Literals:** Use trailing commas. Do not use the `Array` constructor.
- **Object Literals:** Use trailing commas and shorthand properties. Do not use
the `Object` constructor.
- **Classes:** Do not use JavaScript getter/setter properties (`get name()`).
Provide ordinary methods instead.
- **Functions:** Prefer arrow functions for nested functions to preserve `this`
context.
- **String Literals:** Use single quotes (`'`). Use template literals (`` ` ``)
for multi-line strings or complex interpolation.
- **Control Structures:** Prefer `for-of` loops. `for-in` loops should only be
used on dict-style objects.
- **`this`:** Only use `this` in class constructors, methods, or in arrow
functions defined within them.
- **Equality Checks:** Always use identity operators (`===` / `!==`).
## 5. Disallowed Features
- `with` keyword.
- `eval()` or `Function(...string)`.
- Automatic Semicolon Insertion.
- Modifying builtin objects (`Array.prototype.foo = ...`).
## 6. Naming
- **Classes:** `UpperCamelCase`.
- **Methods & Functions:** `lowerCamelCase`.
- **Constants:** `CONSTANT_CASE` (all uppercase with underscores).
- **Non-constant Fields & Variables:** `lowerCamelCase`.
## 7. JSDoc
- JSDoc is used on all classes, fields, and methods.
- Use `@param`, `@return`, `@override`, `@deprecated`.
- Type annotations are enclosed in braces (e.g.,
`/** @param {string} userName */`).
_Source:
[Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)_

57
packages/core/src/extensions/builtin/conductor/templates/code_styleguides/python.md Normal file
View File

@@ -0,0 +1,57 @@
# Google Python Style Guide Summary
This document summarizes key rules and best practices from the Google Python
Style Guide.
## 1. Python Language Rules
- **Linting:** Run `pylint` on your code to catch bugs and style issues.
- **Imports:** Use `import x` for packages/modules. Use `from x import y` only
when `y` is a submodule.
- **Exceptions:** Use built-in exception classes. Do not use bare `except:`
clauses.
- **Global State:** Avoid mutable global state. Module-level constants are okay
and should be `ALL_CAPS_WITH_UNDERSCORES`.
- **Comprehensions:** Use for simple cases. Avoid for complex logic where a full
loop is more readable.
- **Default Argument Values:** Do not use mutable objects (like `[]` or `{}`) as
default values.
- **True/False Evaluations:** Use implicit false (e.g., `if not my_list:`). Use
`if foo is None:` to check for `None`.
- **Type Annotations:** Strongly encouraged for all public APIs.
## 2. Python Style Rules
- **Line Length:** Maximum 80 characters.
- **Indentation:** 4 spaces per indentation level. Never use tabs.
- **Blank Lines:** Two blank lines between top-level definitions (classes,
functions). One blank line between method definitions.
- **Whitespace:** Avoid extraneous whitespace. Surround binary operators with
single spaces.
- **Docstrings:** Use `"""triple double quotes"""`. Every public module,
function, class, and method must have a docstring.
- **Format:** Start with a one-line summary. Include `Args:`, `Returns:`, and
`Raises:` sections.
- **Strings:** Use f-strings for formatting. Be consistent with single (`'`) or
double (`"`) quotes.
- **`TODO` Comments:** Use `TODO(username): Fix this.` format.
- **Imports Formatting:** Imports should be on separate lines and grouped:
standard library, third-party, and your own application's imports.
## 3. Naming
- **General:** `snake_case` for modules, functions, methods, and variables.
- **Classes:** `PascalCase`.
- **Constants:** `ALL_CAPS_WITH_UNDERSCORES`.
- **Internal Use:** Use a single leading underscore (`_internal_variable`) for
internal module/class members.
## 4. Main
- All executable files should have a `main()` function that contains the main
logic, called from a `if __name__ == '__main__':` block.
**BE CONSISTENT.** When editing code, match the existing style.
_Source:
[Google Python Style Guide](https://google.github.io/styleguide/pyguide.html)_

69
packages/core/src/extensions/builtin/conductor/templates/code_styleguides/typescript.md Normal file
View File

@@ -0,0 +1,69 @@
# Google TypeScript Style Guide Summary
This document summarizes key rules and best practices from the Google TypeScript
Style Guide, which is enforced by the `gts` tool.
## 1. Language Features
- **Variable Declarations:** Always use `const` or `let`. **`var` is
forbidden.** Use `const` by default.
- **Modules:** Use ES6 modules (`import`/`export`). **Do not use `namespace`.**
- **Exports:** Use named exports (`export {MyClass};`). **Do not use default
exports.**
- **Classes:**
- **Do not use `#private` fields.** Use TypeScript's `private` visibility
modifier.
- Mark properties never reassigned outside the constructor with `readonly`.
- **Never use the `public` modifier** (it's the default). Restrict visibility
with `private` or `protected` where possible.
- **Functions:** Prefer function declarations for named functions. Use arrow
functions for anonymous functions/callbacks.
- **String Literals:** Use single quotes (`'`). Use template literals (`` ` ``)
for interpolation and multi-line strings.
- **Equality Checks:** Always use triple equals (`===`) and not equals (`!==`).
- **Type Assertions:** **Avoid type assertions (`x as SomeType`) and
non-nullability assertions (`y!`)**. If you must use them, provide a clear
justification.
## 2. Disallowed Features
- **`any` Type:** **Avoid `any`**. Prefer `unknown` or a more specific type.
- **Wrapper Objects:** Do not instantiate `String`, `Boolean`, or `Number`
wrapper classes.
- **Automatic Semicolon Insertion (ASI):** Do not rely on it. **Explicitly end
all statements with a semicolon.**
- **`const enum`:** Do not use `const enum`. Use plain `enum` instead.
- **`eval()` and `Function(...string)`:** Forbidden.
## 3. Naming
- **`UpperCamelCase`:** For classes, interfaces, types, enums, and decorators.
- **`lowerCamelCase`:** For variables, parameters, functions, methods, and
properties.
- **`CONSTANT_CASE`:** For global constant values, including enum values.
- **`_` Prefix/Suffix:** **Do not use `_` as a prefix or suffix** for
identifiers, including for private properties.
## 4. Type System
- **Type Inference:** Rely on type inference for simple, obvious types. Be
explicit for complex types.
- **`undefined` and `null`:** Both are supported. Be consistent within your
project.
- **Optional vs. `|undefined`:** Prefer optional parameters and fields (`?`)
over adding `|undefined` to the type.
- **`Array<T>` Type:** Use `T[]` for simple types. Use `Array<T>` for more
complex union types (e.g., `Array<string | number>`).
- **`{}` Type:** **Do not use `{}`**. Prefer `unknown`,
`Record<string, unknown>`, or `object`.
## 5. Comments and Documentation
- **JSDoc:** Use `/** JSDoc */` for documentation, `//` for implementation
comments.
- **Redundancy:** **Do not declare types in `@param` or `@return` blocks**
(e.g., `/** @param {string} user */`). This is redundant in TypeScript.
- **Add Information:** Comments must add information, not just restate the code.
_Source:
[Google TypeScript Style Guide](https://google.github.io/styleguide/tsguide.html)_

415
packages/core/src/extensions/builtin/conductor/templates/workflow.md Normal file
View File

@@ -0,0 +1,415 @@
# Project Workflow
## Guiding Principles
1. **The Plan is the Source of Truth:** All work must be tracked in `plan.md`
2. **The Tech Stack is Deliberate:** Changes to the tech stack must be
documented in `tech-stack.md` _before_ implementation
3. **Test-Driven Development:** Write unit tests before implementing
functionality
4. **High Code Coverage:** Aim for >80% code coverage for all modules
5. **User Experience First:** Every decision should prioritize user experience
6. **Non-Interactive & CI-Aware:** Prefer non-interactive commands. Use
`CI=true` for watch-mode tools (tests, linters) to ensure single execution.
## Task Workflow
All tasks follow a strict lifecycle:
### Standard Task Workflow
1. **Select Task:** Choose the next available task from `plan.md` in sequential
order
2. **Mark In Progress:** Before beginning work, edit `plan.md` and change the
task from `[ ]` to `[~]`
3. **Write Failing Tests (Red Phase):**
- Create a new test file for the feature or bug fix.
- Write one or more unit tests that clearly define the expected behavior and
acceptance criteria for the task.
- **CRITICAL:** Run the tests and confirm that they fail as expected. This is
the "Red" phase of TDD. Do not proceed until you have failing tests.
4. **Implement to Pass Tests (Green Phase):**
- Write the minimum amount of application code necessary to make the failing
tests pass.
- Run the test suite again and confirm that all tests now pass. This is the
"Green" phase.
5. **Refactor (Optional but Recommended):**
- With the safety of passing tests, refactor the implementation code and the
test code to improve clarity, remove duplication, and enhance performance
without changing the external behavior.
- Rerun tests to ensure they still pass after refactoring.
6. **Verify Coverage:** Run coverage reports using the project's chosen tools.
For example, in a Python project, this might look like:
```bash
pytest --cov=app --cov-report=html
```
Target: >80% coverage for new code. The specific tools and commands will vary
by language and framework.
7. **Document Deviations:** If implementation differs from tech stack:
- **STOP** implementation
- Update `tech-stack.md` with new design
- Add dated note explaining the change
- Resume implementation
8. **Commit Code Changes:**
- Stage all code changes related to the task.
- Propose a clear, concise commit message e.g,
`feat(ui): Create basic HTML structure for calculator`.
- Perform the commit.
9. **Attach Task Summary with Git Notes:**
- **Step 9.1: Get Commit Hash:** Obtain the hash of the _just-completed
commit_ (`git log -1 --format="%H"`).
- **Step 9.2: Draft Note Content:** Create a detailed summary for the
completed task. This should include the task name, a summary of changes, a
list of all created/modified files, and the core "why" for the change.
- **Step 9.3: Attach Note:** Use the `git notes` command to attach the
summary to the commit.
```bash
# The note content from the previous step is passed via the -m flag.
git notes add -m "<note content>" <commit_hash>
```
10. **Get and Record Task Commit SHA:**
- **Step 10.1: Update Plan:** Read `plan.md`, find the line for the
completed task, update its status from `[~]` to `[x]`, and append the
first 7 characters of the _just-completed commit's_ commit hash.
- **Step 10.2: Write Plan:** Write the updated content back to `plan.md`.
11. **Commit Plan Update:**
- **Action:** Stage the modified `plan.md` file.
- **Action:** Commit this change with a descriptive message (e.g.,
`conductor(plan): Mark task 'Create user model' as complete`).
### Phase Completion Verification and Checkpointing Protocol
**Trigger:** This protocol is executed immediately after a task is completed
that also concludes a phase in `plan.md`.
1. **Announce Protocol Start:** Inform the user that the phase is complete and
the verification and checkpointing protocol has begun.
2. **Ensure Test Coverage for Phase Changes:**
- **Step 2.1: Determine Phase Scope:** To identify the files changed in this
phase, you must first find the starting point. Read `plan.md` to find the
Git commit SHA of the _previous_ phase's checkpoint. If no previous
checkpoint exists, the scope is all changes since the first commit.
- **Step 2.2: List Changed Files:** Execute
`git diff --name-only <previous_checkpoint_sha> HEAD` to get a precise
list of all files modified during this phase.
- **Step 2.3: Verify and Create Tests:** For each file in the list:
- **CRITICAL:** First, check its extension. Exclude non-code files (e.g.,
`.json`, `.md`, `.yaml`).
- For each remaining code file, verify a corresponding test file exists.
- If a test file is missing, you **must** create one. Before writing the
test, **first, analyze other test files in the repository to determine
the correct naming convention and testing style.** The new tests
**must** validate the functionality described in this phase's tasks
(`plan.md`).
3. **Execute Automated Tests with Proactive Debugging:**
- Before execution, you **must** announce the exact shell command you will
use to run the tests.
- **Example Announcement:** "I will now run the automated test suite to
verify the phase. **Command:** `CI=true npm test`"
- Execute the announced command.
- If tests fail, you **must** inform the user and begin debugging. You may
attempt to propose a fix a **maximum of two times**. If the tests still
fail after your second proposed fix, you **must stop**, report the
persistent failure, and ask the user for guidance.
4. **Propose a Detailed, Actionable Manual Verification Plan:**
- **CRITICAL:** To generate the plan, first analyze `product.md`,
`product-guidelines.md`, and `plan.md` to determine the user-facing goals
of the completed phase.
- You **must** generate a step-by-step plan that walks the user through the
verification process, including any necessary commands and specific,
expected outcomes.
- The plan you present to the user **must** follow this format:
**For a Frontend Change:**
```
The automated tests have passed. For manual verification, please follow these steps:
**Manual Verification Steps:**
1. **Start the development server with the command:** `npm run dev`
2. **Open your browser to:** `http://localhost:3000`
3. **Confirm that you see:** The new user profile page, with the user's name and email displayed correctly.
```
**For a Backend Change:**
```
The automated tests have passed. For manual verification, please follow these steps:
**Manual Verification Steps:**
1. **Ensure the server is running.**
2. **Execute the following command in your terminal:** `curl -X POST http://localhost:8080/api/v1/users -d '{"name": "test"}'`
3. **Confirm that you receive:** A JSON response with a status of `201 Created`.
```
5. **Await Explicit User Feedback:**
- After presenting the detailed plan, ask the user for confirmation: "**Does
this meet your expectations? Please confirm with yes or provide feedback
on what needs to be changed.**"
- **PAUSE** and await the user's response. Do not proceed without an
explicit yes or confirmation.
6. **Create Checkpoint Commit:**
- Stage all changes. If no changes occurred in this step, proceed with an
empty commit.
- Perform the commit with a clear and concise message (e.g.,
`conductor(checkpoint): Checkpoint end of Phase X`).
7. **Attach Auditable Verification Report using Git Notes:**
- **Step 7.1: Draft Note Content:** Create a detailed verification report
including the automated test command, the manual verification steps, and
the user's confirmation.
- **Step 7.2: Attach Note:** Use the `git notes` command and the full commit
hash from the previous step to attach the full report to the checkpoint
commit.
8. **Get and Record Phase Checkpoint SHA:**
- **Step 8.1: Get Commit Hash:** Obtain the hash of the _just-created
checkpoint commit_ (`git log -1 --format="%H"`).
- **Step 8.2: Update Plan:** Read `plan.md`, find the heading for the
completed phase, and append the first 7 characters of the commit hash in
the format `[checkpoint: <sha>]`.
- **Step 8.3: Write Plan:** Write the updated content back to `plan.md`.
9. **Commit Plan Update:**
- **Action:** Stage the modified `plan.md` file.
- **Action:** Commit this change with a descriptive message following the
format `conductor(plan): Mark phase '<PHASE NAME>' as complete`.
10. **Announce Completion:** Inform the user that the phase is complete and the
checkpoint has been created, with the detailed verification report attached
as a git note.
### Quality Gates
Before marking any task complete, verify:
- [ ] All tests pass
- [ ] Code coverage meets requirements (>80%)
- [ ] Code follows project's code style guidelines (as defined in
`code_styleguides/`)
- [ ] All public functions/methods are documented (e.g., docstrings, JSDoc,
GoDoc)
- [ ] Type safety is enforced (e.g., type hints, TypeScript types, Go types)
- [ ] No linting or static analysis errors (using the project's configured
tools)
- [ ] Works correctly on mobile (if applicable)
- [ ] Documentation updated if needed
- [ ] No security vulnerabilities introduced
## Development Commands
**AI AGENT INSTRUCTION: This section should be adapted to the project's specific
language, framework, and build tools.**
### Setup
```bash
# Example: Commands to set up the development environment (e.g., install dependencies, configure database)
# e.g., for a Node.js project: npm install
# e.g., for a Go project: go mod tidy
```
### Daily Development
```bash
# Example: Commands for common daily tasks (e.g., start dev server, run tests, lint, format)
# e.g., for a Node.js project: npm run dev, npm test, npm run lint
# e.g., for a Go project: go run main.go, go test ./..., go fmt ./...
```
### Before Committing
```bash
# Example: Commands to run all pre-commit checks (e.g., format, lint, type check, run tests)
# e.g., for a Node.js project: npm run check
# e.g., for a Go project: make check (if a Makefile exists)
```
## Testing Requirements
### Unit Testing
- Every module must have corresponding tests.
- Use appropriate test setup/teardown mechanisms (e.g., fixtures,
beforeEach/afterEach).
- Mock external dependencies.
- Test both success and failure cases.
### Integration Testing
- Test complete user flows
- Verify database transactions
- Test authentication and authorization
- Check form submissions
### Mobile Testing
- Test on actual iPhone when possible
- Use Safari developer tools
- Test touch interactions
- Verify responsive layouts
- Check performance on 3G/4G
## Code Review Process
### Self-Review Checklist
Before requesting review:
1. **Functionality**
- Feature works as specified
- Edge cases handled
- Error messages are user-friendly
2. **Code Quality**
- Follows style guide
- DRY principle applied
- Clear variable/function names
- Appropriate comments
3. **Testing**
- Unit tests comprehensive
- Integration tests pass
- Coverage adequate (>80%)
4. **Security**
- No hardcoded secrets
- Input validation present
- SQL injection prevented
- XSS protection in place
5. **Performance**
- Database queries optimized
- Images optimized
- Caching implemented where needed
6. **Mobile Experience**
- Touch targets adequate (44x44px)
- Text readable without zooming
- Performance acceptable on mobile
- Interactions feel native
## Commit Guidelines
### Message Format
```
<type>(<scope>): <description>
[optional body]
[optional footer]
```
### Types
- `feat`: New feature
- `fix`: Bug fix
- `docs`: Documentation only
- `style`: Formatting, missing semicolons, etc.
- `refactor`: Code change that neither fixes a bug nor adds a feature
- `test`: Adding missing tests
- `chore`: Maintenance tasks
### Examples
```bash
git commit -m "feat(auth): Add remember me functionality"
git commit -m "fix(posts): Correct excerpt generation for short posts"
git commit -m "test(comments): Add tests for emoji reaction limits"
git commit -m "style(mobile): Improve button touch targets"
```
## Definition of Done
A task is complete when:
1. All code implemented to specification
2. Unit tests written and passing
3. Code coverage meets project requirements
4. Documentation complete (if applicable)
5. Code passes all configured linting and static analysis checks
6. Works beautifully on mobile (if applicable)
7. Implementation notes added to `plan.md`
8. Changes committed with proper message
9. Git note with task summary attached to the commit
## Emergency Procedures
### Critical Bug in Production
1. Create hotfix branch from main
2. Write failing test for bug
3. Implement minimal fix
4. Test thoroughly including mobile
5. Deploy immediately
6. Document in plan.md
### Data Loss
1. Stop all write operations
2. Restore from latest backup
3. Verify data integrity
4. Document incident
5. Update backup procedures
### Security Breach
1. Rotate all secrets immediately
2. Review access logs
3. Patch vulnerability
4. Notify affected users (if any)
5. Document and update security procedures
## Deployment Workflow
### Pre-Deployment Checklist
- [ ] All tests passing
- [ ] Coverage >80%
- [ ] No linting errors
- [ ] Mobile testing complete
- [ ] Environment variables configured
- [ ] Database migrations ready
- [ ] Backup created
### Deployment Steps
1. Merge feature branch to main
2. Tag release with version
3. Push to deployment service
4. Run database migrations
5. Verify deployment
6. Test critical paths
7. Monitor for errors
### Post-Deployment
1. Monitor analytics
2. Check error logs
3. Gather user feedback
4. Plan next iteration
## Continuous Improvement
- Review workflow weekly
- Update based on pain points
- Document lessons learned
- Optimize for user happiness
- Keep things simple and maintainable