What Is a RuleSync Ruleset?
A RuleSync ruleset: a named, versioned collection of AI coding rules. Rulesets are: created and edited in the dashboard (or via CLI), assigned to one or more projects, pulled to project repositories as CLAUDE.md or .cursorrules files, and versioned (every change creates a new version, previous versions are preserved). One ruleset can serve many projects. One project can use multiple rulesets (composed into a single output file). This centralization: is the core value of RuleSync — manage rules once, distribute everywhere.
Ruleset types: base ruleset (organization-wide rules — security, testing, code quality. Assigned to every project), technology ruleset (language or framework-specific rules — TypeScript, Go, Python, React, NestJS. Assigned to projects using that technology), and project ruleset (project-specific rules — domain terminology, API patterns, unique conventions. Assigned to a single project). Projects: inherit rules from all assigned rulesets, composed in order (base → technology → project).
Your first ruleset: start with a base ruleset that covers your organization's core conventions. This single ruleset: immediately improves AI output across all assigned projects. Add technology and project rulesets later as needed.
Step 1: Create the Ruleset (5 Minutes)
From the dashboard: Rulesets → New Ruleset. Enter: name (e.g., 'Organization Base Rules' or 'TypeScript Conventions'), description (what the ruleset covers), type (base, technology, or project), and technology tag (for technology rulesets: TypeScript, Go, Python, etc.). The name and description: displayed to team members when they browse available rulesets.
Choose a starting point: Blank (start from scratch — for teams with strong opinions about their conventions), Template (start from a pre-built template — recommended for most teams). Templates available: Next.js App Router, NestJS Backend, Go Microservice, Python FastAPI, React Native Mobile, and more. The template: provides 15-20 rules covering the stack's common conventions. Customize 20% (your team-specific decisions) and keep 80% (common conventions).
Add rules: the dashboard editor provides a Markdown editor with: syntax highlighting, rule validation (warns about vague rules, missing alternatives for prohibitions, and potential conflicts), and live preview (shows how the rules will appear in the generated CLAUDE.md). Write or paste your rules. The editor: accepts standard Markdown (headings, bullet points, code blocks). AI rule: 'Start with a template and customize. Faster than writing from scratch and covers the common conventions you would write anyway.'
The Next.js App Router template: 18 rules covering Server Components, data fetching, routing, styling, and testing. Your team agrees with 15 of them immediately. 3 need adjustment (your error handling pattern, your test framework preference, your component library). Customize those 3. Keep the 15. Total time: 10 minutes. Starting from scratch with the same coverage: 2+ hours. Templates are not shortcuts — they are proven starting points that your customization makes your own.
Step 2: Configure Output and Versioning
Output formats: choose which files the ruleset generates when pulled. Options: CLAUDE.md (for Claude Code), .cursorrules (for Cursor), .github/copilot-instructions.md (for GitHub Copilot), and custom (for other tools or custom file paths). Most teams: select CLAUDE.md + .cursorrules (covers the two most popular AI coding tools). The content: identical across all formats. The file name and location: tool-specific.
Versioning: every save creates a new version. The dashboard: shows the version history with diffs between versions. Team members: can compare versions to see what changed. Projects: can pin to a specific version (for stability) or always use the latest (for automatic updates). Default: latest. Pinning: for production-critical projects that need to validate rule changes before adoption.
Publishing: after editing, the ruleset is in draft state. Publish: makes the ruleset available to projects. Draft → Published: team members can now pull this ruleset. Published → Updated: a new version is published, projects using 'latest' get the update on next pull. AI rule: 'Publish when the ruleset is ready for the team. Draft mode: for work-in-progress. Published: for team consumption. The publish action: triggers notifications to assigned projects.'
Typing a prohibition without an alternative: the editor highlights it with a warning ('This prohibition has no alternative. The AI will know what to avoid but not what to use instead.'). Writing a vague rule ('handle errors properly'): the editor suggests adding specificity. The validation: catches common rule-writing mistakes before you publish. It is like ESLint for your rules — catching issues at authoring time, not after the team discovers them.
Step 3: Assign to Projects and Pull
Assign the ruleset to projects: Rulesets → [your ruleset] → Assigned Projects → Add Projects. Select the projects that should use this ruleset. For a base ruleset: assign to all projects. For a technology ruleset: assign to projects using that technology. The assignment: tells RuleSync which rulesets to compose when a project pulls rules.
Pull to a project: in the project directory, run rulesync pull. The CLI: fetches all assigned rulesets, composes them (base → technology → project order), and writes the output files. The generated CLAUDE.md: contains all rules from all assigned rulesets, with clear section headers showing which ruleset contributed which rules. Commit the generated files to the repository.
Verify: open Claude Code (or Cursor) in the project. Prompt: 'What coding conventions should I follow in this project?' The AI: references the rules from the generated file. Prompt a real task: 'Create a new API endpoint.' The AI: generates code following the rules. If the output matches your conventions: the setup is complete. If not: review the ruleset and adjust the rules that are not producing the expected output. AI rule: 'The verification prompt is the final quality check. If the AI follows the rules: success. If not: the rule needs to be more specific or the composition order needs adjustment.'
A common mistake: creating a ruleset and forgetting to publish. The team runs rulesync pull: nothing is downloaded (the ruleset is in draft). The developer: thinks RuleSync is broken. Always publish after the ruleset is ready for team use. The dashboard: shows draft vs published status prominently. Draft rulesets: visible only to the author. Published rulesets: available to all team members and projects.
First Ruleset Summary
Complete first RuleSync ruleset setup.
- Concept: rulesets are named, versioned rule collections. Assigned to projects. Pulled as CLAUDE.md/.cursorrules
- Types: base (all projects), technology (language-specific), project (unique conventions)
- Create: dashboard → New Ruleset. Start from template (recommended) or blank
- Editor: Markdown with syntax highlighting, rule validation, and live preview
- Output: CLAUDE.md + .cursorrules (default). Copilot instructions and custom paths also supported
- Versioning: every save creates a version. Diff between versions. Pin or use latest
- Publish: draft → published. Triggers availability for team pull and notifications
- Assign + Pull: assign rulesets to projects. rulesync pull generates the composed output files