@m-velikov/cpp-quick-start-mcp 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +156 -0
- package/build/index.d.ts +3 -0
- package/build/index.d.ts.map +1 -0
- package/build/index.js +146 -0
- package/build/index.js.map +1 -0
- package/data/best-practices-bazel/SKILL.md +28 -0
- package/data/best-practices-cmake/SKILL.md +39 -0
- package/data/best-practices-code-review/SKILL.md +34 -0
- package/data/best-practices-conan/SKILL.md +28 -0
- package/data/best-practices-cpp/SKILL.md +38 -0
- package/data/best-practices-gtest/SKILL.md +30 -0
- package/data/best-practices-meson/SKILL.md +34 -0
- package/data/best-practices-refactoring/SKILL.md +28 -0
- package/data/best-practices-vcpkg/SKILL.md +27 -0
- package/data/meta-quickstart/SKILL.md +104 -0
- package/data/scaffold-agents/SKILL.md +68 -0
- package/data/scaffold-base-configs/SKILL.md +71 -0
- package/data/scaffold-bazel/SKILL.md +65 -0
- package/data/scaffold-clang-tidy/SKILL.md +37 -0
- package/data/scaffold-cmake/SKILL.md +50 -0
- package/data/scaffold-cmake-presets/SKILL.md +114 -0
- package/data/scaffold-code-quality/SKILL.md +58 -0
- package/data/scaffold-conan/SKILL.md +46 -0
- package/data/scaffold-doctest/SKILL.md +50 -0
- package/data/scaffold-github-actions/SKILL.md +29 -0
- package/data/scaffold-gitlab-ci/SKILL.md +30 -0
- package/data/scaffold-gtest/SKILL.md +53 -0
- package/data/scaffold-make/SKILL.md +62 -0
- package/data/scaffold-meson/SKILL.md +49 -0
- package/data/scaffold-pitchfork-layout/SKILL.md +60 -0
- package/data/scaffold-pre-commit/SKILL.md +33 -0
- package/data/scaffold-vcpkg/SKILL.md +50 -0
- package/package.json +59 -0
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scaffold-github-actions
|
|
3
|
+
description: Generates a standard GitHub Actions CI pipeline for a C++ project.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# GitHub Actions Scaffolding Skill
|
|
7
|
+
|
|
8
|
+
This skill instructs the agent on how to scaffold a CI pipeline using GitHub Actions.
|
|
9
|
+
|
|
10
|
+
## Requirements
|
|
11
|
+
|
|
12
|
+
When the user specifies GitHub Actions for their CI Provider, the agent MUST generate a workflow file at `.github/workflows/build.yml`.
|
|
13
|
+
|
|
14
|
+
## Instructions for `build.yml`
|
|
15
|
+
|
|
16
|
+
The generated workflow must:
|
|
17
|
+
|
|
18
|
+
1. **Trigger**: Run on `push` and `pull_request` to the `main` or `master` branch.
|
|
19
|
+
2. **Strategy Matrix**: Test across multiple OS environments if applicable (e.g., `ubuntu-latest`, `macos-latest`, `windows-latest`).
|
|
20
|
+
3. **Steps**:
|
|
21
|
+
- Check out the repository (`actions/checkout@v4`).
|
|
22
|
+
- Setup the compiler and dependencies (e.g., install ninja, CMake).
|
|
23
|
+
- Configure the build using the chosen build system (e.g., `cmake -B build -G Ninja`).
|
|
24
|
+
- Build the project (e.g., `cmake --build build`).
|
|
25
|
+
- Run tests (e.g., `ctest --test-dir build --output-on-failure`).
|
|
26
|
+
|
|
27
|
+
## Workflow Integration
|
|
28
|
+
|
|
29
|
+
This skill is utilized by the `meta-quickstart` skill when the user selects GitHub Actions as their CI Provider.
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scaffold-gitlab-ci
|
|
3
|
+
description: Generates a standard GitLab CI pipeline for a C++ project.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# GitLab CI Scaffolding Skill
|
|
7
|
+
|
|
8
|
+
This skill instructs the agent on how to scaffold a CI pipeline using GitLab CI.
|
|
9
|
+
|
|
10
|
+
## Requirements
|
|
11
|
+
|
|
12
|
+
When the user specifies GitLab CI for their CI Provider, the agent MUST generate a pipeline file at `.gitlab-ci.yml` in the root of the project.
|
|
13
|
+
|
|
14
|
+
## Instructions for `.gitlab-ci.yml`
|
|
15
|
+
|
|
16
|
+
The generated pipeline must:
|
|
17
|
+
|
|
18
|
+
1. **Image**: Use a standard C++ docker image (e.g., `gcc:latest` or `silkeh/clang:latest`).
|
|
19
|
+
2. **Stages**: Define at least two stages: `build` and `test`.
|
|
20
|
+
3. **Build Job**:
|
|
21
|
+
- Install necessary dependencies (e.g., `apt-get update && apt-get install -y cmake ninja-build`).
|
|
22
|
+
- Configure and build the project.
|
|
23
|
+
- Save the build artifacts.
|
|
24
|
+
4. **Test Job**:
|
|
25
|
+
- Depend on the build job.
|
|
26
|
+
- Run the testing suite (e.g., `ctest --output-on-failure`).
|
|
27
|
+
|
|
28
|
+
## Workflow Integration
|
|
29
|
+
|
|
30
|
+
This skill is utilized by the `meta-quickstart` skill when the user selects GitLab CI as their CI Provider.
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scaffold-gtest
|
|
3
|
+
description: Generates boilerplate for Google Test (GTest) framework integration.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# GTest Scaffolding Skill
|
|
7
|
+
|
|
8
|
+
This skill instructs the agent on how to scaffold Google Test (GTest) for a C++ project.
|
|
9
|
+
|
|
10
|
+
## Requirements
|
|
11
|
+
|
|
12
|
+
When the user specifies GTest for their Testing Framework, you MUST generate the necessary boilerplate to integrate it with the chosen build system and package manager.
|
|
13
|
+
|
|
14
|
+
## Instructions for CMake
|
|
15
|
+
|
|
16
|
+
If the Build System is CMake:
|
|
17
|
+
|
|
18
|
+
1. **Fetching GTest**: If the user didn't specify a package manager (or specifies FetchContent), use CMake's `FetchContent` to download GTest:
|
|
19
|
+
```cmake
|
|
20
|
+
include(FetchContent)
|
|
21
|
+
FetchContent_Declare(
|
|
22
|
+
googletest
|
|
23
|
+
URL https://github.com/google/googletest/archive/03597a01ee50ed33e9dfd640b249b4be3799d395.zip
|
|
24
|
+
)
|
|
25
|
+
# For Windows: Prevent overriding the parent project's compiler/linker settings
|
|
26
|
+
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
|
|
27
|
+
FetchContent_MakeAvailable(googletest)
|
|
28
|
+
```
|
|
29
|
+
2. **Linking**: Link test executables against `GTest::gtest_main` and `GTest::gmock`.
|
|
30
|
+
```cmake
|
|
31
|
+
add_executable(my_test test_main.cpp)
|
|
32
|
+
target_link_libraries(my_test PRIVATE GTest::gtest_main GTest::gmock my_library)
|
|
33
|
+
```
|
|
34
|
+
3. **Test Discovery**: Include `GoogleTest` and use `gtest_discover_tests()` to automatically discover tests for CTest.
|
|
35
|
+
```cmake
|
|
36
|
+
include(GoogleTest)
|
|
37
|
+
gtest_discover_tests(my_test)
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
## Instructions for Source Files
|
|
41
|
+
|
|
42
|
+
Generate a basic test file `test_main.cpp` using the `TEST` macro:
|
|
43
|
+
|
|
44
|
+
```cpp
|
|
45
|
+
#include <gtest/gtest.h>
|
|
46
|
+
|
|
47
|
+
TEST(ExampleTest, BasicAssertions) {
|
|
48
|
+
EXPECT_EQ(1, 1);
|
|
49
|
+
EXPECT_TRUE(true);
|
|
50
|
+
}
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
_Note: If linking against `GTest::gtest_main`, no `main()` function is required in the test file._
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scaffold-make
|
|
3
|
+
description: Generates modern Makefiles for configuring a C++ project.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Makefile Scaffolding Skill
|
|
7
|
+
|
|
8
|
+
This skill instructs the agent on how to scaffold a `Makefile` for a C++ project.
|
|
9
|
+
|
|
10
|
+
## Requirements
|
|
11
|
+
|
|
12
|
+
When the user specifies Makefiles for the Build System, the agent MUST generate a single root `Makefile`. Do NOT generate recursive Makefiles (e.g., invoking `$(MAKE)` in subdirectories for sub-components). Use a non-recursive design (e.g., including `.mk` files) for better dependency tracking and performance.
|
|
13
|
+
|
|
14
|
+
## Instructions
|
|
15
|
+
|
|
16
|
+
1. **Non-Recursive Design**: Always use a non-recursive Makefile architecture. Include source files from subdirectories directly or via `include` statements.
|
|
17
|
+
2. **Compiler and Flags**: Define `CXX`, `CXXFLAGS`, and `LDFLAGS`. Use modern defaults.
|
|
18
|
+
```makefile
|
|
19
|
+
CXX ?= g++
|
|
20
|
+
CXXFLAGS ?= -std=c++17 -Wall -Wextra -Wpedantic -O2
|
|
21
|
+
LDFLAGS ?=
|
|
22
|
+
```
|
|
23
|
+
3. **Directories**: Define `SRC_DIR`, `OBJ_DIR`, and `BIN_DIR`.
|
|
24
|
+
```makefile
|
|
25
|
+
SRC_DIR := src
|
|
26
|
+
OBJ_DIR := obj
|
|
27
|
+
BIN_DIR := bin
|
|
28
|
+
```
|
|
29
|
+
4. **Source Discovery**: Automatically discover source files or list them explicitly.
|
|
30
|
+
```makefile
|
|
31
|
+
SRCS := $(wildcard $(SRC_DIR)/**/*.cpp)
|
|
32
|
+
OBJS := $(patsubst $(SRC_DIR)/%.cpp, $(OBJ_DIR)/%.o, $(SRCS))
|
|
33
|
+
```
|
|
34
|
+
5. **Targets**: Create rules for the executable(s) and object files.
|
|
35
|
+
|
|
36
|
+
```makefile
|
|
37
|
+
TARGET := $(BIN_DIR)/my_app
|
|
38
|
+
|
|
39
|
+
all: $(TARGET)
|
|
40
|
+
|
|
41
|
+
$(TARGET): $(OBJS)
|
|
42
|
+
@mkdir -p $(@D)
|
|
43
|
+
$(CXX) $(OBJS) -o $@ $(LDFLAGS)
|
|
44
|
+
|
|
45
|
+
$(OBJ_DIR)/%.o: $(SRC_DIR)/%.cpp
|
|
46
|
+
@mkdir -p $(@D)
|
|
47
|
+
$(CXX) $(CXXFLAGS) -c $< -o $@
|
|
48
|
+
|
|
49
|
+
clean:
|
|
50
|
+
rm -rf $(OBJ_DIR) $(BIN_DIR)
|
|
51
|
+
|
|
52
|
+
.PHONY: all clean
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
## Build Skills Generation
|
|
56
|
+
|
|
57
|
+
If Makefile is the build system, the agent MUST generate a `skills/build-project/SKILL.md` in the new project.
|
|
58
|
+
The generated skill must instruct agents to build the project using:
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
make -j
|
|
62
|
+
```
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scaffold-meson
|
|
3
|
+
description: Generates modular meson.build files for configuring a C++ project.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Meson Scaffolding Skill
|
|
7
|
+
|
|
8
|
+
This skill instructs the agent on how to scaffold a modern, modular Meson build structure for the C++ project.
|
|
9
|
+
|
|
10
|
+
## Requirements
|
|
11
|
+
|
|
12
|
+
When the user specifies Meson for the Build System, the agent MUST generate a root `meson.build` and any necessary subdirectory `meson.build` files (e.g., in `src/` or `tests/`).
|
|
13
|
+
|
|
14
|
+
## Instructions for `meson.build`
|
|
15
|
+
|
|
16
|
+
**If generating a NEW project (Mode A):**
|
|
17
|
+
|
|
18
|
+
1. **Project Definition**: Start the root `meson.build` with:
|
|
19
|
+
`project('ProjectName', 'cpp', version : '0.1.0', default_options : ['warning_level=3', 'cpp_std=c++20'])`
|
|
20
|
+
Adjust the `cpp_std` according to the user's choice.
|
|
21
|
+
2. **Modularity (CRITICAL RULE)**: Do NOT define libraries or executables in a single monolithic top-level `meson.build`. The root `meson.build` MUST only use `subdir('dir')` for each target. The actual `library()` or `executable()` calls MUST be placed inside individual `meson.build` files residing in their respective target source directories.
|
|
22
|
+
3. **Dependency Management**: Use `dependency('<name>')` to link dependencies.
|
|
23
|
+
- **External Package Managers (Conan/vcpkg)**: If the user chose Conan or vcpkg, assume dependencies will be resolved via `pkg-config`. (e.g. `dependency('fmt')`).
|
|
24
|
+
- **Native Meson Wraps**: If no external package manager is used, instruct the AI to scaffold `.wrap` files for the requested dependencies inside the `subprojects/` directory, and use `dependency('fmt', fallback: ['fmt', 'fmt_dep'])`.
|
|
25
|
+
4. **Target Definitions**: In the subdirectory `meson.build` files:
|
|
26
|
+
- For libraries, use `library('name', sources, dependencies : [...])`.
|
|
27
|
+
- For executables, use `executable('name', sources, dependencies : [...])`.
|
|
28
|
+
- If an executable tool depends on a library built in the same project, link them by creating a `declare_dependency` for the library or passing the library target directly in `link_with`.
|
|
29
|
+
5. **Testing**: If a testing framework is chosen, create a `tests/` directory with a `meson.build` file containing `test('test_name', test_exe)`. Download the testing framework (e.g., GTest, Catch2) via a `.wrap` file if no external package manager handles it.
|
|
30
|
+
6. **IDE Support**: Meson inherently generates `compile_commands.json` in the build directory, so no special build system flags are required. Our standard `.clangd` file configuration will seamlessly discover it.
|
|
31
|
+
|
|
32
|
+
**If adding components to an EXISTING project (Mode B):**
|
|
33
|
+
|
|
34
|
+
1. **DO NOT OVERWRITE**: You MUST NOT overwrite existing `meson.build` files entirely.
|
|
35
|
+
2. **Safe Appending**: Append the new `subdir('<target_name>')` calls to the root `meson.build` and create the new folder with its own isolated `meson.build` file.
|
|
36
|
+
|
|
37
|
+
## Build Skills Generation
|
|
38
|
+
|
|
39
|
+
If Meson is the build system, the agent MUST generate a `skills/build-project/SKILL.md` in the new project.
|
|
40
|
+
The generated skill must instruct agents to build the project using:
|
|
41
|
+
|
|
42
|
+
```bash
|
|
43
|
+
meson setup build
|
|
44
|
+
meson compile -C build
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
## Workflow Integration
|
|
48
|
+
|
|
49
|
+
This skill is utilized by the `meta-quickstart` skill when the user selects Meson as their build system.
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scaffold-pitchfork-layout
|
|
3
|
+
description: Generates a C++ project directory structure strictly following the Pitchfork Layout specification.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Pitchfork Layout Scaffolding Skill
|
|
7
|
+
|
|
8
|
+
This skill instructs the agent on how to correctly scaffold a C++ project following the official Pitchfork directory layout specification.
|
|
9
|
+
|
|
10
|
+
## Reference
|
|
11
|
+
|
|
12
|
+
For the exact specification and rationale, always refer to the official documentation:
|
|
13
|
+
[Pitchfork Layout Specification](https://github.com/vector-of-bool/pitchfork/blob/develop/data/spec.bs)
|
|
14
|
+
|
|
15
|
+
## Standard Directories to Create
|
|
16
|
+
|
|
17
|
+
When invoking this skill to scaffold a new C++ project, the agent MUST create the following structure based on the Pitchfork standard:
|
|
18
|
+
|
|
19
|
+
1. **`src/`** or **`libs/` / `tools/`**:
|
|
20
|
+
- For a single library/executable, use `src/` for private implementation files (`*.cpp`, private `*.hpp`).
|
|
21
|
+
- **For multiple targets** (e.g., a core library and multiple CLI tools), the agent MUST group them properly. Either use target-specific subdirectories inside `src/` (e.g., `src/core_lib/`, `src/app_cli/`) or use the top-level `libs/` and `tools/` directories as per Pitchfork (e.g., `libs/core_lib/src/`, `tools/app_cli/src/`).
|
|
22
|
+
2. **`include/`**: Contains the public headers API.
|
|
23
|
+
- **CRITICAL**: Do NOT place headers directly in `include/`. You must create a subdirectory matching the target name (e.g., `include/<target_name>/`). This prevents header collisions. For multiple libraries, create multiple subdirectories (e.g., `include/libA/`, `include/libB/`).
|
|
24
|
+
3. **`tests/`**: Contains all testing code. For multiple targets, group tests by target (e.g., `tests/libA/`, `tests/libB/`).
|
|
25
|
+
4. **`examples/`** _(Optional)_: Contains example code showing how to use the library/project.
|
|
26
|
+
5. **`external/`** _(Optional)_: Contains third-party dependencies (if not using a package manager like vcpkg or FetchContent).
|
|
27
|
+
6. **`data/`** _(Optional)_: Contains non-source data files (e.g., assets, images, databases).
|
|
28
|
+
7. **`tools/`** _(Optional)_: Contains development scripts, deployment scripts, and internal utilities.
|
|
29
|
+
8. **`docs/`** _(Optional)_: Contains project documentation (e.g., Doxygen configuration).
|
|
30
|
+
9. **`build/`**: The designated output directory for build artifacts (compilation should always be out-of-source). This directory should be added to `.gitignore`.
|
|
31
|
+
|
|
32
|
+
## Example Structure (Multi-Target)
|
|
33
|
+
|
|
34
|
+
If building a project with a library `core_lib` and an executable `app_cli`, the layout should look like this:
|
|
35
|
+
|
|
36
|
+
```
|
|
37
|
+
my_project/
|
|
38
|
+
├── CMakeLists.txt
|
|
39
|
+
├── .gitignore
|
|
40
|
+
├── include/
|
|
41
|
+
│ └── core_lib/
|
|
42
|
+
│ └── core_lib.hpp
|
|
43
|
+
├── src/
|
|
44
|
+
│ ├── core_lib/
|
|
45
|
+
│ │ └── core_lib.cpp
|
|
46
|
+
│ └── app_cli/
|
|
47
|
+
│ └── main.cpp
|
|
48
|
+
└── tests/
|
|
49
|
+
└── core_lib/
|
|
50
|
+
└── test_core_lib.cpp
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
## Existing Project Additions (Mode B)
|
|
54
|
+
|
|
55
|
+
If adding new components to an _existing_ project, the agent MUST NOT delete, overwrite, or reorganize existing directories unless a layout refactoring plan has been explicitly proposed and approved by the user (as determined by the Layout Conformity Check).
|
|
56
|
+
If no refactoring plan was approved, safely _add_ the new component directories alongside the existing ones, strictly following the inferred layout (e.g., creating `src/<new_target>/` and `include/<new_target>/`).
|
|
57
|
+
|
|
58
|
+
## Workflow Integration
|
|
59
|
+
|
|
60
|
+
This skill is utilized by the `meta-quickstart` skill when a user selects "Pitchfork" as their desired directory layout, or when an existing project is inferred to use Pitchfork conventions. The agent generating the final project should use the rules above to create the file tree.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scaffold-pre-commit
|
|
3
|
+
description: Generates .pre-commit-config.yaml for C++ projects.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Pre-Commit Scaffolding Skill
|
|
7
|
+
|
|
8
|
+
This skill instructs the agent on how to scaffold a `.pre-commit-config.yaml` file for a C++ project.
|
|
9
|
+
|
|
10
|
+
## Requirements
|
|
11
|
+
|
|
12
|
+
When the user specifies Pre-Commit hooks for Code Quality, the agent MUST generate a `.pre-commit-config.yaml` file in the project root.
|
|
13
|
+
|
|
14
|
+
## Instructions
|
|
15
|
+
|
|
16
|
+
1. **Configuration File**: Create a `.pre-commit-config.yaml` with common C++ hooks.
|
|
17
|
+
```yaml
|
|
18
|
+
repos:
|
|
19
|
+
- repo: https://github.com/pre-commit/pre-commit-hooks
|
|
20
|
+
rev: v4.4.0
|
|
21
|
+
hooks:
|
|
22
|
+
- id: trailing-whitespace
|
|
23
|
+
- id: end-of-file-fixer
|
|
24
|
+
- id: check-yaml
|
|
25
|
+
- repo: https://github.com/pre-commit/mirrors-clang-format
|
|
26
|
+
rev: v16.0.2
|
|
27
|
+
hooks:
|
|
28
|
+
- id: clang-format
|
|
29
|
+
```
|
|
30
|
+
2. **Installation Instructions**: In the generated build or configuration skill, instruct the agent to note that the user should install pre-commit hooks:
|
|
31
|
+
```bash
|
|
32
|
+
pre-commit install
|
|
33
|
+
```
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scaffold-vcpkg
|
|
3
|
+
description: Generates a vcpkg.json manifest for configuring packaging and dependency management with vcpkg.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# vcpkg Packaging Skill
|
|
7
|
+
|
|
8
|
+
This skill instructs the agent on how to scaffold a vcpkg manifest (`vcpkg.json`) for the C++ project.
|
|
9
|
+
|
|
10
|
+
## Requirements
|
|
11
|
+
|
|
12
|
+
When the user specifies vcpkg for Project Packaging or Dependency Management, the agent MUST generate a `vcpkg.json` file in the root of the project.
|
|
13
|
+
|
|
14
|
+
## Instructions for `vcpkg.json`
|
|
15
|
+
|
|
16
|
+
The `vcpkg.json` file must be a valid JSON containing:
|
|
17
|
+
|
|
18
|
+
1. `"$schema"`: Pointing to the vcpkg schema URL.
|
|
19
|
+
2. `"name"`: The project name (lowercase).
|
|
20
|
+
3. `"version-string"` or `"version"`: The project version.
|
|
21
|
+
4. `"description"`: A brief description of the library/application.
|
|
22
|
+
5. `"dependencies"`: An array of strings or objects representing the third-party dependencies required.
|
|
23
|
+
|
|
24
|
+
### Example Manifest:
|
|
25
|
+
|
|
26
|
+
```json
|
|
27
|
+
{
|
|
28
|
+
"$schema": "https://raw.githubusercontent.com/microsoft/vcpkg-tool/main/docs/vcpkg.schema.json",
|
|
29
|
+
"name": "my-library",
|
|
30
|
+
"version": "1.0.0",
|
|
31
|
+
"description": "My awesome C++ library",
|
|
32
|
+
"dependencies": ["fmt", "nlohmann-json"]
|
|
33
|
+
}
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
## `vcpkg-configuration.json` (Optional)
|
|
37
|
+
|
|
38
|
+
If the project requires pinning dependencies to specific baselines or using custom registries, instruct the agent to also generate a `vcpkg-configuration.json` file alongside the manifest.
|
|
39
|
+
|
|
40
|
+
## Configure Skills Generation
|
|
41
|
+
|
|
42
|
+
If vcpkg is used with CMake, the agent MUST instruct that the generated `skills/configure-project/SKILL.md` inside the new project contains the exact instructions for passing the vcpkg toolchain to CMake. For example:
|
|
43
|
+
|
|
44
|
+
```bash
|
|
45
|
+
cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=[path to vcpkg]/scripts/buildsystems/vcpkg.cmake
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
## Workflow Integration
|
|
49
|
+
|
|
50
|
+
This skill is utilized by the `meta-quickstart` skill when the user selects vcpkg for Project Packaging or Dependency Management.
|
package/package.json
ADDED
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@m-velikov/cpp-quick-start-mcp",
|
|
3
|
+
"version": "0.1.0",
|
|
4
|
+
"description": "An MCP server for scaffolding modern C++ projects and agentic configurations.",
|
|
5
|
+
"repository": {
|
|
6
|
+
"type": "git",
|
|
7
|
+
"url": "https://github.com/m-velikov/cpp-quick-start-mcp.git"
|
|
8
|
+
},
|
|
9
|
+
"main": "build/index.js",
|
|
10
|
+
"bin": {
|
|
11
|
+
"cpp-quick-start-mcp": "build/index.js"
|
|
12
|
+
},
|
|
13
|
+
"files": [
|
|
14
|
+
"build",
|
|
15
|
+
"data"
|
|
16
|
+
],
|
|
17
|
+
"scripts": {
|
|
18
|
+
"build": "tsc",
|
|
19
|
+
"prepublishOnly": "npm run build",
|
|
20
|
+
"start": "node build/index.js",
|
|
21
|
+
"format": "prettier --write \"src/**/*.ts\" \"data/**/*.md\"",
|
|
22
|
+
"lint": "eslint src/**/*.ts"
|
|
23
|
+
},
|
|
24
|
+
"keywords": [
|
|
25
|
+
"mcp",
|
|
26
|
+
"c++",
|
|
27
|
+
"scaffold",
|
|
28
|
+
"cmake",
|
|
29
|
+
"vcpkg",
|
|
30
|
+
"conan"
|
|
31
|
+
],
|
|
32
|
+
"author": {
|
|
33
|
+
"name": "Momchil Velikov",
|
|
34
|
+
"email": "momchil.velikov@gmail.com",
|
|
35
|
+
"url": "https://github.com/m-velikov"
|
|
36
|
+
},
|
|
37
|
+
"license": "MIT",
|
|
38
|
+
"type": "module",
|
|
39
|
+
"engines": {
|
|
40
|
+
"node": ">=18.3.0"
|
|
41
|
+
},
|
|
42
|
+
"publishConfig": {
|
|
43
|
+
"access": "public"
|
|
44
|
+
},
|
|
45
|
+
"dependencies": {
|
|
46
|
+
"@hono/node-server": "^2.0.4",
|
|
47
|
+
"@modelcontextprotocol/sdk": "^1.29.0",
|
|
48
|
+
"hono": "^4.12.23"
|
|
49
|
+
},
|
|
50
|
+
"devDependencies": {
|
|
51
|
+
"@eslint/js": "^9.14.0",
|
|
52
|
+
"@types/node": "^25.9.1",
|
|
53
|
+
"eslint": "^9.14.0",
|
|
54
|
+
"prettier": "^3.8.3",
|
|
55
|
+
"tsx": "^4.22.3",
|
|
56
|
+
"typescript": "^6.0.3",
|
|
57
|
+
"typescript-eslint": "^8.13.0"
|
|
58
|
+
}
|
|
59
|
+
}
|