Skip to content
Back to skills

Moxpp Add Project

ASecurity

Adds a new sub-project to an existing MoxPP workspace. Use when the developer wants to add a new executable, library, or utility project to the build system.

  • 23 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added May 27, 2026
data-aipythongoc++c#bash

Works with

  • cli

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add Moxibyte/MoxPP --skill moxpp-add-project --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Moxpp Add Project?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Moxpp Add Project
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/moxibyte-moxpp-add-project/badge)](https://www.skillsdirectory.com/skills/moxibyte-moxpp-add-project)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: moxpp-add-project
description: Adds a new sub-project to an existing MoxPP workspace. Use when the developer wants to add a new executable, library, or utility project to the build system.
---

# MoxPP Add Project

Help the developer add a new sub-project to this MoxPP workspace. Work through the steps below interactively — ask for any information you don't already have before making changes.

## Steps

### 1. Check architecture compatibility

Read `mox.lua` and check `cmox_project_architecture`:
- **`single`**: Adding a second project requires switching to `flat`, `hierarchical`, or `manual` first. Warn the user and ask how they want to proceed before continuing.
- **`flat`**: New project goes into `src/<project-name>/`.
- **`hierarchical`**: Ask for the group name. New project goes into `src/<group>/<project-name>/`.
- **`manual`**: Remind the user they must manually add an `include` call in `cmox_function_includeprojects()` inside `mox.lua`.

### 2. Gather project information

Ask the user for the following if not already provided via $ARGUMENTS:
- **Project name** — used in the Visual Studio solution (PascalCase recommended)
- **Output name** — binary/library filename, snake_case. Default: snake_case of project name.
- **Language** — `C++` (default), `C`, or `C#`
- **Output type**:
  - `console` — console executable
  - `windowed` — GUI executable (no console window, Windows only)
  - `sharedlib` — shared library (.dll / .so / .dylib)
  - `staticlib` — static library
  - `utility` — custom build actions, no code output
  - `none` — header-only, no build output
- **Dependencies on other projects** — list project names to `links {}` against. Ask separately if build order matters (`dependson {}`).
- **Unit test requirement** — if output type is `sharedlib` or `staticlib`, ask whether the unit test project should link against this project (adds `mox_test_requirement()`).
- **Conan dependencies** — any additional Conan packages needed in `<name>/<version>` format. Ask whether any need options changed. (Only relevant for `C++` and `C` projects; skip for `staticlib` and `none` since they don't link Conan deps directly.)

### 3. Generate a UUID

Generate a UUID by running `python -c "import uuid; print(uuid.uuid4())"` via Bash and use the output in the new `build.lua`.

### 4. Create the project directory and `build.lua`

Create the directory according to the architecture layout determined in step 1.

Write `build.lua` using the gathered information:

```lua
mox_project("<ProjectName>", "<output_name>")

mox_cpp()        -- or mox_c() / mox_cs()

mox_console()    -- or mox_windowed() / mox_sharedlib() / mox_staticlib() / mox_utility() / mox_none()

uuid("<generated-uuid>")

-- mox_test_requirement()  -- uncomment if this lib is needed by the unit tests

-- links {
--     "OtherProject",
-- }

-- dependson {
--     "OtherProject",
-- }
```

Uncomment and fill in only the sections that apply. Remove unused comment blocks.

### 5. Create a starter source file

For `console` and `windowed` projects: create `<project-dir>/main.cpp` with a minimal `main()` function.
For `sharedlib` or `staticlib`: create `<project-dir>/<output_name>.h` and `<project-dir>/<output_name>.cpp` with an empty placeholder. Also create `<project-dir>/dummy.cpp` containing a single empty translation unit (`// dummy`). This file is required on Windows — without at least one compiled `.cpp`, MSBuild will not produce a `.lib` output and any project that links against this one will fail to build.
For `utility` or `none`: no source file needed.

### 6. Update `conanfile.py` and `CLAUDE.md` (if new Conan packages were requested)

Add the new `self.requires(...)` calls and any `self.options[...]` entries to `conanfile.py`. Then update the `## Conan Dependencies` section in `CLAUDE.md` to include the newly added packages.

### 7. Update `mox.lua` if needed

- If architecture was changed from `single` to `flat`/`hierarchical`: update `cmox_project_architecture`.
- For `manual` architecture: remind the user to add the `include` call in `cmox_function_includeprojects()`.
- If this is the intended startup project for Visual Studio, update `startproject` in `cmox_function_setupworkspace()`.

### 8. Confirm and summarize

List all files created or modified and remind the user to run `mox init` (or `./mox.sh init`) to regenerate project files.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.