This project has a knowledge graph at graphify-out/ with god nodes, community structure, and cross-file relationships.
When the user types /graphify, invoke the skill tool with skill: "graphify" before doing anything else.
Rules:
- For codebase questions, first run
graphify query "<question>"when graphify-out/graph.json exists. Usegraphify path "<A>" "<B>"for relationships andgraphify explain "<concept>"for focused concepts. These return a scoped subgraph, usually much smaller than GRAPH_REPORT.md or raw grep output. - Dirty graphify-out/ files are expected after hooks or incremental updates; dirty graph files are not a reason to skip graphify. Only skip graphify if the task is about stale or incorrect graph output, or the user explicitly says not to use it.
- If graphify-out/wiki/index.md exists, use it for broad navigation instead of raw source browsing.
- Read graphify-out/GRAPH_REPORT.md only for broad architecture review or when query/path/explain do not surface enough context.
- After modifying code, run
graphify update .to keep the graph current (AST-only, no API cost).
This file helps AI coding agents work effectively in this repository. Use it as a fast orientation guide before making changes.
This repository is a Clean Architecture Blazor Server solution template built for long-term maintainability, modular feature development, and enterprise-style application patterns.
The main application layers are:
Domain: core entities, domain events, and business rulesApplication: use cases, DTOs, validation, pipeline behaviors, and application abstractionsInfrastructure: persistence, external integrations, identity, caching, and runtime servicesServer.UI: Blazor Server UI, pages, components, and client-facing application wiringMigrators: EF Core migration entry points and database update tooling
src/ApplicationApplication logic and feature implementation. Start here for commands, queries, validators, specifications, and service contracts.src/DomainDomain model and business concepts. Keep this layer independent of UI and infrastructure concerns.src/InfrastructureEF Core, authentication, file services, caching, background jobs, and other external dependencies.src/MigratorsDatabase migration projects used for provider-specific EF Core migration work.src/Server.UIBlazor Server host, pages, components, menus, dialogs, and UI services.tests/Application.UnitTestsUnit tests for application-layer behavior.tests/Application.IntegrationTestsIntegration-style tests for application workflows and persistence-backed behavior.tests/Domain.UnitTestsUnit tests focused on domain behavior.tests/Infrastructure.UnitTestsTests for infrastructure services and related helpers.docs/Supporting project documentation.docs/superpowers/Recommended place for design notes, plans, and implementation specs when a task needs explicit planning.
- Preserve Clean Architecture boundaries. Avoid introducing UI or infrastructure concerns into
Domain. - Prefer existing repository patterns over inventing new ones. Match nearby features before creating new abstractions.
- When adding a new feature, inspect similar modules in
Application,Infrastructure, andServer.UIfirst. - Keep changes targeted. Do not refactor unrelated areas unless the task requires it.
- Update documentation when setup steps, commands, or workflows change.
- If a task benefits from explicit design or planning, add artifacts under
docs/superpowers/rather than inventing a separate process.
Build the solution:
dotnet build CleanArchitecture.Blazor.slnxRun tests:
dotnet test CleanArchitecture.Blazor.slnxRun the Blazor Server app:
dotnet run --project src/Server.UIAdd an EF Core migration for SQL Server:
dotnet ef migrations add InitialCreate --project src/Migrators/Migrators.MSSQL --startup-project src/Server.UI --context ApplicationDbContextApply database updates:
dotnet ef database update --project src/Migrators/Migrators.MSSQL --startup-project src/Server.UI --context ApplicationDbContextREADME.mdfor project overview, setup, and supported workflowsdocs/for additional repository documentation- existing feature folders in
src/Application/Featuresand related UI pages insrc/Server.UI docs/superpowers/for prior design notes and implementation plans when available
When making changes in this repository:
- favor small, reviewable edits
- explain assumptions when behavior is unclear
- verify builds or tests when the task meaningfully changes behavior
- keep new guidance aligned with the current repository structure instead of generic best practices