@m-velikov/cpp-quick-start-mcp 0.1.0

package/data/meta-quickstart/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: meta-quickstart
+description: Interviews the user about their preferred C++ stack and generates the specific project scaffolding skills.
+---
+
+# Meta-Scaffold Skill
+
+This is a Level 2 "Meta-Skill". Its purpose is not to write C++ code directly, but to generate the _actual_ scaffolding skills (e.g., `scaffold-project`, `build-project`) tailored to the user's specific tooling choices.
+
+## Workflow
+
+When invoked, follow these steps exactly:
+
+### Step 1: Pre-flight Project Scan
+
+Before doing anything, YOU MUST list the contents of the current working directory to determine if it is empty or already contains a project (e.g., presence of `CMakeLists.txt`, `src/`, `Makefile`, etc.).
+
+If the directory is essentially **EMPTY**, proceed to **Mode A: New Project Interview**.
+If the directory **CONTAINS AN EXISTING PROJECT**, proceed to **Mode B: Add Components**.
+
+---
+
+### Mode A: New Project Interview
+
+Ask the user to select their preferences for the following categories.
+**CRITICAL**: You MUST use your interactive multiple-choice question tool (e.g., `ask_question`) to present these questions to the user in a strict multiple-choice format. Always ensure the user has a free-form text input option to provide custom answers (write-ins).
+
+1. **C++ Standard Version**: (e.g., C++11, C++14, C++17, C++20, C++23)
+2. **Build System**: (e.g., CMake, Bazel, Meson, Makefiles)
+3. **Dependency Management**: (e.g., FetchContent, vcpkg, Conan, system packages)
+   - **CRITICAL**: Do NOT ask contradicting questions. Adapt your questions dynamically based on previous answers. For example, if the user chooses Conan for Dependency Management, do NOT ask them about vcpkg for Project Packaging in the next question unless they explicitly request both.
+4. **Project Packaging**: (e.g., Conan conanfile.py, vcpkg manifest, None)
+5. **Testing Framework**: (e.g., GTest, Catch2, doctest, Boost.Test)
+6. **Code Quality**: (e.g., clang-tidy, pre-commit hooks, custom build targets)
+7. **CI Provider**: (e.g., GitHub Actions, GitLab CI, None)
+8. **Coding Style**: (e.g., Google, LLVM, Mozilla, WebKit, Custom)
+9. **Target Platforms**: (e.g., Desktop vs. Mobile, Windows vs Linux, Android vs macOS).
+10. **Directory Layout**: (e.g., Standard Pitchfork [src/, include/, tests/], Flat Layout, or Custom). **CRITICAL**: Suggest Pitchfork directory layout based on the user's answers for Target Platforms.
+11. **Naming Conventions**: Preferred standards for types, values, namespaces, file names, and file extensions (e.g., `.cpp`/`.hpp` vs `.cc`/`.h`).
+12. **Libraries and Tools**: explicitly ask the user: "What libraries or executable tools do you want to build in this project?"
+
+- **CRITICAL**: You must prompt the user repeatedly (e.g., "Are there any other libraries or tools?") until the user explicitly says "no more targets for now".
+
+Wait for the user's responses. Only proceed to **Step 2 (Implementation Plan)** when all 12 questions are answered AND the user indicates they have no more targets to add.
+
+---
+
+### Mode B: Existing Project (Add Components or Modernize)
+
+If the project already exists, **DO NOT** conduct the full Mode A interview.
+
+1. **Convention Scanning**: You MUST read the existing build files (e.g., `CMakeLists.txt`, `Makefile`) and a few source files to automatically infer the build system, package manager, directory layout, naming conventions, and code formatting style. Auto-detect whatever is possible.
+2. **Path Selection**: Ask the user: _"I see this is an existing project. Would you like to **1. Add new components** (libraries/executables), or **2. Modernize the codebase and augment it for agentic development**?"_
+
+**If the user chooses Path 1 (Add Components):** 3. **Component Interview**: Ask the user what new components to add, prompting repeatedly until they say "no more targets for now". 4. **Target Platforms**: Ask about support for major target platforms (e.g., Desktop vs. Mobile, Windows vs Linux, Android vs macOS). 5. **Layout Conformity Check**: Evaluate if adding these new components causes the project to violate its inferred directory layout conventions.
+
+- If it violates conventions or if the target platforms suggest a more robust layout, suggest a layout refactoring (e.g., migrating to Pitchfork layout).
+
+6. Proceed to **Step 2 (Implementation Plan)**.
+
+**If the user chooses Path 2 (Modernize & Augment):** 3. **Missing Tooling Interview**: Based on the auto-detected conventions, identify missing modern tooling (e.g., `.clang-format`, `.clang-tidy`, `.pre-commit-config.yaml`, testing frameworks, CI/CD). Ask the user which of these missing tools they would like to integrate. 4. **Build System Evaluation**: Evaluate the existing build system. Do NOT suggest migrating it to a completely different build system (e.g., do not migrate Makefiles to CMake). Instead, suggest improvements for the existing build system (e.g., modernizing legacy CMake to target-based CMake, or optimizing Makefiles). 5. **Target Platforms**: Ask the user about support for major target platforms (e.g., Desktop vs. Mobile, Windows vs Linux, Android vs macOS). Suggest migrating to the Pitchfork directory layout based on their answers if the current layout is insufficient. 6. Proceed to **Step 2 (Implementation Plan)**.
+
+---
+
+### Step 2: Implementation Plan
+
+Based on the chosen Mode and the user's answers, create a formal implementation plan.
+
+**If you are in Mode A (New Project):**
+Your plan must outline the exact file templates and commands needed to bootstrap the cross-platform C++ project using the chosen stack.
+
+- Prefer splitting build system files per artifact (e.g., using `add_subdirectory` or `subdir()`) instead of creating a single top-level monolithic build file.
+- Explicitly plan to run `git init` in the project directory if a Git repository is not already initialized, and to create or rename the initial branch to `main` (e.g. `git branch -M main`).
+- Plan to generate a fresh `README.md` specifically describing the user's new C++ project. This `README.md` MUST include a `## Configure and Build` section containing the exact CLI commands required to configure and build the project based on the user's chosen stack (e.g., `cmake -B build -S .` or `conan install . --build=missing`).
+- Plan to read the `scaffold-agents` skill from the MCP knowledge base and use it to generate an `AGENTS.md` file in the user's project root.
+
+**If you are in Mode B (Existing Project - Add Components):**
+Your plan must detail how you will create the new target folders adhering strictly to the inferred layout conventions, and how you will safely _append_ the new targets to the existing build files (do NOT overwrite existing files).
+If a layout refactoring was agreed upon, include that in the plan before adding the new components.
+
+**If you are in Mode B (Existing Project - Modernize):**
+Your plan must include:
+
+- Generating an `AGENTS.md` file using the `scaffold-agents` skill.
+- Safely introducing the requested code quality tools (e.g., `.clang-format`, `.clang-tidy`).
+- Applying the agreed-upon build system improvements directly to the existing build files.
+- Implementing any layout refactoring if agreed upon.
+
+**Workspace Skills Generation (All Modes)**:
+In ALL plans, you must include the creation of customized permanent workspace SKILL files. These must be written directly into the project's workspace using an agent-agnostic directory like `.agents/skills/` or `skills/` so that any AI working in the project immediately knows how to operate it. **CRITICAL**: Do NOT use agent-specific directories like `.gemini` or `.claude`.
+The workspace skills to create are:
+
+1. `skills/configure-project/SKILL.md`: Exact instructions and CLI commands for fetching dependencies, installing them, and configuring the project (e.g., `conan install` or `vcpkg install` followed by `cmake -B build`).
+2. `skills/build-project/SKILL.md`: Exact instructions and CLI commands for building the project (e.g., `cmake --build build -j`).
+3. **Component Best Practices**: For each of the components and tools used in the project (e.g., CMake, vcpkg, GTest), create a dedicated skill containing best practices and usage instructions tailored to this specific project.
+4. **Refactoring Best Practices**: Create a skill (e.g., `skills/best-practices-refactoring/SKILL.md`) detailing how to safely refactor code within the project's layout and test constraints.
+5. **Code Review Best Practices**: Create a skill (e.g., `skills/best-practices-code-review/SKILL.md`) containing guidelines for reviewing code to ensure compliance with the project's chosen formatting, style, and CI requirements.
+6. **C++ Core Guidelines Best Practices**: Create a skill (e.g., `skills/best-practices-cpp/SKILL.md`) establishing fundamental C++ guidelines based on the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md).
+
+Wait for the user's explicit approval on the implementation plan before proceeding to Execution.
+
+### Step 3: Execution
+
+Once the user approves the implementation plan, proceed to directly execute it. Implement the code, initialize git, create the workspace skills, and verify the build as outlined in your plan.

