/setup-generate

namespace: aiwg
name: setup-generate
platforms: [all]
description: "Generate a `setup.manifest.yaml` file for a project using the `setup.aiwg.io/v1`"

setup-generate

Generate a `setup.manifest.yaml` file for a project using the `setup.aiwg.io/v1` SetupManifest language.

For AIWG itself, reuse the published provider-orchestrated `setup.aiwg.yaml` rather than generating a replacement. It bootstraps a healthy CLI, then uses `aiwg setup --scope project`, `aiwg setup --review`, and `aiwg setup --apply`. These commands save, review, and apply an interview plan; they do not change SetupManifest execution mode or make `setup-run` an interactive installer.

Trigger Phrases

• "generate a setup manifest for [project]"
• "create installer for [project]"
• "scaffold setup manifest"
• "write a setup.manifest.yaml for [directory]"
• "generate install workflow for [project]"
• "generate dev installer for [project]"

Parameters

project-dir (positional, optional)

Path to the project root. Defaults to `.`.

--output (optional)

Manifest path to create. Default: `./setup.manifest.yaml`.

--name (optional)

Manifest `metadata.name`. Default: package name or project directory name.

--type (optional)

Install type: `user`, `developer`, or `ci`. Default: `developer`.

--platform (optional)

Target platform: `linux`, `macos`, `windows`, or `docker`.

--force (optional)

Overwrite existing generated manifest/script files.

--type (optional)

Install type to generate: `user`, `developer`, or `ci`. Default: `user`.

• `user` — production/end-user deployment (default, behavior unchanged from previous versions)
• `developer` — local development environment standup with OS configuration
• `ci` — headless pipeline setup

When `--type developer`, output filename is `setup.dev.manifest.yaml`. When `--type user`, output is `setup.user.manifest.yaml` (or `setup.manifest.yaml` if no type is specified for backwards compatibility).

--interactive (optional)

Ask clarifying questions before generating.

Execution Flow

Phase 1: Discovery

1. Read the project root to understand structure:

• Check for `package.json`, `requirements.txt`, `Cargo.toml`, `go.mod`, `Makefile`, etc.
• Check for `README.md`, `INSTALL.md`, `docs/install.md`
• Check for existing `setup.manifest.yaml`

2. Parse local project cues when they are available; the CLI entrypoint emits a conservative starter manifest and leaves richer project-specific authoring to the agent skill. 3. If `--interactive`, ask:

• What OSes must be supported?
• What are the hard prerequisites (git, node, python version)?
• Is there a config directory that needs to be created?
• Does the project chain sub-projects?

Developer Install Discovery (when `--type developer`)

Additional discovery steps for developer manifests:

1. Scan for dev-specific indicators: `.nvmrc`, `.tool-versions`, `mise.toml`, `pyproject.toml [dev]`, `Brewfile`, `.devcontainer/` 2. Detect Docker-in-dev usage patterns (bind mounts, live reload, `--watch` flags) 3. If `--interactive` or key information is absent, ask mandatory interactive questions:

• "What OS(es) do developers use? (linux/macos/windows)"
• "Is there a local domain for HTTPS development? (e.g., myapp.local)"
• "Do developers need GPU access for local dev? (yes/no)"
• "Is SSH key setup required as a project prerequisite? (yes/no)"
• "Which IDE(s) are standard? (vscode/jetbrains/none)"
• "Any kernel/OS parameters required? (inotify watches, vm.max_map_count, etc.)"
• "Does the project use a local certificate authority for HTTPS dev?"

Phase 2: Assemble Manifest

Build the manifest YAML following this priority order:

1. **metadata block** — include `install_type` matching `--type` flag (default: `developer`) 2. **platform block** — from `--platform` or detected by project type 3. **params block** — standard params: `INSTALL_DIR`, `BRANCH` (default: `main`); add `CONFIG_DIR` if a config step is needed 4. **prerequisites block** — from project type (e.g., `node` for npm projects, `python3` for Python) 5. **steps block** — construct from script templates:

• Always start with a `clone` or `verify-existing` detect step
• Add `install-deps-*` steps for each target platform
• Add `configure` step if config files are needed
• End with a `verify` step

6. **recovery_procedures block** — always include a `full-reset` fallback

Developer Manifest Assembly Rules (when `--type developer`)

When assembling developer manifests, apply these additional rules:

**os_config block** — emit entries based on detection:

| Condition | Entry | |-----------|-------| | Linux + Docker in project | `docker-group` (requires_relogin: true) | | Linux + file watchers detected (webpack/jest/vite/nodemon) | `inotify-watches` | | Linux + Elasticsearch/Weaviate/OpenSearch detected | `vm-mapcount` | | macOS | `xcode-cli-tools` (interactive: true) | | HTTPS dev + local domain | mkcert install step (not os_config, but a script step) | | GPU dev | `nvidia-container-toolkit` os_config entry |

**params** — emit with `interactive_required: true` for:

• `LOCAL_DOMAIN` — when HTTPS dev or local domain detected
• `SSH_EMAIL` — when SSH key setup is required
• `GIT_USER_NAME`, `GIT_USER_EMAIL` — when git config step is included
• `GIT_GPG_KEY_ID` — when GPG signing is requested
• `IDE` — when IDE-specific extension installation is included

**steps** — emit os-config steps for each os_config entry:

- id: apply-docker-group
  type: os-config
  config_id: docker-group
  depends_on: [install-docker]
  platform: linux

**dev-specific prerequisites** — add as detected:

• `nvm` or `mise` — when `.nvmrc` or `.tool-versions` found
• `mkcert` — when HTTPS dev requested
• `act` — when GitHub Actions local testing detected

Docker-based Project Detection

When `docker-compose.yml` or `compose.yaml` is found during Phase 1 discovery, apply these additional behaviors: