Quick lookup into working rules. Use when user says "/aria-cowork:rules", "/aria-cowork:rules 22", "/aria-cowork:rules dependencies", "look up rule about...", "what rule covers...", or references a specific rule number. (Cowork variant — namespaced-only.)
Scanned 9/5/2026
Install to Claude Code
npx -y skills add mikeprasad/aria-knowledge --skill rules --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Rules?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/mikeprasad-rules-2c4a42ff)More formats (shields.io, HTML) on the badges page.
---
name: rules
description: 'Quick lookup into working rules. Use when user says "/aria-cowork:rules", "/aria-cowork:rules 22", "/aria-cowork:rules dependencies", "look up rule about...", "what rule covers...", or references a specific rule number. (Cowork variant — namespaced-only.)'
argument-hint: '[number or keyword]'
---
# /rules — Quick Rule Lookup
Look up rules from both the plugin's `working-rules.md` and the user's optional `user-rules.md`.
## Runtime Gate (per ADR-094)
**Canonical resolution:** This is the Claude Cowork variant — namespaced-only. When both `plugin-claude-code` and `plugin-claude-cowork` are loaded in the same session (most common in Claude Desktop), bare `/rules` resolves to aria-knowledge's variant — Code is the canonical owner of all 24 dual-port skills per ADR-094 §Part 1. To reach this skill, use the namespaced form: `/aria-cowork:rules`. Do NOT match bare `/rules` — that belongs to aria-knowledge.
**Before Step 0 — runtime self-correction.** Check whether the `Bash` tool is available in this session. If `Bash` IS available (you are running in Claude Code or another runtime with shell access), this invocation reached the wrong variant for the runtime. **Do not ask — redirect.** Announce it in one line, then use the `Skill` tool to invoke `rules` with the same arguments the user provided, and do not run this skill's steps:
> ↪️ **Redirecting to `/rules` — you invoked the aria-cowork variant, but you are running in Claude Code or another runtime with shell access.**
>
> Behavior is largely the same in both runtimes; for the Code-native variant, use `/rules` (the aria-knowledge canonical).
⛔ **The redirect is unconditional** — every mode including `auto`, and no opt-out. Reaching this variant under that condition is always a mis-invocation, so there is nothing for the user to decide. Design record: `docs/superpowers/specs/2026-08-28-runtime-gate-auto-redirect-design.md` (D2 auto-redirect, D3 no escape hatch, D6 announce-don't-swap-silently).
If `Bash` is NOT available (normal Cowork runtime), proceed to Step 0.
## Step 0: Resolve config
The default knowledge folder is `~/Projects/knowledge/` (expand `~` to your home directory's absolute path). Read `<knowledge_folder>/aria-config.md` and extract `knowledge_folder`. If `aria-config.md` doesn't exist, stop: *"aria-cowork is not configured. Run `/aria-setup` to get started."*
Set two rules file paths (using `<knowledge_folder>` since file reads happen during this Cowork session):
- **Plugin rules:** `<knowledge_folder>/rules/working-rules.md`
- **User rules:** `<knowledge_folder>/rules/user-rules.md` (optional — may not exist if the user hasn't added custom rules)
If the plugin rules file doesn't exist, stop: *"No `working-rules.md` found in your knowledge folder. Run `/aria-setup` to repair the structure."*
If the user rules file doesn't exist, proceed with plugin rules only — this is the normal state for users who haven't added any custom rules.
**Note for Phase 1:** Rule 22 (change-decision framework) and Rule 23 (file-edit discipline) reference Code-side mechanics (Edit/Write tool gating) that don't apply in Cowork. They surface as-is in v0.1.0; Phase 2+ adds a `cowork_relevant: true|false` flag in rule frontmatter for filtering. See [ADR-004](../../../knowledge/projects/aria-cowork/decisions/004-hook-replacement-strategy.md) for the design.
## Step 1: Parse argument
Check what argument was provided:
- **No argument:** go to Step 2 (index mode).
- **Number with optional U prefix** (e.g., `22`, `U1`): go to Step 3 (lookup by identifier).
- **Keyword** (e.g., `dependencies`): go to Step 4 (search mode).
## Step 2: Index mode
Read both files. Extract all rule headings (lines matching `### N. [title]` or `### UN. [title]`). Output a grouped list:
```
## Working Rules Index
### Plugin Rules (working-rules.md)
1. Scope tasks tightly, but keep the whole system in view
2. Let errors guide where you add context
...
### Your Rules (user-rules.md)
U1. Always run the linter locally before committing
U2. Test data lives in test/fixtures/, not scattered next to tests
...
```
If `user-rules.md` doesn't exist, omit the "Your Rules" section entirely. If `user-rules.md` exists but contains no `### U` rules, note: *"(Your Rules file exists but has no rules yet.)"*
## Step 3: Lookup by identifier
Read both files (plugin rules always, user rules if present). Find the heading matching the requested identifier:
- **Plain number** (e.g., `22`) → search both files for `### 22.` AND `### U22.`
- **U-prefixed** (e.g., `U1`) → search `user-rules.md` for `### U1.`
For each match, extract the full rule text (heading through next heading or section end) and present it with a clear source label:
```
## Plugin Rule 22 — Follow the change decision framework
[full rule text]
```
or
```
## User Rule U1 — Always run the linter locally before committing
[full rule text]
```
**Collision handling:** If the same plain number matches in both files (e.g., user's `### 30.` collides with plugin's `### 30.`), present BOTH and warn:
> *"Number collision: Rule 30 exists in both `working-rules.md` and `user-rules.md`. Consider renaming the user version with a `U` prefix to avoid this — see `user-rules.md` naming convention."*
If no match in either file: *"Rule [identifier] not found. Plugin has rules 1-[max plugin]; `user-rules.md` has [list of user rule identifiers, or 'no custom rules' if file missing/empty]. Run `/aria-cowork:rules` to see the full index."*
**Examples lookup (since v0.3.0 — parity with aria-knowledge v2.14.2+):** After returning the rule body, also check for a user-authored example in `<knowledge_folder>/rules/user-examples.md`.
If `user-examples.md` exists, search for a heading matching `## Rule N` (where N is the requested plain-number identifier — examples currently target plugin rules only, not user rules). If found, extract the example body (heading through next `## Rule` heading or end of file) and append it to the output as a separate section:
```
## Plugin Rule 25 — Check secondary impact on every change
[full rule text]
---
## Example (from your user-examples.md)
## Rule 25 — Check secondary impact
[example body — Before / After / etc.]
```
If `user-examples.md` doesn't exist, or exists but has no matching `## Rule N` heading, omit the example section silently. This is the normal state for users who haven't authored examples for that rule yet.
Multiple examples for the same rule (e.g., two `## Rule 25` headings) are all returned in document order, separated by `---`.
## Step 4: Search mode
Read both files. Search rule titles and bodies for the keyword. Return all matching rules with their full text, grouped by source:
```
## Search results for '[keyword]'
### Plugin Rules
[matching rules from working-rules.md]
### Your Rules
[matching rules from user-rules.md]
```
If no matches in either: *"No rules match '[keyword]'. Run `/aria-cowork:rules` to see the full index."*
If matches in only one file, omit the empty section heading.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!