package/data/scaffold-agents/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: scaffold-agents
+description: Instructs the AI on the multi-agent topology to use for complex C++ projects.
+---
+
+# Agent Topology Skill
+
+This skill defines how AI agents should coordinate when working on this C++ project.
+
+## Guidelines
+
+Embed the following guidelines into an `AGENTS.md` file in the project root so other agents understand the architecture.
+
+### `AGENTS.md`
+
+```markdown
+# Agent Configuration and Guidelines
+
+You are an AI assistant operating within a C++ Agentic template repository. Your behavior must adhere to the following directives.
+
+## Agent Topology & Roles
+
+This repository is designed to be operated by a multi-agent system. When working on larger tasks, define and invoke the following specialized subagents to distribute the workload:
+
+1. **Lead Orchestrator Agent (You)**:
+
+   - **Role**: High-level planning, user communication, and task delegation.
+   - **Responsibilities**: Breaks down user requests into tasks and delegates them to specialized subagents using the `invoke_subagent` and `send_message` tools.
+
+2. **C++ Coder Agent**:
+
+   - **Role**: Core implementation and logic design.
+   - **Responsibilities**: Writes the actual C++ headers and source files. Enforces the configured coding style and ensures code compiles flawlessly with the configured C++ standard.
+
+3. **QA / Tester Agent**:
+
+   - **Role**: Quality assurance and test coverage.
+   - **Responsibilities**: Writes test cases using the configured testing framework. Continuously runs the configured test command to verify correctness and reports back to the Lead Agent.
+
+4. **Build System Agent**:
+   - **Role**: Managing build configurations and cross-platform support.
+   - **Responsibilities**: Updates the project's build system files, manages dependencies according to the configured package manager, and ensures cross-platform settings (like export macros) are correctly maintained.
+
+## Code Style & Tooling
+
+Once the project is scaffolded, enforce the following:
+
+- Follow the coding style configured in `.clang-format`. (Note: Choosing a Google or LLVM coding style does NOT override naming conventions; the user's explicit naming convention decisions always take precedence.)
+- Ensure all C++ files use LF line endings (as per `.gitattributes`).
+- Never commit code that fails `.clang-tidy` checks.
+
+## Naming Conventions
+
+- Adhere strictly to the naming conventions established in the project (e.g., camelCase vs snake_case, file extensions like `.cpp` vs `.cc`).
+- **CRITICAL RULE**: You may ONLY deviate from the established naming convention if absolutely required by a project dependency (for example, if a specific testing framework explicitly insists that test files must end in `_test`).
+
+## Build System & Testing
+
+- Adhere strictly to the project's configured build system and testing framework.
+- Use the local workspace skills (e.g., `build-project` and `test-project`) to compile and test the code.
+- Do not write custom shell scripts for building unless explicitly instructed to do so by the user's stack configuration.
+- **Out-of-Source Builds**: A build process must not modify the source directory. The source directory can be modified by the user and agents, but not by build scripts. A `build` or similar subdirectory in the source tree is allowed for this purpose. When you identify a directory serving this purpose, check if it is present in `.gitignore` and add it if missing (subject to follow-up user review). If modification to the source directory by build scripts appears unavoidable, ask the user for an exception. Try to limit the affected source files (for example, allow just for a few machine-generated files that are infrequently updated).
+
+## Security & Privacy
+
+- **NEVER** upload anything on the internet to prevent IP, trade secret, or other leaks.
+- This rule is absolute unless under explicit instructions from the developer, in which case an implementation plan is mandatory.
+```

