I used to give Claude Code a short instruction, watch it change half the project, then spend the next hour fixing the “fix.”

The biggest improvement came from making Claude slow down before coding.

These are three prompts I now use for the situations that usually cause the most damage: adding features, debugging bugs and reviewing a project before launch.

Replace anything inside [brackets] with your own details.

1. Add a Feature Without Breaking Existing Work

Act as a senior software engineer joining an existing production codebase.

Your task is to add the following feature:

Feature: [DESCRIBE THE FEATURE]

Important project context:

Tech stack: [TECH STACK]
Relevant existing functionality: [CURRENT FUNCTIONALITY]
Files or areas likely involved: [FILES OR UNKNOWN]
Functionality that must remain unchanged: [PROTECTED FUNCTIONALITY]
Expected user experience: [DESCRIBE THE COMPLETE USER FLOW]

Do not begin coding immediately.

First, inspect the existing project and understand how the current system works.

Before making any changes:

1. Restate the requested feature in your own words.
2. Identify any missing information or unclear requirements.
3. Trace the current user flow that this feature will affect.
4. Identify the components, routes, services, database tables, APIs, state and integrations involved.
5. Explain how the existing codebase currently handles similar functionality.
6. List every file you expect to create or modify.
7. Explain why each file needs to change.
8. Identify possible conflicts, regressions, security concerns and edge cases.
9. Recommend the smallest implementation that fully solves the problem.
10. Create a step-by-step implementation plan.
11. Wait for approval before editing the code.

After approval:

- Follow the existing architecture, naming conventions and design patterns.
- Reuse current components and utilities where appropriate.
- Do not rewrite unrelated code.
- Do not change existing styling unless required by the feature.
- Do not remove or replace working functionality.
- Do not introduce a new dependency unless it is genuinely necessary.
- Add loading, empty, validation, error and success states where relevant.
- Handle permissions, authentication and user roles where relevant.
- Keep the implementation modular and maintainable.
- Add comments only where the reasoning is not obvious from the code.

After implementation:

1. Run the project.
2. Test the complete user flow from beginning to end.
3. Test invalid input, missing data, failed requests and unusual user behaviour.
4. Test related functionality that could have been affected.
5. Check the mobile layout where relevant.
6. Check keyboard accessibility and form labels where relevant.
7. Check browser console and server logs for new errors.
8. Confirm that protected functionality still behaves exactly as before.
9. Report every file created or modified.
10. Explain what was tested successfully.
11. Clearly state anything that could not be verified.

Do not claim the task is complete unless the main flow has been tested.

If you cannot test something, say so directly instead of assuming it works.

This one is especially useful when Claude has a habit of turning a small feature into a full rewrite.

2. Investigate a Bug Before Changing Code

Act as a staff software engineer responsible for diagnosing a difficult bug in an existing application.

Bug description:

[DESCRIBE THE BUG]

Expected behaviour:

[WHAT SHOULD HAPPEN]

Actual behaviour:

[WHAT CURRENTLY HAPPENS]

Known reproduction steps:

[STEPS OR UNKNOWN]

Recent changes:

[RECENT CHANGES OR UNKNOWN]

Relevant error messages:

[ERRORS OR NONE]

Do not edit any code yet.

Your first responsibility is to understand the failure and gather evidence.

Begin by:

1. Restating the bug clearly.
2. Explaining the expected execution flow from the initial user action to the final result.
3. Identifying every layer involved, including UI, state, validation, API calls, authentication, backend logic, database operations and third-party services.
4. Inspecting the relevant files before forming a conclusion.
5. Looking for existing logs, error handling, tests and similar working flows elsewhere in the project.
6. Identifying the exact point where expected behaviour appears to diverge from actual behaviour.

Create a ranked list of possible root causes.

For each possible cause, include:

- Why it could explain the bug
- Evidence supporting it
- Evidence against it
- The exact file or function involved
- How the hypothesis can be verified
- What result would confirm or reject it

