`rules render claude` doesn't work

[johnlindquist]

Steps:

➜  testing-rules-cli rules add starter/nextjs-rules
Creating new rules.json file with default structure
Downloading rule 'starter/nextjs-rules' (version latest) from registry API...
Rule 'starter/nextjs-rules' (version 0.0.1) added successfully
➜  testing-rules-cli render render claude
zsh: command not found: render
➜  testing-rules-cli rules render claude
Rendering rules to claude format...
Successfully rendered rules to claude format
➜  testing-rules-cli 

Output:

A CLAUDE.md file with the content:

# Rules

• Other formats seem to work fine.
• This rules renders "fine": rules add gh:continuedev/rules-template

I'm assuming it's something with the formatting of the nextjs-rules?

[bdougie]

Hey @johnlindquist good to see you and thanks for trying the cli. I was able to reproduce and can look into this closer.

[sestinj]

There's a behavior that we decided on (which is described in the spec here: https://github.com/continuedev/rules/blob/main/spec/render-formats.md) where only rules that are marked with alwaysApply: true make it into the CLAUDE.md file. The reason we went with this was that everything in CLAUDE.md will always be applied.

That said, I can see how this appears very unexpected. Perhaps we just put all rules into CLAUDE.md?

[Patrick-Erichsen]

Relevant spec:

However, for formats that support only a single file (like AGENT.md), we concatenate all rules that have alwaysApply: true into a single file at the root of the repository, and ignore all other rules.

I think I'd +1 modifying the behavior to just include all rules regardless of the alwaysApply clause.

The user is taking an explicit action to request that a given rule(s) be included in their codebase. We can make our best effort to map schemas, but erring on the side of inclusion rather than exclusion seems intuitive.

Perhaps we include a flag to override this default behavior though, eg --strict, which could skip outputs altogether that don't adhere to the schema.

[bdougie]

That said, I can see how this appears very unexpected. Perhaps we just put all rules into CLAUDE.md?

I see a few options to improve the initial experience:

Option 1: Move everything to CLAUDE.md
This would make all rules visible by default, which aligns better with user expectations.

Option 2: Keep current approach but improve discoverability
My original thinking was that users would want alwaysApply: true as a starting point to test effectiveness, then adjust as needed. However, you're right that having rules apply invisibly creates a poor first impression.

Option 3: Commented rules with clear instructions
Add the rule as a comment with instructions to uncomment when ready to apply. This gives visibility while requiring explicit opt-in.

The core issue is that users expect to see something happening, especially initially. Even if the rule is helpful, the surprise of seeing nothing undermines trust for using the tool.

What do you think about moving toward Option 1 for better transparency?

[johnlindquist]

Just print out a message like:

"These rules were not rendered to CLAUDE.md because they don't have alwaysApply. To use them with claude, please reference them by their path in the .rules folder"

[johnlindquist]

Might be neat to have rules render --rules-tree claude where CLAUDE.md includes a tree view of the current .rules dir.

## Rules Tree
.rules/foo/bar
-- react.md

## Main Section