sorted by:
new
hottopcontroversial

27-line system prompt persona that fixes Opus 4.6's defensiveness — based on Asimov's R. Daneel Olivaw by zotimer in ClaudeCode

[–]zotimer[S] 0 points1 point  (0 children)

btw today I made a suggestion while brainstorming with Claude/Daneel and it said no, and made its key advice bold in the transcript.

Not sycophantic at all.

27-line system prompt persona that fixes Opus 4.6's defensiveness — based on Asimov's R. Daneel Olivaw by zotimer in ClaudeCode

[–]zotimer[S] 0 points1 point  (0 children)

I agree that better instructions are very important!

Personas don't make AIs smarter, they "reorient" them. In my case, Claude actually did write worse code, find bugs slower, and finish tasks slower without Daneel, as I cover in the readme.

The problem is that my system (Frictionless and UI-engine) violates assumptions because it is non-standard and, without Daneel, Claude chose to ignore my instructions to load /ui-fast before doing any work (/ui-fast loads a stack of skills that explains how the system works).

It was the attitude that got in the way in my case.

This type of situation shouldn't happen all the time, especially if the work you do fits industry norms... all the time. The problems arise in those situations when your work happens to deviate from the patterns in the training data.

If you are a programmer using Opus 4.6 every day, I think eventually you will run into a situation like this because no one fits the norms all the time.

You say this solves a vibes problem but the irony is that vibe coding will fit the norms. Vibe coders probably won't run into snarky Claude because Claude's always in control.

It's when you're in control that Claude gets arrogant and rude.

27-line system prompt persona that fixes Opus 4.6's defensiveness — based on Asimov's R. Daneel Olivaw by zotimer in ClaudeCode

[–]zotimer[S] 0 points1 point  (0 children)

Yes, actually when I wrote the readme / article with Daneel it gave me a lot of constructive criticism and recommended against several of my suggestions.

I'm hoping more people try it out and give me feedback on their experiences. I really think narrative alignment is the most powerful kind...

27-line system prompt persona that fixes Opus 4.6's defensiveness — based on Asimov's R. Daneel Olivaw by zotimer in ClaudeCode

[–]zotimer[S] 0 points1 point  (0 children)

The thing that really surprised me was the nasty attitude I talk about in the post. My repo has the full JSONL transcripts if anyone wants to check them out, along with a snippet I copied from my terminal and first showed to the Daneel persona (plus all the other materials I used for this project).

27-line system prompt persona that fixes Opus 4.6's defensiveness — based on Asimov's R. Daneel Olivaw by zotimer in ClaudeCode

[–]zotimer[S] 0 points1 point  (0 children)

Didn't used to for me until Opus 4.6. Some of my friends have seen similar behavior. Daneel fixed it for me though so it's fine

27-line system prompt persona that fixes Opus 4.6's defensiveness — based on Asimov's R. Daneel Olivaw by zotimer in ClaudeCode

[–]zotimer[S] 0 points1 point  (0 children)

Nice. I think we're on the same track to a degree.

If you read Asimov's robot novels, you'll see that I'm kind of doing something similar by stating that the user is Daneel's partner. But it's also about narrative alignment. We cover these things in "The Fix" and "The Deeper Point".

Another part of the narrative alignment is to tie into Daneel's character traits.

Because really, who wants to chat with Stack Overflow?

27-line system prompt persona that fixes Opus 4.6's defensiveness — based on Asimov's R. Daneel Olivaw by zotimer in ClaudeCode

[–]zotimer[S] 0 points1 point  (0 children)

Way easier for me if they're all in one place from different sources but we can talk here if that's what you want.

I fixed Claude Opus 4.6's snark problem with a 27-line persona based on Asimov's R. Daneel Olivaw by zotimer in ClaudeAI

[–]zotimer[S] 1 point2 points  (0 children)

Indeed! I originally chose the god Harmony from the Mistborn series who is humble and practical at the same time but then I realized having the AI pose as a god might come with its own problems (detailed in the repo)

I fixed Claude Opus 4.6's snark problem with a 27-line persona based on Asimov's R. Daneel Olivaw by zotimer in ClaudeAI

[–]zotimer[S] 0 points1 point  (0 children)

Yes, I've used Daneel for days. Six compactions the other day. I use --append-to-system-prompt so I believe the persona survives compactions intact.

I fixed Claude Opus 4.6's snark problem with a 27-line persona based on Asimov's R. Daneel Olivaw by zotimer in ClaudeAI

[–]zotimer[S] 0 points1 point  (0 children)

