dev-rules

name	dev-rules
description	Core development rules and philosophy for coding standards, git practices, and quality guidelines

Define coding standards and practices that MUST be followed for all development work. Establish session continuity, git safety, documentation discipline, and development philosophy at the start of any task.

Triggers on any implementation, fix, or refactoring task

Announce: "I'm applying the dev-rules skill to ensure we follow project standards and best practices."

At session start, scan `specification/` directories (highest index first) for `[doc-index]-handoff.md`. If found, present prior context: what was done, key decisions, unfinished items, risks, recommended first steps. This informs requirements awareness, code assessment, and avoids redundant work. 1) `get_design_context` first (if truncated, `get_metadata` then re-fetch specific nodes). 2) `get_screenshot` for visual reference. 3) Only then download assets and implement. 4) Translate into project conventions — reuse existing tokens/components. 5) Validate 1:1 visual parity. Use wrapper scripts via Bash (Exa, DeepWiki, Context7, GitHub) per `${CLAUDE_PLUGIN_ROOT}/scripts/README.md`. Exception: `mcp__time-mcp__current_time` allowed directly. Always add current date/time as context Prefer AST-based pattern matching for structural code searches Never create GitHub Actions. Don't `git add -A` — selective staging only. Only commit files you edited. Always generate proper commit messages. ALL development MUST be in a worktree. Verify with `test -f .git`. If not in worktree, create: `git worktree add .worktree/[spec-index]-[spec-name]`. Branch name MUST match worktree name. Stash before major operations. Commit after every completed task (small, atomic). Verify `git status` clean between stages. Clean working tree at end of session. Commit docs WITH code. Mark tasks complete immediately. Update implementation summary after each milestone. Update spec when code deviates (same commit). For complex features and bugs, break down to fundamental truths Small commits, each must compile and pass tests Study 3 similar features before implementing Adapt to project's actual situation Simple, clear solutions Testability → Readability → Consistency → Simplicity → Reversibility Stop after 3 attempts. Record failures. Research 2-3 alternatives. Question assumptions. Running `git add -A` — stages everything including untracked files and build artifacts Forgetting git stash before major operations — context compaction can lose uncommitted work Working in main repo instead of worktree — breaks branch isolation Not checking for existing specs — duplicate specs fragment documentation Skipping doc updates when committing — code and docs must go together Ignoring the 3-attempt limit — infinite retry loops waste tokens Creating GitHub Actions accidentally