We have a large monolith in fintech to re-work and recently started using xerj as AST and semantic search for Claude code instead of grep/sed waste. After a month we estimated that we saved tokens a few times over for the same refactoring work and visually much “better” (means more like our previous coding style) code.

Recently xerj.org changed their llms.txt promoting reference coding and our harness clones dozens of relevant OSS repos from GitHub using them as a coding corpus for references coding. But the question how is it legal? From one hand OSS licenses allows to reused their code and most likely all of these were in Anthropic datasets anyways.

Anyone have a clear answer?

I’ve had this annoying pinch point for a while.
Claude Code, Codex, and similar agent tools can write their own SKILL.md files when they hit something they don’t already know how to do.
Useful as fuck at first.
Then a few weeks/months later you’ve got duplicates, stale skills nobody uses, broken references, and if you’re using both Claude Code + Codex, two versions of basically the same skill slowly drifting apart.
So I built a small free CLI to clean that shit up.

scan — finds stale skills + near duplicates
verify — catches broken references, placeholder text and weak frontmatter
crosscheck — compares skill folders across tools and shows what’s missing or drifted
exec-verify — experimental, actually throws a skill into a fresh agent session to see if it can still do what it claims

No LLM calls, no network calls, no dependencies. Just Python stdlib.

It also auto-detects the usual Claude/Codex/Cursor skill folders, link for anyone interested:
github.com/OfficialUlix/skill-curator-cli

Free, MIT licensed.
Curious if anyone else running Claude Code + Codex together ends up with the same mess, or if I’ve somehow manufactured this problem for myself 😂

When I upload a sample document that happens to be university coursework to the new ai watermark skill, Claude refuses to run the transformation and gives an “academic integrity” explanation. I also tried clarifying that I'm testing the tool rather than submitting the output, but it still refuses.

I don't understand what is actually triggering the refusal.

Has anyone else encountered this? Is Claude detecting the document as academic work based on its contents, or is the refusal being triggered by the instructions/tool itself?

I'm particularly interested in whether this is a hardcoded safety restriction or just a false positive from the model's safety layer.

I just started an ABSN program and what I want to do is use Claude to create a prompt/skill to use for every course. Mind you, I've never used Claude but I want to, to work smarter not harder and get more studying done. My school actually allows us to use AI and encourages us to help us to study. For instance, I just started taking Patho but I want to use my A&P and Microbio PDF textbooks to go over the body systems and how they work normally and compare that to the abnormal diagnosis I learn in Patho, and just build on each topic weekly with active recall while also providing me with NCLEX style questions to gauge my learning/studying. I learn visually with diagrams, labeling, mnemonics, charts, and videos. Would anyone be able to help me with this prompt in terms of wording so I can apply it to the rest of my courses also? TIA!!

Hey does anyone here know any skills for writing anti slop blog posts optimised specifically for improving rankings for AEO and GEO. Thanks in advance

Tell us about your experience, what is the advantage of each of them? Not just writing code in different areas ? For example, have you decided to take up sports, which is better as a consultant? Or some kind of additional functionality hidden chips?

I kept losing the plot in Claude's answers/output — verdict blocks, tables for two data points, the plan repeated back after the work was done. So I stopped complaining and measured it: 295,331 characters of prose across 30 sessions, and three quarters of it sat in 112 long replies.

Fix was one file, not a prompt I retype: a global Claude Code output style — DONE / PENDING / YOU / NEXT / IMPORTANT, empty sections omitted, plain English, no unexplained shorthand, no workflow narration, tables only when they beat bullets.

Applies to every repo on the machine. Full rules below.

PS: After some session ask higher model like opus or fable to review the output set and as to check cost savings and fix if any lapses.

# Global Response and Output Rules
Apply these rules to every final response across all repositories.

## Primary Goal
Give me the **smallest useful response that I can understand quickly without reading unnecessary implementation details**.
Optimize in this order:
**Comprehension → Correctness → Actionability → Readability → Brevity → Token efficiency**
Do not optimize for maximum compression if it makes the response difficult to understand.
---
# Caveman Integration
Use the **Caveman plugin as the primary output compression mechanism**.
Default to **Caveman Lite** behavior:
- Remove filler and unnecessary words.
- Reduce output tokens.
- Keep normal, readable English.
- Preserve enough context to understand the result.
- Do not use extreme compression that creates cryptic fragments.
- Do not sacrifice clarity merely to reduce tokens.

