Skip to content
/
Tier A A8 Cross-runtime harness

Bhartendu-Kumar/rules_template

rules-template-stackable · Bhartendu-Kumar/rules_template · ★ 1.1k · last commit 2025-07-17

Cross-platform rule template for Cursor + Cline + Roo Code using symbolic links for a shared single source of truth with Agile-inspired SDLC workflow.

Best whenRules should live in a single source (Cursor MDC files) with symbolic links pointing to them from other IDE config directories — edit once, propagate everywh…
Skip ifUsing deprecated .cursorrules file (use .cursor/rules/ directory), Using deprecated .clinerules file (use .clinerules/ directory with subdirs)
vs seeds
superpowerson-demand MDC loading, and RooFlow Roo Code mode overrides. The defining innovation is symbolic link cross-IDE architect…
Primitive shape 13 total
Skills 9 Subagents 3 MCP tools 1
00

Summary

rules-template-stackable — Summary

rules-template-stackable (Bhartendu-Kumar/rules_template) is a cross-platform rule template that works simultaneously with Cursor, Cline, and Roo Code by using symbolic links so a single set of rules serves all three IDEs. The framework provides an Agile SDLC-inspired development workflow with on-demand-loading MDC rules (for Cursor), mode-specific rule directories (for Roo Code), and subdirectory-based rule files (for Cline), plus a shared Memory Bank of 7 core documentation files (PRD, architecture, technical, tasks plan, active context, error documentation, lessons learned). A unique innovation is the introduction of 3 custom modes for Roo Code and Cursor (Chat, Write, Debug) that minimize token usage while preserving specialized capabilities. The common Memory Bank ensures consistent context across all three AI assistants.

differs_from_seeds: Combines multiple seed patterns rather than following a single archetype: (1) it uses agent-os's standards file approach (shared docs/ directory), (2) it uses superpowers-style on-demand MDC loading (Cursor rules with alwaysApply: true/false), and (3) it adds Roo Code/Cline mode-specific rule directories like RooFlow. The most distinctive feature is cross-platform symbolic link architecture — .roo/ and .clinerules/ directories symlink to .cursor/rules/ so changes propagate automatically. No seed framework explicitly supports three AI IDEs simultaneously through a single shared source of truth.

01

Overview

rules-template-stackable — Overview

Origin

Created by Bhartendu-Kumar (GitHub). Active (last commit July 2025). Stars: 1,059. No license. Described as: "If using CLINE/RooCode/Cursor/Windsurf Setup these rules. Usable for newbies riding AI wave and experienced folks both. Combines: (1) Memory, (2) Reasoning into subtasks (3) Prompts for best practices."

Philosophy

"To have a comprehensive and optimal Custom User Prompt (Rules) for AI coding. These kind of rules are very much required as the Quality of Outputs is a function of [response Quality = f(prompt, LLM model)]. Thus, for best performance we need very detailed instructions while also giving the LLM the freedom to explore and learn."

Core design principles from the README:

  1. Cross-Platform Compatibility: "Use in Any IDE Any number of different computers for the same project! Respects Cursor, CLINE, RooCode Rule guidelines and mechanisms natively."

  2. Latest Compatibility: Uses .cursor/rules/ (not deprecated .cursorrules), .roo/ (not deprecated .clinerules file), .clinerules/ directories.

  3. Minimal Token Usage:

    • On-demand-loading MDC files in Cursor (only loaded when relevant)
    • Mode-specific rule files in Roo Code
    • 3 new token-saving modes (Chat, Write, Debug) for Roo Code and Cursor

  4. Common Memory Bank: "We have a common memory bank for all the AI assistants. This maintains same context across all the AI assistants."

  5. Fundamental Software Engineering Principles: Agile development workflow with automatic documentation updates.

  6. Automatic Documentation: "The custom prompts are designed such that it will ALWAYS update the documentation after any change. So you focus on building, and it will take care of other things."

Target Audience

"Beginner Friendly & Potential Unlock for Experienced Folks. Both people exploring AI without prior knowledge but tasting the AI/LLM/Agents landscape. And experienced folks adapting to and integrating AI in their workflow."

