/setup-project

Set up development standards for this project by detecting the tech stack, interviewing the user, and generating contextual rules and skills into .claude/rules/ and .claude/skills/.

All template files are located at ${CLAUDE_PLUGIN_ROOT}/assets/templates/.

Phase 1 -- Auto-Detection

Scan the project automatically. Do NOT ask the user anything yet.

Language and Framework Detection

Use Glob to check for the presence of these files:

• package.json -- Node.js / JavaScript / TypeScript
• tsconfig.json or **/*.ts -- TypeScript confirmation
• *.csproj or *.sln -- C# / .NET
• go.mod -- Go
• Cargo.toml -- Rust
• pyproject.toml, setup.py, requirements.txt -- Python
• Makefile -- build system

Framework Detection

Check for framework-specific config files:

• next.config.* -- Next.js
• angular.json -- Angular
• vite.config.* -- Vite
• nuxt.config.* -- Nuxt
• svelte.config.* -- SvelteKit
• astro.config.* -- Astro
• remix.config.* -- Remix
• gatsby-config.* -- Gatsby
• Program.cs with WebApplication -- ASP.NET
• serverless.yml or serverless.ts -- Serverless Framework
• sam-template.yaml or template.yaml -- AWS SAM
• cdk.json -- AWS CDK
• terraform directory -- Terraform
• Dockerfile -- Containerized
• docker-compose*.yml -- Docker Compose

Test Runner Detection

Check for test configuration files:

• jest.config.* or "jest" key in package.json -- Jest
• vitest.config.* -- Vitest
• pytest.ini, pyproject.toml with [tool.pytest] -- pytest
• xunit or nunit references in *.csproj -- .NET test frameworks
• *_test.go files -- Go testing
• playwright.config.* -- Playwright
• cypress.config.* -- Cypress

Linter and Formatter Detection

Check for:

• .eslintrc* or eslint.config.* -- ESLint
• .prettierrc* or prettier.config.* -- Prettier
• biome.json -- Biome
• .editorconfig -- EditorConfig
• ruff.toml or [tool.ruff] in pyproject.toml -- Ruff
• .golangci.yml -- golangci-lint
• rustfmt.toml -- rustfmt

Existing Configuration Detection

Check for:

• .claude/ directory -- existing Claude configuration
• .claude/rules/ -- existing rules
• .claude/skills/ -- existing skills
• CLAUDE.md -- existing project instructions

Persistence Detection

Check for:

• prisma/ or schema.prisma -- Prisma ORM
• **/migrations/ directory -- database migrations
• docker-compose*.yml with database service names (postgres, mysql, redis, mongo)
• *.entity.ts, *.model.ts, **/models/, **/entities/ -- ORM entities
• knexfile.* -- Knex
• drizzle.config.* -- Drizzle
• sequelize in package.json -- Sequelize
• alembic/ or alembic.ini -- Alembic (Python)
• Entity Framework references in *.csproj -- EF Core

Collect all findings into a detection summary. Proceed to Phase 2.

Phase 2 -- Confirm and Classify

Present the detection summary to the user in a clear format:

Detected:
  Languages: [list]
  Frameworks: [list]
  Test runners: [list]
  Linters: [list]
  Persistence: [list]
  Existing config: [list or "none"]

Then ask ONE question at a time. Wait for each answer before asking the next.

Question 1: Confirm Detection

Ask the user to confirm the detected languages and frameworks. Ask if anything is missing or incorrect.

Question 2: Project Type

Ask the user to pick the project type:

• script -- One-off or scheduled script
• CLI -- Command-line tool
• library -- Reusable package/library
• desktop -- Desktop application (Photino or similar)
• web app -- Web application (frontend, backend, or full-stack)
• SaaS -- Multi-tenant SaaS product
• serverless -- Serverless functions / Lambda

Question 3: Architecture Style

Ask the user to pick the architecture style:

• simple -- Flat structure, minimal abstraction
• CRUD -- Standard CRUD with service layer
• DDD -- Domain-driven design with aggregates and bounded contexts
• event-driven -- Event sourcing, message queues, pub/sub
• microservices -- Distributed services with independent deployment

Question 4: Deployment Target

Ask the user to pick the deployment target:

• local-only -- Runs locally, no deployment
• container -- Docker / Kubernetes
• serverless -- Lambda / Cloud Functions / Azure Functions
• edge -- Edge runtime (Cloudflare Workers, Deno Deploy, Vercel Edge)
• desktop -- Desktop distribution

Question 4b: TDD Discipline

Ask the user if they want strict TDD discipline enforced:

• strict -- RED/GREEN/REFACTOR cycle enforced, vertical slices required, test distribution targets
• standard -- Testing required but TDD cycle not strictly enforced
• minimal -- Tests recommended but not mandatory (scripts, prototypes)