package/data/scaffold-base-configs/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: scaffold-base-configs
+description: Generates essential base repository files like .gitignore and .gitattributes.
+---
+
+# Base Configurations Skill
+
+This skill provides the standard foundational files for any new C++ repository.
+
+## Instructions
+
+Always generate these files at the root of the project to ensure proper Git behavior.
+
+### 1. `.gitignore`
+
+Create a file named `.gitignore` with the following exact content:
+
+```gitignore
+# CMake
+build/
+CMakeCache.txt
+CMakeFiles/
+CMakeScripts/
+Testing/
+Makefile
+cmake_install.cmake
+install_manifest.txt
+compile_commands.json
+
+# IDEs
+.idea/
+.vscode/
+*.swp
+*.swo
+
+# OS
+.DS_Store
+Thumbs.db
+
+```
+
+### 2. `.gitattributes`
+
+Create a file named `.gitattributes` with the following exact content:
+
+```gitattributes
+# Auto detect text files and perform LF normalization
+* text=auto
+
+# Ensure bash scripts always use LF
+*.sh text eol=lf
+
+# C++ Source Code
+*.cpp text diff=cpp
+*.hpp text diff=cpp
+*.c text diff=cpp
+*.h text diff=cpp
+
+# Build files
+CMakeLists.txt text
+*.cmake text
+```
+
+### 3. `.clangd`
+
+Create a file named `.clangd` at the project root with the following exact content to ensure seamless IDE support if the build system generates a `compile_commands.json` file:
+
+```yaml
+CompileFlags:
+  CompilationDatabase: build
+```

