3 ms·

So the correct strategy is a global CLAUDE.md with couple lines of colourful "you best behave or else" texts, so all your prompts get routed via the frustrated

So the correct strategy is a global CLAUDE.md with couple lines of colourful "you best behave or else" texts, so all your prompts get routed via the frustrated path?

knollimar 4mo ago
I find it routes more quickly for patches when in the frustrated path, so after planning sure :)
cyanydeez 4mo ago
there already is a global claude using any cloud model is a high probability that theyre context stuffing trying to curate output for the normative use cases. see "dont talk about goblins"
eithed 4mo ago
That will not work - you end up with Claude being ADHD and not following any guidelines. Skills do work, as they ground the agent with constrained context for the task it's performing
- notnaut 4mo ago
  Can you explain how you’d use skills to address the situation that anonzzzies was describing…?
  - eithed 4mo ago
    I have a skill for exactly such case! Here's an excerpt :) ``` --- name: evidence-debugging description: > Use when debugging any failing test or bug, investigating unexpected behavior, or tracing the cause of a reported defect. --- # Debugging Discipline ## When to Use - A test is failing and you need to understand why - Behavior is unexpected and the cause is unknown - The user asks you to debug or investigate a defect - You need to verify what a value actually is at runtime *When NOT to use:* proactive code exploration without a specific failure to investigate. ## STOP — Do This Before Anything Else Before reading code, before forming a hypothesis, before typing anything — answer these: 1. *Do I have actual output from a running system?* - No → instrument, run, save to file, read. Do not proceed until you have real output. - Yes → read it. Do not re-run. 2. *Am I about to explain what the issue "probably is" or "must be"?* - Yes → stop. That is deduction without evidence. It is a violation. Instrument instead. 3. *Am I about to touch passing code?* - Yes → stop. Only instrument the failing scope. If you find yourself already reasoning about likely causes — you are already violating Rule 1. Stop. Go back to step 1. ```
    - notnaut 4mo ago
      Thanks a lot! This is really helpful!
      - eithed 4mo ago
        No worries! Here's the full prompt if you need it: https://sharetext.io/g6ibuxa5 https://sharetext.io/g6ibuxa5 (you'll probably need to update it, as there're specific things I wanted it to take into account) Ultimately my point is to define small contexts grounding agents in tasks you expect them to do. Trying to define guidelines for everything will not work = telling it that it shouldn't delete prod AND that it's architect AND that it should review code using this and this principle AND milliard other things that you expect from yourself.

So the correct strategy is a global CLAUDE.md with couple lines of colourful "you best behave or else" texts, so all your prompts get routed via the frustrated path?

knollimar 4mo ago

I find it routes more quickly for patches when in the frustrated path, so after planning sure :)

cyanydeez 4mo ago

there already is a global claude using any cloud model is a high probability that theyre context stuffing trying to curate output for the normative use cases. see "dont talk about goblins"

eithed 4mo ago

That will not work - you end up with Claude being ADHD and not following any guidelines. Skills do work, as they ground the agent with constrained context for the task it's performing

notnaut 4mo ago
Can you explain how you’d use skills to address the situation that anonzzzies was describing…?
- eithed 4mo ago
  I have a skill for exactly such case! Here's an excerpt :) ``` --- name: evidence-debugging description: > Use when debugging any failing test or bug, investigating unexpected behavior, or tracing the cause of a reported defect. --- # Debugging Discipline ## When to Use - A test is failing and you need to understand why - Behavior is unexpected and the cause is unknown - The user asks you to debug or investigate a defect - You need to verify what a value actually is at runtime *When NOT to use:* proactive code exploration without a specific failure to investigate. ## STOP — Do This Before Anything Else Before reading code, before forming a hypothesis, before typing anything — answer these: 1. *Do I have actual output from a running system?* - No → instrument, run, save to file, read. Do not proceed until you have real output. - Yes → read it. Do not re-run. 2. *Am I about to explain what the issue "probably is" or "must be"?* - Yes → stop. That is deduction without evidence. It is a violation. Instrument instead. 3. *Am I about to touch passing code?* - Yes → stop. Only instrument the failing scope. If you find yourself already reasoning about likely causes — you are already violating Rule 1. Stop. Go back to step 1. ```
  - notnaut 4mo ago
    Thanks a lot! This is really helpful!
    - eithed 4mo ago
      No worries! Here's the full prompt if you need it: https://sharetext.io/g6ibuxa5 https://sharetext.io/g6ibuxa5 (you'll probably need to update it, as there're specific things I wanted it to take into account) Ultimately my point is to define small contexts grounding agents in tasks you expect them to do. Trying to define guidelines for everything will not work = telling it that it shouldn't delete prod AND that it's architect AND that it should review code using this and this principle AND milliard other things that you expect from yourself.