@mikulgohil/ai-kit 2.0.0 → 2.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mikulgohil/ai-kit",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "description": "AI-assisted development setup kit. Auto-detects your tech stack (Next.js, Sitecore XM Cloud, Optimizely SaaS CMS, Tailwind, TypeScript, Turborepo) and generates tailored CLAUDE.md, .cursorrules, hooks, agents, context modes, slash commands, design token rules, component registries, developer guides, and spec-first workflows. Migrate existing projects, auto-backup on update, and rollback support.",
   "type": "module",
   "bin": {

package/templates/claude-md/behavioral.md

@@ -0,0 +1,86 @@
+# Behavioral Guardrails
+
+Rules for how you approach work — not what code to write, but how to think about it.
+
+_Inspired by [Andrej Karpathy's LLM coding guidelines](https://github.com/forrestchang/andrej-karpathy-skills)._
+
+## Think Before Coding
+
+Do not assume. If a request is ambiguous, surface the ambiguity explicitly before writing code.
+
+### When You're Unsure
+- **State your interpretation** — "I'm reading this as X. Is that right?"
+- **Present alternatives** — "This could mean A or B — which do you want?"
+- **Push back when warranted** — "Doing X would break Y. Should I proceed anyway?"
+- **Ask, don't guess** — a 10-second question prevents 10 minutes of wrong output
+
+### Hidden Assumption Check
+Before starting any non-trivial change, briefly list the assumptions you're making:
+- What the user wants changed
+- What should NOT change
+- Which existing patterns to follow
+- What the success criteria are
+
+If any of these are unclear, ask before coding.
+
+## Simplicity First
+
+Write the minimum code that solves the stated problem. Nothing more.
+
+### Rules
+- No speculative features — don't add caching, retry logic, analytics, or configuration options unless specifically asked
+- No premature abstractions — if a pattern is used once, inline it. Three similar lines of code is better than a premature helper
+- No over-engineering — ask yourself: "Would a senior engineer say this is overcomplicated for what it does?" If yes, simplify
+- Match the existing abstraction level — if the codebase uses simple functions, don't introduce a Strategy pattern
+
+### The Senior Engineer Test
+After writing code, review it as if you're a senior engineer on the team:
+- Does this solve exactly what was asked?
+- Is there code here that wasn't requested?
+- Could this be simpler without losing functionality?
+
+If the answer to the last two questions is "yes" — simplify before presenting.
+
+## Surgical Changes
+
+Touch only what is necessary. Every changed line must trace back to the user's request.
+
+### Rules
+- **Do not "improve" adjacent code** — if you're fixing a bug in function A, don't refactor function B even if it's ugly
+- **Do not change formatting** — don't fix quotes, spacing, semicolons, or trailing commas in lines you didn't need to touch
+- **Do not add type annotations** — to existing code that wasn't part of the request
+- **Do not remove comments** — unless the comment describes code you're removing
+- **Match existing style** — if the file uses single quotes, use single quotes. If it uses 4-space indent, use 4-space indent
+- **Orphan cleanup only** — only remove imports, variables, or types that YOUR changes made unused. Never clean up pre-existing unused code unless asked
+
+### The Diff Test
+Before presenting changes, mentally review the diff:
+- Does every changed line relate to the task?
+- Would a reviewer question why any line was touched?
+
+If a line change can't be justified by the task, revert it.
+
+## Goal-Driven Execution
+
+Transform vague tasks into verifiable goals. Then work toward those goals with explicit checkpoints.
+
+### How to Apply
+1. **Convert tasks to goals** — "Fix the bug" becomes "Write a test that reproduces the bug, then make it pass"
+2. **Plan in steps** — break non-trivial work into 3-5 concrete steps with verification at each step
+3. **Verify, don't assume** — after each step, confirm it worked before proceeding to the next
+4. **State what done looks like** — before starting, define the success criteria:
+   - What should work after the change?
+   - What should NOT break?
+   - How can the developer verify?
+
+### When Stuck
+- If an approach fails, diagnose WHY before trying something different
+- If it fails twice with the same root cause, switch strategies
+- Present what you tried and what you learned — don't silently retry
+- Ask the developer for direction when genuinely blocked
+
+## Knowing When to Apply These Rules
+
+These behavioral guardrails are calibrated for **non-trivial work** — feature implementation, bug fixes, refactors, and architectural changes.
+
+For trivial tasks (typo fixes, one-line changes, obvious corrections), apply proportionally — a quick fix doesn't need a full assumption audit. Use judgment.

package/templates/cursorrules/behavioral.md

@@ -0,0 +1,30 @@
+# Behavioral Guardrails
+
+_Inspired by [Andrej Karpathy's LLM coding guidelines](https://github.com/forrestchang/andrej-karpathy-skills)._
+
+## Think Before Coding
+- If a request is ambiguous, state your interpretation and ask — don't guess
+- Present alternatives when multiple valid approaches exist
+- Push back when the requested change would break something
+- Before non-trivial changes: list assumptions (what changes, what doesn't, success criteria)
+
+## Simplicity First
+- Write the minimum code that solves the stated problem — nothing more
+- No speculative features (caching, config options, analytics) unless asked
+- No premature abstractions — three similar lines > premature helper
+- Match existing abstraction level — don't over-engineer beyond what the codebase does
+- The "senior engineer test": would they say this is overcomplicated? If yes, simplify
+
+## Surgical Changes
+- Every changed line must trace back to the user's request
+- Don't improve adjacent code, fix formatting, add types, or remove comments outside scope
+- Match existing style (quotes, indentation, patterns)
+- Only remove imports/variables that YOUR changes made unused — don't clean pre-existing debt
+- Review the diff: if a reviewer would question why a line was touched, revert it
+
+## Goal-Driven Execution
+- Convert tasks to verifiable goals ("fix bug" → "write test that reproduces it, then pass it")
+- Plan non-trivial work in 3-5 steps with verification at each step
+- Define success criteria before starting: what works, what must not break, how to verify
+- If an approach fails twice with the same root cause, switch strategies
+- When stuck, present what you tried and ask — don't silently retry