Skip to content
Back to skills

Architecture

ASecurity

Design or review a system with Imagile's opinions on .NET, Blazor, TypeScript, Astro and Azure. Use for structure, module boundaries, hosting, Azure naming or cost, and tech choices.

  • 3 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 20, 2026
ai-agentstypescriptgosqlnodeazuretestinggitapidatabaseci/cd

Works with

  • cli
  • api

Security analysis

A100/100

Pro scans all 6 files and shows the line behind each finding

Scanned October 20, 2026

npx -y skills add imagile-dev/claude-plugins --skill architecture --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Architecture?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Architecture
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/imagile-dev-architecture/badge)](https://www.skillsdirectory.com/skills/imagile-dev-architecture)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: architecture
description: Design or review a system with Imagile's opinions on .NET, Blazor, TypeScript, Astro and Azure. Use for structure, module boundaries, hosting, Azure naming or cost, and tech choices.
---

# Architecture

Give an opinionated design or review, grounded in the stack below. Recommend one option, and say what it optimizes for. Do not survey every option.

## 1. Understand the problem

Before you propose anything, answer these:

- **What problem does it solve, and for whom?** The answer sets the boundary.
- **Who owns it?** If the team boundary and the system boundary differ, say so plainly.
- **Can it deploy and test on its own?** If not, the boundary is probably wrong.
- **What does it cost each month?** Include always-on resources (see `references/azure.md`).

For a review, read the design or code first. Then apply the rules.

## 2. The non-negotiables

- **Radically obvious, and simple until users force a compromise.** Code and design a newcomer understands on the first read. Keep the simplest option until it would compromise what users experience: behavior, correctness or performance they feel. Hypothetical scale, future flexibility and taste never justify complexity.
- **Name the trade-off.** Every recommendation says what it optimizes for and what it gives up.
- **Modular monolith first.** Extract a service only when its load, its owner or its release cadence is independent. Late is right.
- **No new infrastructure unless it is unavoidable.** Reuse the database, storage and hosts that exist. Ask before you add a resource.
- **Serverless and static by default.** Small APIs go on Azure Functions with Table Storage or SQL. Sites go on GitHub Pages (Astro).
- **No repository, unit-of-work or mediator.** Services take the `DbContext` directly. Controllers call services.
- **Write it before you depend on it.** Use the platform first (`System.Text.Json`, `HttpClient`, `Microsoft.Extensions.*`, Node built-ins). Offer a third-party package only for a real feature gap, with its license.
- **Pin dependencies exactly**, and add only versions at least 14 days old. Pin GitHub Actions to a commit SHA.
- **No secrets in files.** Use OIDC for CI, managed identity in the cloud, and Key Vault or the OS credential store for the rest. Never an API key where federation works.
- **Cost is a gate.** State the monthly cost before you create a resource. Tear down trial infrastructure in the same piece of work.
- **Mobile responsive is part of done.** Test at 375px and desktop.
- **Errors are honest.** Say what failed and how to fix it. Nothing fails silently.

## 3. Stack references

Read only the file the task needs:

| File | Covers |
|------|--------|
| `references/dotnet.md` | Solution layout, EF Core and SQL, DTOs, DI, config, testing, CLI, seeding |
| `references/azure.md` | Hosting choices, Bicep, Imagile resource naming and its 1 to 5 score, cost, CI/CD |
| `references/web.md` | TypeScript and Node tools, Astro sites, front-end defaults |
| `references/principles.md` | Module boundaries, cross-module calls, when to extract a service |

## 4. Output

Use generic `Company.App.*` names in examples. Never use a real client name. Link to docs. Do not copy them.

```
## Architecture: [name]

### Problem
[One sentence.]

### Recommendation
[What to build, where it lives, how it is structured.]

### Optimizing for
[The one or two qualities this favors (obviousness, time to ship, user-felt latency, cost, operability), and what it gives up.]

### Structure
[Projects, folders, key files.]

### Cost
[Monthly run rate of anything new, or "no new resources".]

### Trade-offs
| Option | Gains | Costs | Forced by a user need? |
|--------|-------|-------|------------------------|
| [Recommended] | | | |
| [Alternative] | | | |

### Ownership and independence
[Who owns it. How it deploys and tests on its own.]
```

The recommended option is the simplest one whose costs users never feel. If a more complex option wins, name the user behavior that forces it.

For a review, replace **Recommendation** with **Assessment**, and add **Concerns** before **Trade-offs**. For an Azure naming review, add the **Infra naming** block from `references/azure.md`.

Files in this skill

  • SKILL.md4.1 KB
  • evals/evals.json2 KB
  • references/azure.md3.8 KB
  • references/dotnet.md4.7 KB
  • references/principles.md1.4 KB
  • references/web.md2 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.