AI Methods — AI skill for Claude Code

How I Pilot Claude Code — My Method

If you like it and/or useit, please consider a coffee ^ : → [Ko-fi](https://ko-fi.com/billisdead)

A practical account of how I get consistent, high-quality results from Claude Code across infrastructure, development, and creative projects.

Companion files: [`CLAUDE.md`](CLAUDE.md) (the full operator template, section 21 explains the memory architecture) and [`APPENDIX-skills.md`](APPENDIX-skills.md) (the shared skills we built together).

---

1. The Foundation: CLAUDE.md as a Persistent Contract

The single most impactful thing I did was writing a detailed `CLAUDE.md` file stored at the project (or global) level. It contains:

• My role and context — sysadmin, Linux/K8s, electronic music artist
• Full infrastructure topology — hypervisor, cluster, NAS, networking, services
• Hard constraints — HAProxy/TLS rules that must never be violated, storage and safety rules, etc.
• Tech stack reference — so Claude never suggests tools outside my ecosystem
• Numbered rules — explicit, non-negotiable behaviors (no wildcard certs, no TLS bypass, etc.)
• Security by design — hardening is a design constraint from day 1, not a post-deployment pass
• Documentation philosophy — doc is written from day 1, pedagogical, lives in the repo

This means I never re-explain my environment. Claude enters every session already knowing the full picture. The CLAUDE.md is a living document — I update it whenever a new hard constraint emerges from real experience.

---

2. Memory System for Cross-Session Continuity

Claude Code has a persistent file-based memory system (`~/.claude/projects/.../memory/`). I use it for per-machine pointers, but the memory that matters is **versioned in git**, in the same repository as my global `CLAUDE.md`, so any workstation resumes the work with a single `git pull`:

• A short global CLAUDE.md — profile, hard rules, and one index line per project. It is loaded in full every session