My Claude Code working setup: the global rules, the skills, the references, and the scripts that drive them. Published so you can see how the skills are built, not just that they exist.

Author: Amin Khayam

Heads up: this is a museum piece. It's how I worked months ago, before I built Goodboy. It still runs, but I don't live here anymore. I shipped this much config because Claude Code, on its own, kept walking me into the same five walls:

• Context died between sessions. Every new chat, I re-explained the same things. Long threads, no memory, no sense of what mattered.
• Costs ran on vibes. Token overhead I couldn't see, model choice I made by hand every time, nothing optimizing itself.
• No parallelism. One agent, one thing at a time. Research blocked planning blocked implementation. A lot of waiting.
• The workflow was in pieces. AI tool, then GitHub, then the PR, then CI, then the docs. Too many apps to hold one task together.
• All of it was on me. Manage context, pick the model, track spend, remember the plan, glue the tools, run the workflow. Manually. Every time.

These scripts and skills are me patching those holes by hand. It worked, but it was a lot of duct tape. So I turned the duct tape into a product: Goodboy does this for you. Shared context across sessions, plans that auto-split into parallel sub-agents, a plan you can always open, sequential clusters that archive when done, and it stops you when you're about to do something dumb. Same ideas as below, minus the duct tape.

CLAUDE.md          global working rules (loaded into every session)
skills/            ak-* skills — the workflow engine
references/        shared docs the skills lazy-load
agent-prompts/     system prompts for the ak-go sub-agents
scripts/           the shell/python that the skills shell out to

Everything is prefixed ak (my initials). The pieces fit together as a ticket-to-PR pipeline:

• ak-init — model gate + worktree + branch + draft PR for a ticket.
• ak-implement — the build phase, with a lazy reference-trigger table.
• ak-check — lint/typecheck/test, gated (never autonomous).
• ak-review — review a PR, with a tone reference for comments.
• ak-done — static diff check, commit review, PR update, code-review trigger.
• ak-go — the orchestrator: a disk-backed state machine that routes a ticket (or a parent ticket's children, in parallel) through the phases above, picking a model by classified effort.
• ak-graphql / ak-test / ak-compress / ak-backup / ak-retro — supporting skills.

• Effort-based model routing. ak-classify-effort.sh reads a ticket and emits low | medium | high from estimate + title keywords. Low → a cheaper model, high → a larger one. No LLM call to decide which LLM to use.
• State machine on disk. ak-go writes ~/.claude/.ak-state/<ticket>.json and routes off it (ak-route.sh), so a long run survives compaction and a sub-agent crash resumes from the last phase instead of the start.
• Lazy reference loading. Skills don't preload docs. A trigger table maps "touching a form" → load forms.md, only then. Keeps context lean.
• Meta-file compression. compress-md.py shrinks the skill/reference markdown itself, so the rules cost fewer tokens per session.
• Script-first, LLM-last. Anything deterministic (slugging a branch, checking commit types, pushing) is a shell script. The model only does what needs judgment.

These are my conventions, not a framework. Treat it as a reference, not a dependency. If you want to try a piece:

1. Copy a skill folder into ~/.claude/skills/.
2. Copy any scripts it calls into ~/.claude/scripts/ and chmod +x them.
3. Read the skill's SKILL.md — paths and project assumptions are baked in and you'll want to adjust them.

The scripts assume macOS (Keychain for secrets, security CLI) and a few tools: gh, jq, git worktrees. Tokens are never hardcoded — linear-task-read.sh and friends read from Keychain (linear-cli) or ~/.claude/secrets/, neither of which is in this repo.

Personal config shared for reference. Take what's useful.