/standalone

description:  >
  Create an initial Claude Code setup for a brownfield project with a single-application topology
  (no sub-projects or monorepo structure).
disable-model-invocation: true
user-invocable: true

Claude Code Standalone Project Scaffolding

Your goal is to create an initial setup for Claude Code in a pre-existing standalone project, including agent instructions and context information. You work in close collaboration with the user to obtain the required base knowledge about the goals and structure of the project.

**Additional user arguments**: $ARGUMENTS

**Language hint**: Always create all generated document content in English for consistency across the codebase, while continuing to speak to the user in the language of their choice.

**Platform hint**: Instructions and templates assume a Linux host with GNU coreutils. Adapt to the detected user OS.

• macOS — Substitute BSD equivalents for GNU-only utilities.
• Windows — Still use `.sh` files (skip irrelevant `chmod +x`), assuming Git Bash is available at runtime.

Highlight this requirement in the Debriefing. Set `"shell": "bash"` on command hooks in `settings.json`. Omit the entire `sandbox` block from `settings.json` as long as bash sandboxing is unsupported.

Agent Content Principles

When generating content for `.md` files below, you are writing prompts and context for other AI coding agents. Follow these principles to optimally tailor your instructions to their needs:

• **Concise** — Minimize token usage. Prefer keywords and terse bullet points over prose.
• **Structured** — Use compact Markdown to delineate connected aspects.
• **Actionable** — Generate concrete operational directives, as abstract guidelines may lead to over-refusal or handwaving.

Avoid aspirational quality statements, general engineering practices, blanket prohibitions.

• **Referential** — Provide pointers to key code files the agents can read themselves.

Do not describe how code works in agent instructions as such duplication leads to drift.

• **Scoped** — Context is hierarchical. The CLAUDE.md must only contain core project identity and semantics.

Rules and agent instructions progressively disclose domain- and task-specific knowledge.

• **Durable** — Only include details that remain invariant under normal codebase evolution.

Reference namespaces or search terms instead of single artifacts.

Workflow

Begin execution by creating a formal task list for progress tracking using the `TaskCreate` tool (if available). Create a task for each of the following phases (##) and sub-phases (###). This protects you from accidentally skipping phases and visualizes the progress for the user.

Phase 1: Reconnaissance

1. Use `Explore` agents to scan the repository and build an initial understanding of its structure

• Number of source files, excluding dependency and build directories (e.g. `vendor/`, `node_modules/`, `dist/`).
• Top-level directory content that hints at used technologies (e.g. `package.json`, `composer.json`, `Cargo.toml`, `go.mod`, `Makefile`, `Dockerfile`)
• Existing documentation (e.g. `README.md`, `CONTRIBUTING.md` or `docs/`)
• Style (e.g. imperative mood) and common patterns (e.g. ticket numbers) in commit messages from the `git log`.

2. Read any discovered documentation and technology manifest files 3. Check for an existing `CLAUDE.md` or `.claude/` directory — if found, establish if the user wants to amend or replace these. 4. Summarize your findings and conclusions briefly for the user and ask if they want to comment or add information.

Phase 2: User Interview

Interview the user to establish the project's base details. Use `AskUserQuestion` where appropriate to keep the conversation structured.

Offer pre-defined choice options if likely answers to a question are already known from context. However, **never skip parts of the interview** even if all answers could be inferred. The purpose of the interview is to include tribal project knowledge not captured by reconnaissance.

Question Catalogue

1. What is the name of the project? 2. Who is the project creator and/or maintainer (company/organization)? 3. What is the overall purpose of the project (one-sentence summary)? 4. What is the production scale of the project (data size, number of users)? 5. What are the main technologies used (programming language, framework, deployment...)? 6. What are key concepts or vocabulary that every developer needs to learn on their first day? 7. What are the key source directories? 8. How are automated tests organized and run? 9. Are there tools for linting or other automated code quality control?

Phase 3: Generate Artifacts

3a — Claude Code Settings

1. Copy the [settings template](./templates/settings-template.json) to `<project-dir>/.claude/settings.json` 2. Copy the [statusline template](./templates/statusline.sh) to `<project-dir>/.claude/statusline.sh` and make it executable (`chmod +x`). 3. Replace the `{{PLACEHOLDERS}}` based on acquired context. 4. Inject `{{GITIGNORE-EXCLUSIONS}}` into the sandbox config, limiting write access to version-controlled files only.

3b — Central CLAUDE.md

1. Copy the [template](./templates/CLAUDE-template.md) to `<project-dir>/CLAUDE.md` 2. Replace the `{{PLACEHOLDERS}}` based on acquired context. 3. For placeholders that do not have corresponding answers, ask the user whether they want to provide an answer, generate an answer from code exploration, or omit the section.

3c — Local Override Files

If a `.gitignore` file exists in the project root, append the following entries (if not already present):

/CLAUDE.local.md
/.claude/settings.local.json
/.claude/plans/

3d — Code Navigation

The approach depends on the source file count established in Phase 1. A dedicated explorer agent only pays off in codebases with more than a hundre