Init Project

/init-project

> Run the Activation preflight from METHODOLOGY.md before proceeding. If inactive, no-op and exit. > > Additional activation behavior for this command: see Step 0 "Global activation mode" below.

Scaffold a new project with the standard AGENTS.md hierarchy, CLI tool config, and gitignore.

Steps

0. Run discovery

0a. Global activation mode — read this before any other discovery work.

Read ~/.claude/agentic-engineering.json. Expected shape: { "mode": "opt-out" | "opt-in", "profile": "relaxed" | "default" | "strict", "preset": "lean" | "standard" | "strict" | null, "set_at": "" }. If missing or unreadable, assume mode=opt-out, profile=default, and preset=null. The preset field is optional and back-compat - when null/missing, the direct profile field is used. When writing this file during init (if creating it for the first time), include "preset": "standard" as a sensible default that maps to profile=default via the preset table in METHODOLOGY.md.

• If mode=opt-in: prompt the user before doing any scaffolding:

> "agentic-engineering is installed in opt-in mode. Activate it for this project? [Y/n]"

Accept y / yes / 1 / empty (Enter) as yes. Accept n / no / 2 as no.

• On yes: the scaffolded AGENTS.md ## Activation section (always emitted by Step 3) carries the active agentic-engineering: opt-in line at the top of the section - this is the "opt-in activation case" of the section's conditional assembly (see the Step 3 template). Do not add a second bare agentic-engineering: opt-in line elsewhere; the ## Activation section is the single source of placement truth.

• The profile line is handled by the same ## Activation section per its profile sub-block: an active agentic-engineering-profile: line is woven in only when INITPROFILE (captured in the 0a-profile dialogue) is relaxed or strict, the user explicitly requests a profile during Step 1, or a global non-default profile is set in ~/.claude/agentic-engineering.json. If INITPROFILE is null/default and the user does not mention a profile, the section emits the commented profile helper instead of an active line (the global default applies).

• On no: stop /init-project here. Print: "Skipped - no scaffolding written. Rerun /init-project to activate later, or set --mode=opt-out via a reinstall." Exit.

• If mode=opt-out (default): proceed as today. Do NOT prompt. Mention in the Step 12 summary: "This project will use agentic-engineering by default. To disable it in this project, uncomment the pre-staged agentic-engineering: opt-out marker in the ## Activation section of AGENTS.md (the scaffolding already wrote it there as a comment)."

• If the config file is missing or malformed: treat as mode=opt-out and proceed without prompting (back-compat with pre-feature installs).

This step runs before Step 0 discovery below because an opt-in decline should short-circuit the entire command.

