AI Portfolio
Digital Rebel Brain
A second brain in Notion plus Claude skills that share its context

The Problem
Every AI session starts cold
The biggest hidden cost in working with AI as a solopreneur isn't the model — it's the re-onboarding. Every fresh session starts with no memory of my ICP, no sense of my brand voice, no awareness of what's already in my pillar plan, no read on which post structures have worked.
Without a shared context layer, every Claude session asks me the same questions. "Who's your audience?" "What's your tone?" "What have you already published?" Five minutes of context-setting before any real work. Multiplied across a week, that's hours.
And worse, the answers drift. One session gets a slightly different version of my ICP than the next. The work starts to sound like five different consultants wrote it.
The Solution
Every conversation goes through the brain first
Every Claude conversation — regardless of which instance, which model, or which project — starts by reading the Second Brain. That's the rule. Before an agent drafts a post, scores a prospect, picks today's task, or critiques a wireframe, it queries the brain in Notion to understand who I am, what I'm working toward, what's worked recently, and what's currently in flight.
The brain is in Notion. Claude reads it via the **Notion MCP server** when a session needs context. For a few load-bearing pieces — current ICP, content patterns, weekly performance data — I keep a local markdown version on my Mac so the skills that read them every single run can do it without a round-trip.
The result is the part that matters: every session sounds like me, lands in my voice, and reflects what I've actually published instead of guessing. No re-onboarding, no drift, no five-minute brand briefings before real work starts.
All skills live as folders on my Mac in `~/my-demos/digital-rebel-skills/`. Each has a `SKILL.md` describing when to use it, what it reads from the brain, and what it produces. Claude Code loads them from disk as slash-commands.
The same folder is also a GitHub repo — backup, version control, and the ability to roll back when a skill change breaks something downstream.
The stack today (90+ skills)
- **Content:** Content Refinery, Humanizer
- **Operations:** Research Radar, Daily Briefing, PM Brain
- **Discovery (~30):** assumption mapping, interview scripts, summarization, JTBD canvases, opportunity-solution trees, customer journeys, market segmentation, ICPs, value propositions, sentiment / cohort / funnel analysis
- **Strategy & GTM (~20):** product strategy, vision, positioning, GTM motions, market sizing, beachhead segments, pricing, monetization, competitive battlecards, PESTLE, SWOT, Porter's Five Forces
- **Planning & writing (~15):** PRDs, user stories, job stories, WWAs, OKRs, sprint plans, retros, release notes, launch checklists, agent task briefs, stakeholder maps
- **Design (~10):** design systems, design principles, UX writing, IA, wireframe critique, service blueprints, storyboards, mobile-app specs
- **Engineering (~14):** frontend and backend builders, system architecture, tech-stack selection, API contracts, data models, CI/CD, code review, error handling, monitoring, refactor plans, test strategy, ADRs, incident postmortems
Every skill that touches content, strategy, or prospecting reads from the Second Brain before doing anything.
How operating-model thinking plays out in real engagements
Further reading
Fixing Your Product Operating Model Might Break Everything Else
What happens when product speeds up and nothing else does? Introducing SBOM, the Systemic Business Operating Model that keeps the organization moving.
Your Operating Model Is Either Enabling or Killing Your Strategy
Most strategies aren't strategies. The ones that are still fail, because nobody changed the structure underneath. Operating models are the missing layer.
Your Budget Structure Is Your Real Operating Model
When every function optimizes inside its own budget line, the work between teams gets no owner. That's not a people problem, it's a design problem.
Get the next article in your inbox
Short, practical notes on strategy execution, operating models, and the structures that decide whether a transformation actually changes how teams work.
