Plan

codewithmukesh/dotnet-claude-kit/skills/plan

by codewithmukesh23300897f4d1No license754 starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 2 months ago

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.

Instructions onlyProductivity & WorkflowSoftware Development
AI-generated overview

Enters a structured planning mode for .NET projects, mapping tasks to architecture layers before any code is written.

What it does
This skill puts the agent into a deliberate planning mode for .NET work, first identifying the project's architecture pattern (such as Vertical Slice, Clean Architecture, DDD, or Modular Monolith) and then mapping the task to affected layers, modules, and boundaries. It produces a numbered implementation plan with steps, open questions, and risks, and iterates with the user until the plan is confirmed. It also checks for an approved spec and recommends writing one first when the feature is too large to describe in a sentence.
When to use it
Use it for non-trivial tasks needing three or more implementation steps, architectural decisions, features spanning multiple layers, or refactoring that affects several consumers. It is meant for requests phrased as plan, think through, design this, or how should I implement. Simple single-file changes, bug fixes, and config tweaks are explicitly out of scope.
Requirements
Instructions only; no scripts are shipped. It expects a .NET project context and references companion skills (architecture-advisor, vertical-slice, clean-architecture, ddd, /spec, /scaffold, /verify) plus MCP tools such as find_references and find_callers, and it may read docs/specs/.

/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]
### Steps1. [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
### Steps1. Create Product entity + EF config -- Domain layer -- Foundation for everything else2. Add migration -- Infrastructure -- Schema must exist before features3. Scaffold GetProducts feature (with filtering) -- Features/Products/ -- Read path first4. Scaffold CreateProduct feature -- Features/Products/ -- Write path5. Add integration tests -- Tests/Features/Products/ -- Verify both features6. 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

Source and attribution

Source:codewithmukesh/dotnet-claude-kitinskills/planat commit2330089

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

More from codewithmukesh/dotnet-claude-kit

Wrap Up

codewithmukesh

Captures end-of-session work, pending tasks and learnings into a handoff file, and reloads it at session start.

Productivity & Workflow754updated 2 months ago

Workflow Mastery

codewithmukesh

Claude Code workflow mastery for .NET developers. Covers parallel execution with git worktrees, plan mode strategy, verification loops, auto-formatting hooks, permission setup for dotnet CLI, prompting techniques, subagent patterns, and context discipline — token budget management, MCP-first navigation, lazy loading, and subagent isolation — all adapted for the .NET ecosystem. Load this skill when setting up Claude Code for a .NET project, optimizing workflows, running parallel sessions, when context is running low or sessions feel sluggish, when exploring a large codebase efficiently, or when the user mentions "productivity", "workflow", "parallel", "worktree", "plan mode", "permissions", "hooks", "10x", "setup Claude Code", "speed up development", "context", "tokens", "budget", "running out of context", "too many files", or "large codebase". Inspired by tips from Boris Cherny (creator of Claude Code) and the Anthropic team.

Awaiting classification754updated 2 months ago

Vertical Slice

codewithmukesh

Guides .NET developers in structuring applications with Vertical Slice Architecture, covering feature folders, endpoint grouping and handler patterns.

Software Development754updated 2 months ago

Testing

codewithmukesh

Testing strategy for .NET 10 applications. Covers xUnit v3, WebApplicationFactory for integration tests, Testcontainers for real database testing, Verify for snapshot testing, and the AAA pattern. Load this skill when writing tests, setting up test infrastructure, reviewing test coverage, or when the user mentions "test", "xUnit", "WebApplicationFactory", "Testcontainers", "integration test", "unit test", "bUnit", "snapshot test", "Verify", "test coverage", "AAA pattern", "WireMock", or "FakeTimeProvider".

Awaiting classification754updated 2 months ago

Tdd

codewithmukesh

Guided test-driven development workflow for .NET 10 using xUnit v3, WebApplicationFactory, Testcontainers, and Verify snapshots. Follows the strict red-green-refactor cycle. Use when: "TDD", "test-driven", "let's TDD this", "red green refactor", "write the test first", or when building a feature with clear acceptance criteria.

Awaiting classification754updated 2 months ago

Spec

codewithmukesh

Turns a vague feature idea into an agreed, persisted specification file through structured questioning rounds.

Productivity & Workflow754updated 2 months ago

More in Productivity & Workflow

Dd Meeting Prep

anthropics

Featured

Prepares question lists, benchmarks and red flags for due diligence meetings such as management presentations and expert calls.

Productivity & Workflow39Kupdated 2 weeks ago

Dd Checklist

anthropics

Featured

Builds and tracks sector-tailored due diligence checklists with workstreams, status tracking and red flag escalation.

Productivity & Workflow39Kupdated 2 weeks ago

Deal Tracker

anthropics

Featured

Tracks live M&A deals with milestones, deadlines, action items and weekly pipeline reviews.

Productivity & Workflow39Kupdated 2 weeks ago

Client Review

anthropics

Featured

Prepares client review meetings with portfolio performance, allocation analysis, talking points, and action items.

Productivity & Workflow39Kupdated 2 weeks ago

Morning Note

anthropics

Featured

Drafts concise morning meeting notes on overnight developments, trade ideas and key events for coverage stocks.

Productivity & Workflow39Kupdated 2 weeks ago

Notion Spec To Implementation

openai

Featured

Turns Notion specs into implementation plans, linked tasks, and progress updates inside Notion.

Productivity & Workflow27Kupdated 4 weeks ago