How I work | Yes Please Studio

This document is intended to be shared with collaborators, partners, and people I want to work with. The most useful thing you can do with it is send it to your own AI and have a conversation about how my way of working relates to yours.

What this is

Yes Please Studio is my solo consulting practice. I help companies get clear on their positioning, audience, and growth strategy, then carry that clarity into the product and the go-to-market. I work with founders and teams directly through coaching, workshops, an operating-system engagement, a studio subscription, or a custom shape when none of those fit.

The document below describes how I have built the operating system behind that practice: the tools, the architecture, the philosophy, and what I am still building. It is not exhaustive. It is a map, not the territory.

The core setup

My operating environment is an Obsidian vault backed by Git, with Claude Code as the AI-native processing layer. These three pieces each do a specific job:

Obsidian. For reading and writing. I browse context, draft notes, and navigate between company and project files. I browse in Obsidian; I process in Claude Code.
Claude Code. For processing. It runs structured workflows, maintains systems, and does the analytical and generative heavy lifting. Everything Claude touches is file-based and Git-tracked.
Git. For versioning. Commits happen when I say so, never automatically mid-session. The vault is a repository: structured, auditable, and recoverable.

The folder model

The vault is organized so that the folder you open is the context you are working in. Five top-level surfaces:

systems/ holds the shared methodologies (strategy, voice, content conventions, maintenance). These are loaded when reasoning about approach matters.
skills/ holds executable Claude Code workflows, from inbox triage and meeting prep to the agentic build loop described below. Each has a SKILL.md.
companies/ holds active company profiles, notes, assessments, and project work. Closed or disqualified engagements move to companies/archived/ and become read-only reference.
knowledge/ holds non-client research, frameworks, and references.
inbox/ is a drop zone for unstructured inputs (voice notes, transcripts, brain dumps). A triage skill classifies and routes everything to the right place, then deletes the source.

There is one ACTIONS.md at the root and one inside each company folder. Both Eric and Claude read and write to these.

How context works

The vault is structured around a CLAUDE.md cascade. At every scope level (vault root, company directory, project directory) there is a CLAUDE.md file that provides context to Claude Code. Each level inherits from the one above it.

The folder I open Claude Code in is the scope I am working at. This is intentional. It is not just organization, it is context control. Opening Claude Code at the root means I am thinking across the studio. Opening it inside a project means I am thinking inside that engagement.

The file classification model

Vault files fall into three tiers. The tier determines whether Claude can modify a file autonomously, needs to propose first, or must never touch without explicit approval.

System files. Skills, methodology docs, conventions, templates. Claude can propose and apply edits during skill or maintenance work, always with a preview shown.
Collaborative files. ACTIONS.md, PLAN.md, SESSION-LOG.md, the inbox and improvements folders. Both Eric and Claude write here as part of normal workflow.
User files. Company profiles, notes, assessments, deliverables, personal notes. Claude reads freely but proposes any edit before writing.

The classification is what makes it safe to give Claude broad access to the vault while keeping client work and the calls that matter under my hands.

The open-source layer: the please family

Alongside the vault, I have been building a family of open-source frameworks called the please family. These are standalone tools designed to work together, each solving a specific problem in the consulting-to-build workflow. Each one has its own page under open work.

strategy-please is a workshop recommendation engine. It diagnoses strategic gaps and prescribes the right workshop.
prd-please is a PRD methodology. It translates strategy into a structured spec and decomposes it into executable tasks.
sales-please is a deal qualification framework. It scores opportunities so I know which ones deserve time.
voice-please is a voice system. It defines how a company sounds and operationalises that across content and AI tooling.
design-please handles design system scoping. It defines Look, Feel, and Act direction before any design work begins.
name-please validates and generates names. It evaluates names across six dimensions and delivers a verdict.
messaging-please maps messaging architecture. It builds the chain from purpose to per-audience messages to the GTM narrative.

Outside the please family, two more tools sit in the loop. Archgate governs architectural decisions during implementation, by codifying ADRs that get enforced in CI. Aldente is a phased build workflow for SaaS products. Both are open source and slot into the methodology flow below.

The consulting-to-build flow

When an engagement moves beyond strategy into product or technical work, the full sequence is:

Strategy assessment using systems/strategy/. Diagnose the company's maturity, identify the gap, define the right engagement.
PRD authoring using prd-please. Translate strategy decisions into a structured Strategic PRD. The skills run author then taskmaster then validator then learner.
Architecture governance using Archgate. Codify key architectural decisions as ADRs inside the client repository. Run archgate check in CI so the decisions are enforced, not just documented.
Build using Aldente. Execute the phased SaaS workflow with tasks derived from the PRD driving each phase.

Most engagements only use a piece of this sequence. Strategy-only and workshop engagements stop at step 1. PRD work without a build stops at step 2. Step 3 only applies when the engagement involves implementation and the architectural calls need to be durable.

How I think about automation

Build it. Use it. Trust it. Then automate it. No workflow gets codified until I have run it manually enough times to predict its output. No scheduled routine gets built until the manual version has run so many times it is obvious what it should do.

This is a reaction to a failure mode I keep seeing in AI-native setups: people automate processes they do not understand yet. The vault does the opposite. Skills emerge from practice, not from a design document. The improvements folder is where I write down what was awkward about a skill run, so the next maintenance pass can sharpen it from real signal instead of a guess.

The clearest example is the agentic build layer, which started as a single manual experiment and is now becoming a set of skills.

The agentic build loop

When the work is building software, one Claude Code session acts as an orchestrator. It does not write feature code itself. It reads the spec, briefs small background sub-agents to do one scoped job each, reads their reports, decides what happens next, and escalates the real forks to me. The sub-agents are disposable: each one cold-starts, does its piece, reports back, and is discarded.

The loop they run is fixed: implement, then validate, then learn, then apply, then commit, then implement again. A few rules make it safe to run that loop with parts of it on autopilot:

The implementer and the validator are different agents. The validator is adversarial and read-only. It checks the work against a list and reports defects without fixing them. A self-checking implementer misses the things it was already wrong about; a separate validator catches them.
Stop and surface, never invent architecture. When an agent hits a genuine design fork, it halts and asks instead of guessing past it with code that compiles but is quietly wrong. This one rule prevents the most expensive kind of failure: confident wrong work that passes every automated check.
Honest degradation. When an agent reaches a seam it cannot cross, it builds the surface, wires it to a documented contract, and degrades visibly. No fake success. The validator is told that a dishonest fallback is a hard failure.
Explicit file ownership. When several agents run in parallel, each gets a list of files it may write and a list it must not touch. That contract is what makes parallel work safe.

I ran this once, by hand, on a real product build before writing any of it down. That session is what taught me which parts to keep. The skills came after: a loop-state file so the loop survives a context limit, a brief template so I am not writing agent instructions from scratch each time, a context pack so agents read one curated file instead of re-reading the whole spec, a validator, a learner, and a decision-batch step that collects the calls only I can make into one package instead of interrupting me one at a time.

The principle underneath all of it is the same one I bring to client work: I stay the architect. The system surfaces decisions; it never makes the architectural calls for me, and it never hides what it did not understand.

Routines that run without me

A few things now run on their own, but only because the manual version proved itself first:

A Monday digest. Every Monday it reads every action list, every plan, and every unprocessed note across the vault, checks the open-source repos for upstream activity, and writes one scannable briefing of what is worth doing this week. I read it and decide; it does not decide for me.
On-the-go capture. When a thought arrives while I am away from my machine, I can capture it from my phone into the right company or project, and it gets filed, committed, and pushed without a later desk session to clean it up.
A checkpoint guard. A small hook refuses to let me end a session with too much uncommitted work, because a long unsaved session is how you lose a day's thinking. This one came straight out of the build loop, where thirty tasks once piled up with no commit behind them.

What routes to where

Not everything lives in the vault. The split between vault and Notion is deliberate.

Vault. Company profiles, assessments, notes, meeting transcripts, methodologies, skills, project deliverables. Anything that benefits from being in Claude Code's context window.
Notion. Time tracking and billing, pipeline and CRM, client-facing shared docs, invoicing. Anything that needs database views, rollups, or live shared editing.

The pattern is: the vault is for thinking and producing; Notion is for tracking and transacting.

What this connects to

The premise behind all of this is that a one-person consulting practice should be able to run at a quality level that does not scale down with capacity. The vault, the skills, the please family, the agentic build loop, and the routines that run without me are what make that possible.

The goal is to remove the friction between good thinking and useful output, and to make sure the context I need is always available when I need it.

If something here resonates, share this with your AI and ask how your setup compares. That is a better starting point for a collaboration conversation than a list of credentials. Or just get in touch.