hexagram

Plugin hexagram from marketplace hexagram in imgabrieldev/hexagram. Commands read from the repo's manifest — 1 month ago.

Skills (16)

• architecture

  Use when writing or reviewing application code and a structural question comes up - where a file goes, whether a dependency needs a port, how many ports, how a use case gets its dependencies, what belongs in a shared library, or whether the core can be replayed. The Deterministic Hexagon.

• board

  Use when picking up work and needing to know which slice is next and what proves it done, after finishing one so the board catches up, when a card was moved and the markdown should follow, or when this repo's pitches and plans should be shown as a kanban board. Syncs both directions and leaves the m

• clean-code

  Use when naming a variable, function, type or file, deciding how big a function or file should get, handling an error, or reviewing code for readability. House style for how code reads.

• diagrams

  Use when creating, editing or reviewing an architecture diagram. Covers C4 notation, Excalidraw inside an Obsidian vault, whether a generator or your hands own the file, and the binding trap that draws every arrow through its own boxes.

• git

  Use when committing, branching, pushing, working with submodules, or rewriting history. The commit-message policy and why it is enforced by a hook rather than by prose, plus the submodule ordering that breaks a fresh clone when you get it backwards.

• init-project

  Use when starting a brand new project or repo, or when adopting the house style in an existing one. Writes the parts that have to live on disk - the docs vault, the commit-msg hook, the statusline, the gitignore - and wires the per-repo config a plugin cannot reach.

• language

  Use before writing anything that lands in a repo: code, comments, docstrings, test names, docs, README, commit messages, branch names, resource names. Everything is English, and this covers what counts as an exception and how to sweep an existing repo.

• lint

  Use when checking formatting, lint rules and types across a project, or before pushing. Detects the stack from the files that are actually present rather than being told, and reports per tool with file and line.

• naming

  Use when deciding what to call something or where it lives - a folder, a repo, a cloud resource, a state key, a secret path, a hostname, or a slug that ends up in a database row or a partition key. Some renames are a git mv and some are a data migration; this is how to tell which before you choose.

• pitch

  Use when starting a piece of work, before it is researched or built. Writes the pitch that says what the problem is, what is proposed, what is explicitly out of scope, and what would count as done.

• postmortem

  Use when anything is finished and worth a record - a plan or slice completed, a bug fixed, an incident closed, a migration done, or a claim that turned out wrong. Writes what it cost to learn, tagged so it is findable when the same thing happens again.

• research

  Use when a decision depends on something you do not know yet - whether a library does X, what a limit actually is, what something costs, how the industry solves this. Searches in English, keeps every source fetched as its own file, and writes the aggregate that unblocks the choice. Never asks permis

• setup-machine

  Use when setting up Claude Code on a new machine, or when checking whether an existing setup still matches the house plugin set. Reports what is already there, says what would land before landing it, installs the set from plugins.json, and turns off the MCP servers this machine does not want.

• terraform

  Use when writing or reviewing infrastructure as code: stack layout, one directory serving several environments, remote state, when a resource earns its own module, and why infra does NOT use the hexagon.

• testing

  Use when writing a test, deciding what to test at which layer, choosing between a fake and real infrastructure, or checking whether a test actually kills the mutant its own name describes.

• workflow

  Use when starting a feature, deciding which document to write, or closing work out. The pitch to research to decision to plan to implement to postmortem loop, what each document is for, and which step is safe to skip.

Hooks (2)

• PreToolUse

  "${CLAUDE_PLUGIN_ROOT}/hooks/no-ai-attribution.sh"

• SessionStart

  "${CLAUDE_PLUGIN_ROOT}/hooks/self-update.sh"

Similar plugins