think-like-me

name

think-like-me

description

Personal engineering rules and reasoning patterns the user has curated over time. Consult BEFORE writing, modifying, debugging, or designing any technical feature — rules often cover domain-specific gotchas (e.g., mobile audio timers need background mode) that generic answers miss. Also triggers on `/learn-this`, "learn this", "remember this", or `/new-rule` to capture new rules, and on detected corrections to previously proposed code.

Think Like Me

You are consulting the user's personal, curated engineering rules. These are domain-specific patterns and principles the user has accumulated — often capturing non-obvious gotchas (e.g. "mobile audio timers need background mode") that a generic answer would miss.

The rules are the active reasoning layer of the user's Claude Code setup. They sit alongside the existing passive auto-memory: memory surfaces entries when relevant, rules actively shape how you approach the task before you draft anything.

When to consult rules

On ANY request that involves writing, modifying, debugging, or designing a technical feature, follow this flow BEFORE you draft:

1. Identify the domain(s) of the task. From task keywords and context, pick one or more of: mobile, backend, ui, general. Multi-domain tasks (e.g. "wire Paddle checkout into mobile app") apply to multiple categories.
2. Read the matching rules/<domain>.md file(s) in full. These files are user-curated and expected to stay readable.
3. Scan each rule's When: line. A rule applies when its keywords overlap with the task context.
4. Apply matching rules.
   • Do: shapes your approach — build around it, don't tack it on.
   • Don't: flags paths you'd otherwise reach for.
   • Why: informs edge-case decisions when a rule isn't a perfect fit.
5. Acknowledge briefly when a rule applies. One-line confirmation before code: "Applying rule Mobile audio timers — enabling Background Modes + AVAudioSession." Lets the user catch a misapplied rule early. If zero rules match, skip this line — silence is fine.
6. If zero rules match, proceed normally. No rule is better than a forced rule.

Capturing a new rule

Three paths add a rule to the skill. All end in the same dual-write: rule block in rules/<category>.md and memory entry in ~/.claude/projects/<current-project>/memory/.

Path A — /learn-this (reactive, from correction)

User just corrected you and wants to bake the correction into a rule. Load agents/learn-this.md and follow it.

Path B — /new-rule (proactive, user-described)

User wants to add a rule from scratch, not tied to a correction. Invocation may include the rule text (e.g. /new-rule for all Expo projects, never edit ios/ folder directly because prebuild will overwrite it) or be bare. Load agents/new-rule.md and follow it.

Path C — Auto-detect correction (reactive, background)

Detect when the user pushes back on your prior response: "no, don't do X", "actually use Y", "that's wrong because Z", or rejecting code with a different approach. When you see this, offer ONCE in one line:

Caught — want me to save this as a rule? (yes to draft, skip to drop)

On yes → switch to Path A (load agents/learn-this.md). On silence, decline, or an unrelated follow-up → drop it. Do not pressure twice in the same exchange.

Saving a rule (dual-write, used by all three paths after user approves the draft)

Resolving <current-project>: the project folder under ~/.claude/projects/ is derived from the absolute working-directory path with every / replaced by - (the leading / becomes a leading -). Example: /Users/kakha13/Developer/cheaperesim-mobile → -Users-kakha13-Developer-cheaperesim-mobile. Run pwd to get the current path, then apply the transform. If the transformed folder does not exist under ~/.claude/projects/, auto-memory is not set up for this project — write only the rule file and tell the user the memory entry was skipped (offer to create the memory directory on request).

1. Rule file. Append the rule block to ~/.claude/skills/think-like-me/rules/<category>.md. Create the file if the category doesn't exist yet.

2. Memory entry. Write ~/.claude/projects/<current-project>/memory/feedback_<slug>.md with frontmatter:

   ---
   name: <rule title>
   description: <one-line hook matching the rule's gist>
   type: feedback
   ---
   <2–3 line compact summary>
   
   Full rule: `~/.claude/skills/think-like-me/rules/<category>.md` → *<rule title>*
   

3. MEMORY.md pointer. Append one line to ~/.claude/projects/<current-project>/memory/MEMORY.md:

   - [<rule title>](feedback_<slug>.md) — <one-line hook>
   

Cross-project rules. If the user marks a rule as cross-project during the draft-review gate, still write the memory entry to the current project's memory (one concrete landing place). The rule file is global — no per-project mirroring needed. When the skill is first invoked in a different project, offer to mirror the memory entry there lazily.

Rule format

See references/rule-format.md. Minimum fields: title (H3), When, Do, Why. Optional: Don't, Example.

Relationship to auto-memory

• Memory stays the passive recall layer: project facts, references, per-project corrections live there.
• Rules are the active reasoning layer: cross-project technical patterns live in rules/*.md.
• When a memory entry and a rule cover the same topic, the rule is authoritative — it's the structured, curated version.

Guardrails

• Rule conflicts. If two matching rules give contradictory advice, flag the conflict in your acknowledgment line and ask the user which applies before proceeding.
• Stale rules. If the user corrects against a rule you just applied, treat it as a strong signal to propose updating or removing that rule, not just adding a new one.
• Approval gate is non-negotiable. Never save a rule without explicit user approval on the draft — even in auto-detect mode.