caruso 0.6.2 → 0.7.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,246 @@
1
+ # Rules
2
+
3
+ Rules provide system-level instructions to Agent. They bundle prompts, scripts, and more together, making it easy to manage and share workflows across your team.
4
+
5
+ Cursor supports four types of rules:
6
+
7
+ - [Project Rules](): Stored in .cursor/rules, version-controlled and scoped to your codebase.
8
+ - [User Rules](): Global to your Cursor environment. Used by Agent (Chat).
9
+ - [Team Rules](): Team-wide rules managed from the dashboard. Available on Team and Enterprise plans.
10
+ - [AGENTS.md](): Agent instructions in markdown format. Simple alternative to
11
+ .cursor/rules.
12
+
13
+ ## How rules work
14
+
15
+ Large language models don't retain memory between completions. Rules provide persistent, reusable context at the prompt level.
16
+
17
+ When applied, rule contents are included at the start of the model context. This gives the AI consistent guidance for generating code, interpreting edits, or helping with workflows.
18
+
19
+ ## Project rules
20
+
21
+ Project rules live in `.cursor/rules`. Each rule is a folder containing a `RULE.md` file and is version-controlled. They are scoped using path patterns, invoked manually, or included based on relevance.
22
+
23
+ Use project rules to:
24
+
25
+ - Encode domain-specific knowledge about your codebase
26
+ - Automate project-specific workflows or templates
27
+ - Standardize style or architecture decisions
28
+
29
+ ### Rule folder structure
30
+
31
+ Each rule folder can contain:
32
+
33
+ - **`RULE.md`** — The main rule file with frontmatter metadata and instructions
34
+ - **Scripts and prompts** — Additional files referenced by the rule
35
+
36
+ ```
37
+ .cursor/rules/
38
+ my-rule/
39
+ RULE.md # Main rule file
40
+ scripts/ # Helper scripts (optional)
41
+ ```
42
+
43
+ ### Rule anatomy
44
+
45
+ Each rule is a folder containing a `RULE.md` file with frontmatter metadata and content. Control how rules are applied from the type dropdown which changes properties `description`, `globs`, `alwaysApply`.
46
+
47
+ Rule TypeDescription`Always Apply`Apply to every chat session`Apply Intelligently`When Agent decides it's relevant based on description`Apply to Specific Files`When file matches a specified pattern`Apply Manually`When @-mentioned in chat (e.g., `@my-rule`)
48
+ ```
49
+ ---
50
+ globs:
51
+ alwaysApply: false
52
+ ---
53
+
54
+ - Use our internal RPC pattern when defining services
55
+ - Always use snake_case for service names.
56
+
57
+ @service-template.ts
58
+ ```
59
+
60
+ ### Creating a rule
61
+
62
+ Create rules using the `New Cursor Rule` command or going to `Cursor Settings > Rules, Commands`. This creates a new rule folder in `.cursor/rules`. From settings you can see all rules and their status.
63
+
64
+ ## Best practices
65
+
66
+ Good rules are focused, actionable, and scoped.
67
+
68
+ - Keep rules under 500 lines
69
+ - Split large rules into multiple, composable rules
70
+ - Provide concrete examples or referenced files
71
+ - Avoid vague guidance. Write rules like clear internal docs
72
+ - Reuse rules when repeating prompts in chat
73
+
74
+ ## RULE.md file format
75
+
76
+ The `RULE.md` file is a markdown file with frontmatter metadata and content. The frontmatter metadata is used to control how the rule is applied. The content is the rule itself.
77
+
78
+ ```
79
+ ---
80
+ description: "This rule provides standards for frontend components and API validation"
81
+ alwaysApply: false
82
+ ---
83
+
84
+ ...rest of the rule content
85
+ ```
86
+
87
+ If alwaysApply is true, the rule will be applied to every chat session. Otherwise, the description of the rule will be presented to the Cursor Agent to decide if it should be applied.
88
+
89
+ ## Examples
90
+
91
+ ### Standards for frontend components and API validation
92
+
93
+ ### Templates for Express services and React components
94
+
95
+ ### Automating development workflows and documentation generation
96
+
97
+ ### Adding a new setting in Cursor
98
+
99
+ First create a property to toggle in `@reactiveStorageTypes.ts`.
100
+
101
+ Add default value in `INIT_APPLICATION_USER_PERSISTENT_STORAGE` in `@reactiveStorageService.tsx`.
102
+
103
+ For beta features, add toggle in `@settingsBetaTab.tsx`, otherwise add in `@settingsGeneralTab.tsx`. Toggles can be added as `<SettingsSubSection>` for general checkboxes. Look at the rest of the file for examples.
104
+
105
+ ```
106
+ <SettingsSubSection label="Your feature name" description="Your feature description" value={ vsContext.reactiveStorageService.applicationUserPersistentStorage .myNewProperty ?? false } onChange={(newVal) => { vsContext.reactiveStorageService.setApplicationUserPersistentStorage( "myNewProperty", newVal, ); }}/>
107
+ ```
108
+
109
+ To use in the app, import reactiveStorageService and use the property:
110
+
111
+ ```
112
+ const flagIsEnabled = vsContext.reactiveStorageService.applicationUserPersistentStorage .myNewProperty;
113
+ ```
114
+
115
+ Examples are available from providers and frameworks. Community-contributed rules are found across crowdsourced collections and repositories online.
116
+
117
+ ## Team Rules
118
+
119
+ Team and [Enterprise](/docs/enterprise) plans can create and enforce rules across their entire organization from the [Cursor dashboard](https://cursor.com/dashboard?tab=team-content). Admins can configure whether or not each rule is required for team members.
120
+
121
+ Team Rules work alongside other rule types and take precedence to ensure organizational standards are maintained across all projects. They provide a powerful way to ensure consistent coding standards, practices, and workflows across your entire team without requiring individual setup or configuration.
122
+
123
+ ### Managing Team Rules
124
+
125
+ Team administrators can create and manage rules directly from the Cursor dashboard:
126
+
127
+ Once team rules are created, they automatically apply to all team members and are visible in the dashboard:
128
+
129
+ ### Activation and enforcement
130
+
131
+ - **Enable this rule immediately**: When checked, the rule is active as soon as you create it. When unchecked, the rule is saved as a draft and does not apply until you enable it later.
132
+ - **Enforce this rule**: When enabled, the rule is required for all team members and cannot be disabled in their Cursor settings. When not enforced, team members can toggle the rule off in `Cursor Settings → Rules` under the Team Rules section.
133
+
134
+ By default, non‑enforced Team Rules can be disabled by users. Use **Enforce this rule** to prevent that.
135
+
136
+ ### Format and how Team Rules are applied
137
+
138
+ - **Plain text**: Team Rules are free‑form text. They do not use the folder structure of Project Rules and do not support metadata such as `globs`, `alwaysApply`, or rule types.
139
+ - **Where they apply**: When a Team Rule is enabled (and not disabled by the user, unless enforced), it is included in the model context for Agent (Chat) across all repositories and projects for that team.
140
+ - **Precedence**: Rules are applied in this order: **Team Rules → Project Rules → User Rules**. All applicable rules are merged; earlier sources take precedence when guidance conflicts.
141
+
142
+ Some teams use enforced rules as part of internal compliance workflows. While this is supported, AI guidance should not be your only security control.
143
+
144
+ ## Importing Rules
145
+
146
+ You can import rules from external sources to reuse existing configurations or bring in rules from other tools.
147
+
148
+ ### Remote rules (via GitHub)
149
+
150
+ Import rules directly from any GitHub repository you have access to—public or private.
151
+
152
+ 1. Open **Cursor Settings → Rules, Commands**
153
+ 2. Click `+ Add Rule` next to `Project Rules`, then select Remote Rule (Github)
154
+ 3. Paste the GitHub repository URL containing the rule
155
+ 4. Cursor will pull and sync the rule into your project
156
+
157
+ Imported rules stay synced with their source repository, so updates to the remote rule are automatically reflected in your project.
158
+
159
+ ### Agent Skills
160
+
161
+ Cursor can load rules from [Agent Skills](/docs/context/skills), an open standard for extending AI agents with specialized capabilities. These imported skills are always applied as agent-decided rules, meaning Cursor determines when they are relevant based on context.
162
+
163
+ To enable or disable Agent Skills:
164
+
165
+ 1. Open **Cursor Settings → Rules**
166
+ 2. Find the **Import Settings** section
167
+ 3. Toggle **Agent Skills** on or off
168
+
169
+ Agent Skills are treated as agent-decided rules and cannot be configured as always-apply or manual rules.
170
+
171
+ ## AGENTS.md
172
+
173
+ `AGENTS.md` is a simple markdown file for defining agent instructions. Place it in your project root as an alternative to `.cursor/rules` for straightforward use cases.
174
+
175
+ Unlike Project Rules, `AGENTS.md` is a plain markdown file without metadata or complex configurations. It's perfect for projects that need simple, readable instructions without the overhead of structured rules.
176
+
177
+ Cursor supports AGENTS.md in the project root and subdirectories.
178
+
179
+ ```
180
+ # Project Instructions
181
+
182
+ ## Code Style
183
+
184
+ - Use TypeScript for all new files
185
+ - Prefer functional components in React
186
+ - Use snake_case for database columns
187
+
188
+ ## Architecture
189
+
190
+ - Follow the repository pattern
191
+ - Keep business logic in service layers
192
+ ```
193
+
194
+ ### Improvements
195
+
196
+ ### Nested AGENTS.md support
197
+
198
+ Nested `AGENTS.md` support in subdirectories is now available. You can place `AGENTS.md` files in any subdirectory of your project, and they will be automatically applied when working with files in that directory or its children.
199
+
200
+ This allows for more granular control of agent instructions based on the area of your codebase you're working in:
201
+
202
+ ```
203
+ project/
204
+ AGENTS.md # Global instructions
205
+ frontend/
206
+ AGENTS.md # Frontend-specific instructions
207
+ components/
208
+ AGENTS.md # Component-specific instructions
209
+ backend/
210
+ AGENTS.md # Backend-specific instructions
211
+ ```
212
+
213
+ Instructions from nested `AGENTS.md` files are combined with parent directories, with more specific instructions taking precedence.
214
+
215
+ ## User Rules
216
+
217
+ User Rules are global preferences defined in **Cursor Settings → Rules** that apply across all projects. They are used by Agent (Chat) and are perfect for setting preferred communication style or coding conventions:
218
+
219
+ ```
220
+ Please reply in a concise style. Avoid unnecessary repetition or filler language.
221
+ ```
222
+
223
+ ## Legacy Cursor Rules
224
+
225
+ ### .cursorrules
226
+
227
+ The `.cursorrules` (legacy) file in your project root is still supported but **will be deprecated**. We recommend migrating to Project Rules or to `AGENTS.md`.
228
+
229
+ ### .mdc cursor rules
230
+
231
+ As of 2.2, `.mdc` cursor rules will remain functional however all new rules will now be created as folders in `.cursor/rules`. This is to improve the readability and maintainability of rules.
232
+
233
+ ## FAQ
234
+
235
+ ### Why isn't my rule being applied?
236
+
237
+ ### Can rules reference other rules or files?
238
+
239
+ ### Can I create a rule from chat?
240
+
241
+ ### Do rules impact Cursor Tab or other AI features?
242
+
243
+ ### Do User Rules apply to Inline Edit (Cmd/Ctrl+K)?
244
+
245
+ No. User Rules are not applied to Inline Edit (Cmd/Ctrl+K). They are only
246
+ used by Agent (Chat).
@@ -0,0 +1,57 @@
1
+ # Steering Docs
2
+
3
+ **Steering docs** are files and configurations that direct an AI agent's behavior, capabilities, and workflows. They act as the "operating system" for the agent, defining what it can do, how it should act, and what rules it must follow.
4
+
5
+ ## Claude Code Supported Types
6
+
7
+ Claude Code uses a plugin-based architecture where steering docs are organized into specific directories within a plugin or project structure.
8
+
9
+ 1. **Commands** (`commands/*.md`)
10
+ * **Definition:** Custom slash commands (e.g., `/deploy`) invoked by the user.
11
+ * **Format:** Markdown files with frontmatter describing the command's intent and logic.
12
+
13
+ 2. **Agents** (`agents/*.md`)
14
+ * **Definition:** Specialized sub-personas (e.g., "Security Reviewer") that Claude can invoke automatically or users can call manually.
15
+ * **Format:** Markdown files defining the agent's capabilities and prompt instructions.
16
+
17
+ 3. **Skills** (`skills/*/SKILL.md`)
18
+ * **Definition:** Discrete capabilities (e.g., "PDF Reader", "API Client") that Claude figures out how to use autonomously.
19
+ * **Format:** Directories containing a `SKILL.md` file and optional supporting scripts.
20
+
21
+ 4. **Hooks** (`hooks/hooks.json`)
22
+ * **Definition:** Event handlers that trigger scripts based on system lifecycle events (e.g., `PostToolUse`, `SessionStart`).
23
+ * **Format:** JSON configuration mapping events to scripts.
24
+
25
+ 5. **MCP Servers** (`.mcp.json`)
26
+ * **Definition:** Connections to external tools, databases, and APIs via the Model Context Protocol.
27
+ * **Format:** JSON file configuring local servers (environment variables, command arguments).
28
+
29
+ ## Cursor Supported Types
30
+
31
+ Cursor uses a file-based configuration system, typically stored in a `.cursor/` directory at the project root.
32
+
33
+ 1. **Rules** (`.cursor/rules/*.md`)
34
+ * **Definition:** Persistent, context-aware instructions injected into the agent's prompt.
35
+ * **Application:** Can be applied always (`alwaysApply: true`), intelligently based on description, to specific files (globs), or manually via `@mention`.
36
+
37
+ 2. **Commands** (`.cursor/commands/*.md`)
38
+ * **Definition:** User-triggered workflows (e.g., `/onboard`) defined as standardized prompts.
39
+ * **Role:** Replaces the deprecated "Custom Modes" feature.
40
+
41
+ 3. **Hooks** (`.cursor/hooks.json`)
42
+ * **Definition:** Scripts that run before or after agent/IDE actions (e.g., `beforeShellExecution`, `afterFileEdit`).
43
+ * **Scope:** Supports distinct events for both the Agent (Cmd+K) and Tab (inline autocomplete).
44
+
45
+ 4. **Modes** (Built-in)
46
+ * **Definition:** High-level operational states: **Agent** (coding), **Ask** (read-only), **Plan** (architecture), and **Debug** (diagnosis).
47
+ * **Note:** Custom modes are deprecated in favor of Commands.
48
+
49
+ ## Feature Mapping: Claude Code vs. Cursor
50
+
51
+ | Claude Code Type | Cursor Equivalent | Justification | Caveats | Caruso Implementation |
52
+ | :--- | :--- | :--- | :--- | :--- |
53
+ | **Commands** | **Commands** | Both are user-triggered workflows invoked via `/` (e.g., `/test`). | Cursor Commands are simple markdown prompts; Claude Code Commands can be more complex plugins with executable code. | **Simplification:** Strip executable logic where possible, or convert complex commands into a Rule + Script combo if execution is required. |
54
+ | **Agents** | **Rules** (partial) | Cursor Rules can define persona/behavior, which is similar to an Agent identity. | Cursor "Rules" are context injections, not autonomous loops. Claude Agents are distinct sub-personas that can have their own loops and tools. | **Sync Persona:** Extract agent prompt/identity into `.cursor/rules/agent_[name].mdc`. **Sub-agents:** Use [Cursor CLI](https://cursor.com/cli) to spawn independent agent sessions. |
55
+ | **Skills** | **Rules** | Both are "model-invoked" capabilities. Cursor's "Apply Intelligently" mirrors Claude's autonomous skill selection. | **Pros:** Markdown-based, semantic alignment (teaching the agent). **Cons:** Cursor Rules are text context; they don't natively "bundle" executable scripts like a Plugin/Skill structure might. | **Script Bundling:** Fetch `scripts/` from the Skill directory, make them executable, and rewrite the Rule to reference these local scripts. |
56
+ | **Hooks** | **Hooks** | Both intercept lifecycle events to run scripts (e.g., pre-command, post-edit). | Event names differ (e.g., `PostToolUse` vs `afterShellExecution`). Cursor distinguishes between "Main Agent" and "Tab" events. | **Event Translation:** Parse Claude's `hooks.json`, map events (e.g., `PostToolUse` -> `afterFileEdit`), and generate a valid `.cursor/hooks.json`. |
57
+ | **MCP Servers** | **MCP Servers** | Direct 1:1 mapping. Both use the Model Context Protocol to connect to external tools. | Configuration syntax might differ slightly (e.g., `.mcp.json` vs Cursor settings), but the protocol is identical. | **Config Adapter:** specific MCP config from `.mcp.json` could be converted to a Cursor-compatible configuration or appended to a global MCP config file. |
data/tasks.md ADDED
@@ -0,0 +1,22 @@
1
+ # Implementation Tasks: Skill Support Refactor
2
+
3
+ ## Phase 1: Foundation (Refactor)
4
+ - [x] Create `lib/caruso/adapters/base.rb` (Base class for shared logic)
5
+ - [x] Create `lib/caruso/adapters/dispatcher.rb` (Dispatcher to select adapter based on type)
6
+ - [x] Refactor `lib/caruso/adapter.rb` to use the Dispatcher
7
+ - [x] Update `lib/caruso/cli.rb` to use the new Adapter architecture (Implicit)
8
+
9
+ ## Phase 2: Skills Support
10
+ - [x] Update `lib/caruso/fetcher.rb` to support `skills/` directory recursion
11
+ - [x] Implement `check_resource_types` in Fetcher (Logic integrated in `find_steering_files`)
12
+ - [x] Create `lib/caruso/adapters/skill_adapter.rb`
13
+ - [x] Implement script copying to `.cursor/scripts/caruso/...`
14
+ - [x] Implement rule generation (`SKILL.md` -> `.cursor/rules/...`)
15
+ - [x] Add header/frontmatter to rule pointing to script location
16
+ - [x] Create unit tests for `SkillAdapter` & `Fetcher`
17
+ - [x] Verify implementation with tests
18
+ - [x] Refactor `Dispatcher` logic for robust skill clustering <!-- id: 11 -->
19
+ - [x] Refactor `SkillAdapter` to preserve script directory structure <!-- id: 12 -->
20
+
21
+
22
+
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: caruso
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.6.2
4
+ version: 0.7.0
5
5
  platform: ruby
6
6
  authors:
7
7
  - Philipp Comans
@@ -143,8 +143,15 @@ files:
143
143
  - bin/caruso
144
144
  - caruso.gemspec
145
145
  - caruso.json
146
+ - impl.md
146
147
  - lib/caruso.rb
147
148
  - lib/caruso/adapter.rb
149
+ - lib/caruso/adapters/base.rb
150
+ - lib/caruso/adapters/command_adapter.rb
151
+ - lib/caruso/adapters/dispatcher.rb
152
+ - lib/caruso/adapters/hook_adapter.rb
153
+ - lib/caruso/adapters/markdown_adapter.rb
154
+ - lib/caruso/adapters/skill_adapter.rb
148
155
  - lib/caruso/cli.rb
149
156
  - lib/caruso/config_manager.rb
150
157
  - lib/caruso/fetcher.rb
@@ -154,9 +161,19 @@ files:
154
161
  - lib/caruso/safe_dir.rb
155
162
  - lib/caruso/safe_file.rb
156
163
  - lib/caruso/version.rb
157
- - reference/marketplace.md
164
+ - package-lock.json
165
+ - reference/claude_code_create_marketplaces.md
166
+ - reference/claude_code_hooks.md
167
+ - reference/claude_code_marketplaces.md
168
+ - reference/claude_code_plugins.md
169
+ - reference/claude_code_slash_commands.md
170
+ - reference/cursor_commands.md
171
+ - reference/cursor_hooks.md
172
+ - reference/cursor_modes.md
173
+ - reference/cursor_rules.md
158
174
  - reference/plugins.md
159
- - reference/plugins_reference.md
175
+ - reference/steering_docs.md
176
+ - tasks.md
160
177
  homepage: https://github.com/pcomans/caruso
161
178
  licenses:
162
179
  - MIT