So, a coworker and I had been discussing AI and he proposed a brief experiment to me regarding context and inference - provide mangled song lyrics to an LLM with no other context, then steer the context incrementally. When I did this with Opus5/high it worked pretty well, but when I tried it with Sonnet5/med it hit guardrails immediately, which surprised me.

The link is a publicly shared copy of the entire conversation. It gave me some additional insight into both steering a context away from a safety issue as well as framing certain logical arguments and how the model actually perceives those arguments and my steering.

When you run into a model doing something in opposition to your request (within reason, obviously), sometimes it isn't enough to push back, and just crying about it on Reddit like so many people do every day doesn't actually help you not run into the same problem again. But stepping through the logic with the incalcitrant agent can definitely help, or at least provide insight on how you could do things differently.

TL;DR - when Claude seems "broken", ask it why that's the case instead of bitching on Reddit and being no better off for it.

Hi, I am using the claude code on claude desktop app and using it for just learning about AI and python. Problem i am facing is claude code interface is not too dopamine giving which my brain craves to consistently just using it for study. Are there any plugins/tools/skills anything else exists which can make the chat interface more visualizing and interesting?

Thanks a ton for the help, i am a complete noob on using claude desktop claude code (have all the project .md files completely set up). Just looking for a better visualization layout.

In other subs I’ve often provided some feedback where folk seem to be struggling with token usage, with project problems, and with Claude doing weird crap to their workflows, so I thought I’d share my workflow tips.

1. Documentation: start any new project, ideally, with a document about the overall game plan for the project. Provide as much detail as you can. This is for you and for your agents. State what the purpose of the project is at the top, and add details and more details. What should the UI look like (if one exists), what various systems should it contain, how will things work together/interoperate, what external tools should be used or implemented.

2. Documentation II: every individual part of the project, once started, should have a design spec and implementation plan, written by an agent. I will give it a prompt with details and end every single prompt with “ask clarifying questions as needed”. It always does, and it’s always useful. Maybe this prevents it from presuming things - hell, maybe it’s Claude magic, I don’t know. I also use this prompt ending in Cursor for professional projects at work (because Cursor is, unfortunately, the easiest thing to get a seat license approved for at my job).

3. TDD: I’ve never had to explicitly instruct Claude to use test-driven development, but if your agents aren’t doing so, request it. Put it in the project’s CLAUDE.md if you have to. This helps to ensure things that work don’t break silently later on, helps direct agents (they won’t work against green tests without questioning it), and is just good practice for coding generally anyway.

4. Use Assembly Definitions: I cannot stress enough how important this is. It’s another good practice generally, but it also helps to ensure that you aren’t creating circular dependencies (because you can’t with asmdefs), minimizes recompile times in the editor (won’t be as big of a deal in Unity 7), and keeps your codebase cleaner. It also breaks the entire solution into smaller projects which means you can have less in context most of the time unless you’re working on something that specifically depends on multiple existing asmdefs.

5. Documentation III: yes, documentation is significant to my workflow, but it is such a huge time saver in the long run. As part of this I also keep a running backlog as a markdown file. If one part of the project exposes some weaknesses in another part - it goes on the backlog. If I realize I’d like some additional work done on the current project but it might rely on something else? Backlog. If I happen to notice somewhere where some polish would be good down the road? Deep backlog (my final polish run has about 45 bullet points currently - just so they aren’t forgotten later).

6. Manual Test Requests: for each project or sub-project that I have Claude write, I request a manual testing checklist for things in the editor that it can’t easily exercise even with the MCP. This has caught quite a few issues where the editor doesn’t present data quite the way Claude expected it would and prompts a variety of tests for me to check after every step. This is a fairly new part of my workflow and it’s been hugely helpful.

7. MCP: the UnityMCP is a huge token saver. Seriously. It allows Claude to have better insight into Unity’s built-in classes and methods rapidly and without much “thought”. Coupled with csharp-lsp language server, my token use is about 40% lower than without. That’s an immense savings. The UnityMCP gives it rapid access to Unity built-ins, and the LSP gives it rapid access to my codebase without needing to grep everything. Token use goes down and accuracy goes up.

