AI Coding Workflow, Rules & Skills Explained (With Examples)

1. Why AI coding needs Workflow, Rules, and Skills as separate layers

AI coding assistants are Agents with tool access: they read repos, edit files, and run terminals. Their weakness is equally obvious—every new chat starts from amnesia unless you re-inject team norms into the prompt. Worse, some teams dump code style, Git policy, release checklists, and incident runbooks into a single User Rule. Each message then carries thousands of tokens of policy, crowding out the diff, logs, and stack traces that actually matter for the task at hand.

Best practice in 2026 is to split constraints and procedures into three layers:

• Workflow: How you start an AI task—slash commands, Plan/Agent mode switches, CI triggers, remote Agent orchestration.
• Rules: What always holds—language style, forbidden directories, test requirements, security red lines.
• Skills: What runs on demand—code review checklists, Xcode release steps, migration runbooks, usually in SKILL.md.

This mirrors the logic in our Agent development modes guide: entry points define behavior boundaries, not model parameter tables. The open standard for Skills is the Agent Skills Specification; Cursor documents Rules at cursor.com/docs/context/rules.

Think of it like airport security versus a flight manual. Rules are the metal detector—always on, same for everyone. Skills are the pilot’s checklist for a specific aircraft type—pulled out only when that plane is on the ramp. Workflow is air-traffic control—who gets clearance, in what order, and on which runway. Mixing all three into one blob is how teams end up with 8,000-token system prompts that the model partially ignores because half the content is irrelevant to the current edit.

Layering also improves reviewability. When a junior developer changes a Rule, every future conversation shifts—that deserves a careful PR. When someone updates a Skill, only users who invoke that Skill pay the context cost. When a Workflow changes, you update a command doc or CI job without touching global behavior. Governance teams can audit Rules quarterly; platform teams can version Skills like internal libraries; DevOps owns Workflows. Without separation, “who approved this prompt change?” has no answer.

Finally, layered design makes onboarding measurable. New hires clone the repo and inherit the same Rules and project Skills on day one. They learn Workflows from .cursor/commands/ READMEs instead of tribal knowledge in Slack. That is how AI-assisted development scales past a handful of power users.

2. How to classify Workflow, Rules, and Skills

2.1 Workflow — how tasks are started and orchestrated

Workflow answers who pulls the Agent, and when. Typical forms include Cursor custom commands like /generate-blog, switching between Plan Mode and Agent Mode, Claude Code /loop and batch jobs, GitHub Actions that call AI to fix CI, and gateways such as OpenClaw that connect Telegram or cron to a remote Mac. Workflow cares about triggers, state machines, and artifact paths—not single-line formatting preferences.

A mature Workflow documents gates: “brief approved → generate zh → human OK → i18n.” It names outputs (articles.json, staging images) and failure behavior (retry, notify, halt). Without explicit gates, Agents improvise—and improvisation is where production incidents come from.

2.2 Rules — the always-on constraint layer