Default to strict for web apps, SaaS, libraries, and DDD projects. Default to standard for CLIs and serverless. Default to minimal for scripts.

Question 4c: Documentation Level

Ask the user what documentation to generate:

• full -- User stories, user flows, tech specs, ADRs, API docs, changelog
• standard -- Tech specs, API docs, changelog (no formal user stories/flows)
• minimal -- Changelog only

Default to full for DDD, SaaS, and web apps. Default to standard for libraries and CLIs. Default to minimal for scripts.

Phase 3 -- External Dependencies

Ask the user about external dependencies. Ask ONE question at a time.

Question 5: Databases and Storage

Ask what databases or storage systems the project uses (if any). Examples: PostgreSQL, MySQL, MongoDB, Redis, S3, SQLite. Skip if no persistence was detected and user confirms none.

Question 6: External APIs

Ask what external APIs or third-party services the project integrates with (if any). Examples: Stripe, Auth0, SendGrid, OpenAI, AWS services.

Question 7: Replay Proxies

If external APIs were listed, ask which ones need replay proxies for testing. Explain briefly: replay proxies record real API responses and replay them in CI so tests are fast and deterministic.

Phase 4 -- Project Context

Ask the user for project context. Ask ONE question at a time.

Question 8: Project Description

Ask for a brief (1-3 sentence) description of what the project does.

Question 9: Domain Concepts

Ask for key domain concepts or terms that are important for understanding the codebase. Examples: "tenant", "workspace", "pipeline", "widget". Skip if the user says none.

Question 10: Team Conventions

Ask if there are any team conventions or patterns that should be documented. Examples: "we use barrel exports", "all API responses use a wrapper type", "we prefix interfaces with I". Skip if the user says none.

Phase 5 -- Output Generation

Generate all output files. Read each template from ${CLAUDE_PLUGIN_ROOT}/assets/templates/ before copying.

Every generated file MUST start with this comment on the first line:

<!-- Generated by dev-standards plugin. Customize as needed. -->

If a template already includes this comment, do not duplicate it.

Step 1: Create Directories

Create .claude/rules/ and .claude/skills/ directories if they do not exist.

mkdir -p .claude/rules .claude/skills

Step 2: Copy Always-Loaded Rules

Read and copy these templates to .claude/rules/:

• ${CLAUDE_PLUGIN_ROOT}/assets/templates/rules/version-control.md -> .claude/rules/version-control.md
• ${CLAUDE_PLUGIN_ROOT}/assets/templates/rules/code-quality.md -> .claude/rules/code-quality.md

Copy them as-is. They have no placeholders that need filling.

Step 3: Generate Architecture Rule

Read ${CLAUDE_PLUGIN_ROOT}/assets/templates/rules/architecture.md. Replace these placeholders with values from the interview:

• {{project_type_description}} -- Replace with the project type and architecture style. Example: "Web application using DDD architecture, deployed to containers."
• {{active_decisions}} -- Replace with "No active architecture decisions documented yet. Add decisions here as they are made." (The user will fill this in over time.)
• {{active_migrations}} -- Replace with "No active migrations. Document ongoing migrations here." (The user will fill this in over time.)
• {{project_constraints}} -- Replace with deployment target and any team conventions mentioned. Example: "Deployed to Kubernetes. All API responses use a standard wrapper type."

Write the result to .claude/rules/architecture.md.

Step 4: Copy Language-Specific Rules

For each detected language, read the corresponding template and copy it to .claude/rules/:

Language	Template file	Output file
TypeScript	typescript.md	.claude/rules/typescript.md
C#	csharp.md	.claude/rules/csharp.md
Python	python.md	.claude/rules/python.md
Go	go.md	.claude/rules/go.md
Rust	rust.md	.claude/rules/rust.md

Copy each as-is. The templates already include correct glob paths in their frontmatter.

Step 5: Generate Testing Rule

If any test runner was detected, read ${CLAUDE_PLUGIN_ROOT}/assets/templates/rules/testing.md and replace these placeholders:

• {{test_runner}} -- The detected or confirmed test runner (e.g., "vitest", "jest", "pytest", "go test")
• {{e2e_framework}} -- The detected e2e framework (e.g., "playwright", "cypress"). If none detected, use "not configured"
• {{replay_proxy}} -- The replay proxy tool if specified by the user, otherwise "not configured"
• {{external_services}} -- The external services that need replay proxies, or "none configured"

Write the result to .claude/rules/testing.md.

Step 6: Copy Data Integrity Rule

If persistence was detected (databases, ORMs, migrations), read and copy ${CLAUDE_PLUGIN_ROOT}/assets/templates/rules/data-integrity.md to .claude/rules/data-integrity.md.