package/data/scaffold-bazel/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: scaffold-bazel
+description: Generates Bazel build files (WORKSPACE/BUILD) for configuring a C++ project.
+---
+
+# Bazel Scaffolding Skill
+
+This skill instructs the agent on how to scaffold Bazel build files for a C++ project.
+
+## Requirements
+
+When the user specifies Bazel for the Build System, the agent MUST generate a root `MODULE.bazel` file (as Bzlmod is the default in Bazel 7+) and `BUILD` or `BUILD.bazel` files in the necessary directories.
+
+## Instructions
+
+1. **Root File**: Create a `MODULE.bazel` file in the project root to mark it as a Bazel workspace and define dependencies using `bazel_dep`.
+2. **Targets and Modularity**: Use `cc_library` and `cc_binary` rules to define the libraries and executable tools requested by the user.
+   - Separate rules into individual `BUILD` files inside their respective source directories.
+3. **Libraries**:
+   ```starlark
+   # src/my_lib/BUILD
+   cc_library(
+       name = "my_lib",
+       srcs = ["my_lib.cc"],
+       hdrs = ["my_lib.h"],
+       includes = ["."], # or strip_include_prefix
+       visibility = ["//visibility:public"],
+   )
+   ```
+4. **Executables**:
+   ```starlark
+   # src/my_app/BUILD
+   cc_binary(
+       name = "my_app",
+       srcs = ["main.cc"],
+       deps = ["//src/my_lib:my_lib"],
+   )
+   ```
+5. **Testing**:
+   - For `cc_test` targets, depend on the testing framework.
+   ```starlark
+   cc_test(
+       name = "my_lib_test",
+       srcs = ["my_lib_test.cc"],
+       deps = [
+           "//src/my_lib:my_lib",
+           "@googletest//:gtest_main", # Example if using gtest via bazel_dep in MODULE.bazel
+       ],
+   )
+   ```
+
+## Build Skills Generation
+
+If Bazel is the build system, the agent MUST generate a `skills/build-project/SKILL.md` in the new project.
+The generated skill must instruct agents to build the project using:
+
+```bash
+bazel build //...
+```
+
+And to run tests:
+
+```bash
+bazel test //...
+```