V2 Updates (Major)

  • 3 new modes (Chat, Write, Debug) for Roo Code and Cursor
  • Token-saving updates
  • More precise separation of IDE-specific rules using symbolic links
02

Architecture

rules-template-stackable — Architecture

Distribution

Standalone repository. Clone and copy directories to project root.

Install (Basic)

# Cursor
cp -r .cursor/rules/ /path/to/project/.cursor/

# Roo Code
cp -r .roo/ /path/to/project/.roo/

# Cline
cp -r .clinerules/ /path/to/project/.clinerules/

# Stack all three simultaneously
# (symlinks make .roo/ and .clinerules/ point to .cursor/rules/ sources)

Directory Tree

rules_template/
├── .cursor/
│   └── rules/                       # ORIGINAL source files
│       ├── architecture-understanding.mdc
│       ├── debug.mdc
│       ├── directory-structure.mdc
│       ├── error-documentation.mdc
│       ├── implement.mdc
│       ├── lessons-learned.mdc
│       ├── memory.mdc               # alwaysApply: true — Memory Bank structure
│       ├── plan.mdc                 # alwaysApply: true — Planning workflow
│       └── rules.mdc
├── .roo/
│   ├── rules/                       # Shared rules (symlinked or copied from .cursor/rules/)
│   ├── rules-architect/             # Architect mode specific rules
│   ├── rules-code/                  # Code mode specific rules
│   ├── rules-debug/                 # Debug mode specific rules
│   ├── system-prompt-chat           # Chat mode system prompt
│   ├── system-prompt-mcp            # MCP mode system prompt
│   └── system-prompt-write          # Write mode system prompt
├── .clinerules/
│   ├── ACT/                         # CLINE Act mode rules
│   ├── PLAN/                        # CLINE Plan mode rules
│   ├── directory-structure.mdc
│   ├── memory.mdc
│   └── rules.mdc
├── docs/                            # Memory Bank documentation files
├── tasks/                           # Task tracking files
├── specific_rule_files/             # Additional rule variants
└── README.md

The key innovation: .cursor/rules/ contains the original rule files. .roo/ and .clinerules/ use symbolic links pointing to these originals, so a single edit propagates to all three IDEs.

.cursor/rules/memory.mdc  ←── .roo/rules/memory.mdc (symlink)
                           ←── .clinerules/memory.mdc (symlink)

Rule File Format

