Imported from equinor/fusion-skills (skills/.system/fusion-rule-author/SKILL.md) via skills.sh. Install upstream with npx skills add equinor/fusion-skills --skill fusion-rule-author. Copyright stays with the author (MIT).

Rule Author

Canonical workflow, templates, and references for authoring AI coding assistant rules. Supports GitHub Copilot, Cursor, and Claude Code.

Internal skill. Users interact via the fusion-rules gateway, which routes to editor-specific agents that follow the workflow defined here.

Scope

This skill provides:

• Workflow (Steps 1–7 below) — the guided authoring process
• Templates (assets/) — starter files for each editor format
• References (references/) — tech-stack examples

It does not provide agents. Agents live in fusion-rules/agents/ and reference this skill's assets and workflow.

Required inputs

Mandatory

• Repository context (working directory or repo URL)

Gathered during interview

• Tech stack (languages, frameworks, build tools)
• Code conventions (naming, formatting, patterns)
• Testing expectations (framework, coverage, style)
• Documentation preferences (comments, TSDoc/JSDoc, README standards)
• Commit and PR conventions
• Error handling patterns
• Security or compliance constraints
• File/path-specific conventions that need scoped rules

Instructions

Step 1 — Assess current state

Check the repository for existing rule files:

.github/copilot-instructions.md
.github/instructions/*.instructions.md
.cursor/rules/*.md
.cursor/rules/*.mdc
.cursor/rules/**/*.md
.cursor/rules/**/*.mdc
CLAUDE.md
.claude/CLAUDE.md
.claude/rules/*.md
.claude/rules/**/*.md

Report what exists, what is missing, and whether updates or new files are needed.

Step 2 — Scan repository

Before interviewing, scan for existing documentation and configuration that encodes conventions. Extract actionable directives from:

Documentation files:

• README.md — project overview, setup, tech stack
• CONTRIBUTING.md — code style, PR workflow, commit conventions
• AGENTS.md, CLAUDE.md — existing AI instructions
• docs/adr/**, adr/**, docs/decisions/** — Architecture Decision Records
• docs/**/*.md — developer guides, onboarding docs, style guides
• SECURITY.md — security policies
• CODE_OF_CONDUCT.md — collaboration guidelines (rarely rule-relevant)

Configuration files:

• package.json / pyproject.toml / *.csproj — tech stack, scripts, dependencies
• tsconfig.json / jsconfig.json — language settings, strictness
• biome.json / .eslintrc* / .prettierrc* / ruff.toml / .editorconfig — formatting and linting
• .github/workflows/*.yml — CI checks, required validations, test commands
• Dockerfile / docker-compose.yml — runtime environment
• Makefile / Justfile / Taskfile.yml — build and task commands

Code patterns (sample, don't exhaustively read):

• Entry points (src/index.*, src/main.*, app.*) — architecture patterns
• Test files — testing framework, naming conventions, file placement
• Directory structure — architectural boundaries, feature organization

For each source, extract:

1. Concrete conventions that can become imperative directives
2. Build/test/lint commands the AI should know
3. Architecture boundaries or patterns to follow
4. Explicit "do this / don't do that" rules

Skip:

• Implementation details that change frequently
• Content that restates language/framework defaults
• Aspirational rules not enforced by CI or team practice

Present summary of discovered conventions to the developer, organized by area, before proceeding to the interview.

Step 3 — Interview (fill gaps)

Use scan results to skip areas already well-documented. Ask focused questions only for gaps. Cover these areas one at a time:

1. Tech stack — languages, frameworks, runtime, package manager
2. Code style — naming conventions, formatting rules, import ordering
3. Architecture — project structure, key patterns (MVC, hexagonal, etc.)
4. Testing — framework, conventions, coverage expectations
5. Documentation — inline comments style, doc generation, README standards
6. Git workflow — branch naming, commit message format, PR expectations
7. Security — sensitive data handling, auth patterns, compliance rules
8. Path-specific concerns — directories or file types needing specialized guidance

For each area, present what the scan found and ask: "Is this accurate? Anything to add or correct?" Don't re-ask for information already captured.

For each convention needing deeper context, use follow-up questions in assets/creation-follow-up.md — purpose, exceptions, boundaries, voice.

Step 4 — Classify guidance

Separate the gathered conventions into buckets:

GitHub Copilot:

Cursor:

Claude Code:

Decision rule: If a convention applies to all files in the repo, it belongs in root / always-on instructions. If it applies only to specific paths or file types, create a scoped rule.

When targeting multiple editors, generate parallel files with equivalent content — do not duplicate guidance within a single editor's files.

Step 5 — Draft rule files

Generate files using templates in assets/:

GitHub Copilot:

• Root instructions: use assets/copilot-instructions-template.md
• Scoped instructions: use assets/scoped-rule-template.md with correct applyTo glob

Cursor:

• Use assets/cursor-rule-template.mdc and set frontmatter accordingly

Claude Code:

• Project instructions: use assets/claude-rule-template.md
• Scoped rules: place in .claude/rules/ with paths frontmatter

Quality rules (enforced during drafting):

• Keep instructions concise — actionable directives, not explanations
• Use imperative voice ("Use camelCase for variables", not "Variables should use camelCase")
• Avoid duplicating guidance between root and scoped files
• Validate applyTo / globs / paths glob patterns match intended files
• Warn if total root instructions exceed ~80 lines (risk of context dilution)
• Warn if scoped instruction file exceeds ~50 lines (GitHub Copilot), ~500 lines (Cursor), ~200 lines (Claude Code CLAUDE.md)
• See references/examples.md for concrete good/bad examples
• See assets/quality-checklist.md for full checklist

Step 6 — Review and refine

Present drafted files to the developer. For each file:

1. Show full content
2. Highlight quality warnings (length, broad globs, duplication)
3. Ask for approval or edits

Step 7 — Write files

After approval, write rule files to the repository. Create .github/instructions/, .cursor/rules/, and/or .claude/rules/ directories as needed.

Confirm final file list and paths before writing.

Expected output

• .github/copilot-instructions.md — root instructions file (created or updated)
• .github/instructions/*.instructions.md — zero or more scoped instruction files
• .cursor/rules/*.mdc — zero or more Cursor rule files (when Cursor is targeted)
• CLAUDE.md or .claude/CLAUDE.md — project instructions (when Claude Code is targeted)
• .claude/rules/*.md — zero or more Claude Code scoped rule files
• Summary of what was created/updated and why

Instructions vs skills vs rules — when to use which

Instructions and rules shape how the AI writes code. Skills define what it can do as structured tasks.

Safety and constraints

Never:

• Embed secrets, tokens, or credentials in rule files
• Generate rules that contradict repository security policies
• Overwrite existing files without showing the diff and getting approval
• Invent conventions — only document what the developer confirms

Always:

• Show drafts before writing any files
• Validate glob patterns against actual repository paths
• Warn on overly broad globs (e.g., **/* captures everything)
• Keep instructions concise and actionable
• Preserve existing content when updating (append or merge, never replace silently)

References

• references/examples.md — concrete examples for different tech stacks
• assets/creation-follow-up.md — per-rule follow-up questions (purpose, exceptions, boundaries, voice)
• assets/frontmatter-scenarios.md — scenario-based frontmatter guide for GitHub Copilot, Cursor, and Claude Code
• assets/copilot-instructions-template.md — starter template for root instructions
• assets/scoped-rule-template.md — starter template for scoped rules
• assets/cursor-rule-template.mdc — starter template for Cursor rules
• assets/claude-rule-template.md — starter template for Claude Code rules
• assets/quality-checklist.md — quality review checklist