This raise a question: why do open source models sometimes identify themself as Anthropic's models. I recall seeing some plausible theories in the past but I can't recall.
Name training is shallow and should never be relied upon. Claude sometimes identifies itself as Qwen or DeepSeek when asked in Chinese. I've seen it identify itself as GPT-3 (that version in particular) and Reddit Anti-Evil Operations team (Sonnet 3.6).
"He was born, lost his father at 13, was orphaned at 20, had 4 children, and died at 90 of a parasitic infection, with 3 surviving children, 10 grandchildren, and 15 great-grandchildren."
You may be interested in my No3371/projex repo, which is a whole solution based in this idea, I wonder how much do people do differently in this direction
> Plus your handoff files becomes a useful piece of project memory that you can reference later.
I've been doing this since I started agentic development, and have a whole framework based on this; Simply put I define workflow s that output templated files for everytype of tasks that happens in development.
I started doing this and then a colleague of mine recommended me OpenSpec. It might be overkill for small projects but it’s pretty clean and if you have goldfish memory like me, it helps to track changes.
I now feel a bit silly but I reinvented the wheel during my last lil project and indeed found it very powerful. A variant of it is the "implementation (handover) prompt" when I conclude the planning session with plans and design documents, updated handoff, clean tree and a file for a new Opus implementing orchestrator (unusually do a single, highly specific implementer and a single, highly specific tester).
After implementation and task-level tests I end up with a long and very detailed implementation progress ledger and a summary findings from the orchestrator.
Then in the new session I do the whole branch tests.
Works really well, uses much less tokens than any other approach with more of Opus and very little repetitions/corrections.
Yeah, making it a skill is just much more convenient. It can be a very simple skill, a one liner asking the agent to gather the context and write a handoff for another agent. My skill is unnecessarily complex if that's the only requirement.
This is where I landed too. Basic skill for a Jira-like task board and another for keeping an orchestration ledger. Let’s me arbitrarily clear context without losing big picture knowledge.
I've been using my own variant docset driven development since late last year. It emerged organically for me by adapting to the limits of the agents.
- Prefix-numbered sets of documents, keeping them clustered visually and easily referenced by humans and agents. (124.5 = docset 125, phase 5)
- Each doc gets a suffix. Most of the time STRATEGY is the first doc. Sometimes NOTES, DISCUSSION, or HANDOFF though.
- Once the strategy doc is comprehensive, the multi-phase checklist PLAN doc can emerge.
- During execution, the agent drives the PLAN while purposefully expanding lightly scaffolded phases before entry.
- As the user, I drive a PROGRESS doc during the PLAN execution. This tracks the progression of my own questions and the important work summaries that I need for tracking the current work trajectory and for historic analysis over past decision-making.
- Any concern that exceed the scope of the active docset numbers calls for a new one.
- A "docs/archive" folder is kept where I sweep docsets into numbered eras.
I have aliases and templates too, but DDD is so simple that it's overkill.
Any modern reasoning agent can take the plain explanation above and understand you effortlessly when you say "open a new docset strategy" or "read docset 125 and proceed".
I used this for a while then decided to build my own suites that pack individual harness and respective host state (config, plugins, skills, etc.) into an image. Works better and much flexible in my opinion.
reply