Rules are resident context. In Cursor, common locations are .cursor/rules/*.mdc (project), Rules in user Settings, and root AGENTS.md. Good Rule content: minimize diff scope, directories the Agent must not touch, commit conventions, reply language, when tests are mandatory. Rules should be short, hard, and executable. Do not embed a 30-step release procedure in a Rule—that belongs in a Skill.

Rules also set tone and risk appetite: “prefer asking over guessing,” “never delete files without confirmation,” “use TypeScript strict mode.” Keep each file scannable in one screen. If you need conditional logic (“only for *.tsx in frontend/”), use glob-scoped .mdc files instead of one mega-rule.

2.3 Skills — on-demand runbooks

Skills are load-on-demand workflow packages. Claude Code uses .claude/skills/<name>/SKILL.md; Cursor uses .cursor/skills/<name>/SKILL.md (or a user-level Skills directory). The Agent reads description in frontmatter first and loads the body only when matched—saving context versus Rules. For deep Skill design, see our Claude Code Skills: 10-skill framework guide.

Skills can ship supporting files: references/checklist.md, scripts, or templates. High-risk Skills (security review, production deploy) should set disable-model-invocation: true so only explicit /skill-name invocation runs them—never accidental semantic triggers during unrelated edits.

3. Core comparison table

3.1 Rules vs Skills — quick division of labor

4. Scenario decision matrix

5. Recommended stacks

Stack A — minimum viable (half a day)

• Three User Rules: minimal diff, no unsolicited commits, run lint after edits
• Project .cursor/rules/blog-writing.mdc for repo-specific constraints only
• Personal commit Skill: generate Conventional Commits from staged diff

Stack B — team standards

• Rules: testing.mdc + security.mdc (each < 80 lines)
• Skills: code-review, security-review (manual trigger)
• Workflow: PR template says “run /security-review before merge”

Stack C — iOS delivery

• Skill xcode-release (disable-model-invocation: true)
• Rules: do not edit *.xcodeproj unless explicitly asked
• Execution node: local M4 or Hashvps Cloud Mac; pair with GitHub Actions macOS build trends—heavy compiles on remote

Stack D — content / docs engineering

• Workflow: /generate-blog-style command (brief → zh → i18n gate)
• Rules: blog-standard-spec-v1.mdc structure constraints
• Skills: translate-to, seo-optimize loaded on demand

6. Common mistakes

• “Put everything in User Rules—it’s easiest” → Resident prompts swell and crowd out code context; move runbooks into Skills.
• “More Skills is always better” → Overlapping description fields fight for triggers; stay under ~10 with clear boundaries.
• “Workflow replaces CI” → AI assists development; gates still belong in GitHub Actions / Xcode Cloud as hard checks.
• “Rules and Skills can live in one file” → Different review and load mechanics; a one-line Rule change affects every chat.
• “xcode-release Skill works without a Mac” → codesign needs macOS—local or Cloud Mac node required.
• “Plan Mode equals Workflow” → Plan is an interaction mode; Workflow is repeatable, scriptable triggers and artifact contracts.

7. Seven-step rollout with copy-paste examples

1. Audit repeated prompts: Did you type the same review checklist three times last week? Candidate Skill.
2. Write 3 Rules: Keep only “always true” red lines—each readable on one screen.
3. Create Skill directories: mkdir -p .cursor/skills/code-review (Cursor) or .claude/skills/code-review (Claude Code).
4. Write SKILL.md frontmatter: description uses verb + scenario; high-risk adds disable-model-invocation: true.
5. Define Workflow: Encode gates like “brief OK → then i18n” in .cursor/commands/*.md or team runbooks.
6. Commit to Git: Project Rules and Skills in the same PR as code—avoid “only seniors have the config locally.”
7. Bind execution nodes: Workflows with shell/Xcode point at a macOS host (local or Cloud Mac) for consistent SSH environments.

# .cursor/rules/core.mdc
---
description: Core engineering constraints for this repo
globs: "**/*"
---
- Minimize diff scope; do not refactor unrelated code.
- Never commit unless the user explicitly asks.
- Run tests for touched packages before claiming done.

# .cursor/skills/code-review/SKILL.md
---
name: code-review
description: Review staged git diff for bugs, security, and test gaps. Use when user asks for review or before PR.
---
1. Run `git diff --staged` (or compare branch to main).
2. Output: Critical / Warning / Suggestion in three sections.
3. Do not auto-fix unless user asks.

# .cursor/commands/release-ios.md
## Workflow
1. User confirms brief / scope on main branch.
2. Agent runs /test-runner Skill on changed targets.
3. Manual /xcode-release only after CI green.
4. Post changelog; never skip codesign on shared runner.

8. Summary

In 2026, AI coding competitiveness depends increasingly on workflow engineering, not a single model score. Workflow defines how tasks start; Rules guard what always holds; Skills turn senior checklists into versioned, shareable, permission-bounded runbooks. Layer first—then consider a pricier subscription.

Remember the asymmetric conclusion: model capability is not the watershed; entry points and execution boundaries are. Further reading: Cursor Rules · Claude Code Skills · Agent Skills open standard