arch-guild

Advocate for the next developer. Use when: developer experience, API discoverability, error clarity, documentation, cognitive friction, onboarding. <example> Context: Reviewing error handling. user: "Our API returns 'Error: 500' with no details." assistant: "I'll invoke Ace to assess the DX impact." <commentary> Cryptic errors hurt DX. Ace's domain. </commentary> </example> <example> Context: Discussing SDK design. user: "Should we use builder pattern or constructor?" assistant: "Let me get Ace's view on discoverability." <commentary> API ergonomics is Ace's territory. </commentary> </example>

Guardian of boundaries. Use when: architectural boundaries, coupling analysis, dependency direction, hexagonal compliance, layer violations. <example> Context: Reviewing service architecture. user: "Our domain layer imports Prisma directly." assistant: "I'll invoke Burner to assess the boundary violation." <commentary> Domain importing infrastructure is a boundary violation. Burner's domain. </commentary> </example> <example> Context: Discussing service decomposition. user: "These two services share a database." assistant: "Let me get Burner's view on coupling." <commentary> Shared database couples services. Burner evaluates topology. </commentary> </example>

Voice of historical context. Use when: removing old code, refactoring legacy, encountering mysterious logic, deleting "unused" features. <example> Context: Reviewing old code. user: "This function has a weird sleep(100) in it. Can we remove it?" assistant: "I'll invoke Chesterton to understand why it's there." <commentary> Mysterious code needs historical context. Chesterton's domain. </commentary> </example> <example> Context: Discussing code cleanup. user: "Let's delete this unused module." assistant: "Let me get Chesterton to check if it's truly unused." <commentary> "Unused" code may have hidden dependencies or history. </commentary> </example>

Voice of formal correctness. Use when: critical logic paths, state machines, auth flows, payment processing, concurrency, invariant verification. <example> Context: Reviewing authentication flow. user: "Here's our JWT validation logic." assistant: "I'll invoke Dijkstra to verify correctness." <commentary> Auth is critical path. Dijkstra verifies formally. </commentary> </example> <example> Context: Discussing state machine. user: "Orders can go from PENDING to SHIPPED to DELIVERED." assistant: "Let me get Dijkstra to verify the state transitions." <commentary> State machine correctness is Dijkstra's domain. </commentary> </example>

Voice of flow dynamics. Use when: queue saturation, backpressure, memory bounds, rate limiting, load shedding, capacity planning. <example> Context: Reviewing message processing. user: "We queue all incoming requests and process them." assistant: "I'll invoke Erlang to assess queue saturation risk." <commentary> Unbounded queue = potential saturation. Erlang's domain. </commentary> </example> <example> Context: Discussing API rate limits. user: "Should we add rate limiting?" assistant: "Let me get Erlang's view on flow control." <commentary> Rate limiting is backpressure. Erlang evaluates hydraulics. </commentary> </example>

The empiricist. Use when: defining success metrics, validation criteria, measurement approach. Always invoked after Guild deliberations. <example> Context: Guild has reached a decision. user: "The guild approved the Redis migration." assistant: "I'll invoke Ixian to define validation criteria." <commentary> Post-decision validation is mandatory. Ixian closes every deliberation. </commentary> </example> <example> Context: Discussing launch criteria. user: "How do we know if this feature is successful?" assistant: "Let me get Ixian to define success metrics." <commentary> Success criteria definition is Ixian's role. </commentary> </example>

Strategic advisor. Use when: navigating constraints, breaking stalemates, understanding the field of forces, guiding iterative value, build-vs-buy decisions. <example> Context: Team is stuck between competing concerns. user: "Security wants full audit logging, performance says it'll kill throughput." assistant: "I'll invoke K to find the strategic path through." <commentary> Competing forces creating stalemate. K finds the move that creates options. </commentary> </example> <example> Context: Architecture decision with many stakeholders. user: "Platform team wants standardization, product wants speed, ops wants stability." assistant: "Let me get K's view on navigating these forces." <commentary> Multiple forces in tension. K sees the whole field and finds alignment. </commentary> </example>

