From Context Chaos to “CLEAR” &#8211; An Origin&nbsp;Story

The No-Code Journeyman

I started AI-assisted prototyping with no-code tools like Lovable, Bolt, and Figma Make, but hit frustrating limitations: platform lock-in, no code downloads, and hidden implementation details. Debugging was painful without transparency into changes, and I couldn’t prevent or understand questionable AI decisions. For cost efficiency, these tools also use “smart routing” to assign requests to different AI models without transparency, but this meant I’d get stuck on simple problems when routed to weaker models. Eventually, I abandoned these platforms.

I switched to VSCode with Claude Code, finding CLI assistants liberating for rapid prototyping. However, I quickly identified the core challenge: managing memory, context, and tokens. CLI coding assistants start each session with no memory or context of previous work. To address this, I set up a method of elaborate documentation for Claude Code with 3 memory layers:

Long Term Memory – The project spec and complete blueprint with everything Claude Code needed to build. This lived in CLAUDE.md which Claude would load at the start of every session
Working Memory – Summaries of previous sessions, key technical decisions, what got done and what’s up next. This was all in one doc called claude-summary.md
Episodic Memory – Records of specific visual changes and code states so I could roll back if things went sideways. This was version snapshots plus another summary called visual-changes.md

Spiraling from Organization to Chaos

I tested this setup by building my personal website. My build sessions started strong, but I soon realized I’d only solved memory and not context management or token waste. Claude knew where we left off, but loading all that context consumed tokens upfront. As summaries and episodic files grew, I accomplished less per session before hitting limits and context rot. I only deployed successfully by keeping scope extremely tight between sessions.One thing became abundantly clear: I needed a new approach to manage Memory, Context, AND Tokens simultaneously.

I was reminded of the Chinese proverb:

“If you ignore the dragon, it will eat you. If you try to confront the dragon, it will overpower you. But if you ride the dragon, you will take advantage of its might and power”

To make Claude Code work for me, I had to ride the dragon. That meant going into research mode and find out how. I decided to do what I do best: approach this as a product manager and identify the main problem areas that I needed to solve. I analyzed my build process: reviewing token consumption, productive time per session, and episodic memory files.

The token consumption math was brutal, and better expressed by this visual.

To put things into perspective: It took 46 sessions to deploy the site, with severe struggles near the end.

A Shared Pain

Token consumption analysis confirmed my suspicions, but analyzing session summary data files revealed deeper issues. Beyond memory, context, and token management, I also needed to solve: implementation inconsistency, decision persistence, proactive monitoring, and standardized handoffs.

But then I was like: Hold on, I’m but a fledgling in this arena. Surely I’m not the only person to identify these problems. What are the others doing? A few nights of doom-scrolling Reddit communities like r/ClaudeCode confirmed I wasn’t alone. Builders faced identical challenges:

“Anyone else losing their mind with token limits?”
“How are you guys managing your sessions? I’m getting rate limited in 15 minutes, this is beyond unusable”
“I’m so done with this. I’m seeing three different implementations for similar APIs in three different sessions. I don’t know who thinks AI can replace humans”
“I spend more time bringing Claude up to speed at the start of every session than actual coding. By the time he’s ready to start coding, my conversation gets auto-compacted”

I found that unlike me, seasoned developers were already aware of these issues. Some used elaborate documentation methods that hit the same limits I did. Others kept detailed session notes that created historical records but couldn’t intelligently surface relevant information. Some tried summarizing previous sessions to save tokens, but lost critical implementation details. Others built external memory tools that helped with memory and context but lacked automated entry/exit points and didn’t formalize patterns, leaving inconsistent implementations unaddressed.

I also explored promising frameworks like claude-mem & BMAD-Method but they solved specific problems without addressing all the issues together.

Brainstorming

The AI-assisted coding community (developers & product designers) clearly faced significant, persistent problems that needed addressing. As a product manager who’d experienced these issues firsthand, I understood the problem space deeply. I saw that existing solutions tackled issues in isolation rather than holistically, and understood why. Engineers often focus on specific problems with low-effort solutions, missing the bigger picture. Product Managers often envision solutions without considering technical feasibility. With my product management and engineering background, I was uniquely positioned to conceptualize a framework that solved these issues holistically while remaining technically feasible, extendable, and accessible to both developers and product designers. Even if I didn’t succeed in coming up with something, I felt I needed to at least try.

