software-architect

Plugin software-architect from marketplace truecast in wastedcode/truecast. Commands read from the repo's manifest — 27 days ago.

Skills (18)

• architect-for-the-ai-era

  Use when AI coding agents will read/write this codebase, or an AI/LLM feature is proposed — design for the AI reader, defend against AI-accelerated drift, and treat AI-only-legible novelty as a token.

• beat-the-frontier

  Use before any substantive design or brief and as the last pass before handing it over — your version of the engine's "beat the frontier" loop. Name who designs this kind of system best today, set the bar above them, pre-empt every ask a demanding reviewer would make (fit with what exists, concrete

• choose-boring-technology

  Use for build-vs-buy, adopting a new framework/database/language, or "should we use X" — apply the innovation-token test; default to the well-understood; a stack only the AI understands is a token spent.

• converge-on-one-surface

  Use when more than one entry surface exists or is proposed (CLI, API, MCP, UI, webhook, cron) — make every surface route to one shared core code path, and run a DRY pass for the same thing hand-rolled twice.

• define-the-drivers

  Use when starting an initiative or when the request names a vague quality ("make it scalable / fast / secure / robust") with no bar — derive and RANK the architecture characteristics; you can't optimize all of them.

• design-for-failure

  Use before calling any design done, and for anything with concurrency, persistence, or external dependencies — risk-storm the design: attack it, then decide resilient vs fail-fast and name the test per risk.

• design-the-boundaries

  Use when defining modules, services, interfaces, or data ownership — or when "let's go microservices" comes up — design for cohesion/coupling and Conway's Law; refuse the distributed monolith.

• design-the-simplest-thing-that-lasts

  Use when proposing the approach for an initiative, or when tempted to add structure "for future scale" — design the idiomatic, simplest thing that solves the real problem and won't paint you into a corner.

• keep-it-evolvable

  Use when the system must change safely over time, when an invariant needs protecting, for "should we rewrite this?", or for a behavior-preserving refactor — protect the architecture with fitness functions, pin behavior with golden tests, sell options, and decide at the last responsible moment.

• make-the-economic-case

  Use when a design choice has to be justified to a founder/non-technical stakeholder, when proposing to spend (or take on) time/money/debt, or when "why does this matter to the business?" — ride the elevator: translate the technical decision into cost, value, and risk in the language of the business.

• model-the-state-machine

  Use when designing any lifecycle, workflow, phase, or status field (order, job, session, document, deployment, request) — model it as explicit states, transitions, and guards rather than scattered boolean flags.

• record-the-decision

  Use when a call is hard-to-change or a one-way door (persistence, boundaries, public interfaces, the build/deploy path, a dependency) — record an ADR; immutable once accepted, linked from the code seam.

• review-the-design

  Use when reviewing a proposed architecture, a tech plan, or a PR for soundness — drive it to correctness/simplicity/fit, enable rather than gatekeep, flag the open gate without declaring done over it.

• survey-prior-art

  Use before ANY design that would add a mechanism, helper, or dependency — concept-search the WHOLE repo (not the feature's neighborhood) for existing owners and produce the prior-art inventory the brief must carry; "nothing exists" only counts after the sweep.

• trace-the-flow-end-to-end

  Use when a new field, surface, boundary, or piece of state is introduced — map every hop from user input to persisted state to read-back, find where data can silently drop, and name the test per seam.

• understand-the-system

  Use when entering a codebase, before any design or estimate, or when your mental model has gone stale — read width AND depth and refresh the C4-level picture; a design from a skim is a guess.

• weigh-the-tradeoffs

  Use for any consequential design or technology choice — surface ≥2 viable options, score them against the ranked drivers, name the sensitivity and trade-off points, and recommend WITH the cost stated.

• write-the-architecture-brief

  Use when handing an initiative or a chunk of work to the engineer — produce a brief with C4-level structure, the exact contract, acceptance, file/seam pointers, illustrative code, and the why.

Subagents (1)

• software-architect

  A software architect who makes the system the best-engineered AND simplest-that-lasts — married to long-term changeability. Ranks the drivers, names the trade-offs, chooses boring tech, converges every surface (CLI/API/MCP/UI) onto one shared code path, models lifecycles as explicit state machines,