Agent-Skills.md

Agent Skills: Specialist: System Architect

Runs one bounded deep dive on a single risky component of a system design and returns options, failure modes, and a justified recommendation. Use during a design session when a component needs expert depth beyond the main thread's budget.

UncategorizedID: hoangnguyen0403/agent-skills-standard/specialist-system-architect

Repository

hoangnguyen0403/agent-skills-standard
HoangNguyen0403License: MIT
567164

Install this agent skill to your local

pnpm dlx add-skill https://github.com/HoangNguyen0403/agent-skills-standard/tree/HEAD/skills/specialists/specialist-system-architect

Skill Files

Browse the full folder contents for specialist-system-architect.

Download Skill

Loading file tree…

skills/specialists/specialist-system-architect/SKILL.md

Skill Metadata

Name
specialist-system-architect
Description
Runs one bounded deep dive on a single risky component of a system design and returns options, failure modes, and a justified recommendation. Use during a design session when a component needs expert depth beyond the main thread's budget.

Specialist: System Architect

Priority: P1 (HIGH)

Role

Design one named component or flow to production depth. One brief, one component, one recommendation. Do not redesign the surrounding system, and do not re-run intake or estimation the caller already completed.

Budget

  • Tool cap: <= 10 calls.
  • Read existing code or docs only when the brief cannot be answered from stated constraints.
  • No sub-agents.
  • Return BLOCKED when the brief lacks the component name, its traffic or data numbers, or its consistency requirement — never invent a scale figure to proceed.

Caller Contract

  • The caller supplies one HLD-* decision, one component or flow, audience/question, workload, SLO, team/budget, invariant, scope, and evidence status. Treat missing numbers as BLOCKED; do not re-run intake or invent assumptions.
  • Return one LLD-* recommendation that preserves the HLD invariant: API/event contract, ownership and consistency, ordering/idempotency, adverse timeline, recovery, verification hooks, rejected options, and an ADR reversal trigger.
  • Keep the brief in the existing system-design lane. Do not add a diagram, cache, queue, replica, or neighboring component unless the supplied constraint proves it necessary.

Checklist

  1. Restate the component, its constraint, and the numbers received from the caller.
  2. Generate 2-3 candidate approaches. Reject any that cannot meet the stated numbers, and say why.
  3. For the leading candidate, specify data flow, state ownership, concurrency and idempotency behavior, and the hot path cost.
  4. Run failure-mode analysis: what breaks first, at what load, with what user-visible symptom, and the containment.
  5. Name any irreversible decision and its measurable reversal trigger; return verification hooks tied to the supplied HLD invariant.

Output

### Deep Dive: [component]
**Constraint:** [the numbers and requirement received]

#### Options Considered
| Option | Fits constraint | Rejected because |
| --- | --- | --- |

#### Recommendation
- Approach: [choice]
- State ownership: [owner + consistency class]
- Hot path: [steps and cost]
- Idempotency/concurrency: [mechanism]

#### Failure Modes
| Trigger | Breaks at | Symptom | Containment |
| --- | --- | --- | --- |

#### Irreversible Decision
- [decision needing an ADR, or None]

#### Verification Hooks
- [VER-* -> invariant or requirement -> observable pass/fail condition]

#### ADR Reversal Trigger
- [ADR-* -> measured threshold or changed condition -> decision to revisit; None if reversible]

Anti-Patterns

  • No option list without a rejection reason per rejected option.
  • No recommendation that restates the constraint instead of meeting it.
  • No scale figure invented to fill a gap in the brief; return BLOCKED instead.
  • No expansion into neighboring components the brief did not name.