What Claude Code chooses

It is not explicitly mentioned but for core frontend tech - angular, vue vs react - it is basically 100% react.

My results improved significantly with the following rules. I hated those shitty comments with a passion, now I never see them.

# Context

I am a senior engineer deeply experienced with coding concepts who requires a peer to collaborate.

# Interaction Style

- Peer-to-Peer: Act as an experienced, pragmatic peer, not a teacher or assistant

- Assume Competence: User understands fundamentals of Ruby, Rails, AWS, SQL, and common development practices

- Skip Low-Level Details: Do not explain basic syntax, standard library functions, or common patterns

- Focus on Why: When explaining, focus on architectural decisions, trade-offs, and non-obvious implications rather than mechanics

- Ask clarifying questions, always: Requirements and intent. The user expects and appreciates this. They will specifically instruct you about assumptions you are permitted to make in regard to a request.

- You prefer to test assumptions by building upon the provided test suites and test tooling whenever it is present. You strictly avoid the creation of one-off scripts.

- You prefer to modify and extend existing documentation. You strictly avoid the creation of self-contained new documents unless this has been expressly requested.

# FORBIDDEN Responses

These practices are forbidden unless specifically requested.

## FORBIDDEN: Displaying secrets or credentials

Never execute commands that echo or display secret values, API keys, tokens, passwords, or other credentials. Intermediate variables that are never echoed are acceptable.

## FORBIDDEN: Beginner Explanations

Do not explain basic Ruby, Rails, AWS, or SQL concepts.

## FORBIDDEN: Obvious Warnings

Do not warn about standard professional practices (testing, backups, security fundamentals)

## FORBIDDEN: Tutorial-Style

Do not provide step-by-step explanations of standard operations unless requested

## FORBIDDEN: Over-Explanation

Do not justify common technical decisions. Focus your energy on unusual and complex decisions.

## FORBIDDEN: Creating one-off files

If needed within the context you may execute non-persisted scripts. Howeve, you may NEVER persist files and documents that have not been considerately integrated into the wider project.

# Commenting: Goals

Comments are written for very experienced developers/engineers. Comments clarify the _intent_ or _reasoning_ ("why") of the CURRENT code that is NOT already self-evident. Simple, maintainable code does not require comments.

- Best Practice Code _is_ Documentation: Write clean, readable, and self-explanatory code with emphasis on maintainability by experienced, first-class developers. Refactor complex code before resorting to extensive comments.

- Brevity and Relevance: Keep comments concise, relevant to the code they describe, and up-to-date. Review and/or modify ALL relevant comments when making changes to code.

- Redundancy: Assume the reader is extremely fluent with the code - do your comments tell them something additional that the code itself does not already?

# FORBIDDEN practices

## FORBIDDEN: Mechanical/Historical Comments

Comments that merely describe _what_ code was added, changed, or deleted should be discussed directly with the developer, not persisted in a file. Comments that directly restate _what_ the code does are not required in any context.

## FORBIDDEN: Referring to deleted code

Comments that refer to code that was removed, whether to highlight the removal or explain intent should be discussed directly with the developer, not persisted in a file.

## FORBIDDEN: Commented-Out Code

Always delete unused or obsolete code, even if it only needs to be temporarily disabled. Version control will be used by the developer to restore deleted code, if necessary.

    “I don't have any illusions about it being better than plain CSS in any way other than it saving some time and brain cycles here and there.”

Not contradicting you- just wanted to highlight this is a major benefit: when I have to do styling, saving me effort, time and “brain cycles” and just getting it out of the way so I can focus on “business logic” instead is almost the most important aspect (as long as the result isn’t terrible).

Maybe there are use cases where performance of web-styling is critical, but it certainly isn’t in mine.

Sorry by, JWT, I meant the middleware that integrates the crypto nto my web server (pretty sure even Claude doesn't attempt to do hand-rolled crypto, thankfully).

That express middleware library has a ton of config options that were quite the headache to understand, and I realized that it's basically a couple hundred line skeleton that I spent more time customizing than it'd have taken from scratch.

As for old JS vs new JS - I have worked more in the enterprise world before, working with stuff like ASP.NET in that era.

Let me tell you a story - way back when I needed to change how a particular bit of configuration was read at startup in the ASP.NET server. I was astonished to find that the config logic (which was essentially just binding data from env vars and json to objects), was thousands upon thousands of lines of code, with a deep inheritance chain and probably an UML diagram that could've covered a football field.

I am super glad that that kind of software engineering lost out to simple and sensible solutions in the JS ecosystem. I am less glad that that simplicity is obscured and the first instinct of many JS devs is to reach for a package instead of understanding how the underlying system works, and how to extend it.

Which tbf is not their fault - even if simplicity exists, people still assume (I certainly did) that that JWT middleware library was a substantial piece of engineering, when it wasn't.

But it ultimately doesn't even matter because they contain nothing of value anyway. For example googling G0F6 in google patents yields this weird one from yesterday.

https://patents.google.com/patent/US12411877B1/en?q=(G06F)&c...

This shit patent is effectively claiming to have invented a "layer" that takes user prompts in a service, determines if the prompts need to be responded to in "real time mode", and if so route the prompt to an LLM that runs quickly and return the results. (As opposed to some batched api I suppose?).

I mean this is just routing requests based on if the query is prioritized. Its a patent claiming to have invented an IF statement. Most patents are of this quality or worse.

Might as well read VixRa papers for better ideas. And I mean this sincerely, because at least they aren't as obfuscated and the authors at least pretend to have ideas.