Define architecture
Skill onfire7777/universal-ai-skills-library/skills/define-architecture
Generates folder structures, module contracts, middleware pipelines, and frontend/backend boundaries for TypeScript full-stack applications. Use when starting a project, setting up project structure, organizing a monorepo, configuring middleware, defining folder layout, designing backend modules, establishing team conventions, or asking "how should I structure this app", "design the folder structure", or "set up the architecture".From its SKILL.md
npx -y skills add onfire7777/universal-ai-skills-library --skill define-architectureAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 13 stars13 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as Unspecified. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.2 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it
Define Architecture
Define durable, easy-to-change architecture defaults for TypeScript apps.
How to use this skill
- Determine context:
- New codebase: follow
Architecture setup workflow. - Existing codebase: follow
Adoption workflow.
- New codebase: follow
- Produce an architecture brief using
Output template. - Run
Validation loopbefore finalizing.
Load references only when needed:
- Stack defaults: references/stack-defaults.md
- Shipping and rollout: references/shipping-practices.md
- Engineering quality checklists: references/craftsmanship.md
Architecture setup workflow
- Define constraints first:
- Product scope, team size, compliance/security needs, expected scale.
- Deployment targets and required integrations.
- Choose repo shape:
- Use
apps/for deployable surfaces (api,web,admin). - Use
packages/for shared libraries (shared,ui,icons,auth,proto).
- Use
- Define backend module contracts:
handler: transport only.service: business orchestration.dao: database access only.mapper: DB/proto/domain transformations.constantsandtypes: module-local contracts.
- Define request context and middleware:
- Use AsyncLocalStorage-backed
RequestContext:import { AsyncLocalStorage } from "node:async_hooks"; type RequestContext = { tenantId: string; userId: string; traceId: string }; const store = new AsyncLocalStorage<RequestContext>(); export const getContext = () => store.getStore()!; export const runWithContext = (ctx: RequestContext, fn: () => void) => store.run(ctx, fn); - Initialize context in every entrypoint (RPC, HTTP, jobs, CLI).
- Read context via
getContext(); do not thread context params through business functions. - Require route policy per RPC method and register services through
registerServiceWithPolicies. - Keep auth, logging, errors, and context in shared middleware.
- Use AsyncLocalStorage-backed
- Define frontend boundaries:
- Default to Server Components; add
"use client"only for client-only behavior. - Use TanStack/Connect Query for server state.
- Use MobX only for cross-cutting client state that cannot live in component state.
- Keep forms, hooks, and UI mappings type-safe and implementation-focused.
- Default to Server Components; add
- Define testing and release expectations:
- Backend TDD loop: Red -> Green -> Refactor.
- Unit tests stay DB-free; integration and E2E tests run in parallel with dynamic IDs.
- Release in small, reversible steps with a rollback plan.
Adoption workflow (existing codebase)
- Map current architecture and pain points.
- Select the smallest set of changes that enforce clear module boundaries.
- Migrate one vertical slice first.
- Add guardrails (lint/type/test checks) to prevent regression.
- Roll out module-by-module.
Stack defaults
Use references/stack-defaults.md as the default baseline. Deviate only when constraints require it.
Validation loop
Run this loop before finalizing architecture decisions:
- Verify consistency:
- Naming, module boundaries, and middleware rules are applied the same way across services.
- Verify quality gates:
npm run lintnpm run check-typesnpm run test --workspace=<pkg>(or equivalent targeted tests)
- Verify operability:
- Observability, health checks, and rollback path are defined.
- If any check fails:
- Fix the architecture brief or conventions.
- Re-run the loop.
Output template
Use this structure for architecture recommendations:
# Architecture brief
## Context and constraints
## Repo shape
## Backend module contracts
## Request context and middleware policy
## Frontend boundaries
## Testing strategy
## Rollout and rollback plan
## Open risks and follow-ups
Skill handoffs
- Use
ui-auditfor final UI quality checks. - Use
ui-animationfor motion-specific guidance.
Gotchas
- Don't default to microservices for teams under 5 — start with a modular monorepo and split later when boundaries are proven.
- Don't put app-level dependencies in root
package.jsonin a monorepo — each app owns its deps. - Don't skip the adoption workflow for existing codebases — big-bang rewrites fail; migrate one vertical slice first.
- Don't define module contracts (handler/service/dao) without enforcing them via lint rules or type checks — unenforced contracts decay immediately.
- Don't over-abstract shared packages early — wait until three or more apps need the same code before extracting to
packages/. - Don't skip the rollback plan — every architecture decision should be reversible or have a documented fallback.
What ships with it: 3 files
3.3 KB alongside SKILL.md
references/
- craftsmanship.md2.3 KB
- shipping-practices.md622 B
- stack-defaults.md419 B