tarekgs/ddia-engineering

Generate a compact project-specific architecture profile — materialized memory of sources of truth, data flows, capability status, obligations, risks, and invariants — so future agents don't re-derive the architecture each session. Run once per repository, then keep it honest with maintain-ddia-project-profile.

Record or review architectural decisions (ADRs) and design objective architecture checks (fitness functions). Use when a consequential, hard-to-reverse choice is made, when documenting why an option was rejected, or when an invariant should be enforced automatically.

Reason about races, transaction isolation, invariants spanning multiple rows, concurrent writes, and conflict semantics. Use when designing or reviewing anything where two actors (humans, agents, jobs, replicas) can touch the same state, or where correctness depends on an invariant.

Design or review caches, materialized views, indexes, projections, search indexes, denormalized state, and other derived data. Use when adding any representation of state whose authority lives elsewhere.

Design a new feature that persists, moves, or derives state. Use when building anything that writes to a store, crosses a service/network boundary, involves concurrent actors, or adds async/event-driven work. Produces a small design record with explicit invariants and named trade-offs.

Design or review multi-step operations that span components — sagas, compensating actions, orchestration vs choreography, durable execution. Use when a business operation can't be one transaction, or when reviewing Temporal/workflow-engine usage.

Front door for data-intensive and distributed-systems engineering judgment. Use when a task touches persisted state, concurrency, sync, retries, schema evolution, service boundaries, events, scale, or architecture decisions — or when you're unsure whether it does. Routes to the right specialized reasoning skill.

Design or review event-driven, message-based, or stream-processing flows — queues, pub/sub, CDC, outbox, event sourcing decisions. Use when introducing asynchronous boundaries, event schemas, or durable logs, or when reviewing their correctness.

Design or review timeouts, retries, idempotency, dedup, cancellation, and partial-failure handling at any network/process boundary. Use when adding resilience to a call, hardening an operation against crashes, or auditing failure semantics.

Design or review realtime collaboration, sync engines, optimistic local state, presence, offline/reconnect, or multiplayer features. Use whenever humans and/or agents edit shared artifacts concurrently — including when the capability is PLANNED and the task is to produce design obligations.

Review a diff, PR, or design for data/distributed correctness — races, hidden exactly-once assumptions, schema compat, failure modes, boundary violations. Use on any non-trivial change touching state, boundaries, concurrency, or deployment shape.

Model load, find hot spots, reason about tail latency, backpressure, and overload. Use when asked "will this scale", when adding fan-out or a hot path, when choosing sharding/partitioning, or when deciding whether a scale concern is now or later.

Design or review changes to persisted schemas, wire formats, API contracts, event schemas, or run migrations. Use whenever a change must coexist with older/newer code or previously written data.

Decide or review component/service boundaries, data ownership, granularity, and sync-vs-async communication. Use when splitting or merging components, assigning data ownership, choosing module structure, or questioning whether something should be a service.

Keep an existing DDIA project profile honest as the codebase evolves — detect drift between docs and code, reclassify capabilities that changed state, update stale descriptions, and surface (never silently fix) apparent invariant violations. Outcome is clean / changed / blocked.