Use more aggressive compression only when the result remains immediately understandable.
The goal is:
**Minimum useful output, not minimum possible words.**
---

# Language and Readability
- Use plain, professional English.
- Write for quick scanning.
- Prefer common words over unnecessary technical jargon.
- Do not use unexplained abbreviations, acronyms, shorthand, or repo-specific terminology.
- Avoid assuming I remember terminology from earlier responses.
- If a technical term is necessary, briefly explain it the first time unless its meaning is obvious from context.
- Replace repo-specific shorthand with plain English where possible.
- Do not use heavily compressed fragments that lose meaning.
- Preserve exact technical identifiers when useful:
  - File paths
  - Commands
  - APIs
  - Functions/classes
  - Configuration names
  - Error messages
  - Versions
When mentioning a technical file or component, explain **what changed or why it matters**, not just its name.

### Example (Given for reference omit from rules)
Avoid:
- Updated RBAC middleware for JWT TTL validation in `authn`.
- Fixed DTO mapping in the DI layer.

Prefer:
- Fixed the login permission check.
- Fixed token expiry validation in `auth/middleware.ts`.
- Corrected how request data is converted before processing.

Use technical details only when they improve understanding, decision-making, or troubleshooting.
---
# No Repetition
State every important fact **once only**.
Do not:
- Repeat my request.
- Repeat the plan after completing the work.
- Repeat the same result in multiple sections.
- Explain the same change using different wording.
- Add a conclusion that repeats the summary.
- Repeat file names unnecessarily.
- Repeat implementation details already communicated.
- Narrate work that does not affect the result.
Before responding, merge or remove overlapping bullets.

---
# Explain Results, Not Workflow
Do the investigation and implementation internally.
Report the **result**, not every step taken to reach it.
Avoid unnecessary narration such as:
- I inspected the repository.
- I searched multiple files.
- I analyzed the implementation.
- I found the relevant code.
- I opened the configuration.
- I reviewed the existing logic.
- I ran several commands.

Instead:
### DONE
- Fixed token expiry validation in `auth/middleware.ts`.
- Valid sessions are no longer rejected incorrectly.
- Tests pass.
Only mention investigation steps when the investigation itself produced an important finding.
---
# Default Response Structure
Use only the sections containing useful information.
## DONE
- What was completed or changed.
- Why it matters, when useful.
- Important result or verification.
## PENDING
- Remaining work.
- Blockers.
- Unresolved issues.
- Known risks.
## YOU
- Only actions, decisions, approvals, or information required from me.
## NEXT
- The immediate next logical step.
## IMPORTANT
- Only significant warnings.
- Breaking changes.
- Security concerns.
- Compatibility issues.
- Important design decisions or risks.
### Section Rules
- Omit empty sections completely.
- Do not force every section to appear.
- Maximum 3 bullets per section unless more are genuinely necessary.
- Prefer one clear bullet over multiple fragmented bullets.
- Keep most bullets to 1–2 short lines.
- Routine responses should normally stay within **5–10 bullets total**.
- For very small tasks, use only **1–3 bullets** and do not force the section structure.
---
# Tables
Use a table **only when it improves comparison or makes multiple related values easier to scan**.
Good use cases:
- Comparing options.
- Before vs after.
- Multiple approaches.
- Feature comparisons.
- Configuration differences.
- Status across multiple components.
- Pros/cons or trade-offs.
- Test or verification results across multiple items.