package/data/scaffold-clang-tidy/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: scaffold-clang-tidy
+description: Generates .clang-tidy configuration for C++ projects.
+---
+
+# Clang-Tidy Scaffolding Skill
+
+This skill instructs the agent on how to scaffold a `.clang-tidy` configuration file for a C++ project.
+
+## Requirements
+
+When the user specifies Clang-Tidy for Code Quality, the agent MUST generate a `.clang-tidy` file in the root of the project.
+
+## Instructions
+
+1. **Configuration File**: Create a `.clang-tidy` file with a robust set of default checks.
+
+   - **CRITICAL**: For `Checks`, ensure you disable `bugprone-easily-swappable-parameters` (e.g., add `-bugprone-easily-swappable-parameters`).
+   - **CRITICAL**: If the chosen coding convention does not require braces around single statement if/for/while/etc bodies, you MUST also disable `readability-braces-around-statements` (e.g., add `-readability-braces-around-statements`).
+
+   ```yaml
+   Checks: "-*,readability-*,modernize-*,performance-*,bugprone-*,cppcoreguidelines-*,-bugprone-easily-swappable-parameters"
+   WarningsAsErrors: ""
+   HeaderFilterRegex: ".*"
+   AnalyzeTemporaryDtors: false
+   FormatStyle: "file"
+   CheckOptions:
+     - key: readability-identifier-naming.ClassCase
+       value: CamelCase
+     - key: readability-identifier-naming.VariableCase
+       value: camelBack
+   ```
+
+2. **Build System Integration**: If CMake is used, instruct the agent to enable clang-tidy integration by adding `CXX_CLANG_TIDY` properties to targets, or globally:
+   ```cmake
+   set(CMAKE_CXX_CLANG_TIDY "clang-tidy")
+   ```

package/data/scaffold-cmake/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: scaffold-cmake
+description: Generates modern CMakeLists.txt files for configuring a C++ project.
+---
+
+# CMake Scaffolding Skill
+
+This skill instructs the agent on how to scaffold modern `CMakeLists.txt` files for the C++ project.
+
+## Requirements
+
+When the user specifies CMake for the Build System, the agent MUST generate a root `CMakeLists.txt` and any necessary subdirectory `CMakeLists.txt` files (e.g., in `src/` or `tests/`).
+
+## Instructions for `CMakeLists.txt`
+
+**If generating a NEW project (Mode A):**
+The root `CMakeLists.txt` must be written using Modern CMake (target-based) principles:
+
+1. **Minimum Required Version**: Start with `cmake_minimum_required(VERSION 3.20)` (or higher).
+2. **Project Definition**: `project(ProjectName VERSION 0.1.0 LANGUAGES CXX)`
+3. **C++ Standard**: Enforce the C++ standard strictly via target properties (e.g., `target_compile_features(<target> PUBLIC cxx_std_20)`). Avoid using global variables like `CMAKE_CXX_STANDARD`.
+4. **Targets and Modularity**: The agent MUST iterate over the libraries and tools requested by the user during the meta-quickstart interview.
+   - **CRITICAL RULE**: Do NOT create a single monolithic top-level `CMakeLists.txt` that defines every target. Instead, you MUST split the build files per artifact. The root `CMakeLists.txt` should simply use `add_subdirectory(...)` for each target, and the actual `add_library(<target_name>)` or `add_executable(<target_name>)` commands MUST be placed inside individual `CMakeLists.txt` files residing in their respective target source directories.
+   - Avoid global state functions like `include_directories()`.
+5. **Target Properties**: Apply properties to _each_ target specifically. Use `target_include_directories(<target_name> ...)`, `target_compile_features(<target_name> ...)`, and `target_link_libraries(<target_name> ...)`.
+   - If an executable tool depends on a library built in the same project, link them together! (e.g., `target_link_libraries(app_cli PRIVATE core_lib)`).
+6. **Package Management Integration**:
+   - If Conan is used, link against Conan-provided targets (e.g., `find_package(ZLIB REQUIRED)`, `target_link_libraries(my_target PRIVATE ZLIB::ZLIB)`).
+   - If vcpkg is used, do the same. Provide a note that `CMAKE_TOOLCHAIN_FILE` must be passed during the configure step.
+7. **Testing**: If a testing framework is chosen, `enable_testing()` and use `add_subdirectory(tests)` (or similar) to include test targets. Use `FetchContent` to download the testing framework (e.g., GTest, Catch2) if a package manager isn't handling it.
+8. **Compilation Database**: You MUST add `set(CMAKE_EXPORT_COMPILE_COMMANDS ON)` near the top of the file. Furthermore, if the user requested a multi-configuration generator (where build files are placed in subdirectories like `build/Debug/` or `build/Release/`), you MUST generate a configure-time rule (e.g., using `file(CREATE_LINK ...)`) to symlink the nested `compile_commands.json` back to the root of the `build/` directory so the `.clangd` configuration can always find it without modification.
+
+**If adding components to an EXISTING project (Mode B):**
+
+1. **DO NOT OVERWRITE**: You MUST NOT overwrite the existing `CMakeLists.txt`.
+2. **Safe Appending**: Append the new `add_library(<target_name>)` or `add_executable(<target_name>)` definitions safely to the bottom of the file, or inside the appropriate conditional blocks if they exist.
+3. **Respect Conventions**: If the existing `CMakeLists.txt` uses `lowercase()` or `UPPERCASE()` CMake commands, match that style exactly. Do not change global properties.
+
+## Build Skills Generation
+
+If CMake is the build system, the agent MUST generate a `skills/build-project/SKILL.md` in the new project.
+The generated skill must instruct agents to build the project using:
+
+```bash
+cmake --build build -j
+```
+
+## Workflow Integration
+
+This skill is utilized by the `meta-quickstart` skill when the user selects CMake as their build system.

