spec-driven-development

Creates structured specifications before coding .NET 8+ solutions and features.

7|Updated Jan 11, 2026
One-click install
npx skills add https://github.com/peterblazejewicz/claude-plugins --skill spec-driven-development-peterblazejewicz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec-driven-development
Source: https://github.com/peterblazejewicz/claude-plugins/tree/main/plugins/dotnet-skills/skills/spec-driven-development
Command: npx skills add https://github.com/peterblazejewicz/claude-plugins --skill spec-driven-development-peterblazejewicz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Starting a .NET feature or solution without written requirements leads to rework, hidden assumptions, and architectural decisions made on the fly. This Skill enforces a gated Specify → Plan → Tasks → Implement workflow so requirements are validated by a human before any code is written. ## Core Features & Use Cases - Four-phase gated workflow: Specify, Plan, Tasks, and Implement, each requiring human review before advancing. - .NET-specific spec template: Covers objective, dotnet CLI commands, solution structure (Core/Infrastructure/Contracts projects), code style, xUnit/MSTest testing strategy, and Always/Ask First/Never boundaries. - Assumption surfacing and reframing: Translates vague requests like "make the app faster" into testable success criteria for Avalonia, ASP.NET Core, Blazor, MAUI, and EF Core scenarios. - Use Case: When asked to add a new feature to an Avalonia 11 desktop app, the Skill first lists assumptions (.NET 8, EF Core 8, xUnit v3, CommunityToolkit.Mvvm), drafts a spec saved to docs/specs/, and only proceeds to implementation after approval. ## Quick Start Ask the agent to write a specification for your new .NET feature before any code is written, describing the goal and letting it surface assumptions for your review.

Frequently Asked Questions about spec-driven-development

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a specification before coding a .NET feature?

Follow the four-phase workflow: Specify, Plan, Tasks, Implement. Write a spec covering objective, dotnet CLI commands, project structure, code style, testing strategy, and boundaries, then get human approval before generating an implementation plan.

What should a .NET project specification include?

Six core areas: objective, full dotnet CLI commands (restore, build, test, format, run, publish), solution layout with Core/Infrastructure/Contracts projects, code style examples, xUnit or MSTest testing strategy, and Always/Ask First/Never boundaries.

Does spec-driven development work with Avalonia and ASP.NET Core?

Yes, the guidance explicitly frames examples for Avalonia 11, ASP.NET Core, Blazor, .NET MAUI, and EF Core. Success criteria examples cover Avalonia cold-start time and ASP.NET Core p95 latency targets.

When should I skip writing a spec?

Skip it for single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. Anything taking more than about 30 minutes or touching multiple projects warrants at least a short spec with acceptance criteria.

How do I turn vague requirements into testable success criteria?

Reframe each vague requirement into measurable conditions, such as cold-start under 1.2 seconds or p95 latency under 120ms at 200 RPS. Confirm the targets with the human before proceeding so implementation loops toward a clear goal.