Encode the Process, Not the Answer: Five Claude Code Plugins I Use Every Day

I’ve been building plugins for Claude Code for a few months. Not because the built-in experience is bad. It’s good. I built them because I kept doing the same things by hand, session after session, until I got tired of it.

At some point you stop narrating the same context every time and start asking why the process isn’t just encoded.

So I encoded it. The result is a small collection of five plugins I use daily. They’re open, installable in two commands, and they genuinely changed how I work. Here’s what each one does and why it exists.

The problem with chat-based AI tooling

Every session starts fresh. You explain the project, the conventions, what just happened, what you’re trying to do. If you’re disciplined, you maintain a CLAUDE.md. If you’re less disciplined, you paste the same paragraph about your tech stack fifteen times a week.

Meanwhile the actual development loop (pick up the issue, write tests, implement, fix CI, respond to review comments, merge) is twelve steps that demand discipline to execute correctly. Claude can do all of it, but only if you keep pointing it in the right direction.

I wanted to stop pointing.

claude-memory: a three-tier brain

The first thing I built was a memory system. Not a notebook, not a markdown file. An actual multi-tier system, inspired loosely by how human memory works.

Tier 1 is episodic. At the end of every session, a hook captures git state, a transcript snapshot, and some mechanical metadata. No LLM involved, just a shell script. It runs fast and never fails.

Tier 2 is the weekly rollup. A /claude-memory:consolidate command folds the episodic captures into narrative summaries: decisions, dead ends, lessons learned. This is where the LLM does real work. It reads the raw captures, writes something coherent, and redacts anything that looks like a secret or PII.

Tier 3 is durable abstractions. Distilled heuristics like “never auto-resolve migration conflicts” or “always read package.json before running any command.” These load every session.

The session-start hook injects the relevant tier-3 memories plus the last few tier-2 summaries. When Claude opens a session, it already knows what we were doing, what we decided, and why.

Everything is stored locally, per project. No external service, no sync, no API key required.

delivery-workflow: encoding the feature loop

This one does the actual development work. It has four skills.

dev-workflow is an eight-step TDD cycle that runs from a GitHub issue number. It branches, analyzes the issue, writes failing tests, implements, runs coverage, does a code review pass, fixes issues, and runs a security review. In that order, every time, no shortcuts. A stop hook blocks exit if you have uncommitted TypeScript files and a test:cov script, so you can’t accidentally skip the coverage step.

epic-workflow operates at a higher altitude. You give it a GitHub Epic and it navigates the Epic, Features, and Tasks hierarchy, updating the GitHub Project board as it goes. Hard limit of three parallel subagents, with mandatory acceptance-criteria validation before anything gets marked Done.

pr-autoheal polls CI checks on an open PR, downloads the failing logs, and dispatches a diagnostic subagent to find the root cause (stale rebase, missed call sites, type errors, lint violations). It applies the fix, verifies locally, and pushes. Up to five iterations. If it can’t fix the problem in five, it escalates with a full iteration log.

pr-review-fix fetches all open review comments from a PR (using both REST and GraphQL to get the thread state right), plans the fixes, shows you the plan, executes one commit per issue, and posts inline replies to every resolved thread.

issue-ops: the GitHub issue as an API

Two skills here.

bug-rca takes a GitHub issue and runs a read-only investigation: grep for the error string, trace the code path, check git blame, inspect recent changes, and optionally query observability backends like Datadog, Sentry, GCP Cloud Operations, or Loki. Then it synthesizes a root-cause analysis with a priority (P0 to P3) and a size estimate (XS to XL), and updates the issue title and body with the findings. It never touches source files. The output is the issue.

spec-to-issues takes a spec document (a PRD, an OpenSpec bundle, or just a docs folder) and creates a full Epic, Spec, and Task hierarchy in GitHub. It parses the structure, detects the repo and project board, runs a dry-run preview for approval, and creates the issues in order. Dependencies between tasks are tracked as blocked-by relationships.

context-docs: lazy-loading your project context

This one generates modular documentation under docs/context/. Not a monolithic README, but a set of self-contained files each agent can load independently.

There’s an INDEX.md that’s always loaded, plus architecture.md, ADRs, standards, patterns, testing, examples, troubleshooting, and tooling. Each file is sized to be read fast. The generator scans config files, source, tests, CI/CD, and git history to figure out your tech stack and conventions, then writes the docs from what it observes. It flags ambiguities explicitly instead of guessing.

The point is that an agent working on a routing bug doesn’t need the testing patterns file. It loads the index, sees there’s an architecture.md, loads that, and goes. Context stays lean.

design-to-ui: from mockup to component

The newest one. Give it a design source (a Google Stitch URL, a Claude Design handoff, or just a screenshot) and it converts that into framework-native UI components.

It auto-detects your framework (React, Vue, Svelte, Angular, and others), your styling system (Tailwind, CSS Modules, styled-components), your icon library, and your component directory. Then it decomposes the design into atomic layers: atoms, molecules, organisms, templates. It scans your existing components and reuses them where it can, creating the missing ones in dependency order.

The “pluggable source, pluggable target” design means it doesn’t care how you got the mockup or what you’re building with. If it can read the design and detect the project, it works.

How to install

All five plugins live in one repo. Two commands to get started:

/plugin marketplace add edusouza/claude-plugins
/plugin install delivery-workflow@claude-plugins

Replace delivery-workflow with any of the others: claude-memory, issue-ops, context-docs, design-to-ui.

The source is at github.com/edusouza/claude-plugins. Issues and PRs are welcome. These are tools I use on real projects and actively maintain.

What I’ve learned

The most useful plugins aren’t the flashiest ones. claude-memory is just hooks and shell scripts. context-docs is just a disciplined file writer. But they eliminate the friction that would otherwise make me skip the step entirely.

A few patterns keep showing up. Encode the process, not the answer. Give the agent the right context at the right time, not all the context all the time. Let the LLM do the hard diagnostic and synthesis work, and keep the mechanical stuff (git hooks, file writes, API calls) deterministic.

These plugins are the externalized version of the habits I was trying to hold in my head. They work better out there.