Update the paths frontmatter to match the project's actual directory structure for database-related code. For example, if the project uses src/db/ instead of db/, adjust accordingly.

Step 6b: Generate TDD Rule

If TDD discipline is strict or standard, read ${CLAUDE_PLUGIN_ROOT}/assets/templates/rules/tdd.md and copy to .claude/rules/tdd.md.

If TDD discipline is standard, add a note at the top: "TDD cycle is recommended but not strictly enforced for this project."

If TDD discipline is minimal, skip this rule.

Step 6c: Generate DDD Rule

If the architecture style is DDD or event-driven, read ${CLAUDE_PLUGIN_ROOT}/assets/templates/rules/ddd.md and copy to .claude/rules/ddd.md.

Step 6d: Generate Documentation Rule

If documentation level is full or standard, read ${CLAUDE_PLUGIN_ROOT}/assets/templates/rules/documentation.md and copy to .claude/rules/documentation.md.

If documentation level is standard, remove the "User Stories" and "User Flows" sections from the generated file (those are only for full level).

Step 7: Copy Skill Templates

Based on the project type, read and copy skill templates to .claude/skills/. Replace all {{placeholders}} in each skill with values from the interview.

Common placeholders across skills:

• {{framework}} -- The primary framework (e.g., "Next.js", "ASP.NET", "FastAPI")
• {{test_runner}} -- The test runner command
• {{e2e_framework}} -- The e2e framework
• {{api_style}} -- "REST" or "GraphQL" (infer from detection or ask)
• {{validation_library}} -- Detected validation library or "project's validation approach"
• {{auth_pattern}} -- "middleware auth" or "decorator auth" or similar (infer from detection)
• {{orm}} -- The detected ORM or "repository pattern"

Project type to skill mapping:

Project Type	Skills to Copy
web app	webapp/add-endpoint, webapp/add-page, webapp/add-data-model
SaaS	webapp/add-endpoint, webapp/add-page, webapp/add-data-model
serverless	serverless/add-function
CLI	cli/add-command
library	library/add-public-api
desktop	desktop/add-message
script	(no skills)

If the architecture style is DDD or event-driven, also copy:

• ddd/add-aggregate, ddd/add-domain-event (implementation skills)
• ddd/define-context, ddd/spec-domain (design skills)

TDD discipline to skill mapping:

TDD Level	Skills to Copy
strict	tdd/implement-slice
standard	tdd/implement-slice
minimal	(no TDD skill)

Documentation level to skill mapping:

Doc Level	Skills to Copy
full	docs/write-user-story, docs/define-user-flow, docs/write-tech-spec
standard	docs/write-tech-spec
minimal	(no doc skills)

For each skill, create the directory and copy the file:

.claude/skills/<skill-name>/SKILL.md

For example, webapp/add-endpoint/SKILL.md becomes .claude/skills/add-endpoint/SKILL.md.

Step 8: Generate CLAUDE.md

Generate a thin .claude/CLAUDE.md file. This file provides project context to Claude without duplicating rule content.

<!-- Generated by dev-standards plugin. Customize as needed. -->

# Project

{{project_description}}

## Type

{{project_type}} / {{architecture_style}} / {{deployment_target}}

## Key Technologies

{{comma-separated list of languages, frameworks, and key tools}}

## Domain Concepts

{{domain_concepts or "No domain concepts documented yet."}}

## Team Conventions

{{team_conventions or "No team conventions documented yet."}}

## Rules

Project rules are loaded automatically from `.claude/rules/`. See that directory for active standards.

## Skills

Project skills are loaded automatically from `.claude/skills/`. See that directory for available workflows.

Replace all {{placeholders}} with actual values from the interview.

Step 9: Handle Existing Configuration

If .claude/ already existed:

• Do NOT overwrite any existing files without asking the user first
• For each file that would conflict, ask the user whether to overwrite, skip, or merge
• If CLAUDE.md already exists at the project root, do not touch it -- only generate .claude/CLAUDE.md

Completion

After generating all files, present a summary:

Setup complete. Generated files:

Rules (loaded automatically by Claude):
  .claude/rules/version-control.md
  .claude/rules/code-quality.md
  .claude/rules/architecture.md
  .claude/rules/<language>.md (for each language)
  .claude/rules/testing.md (if tests detected)
  .claude/rules/tdd.md (if TDD strict or standard)
  .claude/rules/data-integrity.md (if persistence detected)
  .claude/rules/ddd.md (if DDD or event-driven architecture)
  .claude/rules/documentation.md (if docs full or standard)

Skills (available workflows):
  .claude/skills/<skill-name>/SKILL.md (for each skill)
  Including: implement-slice, define-context, spec-domain,
  write-user-story, define-user-flow, write-tech-spec (based on selections)

Project context:
  .claude/CLAUDE.md

All files are customizable. Edit them to refine your project standards.