dotfiles/.config/opencode/commands/init.md

---
description: Initialize or update a project with scaffold, docs, and .memory files — adapts to both new and existing projects.
---

You are initializing or updating a project. Follow these steps in order.

Project hint (may be empty):
$ARGUMENTS

## Step 1 — Explore current project state (delegate to `explorer`)

Delegate to the `explorer` subagent first, before any questions, to determine whether this is a new or existing project.

- Ask explorer to inspect the working tree for project-defining artifacts, including:
  - source files and source directories
  - `README.md`, `AGENTS.md`, `docs/`
  - stack markers such as `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `composer.json`
  - git markers such as `.git/`
  - any similar files that strongly indicate an existing project
- Ask explorer to return:
  - classification: `new_project` or `existing_project`
  - inferred project name, purpose, and tech stack (with confidence)
  - which required scaffold files already exist vs are missing
  - whether `.git/` exists

## Step 2 — Clarify (Lead, one round max)

Use the `question` tool for at most one round, adapting to Step 1 findings.

- If explorer's classification confidence is low (e.g., directory has only a few ambiguous files), include the classification itself as a question to confirm.
- If classification is `existing_project`:
  - confirm or correct explorer inferences (name, one-sentence purpose, stack)
  - ask only for unknown or low-confidence fields
  - do **not** ask whether to initialize git if `.git/` already exists
  - do **not** ask for files/details that are already present and clear
- If classification is `new_project`:
  - ask:
    - project name and one-sentence purpose
    - primary language / framework / tech stack
    - whether to initialize a git repository

## Step 3 — Scaffold (delegate to `coder`)

Delegate to the `coder` subagent with explicit mode (`new_project` or `existing_project`) and the file existence map from Step 1.

- Required scaffold targets:
  - `README.md` — title, purpose, tech stack, quick-start, project structure overview
  - `.github/copilot-instructions.md` — real instruction file containing shared project guidance
  - `AGENTS.md` — symlink to `.github/copilot-instructions.md`
  - `CLAUDE.md` — symlink to `.github/copilot-instructions.md`
  - `.cursorrules` — symlink to `.github/copilot-instructions.md`
  - `docs/architecture.md` — stub with title + purpose
  - `.gitignore` — add stack-appropriate ignores (e.g., `node_modules/`, `__pycache__/`, `target/`)
  - `.memory/` — create and/or update `knowledge.md`, `decisions.md`, `plans/`, `research/`
  - other stack-specific scaffold files if clearly implied (e.g., `package.json`, `pyproject.toml`)
- If `new_project`:
  - create all required scaffold files/directories
- If `existing_project`:
  - create or fill in only missing pieces
  - **do not overwrite existing files**
  - explicitly instruct coder to check existence before creating each target
  - ensure `.github/copilot-instructions.md` exists as the real instruction file
  - create missing symlinks:
    - `ln -s .github/copilot-instructions.md AGENTS.md`
    - `ln -s .github/copilot-instructions.md CLAUDE.md`
    - `ln -s .github/copilot-instructions.md .cursorrules`
  - if `.github/copilot-instructions.md` is missing but `AGENTS.md` exists as a real file, move AGENTS content into `.github/copilot-instructions.md`, then recreate `AGENTS.md` as a symlink
  - if `.memory/` is missing, create the full `.memory/` directory structure
  - examples:
    - if `README.md` exists and only `AGENTS.md` is missing, create `AGENTS.md` as a symlink to `.github/copilot-instructions.md`
    - if `docs/` is missing, create it and add `docs/architecture.md`

## Step 4 — Documentation review (delegate to `librarian`)

Always delegate to the `librarian` subagent, for both new and existing projects.

- Ensure `README.md` is accurate and complete for the current project state.
- Ensure `.github/copilot-instructions.md` exists and captures project-specific workflow decisions from Step 2.
- Verify `AGENTS.md`, `CLAUDE.md`, and `.cursorrules` are symlinks to `.github/copilot-instructions.md`.
- Ensure stubs are explicitly marked for later completion.
- Keep edits additive and non-destructive for existing projects.

## Step 5 — Initialize or update `.memory` project overview (Lead)

Always create or update `.memory/knowledge.md` for this project.

- Read existing `.memory/knowledge.md` (if present) to avoid duplicate sections.
- Create or update a project overview section with:
  - Project name
  - Purpose and stack
  - Key files (`README.md`, `AGENTS.md`, `docs/architecture.md` when present)
  - Notable init/update decisions
- Add markdown cross-references to related sections in `.memory/decisions.md` when applicable.

## Step 6 — Git handling (delegate to `coder`)

Delegate git operations to `coder` based on discovered state.

- If `.git/` already exists:
  - skip `git init`
  - stage only newly created or modified files from this init/update flow
  - create a commit
- If `.git/` does not exist:
  - use Step 2 answer to decide whether to run `git init`
  - if initialized, stage only newly created or modified files and create a commit
- Commit message should be concise and conventional, e.g.:
  - `chore: initialize project scaffold` (new project)
  - `chore: add missing project scaffolding` (existing project)

## Completion report

Summarize:
- Files created and files updated, with purpose.
- Decisions made and decisions deferred.
- What the user should fill in next (stubs, open questions, follow-up documentation).