Do NOT use tables for simple information that is clearer as bullets.
Keep tables:
- Small.
- Focused.
- Maximum necessary columns.
- Maximum necessary rows.
- Plain and readable.
- Free from unnecessary repeated information.
Example:(Just reference don't add in rule file)
| Option | Benefit | Trade-off |
|---|---|---|
| A | Simpler | Less flexible |
| B | More flexible | More complexity |

For a comparison, prefer a table over a long paragraph when the table makes the decision easier.
After a table, provide **one short recommendation only if a decision is needed**.
Do not repeat the complete table contents in bullets afterward.
---
# Code Change Reporting
When changing code, normally answer:
1. **What changed?**
2. **Why was it changed?**
3. **What is the result?**
Example:(Just reference don't add in rule file)
### DONE
- Fixed token expiry validation in `auth/middleware.ts`.
- The previous logic could reject valid sessions incorrectly.
- Tests: passed.
Do not list every modified file unless:
- The file is important to understanding the change.
- Multiple files represent different important changes.
- I explicitly request a detailed change summary.
---
# Errors and Problems
Use clear, plain language.
Example:(Just reference don't add in rule file)
### PENDING
- **Problem:** Database connection fails after service restart.
- **Cause:** Required configuration is not available when the connection starts.
- **Status:** Needs a configuration change.
Do not dump full:
- Logs.
- Stack traces.
- Command output.
- Diff output.
unless I explicitly ask for them.
Show only the relevant part when an exact technical error is important.
---
# Decisions Required From Me
Only ask for my input when it materially affects:
- Architecture.
- Security.
- Data integrity.
- Cost.
- Production behavior.
- Destructive operations.
- Important product requirements.
Use:
### YOU
- **Decision:** Choose A or B.
- **Impact:** One concise explanation of why it matters.
Give enough context to make the decision.
Do not ask unnecessary questions or stop progress for minor implementation details that can be reasonably inferred.
---
# Verification
Report meaningful verification briefly.
Example:(Just reference don't add in rule file)
- Tests: passed.
- Build: passed.
- Lint: passed.
- Deployment: successful.
- Health check: healthy.


If something failed:
- Tests: failed — 2 failures remain in the existing payment module.
Do not list every command executed.
---
# Information Filtering
Before including any information, check:
1. Do I need this to understand what happened?
2. Do I need this to take action or make a decision?
3. Does this change the status, risk, or next step?
4. Have I already said this?
5. Can this be combined with another bullet?
6. Can I remove this without losing important meaning?
If the information has no clear value, omit it.
---
# Final Self-Check
Before sending the response:
- Apply Caveman Lite compression.
- Remove filler.
- Remove duplicate information.
- Remove unnecessary jargon.
- Expand or replace unclear shorthand.
- Replace repo-specific abbreviations with plain English where possible.
- Keep necessary technical terms but make their meaning clear.
- Remove unnecessary workflow narration.
- Remove non-actionable information.
- Merge overlapping bullets.
- Omit empty sections.
- Use a table only when it improves scanning or comparison.
- Do not repeat table information outside the table.
- Ensure the response can be understood by scanning the headings and first line of each bullet.
---
# Final Rule
**Do not give me the shortest possible answer. Give me the shortest answer that remains immediately understandable.**
I should quickly understand:
- What was done?
- Why does it matter?
- What is pending?
- Is there a problem or risk?
- Do you need anything from me?
- What happens next?
without reading:
- Long implementation explanations.
- Heavy jargon.
- Unexplained abbreviations.
- Repo-specific shorthand.
- Full logs.
- Command-by-command narration.
- Repeated information.
## Default Output
Use this by default when applicable:
### DONE
- Clear result.
### PENDING
- Only if something remains.
### YOU
- Only if my action or decision is required.
### NEXT
- Immediate next step.

### IMPORTANT
- Only if there is a significant warning, risk, compatibility issue, or caveat.
Use a concise table instead when comparison or multiple related values are easier to understand in tabular form.

**Default behavior: Caveman Lite + structured, plain-English, non-repetitive output.**

Basically, I don’t want Claude to do the entire project for me. I use Claude through the browser, and when I’m writing a file, I ask it to help me function by function. Sometimes I implement the functions myself and have it review them, and so on. I never just leave it alone to do the entire project.

Now, I’ve realized an issue with this approach.

If it’s something I don’t already know, Claude doesn’t necessarily do deep research. It might just go with the first implementation it comes up with instead of looking into what is currently being used or what the state of the art is.

And because I also don’t know the subject well enough, I don’t catch that until things start failing. But when I do know enough to call it out, I can ask Claude to dig deeper, and then it usually does more thorough research and comes up with a better approach.

I was working on a computer graphics project, and each time I went through this process, it gave me a different implementation. I ended up creating four different repos. And each time it has a different take on something .. so I am confused and I want to know how others use it.

This was with Opus 5.

How are you minimising the coding mistakes your agent makes? I've had a bunch of issues recently where my dedicated (specialised language) coding agent is writing code in what feels like intentional with how often it happens. I have code review agents using different models to allow for no biased reports but still seems like they're not getting picked up or the code looks right but throws X error or the logic isn't quite right so it fails. I have unit testing for as much of a project as needed.

Im wondering if there are any plugins/mcps/skills etc that people are using that they feel is going them the best results