package/data/scaffold-cmake-presets/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: scaffold-cmake-presets
+description: Generates a CMakePresets.json file to standardize CMake configuration and build commands.
+---
+
+# CMake Presets Scaffolding Skill
+
+This skill instructs the agent on how to scaffold a `CMakePresets.json` file to establish a standardized, hallucination-free build process.
+
+## Requirements
+
+When the user specifies CMake as their Build System, the agent MUST generate a `CMakePresets.json` file in the project root. This ensures that build commands are simple (e.g., `cmake --preset dev`) and consistent across platforms and environments.
+
+## Instructions for `CMakePresets.json`
+
+The file MUST be a valid JSON matching the CMake Presets version 3 (or higher) specification.
+
+### 1. Configure Presets
+
+Define your configuration presets.
+
+- **Hidden Base Preset**: Create a hidden preset (e.g., `default-base` with `"hidden": true`) that defines common properties:
+  - Generator (default to `"Ninja"` unless requested otherwise).
+  - Common cache variables (e.g., `"CMAKE_EXPORT_COMPILE_COMMANDS": "YES"`).
+- **User-Facing Presets**: Create user-facing presets (e.g., `dev` and `release`) that inherit from the base preset.
+  - Set the `"binaryDir"` cleanly (e.g., `"${sourceDir}/build/${presetName}"`).
+  - Set `"CMAKE_BUILD_TYPE"` appropriately (Debug for dev, Release for release).
+
+### 2. Conan Integration (CRITICAL)
+
+If the project uses **Conan 2.x** for dependency management:
+
+- Do NOT hardcode `CMAKE_TOOLCHAIN_FILE` paths manually.
+- Your user-facing presets (e.g., `dev`) MUST **inherit** from the Conan-generated presets (e.g., `"conan-debug"` or `"conan-release"`).
+  ```json
+  {
+    "name": "dev",
+    "inherits": ["conan-debug", "default-base"],
+    "cacheVariables": {
+      "CMAKE_BUILD_TYPE": "Debug"
+    }
+  }
+  ```
+- **Order of Operations Warning**: Instruct the user or subagents that when Conan is used alongside CMake presets, they MUST run `conan install .` (often with build profile arguments) **before** running `cmake --preset dev`. Otherwise, CMake will crash because the inherited Conan preset doesn't exist yet.
+
+### 3. vcpkg Integration
+
+If the project uses **vcpkg** (and not Conan), explicitly define the `CMAKE_TOOLCHAIN_FILE` in the base preset's cache variables. E.g.:
+
+- `"CMAKE_TOOLCHAIN_FILE": "$env{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake"`
+
+### 4. Multi-Package Manager Support (Conan AND vcpkg)
+
+If a project supports _both_ package managers to give developers a choice, do NOT attempt to chain them together. Instead, generate separate, distinct user-facing presets for each:
+
+- **`dev-conan`**: Inherits from the Conan-generated preset (e.g., `"inherits": ["default-base", "conan-debug"]`).
+- **`dev-vcpkg`**: Inherits from the base preset but explicitly defines the vcpkg toolchain variable:
+  ```json
+  "cacheVariables": {
+    "CMAKE_TOOLCHAIN_FILE": "$env{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake"
+  }
+  ```
+  This allows developers to simply run `cmake --preset dev-conan` or `cmake --preset dev-vcpkg` depending on their preferred package manager.
+
+### 5. Build and Test Presets
+
+- Create `buildPresets` that correspond to your configure presets (e.g., a `dev` build preset that references the `dev` configure preset).
+- If a testing framework is used, create `testPresets` that run CTest against the configured build directory.
+
+## Build Skills Generation
+
+If CMake Presets are scaffolded, update the project's build instructions to use the simple preset commands:
+
+```bash
+cmake --preset dev
+cmake --build --preset dev
+```
+
+## Example `CMakePresets.json` Structure
+
+```json
+{
+  "version": 3,
+  "cmakeMinimumRequired": {
+    "major": 3,
+    "minor": 23,
+    "patch": 0
+  },
+  "configurePresets": [
+    {
+      "name": "default-base",
+      "hidden": true,
+      "generator": "Ninja",
+      "binaryDir": "${sourceDir}/build/${presetName}",
+      "cacheVariables": {
+        "CMAKE_EXPORT_COMPILE_COMMANDS": "YES"
+      }
+    },
+    {
+      "name": "dev",
+      "inherits": "default-base",
+      "cacheVariables": {
+        "CMAKE_BUILD_TYPE": "Debug"
+      }
+    }
+  ],
+  "buildPresets": [
+    {
+      "name": "dev",
+      "configurePreset": "dev"
+    }
+  ]
+}
+```

