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. The surfaces group into three kinds.

Where the work lives.

companies/ holds active company profiles, notes, assessments, and project work. Closed or disqualified engagements move to companies/archived/ and become read-only reference.
clients/ holds working relationships with individuals rather than companies: coaching clients, personal operating-system deliveries. The same conventions as companies/, scaled from an organization down to a person.
builds/ holds the live builds: the actual deployable code repositories, each one a Git submodule. The code lives there. The thinking behind it (specs, briefs, decisions) stays in the company or client project folder, with a pointer connecting the two.

Where the method lives.

systems/ holds the shared methodologies: strategy, voice, content conventions, the deck system, the framework behind the operating-system engagement, and maintenance. These load when reasoning about approach matters.
skills/ holds nineteen executable Claude Code workflows, each with a SKILL.md. Intake (inbox triage, prospect intake, capture from a phone), engagement (strategic assessment, meeting prep, time logging), writing (voice revision, voice recalibration, collaborative drafts), upkeep (session close, the maintenance loop, the weekly digest), and the seven that drive the build loop described below.
plugins/ holds the machinery packaged for use outside the vault. More on that near the end.
open-source/ holds the please-family frameworks and the external repos they hand off to, each one a submodule.
docs/ holds the conventions that grew long enough to deserve their own file: file classification, engagement lifecycle, routing, and model routing.
knowledge/ holds non-client research, frameworks, and references.

Where the running of it lives.

inbox/ is a drop zone for unstructured input: voice notes, transcripts, brain dumps. A triage skill classifies and routes everything to the right place, then deletes the source.
improvements/ is where I write down what was awkward about a skill run, right after the run. It is the raw material the maintenance loop reads, so sharpening a skill starts from real signal instead of a guess.
time/ holds time tracking as plain JSONL, one file per month.
weekly/ holds the Monday digest output.

There is one ACTIONS.md at the root and one inside each company and client folder. I write to those and so does Claude.

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.

What the AI can touch on its own

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. Claude and I both 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.

Where things go

For about a year this section described a split between the vault and Notion: the vault for thinking and producing, Notion for tracking and transacting. That split is gone. I retired Notion as a studio system in July 2026, and the honest version of what happened is that the split was never as real as it read. The prospect-intake skill had Notion database IDs written into it from the day it was created, and every one of them was a placeholder. That pipeline never ran once. I had documented an integration I did not actually have, and it took a year to notice, because a documented system that nobody exercises looks exactly like a working one.

What is true now is simpler: git-backed markdown in one repository, unless a client's own tooling requires otherwise.

Time and billing live in time/, as JSONL. Less pretty than a database view, and readable by everything, including Claude.
The pipeline is the directory structure. A prospect is a folder, and its stage is whatever its files say. There is no separate system to fall out of sync with.
Collaborative drafts, the ones meant to be worked on with someone else, go to Proof. A share link is bearer access rather than a permission, so nothing client-confidential goes there.
Client-facing shared documents live in whatever the client already uses. The repo holds the source; the shared copy is an export, not a second home.

The rule the old split was reaching for was always the right one. It just states more simply now: one place, version-controlled, readable by the assistant and by me in the same form.

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, became a set of skills, and has now shipped a real product.

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 loop has since shipped its first real product: the app behind the studio subscription, built batch by batch with this orchestration and now running in production. That app is also where client work gets delivered. When an operating-system engagement produces a deliverable, I publish it from Claude Code straight into the client's workspace in the app, with the status update and the email notification handled in the same step. The vault is where the work gets made; the app is where it lands.

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.

Which model runs which job

Every role in the system is pinned to a model tier, and the pinning is written down rather than assumed. The main session and the implementer run on the strongest tier, because correctness dominates cost. The learner, which is read-only with bounded output, runs a tier down. Bulk classification and extraction, where the work needs no world knowledge, runs a tier down again.

The interesting one is the validator, and it is the reason that file exists at all. During an early build, the validator quietly changed tiers between batches. Nobody decided that. It just happened, and nobody checked whether the verdicts stayed comparable afterwards. So I ran the comparison properly: the same twenty-three-item checklist against the same batch, two tiers, in separate checkouts, neither able to read the other's report.

They agreed on twenty-two of the twenty-three items, and on all seven cross-cutting checks. Every mechanical check was indistinguishable between them. They split on exactly one item, and it was the only one that required weighing something rather than measuring it: a product non-negotiable on a customer-facing screen. The cheaper tier resolved it in the implementer's favor. The more expensive one resolved it against.

That disagreement is the entire reason an adversarial validator exists, so that is the tier it gets. The generalizable version: validation is mostly mechanical work a cheaper model does perfectly well, plus a small part that is the whole point of the role. Cost was not the deciding factor here and could not have been, because both runs used roughly the same number of tokens.

Underneath the routing sits a second discipline that matters more than the routing does: caching. Prompt caching is model-scoped and prefix-based, which turns three ordinary-sounding habits into real money. Do not edit the root context file mid-session, because it sits at the front of the cached prefix and changing it invalidates everything behind it. Hold the reasoning effort constant within a session. Do not switch models mid-session; spawn a cheaper sub-agent instead, which is what the tier table is for.

Packaging it so it leaves the vault

The build loop started as something I ran by hand in my own repository, which is the only way I would have trusted it. It is now an installable Claude Code plugin: seven orchestration skills, three role agents, and the checkpoint hook, with a marketplace manifest at the root of the vault so the whole thing can be installed into any repository.

The part I care about is how it is wired locally. The plugin directory holds the only copy. The vault reaches those skills and agents through symlinks, so there is no second copy to drift away from the first, and editing through either path edits the same file. The failure mode I was avoiding is the one where the public version slowly becomes a worse fossil of the private version, which is what happens every time you package something by copying it.

That is the same instinct as the please family, one level down. The frameworks give away the method. The plugin gives away the machinery that runs it.

Keeping the voice mine

The most fragile thing in an AI-assisted practice is not the data, it is the voice. I run three separate modes for writing, because they fail in different ways:

Generation. Writing something new under my name starts from a voice system: a document that encodes how I actually write, with named attributes and a banned-phrase list.
Editing. Revising a draft I already wrote uses a different skill, one that is preservation-first. Loading the generation system onto an existing draft pulls my real words toward the abstraction and overwrites my voice.
Recalibration. When something the system produced does not sound like me, I diff what is off, fix it, and log it. Only the patterns that repeat get codified back into the voice system.

The split between generation and editing came from watching the first mode quietly rewrite drafts it was only supposed to tighten. That is the improvements loop doing its job.

What runs without me, and what does not

A few things now run on their own, and one deliberately does not:

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.
A Monday digest, on demand. 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 run it by hand. Wiring it to a schedule is a five-minute job I have deliberately not done, because the manual version has not run enough times yet for me to know what it would do unattended. That is the rule from two sections ago, applied to itself. It will get a scheduler when it has earned one.

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.