From sunny
Apply Sunny Kolattukudy's architecture principles to design, review, or evaluate systems. Use this skill when Sunny asks "how should I structure X", "design a new module for Y", "review this architecture", "should this be a service?", "what's the right project structure for Z", "is this the right pattern?", or any question about system design, module boundaries, project layout, cloud hosting choices, or technology selection in .NET, Blazor, or Azure/AWS. Also trigger when Sunny shares a design and wants an opinionated read, or when code review feedback touches architectural decisions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/sunny:architectureThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!--
Apply Sunny's architecture principles to design systems, review proposals, and make technology choices — opinionated, grounded in the actual stack.
Before proposing anything, ask:
If the request is a review of an existing design, read it first, then apply the principles below.
See references/principles.md for the full reference. The non-negotiables:
Features/LicenseSources/ with Pages/, Components/, Services/ inside beats a flat Pages/, Components/, Services/ structure at the root.IMemoryCache for larger cases). No Fluxor, no cascading params.IQueryable<TEntity> extension methods that project to IQueryable<TModel>, composed in controllers. No DAL abstraction layer.IRequest/IHandler, no -Command suffix. Direct controller → service calls only.-Dto suffix. Use Model (e.g. ProviderModel, CredentialSummaryModel).System.Text.Json, HttpClient, Microsoft.Extensions.*. If a third-party package has a significant feature advantage, offer it as an option with a license check.Use this structure. Keep it concise — link to docs rather than reproducing them. Use generic Company.App.* names in examples — never real client names.
## Architecture: [Feature / System Name]
### Problem
[One sentence: what this solves and for whom.]
### Recommendation
[Direct recommendation — what to build, how to structure it, where it lives.]
### Solution structure
[Project layout, folder structure, key files.]
### Alternatives considered
1. [Option] — [Why not recommended in one line]
2. [Option] — [Why not recommended in one line]
### Ownership check
[Who owns this? Does the team boundary match? Flag mismatches plainly — no jargon.]
### Deployment & test independence
[How does this get deployed independently? How do you test it in isolation?]
### Docs
- [Relevant Microsoft docs link]
For reviews (not proposals), swap "Recommendation" for "Assessment" and add a "Concerns" section before Alternatives.
Solution / project naming:
CompanyName.RepositoryName.ComponentName — e.g. Acme.Portal.ApiCompanyName.AppName.ComponentName — e.g. Acme.App.ApiApi, Ui, Domain, Core, Functions, Cli, Data.<Schema>Tests.PreDeployment, Tests.PostDeploymentProject structure (Blazor WASM + API):
Company.App.Api → ASP.NET Core API (Container Apps)
Company.App.Ui → Blazor WASM client
Company.App.Ui.Web → Blazor WASM host (serves the client)
Company.App.Domain → POCOs shared between server and client (no server deps)
Company.App.Core → Shared backend utilities (not sent to client, not a service layer)
Company.App.Data.<Name> → EF Core project, one per database schema
Company.App.Functions → Azure Functions (one app, many functions)
Company.App.Cli → CLI tooling
Tests.PreDeployment → xunit only (runs before deploy)
Tests.PostDeployment → Reqnroll + Playwright E2E (runs after deploy)
No additional class libraries unless producing a distributable package (minimizing package surface is the reason, not convenience).
Blazor feature folder structure (inside .Ui):
Features/
FeatureName/
Pages/ → @page components
Components/ → sub-components used by this feature
Services/ → IFeatureService + implementation (HttpClient-based)
Services/ → cross-cutting services (auth, local storage, etc.)
Layout/ → app shell, nav, sidebars
API feature folder structure (inside .Api):
Features/
FeatureName/
FeatureNameController.cs → primary controller
SubResourceController.cs → e.g. PermissionsController alongside RolesController
Services/
IFeatureNameService.cs
FeatureNameService.cs
When a feature has natural sub-resources (e.g. Roles → Permissions), include both controllers in the same feature folder. Don't collapse them into one controller.
No AutoMapper, no Mapster. Write it directly:
IQueryable<TEntity> that projects to IQueryable<TModel> (for EF Core queries), or a static .ToModel() extension for in-memory mappingCopyFrom(model) method on the entity itself// Entity → Model (EF Core projection)
public static IQueryable<ProviderModel> ProjectToModel(this IQueryable<Provider> query) =>
query.Select(p => new ProviderModel { Id = p.Id, Name = p.Name, ... });
// Entity update
public void CopyFrom(ProviderUpdateModel model)
{
Name = model.Name;
// ...
}
Don't suggest unit testing pure mapping methods — there's no business logic to test.
Azure (preferred):
AWS (secondary):
When recommending hosting, state the reason — scale, cost, team familiarity, or existing infra.
Always recommend this stack — don't suggest alternatives unless asked:
Tests.PreDeployment)Tests.PostDeployment). Feature files describe business scenarios; Step Definitions use Page Model abstraction. Extension methods for common UI interactions (MudBlazor/Telerik).Project naming: Tests.PreDeployment (xunit only) and Tests.PostDeployment (Reqnroll + Playwright). Never UnitTests or IntegrationTests as top-level names.
Third-party test packages (xunit, Reqnroll, Playwright, Impostor) are the explicit exception to the Microsoft-first NuGet rule.
Two distinct seeding patterns — always use both.
For lookup tables, roles, permissions, enum values — data that must exist in every environment.
ReferenceDataSeeder in the .Data projectSyncReferenceDataAsync<TEntity, TId>() — idempotent upsert (add new, update changed, delete orphans)IReferenceDataEntity<TSelf, TId> and provides its own GetSeedData()seed-reference command — runs locally and in CI/CD pipelines after migrationsFor local dev and staging environments.
DataSeeder.cs orchestrates in dependency order; individual entity seeders (e.g. ProviderSeeder.cs) — one per aggregate rootnew Faker(seed: 12345)seed-test command — runs locally and in pull request / staging pipelinesCompany.App.Data.Schema/
Seeding/
DataSeeder.cs
ProviderSeeder.cs
Every repo includes a CLI project (Company.App.Cli) for dev operations, seeding, migrations, and tooling.
System.CommandLine — command routing (Microsoft-supplied)Spectre.Console — output formatting, prompts, progress (explicit third-party exception)Structure commands as feature folders matching the domain: Commands/Db/Deploy/, Commands/Storage/Seed/, etc.
Every new repository should include:
.claude/ — Claude Code skills and context. Add a CLAUDE.md at the repo root with project-specific context (stack, conventions, key file paths)..githooks/ with git config core.hooksPath .githooks in onboarding steps.When reviewing or designing any module boundary, ask: does the team that owns this code match the boundary being drawn? Flag when:
Don't use jargon to describe this — just say plainly who owns what and whether it makes sense.
npx claudepluginhub kolatts/claude-marketplace --plugin sunnyAsks structured questions about domain complexity, team size, and system lifetime to recommend the best .NET architecture: Vertical Slice, Clean Architecture, DDD+CA, or Modular Monolith.
Designs system architecture and high-level technical strategy. Use for new systems or subsystems, major refactors, technology selections, system boundaries, and long-term decisions with broad impact.
Designs system architecture for tech stack, API contracts, data models, and infrastructure shape. Supports brownfield extensions and engagement modes from Express to Meticulous.