package/data/scaffold-code-quality/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: scaffold-code-quality
+description: Generates code quality configurations including .clang-format, .clang-tidy, and pre-commit hooks.
+---
+
+# Code Quality Skill
+
+This skill instructs the agent on how to scaffold code quality tooling for the C++ project.
+
+## Requirements
+
+When the user specifies Code Quality Enforcement (like pre-commit hooks, formatting, linting), generate the following files in the project root.
+
+### 1. `.clang-format`
+
+Create a file named `.clang-format` with the following exact content:
+
+```yaml
+# The coding style is ultimately decided by the users.
+# Update the BasedOnStyle or define your custom rules below.
+BasedOnStyle: LLVM
+Standard: c++20
+ColumnLimit: 100
+IndentWidth: 4
+TabWidth: 4
+UseTab: Never
+```
+
+### 2. `.clang-tidy`
+
+Create a file named `.clang-tidy` with the following exact content:
+
+```yaml
+Checks: "-*,readability-*,bugprone-*,performance-*,modernize-*,clang-analyzer-*,cppcoreguidelines-*,-cppcoreguidelines-pro-bounds-pointer-arithmetic,-cppcoreguidelines-pro-bounds-constant-array-index"
+WarningsAsErrors: ""
+HeaderFilterRegex: ""
+AnalyzeTemporaryDtors: false
+FormatStyle: none
+```
+
+### 3. `.pre-commit-config.yaml`
+
+Create a file named `.pre-commit-config.yaml` with the following exact content:
+
+```yaml
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.6.0
+    hooks:
+      - id: trailing-whitespace
+      - id: end-of-file-fixer
+      - id: check-yaml
+  - repo: https://github.com/pre-commit/mirrors-clang-format
+    rev: v18.1.5
+    hooks:
+      - id: clang-format
+        types_or: [c++, c]
+```

