Conductor Spec-Driven Development Plugin

The Conductor repository is organized into two primary directories:

• /skills: Contains the protocol logic defined in SKILL.md files for each command.
• /rules: Contains platform-specific operational rules files.

Guidelines for class and struct design:

• Constructors: Use explicit for single-argument constructors and conversion operators (except std::initializer_list). Do not make virtual calls in constructors. Use factories for fallible initialization.
• Structs: Use only for passive data. Prefer struct over std::pair or std::tuple.
• Rule of 5: If you define one of the special member functions (copy/move), you must declare all of them. Use = default or = delete explicitly.
• Inheritance: Use public inheritance only. Prefer composition over inheritance. Use the override keyword (and omit virtual).
• Operator Overloading: Use judiciously. Binary operators should be non-members. Never overload &&, ||, ,, or unary &.

After a review is completed, the system provides a recommendation based on the severity of findings. If issues are found, you can choose how to proceed via a multiple-choice selection:

• Apply Fixes: Automatically applies suggested code changes using file editing tools.
• Manual Fix: Terminates the operation so you can edit the code yourself.
• Complete Track: Ignores warnings and proceeds to the next step.

If no issues are found, the process proceeds directly to the next step.

Maintain a clean import structure by following this order:

1. dart: imports first.
2. package: imports second.
3. Relative imports last.
4. Specify exports in a separate section after all imports.
5. Sort all sections alphabetically.

Library boundaries:

• Do not import libraries located inside the src directory of another package.
• Do not allow import paths to reach into or out of lib.
• Use relative import paths when not crossing the lib boundary.

Use /// for doc comments to document members and types.

Guidelines:

• Start with a single-sentence summary, separated into its own paragraph.
• Use square brackets [] to refer to in-scope identifiers (e.g., [StateError], [anotherMethod()]).
• Use prose to explain parameters, return values, and exceptions.
• Place doc comments before metadata annotations.
• For functions/methods with side effects, start with a third-person verb (e.g., "Connects to...").
• For non-boolean properties, start with a noun phrase (e.g., "The current day...").
• For boolean properties, start with "Whether" (e.g., "Whether the modal is...").
• For functions returning a value, use a noun phrase or non-imperative verb phrase.
• Avoid redundancy (e.g., don't repeat the class name in its doc comment).
• Consider including code samples using triple backticks.

Use the following standards for documentation:

• Format: Use /** JSDoc */ for documentation and // for implementation comments.
• Avoid Redundancy: Do not include types in @param or @return blocks (e.g., avoid /** @param {string} user */), as this is redundant in TypeScript.
• Content: Comments must provide new information rather than simply restating the code.

When implementing a track, the skill follows a strict lifecycle of status updates and commits:

1. Start: Updates track status to [~] (In Progress) in conductor/tracks.md.
   • Commit message: chore(conductor): Mark track '<track_description>' as in progress
2. Execution: Executes tasks from the track's Implementation Plan using the Workflow document as the source of truth.
3. Finish: Updates track status to [x] (Complete) in conductor/tracks.md.
   • Commit message: chore(conductor): Mark track '<track_description>' as complete

Once a track review is finished, you can manage the track's lifecycle using a multiple-choice selection:

• Archive: Moves the track folder to conductor/archive/<track_id>/ and removes it from the Tracks Registry. Commits with chore(conductor): Archive track '<track_name>'.
• Delete: Permanently deletes the track folder and removes it from the Tracks Registry. Requires a final Yes/No confirmation. Commits with chore(conductor): Delete track '<track_name>'.
• Skip: Leaves the track unchanged in the Tracks Registry.

The conductor-revert skill is a Git-aware AI assistant designed to revert logical units of work (Tracks, Phases, or Tasks) tracked by the Conductor framework. It identifies the associated Git commits for a specific piece of work and provides a structured way to undo them using either a safe git revert or a destructive git reset --hard strategy.

How to trigger a revert

You can initiate a revert in two ways:

1. Direct Target: Provide a specific target as an argument to skip the menu. Example: /conductor:revert track <track_id>

2. Guided Selection (Default): If no target is provided, the skill will scan your conductor/tracks.md (Tracks Registry) and all plan.md files to present a hierarchical menu of candidates. It prioritizes:

   • The top 3 in-progress items ([~]).
   • The 3 most recently completed items ([x]) if no in-progress items exist.

The following features are strictly prohibited or strongly discouraged:

• any Type: Avoid any. Use unknown or a specific type instead.
• Wrapper Objects: Do not use String, Boolean, or Number wrapper classes.
• Semicolons: Do not rely on Automatic Semicolon Insertion (ASI). Explicitly end all statements with a semicolon.
• Enums: Do not use const enum. Use plain enum instead.
• Dynamic Execution: eval() and Function(...string) are forbidden.

Use the following rules for naming identifiers in Go:

• Multi-word names: Use MixedCaps or mixedCaps. Do not use underscores.
• Visibility: Names starting with an uppercase letter are exported (public); lowercase names are unexported (private).
• Package names: Use short, concise, single-word, lowercase names.
• Getters: Do not use a Get prefix. For a field owner, the getter should be Owner().
• Interface names: For one-method interfaces, append an -er suffix to the method name (e.g., Reader, Writer).