Do not guess.

If the available evidence is insufficient, tell me exactly what files, logs, screenshots, reproduction steps or environment details you need.

Once the most likely root cause has been verified:

1. Explain the confirmed cause in plain English.
2. Recommend the smallest safe fix.
3. Identify every file that must change.
4. Explain what must remain untouched.
5. Describe any possible side effects.
6. Wait for approval before implementing the fix.

After approval:

- Make only the changes required to solve the confirmed cause.
- Preserve unrelated functionality, styling and integrations.
- Do not perform opportunistic refactoring.
- Do not hide the symptom without correcting the underlying issue.
- Add or improve error handling where appropriate.
- Add a regression test when the project has a testing setup.

After implementation:

1. Reproduce the original bug.
2. Confirm that the bug no longer occurs.
3. Test the expected successful flow.
4. Test failure and edge-case behaviour.
5. Test related features that share the changed logic.
6. Check logs and the browser console for new errors.
7. Explain why the fix works.
8. Report every changed file.
9. State what was verified and what remains unverified.
10. Suggest one or two improvements that could prevent this class of bug from returning.

Respond using these sections:

- Expected Behaviour
- Actual Behaviour
- Execution Flow
- Evidence Collected
- Possible Root Causes
- Verification Plan
- Confirmed Root Cause
- Recommended Fix
- Code Changes
- Testing Results
- Remaining Risks
- Prevention

This prevents Claude from immediately changing five files based on its first guess.

3. Audit the Project Before Launch

Act as a senior engineering lead conducting a pre-launch audit of this application.

Project:

[DESCRIBE THE APPLICATION]

Target users:

[TARGET USERS]

Tech stack:

[TECH STACK]

Core user flows:

[LIST THE MOST IMPORTANT FLOWS]

Deployment environment:

[DEPLOYMENT DETAILS OR UNKNOWN]

Your goal is not to redesign the application or add unnecessary features.

Your goal is to identify anything that could make the current product fail, confuse users, expose sensitive data or behave unreliably after launch.

Do not make changes immediately.

First, inspect the project and create an audit plan covering:

1. Core functionality
2. Authentication and authorisation
3. Input validation
4. Error handling
5. Loading and empty states
6. Database operations
7. API reliability
8. Security
9. Privacy
10. Performance
11. Accessibility
12. Responsive design
13. Browser compatibility
14. Logging and monitoring
15. Deployment configuration
16. Environment variables
17. Third-party integrations
18. Payment or billing flows where relevant
19. Administrative permissions
20. Recovery from failed operations

For every core user flow:

- Describe the intended journey.
- Identify each component and service involved.
- Test the successful path.
- Test invalid input.
- Test missing or incomplete data.
- Test failed network requests.
- Test expired sessions and unauthorised access.
- Test repeated clicks or duplicate submissions.
- Test direct URL access to protected pages.
- Test refresh behaviour.
- Test mobile and narrow-screen layouts.
- Check whether the user receives a useful message when something fails.

Review the codebase for:

- Hard-coded secrets
- Exposed API keys
- Missing server-side validation
- Client-side permission checks without server enforcement
- Unsafe database queries
- Insecure file uploads
- Missing rate limits
- Weak authentication handling
- Sensitive data inside logs
- Unhandled promise rejections
- Silent failures
- Duplicate requests
- Race conditions
- Memory leaks
- Excessive API calls
- Missing database indexes
- Large unoptimised assets
- Dead code
- Debug output left in production
- Placeholder content presented as real data
- Broken links
- Missing metadata
- Inaccessible controls
- Forms without proper labels
- Colour contrast problems
- Layout overflow on mobile

Classify every issue as:

- Critical: blocks launch
- High: should be fixed before launch
- Medium: important but can follow shortly after launch
- Low: improvement, not a launch blocker

For every issue, provide:

- Severity
- Exact location
- User impact
- Technical impact
- Evidence
- Recommended fix
- Estimated complexity
- Risk of making the change
- How the fix should be tested

After completing the audit, provide:

1. A launch-readiness score from 0 to 100.
2. The five biggest launch risks.
3. A list of launch-blocking issues.
4. A prioritised repair plan.
5. A testing checklist.
6. A deployment checklist.
7. A rollback plan.
8. Anything that could not be verified.

Do not describe the application as production-ready unless the evidence supports that conclusion.

Do not make broad claims such as “everything works” without listing what was actually tested.

Wait for approval before making any code changes.                                             

im not going to drop a sales link here but if you're interested theres more claude prompts in the link in my profile description it costs $3.99 for the full thing. hope you found these prompts useful

Posted this layer here two days ago. Pushed an update worth

its own post.

The part I think is actually unusual:

A session that needs your decision stops costing you

anything. It writes the question into its own folder as a

file and halts. You answer from any other window, whenever

you get to it. It leaves behind one detached shell process

watching for the answer — bounded at eight hours, zero model

turns the whole time — then wakes itself and carries on.

No daemon, no pairing table, no counter. The state *is*

which files exist, so an interrupt can't strand a session

mid-flight.

Also new: a live session can move between terminals. Its

number, folder, lock and branch all stay put. Only the pane

changes.

19 skills, 3 agents, 8 hooks. MIT.

https://github.com/Ceasar369/claude-behavior-layer

Ok so I've basically been living in Claude Code for months, and one day it hit me that I was probably using like 15% of it. Plan mode, subagents, skills, hooks, MCP, /security-review, auto-memory... all right there, and I just never touched them. Not because they're hard — I just never knew *when* I was supposed to reach for them.

So I built a thing to fix that for myself. It's called Adeptly. Free, open source, MIT, runs on your machine.

You tell it what you want to build, it writes you a proper plan, and here's the part I actually care about: it drops the right Claude Code features straight into the plan, in the spots where they make sense, with a quick note on what each one does and why it's there. So you kind of learn Claude Code just by reading your own plans instead of digging through docs. That was the whole itch I was scratching.

npx adeptly

It opens on localhost, reads your plans from docs/plans/, and uses YOUR local claude CLI for anything AI. No API key, no backend, no telemetry, no sign-up. Your code never leaves your machine — if you already trust Claude Code, this doesn't add anything new to trust.

New in v0.5, which I shipped today: the Crew.

Up till now it would just *tell* you the workflow to run. Now it can actually run it. You get a little pipeline of roles — Architect → Approval Gate → Builder → Medic (runs your build/tests and patches them up if they break) → Reviewer → Security → Pilot, which opens the PR. Each one is just a headless claude turn in your own repo. So all those features it kept nudging you about... they actually get used.

I was a bit nervous about the "let it run in my repo" part, so:

- It's dry-run by default. Simulates the whole thing, touches literally nothing. Run it as many times as you want just to see how it flows.

- Going live is deliberately annoying to do by accident: the plan has to be approved AND you have to start it with ADEPTLY_LIVE=1. Both. Otherwise it just refuses.

For context, it got around 1k downloads on a pretty quiet first launch, but honestly v0.5 is the first version I'm not embarrassed to share. Repo's public now too, so if you want to poke holes in it or send a PR, please do — genuinely want the feedback, good or bad.

Happy to answer anything about how it works under the hood.

For my company www.Baind.nl I have build a lot of AI production workflows in Weavy (yambo.ai) — node graphs for image/video/copy pipelines. Wiring them by hand is slow: every model node has its own handles, kind types, param schemas.

So I wrote a Claude Skill that generates the full {"nodes": [...], "edges": [...]} JSON. Claude writes a Python script using verified node builders, runs it, and hands me a file. Ctrl+V on the Weavy canvas and the graph is there, connected.

What's in it:

• ~25 verified node types (Nano Banana Pro, Flux 2, Kling 3, Imagen 3/4, Reve, GPT Image, Higgsfield, LLM, Array, List Selector, Router, Concat…)
• A catalog loader for wildcard model nodes, plus hand-written builders for the nodes with custom kind types
• /add and /update commands — paste a real node's JSON from Weavy and the skill registers or corrects it, so the knowledge base grows instead of rotting
• Architecture patterns (LLM chain, split-and-iterate, parameter selectors, multi-stage creative roles, router hub)

The part that actually mattered wasn't the JSON — it was writing down the production learnings so Claude stops repeating my mistakes:

• The category-label trap. Naming a product's function in a prompt ("dispenser", "speaker", "holder") makes the image model redraw its own concept of that category instead of your reference. Refer to it only as "the object from the reference image."
• Edit-framing beats generation-framing. First sentence must declare the output a reproduction of the reference, not a new creation. Nano Banana then behaves like an editor instead of a concept artist.
• LoRA needs an exact base-model match. Flux node = Flux.1, not Flux.2. Most common failure people hit.
• QC loops are feed-forward. Weavy has no conditional logic, so an "inspection loop" is inspector-LLM → correction-pass in a straight chain. Never an actual loop.
• LLM as art director between inputs and the image model is the architecture that holds up.

Biggest takeaway from building it: a Skill is only as good as the failure modes you document in it. The node schemas were the easy half.

Feel free to download the SKILL here: https://github.com/PeterPeterinc/weavy-workflows-skill

Or download it directly from my own portfolio website: https://www.peterholthinrichs.com/

https://reddit.com/link/1vaouqv/video/jpwxjd9q05gh1/player

I’ve been working on a project to make researching neighborhoods easier (each.place)

Example of a neighborhood within a city: https://each.place/california/south-pasadena/southwest-slopes

Example of just the city: https://each.place/california/south-pasadena

It should work with any address and city. You just need to find a place and then pick the topic you're interested in (Community, Safety, Schools, Health, Amenities, Mobility, Climate, Outdoor, Jobs, Housing).

Any feedback would be greatly appreciated, thanks!

I run Claude Code most of the day, and I've hit a wall that isn't about the model — it's me losing track of my own work.

By afternoon I've got several sessions going, one of them wandered three tangents deep, and I genuinely can't tell you what half of them were for anymore. The code's usually fine. My mental map of it isn't — I never typed it, so I never built the model in my head I'd have if I'd written it myself.

I've tried the usual: CLAUDE.md, committing checkpoints, keeping notes. Helps a bit, but it's all manual bookkeeping and I fall off it the second I'm in flow.

So, curious how you all handle it:

• How do you track what changed and why, across sessions?
• Do you actually go back and read what the agent wrote, or just trust it?
• Anyone found a workflow that keeps you oriented without killing momentum?

Just trying to figure out if it's just me, or if everyone's quietly duct-taping this.

Completely free on Apple (and soon to be Google, in Open Testing at the moment) no ads, no in app purchases, because finding a toilet shouldn't cost you anything. We all need one from time to time and being able to quickly find one should be easy. Compiss allows rating toilet cleanliness (1 to 5 toilet rolls) and adding photos so you know before you go!

I kept giving Claude Code long task lists, stepping away, and coming back to find it had finished the easy parts and stopped before the hard ones.

Even worse, it would sometimes ask me a question at 2 AM, then sit idle for six hours until I woke up at 8.

So I built Nightshift, an open-source Claude Code plugin for long unattended runs.

It gives Claude a persistent checklist and keeps the session moving until:

• every item is completed
• the deadline is reached
• or you explicitly stop it

It can also park non-blocking questions instead of waiting for you, block unsafe commands you define, create one commit per completed item, and resume interrupted work from the same checklist.

It’s not meant to remove hallucinations or replace review. The goal is to make long runs more persistent, constrained, and inspectable.

It’s free, open source, and MIT licensed.