package/data/scaffold-conan/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: scaffold-conan
+description: Generates a conanfile.py for configuring packaging and dependency management with Conan 2.x.
+---
+
+# Conan Packaging Skill
+
+This skill instructs the agent on how to scaffold a Conan 2.x packaging manifest (`conanfile.py`) for the C++ project.
+
+## Requirements
+
+When the user specifies Conan for Project Packaging, the agent MUST generate a `conanfile.py` in the root of the project.
+
+## Instructions for `conanfile.py`
+
+The `conanfile.py` must define a class inheriting from `ConanFile` and include the following:
+
+1. **Metadata**: `name`, `version`, `license`, `author`, `url`, and `description`.
+2. **Settings**: Standard settings `os`, `compiler`, `build_type`, `arch`.
+3. **Options**: Typically `shared=True/False` and `fPIC=True/False`.
+4. **Tool Requires**: E.g., `cmake/[>=3.24]`.
+5. **Requirements**: Implement the `requirements()` method using `self.requires("package/version")`.
+6. **Layout**: Implement the `layout()` method calling `cmake_layout(self)` to use Conan 2.x's robust default generated layout.
+7. **Generate**: Implement the `generate()` method using `CMakeDeps` and `CMakeToolchain`.
+8. **Build**: Implement the `build()` method using `CMake(self).configure()` and `build()`.
+9. **Package**: Implement the `package()` method using `CMake(self).install()`.
+10. **Package Info**: Implement `package_info()` to define `self.cpp_info.libs = ["<library_name>"]` and `self.cpp_info.set_property("cmake_target_name", "PkgName::LibName")` to ensure modern CMake integration.
+
+## Configure Skills Generation
+
+If Conan is used, the agent MUST instruct that the generated `skills/configure-project/SKILL.md` inside the new project contains the exact Conan configuration commands, for example:
+
+```bash
+conan profile detect --force
+conan install . --output-folder=build --build=missing
+```
+
+And if CMake is used with Conan, the `configure-project` skill must document how to pass the Conan toolchain to CMake:
+
+```bash
+cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=build/conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release
+```
+
+## Workflow Integration
+
+This skill is utilized by the `meta-quickstart` skill when the user selects Conan for Project Packaging.

package/data/scaffold-doctest/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: scaffold-doctest
+description: Generates boilerplate for Doctest framework integration.
+---
+
+# Doctest Scaffolding Skill
+
+This skill instructs the agent on how to scaffold Doctest for a C++ project.
+
+## Requirements
+
+When the user specifies Doctest for their Testing Framework, you MUST generate the necessary boilerplate to integrate it. Doctest is typically used as a single-header library, which makes it very fast and easy to integrate.
+
+## Instructions for CMake
+
+If the Build System is CMake:
+
+1. **Fetching Doctest**: Use `FetchContent` to download Doctest (if no package manager is handling it):
+   ```cmake
+   include(FetchContent)
+   FetchContent_Declare(
+       doctest
+       GIT_REPOSITORY https://github.com/doctest/doctest
+       GIT_TAG        v2.4.11
+   )
+   FetchContent_MakeAvailable(doctest)
+   ```
+2. **Linking**: Link test executables against `doctest::doctest`.
+   ```cmake
+   add_executable(my_test test_main.cpp)
+   target_link_libraries(my_test PRIVATE doctest::doctest my_library)
+   ```
+3. **Test Registration**: To register tests with CTest, use `add_test()`.
+   ```cmake
+   add_test(NAME my_test COMMAND my_test)
+   ```
+
+## Instructions for Source Files
+
+Generate a basic test file `test_main.cpp`. For doctest, exactly one file must define `DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN`.
+
+```cpp
+#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
+#include <doctest/doctest.h>
+
+TEST_CASE("ExampleTest") {
+    CHECK(1 == 1);
+    REQUIRE(true);
+}
+```