plan · codewithmukesh — Claude Code skill for .NET planning

---
name: plan
description: >
  Enter plan mode for .NET projects with architecture awareness. Analyzes tasks
  through the lens of supported architectures (VSA, Clean Architecture, DDD,
  Modular Monolith) and produces structured implementation plans before any code
  is written. Use when: "plan", "let's plan", "think through", "design this",
  "how should I implement", or any non-trivial task requiring 3+ steps.
---

# /plan -- Architecture-Aware Planning

## What

Enters a structured planning mode that considers the project's architecture pattern
before producing an implementation plan. Instead of jumping straight to code, this
command forces a deliberate pause to:

- Identify the project's current architecture (or recommend one)
- Map the task to affected layers, modules, and boundaries
- Produce a numbered implementation plan with clear steps
- Iterate on the plan until it is solid before writing any code

Plans are living documents -- if something goes sideways during implementation,
stop and re-plan rather than pushing through a broken approach.

## When

- Non-trivial tasks requiring 3 or more implementation steps
- Tasks involving architectural decisions (new modules, cross-cutting concerns, new bounded contexts)
- Features that touch multiple layers (API, application, domain, infrastructure)
- Refactoring that could affect multiple consumers
- Any time the user says "plan", "think through", "design this", or "how should I approach"

**Skip planning for:** Single-file changes, simple bug fixes, typo corrections, config tweaks.

## How

### Step 1: Understand the Task

Check `docs/specs/` for an approved spec covering this task — if one exists, it is
the source of truth: map its acceptance criteria to plan steps and skip ahead to
Step 2. If the feature is spec-worthy (too big to describe in one sentence) and no
spec exists, recommend `/spec` first instead of planning on assumptions.
Otherwise, clarify what the user wants to build with focused questions.
Do not assume requirements that were not stated.

### Step 2: Detect Architecture

Use the `architecture-advisor` skill to determine the project's architecture:
- Check for existing architecture markers (folder structure, project references, patterns)
- If no architecture is established, run the architecture questionnaire
- Load the appropriate architecture-specific skill (vertical-slice, clean-architecture, ddd)

### Step 3: Map Affected Areas

Identify every layer, module, and boundary the task touches:
- Which projects/folders will have new or modified files?
- Are there cross-cutting concerns (auth, caching, validation, logging)?
- What existing code will be impacted? Use `find_references` and `find_callers` MCP tools for blast radius.
- Are there database migrations needed?

### Step 4: Produce the Plan

Output a numbered plan with this structure:

```
## Plan: [Task Title]

**Architecture:** [Detected architecture]
**Affected layers:** [List]
**Estimated steps:** [Count]

### Steps
1. [Step] -- [Which file/layer] -- [Why this order]
2. ...

### Open Questions
- [Anything that needs user input before proceeding]

### Risks
- [Potential issues and mitigations]
```

### Step 5: Iterate

Present the plan and ask: "Does this plan look right, or should I adjust anything?"
Revise until the user confirms. Only then proceed to implementation.

## Example

```
User: /plan Add a product catalog feature with search and filtering

Claude: Let me analyze your project structure first...

## Plan: Product Catalog Feature

**Architecture:** Vertical Slice Architecture
**Affected layers:** Features/, Infrastructure/Persistence/, Tests/
**Estimated steps:** 6

### Steps
1. Create Product entity + EF config -- Domain layer -- Foundation for everything else
2. Add migration -- Infrastructure -- Schema must exist before features
3. Scaffold GetProducts feature (with filtering) -- Features/Products/ -- Read path first
4. Scaffold CreateProduct feature -- Features/Products/ -- Write path
5. Add integration tests -- Tests/Features/Products/ -- Verify both features
6. Wire up OpenAPI metadata -- Features/Products/ -- Documentation

### Open Questions
- Should search be full-text (PostgreSQL tsvector) or simple LIKE?
- Do products need categories/tags for filtering?

Does this plan look right, or should I adjust anything?
```

## Related

- `/spec` -- Write the spec first for features too big to describe in one sentence
- `/scaffold` -- Generate the files once the plan is approved
- `/verify` -- Run verification after implementing the plan