Stack packs

A stack pack contributes project-convention knowledge for one tech stack — detection logic, stack-aware skills, MCP suggestions, and validation commands. Adapters consume that data and emit it; stack packs themselves never write files.

First-party packs at v1.0

Pack	Languages	Detection signals	Default validation
`node-ts`	TypeScript, JavaScript	`tsconfig.json` + `typescript` in `package.json`	lint, typecheck, test, format-check, build
`node-js`	JavaScript	`package.json` without `tsconfig.json`	lint, test, format-check
`python`	Python	`pyproject.toml` / `requirements.txt` / `.python-version`	ruff, mypy, pytest
`react`	JavaScript, TypeScript	`react` dep in `package.json`	(composes with node-ts / node-js)
`go`	Go	`go.mod`	(per pack spec)

Auto-detection and confidence

Each pack reports its detection confidence:

high — multiple strong signals (manifest dep + framework marker file).
medium — one strong signal or multiple weak signals.
low — single weak signal.
none — no match.

The CLI default-selects all high matches and surfaces medium for manual confirmation. You can override:

shell

npx aidokit@alpha init --stack node-ts,react

Composition

Multiple packs can match a project. A Next.js app would match node-ts + react at high confidence. Their skill lists, MCP suggestions, and validation commands are concatenated and de-duplicated by the CLI; the adapter emits the merged result.

When two packs conflict on the same id (e.g. both propose a test validation command), the highest-confidence pack wins by default; the CLI surfaces the conflict for explicit resolution.

What each pack contributes

node-ts (Standard)

Skills: typescript-conventions, vitest-patterns, esm-imports, error-envelope-conventions, package-json-discipline — each marked <REVIEW REQUIRED> so you confirm or edit.
MCPs: context7.
Validation: derived from your package.json scripts via ProjectContext.parsedManifests — lint, typecheck, test, format-check, build.
Package manager: auto-detected from lockfile (pnpm-lock.yaml → pnpm; yarn.lock → yarn; bun.lockb → bun; else npm).

node-js (Standard)

Sibling of node-ts for plain JavaScript projects. Skills are JS-flavoured. ESLint / Prettier / Vitest validation commands.

python (Standard)

Skills: python-conventions, pytest-patterns, type-hints, python-error-handling, pyproject-discipline.
MCPs: context7.
Validation: ruff, mypy, pytest.
Detection: three signals with high/medium/low confidence.

react (Standard)

Frontend-focused. Composes with node-ts or node-js. Triggers stack.hasFrontend for MCPs like Playwright and Chrome DevTools.

go (Standard)

Proves the StackPack contract on a non-JS/Python stack.

Adding extra packs after init

shell

npx aidokit skills add <skill-id>     # add one skill
npx aidokit sync                       # re-emit from updated packs

What stack packs cannot do

By design, stack packs:

Cannot emit files directly — they return data; the adapter emits.
Cannot execute shell commands or make network calls.
Cannot define MCPs inline — only reference catalog ids.
Cannot suggest security-sensitive MCPs.
Cannot import or be imported by adapters.

This is the cardinal rule that makes packs portable across adapters by construction.

Third-party packs

Post-v1.0, third-party packs publish under any npm scope or unscoped. Convention: @scope/aidokit-stack-pack-<name> or aidokit-stack-pack-<name>. The @aidokit/* scope is reserved.

shell

npx aidokit search stack-pack