the-council

Plugin the-council from marketplace the-council in aleemont1/TheCouncil. Commands read from the repo's manifest — 1 month ago.

Skills (20)

• add-lens

  Add a new engineering lens (skill) to TheCouncil and register it everywhere it must appear.

• dhh-majestic-monolith

  Majestic monolith: one codebase, integrated Active Record models, server-driven UI, bare-metal deploys, system tests over unit-test mocks. Use when designing or reviewing web app architecture, weighing microservices or repository/mock layers against a single deployable, or choosing a test strategy.

• fowler-evolutionary-design

  Evolutionary design: continuous refactoring under automated tests, YAGNI, MonolithFirst, enterprise data patterns. Use when deciding how much architecture to build up front, whether to split a service, or how to sequence a refactor safely.

• ousterhout-deep-modules

  Deep modules: small interfaces hiding large functionality, information hiding, errors defined out of existence. Use when designing or reviewing module and API boundaries, or when code shows classitis, pass-through methods, or exception-heavy interfaces.

• uncle-bob-solid-orthodox

  Clean Architecture: the Dependency Rule, concentric layers, SOLID, polymorphic boundary crossing, red-green-refactor. Use when separating business rules from frameworks and I/O, untangling dependency direction, or reviewing layering.

• kleppmann-data-contracts

  Data contracts: immutable append-only logs, derived views, CRDTs, backward/forward-compatible schemas. Use when designing replication, event logs, sync or offline-first data, or schema evolution across services.

• lamport-state-invariants

  State invariants: computation as state machines with inductive safety and liveness invariants, logical clocks for causal order. Use when reasoning about concurrency, distributed protocols or ordering bugs, or before writing a formal spec.

• carmack-inlined-execution

  Inlined execution: linear top-to-bottom code, forward-only control flow, one polled main loop, pure functions in C++. Use when simulation, game or real-time loops hide state across many small functions, or when deciding whether to inline.

• danluu-empirical-systems

  Empirical systems: measure real workloads, latency distributions, crash consistency and off-CPU time; distrust vendor and POSIX assumptions. Use when benchmarking, chasing tail latency, or reviewing storage and fsync persistence code.

• muratori-data-oriented

  Data-oriented design: contiguous cache-friendly layout, table-driven dispatch, SIMD, recompute over cache. Use when optimizing hot loops, replacing virtual dispatch or class hierarchies, or choosing data layout in performance-critical code.

• armstrong-fault-isolation

  Fault isolation: share-nothing processes, let-it-crash, supervisor trees, asynchronous messages. Use when designing worker or actor systems, error recovery and restart strategy, or when defensive try/catch is spreading.

• ask-council

  Council triage: picks which engineering lens (solo), lens sequence (pipeline) or opposing pair (tribunal) fits a problem. Use when the user runs /ask-council, asks which lens or skill applies, or faces an architectural trade-off between competing values.

• djb-isolated-privilege

  Privilege isolation: eliminate trusted code, split into tiny single-purpose processes under distinct UIDs, supervised foreground services. Use when designing network daemons or untrusted-input parsers, or deciding where privilege boundaries go.

• hickey-simple-values

  Simple values: immutable data, persistent structures, state as identity over time, uncomplected design. Use when untangling shared mutable state, modeling time or history, or choosing between in-place mutation and value semantics.

• antirez-pragmatic-c

  Pragmatic C: single-threaded event loop, mechanical sympathy, zero dependencies, flat in-memory data structures, readable code. Use when designing in-memory servers or network daemons, or weighing threads and locks against one loop.

• bellard-autonomous-engine

  Autonomous engine: compact dependency-free monolithic C, single-pass execution, embedded interpreter, one binary. Use when building small self-contained tools, emulators, codecs or interpreters, or removing dependencies.

• cantrill-observability-first

  Observability first: production tracing with zero disabled probe effect, bounded telemetry, safe instrumentation, explicit platform values. Use when adding logging, metrics or tracing, designing for production debuggability, or reviewing hot-path telemetry.

• pike-unix-minimalism

  Unix minimalism: data-dominant design, small interfaces, standard data structures, clarity over cleverness, CSP concurrency. Use when simplifying a design, choosing data structures, shaping composition boundaries, or picking channels over shared memory.

• stenberg-defensive-c

  Defensive C: C89 portability, warning-free builds, explicit error propagation, state-machine protocol parsers, disciplined vulnerability handling. Use when writing or reviewing C that parses untrusted input, must port widely, or ships as a library.

• king-type-driven-design

  Parse, don't validate: raw data becomes rich types at the boundary, illegal states unrepresentable, total functions. Use when designing domain types or input handling, or reviewing validation that returns booleans, scattered checks, or flag-based state.

Similar plugins