From rule-creator
Generate project-specific Claude Code rules (.claude/rules/) by analyzing the codebase. Use this skill when the user wants to create, add, or set up rules for their project, establish coding conventions, or configure path-scoped instructions for Claude.
npx claudepluginhub t0k0sh1/agent-plugins --plugin rule-creatorThis skill uses the workspace's default tool permissions.
A skill for generating project-specific Claude Code rules by analyzing the codebase and collaborating with the user.
Generates project-specific CLAUDE.md rules by detecting stack from package.json, Cargo.toml, pyproject.toml, go.mod, git log, and user-selecting categories like response format, library preference, code review stance. Use for new projects, repo onboarding, or establishing conventions.
Guides creation of .claude/rules/ files for path-scoped project conventions using TDD workflow: RED (test gaps), GREEN (write rule), REFACTOR (optimize). Triggers on 'add rule', 'create convention', 'scope guideline'.
Guides authoring rule files in .claude/rules/ for project conventions including formatting, testing, commits, architecture, and referencing from CLAUDE.md.
Share bugs, ideas, or general feedback.
A skill for generating project-specific Claude Code rules by analyzing the codebase and collaborating with the user.
This skill analyzes a project's codebase to detect its technology stack, then proposes and generates appropriate .claude/rules/ files through an interactive dialogue. Unlike skill creation, rules are declarative and always-on, so this follows a single-pass flow: analyze, propose, discuss, generate, review.
Scan the project to understand its technology stack and conventions. Look for:
Language & framework indicators:
package.json (Node.js — check for React, Next.js, Vue, Express, etc.)tsconfig.json (TypeScript)go.mod (Go)Cargo.toml (Rust)pyproject.toml, requirements.txt, setup.py (Python — check for Django, Flask, FastAPI, etc.)Gemfile (Ruby)composer.json (PHP — check for Laravel, Symfony, etc.)CMakeLists.txt (C/C++)build.gradle, pom.xml (Java/Kotlin)*.swift, Package.swift (Swift)Build & tooling indicators:
.eslintrc*, biome.json, .prettierrc (linting/formatting)jest.config.*, vitest.config.*, pytest.ini, .rspec (testing)Dockerfile, docker-compose.yml (containerization)Makefile, justfile (build automation).github/workflows/ (CI/CD)Existing Claude configuration:
.claude/rules/ (existing rules — avoid duplication)CLAUDE.md (existing project instructions — complement, don't repeat).claude/settings.json (permissions and tool config)Report findings concisely to the user before proceeding.
Based on the analysis, propose relevant rule categories. Common categories include:
| Category | When to propose | Example paths |
|---|---|---|
| Code style | Always | src/**/*.{ts,tsx} |
| Testing conventions | Test framework detected | tests/**/*, **/*.test.* |
| API design | API routes/controllers found | src/api/**/*, src/routes/**/* |
| Database | ORM/migration files found | **/migrations/**, **/models/** |
| Security | Auth/crypto code found | src/auth/**/*, **/*.env* |
| Documentation | Docs directory exists | docs/**/*, **/*.md |
| Component patterns | UI framework detected | src/components/**/* |
| Build & CI | CI config found | .github/**/*, Dockerfile |
Present the proposed categories with a brief explanation of what each rule would cover. Ask the user which ones they want, and if they have additional categories in mind.
For each selected category, ask one question at a time to understand specific preferences:
Keep this lightweight — don't over-interview. If the codebase already reveals the conventions (e.g., existing ESLint config, test patterns), state what you found and ask for confirmation rather than asking from scratch.
Before generating, verify:
.claude/rules/ filesCLAUDE.md instructionspaths: patterns actually match files in the project (run a quick glob check)If conflicts are found, present them and ask how to resolve.
Generate each rule as a separate .md file in .claude/rules/. Follow this format:
---
paths:
- "relevant/glob/**/*.ext"
---
# Rule Title
- Concise, actionable instruction
- Explain the why, not just the what
- One topic per rule file
Writing guidelines:
paths: to scope rules to relevant files — avoid global rules unless truly universal.md file per topic for maintainabilitycode-style.md, testing.md, api-design.mdPresent the generated rules to the user for review:
Once approved, confirm the files are written and summarize what was created.
paths: to keep rules relevant and save context tokens