generate-rules

Generate project rules

Use this skill when the user invokes /generate-rules. Behave like Cursor's built-in "Generate Cursor Rules": analyse the codebase first, derive rules from what you find, then write them without asking the user to describe the project.

Phase 1 — scan (do this before writing anything)

Read in order, skimming for patterns:

1. README.md, AGENTS.md, DESIGN.md — stated purpose, tech stack, conventions
2. Build / package manifest: go.mod, package.json, Cargo.toml, pyproject.toml, Makefile — languages, dependencies, build commands, test commands
3. Top-level directory layout (ls) — identify main packages / layers
4. internal/ or src/ root — two or three representative source files per package (not all files)
5. *_test.go / *.test.* / tests/ — understand test strategy and naming
6. Existing rules under .cursor/rules/, .coddy/rules/, .claude/rules/ — read every file to avoid duplicates and understand what is already covered
7. CI config (.github/workflows/, Dockerfile, .pre-commit-config.yaml) if present

Skip binary, generated, or vendored files.

Phase 2 — plan

After scanning, output a brief plan (not the rules yet): a table listing each proposed file, its globs/type, and one-line purpose. Ask the user to confirm, adjust scope, or skip topics before writing.

Example:

File	Type	Purpose
architecture.mdc	always, **/*.go	layer dependencies and import direction
code-style.mdc	always, **/*.go	formatting, lint, comment language
testing.mdc	always, **/*_test.go	test commands, table-driven conventions
api-layer.mdc	manual	HTTP handler patterns and OpenAPI sync

Update or skip existing files that already cover a topic well.

Phase 3 — write

Write each confirmed file. Default target directory:

• .cursor/rules/ if it already exists in the repo
• Otherwise .coddy/rules/
• Use .claude/rules/ only if the user explicitly asks