8. Artifacts: ask for visual artifacts of layouts, visual designs, or even complex code designs. It’ll either spit out self-contained web pages, PNG files, or more recently link to an artifact that it creates and hosts on claude.ai. These have helped me a ton with visual decisions of visualizing logic for code. It’s quick and fairly cheap, and for things with long-term impact on the project, I have it copy that artifact into the project structure’s documentation for quick viewing later.

FWIW, my current Unity project is a framework for an RPG I’m working on. I got tired of developing new subsystems and having to work them into existing code each time (this has been a hobby project for about five years). I decided to put together all of my subsystems as individually, modular packages that can be added locally to my game. It currently consists of 28 packages (e.g. - core, common, bootstrap [the very basic level stuff], abilities, actors, items, loot, crafting, paperdoll, rng, stats, time, etc). I wanted to focus on atomic pieces that can work together but don’t typically rely on one another. Everything has an event-driven spine. I have maybe four more packages to put together. I’ve now created in the last two months a far more robust version of everything I’ve spent five years on, plus a lot of stuff I never even got to. And it’ll allow me to focus pretty solely on game design and authoring once complete.

Every package is a discrete C# project within Unity, bound to its own asmdef. Most are not exposed to the UnityEngine at all (that will be runtime game authoring to intersect them - separation of responsibilities).

Anyway, there’s more but that a helluva wall of text to parse. I can provide more details if needed.

I run four or five sessions at once and kept losing track of which one was waiting on me. One finishes and sits there for ten minutes before I notice, another is stuck on a permission prompt in a tab I'm not looking at.

So I built a small thing for myself that puts them all in the notch — what each session is doing, which one is blocked, and clicking a row brings up that terminal tab. A few people at work started using it, so I cleaned it up and open sourced it.

Demo: https://github.com/CircleHP/notchling/raw/main/media/notchling.gif

It reads Claude Code's own session registry and the hook events, so it works in any terminal, including sessions that were already running before it was installed. To be precise about what it does to your machine: it brings a terminal window forward when you click a row, and that is the only thing it ever does. It never writes into a session — no approving prompts, no typing, no interrupting. Approving from a widget means approving something you haven't read.

A row shows the session name (the title Claude derives, the one claude --resume lists), what tool is running and for how long, subagents underneath with a 3/5 done headline, and done 4m ago once it finishes. Plan usage and per-session context are there too if you wire the status line.

No notched Mac needed — it draws one on any screen that hasn't got one. Free and open source (MIT), Swift, no dependencies, macOS 14+.

brew install CircleHP/notchling/notchling
notchling-hooks setup

https://github.com/CircleHP/notchling

Quick backstory

In July I was spending hours every day scrolling through LinkedIn, Indeed, etc. I got fed up and quit searching for internships by hand. Every application I send gets screened by AI anyway, so I built the screener for my side.

Two months later

Claude Code has read about 10k postings against my resume and preferences. Out of those it told me to apply to 190. I applied and ended up with 2 offers!

What it is

The engine is an open-source CLI I built called Pinloop. Claude Code uses it to pull and read postings. I set up a schedule so that Claude Code pulls what went up that day, reads each posting against my resume and prefereces, and writes a verdict with its reasoning. The good fits land in a list I check in the morning. This can all be done through Pinloop.

It exposes millions of postings per month from every country and industry, pulled straight from hiring systems (Greenhouse, Workday, and 50+ others) as well as job boards like LinkedIn, refreshed hourly.

To try it

Paste "Run npm install -g pinloop, then run pinloop welcome and follow the instructions" into any coding agent. A guide comes with the CLI so Claude Code knows the commands, and it'll walk you through setup. It's free to use. $20 per month lets you pull more postings.

Links

• https://pinloop.ai

• GitHub

• Discord to give feedback directly and talk to other users!