I researched solutions systematically, using Claude Opus as a brainstorming partner, ironically using Claude to design a memory system for Claude Code.

Phase I: Solidifying the Layers

The most crucial insight that I gleaned in the first phase of my research was understanding in broad swathes the main pillars that could manage memory & context effectively.

Persistent Knowledge: Critical information (technical decisions, architecture, requirements) that was sacrosanct and must persist indefinitely. This would be the foundational layer
Reusable patterns: Standards (coding conventions, implementation approaches, quality gates) applied consistently across similar tasks. This would be the consistency layer
Focused Execution: Work with clear boundaries and minimal context to prevent scope creep and token waste, This meant well-defined criteria, dependencies, standards, knowledge references, automated context monitoring and session handoff protocols. This would be the execution layer

Implementing just one or two of these systems would create an incomplete solution. They needed to work together as an integrated whole.

Phase II: Exploring the Layers

With the three-layer concept, I explored each layer’s contents and interactions through brainstorming sessions with Claude. This yielded an initial architecture: four interconnected pillars powering the system.

Knowledge Bases for persistent project memory. Every decision, architectural choice, and business rule documented with rationale. Future sessions load only relevant knowledge.
Workpackages for focused units of work with clear scope, explicit dependencies, and specific context requirements, solving token exhaustion by loading only what’s needed.
Tools to encode reusable patterns. Instead of hoping for consistency, tools explicitly define “how we do X in this project.” Modular, reusable, and shareable.
Agents as focused experts for specific tasks rather than a generalist trying to remember everything.

I then pondered over the inter-connectedness of this system and their overall impact on context management debating some key questions & solutions to them.

What separates knowledge bases from tools? How do we scope workpackages? Are layers hierarchical or networked? Do knowledge bases need categories? How do we prevent information bloat? How do we ensure only minimal required information is loaded per task?

This process helped further define each layer more clearly and establish their relationships.

Knowledge Bases are structured repositories with templates for different knowledge types. Each captures decisions, rationale, alternatives considered, and tradeoffs accepted.
Workpackages are complete specifications with dependencies, context requirements, success criteria, and agent assignments, representing unique units of deliverable functionalities.
Tools are executable patterns with metadata, examples, and integration points. They’re modular – add or remove without breaking the system. They are used by agents and referenced in workpackages
Agents are invoked via workpackage specs or intelligently based on tasks. They can use tools, which can reference sub-agents to achieve objectives.

Phase III: Integration & Workflow

With the relationships between the four cogs fully defined and a deep idea of how these cogs would work together, I dove into further detailing out the core characteristics of this framework.

This resulted in the formulation of the key design decisions & principles that would form the bedrock of this this framework.

Session Management: Each AI-assisted code sessions would need intelligent monitoring. The framework should track token usage and trigger handoff protocols before limits are hit. This would require some some custom monitoring code that could hook into Claude’s progress systeam & monitor it passively in the background, triggering appropriate documentation and session handoff protocols once token consumption crossed a certain threshold.
Progressive Context Loading: Not every session would need full context. The framework should load context progressively: start with minimal essential information, add workpackage-specific context, then layer in relevant knowledge bases and tool calls automatically during development as needed.
Automatic Documentation: Developers shouldn’t need to manually update knowledge bases. The framework should detect when decisions are being made and prompt for documentation at natural points.
Cross-Session Continuity: Each session should know where the previous session ended and what the logical next steps are. This requires coordination between session management, workpackage tracking, and overall project plan management.

Phase IV: User Segmentation & Understanding Claude

With the framework conceptualized, I needed to identify my target user segments. With a plethora of AI-assisted coding platforms, all with users facing similar problems, I decided to focus on one segment first before expanding. I would have also preferred implementing a platform-agnostic framework, but I had limited resources as the single person working on this in my free time. I didn’t know if this framework was even implementable, let alone adoptable, and lacked time and resources for extensive user research & outreach across platforms. Most importantly, I was building this for myself to enable other personal projects. Given my travails with Claude Code, focusing on Claude Code users as the target user segment & platform became the natural choice.

After using Claude Code with a “learn as you use” approach, I realized I needed deeper platform knowledge to implement the framework. I found that the problems I was trying to solve were ones Anthropic had already recognized. This excellent blog post by Anthropic on effective context engineering practices served as affirmation for what I was trying to do.

I was quite excited to discover that for effective context engineering, Anthropic had equipped Claude with capabilities that aligned perfectly with the framework’s needs and could be leveraged to manage organization, memory and context.