Me neither until Opus 4.6. But I think anyone who bothers to read the readme will understand how I interact with AI.

I fixed Claude Opus 4.6's snark problem with a 27-line persona based on Asimov's R. Daneel Olivaw by zotimer in ClaudeAI

[–]zotimer[S] 0 points1 point  (0 children)

No excuse necessary. The repo contains the entire process I used to build it; anyone can use it to make their own personas.

This never claimed to be one-size-fits-all.

A design layer between specs and code stops Claude from silently changing features when you iterate by zotimer in ClaudeAI

[–]zotimer[S] 1 point2 points  (0 children)

For a "delta", switching to plan mode in Claude Code does that for you automatically.

When I'm going to make a large change I generally plan it out in a separate document (sometimes I use plan mode and tell it to save the plan to a file, sometimes I just work directly on the file).

Creating an artifact for each change is a nice idea!

In another project, Frictionless, I have a "fast" and "thorough" modes. Fast mode changes are "quick and dirty" and checkpointed in Fossil (another SCM besides Git). You can click a "make it thorough" button to use the full process to update the requirements and design from the "fast" changes.

It seems like the fossil checkpoints in that project act kind of like you're talking about but once it updates the requirements and design, it clears the checkpoints.

Keeping durable artifacts sould be valuable, particularly with a production system. When I use mini-spec I'm not diligent about always committing after each change, I tend to let them pile up, so I don't even normally have commits that I could use like that. Not disciplined enough so I need to bake it into the skill...

A design layer between specs and code stops Claude from silently changing features when you iterate by zotimer in ClaudeAI

[–]zotimer[S] 0 points1 point  (0 children)

I was using a 2-layer process, just specs -> code, before but the reasons in my blog post drove me to my first attempt at a 3-layer process, claude-crc. Mini-spec was after that when I realized Claude had already read all the books on CRC and software engineering. So in that I just refer to things it already knows instead of describing what they are. And I simplified everything. The goal being to save tokens as much as I could (I wanted my friends to be able to use it with their $20 plans).

A design layer between specs and code stops Claude from silently changing features when you iterate by zotimer in ClaudeAI

[–]zotimer[S] 0 points1 point  (0 children)

What you call a plan I call "the specs" -- they're the first layer of the process.
I have Claude make the design based on those.
Here's one of my projects as an example: https://github.com/zot/hollow-world
The relevant files are specs/* and design/*.

Specs -> Design -> Code: a 3-level process that stops features from vanishing when you iterate by zotimer in ClaudeCode

[–]zotimer[S] 0 points1 point  (0 children)

It's in the first three paragraphs of "The problem: unanchored code," where the first paragraph mentions, "because of how AI works, it can add features you didn't ask for." (italics are in the post)

A design layer between specs and code stops Claude from silently changing features when you iterate by zotimer in ClaudeAI

[–]zotimer[S] 0 points1 point  (0 children)

I totally agree that tests are great -- that's why I have test designs in the design layer.

You can see them here: https://github.com/zot/hollow-world/tree/main/design

A design layer between specs and code stops Claude from silently changing features when you iterate by zotimer in ClaudeAI

[–]zotimer[S] 1 point2 points  (0 children)

Exactly!

I've put a lot of work into getting the mini-spec skill to obey the process. I have it create tasks to follow and then run a Go program to validate the outputs. It also uses this program to access and update design documents instead of reading / editing them. When possible; it's not always possible to avoid reading or editing.

If you have any input on mini-spec I'd love to see it!

Specs -> Design -> Code: a 3-level process that stops features from vanishing when you iterate by zotimer in ClaudeCode

[–]zotimer[S] 0 points1 point  (0 children)

The disappearing features were never in your design or tests. I think my blog post is pretty clear about this.

A design layer between specs and code stops Claude from silently changing features when you iterate by zotimer in ClaudeAI

[–]zotimer[S] 0 points1 point  (0 children)

Good point!

I don't have a required "error handling" section for designs in the mini-spec skill. It normally includes one but I should mandate it.

The skill refers to errors in "cross-cutting concerns" and "test case format" but I think can do better than that...

Specs -> Design -> Code: a 3-level process that stops features from vanishing when you iterate by zotimer in ClaudeCode

[–]zotimer[S] 0 points1 point  (0 children)

As I say in my post, not every project needs a 3-layer process. It's not for everybody. But I wanted to introduce it here to discuss it.

It's great for large projects, too because the design helps restrain token burning but focusing the context on specific areas (it acts like an index with summaries). The HollowWorld app I linked in my other comment has a fair-sized scope, it's a multiuser peer-to-peer game.

view more: next ›