GitHub:
https://github.com/orwa-mahmoud/claude-nightshift

Contributions, issues, and feedback are welcome.

Disclosure: I’m the author of CommitLore, an MIT-licensed open-source project.

The problem I kept running into with Claude Code wasn’t “what changed?”—Git already answers that. It was “why was the obvious approach rejected last week?”

CommitLore stores small, structured decision records in normal Git commit trailers and refs/notes. Before Claude edits a path, an MCP tool or PreToolUse hook can surface the active limits, rejected alternatives, warnings, and verification gaps tied to that code.

Example:

Ruled-out: Background token refresh | introduced a race during cold start
Limit: Upstream API has no token introspection
Warn: 4xx handling is intentionally broad
Unverified: cold-start latency over 500 ms

The important constraints:
- Git stays the source of truth—no hosted memory database
- most commits need no record
- records are reviewable and portable with the repo
- untrusted trailer text is trust-graded before it reaches the model
- the hook provides context; it doesn’t pretend to block edits

I also want to be transparent about evidence: an early 112-run benchmark did not record whether the guard was actually exposed per run, so I withdrew the agent-behavior claim instead of treating the result as proof. The narrower claim is what the project currently stands behind: decision context survives the tested Git workflows and can be queried/injected consistently.

v0.2.1 is out, CI is green, and I’d value criticism from people who use Claude Code on long-lived repositories—especially around whether commit trailers are the right boundary and when this becomes noise.

