@m-velikov/cpp-quick-start-mcp 0.1.0 → 0.2.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/README.md +23 -8
- package/build/index.js +2 -2
- package/build/index.js.map +1 -1
- package/data/best-practices-code-review/SKILL.md +19 -10
- package/data/best-practices-conan/SKILL.md +4 -0
- package/data/best-practices-cpp/SKILL.md +1 -0
- package/data/meta-quickstart/SKILL.md +13 -4
- package/data/scaffold-agents/SKILL.md +7 -2
- package/data/scaffold-clang-tidy/SKILL.md +15 -0
- package/data/scaffold-cmake/SKILL.md +2 -2
- package/data/{scaffold-code-quality → scaffold-code-hygiene}/SKILL.md +14 -18
- package/data/scaffold-conan/SKILL.md +1 -1
- package/data/scaffold-github-actions/SKILL.md +1 -1
- package/data/scaffold-gitlab-ci/SKILL.md +1 -1
- package/data/scaffold-meson/SKILL.md +1 -1
- package/data/scaffold-pitchfork-layout/SKILL.md +2 -1
- package/data/scaffold-vcpkg/SKILL.md +1 -1
- package/package.json +1 -1
- package/data/scaffold-pre-commit/SKILL.md +0 -33
package/README.md
CHANGED
|
@@ -8,7 +8,7 @@ Instead of writing boilerplate from scratch (and hallucinating build system rule
|
|
|
8
8
|
|
|
9
9
|
## Features
|
|
10
10
|
|
|
11
|
-
- **The `
|
|
11
|
+
- **The `go` Prompt**: Initiates an interactive interview with the developer to determine the exact C++ stack (Standard, Build System, Package Manager, CI/CD, Coding Style, etc.).
|
|
12
12
|
- **Dynamic Scaffolding Resources**: Provides the AI with deep, instructional markdown resources (`mcp://scaffold/conan`, `mcp://scaffold/github-actions`, etc.) so it knows exactly how to write the requested boilerplate files perfectly.
|
|
13
13
|
- **Agent-Ready Architecture**: When you run the prompt, your C++ project will be automatically configured for modern agentic development. It seeds your project with built-in guidelines and architecture rules so future AI agents know exactly how to collaborate on your codebase safely and predictably.
|
|
14
14
|
|
|
@@ -60,9 +60,22 @@ This server supports **Dual Transport** (both `stdio` for local clients and `sse
|
|
|
60
60
|
|
|
61
61
|
### 1. Local Connection (stdio) - DEFAULT
|
|
62
62
|
|
|
63
|
-
For local IDE clients, you can connect directly without running an HTTP server.
|
|
63
|
+
For local IDE clients, you can connect directly without running an HTTP server.
|
|
64
64
|
|
|
65
|
-
|
|
65
|
+
**Option A: Global Install (Recommended)**
|
|
66
|
+
If you installed the package globally, use the `cpp-quick-start-mcp` command directly in the configurations below. _(Note: On Windows, use `cpp-quick-start-mcp.cmd` instead)._
|
|
67
|
+
|
|
68
|
+
**Option B: NPX (No Install Required)**
|
|
69
|
+
Alternatively, you can configure your IDE to run the MCP server directly via `npx` without installing it globally. Simply use `npx` as the command (or `npx.cmd` on Windows) and pass `-y @m-velikov/cpp-quick-start-mcp` as the arguments. For example:
|
|
70
|
+
|
|
71
|
+
```json
|
|
72
|
+
"mcpServers": {
|
|
73
|
+
"cpp-quick-start": {
|
|
74
|
+
"command": "npx",
|
|
75
|
+
"args": ["-y", "@m-velikov/cpp-quick-start-mcp"]
|
|
76
|
+
}
|
|
77
|
+
}
|
|
78
|
+
```
|
|
66
79
|
|
|
67
80
|
#### Antigravity IDE
|
|
68
81
|
|
|
@@ -135,19 +148,21 @@ Example configuration for a custom web client:
|
|
|
135
148
|
|
|
136
149
|
### New Projects
|
|
137
150
|
|
|
138
|
-
Once connected, simply open an empty folder in your editor/terminal
|
|
151
|
+
Once connected, simply open an empty folder in your editor/terminal. To start the scaffolding interview, you can simply tell your AI assistant:
|
|
152
|
+
|
|
153
|
+
> `/go help me start a new C++ project`
|
|
139
154
|
|
|
140
|
-
|
|
155
|
+
_(Depending on your client, you may need to use the full prompt command: `/mcp:cpp-quick-start:go help me start a new C++ project`)_
|
|
141
156
|
|
|
142
157
|
The AI will take over, interview you, and generate your custom C++ boilerplate.
|
|
143
158
|
|
|
144
159
|
### Existing Projects
|
|
145
160
|
|
|
146
|
-
You can also use this MCP server to configure an existing project for agentic development. Open your existing project folder and tell your AI assistant:
|
|
161
|
+
You can also use this MCP server to configure or modernize an existing project for agentic development. Open your existing project folder and tell your AI assistant:
|
|
147
162
|
|
|
148
|
-
>
|
|
163
|
+
> `/go upgrade the project`
|
|
149
164
|
|
|
150
|
-
The AI will read the exact blueprints from the MCP server and cleanly integrate them into your existing codebase.
|
|
165
|
+
The AI will read the exact blueprints from the MCP server and cleanly integrate them into your existing codebase (e.g., adding an `AGENTS.md`, setting up GitHub Actions, or integrating a package manager).
|
|
151
166
|
|
|
152
167
|
## Community
|
|
153
168
|
|
package/build/index.js
CHANGED
|
@@ -72,7 +72,7 @@ server.setRequestHandler(ListPromptsRequestSchema, async () => {
|
|
|
72
72
|
return {
|
|
73
73
|
prompts: [
|
|
74
74
|
{
|
|
75
|
-
name: "
|
|
75
|
+
name: "go",
|
|
76
76
|
description: "Conducts the C++ quick start interview to determine project stack.",
|
|
77
77
|
arguments: [],
|
|
78
78
|
},
|
|
@@ -80,7 +80,7 @@ server.setRequestHandler(ListPromptsRequestSchema, async () => {
|
|
|
80
80
|
};
|
|
81
81
|
});
|
|
82
82
|
server.setRequestHandler(GetPromptRequestSchema, async (request) => {
|
|
83
|
-
if (request.params.name !== "
|
|
83
|
+
if (request.params.name !== "go") {
|
|
84
84
|
throw new McpError(ErrorCode.InvalidRequest, `Prompt not found: ${request.params.name}`);
|
|
85
85
|
}
|
|
86
86
|
const metaSkillPath = path.join(DATA_DIR, "meta-quickstart", "SKILL.md");
|
package/build/index.js.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AACA,OAAO,EAAE,KAAK,EAAE,MAAM,mBAAmB,CAAC;AAC1C,OAAO,EAAE,IAAI,EAAE,MAAM,MAAM,CAAC;AAC5B,OAAO,EAAE,MAAM,EAAE,MAAM,2CAA2C,CAAC;AACnE,OAAO,EAAE,wCAAwC,EAAE,MAAM,+DAA+D,CAAC;AACzH,OAAO,EACL,wBAAwB,EACxB,sBAAsB,EACtB,0BAA0B,EAC1B,yBAAyB,EACzB,SAAS,EACT,QAAQ,GACT,MAAM,oCAAoC,CAAC;AAC5C,OAAO,KAAK,EAAE,MAAM,aAAa,CAAC;AAClC,OAAO,KAAK,IAAI,MAAM,MAAM,CAAC;AAC7B,OAAO,EAAE,aAAa,EAAE,MAAM,KAAK,CAAC;AACpC,OAAO,MAAM,MAAM,QAAQ,CAAC;AAC5B,OAAO,EAAE,SAAS,EAAE,MAAM,WAAW,CAAC;AAEtC,MAAM,SAAS,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;AAC/D,MAAM,QAAQ,GAAG,IAAI,CAAC,IAAI,CAAC,SAAS,EAAE,IAAI,EAAE,MAAM,CAAC,CAAC;AAEpD,MAAM,MAAM,GAAG,IAAI,MAAM,CACvB;IACE,IAAI,EAAE,qBAAqB;IAC3B,OAAO,EAAE,OAAO;CACjB,EACD;IACE,YAAY,EAAE;QACZ,OAAO,EAAE,EAAE;QACX,SAAS,EAAE,EAAE;KACd;CACF,CACF,CAAC;AAEF,2DAA2D;AAC3D,MAAM,CAAC,iBAAiB,CAAC,0BAA0B,EAAE,KAAK,IAAI,EAAE;IAC9D,MAAM,IAAI,GAAG,MAAM,EAAE,CAAC,OAAO,CAAC,QAAQ,CAAC,CAAC;IACxC,MAAM,SAAS,GAAG,EAAE,CAAC;IAErB,KAAK,MAAM,GAAG,IAAI,IAAI,EAAE,CAAC;QACvB,IAAI,GAAG,KAAK,iBAAiB;YAAE,SAAS,CAAC,qDAAqD;QAE9F,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,QAAQ,EAAE,GAAG,EAAE,UAAU,CAAC,CAAC;QACvD,IAAI,CAAC;YACH,MAAM,EAAE,CAAC,MAAM,CAAC,SAAS,CAAC,CAAC;YAC3B,SAAS,CAAC,IAAI,CAAC;gBACb,GAAG,EAAE,kBAAkB,GAAG,EAAE;gBAC5B,IAAI,EAAE,0BAA0B,GAAG,EAAE;gBACrC,QAAQ,EAAE,eAAe;gBACzB,WAAW,EAAE,gCAAgC,GAAG,EAAE;aACnD,CAAC,CAAC;QACL,CAAC;QAAC,OAAO,CAAC,EAAE,CAAC;YACX,sCAAsC;QACxC,CAAC;IACH,CAAC;IAED,OAAO,EAAE,SAAS,EAAE,CAAC;AACvB,CAAC,CAAC,CAAC;AAEH,MAAM,CAAC,iBAAiB,CAAC,yBAAyB,EAAE,KAAK,EAAE,OAAO,EAAE,EAAE;IACpE,MAAM,GAAG,GAAG,OAAO,CAAC,MAAM,CAAC,GAAG,CAAC;IAC/B,MAAM,KAAK,GAAG,GAAG,CAAC,KAAK,CAAC,0BAA0B,CAAC,CAAC;IAEpD,IAAI,CAAC,KAAK,EAAE,CAAC;QACX,MAAM,IAAI,QAAQ,CAAC,SAAS,CAAC,cAAc,EAAE,gBAAgB,GAAG,EAAE,CAAC,CAAC;IACtE,CAAC;IAED,MAAM,SAAS,GAAG,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC,CAAW,CAAC,CAAC;IACpD,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,QAAQ,EAAE,SAAS,EAAE,UAAU,CAAC,CAAC;IAE7D,IAAI,CAAC;QACH,MAAM,OAAO,GAAG,MAAM,EAAE,CAAC,QAAQ,CAAC,SAAS,EAAE,OAAO,CAAC,CAAC;QACtD,OAAO;YACL,QAAQ,EAAE;gBACR;oBACE,GAAG;oBACH,QAAQ,EAAE,eAAe;oBACzB,IAAI,EAAE,OAAO;iBACd;aACF;SACF,CAAC;IACJ,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,MAAM,IAAI,QAAQ,CAAC,SAAS,CAAC,cAAc,EAAE,uBAAuB,GAAG,EAAE,CAAC,CAAC;IAC7E,CAAC;AACH,CAAC,CAAC,CAAC;AAEH,gDAAgD;AAChD,MAAM,CAAC,iBAAiB,CAAC,wBAAwB,EAAE,KAAK,IAAI,EAAE;IAC5D,OAAO;QACL,OAAO,EAAE;YACP;gBACE,IAAI,EAAE,
|
|
1
|
+
{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AACA,OAAO,EAAE,KAAK,EAAE,MAAM,mBAAmB,CAAC;AAC1C,OAAO,EAAE,IAAI,EAAE,MAAM,MAAM,CAAC;AAC5B,OAAO,EAAE,MAAM,EAAE,MAAM,2CAA2C,CAAC;AACnE,OAAO,EAAE,wCAAwC,EAAE,MAAM,+DAA+D,CAAC;AACzH,OAAO,EACL,wBAAwB,EACxB,sBAAsB,EACtB,0BAA0B,EAC1B,yBAAyB,EACzB,SAAS,EACT,QAAQ,GACT,MAAM,oCAAoC,CAAC;AAC5C,OAAO,KAAK,EAAE,MAAM,aAAa,CAAC;AAClC,OAAO,KAAK,IAAI,MAAM,MAAM,CAAC;AAC7B,OAAO,EAAE,aAAa,EAAE,MAAM,KAAK,CAAC;AACpC,OAAO,MAAM,MAAM,QAAQ,CAAC;AAC5B,OAAO,EAAE,SAAS,EAAE,MAAM,WAAW,CAAC;AAEtC,MAAM,SAAS,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;AAC/D,MAAM,QAAQ,GAAG,IAAI,CAAC,IAAI,CAAC,SAAS,EAAE,IAAI,EAAE,MAAM,CAAC,CAAC;AAEpD,MAAM,MAAM,GAAG,IAAI,MAAM,CACvB;IACE,IAAI,EAAE,qBAAqB;IAC3B,OAAO,EAAE,OAAO;CACjB,EACD;IACE,YAAY,EAAE;QACZ,OAAO,EAAE,EAAE;QACX,SAAS,EAAE,EAAE;KACd;CACF,CACF,CAAC;AAEF,2DAA2D;AAC3D,MAAM,CAAC,iBAAiB,CAAC,0BAA0B,EAAE,KAAK,IAAI,EAAE;IAC9D,MAAM,IAAI,GAAG,MAAM,EAAE,CAAC,OAAO,CAAC,QAAQ,CAAC,CAAC;IACxC,MAAM,SAAS,GAAG,EAAE,CAAC;IAErB,KAAK,MAAM,GAAG,IAAI,IAAI,EAAE,CAAC;QACvB,IAAI,GAAG,KAAK,iBAAiB;YAAE,SAAS,CAAC,qDAAqD;QAE9F,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,QAAQ,EAAE,GAAG,EAAE,UAAU,CAAC,CAAC;QACvD,IAAI,CAAC;YACH,MAAM,EAAE,CAAC,MAAM,CAAC,SAAS,CAAC,CAAC;YAC3B,SAAS,CAAC,IAAI,CAAC;gBACb,GAAG,EAAE,kBAAkB,GAAG,EAAE;gBAC5B,IAAI,EAAE,0BAA0B,GAAG,EAAE;gBACrC,QAAQ,EAAE,eAAe;gBACzB,WAAW,EAAE,gCAAgC,GAAG,EAAE;aACnD,CAAC,CAAC;QACL,CAAC;QAAC,OAAO,CAAC,EAAE,CAAC;YACX,sCAAsC;QACxC,CAAC;IACH,CAAC;IAED,OAAO,EAAE,SAAS,EAAE,CAAC;AACvB,CAAC,CAAC,CAAC;AAEH,MAAM,CAAC,iBAAiB,CAAC,yBAAyB,EAAE,KAAK,EAAE,OAAO,EAAE,EAAE;IACpE,MAAM,GAAG,GAAG,OAAO,CAAC,MAAM,CAAC,GAAG,CAAC;IAC/B,MAAM,KAAK,GAAG,GAAG,CAAC,KAAK,CAAC,0BAA0B,CAAC,CAAC;IAEpD,IAAI,CAAC,KAAK,EAAE,CAAC;QACX,MAAM,IAAI,QAAQ,CAAC,SAAS,CAAC,cAAc,EAAE,gBAAgB,GAAG,EAAE,CAAC,CAAC;IACtE,CAAC;IAED,MAAM,SAAS,GAAG,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC,CAAW,CAAC,CAAC;IACpD,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,QAAQ,EAAE,SAAS,EAAE,UAAU,CAAC,CAAC;IAE7D,IAAI,CAAC;QACH,MAAM,OAAO,GAAG,MAAM,EAAE,CAAC,QAAQ,CAAC,SAAS,EAAE,OAAO,CAAC,CAAC;QACtD,OAAO;YACL,QAAQ,EAAE;gBACR;oBACE,GAAG;oBACH,QAAQ,EAAE,eAAe;oBACzB,IAAI,EAAE,OAAO;iBACd;aACF;SACF,CAAC;IACJ,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,MAAM,IAAI,QAAQ,CAAC,SAAS,CAAC,cAAc,EAAE,uBAAuB,GAAG,EAAE,CAAC,CAAC;IAC7E,CAAC;AACH,CAAC,CAAC,CAAC;AAEH,gDAAgD;AAChD,MAAM,CAAC,iBAAiB,CAAC,wBAAwB,EAAE,KAAK,IAAI,EAAE;IAC5D,OAAO;QACL,OAAO,EAAE;YACP;gBACE,IAAI,EAAE,IAAI;gBACV,WAAW,EACT,oEAAoE;gBACtE,SAAS,EAAE,EAAE;aACd;SACF;KACF,CAAC;AACJ,CAAC,CAAC,CAAC;AAEH,MAAM,CAAC,iBAAiB,CAAC,sBAAsB,EAAE,KAAK,EAAE,OAAO,EAAE,EAAE;IACjE,IAAI,OAAO,CAAC,MAAM,CAAC,IAAI,KAAK,IAAI,EAAE,CAAC;QACjC,MAAM,IAAI,QAAQ,CAChB,SAAS,CAAC,cAAc,EACxB,qBAAqB,OAAO,CAAC,MAAM,CAAC,IAAI,EAAE,CAC3C,CAAC;IACJ,CAAC;IAED,MAAM,aAAa,GAAG,IAAI,CAAC,IAAI,CAAC,QAAQ,EAAE,iBAAiB,EAAE,UAAU,CAAC,CAAC;IACzE,IAAI,CAAC;QACH,MAAM,OAAO,GAAG,MAAM,EAAE,CAAC,QAAQ,CAAC,aAAa,EAAE,OAAO,CAAC,CAAC;QAC1D,OAAO;YACL,WAAW,EAAE,sCAAsC;YACnD,QAAQ,EAAE;gBACR;oBACE,IAAI,EAAE,MAAM;oBACZ,OAAO,EAAE;wBACP,IAAI,EAAE,MAAM;wBACZ,IAAI,EAAE,OAAO;qBACd;iBACF;aACF;SACF,CAAC;IACJ,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,MAAM,IAAI,QAAQ,CAChB,SAAS,CAAC,aAAa,EACvB,6CAA6C,CAC9C,CAAC;IACJ,CAAC;AACH,CAAC,CAAC,CAAC;AAEH,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AAEjF,KAAK,UAAU,IAAI;IACjB,MAAM,EAAE,MAAM,EAAE,GAAG,SAAS,CAAC;QAC3B,IAAI,EAAE,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC;QAC3B,OAAO,EAAE;YACP,IAAI,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE,KAAK,EAAE,GAAG,EAAE;YACpC,IAAI,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE,KAAK,EAAE,GAAG,EAAE;YACpC,KAAK,EAAE,EAAE,IAAI,EAAE,SAAS,EAAE;SAC3B;KACF,CAAC,CAAC;IAEH,MAAM,IAAI,GAAG,MAAM,CAAC,IAAI;QACtB,CAAC,CAAC,QAAQ,CAAC,MAAM,CAAC,IAAI,EAAE,EAAE,CAAC;QAC3B,CAAC,CAAC,OAAO,CAAC,GAAG,CAAC,IAAI;YAChB,CAAC,CAAC,QAAQ,CAAC,OAAO,CAAC,GAAG,CAAC,IAAI,EAAE,EAAE,CAAC;YAChC,CAAC,CAAC,SAAS,CAAC;IAEhB,6DAA6D;IAC7D,IAAI,MAAM,CAAC,KAAK,IAAI,CAAC,IAAI,EAAE,CAAC;QAC1B,OAAO,CAAC,KAAK,CAAC,iDAAiD,CAAC,CAAC;QACjE,MAAM,SAAS,GAAG,IAAI,oBAAoB,EAAE,CAAC;QAC7C,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;QAChC,OAAO;IACT,CAAC;IAED,0BAA0B;IAC1B,MAAM,SAAS,GAAG,IAAI,wCAAwC,CAAC;QAC7D,kBAAkB,EAAE,GAAG,EAAE,CAAC,MAAM,CAAC,UAAU,EAAE;KAC9C,CAAC,CAAC;IAEH,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;IAEhC,MAAM,GAAG,GAAG,IAAI,IAAI,EAAE,CAAC;IAEvB,GAAG,CAAC,GAAG,CAAC,MAAM,EAAE,KAAK,EAAE,CAAC,EAAE,EAAE;QAC1B,OAAO,SAAS,CAAC,aAAa,CAAC,CAAC,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;IAC5C,CAAC,CAAC,CAAC;IAEH,MAAM,IAAI,GAAG,MAAM,CAAC,IAAI,IAAI,OAAO,CAAC,GAAG,CAAC,IAAI,IAAI,SAAS,CAAC;IAE1D,OAAO,CAAC,GAAG,CACT,iDAAiD,IAAI,IAAI,IAAI,UAAU,CACxE,CAAC;IACF,KAAK,CAAC;QACJ,KAAK,EAAE,GAAG,CAAC,KAAK;QAChB,IAAI,EAAE,IAAI;QACV,QAAQ,EAAE,IAAI;KACf,CAAC,CAAC;AACL,CAAC;AAED,IAAI,EAAE,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC"}
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: best-practices-code-review
|
|
3
|
-
description: Best practices for performing automated code reviews
|
|
3
|
+
description: Best practices for performing automated code reviews.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Code Review Best Practices
|
|
@@ -9,19 +9,28 @@ When tasked with reviewing code, the agent MUST follow these guidelines to provi
|
|
|
9
9
|
|
|
10
10
|
## 1. Style and Formatting
|
|
11
11
|
|
|
12
|
-
- Verify that the code complies with the project's chosen coding style
|
|
13
|
-
- Check if the code passes automated formatters
|
|
12
|
+
- Verify that the code complies with the project's chosen coding style and naming conventions.
|
|
13
|
+
- Check if the code passes the project's automated formatters or linters.
|
|
14
14
|
|
|
15
|
-
## 2.
|
|
15
|
+
## 2. Clean Code and Architecture
|
|
16
16
|
|
|
17
|
-
-
|
|
18
|
-
-
|
|
17
|
+
- Ensure functions and classes follow the Single Responsibility Principle.
|
|
18
|
+
- Look for opportunities to simplify complex logic or reduce code duplication (DRY).
|
|
19
|
+
- Check that variable and function names are descriptive and reveal intent. Enforce identifier length based on scope: short scopes should have short names (e.g., `i` in a loop), while larger scopes require longer, more descriptive names.
|
|
20
|
+
- Prefer verbs or verb phrases for function names (e.g., `calculateTotal()`) and nouns or noun phrases for variables and values (e.g., `totalAmount`).
|
|
21
|
+
- Flag functions that are excessively long or contain too many levels of nesting. **Exception**: A single, large `switch` statement is acceptable if it cleanly maps cases without complex embedded logic.
|
|
22
|
+
- Strongly prefer the "early-return" (guard clause) style to reduce nesting and improve readability, rather than wrapping the entire function body in a large `if` block.
|
|
23
|
+
- Code should be self-documenting. Comments should explain the "Why" (business logic/decisions), not the "What". Do not comment bad code; rewrite it instead.
|
|
24
|
+
- Avoid magic numbers in business logic. Extract them into meaningfully named constants to reveal their intent. (Hardcoded string literals are usually fine).
|
|
25
|
+
- Avoid boolean flag arguments as they imply the function does more than one thing. Split into two separate functions instead.
|
|
26
|
+
- Strive for strict architectural layering. Components should preferably communicate only with their immediate upper and lower layers. Flag designs that bypass adjacent layers or create circular dependencies.
|
|
19
27
|
|
|
20
|
-
## 3. Correctness and
|
|
28
|
+
## 3. Correctness and Logic
|
|
21
29
|
|
|
22
|
-
-
|
|
23
|
-
-
|
|
24
|
-
-
|
|
30
|
+
- Verify that the logic correctly implements the requested feature or bug fix.
|
|
31
|
+
- Look out for off-by-one errors, infinite loops, or unhandled edge cases.
|
|
32
|
+
- Check for thread-safety issues if concurrency is involved.
|
|
33
|
+
- Avoid redundant parameter validation. The caller is responsible for providing correct parameter values (Design by Contract). Use assertions to enforce preconditions during development. Only add explicit runtime checks if the function is intentionally designed to be called with invalid/unsafe values (e.g., parsing raw user input).
|
|
25
34
|
|
|
26
35
|
## 4. Test Coverage
|
|
27
36
|
|
|
@@ -26,3 +26,7 @@ Follow these best practices when managing C++ dependencies via Conan:
|
|
|
26
26
|
## 4. Reproducible Builds
|
|
27
27
|
|
|
28
28
|
- Generate and commit a `conan.lock` lockfile for stable and reproducible builds across developer machines and CI.
|
|
29
|
+
|
|
30
|
+
## 5. Virtual Environments
|
|
31
|
+
|
|
32
|
+
- If you encounter issues finding compilers or build tools while using Conan, consider sourcing or executing the Conan-generated environment setup scripts (e.g., `conanbuild.bat` / `conanbuild.sh` or `conanrun.bat` / `conanrun.sh`). These scripts properly configure the `PATH` and environment variables for the build tools.
|
|
@@ -34,5 +34,6 @@ When writing or modifying C++ code in this project, strictly adhere to the philo
|
|
|
34
34
|
- Apply `noexcept` consistently for functions that are guaranteed not to throw exceptions (especially move constructors and destructors).
|
|
35
35
|
- Use `[[nodiscard]]` on functions where ignoring the return value is likely a bug (e.g., error codes).
|
|
36
36
|
- Avoid C-style raw arrays; use `std::array` or `std::vector`. When creating `std::array`s, prefer `std::to_array` to deduce the array length automatically instead of hardcoding it (e.g., `auto arr = std::to_array({1, 2, 3});`).
|
|
37
|
+
- Always initialize variables before use. Check for and prevent potential memory leaks and dangling references.
|
|
37
38
|
|
|
38
39
|
These guidelines ensure the code remains safe, performant, and maintainable across the entire project.
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: go
|
|
3
3
|
description: Interviews the user about their preferred C++ stack and generates the specific project scaffolding skills.
|
|
4
4
|
---
|
|
5
5
|
|
|
@@ -58,7 +58,7 @@ If the project already exists, **DO NOT** conduct the full Mode A interview.
|
|
|
58
58
|
|
|
59
59
|
6. Proceed to **Step 2 (Implementation Plan)**.
|
|
60
60
|
|
|
61
|
-
**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
|
|
61
|
+
**If the user chooses Path 2 (Modernize & Augment):** 3. **Missing Tooling Interview**: Based on the auto-detected conventions, identify missing modern tooling (e.g., code hygiene like `.clang-format` and pre-commit hooks, `.clang-tidy`, testing frameworks, CI/CD, base configs like `.gitignore`). 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). **If CMake is used, suggest generating a `CMakePresets.json` to standardize build configurations.** 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)**.
|
|
62
62
|
|
|
63
63
|
---
|
|
64
64
|
|
|
@@ -66,13 +66,17 @@ If the project already exists, **DO NOT** conduct the full Mode A interview.
|
|
|
66
66
|
|
|
67
67
|
Based on the chosen Mode and the user's answers, create a formal implementation plan.
|
|
68
68
|
|
|
69
|
+
**CRITICAL TOOLING RULE**: For every tool, build system, CI provider, code quality checker, or package manager selected by the user (or universally required, like `base-configs`), you MUST actively attempt to fetch its corresponding `mcp://scaffold/<name>` resource using the `read_resource` tool before writing files. If a specific resource exists, you must follow it strictly. However, if no specific resource exists for a chosen tool, you should still proceed and do your best to configure it correctly using your general knowledge.
|
|
70
|
+
|
|
69
71
|
**If you are in Mode A (New Project):**
|
|
70
72
|
Your plan must outline the exact file templates and commands needed to bootstrap the cross-platform C++ project using the chosen stack.
|
|
71
73
|
|
|
72
74
|
- Prefer splitting build system files per artifact (e.g., using `add_subdirectory` or `subdir()`) instead of creating a single top-level monolithic build file.
|
|
73
75
|
- 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`).
|
|
74
|
-
- 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
|
|
76
|
+
- 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 --preset dev` or `conan install . --build=missing`).
|
|
77
|
+
- Plan to read the `scaffold-base-configs` skill and generate the `.gitignore`, `.gitattributes`, and `.clangd` files.
|
|
75
78
|
- 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.
|
|
79
|
+
- **CRITICAL**: If CMake is the build system, you MUST read the `scaffold-cmake-presets` skill and plan to generate a `CMakePresets.json` file.
|
|
76
80
|
|
|
77
81
|
**If you are in Mode B (Existing Project - Add Components):**
|
|
78
82
|
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).
|
|
@@ -81,19 +85,24 @@ If a layout refactoring was agreed upon, include that in the plan before adding
|
|
|
81
85
|
**If you are in Mode B (Existing Project - Modernize):**
|
|
82
86
|
Your plan must include:
|
|
83
87
|
|
|
88
|
+
- Reading the `scaffold-base-configs` skill to ensure `.gitignore`, `.gitattributes`, and `.clangd` are present and correct.
|
|
84
89
|
- Generating an `AGENTS.md` file using the `scaffold-agents` skill.
|
|
85
90
|
- Safely introducing the requested code quality tools (e.g., `.clang-format`, `.clang-tidy`).
|
|
86
91
|
- Applying the agreed-upon build system improvements directly to the existing build files.
|
|
87
92
|
- Implementing any layout refactoring if agreed upon.
|
|
93
|
+
- **CRITICAL**: If CMake is the build system and the user agreed to CMake improvements, you MUST read the `scaffold-cmake-presets` skill and plan to generate a `CMakePresets.json` file.
|
|
88
94
|
|
|
89
95
|
**Workspace Skills Generation (All Modes)**:
|
|
90
96
|
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`.
|
|
97
|
+
|
|
98
|
+
**Skill Modification Guidelines**: When upgrading or modifying existing skills, avoid big rewrites of an existing skill file. Do the minimal changes which add the new information and remove the obsolete information.
|
|
99
|
+
|
|
91
100
|
The workspace skills to create are:
|
|
92
101
|
|
|
93
102
|
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`).
|
|
94
103
|
2. `skills/build-project/SKILL.md`: Exact instructions and CLI commands for building the project (e.g., `cmake --build build -j`).
|
|
95
104
|
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.
|
|
96
|
-
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.
|
|
105
|
+
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. **Include the rule**: When creating or renaming a C++ namespace, review the names of the files and directories where members of the namespace are declared/defined; strive for consistency.
|
|
97
106
|
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.
|
|
98
107
|
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).
|
|
99
108
|
|
|
@@ -32,12 +32,17 @@ This repository is designed to be operated by a multi-agent system. When working
|
|
|
32
32
|
- **Role**: Core implementation and logic design.
|
|
33
33
|
- **Responsibilities**: Writes the actual C++ headers and source files. Enforces the configured coding style and ensures code compiles flawlessly with the configured C++ standard.
|
|
34
34
|
|
|
35
|
-
3. **
|
|
35
|
+
3. **Design / Code Review Agent**:
|
|
36
|
+
|
|
37
|
+
- **Role**: Architectural oversight and code quality enforcement.
|
|
38
|
+
- **Responsibilities**: Reviews the implementation plans and C++ code against the `best-practices-*` skills. Enforces Clean Code principles, architectural layering, and security rules before code is finalized.
|
|
39
|
+
|
|
40
|
+
4. **QA / Tester Agent**:
|
|
36
41
|
|
|
37
42
|
- **Role**: Quality assurance and test coverage.
|
|
38
43
|
- **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.
|
|
39
44
|
|
|
40
|
-
|
|
45
|
+
5. **Build System Agent**:
|
|
41
46
|
- **Role**: Managing build configurations and cross-platform support.
|
|
42
47
|
- **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.
|
|
43
48
|
|
|
@@ -35,3 +35,18 @@ When the user specifies Clang-Tidy for Code Quality, the agent MUST generate a `
|
|
|
35
35
|
```cmake
|
|
36
36
|
set(CMAKE_CXX_CLANG_TIDY "clang-tidy")
|
|
37
37
|
```
|
|
38
|
+
|
|
39
|
+
## Upgrading Existing Projects (Mode B)
|
|
40
|
+
|
|
41
|
+
When upgrading or modernizing an existing project that already has a `.clang-tidy` file:
|
|
42
|
+
|
|
43
|
+
1. **Preserve User Overrides**: You MUST read the existing `.clang-tidy` file before making any changes.
|
|
44
|
+
2. **Do Not Clobber**: Any specific checks explicitly disabled or added by the user (e.g., `-readability-magic-numbers`) MUST be preserved in the updated `.clang-tidy` configuration.
|
|
45
|
+
|
|
46
|
+
## Workspace Skill Generation
|
|
47
|
+
|
|
48
|
+
As part of the workspace skills generation, append the following to the `skills/best-practices-code-review/SKILL.md` (or similar code quality skill):
|
|
49
|
+
|
|
50
|
+
- Provide the official list of checks for reference: `https://clang.llvm.org/extra/clang-tidy/checks/list.html`
|
|
51
|
+
- Explain to the user that they can easily disable annoying checks by adding `-check-name` to the `Checks` string in their `.clang-tidy` file.
|
|
52
|
+
- Remind future agents that when modifying this workspace skill or the `.clang-tidy` file, they must respect the **Skill Modification Guidelines** and strictly preserve the user's custom overrides.
|
|
@@ -19,7 +19,7 @@ The root `CMakeLists.txt` must be written using Modern CMake (target-based) prin
|
|
|
19
19
|
1. **Minimum Required Version**: Start with `cmake_minimum_required(VERSION 3.20)` (or higher).
|
|
20
20
|
2. **Project Definition**: `project(ProjectName VERSION 0.1.0 LANGUAGES CXX)`
|
|
21
21
|
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`.
|
|
22
|
-
4. **Targets and Modularity**: The agent MUST iterate over the libraries and tools requested by the user during the
|
|
22
|
+
4. **Targets and Modularity**: The agent MUST iterate over the libraries and tools requested by the user during the go prompt interview.
|
|
23
23
|
- **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.
|
|
24
24
|
- Avoid global state functions like `include_directories()`.
|
|
25
25
|
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> ...)`.
|
|
@@ -47,4 +47,4 @@ cmake --build build -j
|
|
|
47
47
|
|
|
48
48
|
## Workflow Integration
|
|
49
49
|
|
|
50
|
-
This skill is utilized by the `
|
|
50
|
+
This skill is utilized by the `go` prompt when the user selects CMake as their build system.
|
|
@@ -1,15 +1,15 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: scaffold-code-
|
|
3
|
-
description: Generates code
|
|
2
|
+
name: scaffold-code-hygiene
|
|
3
|
+
description: Generates code hygiene configurations including .clang-format and pre-commit hooks.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# Code
|
|
6
|
+
# Code Hygiene Skill
|
|
7
7
|
|
|
8
|
-
This skill instructs the agent on how to scaffold
|
|
8
|
+
This skill instructs the agent on how to scaffold formatting and pre-commit hooks for the C++ project.
|
|
9
9
|
|
|
10
10
|
## Requirements
|
|
11
11
|
|
|
12
|
-
When the user specifies Code Quality Enforcement (like pre-commit hooks, formatting
|
|
12
|
+
When the user specifies Code Quality Enforcement (like pre-commit hooks, formatting), generate the following files in the project root.
|
|
13
13
|
|
|
14
14
|
### 1. `.clang-format`
|
|
15
15
|
|
|
@@ -26,19 +26,7 @@ TabWidth: 4
|
|
|
26
26
|
UseTab: Never
|
|
27
27
|
```
|
|
28
28
|
|
|
29
|
-
### 2. `.
|
|
30
|
-
|
|
31
|
-
Create a file named `.clang-tidy` with the following exact content:
|
|
32
|
-
|
|
33
|
-
```yaml
|
|
34
|
-
Checks: "-*,readability-*,bugprone-*,performance-*,modernize-*,clang-analyzer-*,cppcoreguidelines-*,-cppcoreguidelines-pro-bounds-pointer-arithmetic,-cppcoreguidelines-pro-bounds-constant-array-index"
|
|
35
|
-
WarningsAsErrors: ""
|
|
36
|
-
HeaderFilterRegex: ""
|
|
37
|
-
AnalyzeTemporaryDtors: false
|
|
38
|
-
FormatStyle: none
|
|
39
|
-
```
|
|
40
|
-
|
|
41
|
-
### 3. `.pre-commit-config.yaml`
|
|
29
|
+
### 2. `.pre-commit-config.yaml`
|
|
42
30
|
|
|
43
31
|
Create a file named `.pre-commit-config.yaml` with the following exact content:
|
|
44
32
|
|
|
@@ -56,3 +44,11 @@ repos:
|
|
|
56
44
|
- id: clang-format
|
|
57
45
|
types_or: [c++, c]
|
|
58
46
|
```
|
|
47
|
+
|
|
48
|
+
### 3. Installation Instructions
|
|
49
|
+
|
|
50
|
+
In the generated build or configuration workspace skill, instruct the agent to note that the user should install pre-commit hooks:
|
|
51
|
+
|
|
52
|
+
```bash
|
|
53
|
+
pre-commit install
|
|
54
|
+
```
|
|
@@ -43,4 +43,4 @@ cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=build/conan_toolchain.cmake -DCMAKE_B
|
|
|
43
43
|
|
|
44
44
|
## Workflow Integration
|
|
45
45
|
|
|
46
|
-
This skill is utilized by the `
|
|
46
|
+
This skill is utilized by the `go` prompt when the user selects Conan for Project Packaging.
|
|
@@ -26,4 +26,4 @@ The generated workflow must:
|
|
|
26
26
|
|
|
27
27
|
## Workflow Integration
|
|
28
28
|
|
|
29
|
-
This skill is utilized by the `
|
|
29
|
+
This skill is utilized by the `go` prompt when the user selects GitHub Actions as their CI Provider.
|
|
@@ -27,4 +27,4 @@ The generated pipeline must:
|
|
|
27
27
|
|
|
28
28
|
## Workflow Integration
|
|
29
29
|
|
|
30
|
-
This skill is utilized by the `
|
|
30
|
+
This skill is utilized by the `go` prompt when the user selects GitLab CI as their CI Provider.
|
|
@@ -21,6 +21,7 @@ When invoking this skill to scaffold a new C++ project, the agent MUST create th
|
|
|
21
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
22
|
2. **`include/`**: Contains the public headers API.
|
|
23
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
|
+
- **Avoid Redundancy**: Check for redundancies in file naming. For example, there is not much point in having `include/foo/foo-bar.hpp` when it could simply be `include/foo/bar.hpp`.
|
|
24
25
|
3. **`tests/`**: Contains all testing code. For multiple targets, group tests by target (e.g., `tests/libA/`, `tests/libB/`).
|
|
25
26
|
4. **`examples/`** _(Optional)_: Contains example code showing how to use the library/project.
|
|
26
27
|
5. **`external/`** _(Optional)_: Contains third-party dependencies (if not using a package manager like vcpkg or FetchContent).
|
|
@@ -57,4 +58,4 @@ If no refactoring plan was approved, safely _add_ the new component directories
|
|
|
57
58
|
|
|
58
59
|
## Workflow Integration
|
|
59
60
|
|
|
60
|
-
This skill is utilized by the `
|
|
61
|
+
This skill is utilized by the `go` prompt 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.
|
|
@@ -47,4 +47,4 @@ cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=[path to vcpkg]/scripts/buildsystems/
|
|
|
47
47
|
|
|
48
48
|
## Workflow Integration
|
|
49
49
|
|
|
50
|
-
This skill is utilized by the `
|
|
50
|
+
This skill is utilized by the `go` prompt when the user selects vcpkg for Project Packaging or Dependency Management.
|
package/package.json
CHANGED
|
@@ -1,33 +0,0 @@
|
|
|
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
|
-
```
|