kakha13/think-like-me: Claude Code skill that applies your curated engineering rules before every coding task. Captures new rules via /learn-this and /new-rule.

Claude Code skill that applies your curated engineering rules before every coding task. Captures new rules via /learn-this and /new-rule. - kakha13/think-like-me

Summary

think-like-me is a Claude Code skill that stores an engineer's curated coding rules and consults them before Claude drafts any code. Unlike Claude Code's passive auto-memory, which only surfaces past facts when relevant, this skill actively shapes Claude's approach up front by reading domain-matched rule files. Engineers add rules through three capture commands (/learn-this, /new-rule, and an auto-detect prompt) that convert corrections into reusable guidance.

What it is useful for

Engineers who repeatedly correct Claude on the same issues — for example, "NativeWind crashes in tab FlatLists" or "Laravel Sanctum v4.3 has no isExpired()" — can encode those corrections once and have them applied automatically. The skill categorizes tasks into mobile, backend, ui, and general domains, then loads only the rules whose When keywords overlap with the current request. Before writing any code, Claude acknowledges the applied rule in one line, making a misapplied rule visible early. If no rule matches, Claude proceeds normally — no forced matches are imposed.

The seed rules shipped in the repository (seven mobile, two backend, one UI) come from cross-project memory entries, while project-specific fixes stay in project-scoped memory instead.

How engineers can use it

The skill is designed to live at ~/.claude/skills/think-like-me/, the standard Claude Code skills directory. The README describes the resulting file layout (SKILL.md, agents/, rules/, references/) but does not include explicit clone or install commands, so engineers should consult DESIGN.md or the project page for setup steps.

Once installed, three workflows add rules. After correcting Claude, run /learn-this; the skill analyzes the correction, drafts a rule with the Don't field pre-filled from the wrong approach, and asks for approval. To add a rule from scratch, run /new-rule [description]; Claude parses the prose into the structured block. If the engineer corrects Claude without typing a command, Claude offers once: "Caught — want me to save this as a rule?" and does not ask again. All three paths end with the same dual-write: the rule lands in rules/<category>.md and a pointer is added under ~/.claude/projects/<project>/memory/feedback_<slug>.md.

Each rule follows a fixed format with required When, Do, and Why fields, plus optional Don't and Example fields. The Why field exists specifically so Claude can reason about edge cases the rule does not literally cover. New categories can be created by naming them in /new-rule (e.g. "this is a devops rule"); Claude proposes the new file and asks for confirmation. Removing or editing a rule means opening the category file directly.

Documented limitations: installation commands are not provided in the README, and the general.md category ships empty, so users start without cross-cutting rules until they accumulate them.