Up-front configuration (additive; Enter keeps today's defaults at every step).

Before scaffolding, walk through a short set of questions that explain how this project will be configured and let you change the few settings that most affect how work gets done. Each question has a plain-English explanation, the options, and an "Enter to keep the current default" line. Pressing Enter through all of them lands you on exactly the standard defaults - nothing is written that you do not choose.

0a-mode. How this project activates (explanation; reconciles with the 0a prompt above).

The resolved global mode was determined in 0a from ~/.claude/agentic-engineering.json. Explain it in plain English; do NOT add a second prompt and do NOT write the global config file from here.

• If global mode = opt-out (the default): print, as information only (no prompt):

> This project will use agentic-engineering automatically (global mode is "opt-out": > active everywhere unless a project opts out). To turn it OFF for THIS project only, > uncomment the agentic-engineering: opt-out marker in the ## Activation section of > AGENTS.md (the scaffolding writes that section with the marker pre-staged as a comment). > To change the GLOBAL default for all projects, run /agentic-disable --global (this > command will not change global settings for you).

Write no marker line here - the ## Activation section emitted by Step 3 already carries the commented opt-out marker (inert until uncommented). The Step 12 reminder carries the same pointer.

• If global mode = opt-in: print this explanation IMMEDIATELY BEFORE the existing 0a

"[Y/n]" activation prompt (do not duplicate that prompt - it stays as the single mode decision):

> Global mode is "opt-in": agentic-engineering activates only in projects that > explicitly opt in. The next question asks whether to opt THIS project in (it writes > agentic-engineering: opt-in to AGENTS.md if you say yes). To change the global > default instead, run /agentic-disable --global after setup.

Then proceed to the existing 0a [Y/n] prompt unchanged.

0a-profile. Risk profile (additive; Enter keeps current defaults).

Explain and offer the risk profile. This controls how much independent review each change gets. Present:

> How strict should the review workflow be in this project? This sets the risk profile. > > relaxed - Single-file behavioral edits and small UI-only changes run directly with a > self-check. Lighter review, faster iteration. Good for solo/early projects. > default - Single-file behavioral edits run directly; multi-file, new-file, shared, or > risky changes get a Worker + independent Skeptic. (This is the default.) > strict - The broadest review coverage: even UI-copy tweaks, renames, and wording fixes > get Worker + Skeptic. Use when correctness matters most. > > Press Enter to keep the current default (no project override - the global setting applies). > Or type relaxed / default / strict.

Capture the answer as INITPROFILE. Empty (Enter) = "keep current default": INITPROFILE = null, write NOTHING. Typing 'default' is also a no-op write (do not pin default explicitly). Only 'relaxed' or 'strict' set INIT_PROFILE to that value.

0a-config. Four project settings that change how work gets done (additive; Enter keeps each default).

Q1-Q3 map to keys in .agentic/config.json (written once in Step 6f). Each answer is captured into a variable substituted into that single seed write - there is no separate config write. Empty input keeps the documented default exactly. Q4 does not write to config.json; it gates Step 6g only.

Q1 - Auto-merge on green CI?

> After a pull request's CI checks all pass and no reviewer has requested changes, > should the workflow squash-merge it automatically? "No" keeps the usual flow where a > human merges (draft -> CI -> ready -> review -> you merge). "Yes" merges for you the > moment CI is green and the PR is ready. > > Press Enter to keep the default (No). Or type y to enable auto-merge.

Capture as INIT_AUTOMERGE. Enter / n / no -> false (default). y / yes -> true.

Q2 - Model profile for spawned agents: default or budget?

> When the workflow spawns helper agents (architects, engineers, reviewers), "default" > picks the right-capability model per task. "budget" routes eligible spawns to a > cheaper, faster tier to cut cost - at some capability cost on harder tasks. Security > reviews always use the strongest model regardless of this setting. > > Press Enter to keep the default ("default"). Or type budget.

Capture as INIT_MODELPROFILE. Enter / default -> "default". budget -> "budget". Any other input: re-prompt once, then fall back to "default".

Q3 - Diagnose failures with a debugger pass?

> When an automated quality gate fails (a test or check breaks during an Elevated-risk > change), should the workflow run a focused Debugger diagnosis before each fix attempt? > "Yes" tends to produce better-targeted fixes at the cost of an extra step per failure. > "No" goes straight to the fix attempt (today's behavior). > > Press Enter to keep the default (No). Or type y to enable debugger-on-failure.

Capture as INIT_DEBUGGER. Enter / n / no -> false (default). y / yes -> true.

Q4 - Per-role / antagonist-reviewer model routing? (Pi / oh-my-pi only)

> On Pi, the workflow can run each role (architect, engineer, reviewer, ...) on a > model you choose, and run the adversarial reviewer on a DIFFERENT model than the one > that wrote the code - a true antagonist (e.g. an Opus author reviewed by GPT or GLM). > Enabling this seeds an editable ~/.agentic/role-models.yml you fill in with the > models you have in Pi. Ignored on Claude/Codex/Gemini. > > Press Enter to skip (no routing file; Pi uses session defaults). Or type y to seed it.

Capture as INIT_ROLEMODELS. Enter / n / no -> skip. y / yes -> seed in Step 6g.

Note: the other config keys (capability preflight, the QA-method toggles, Storybook, theme) are left at their safe defaults and detected automatically where relevant. They live in .agentic/config.json and are explained by /agentic-status (How to adjust) and re-runnable via /init-project. They are intentionally not asked here to keep setup short.

0b. Project discovery — once activation is resolved, silently scan the project to derive as many configuration values as possible.

Project name — check in order: package.json .name (strip leading @scope/); pyproject.toml [project] name; Cargo.toml [package] name; go.mod module path last segment; build.gradle/settings.gradle rootProject.name; git remote origin URL last path segment (strip .git); current directory basename. First match wins. Steps 1–5 = high confidence; steps 6–7 = low confidence (annotate as "(inferred)").

Description — check in order: package.json .description; pyproject.toml [project] description; first non-title, non-badge paragraph of README.md. First match wins.

Tracks — two passes: (1) check for apps/, packages/, services/, libs/ at repo root; a subdirectory under these is a track if it contains its own package.json, pyproject.toml, go.mod, or Cargo.toml; (2) scan top-level subdirectories (excluding .git, .claude, node_modules, dist, build, .next, coverage, __pycache__, .venv, venv) for their own manifest file. Deduplicate. 0 candidates = no signal (omit). 1 candidate = low confidence (annotate). 2+ candidates = high confidence.

Database CLI — scan package.json deps, requirements.txt/pyproject.toml deps, Cargo.toml, go.mod. Match in order: @prisma/client or schema.prisma → recommend prisma; pg/pg-promise/psycopg2/psycopg/asyncpg → recommend psql; mongoose/mongodb/pymongo/motor → recommend mongosh; mysql2/pymysql/aiomysql → recommend mysql; better-sqlite3/sqlite3/aiosqlite → recommend sqlite3. No match = no signal (omit). Multiple database matches = list both and ask user to confirm in the confirmation step.

Web UI — scan package.json deps and scripts. Match in order: next dep + dev script → Next.js (default port 3000); @remix-run/react or @remix-run/node → Remix (port 3000); react-scripts → CRA (port 3000); vite dep + dev script (check vite.config.ts/vite.config.js for server.port; default 5173) → Vite; @vue/cli-service → Vue CLI (port 8080); svelte + vite → SvelteKit (port 5173); astro → Astro (port 4321). Package manager: prefer pnpm if pnpm-lock.yaml exists, yarn if yarn.lock, bun if bun.lock/bun.lockb, else npm. No match = no signal (omit). Compose dev command as [package-manager] run dev (or [pm] dev for bun).

Tracker — check in order: (1) if ## Tracker or ## Linear already exists in AGENTS.md → tracker is already configured, stop tracker detection, annotate as "(already configured)"; (2) check ~/.claude.json mcpServers for keys linear or mcp-atlassian; (3) scan git log --oneline -50 for ticket patterns [A-Z][A-Z0-9]{1,9}-\d+ — if a prefix appears 3+ times, flag as a signal; (4) check for .linear/ directory. Signals: Linear MCP entry or .linear/ dir = Linear signal; mcp-atlassian entry = Jira signal; commit patterns alone = low confidence. No signals = no prompt (leave tracker unconfigured).

GitHub CLI — run which gh. If present, treat as a high-confidence signal and include the gh line in ## Tools automatically. If absent, omit.

Release signals — scan for any of: release or deploy scripts in package.json; CHANGELOG.md at repo root; vercel.json; Dockerfile; .github/workflows/ files matching release*.yml or deploy*.yml; fly.toml; railway.toml. If any are found, note as a release signal and record the detected type (e.g. "vercel.json", "GitHub Actions release workflow", "Dockerfile"). No match = no signal (omit from Step 1).

Benchmark signals — scan for: bench or benchmark or profile scripts in package.json; a benches/ or benchmarks/ directory at repo root; k6 config files; vitest bench invocations in scripts; pytest-benchmark in requirements.txt/pyproject.toml. If any are found, note as a perf signal and record the detected type (e.g. "vitest bench scripts in package.json", "benchmarks/ directory"). No match = no signal (omit from Step 1).

Dep-audit command — derived from the package manager already detected in the Web UI pass. Map: pnpm-lock.yaml → pnpm audit; yarn.lock → yarn audit; package-lock.json or npm detected → npm audit; requirements.txt/pyproject.toml (poetry or pip) → pip-audit; Cargo.lock → cargo audit; go.sum → govulncheck. No lockfile detected = no signal (omit). This is a pure derivation from existing package manager detection — no extra scan needed.

Auto-memory directory - memory lives at /.agentic/memory/. This is project-local (not under the sensitive .claude/ path) and not platform-hashed. /init-project writes this path as autoMemoryDirectory in Step 7. Note: autoMemoryDirectory is ignored if set in the checked-in .claude/settings.json for security - it must be written to .claude/settings.local.json (the gitignored user-local file). Only Claude Code honors this setting; Codex/Cursor/Gemini adapters do not consume it.

1. Present discovery results

Present the results of Step 0 in a single message:

Discovery complete. Here's what I found:

  Project name:  [value]         ([source, e.g. "from package.json"])
  Description:   [value]         ([source])
  Tracks:        [list]          ([e.g. "detected as monorepo — apps/"])
  Database CLI:  [value]         ([e.g. "detected @prisma/client"])
  Web UI:        [command, port] ([e.g. "detected Next.js"])
  GitHub CLI:    gh               (detected on PATH)
  Tracker:       [value]         ([e.g. "from AGENTS.md ## Linear" or "detected in ~/.claude.json"])
  Release:       [detected type]  ([e.g. "vercel.json", "GitHub Actions release workflow"])
  Benchmarks:    [detected type]  ([e.g. "vitest bench scripts in package.json"])
  Dep audit:     [command]        ([e.g. "npm audit", derived from package manager])
  Auto-memory:   [selected path]  ([e.g. "selected from 3 existing dirs - most recent" or "greenfield - new dir will be created"])

Fields not shown were not detected and are optional — you can add them now or later.

Press Enter to accept all, or tell me what to change (e.g. "project name is widgetco", "no web UI", "no gh", "use Jira").

Show only fields where a value was found. Omit fields with no detection. Annotate low-confidence values with "(inferred — verify)".

Override grammar — the user may correct any field in free-form. Recognized patterns:

• "project name is X" → override project

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Space-Dinosaurs
• Source: Space-Dinosaurs/DinoStack
• License: Apache-2.0
• Homepage: https://docs.dinostack.ai

Install and usage instructions live in the source repository linked above.