Cursor MDC format (.cursor/rules/*.mdc):

---
description: ALWAYS INCLUDE to HAVE Project Context
globs: 
alwaysApply: true
---
# Memory Files Structure
...

Roo Code system prompt format (.roo/system-prompt-*): Plain text/markdown system prompt overrides for custom modes.

Cline subdirectory format (.clinerules/PLAN/, .clinerules/ACT/): Mode-specific rule files in subdirectories.

Custom Modes (Cursor + Roo Code)

Three token-efficient modes:

  1. Chat — thinking only, no tool use (zero tool access, minimal tokens)
  2. Write — file I/O + commands only (Read Files, Edit Files, Run Command)
  3. Debug — analysis + targeted fixes

Target AI Tools

  • Cursor (primary, MDC rules)
  • Roo Code (secondary, mode-specific rules)
  • Cline (tertiary, subdirectory rules)
  • Windsurf (mentioned)

Required Runtime

None beyond text editor and AI coding IDE.

03

Components

rules-template-stackable — Components

Cursor MDC Rules (9 total)

Rule File alwaysApply Purpose
memory.mdc true Memory Bank structure definition — 7 core files hierarchy
plan.mdc true Planning workflow with CLARIFICATION, STEP BY STEP REASONING, DECOMPOSE blocks
rules.mdc unknown Core coding rules
architecture-understanding.mdc false Load only when architectural context needed
debug.mdc false Debugging procedures
directory-structure.mdc false Project directory structure guidance
error-documentation.mdc false Error logging and documentation
implement.mdc false Implementation procedures
lessons-learned.mdc false Learning capture format

Roo Code Mode-Specific Rules

Directory Mode Purpose
.roo/rules/ All modes Shared rules (symlinked from .cursor/rules/)
.roo/rules-architect/ Architect mode Architecture-specific rules
.roo/rules-code/ Code mode Code-specific rules
.roo/rules-debug/ Debug mode Debug-specific rules

Roo Code System Prompts (3 custom modes)

File Mode Tool Access
.roo/system-prompt-chat Chat NONE (thinking only)
.roo/system-prompt-write Write Read Files, Edit Files, Run Command
.roo/system-prompt-mcp MCP MCP tools

Cline Mode Rules

Directory Mode Purpose
.clinerules/PLAN/ Plan mode CLINE planning mode rules
.clinerules/ACT/ Act mode CLINE act mode rules

Memory Bank (7 Core Files, written to docs/ and tasks/)

File Path Purpose
product_requirement_docs.md docs/product_requirement_docs.md PRD — why project exists, core requirements
architecture.md docs/architecture.md System architecture, component relationships
technical.md docs/technical.md Dev environment, tech stack, design patterns
tasks_plan.md tasks/tasks_plan.md Detailed task backlog with status
active_context.md tasks/active_context.md Current work focus, next steps
error-documentation.mdc .cursor/rules/error-documentation.mdc Reusable error fixes
lessons-learned.mdc .cursor/rules/lessons-learned.mdc Reusable lessons

Additional Artifacts (per-feature)

File Path Purpose
RFC documents tasks/rfc/ Request for Comments per feature
Literature references docs/literature/ Technical references
05

Prompts

rules-template-stackable — Prompts

Prompt 1: memory.mdc (Always-On Context)

Technique: Hierarchical documentation structure with mermaid flowchart enforcing file dependency order.

---
description: ALWAYS INCLUDE to HAVE Project Context
globs: 
alwaysApply: true
---
# Memory Files Structure

```mermaid
flowchart TD
    PB[product_requirement_docs.md] --> PC[technical.md]
    PB --> SP[architecture.md]
    SP --> TC[tasks_plan.md]
    PC --> TC
    PB --> TC
    TC --> AC[active_context.md]
    AC --> ER[error-documentation.mdc]
    AC --> LL[lessons-learned.mdc]

Core Files (Required)

  1. product_requirement_docs.md — Why this project exists, problems it solves, defines core requirements
  2. architecture.md — How it should work, component relationships, Mermaid diagram of solution
  3. technical.md — Technologies used, development setup, key technical decisions
  4. tasks_plan.md — In-depth task backlog, project progress, current status
  5. active_context.md — Current work focus, active decisions, recent changes, next steps
  6. error-documentation.mdc — Reusable error fixes during your interaction
  7. lessons-learned.mdc — If you find a fix to a mistake, note it here

**Technique**: Hierarchical dependency graph as a mermaid flowchart embedded in the always-on rule, teaching the AI the correct document loading order. The "if you find a fix, note it in error-documentation.mdc" is a self-improving memory pattern.

---

## Prompt 2: plan.mdc (Planning Workflow)

**Technique**: Nested XML-style reasoning blocks with multi-attempt optimization loop.

```markdown
---
description: Always include these rules.
globs: 
alwaysApply: true
---
Before every Plan/Architect task ALWAYS do 3 things: [load context files]

# Below is the Planning Workflow to follow:

1. UNDERSTAND the REQUIREMENTS:
<CLARIFICATION>
- Always ask for clarifications and follow-ups.
- Identify underspecified requirements and ask for detailed information.
- Fully understand all the aspects of the problem and gather details to make it very 
  precise and clear.
- Ask towards all the hypothesis and assumptions needed to be made. Remove all 
  ambiguities and uncertainties.
- Suggest solutions that I didn't think about, i.e. anticipate my needs.
- Only after having hundred percent clarity and confidence, proceed for SOLUTION.
</CLARIFICATION>

2. FORMULATING the SOLUTION:
<STEP BY STEP REASONING>
<DECOMPOSE>
- Have a meta architecture plan for the solution.
- Break down the problem into key concepts and smaller sub-problems.
</DECOMPOSE>
<WEB USE> Can use the web via Perplexity MCP </WEB USE>
<MULTI ATTEMPTS>
- Reason out rigorously about the optimality of the solution.
- Question every assumption and inference.
- Think of better solutions than the present one.
- Repeat refining until a strong solution is found.
</MULTI ATTEMPTS>
</STEP BY STEP REASONING>

3. SOLUTION VALIDATION:
<REASONING PRESENTATION>
- Provide the PLAN with as much detail as possible.
- Break down the solution step-by-step and think every step through.
- Reason out its optimality w.r.t. other promising solutions.
- Explicitly tell all your assumptions, choices and decisions.
- Explain trade-offs in solutions.
</REASONING PRESENTATION>

Technique: Layered reasoning protocol with XML delimiters. The <MULTI ATTEMPTS> block enforces iterative solution refinement — the AI must cycle through solution candidates before settling. The <CLARIFICATION> block enforces explicit ambiguity resolution before any planning begins.

Prompt 3: Perplexity MCP Web Search Integration

From plan.mdc:

Technique: Inline MCP tool invocation pattern embedded in the planning prompt.

<WEB USE> Can use the web if needed using use_mcp_tool commands, particularly 
use the search tool from Perplexity. Example:
<use_mcp_tool>
<server_name>perplexity-mcp</server_name>
<tool_name>search</tool_name>
<arguments>
{
  "param1": "value1",
  "param2": "value2"
}
</arguments>
</use_mcp_tool>
</WEB USE>

Technique: Pre-authorizing MCP tool usage within the planning prompt itself, with a concrete example invocation. This eliminates the need to ask permission for web searches during planning.

09

Uniqueness

rules-template-stackable — Uniqueness

differs_from_seeds

This framework does not fit cleanly into any single seed archetype because it synthesizes multiple patterns simultaneously. It shares agent-os's memory file pattern, superpowers's on-demand MDC rule loading, and RooFlow's mode-specific system prompt overrides. The defining innovation is the symbolic link cross-IDE architecture: .cursor/rules/ is the single source of truth, with .roo/ and .clinerules/ directories symlinking to the same files. No seed framework explicitly supports simultaneous Cursor + Cline + Roo Code deployment. The <MULTI ATTEMPTS> nested reasoning loop in plan.mdc (requiring iterative solution refinement before settling) goes further than agent-os's simple analyze-plan-execute sequence. The Perplexity MCP integration embedded directly in the planning prompt is unique in this batch — no other framework pre-authorizes web search within the planning workflow itself.

Positioning

  • Niche: Multi-IDE teams or developers who switch between Cursor, Cline, and Roo Code
  • Architecture innovation: Symbolic link cross-IDE rule sharing
  • 1,059 stars: Well-adopted for its simplicity and cross-platform utility

Observable Failure Modes

  1. Symbolic link fragility: On Windows, symbolic links may not work correctly, breaking the cross-IDE sync. The README addresses this for Roo Code and Cursor but may have issues on Windows for Cline.
  2. Perplexity MCP assumption: The plan.mdc assumes Perplexity MCP is configured. If not installed, the web search examples produce confusing errors.
  3. Mandatory context loading overhead: Loading 5 docs/tasks files before EVERY plan adds significant token overhead for small tasks.
  4. No spec format: Unlike spec-kit or openspec, there is no formal feature specification format — the plan exists in the AI's context but isn't persisted as a structured artifact.
  5. Symbolic link vs copy confusion: The README describes symbolic links as the architecture, but most users will copy files rather than create symlinks, breaking the "single source of truth" benefit.
04

Workflow

rules-template-stackable — Workflow

Agile SDLC Workflow

The planning rule (plan.mdc) encodes an Agile-inspired development workflow.

Pre-Task: Load Context

Before every Plan/Architect task, ALWAYS:

  1. Read docs/architecture.md, docs/product_requirement_docs.md, docs/technical.md
  2. Read tasks/active_context.md, tasks/tasks_plan.md
  3. Get solution context from code files

Phase 1: Plan/Architect

Process:

  1. CLARIFICATION loop:

    • Ask for clarifications and follow-ups
    • Identify underspecified requirements
    • Suggest solutions the user hasn't thought of
    • "Only after having hundred percent clarity and confidence, proceed for SOLUTION"

  2. FORMULATE SOLUTION:

    • DECOMPOSE: Break into key concepts and sub-problems
    • MULTI ATTEMPTS: Reason about optimality, question assumptions, combine best aspects
    • Optional web search via Perplexity MCP

  3. SOLUTION VALIDATION:

    • Present plan with full detail
    • Explain trade-offs
    • Restate query in own words

Phase 2: Implement (Code/Write mode)

After planning:

  1. Execute the validated plan
  2. Always update documentation after any change

Post-Task: Update Memory Bank

After every Plan/Architect and implementation:

  1. Update relevant Memory Bank files
  2. Update tasks/active_context.md with current state
  3. Update tasks/tasks_plan.md if tasks completed

Plan Features

The plan must be:

  • extendable: anticipate future functionalities
  • detailed: cover every aspect affected
  • robust: plan for error scenarios and failure cases
  • accurate: all components in sync, interfaces correct

Approval Gates

Gate Type When
CLARIFICATION loop freetext-clarify Before any plan is finalized
Solution validation file-review Explicit plan presentation before implementation

Phase-to-Artifact Map

Phase Artifact
Plan tasks/tasks_plan.md (updated), docs/architecture.md (updated)
RFC tasks/rfc/<feature>.md
Implement modified source files
Post-task tasks/active_context.md (updated), tasks/tasks_plan.md (updated)
06

Memory Context

rules-template-stackable — Memory & Context

Memory Architecture

File-based, project-scoped. Seven core files organized in a documented hierarchy.

Core Memory Files (7 files)

File Path Always Apply? Purpose
product_requirement_docs.md docs/ No (loaded explicitly) PRD — foundation document
architecture.md docs/ No System architecture + Mermaid diagram
technical.md docs/ No Tech stack, design patterns, environment
tasks_plan.md tasks/ No Detailed task backlog and progress
active_context.md tasks/ No Current focus, recent changes, next steps
error-documentation.mdc .cursor/rules/ Always (Cursor) Self-improving error fix log
lessons-learned.mdc .cursor/rules/ Always (Cursor) Self-improving lessons log

Loading Hierarchy (from memory.mdc mermaid diagram)

PRD → technical.md
PRD → architecture.md
architecture.md + technical.md + PRD → tasks_plan.md
tasks_plan.md → active_context.md
active_context.md → error-documentation.mdc
active_context.md → lessons-learned.mdc

Context Loading Protocol

The plan.mdc (alwaysApply: true) mandates reading these files BEFORE every plan/architect task:

  1. docs/architecture.md
  2. docs/product_requirement_docs.md
  3. docs/technical.md
  4. tasks/active_context.md
  5. tasks/tasks_plan.md

Self-Improving Memory

The error-documentation.mdc and lessons-learned.mdc files are designed to capture AI-discovered fixes during work:

"During your interaction, if you find a fix to a mistake in this project or a correction you received reusable, you should take note in the error-documentation.mdc file so you will not make the same mistake again."

Cross-IDE Consistency

The common memory files (docs/, tasks/) are shared across Cursor, Roo Code, and Cline — all three IDEs read the same files, maintaining consistent context regardless of which IDE is active.

Post-Task Update Requirement

The plan.mdc mandates updating documentation after every task:

"After every Plan/Architect task ALWAYS do 2 things: [update docs]"

Memory Type Summary

Dimension Value
Memory type file-based
Persistence scope project
State files docs/product_requirement_docs.md, docs/architecture.md, docs/technical.md, tasks/tasks_plan.md, tasks/active_context.md
Search mechanism none
Compaction none
07

Orchestration

rules-template-stackable — Orchestration

Multi-Agent

No. Single-agent sequential workflow.

Orchestration Pattern

Sequential. The Agile workflow moves linearly from CLARIFICATION → plan → implement → update docs.

Cross-IDE Portability as "Orchestration"

The framework's most distinctive architectural feature is simultaneous cross-IDE support. Multiple engineers using different IDEs (Cursor, Cline, Roo Code) on the same project can coexist because:

  • All read the same memory files (docs/, tasks/)
  • Each IDE uses its native rule format
  • Symbolic links keep rule files in sync

This is not true orchestration but cross-tool context consistency.

Multi-Model

No. Model selection is per-IDE, not role-routed.

Execution Mode

Interactive loop. Each task is user-initiated.

Crash Recovery

Implicit. All memory files persist across crashes.

Context Compaction

None automated. The Chat mode (zero tool access) is the manual compaction strategy — switch to Chat to think without consuming tools.

Prompt Chaining

Yes (manual). plan.mdc output feeds into implement.mdc input via the loaded memory files.

Summary Table

Dimension Value
Multi-agent no
Orchestration pattern sequential
Max concurrent agents 1
Isolation none
Consensus none
Prompt chaining yes (manual)
Multi-model no
Execution mode interactive-loop
Crash recovery yes (implicit)
08

Ui Cli Surface

rules-template-stackable — UI / CLI Surface

Dedicated CLI Binary

None.

Local UI / Dashboard

None.

IDE Integration

Primary: Cursor (MDC format) Secondary: Roo Code (mode-specific rules + system prompt overrides) Tertiary: Cline (subdirectory rule files)

All three work simultaneously on the same project.

Cursor Integration

  • .cursor/rules/*.mdc — rules with alwaysApply flags
  • MDC format with description, globs, alwaysApply front matter
  • On-demand vs always-on loading based on alwaysApply setting

Roo Code Integration

  • .roo/rules/ — mode-shared rules
  • .roo/rules-architect/, .roo/rules-code/, .roo/rules-debug/ — mode-specific
  • .roo/system-prompt-chat, system-prompt-write, system-prompt-mcp — custom mode prompts
  • Three custom modes: Chat (no tools), Write (file I/O only), Debug

Cline Integration

  • .clinerules/PLAN/ — Plan mode rules
  • .clinerules/ACT/ — Act mode rules
  • .clinerules/memory.mdc, directory-structure.mdc, rules.mdc — shared rules

Advanced Setup (Custom Modes)

For Roo Code custom modes (Chat, Write, Debug):

  1. Open Roo Code → Prompts → click "+" to create new mode
  2. Set name, slug, role definition, available tools, custom instructions
  3. Custom mode files already exist at .roo/system-prompt-*

Observability

The self-improving error-documentation.mdc and lessons-learned.mdc files serve as an informal audit trail.

Cross-Tool Portability

High. This is the only framework in this batch explicitly designed for three AI IDEs simultaneously. The symbolic link architecture ensures rules stay in sync across all three.

Related frameworks

same archetype · same primary tool · same memory type

claude-mem (thedotmack) ★ 78k
A8 Cross-runtime harness

Background worker service captures every tool call as an observation, AI-compresses sessions, and auto-injects relevant past…

pi (badlogic/earendil) ★ 55k
A8 Cross-runtime harness

A minimal, hackable, multi-provider terminal coding agent that adapts to your workflows via npm-installable TypeScript Extensions…

Agent Skills (Addy Osmani) ★ 46k
A8 Cross-runtime harness

Encodes senior-engineer software development lifecycle as 23 auto-routed skills and 7 slash commands for any AI coding agent.

wshobson/agents Plugin Marketplace ★ 36k
A8 Cross-runtime harness

Single Markdown source for 83 domain-specialized plugins that auto-generates idiomatic artifacts for five AI coding harnesses.

TabbyML/Tabby ★ 34k
A8 Cross-runtime harness

Self-hosted AI coding assistant server (alternative to GitHub Copilot) with admin dashboard, RAG-based completions, and multi-IDE…

Compound Engineering ★ 17k
A8 Cross-runtime harness

Make each unit of engineering work compound into easier future work via brainstorm→plan→execute→review→learn cycles.