بنقرة واحدة
plan-templates
Use when creating implementation plans that need mode-specific templates.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Use when creating implementation plans that need mode-specific templates.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when designing gRPC services, proto files, or adding gRPC-Web or JSON transcoding.
Use when writing async code, propagating CancellationTokens, or fixing async/await pitfalls.
Use when applying or enforcing C# coding style — namespaces, sealed classes, var usage, XML docs.
Use when applying modern C# idioms — records, pattern matching, primary constructors, collection expressions.
Use when registering services, choosing lifetimes, or implementing DI patterns like decorator or keyed services.
Use when selecting or implementing design patterns in C# — factory, builder, strategy, decorator, or mediator.
| name | plan-templates |
| description | Use when creating implementation plans that need mode-specific templates. |
| metadata | {"category":"workflow"} |
| when_to_use | When generating implementation plan templates based on project mode |
Generate the plan.md structure based on project mode.
# Implementation Plan: {Feature Name}
**Feature**: {NNN}-{short-name} | **Date**: {DATE} | **Mode**: Generic
**Spec**: spec.md
## Summary
{1-2 sentence overview}
## Constitution Check
Source: `.dotnet-ai-kit/memory/architecture.md` + `domain-model.md` (per FR-024 split)
{PASS/FAIL with notes}
## Technical Context
**Framework**: .NET {version} | **Architecture**: {detected pattern}
**Test Framework**: {detected} | **Key Packages**: {list}
## Research Findings
{Summary of existing patterns from codebase scan}
## Layer Plan
### Domain Layer
- Entities: {list with file paths}
- Value Objects: {list}
- Domain Events: {list}
### Application Layer
- Commands: {list with handlers}
- Queries: {list with handlers}
- Validators: {list}
- Interfaces: {list}
### Infrastructure Layer
- Repositories: {list}
- Services: {list}
- Configurations: {EF configs, DI registrations}
### API Layer
- Endpoints: {list with HTTP methods and paths}
- DTOs: {request/response models}
- Mapping: {profiles or extensions}
## Complexity Tracking
{Only if constitution violations need justification}
plan.md — per-service breakdown:
# Implementation Plan: {Feature Name}
**Feature**: {NNN}-{short-name} | **Date**: {DATE} | **Mode**: Microservice
## Summary
One paragraph stating the feature's primary user-visible behavior and the
single architectural axis it changes. No diagrams; reference the FR list
in `spec.md` and the architectural diff in `data-model.md`.
## Constitution Check
Source: `.dotnet-ai-kit/memory/architecture.md` + `domain-model.md` (per FR-024 split)
## Research Findings
Numbered list of the R-items captured in `research.md` that drive plan
decisions, each with a one-line "decision" / "rationale" / "alternatives"
trio. Cross-link the canonical R-entry rather than restating it.
## Service Plan
### {domain}-command
- Aggregates: {list}
- Events: {list with data schemas}
- Commands: {list}
### {domain}-query
- Entities: {list}
- Event Handlers: {list}
- Queries: {list}
### {domain}-processor (if applicable)
- Listeners: {list}
- Handlers: {list — what each handler forwards to}
### {domain}-gateway
- Endpoints: {list}
- Proto clients: {list}
### {domain}-controlpanel (if applicable)
- Pages: {list}
- Facades: {list}
## Dependency Order
command → query/processor (parallel) → gateway → controlpanel
service-map.md — Mermaid diagram of service dependencies + per-service change summary.
event-flow.md — Mermaid sequence diagram + event catalogue (name, publisher, subscribers, data schema).
contracts/ — Proto definitions, event schemas for new/updated services.