← all publishers

guygrigsby

@guygrigsby source repo

5 published skills

  1. Defining Contracts · guygrigsby
    Use when a service's contracts are being decided or extended — a new service, a new endpoint, a new domain event, a schema change, a seam between two services, or any design session that has produced a domain model and is heading toward code. Also when a design describes an API but not its data, names events without defining them, or when an invariant exists in application code with no constraint behind it.
    0
    installs
  2. Agent Ready · guygrigsby bundle
    Use when making a repository easy for coding agents to work in, or keeping it that way, auditing a repo for agent ergonomics, bootstrapping or refreshing CLAUDE.md / AGENTS.md, when a session-start notice says context files are missing or stale, when a file has grown too large for an agent to hold in context, or when onboarding a codebase for agentic development. Not for writing application features.
    0
    installs
  3. Domain Driven Design · guygrigsby bundle
    Use when any architecture or design work begins, however small — designing a new feature, subsystem, or service, an architectural shift, encapsulating or replacing a dependency, restructuring how modules relate, or any session where the shape of the code is being decided. Also when vendor or implementation types have leaked across module boundaries, when the same domain term means different things in different parts of the code, or when the domain model is anemic — objects holding data but almost no behavior, rules living in callers or services. Active by default for design work; the user opting out ("no DDD") is the only skip. Not for mechanical bugfixes or config tweaks that decide nothing about design.
    0
    installs
  4. Drift Guards · guygrigsby
    Use when a fact is about to live in more than one place (docs describing code, a README command, a catalog or config mirrored in a spec, a version string repeated across manifests, an env key in code and .env.example and a deploy unit, a status table, an onboarding doc), when writing or updating READMEs/specs/CLAUDE.md, when adding an op/endpoint/flag/config key/enum variant that something else mentions, when committing generated artifacts, or when a reviewer or user notices docs out of date. Automate everything so drift is impossible.
    0
    installs
  5. Writing DB Schemas · guygrigsby
    Use when writing or reviewing SQL DDL — creating a table, adding a column, designing a schema or a migration — before the first CREATE TABLE is typed. Also when a schema shows nullable status columns (returned_at, deleted_at, closed_at), foreign keys without ON DELETE, TEXT timestamps, application-generated surrogate ids, CHECK (col IN (...)) vocabularies, delimited lists or JSON columns standing in for child tables, or tables whose only key is the surrogate id.
    0
    installs