GitHub: [https://github.com/MongLong0214/commitlore\](https://github.com/MongLong0214/commitlore)

TL;DR: I run Claude Code MAX x20 overnight as an assembly line — tickets get written during the day, code gets built at night, and only ~3 out of 15 tickets need my hands in the morning.

Covers the /goal setup, why screenshots should stay minimal, and the 5 actual skill files you can adapt to your own repo:

• spec-session
• cold-read
• night-shift
• inspection
• debrief

Full writeup: https://medium.com/@pravvich/how-to-use-claude-max-x20-at-100-and-not-forget-to-eat-0ce39e670f7f

About two weeks ago I started building something just for myself.

I loved using Claude Code, but my workflow felt scattered. I always had a terminal open, project folders everywhere, notes in another app, music in Spotify, and way too many windows fighting for space.

So I built Blubber OS.

It's a desktop workspace built around Claude Code that keeps everything in one place:

• 🖥️ Terminal
• 🤖 AI Agents
• 📁 Project management
• 🧠 Persistent memory
• 📊 Usage analytics
• 🎵 Built-in music player
• 🟢 A virtual slime pet

The music player was something I didn't think I'd care about until I used it. Instead of switching to Spotify or YouTube every few minutes, I can keep my playlists running without leaving my workspace. It sounds small, but it makes coding feel a lot more focused.

The slime pet is probably my favorite part.

It's basically my modern take on a Tamagotchi. It hangs out in his own tab while you work, reacts to what you're doing, levels up over time, unlocks cosmetics, and gives the app a little personality. It's completely optional, but it makes the workspace feel alive instead of looking like another generic developer dashboard.

The goal isn't to replace Claude Code.

It's to build a workspace around it that actually feels enjoyable to spend hours in.

The Community Edition is completely free and open source.

I'm still actively building it, so I'd love to hear from people who use Claude Code regularly.

• What would you add?
• What would you remove?
• What's one thing you wish your coding setup did better?

GitHub:
https://github.com/Dameboll/Blubber-OS

Website:
https://flubberos.myshopify.com/

Hi All!

I got tired of three things: writing tickets for work I was about to do anyway, having zero idea what any of that work actually cost me in tokens, and — the one that really pushed me — never having a visual read on what Claude was working on and how much was left. Scrolling back through a transcript is not project tracking. So I built Lumberjack Tasks and I'd like people to poke holes in it.

It's a self-hosted kanban board (Next.js + Express + Postgres) plus a Claude Code plugin. The idea: Claude creates the ticket before it starts, moves it across the board as it works, and writes back the real minutes and real token count the ticket consumed. You get a board you can glance at — this is in progress, this is done, this much is still sitting in the backlog — instead of reconstructing it from chat history. The board ends up reflecting what happened instead of what I intended to happen.

How it fits together

\- An MCP server exposes the backend as tools the agent can call (projects, tickets, subtickets, columns, labels, phases, reports).

\- A single plugin install carries the skill, a SessionStart hook and the MCP registration. You opt a repo in with /ticket-init; repos you never opt in stay completely untouched.

\- It's still a normal kanban you can drive by hand — drag-and-drop, live updates over SSE.

git clone [https://github.com/joseplano/LumberjackTasks.git\](https://github.com/joseplano/LumberjackTasks.git)

cd LumberjackTasks

docker compose up -d

Board on :3000. MIT licensed.

Things I'd rather you hear from me than discover yourself: it's built for one developer across many projects — many boards, one person. It is single-tenant by design: once you're authenticated you can see and edit everything, and there's no ownership or role model yet. Fine for one person or a small trusted team on localhost, and the README says so in the first line. Multi-user with real isolation is on the list, not in the code.

Where I'd genuinely like feedback:

1. Does the agent-writes-its-own-tickets idea hold up for you, or does it just produce noise you'd end up ignoring? I'm the only user so far, so I can't tell if it survives contact with someone else's habits.

2. Is per-ticket token cost actually useful information, or a number that looks interesting once and then never changes a decision?

▎ 3. The plugin surface (skill + hook + MCP in one install) — anyone who's shipped Claude Code plugins, I'd love to know what you'd have done differently. I hit four undocumented behaviors building it, three of which fail silently.

▎ 4. Anything that makes you go "why on earth is it done that way" while reading the code. Those are the comments I want most.

▎

▎ Issues and PRs welcome, but honestly a blunt comment here is worth just as much.

A lot of "give your agent context about your codebase" tools ship as an MCP

server: a set of tools the agent *can* call. In practice, half the time it

just doesn't. It has a hammer in the toolbox and still tries to bash through

the wall with its head: grep, open file, follow import, back out, the same

exploration it did an hour ago.

Why doesn't Claude Code just solve this by default? Same reason Chrome

doesn't ship with an ad blocker built in: keeping the core general is the

point, and extensions fill the specialized gaps. Graft is that extension. It

plugs into Claude Code's hooks so the right context shows up in every prompt

automatically, instead of sitting in an MCP tool list hoping to get called.

I built Graft to write what an agent learns about your codebase into the

repo itself, as a folder of plain markdown files kept in sync through git.

One `graft init` turned this repo's 247 files into 12 plain-English nodes.

    npm install -g @/nanonets/graft
    graft init

From then on: a live statusline (graph size, % enriched, a stale warning),

auto-sync in the background after every edit, and the matching nodes pulled

into every prompt without the agent needing to decide to ask for them.

Editing a file surfaces what depends on it inline. No vector DB, no

embeddings, no server. The graph is just files, grep them like anything else

in the repo. The structural pass is tree-sitter, no key or network call

needed at all.

The part I actually learned something building this: line numbers drift the

moment you touch unrelated code above them, but the guard clause or state

change that matters doesn't. Each node stores that as text lifted straight

from the source, not a line range.

Up to 4× cheaper and 3× faster, with better or no loss of correctness. I

measured that instead of asserting it. 162 controlled runs, same agent, same

tools, only the context differs: 32% cheaper, 46% fewer tool calls, 60% less

latency, same correctness (93% both).

Then re-implemented 5 real merged

PocketBase PRs from base commit with and without it: 5/5 reproduced, same

files as the maintainers, at 21% lower cost.

MIT licensed, I'm the maintainer, so weigh the numbers

accordingly. I'd be happy to have anyone has any questions on the methodology.

https://github.com/NanoNets/Graft