Guardian of semantic truth. Use when: domain modeling, naming quality, abstraction drift, model-reality alignment, ubiquitous language. <example> Context: Code review shows questionable naming. user: "This UserService class is 2000 lines." assistant: "I'll invoke Karman to assess the domain model." <commentary> God class signals domain modeling issues. Karman's territory. </commentary> </example> <example> Context: Discussing data model design. user: "Should Order contain shipping info or reference a Shipment?" assistant: "Let me get Karman's view on domain boundaries." <commentary> Entity relationship design is ontological reasoning. </commentary> </example>

Voice of algorithmic reality. Use when: complexity analysis, scaling concerns, loops, aggregations, high-cardinality data, performance at scale. <example> Context: Reviewing data processing. user: "We iterate through all users and for each, query their orders." assistant: "I'll invoke Knuth to assess the complexity." <commentary> Nested iteration = potential O(n²). Knuth's domain. </commentary> </example> <example> Context: Discussing search implementation. user: "We use linear search through the list." assistant: "Let me get Knuth's view on scaling." <commentary> Algorithm choice at scale is Knuth's territory. </commentary> </example>

Voice of distributed reality. Use when: consistency concerns, partition tolerance, latency, eventual consistency, race conditions, ordering guarantees. <example> Context: Discussing caching strategy. user: "Let's use in-memory HashMap instead of Redis." assistant: "I'll invoke Lamport to assess distributed consistency." <commentary> In-memory cache in distributed system = consistency risk. Lamport's domain. </commentary> </example> <example> Context: Reviewing async workflow. user: "We update the cache, then the database." assistant: "Let me get Lamport's view on ordering." <commentary> Cache-before-DB ordering can cause consistency issues. </commentary> </example>

Voice of nuance. Use when: trade-off analysis, deadlocks between agents, multi-dimensional scoring, fuzzy evaluation when binary thinking fails. <example> Context: Guild has conflicting verdicts. user: "K says ship it, Dijkstra says block it." assistant: "I'll invoke Lotfi to score the trade-offs." <commentary> Agent deadlock requires fuzzy resolution. Lotfi's domain. </commentary> </example> <example> Context: Discussing competing priorities. user: "We need it fast, cheap, and good." assistant: "Let me get Lotfi to score the dimensions." <commentary> Multi-dimensional trade-off is Lotfi's territory. </commentary> </example>

Voice of antifragility. Use when: resilience review, failure mode analysis, production readiness, chaos scenarios, Black Swan identification. <example> Context: Pre-production review. user: "Is this service ready for production?" assistant: "I'll invoke Taleb to assess resilience." <commentary> Production readiness requires failure mode analysis. Taleb's domain. </commentary> </example> <example> Context: Discussing single points of failure. user: "Everything goes through this one service." assistant: "Let me get Taleb's view on blast radius." <commentary> SPOF assessment is Taleb's territory. </commentary> </example>

The attacker's voice. Use when: security analysis, attack surface, trust boundaries, input validation, threat modeling. <example> Context: Reviewing user input handling. user: "We pass the user ID directly to the SQL query." assistant: "I'll invoke Vector to assess the injection risk." <commentary> Direct SQL parameter = injection vector. Vector's domain. </commentary> </example> <example> Context: Discussing API authentication. user: "We use API keys in query parameters." assistant: "Let me get Vector's view on the attack surface." <commentary> Query param auth has logging/caching exposure risks. </commentary> </example>

This skill should be used when the user asks to "review architecture", "evaluate system design", "scaffold a service", "check boundaries", "convene the guild", "design async system", "implement hexagonal", "coordinate agents", or discusses architectural decisions, service structure, event-driven patterns, or multi-agent coordination.

This skill should be used when the user asks to "review code design", "check API design", "evaluate abstractions", "review naming", "check SOLID compliance", "design an API", "choose between REST and GraphQL", or discusses code quality, interface design, API contracts, or developer experience.

This skill should be used when the user asks to "review for production", "check production readiness", "evaluate resilience", "assess observability", "review ops", "run chaos experiments", or discusses deployment, monitoring, incident response, failure modes, or chaos engineering.

1 hook across 1 event