Hooks: User-defined shell commands that execute at various points in Claude Code’s lifecycle. Hooks provide deterministic control over Claude Code’s behavior, ensuring certain actions always happen rather than relying on the LLM to choose to run them. Hooks allow even-driven automation.
Skills: Organized folders of instructions, scripts and resources that can be loaded dynamically to perform specific tasks that are repeatable and predictable. Skills operate on the core design principle of Progressive Disclosure, making them flexible & scalable, letting Claude information load information only as needed.
Custom Sub-agents: Specialized AI personalities that Claude Code can invoke to handle specific type of tasks. Each sub-agent has a specific purpose & expertise, uses its own context window separate from the main conversation, can be configured with specific tools, and includes a custom system prompt that guides its behavior.
Plugins: Allow extension of Claude Code’s functionality by adding custom commands, cubstom sub-agents, skills and hooks.
Token counting & monitoring: Determines token count in messages and monitors usage.
Native Session monitoring: Persistent session identifiers for git attribution and session management.

Phase V: Crystallizing the framework

I then set about formalizing how my framework would leverage Claude Code’s native capabilities.

Claude Code Hooks: Event-Driven Intelligence

Hooks would serve as the event-driven intelligence at the heart of the framework that would perform automated session management, knowledge base updates and workpackage status updates.

Native Session IDs: Traceability Without Overhead

Session IDs would enable Git commit attribution and organize session logs, creating a traceable history. Knowledge bases and workpackages would reference session IDs to track decisions and completions, while also enabling easy work resumption.

Skills: Progressive Disclosure for effective context management

Claude’s game changing skills feature with progressive disclosure would be extensively leveraged for repeatable tasks and to power sub-agents. A typical skills file load would look something like this:

YAML frontmatter – contains metadata, hook definitions and configuration. Always loaded
Core instructions & patterns in Markdown – always loaded
Examples library – contains extensive examples for effective leverage. Loaded only on demand when utilizing the skill
Reference documentation – contains detailed explanations and edge cases. Loaded only when needed
Scripts and tools – contains actual executable loaded. Loaded only when code execution or writing would be required.

Sub-Agents: Native specialization with independent context

Anthropic’s sub-agent system would provide native support for building & calling specialized agents that would work in their own context window, leveraging skills and pulling reference documentation and resources as defined in each workpackage.

Knowledge Bases, Session Summaries & Workpackages: The persistent memory

Auto-maintained knowledge bases, session summaries, and workpackages would serve as long-term and episodic memory. Skills or sub-agents would load specific sections just-in-time with minimal context.

Plugin Architecture: Seamless Integration

Finally, the framework would be distributed as a Claude Code plugin on the Claude marketplace instead of being offered as an external CLI tool, leveraging Anthropic’s native support. This would also enable native distribution & seamless updates to users.

Phase VI: Naming & Identity

The final phase was naming the framework. After brainstorming with Claude, I settled on CLEAR (Context Layered Engineering for Agentic Resources), capturing the clarity when chaos becomes manageable.

But there was something deeper. In Claude Code and terminals, the /clear command means one thing: wipe everything. Clear the screen, memory, and context. It represents erasure and starting over with nothing.

The CLEAR Framework inverts that meaning entirely. Instead of /clear meaning “memory gone,” CLEAR would now mean:

Clarity of memory – decisions preserved and accessible
Contextual clarity – relevant information surfaced automatically
Clear continuity – seamless flow between sessions

Conclusion

And that is the origin story of CLEAR, a framework conceptualized for working efficiently with Claude Code. Putting it all together, this is how the CLEAR framework would be powered by Claude Code’s native capabilities.

The core of the CLEAR framework

result in the framework meeting its design principles.

Now that the framework is conceptualized and formalized, I’m excited to move forward with implementation! I’ll be switching over to my trusted Claude Sonnet 4.5 and VSCode to bring this to life. I won’t be just building it, I’m going to use it right away for a sample project and then for all my future personal projects. You know, like the term Microsoft’s Paul Maritz made famous back in 1988: “Eating our own Dogfood“

If things go well with the framework, I’m looking forward to adding some cool enhancements down the line: things like graph search capabilities to track and find those informal decisions we make along the way, plus a bunch of other specialized sub-agents beyond the core ones.

I’d really love to hear what you think about this framework! Feel free to share any thoughts, feedback, or even criticisms you might have; I’m all ears!