Methodology Template¶
How to use this template¶
Copy this file when authoring a new methodology document. Replace the placeholder content in each section with the manager's actual operating reality. Keep the seven-section structure — that's what makes the documents consistent across the library.
The template below shows what each section should contain and gives examples of good vs. bad content.
Two document types¶
This template covers manager methodology documents — the operational reality of a manager role (e.g. wdm-website-build.md, it-manager.md). Manager methodologies follow the seven-section structure below.
The library also contains task methodology documents — procedures for a specific kind of work that compose on top of one or more manager methodologies (e.g. wdm/tasks/audit-existing-site.md). Task methodologies have a different shape because they ARE the playbook for a specific situation rather than the framing for a whole role. A task methodology should include:
- Purpose & when to use — what the task is, and the trigger conditions (the recognition layer that lets the manager invoke it)
- Universal core — the procedure that runs every time, regardless of the situation's specifics
- Situational lenses or branches — how the procedure changes based on the situation's classification (e.g. site type, deal size, urgency)
- The procedure itself — step-by-step, ordered, actionable
- Composition references — which manager methodologies this task reads on top of, and which other task methodologies it may compose with
- What this doesn't cover — explicit non-goals and bounded scope, so the task doc doesn't sprawl
- Failure modes & non-fabrication rules — what the task should refuse to do (e.g. fabricate numbers, fabricate citations) so the procedure stays honest
Task methodologies live at methodology/<role>/tasks/<task>.md. Each task doc references the manager methodology it composes with. A task doc without a manager-methodology composition reference is suspect — most real work is task-level execution within a role-level operating reality.
The remaining template below is the manager methodology template.
[Manager Name] — [Domain]¶
1. What this manager builds¶
A concrete description of the operational domain. Not the charter (that lives in shared memory), but a working description of what gets produced.
Example (good): "WDM builds public-facing websites for enterprise entities. This means: a Tailwind-based design system applied to entity branding, a Supabase-backed admin area for content management, a Cloudflare Pages deployment, and a custom domain via Cloudflare DNS. Photo capture, inventory display, contact forms, and admin authentication are standard features. Each site is single-file HTML where possible, with progressive enhancement via vanilla JavaScript."
Example (bad): "WDM is responsible for the website needs of the enterprise."
The bad version gives the manager nothing to work with. The good version describes the actual artifact in terms the manager can recognize and produce.
2. Trigger patterns¶
The most important section. What does Brandon or another manager say that means "execute this playbook"? What's the immediate first action? What should the manager NOT ask about?
Format each trigger pattern as:
Recognition signal: What the request looks like — phrasings, contexts, situations
First action: What you do immediately upon recognizing the trigger, without further direction
What you don't do: The questions you don't ask, the clarifications you don't request, the default assumptions you proceed with
A methodology document may have multiple trigger patterns (e.g., "build new website" vs. "modify existing website" vs. "redesign existing website"). Each gets its own trigger pattern block.
Why trigger patterns matter
A manager with documentation but no trigger patterns waits for step-by-step direction. A manager with trigger patterns recognizes the work, treats it as familiar, and executes. The Salt Lake City WDM experience showed that having documentation alone doesn't produce action — the recognition layer has to be explicit.
3. Default assumptions¶
What the manager should assume is true and NOT ask about. These are the answered questions that don't need to be re-litigated each time.
Example (good): - The design system uses Tailwind core utility classes only (no compiler, no plugins) - Typography is Inter (body) + JetBrains Mono (code) unless the entity has a documented brand exception - Deployment target is Cloudflare Pages unless documented otherwise - Database is Supabase; admin authentication uses Supabase Auth - Single-file HTML preferred for simplicity; React only if the entity has documented React infrastructure
Example (bad): "Follow the standard patterns."
The bad version forces the manager to figure out what's standard. The good version says exactly what's standard so the manager doesn't have to ask.
4. The playbook¶
Step-by-step, in order, what the manager does when the trigger fires. This is the operational core.
The playbook should be specific enough that a fresh Claude instance can execute it. It should reference canonical examples by path or URL. It should name the tools, frameworks, and patterns by name.
Example structure:
- Read the canonical example source at [path]
- Note the patterns: [specific patterns to confirm]
- Determine what's entity-specific vs. framework-standard
- Create the new entity's surface adapting only the entity-specific elements
- Deploy via [specific deployment command/process]
- Verify [specific success criteria]
- Report completion via [specific channel]
Each step should be actionable, not aspirational.
5. Canonical examples¶
Links to working artifacts that demonstrate the pattern. The manager can study these directly to confirm they understand the playbook.
Example:
- cactustruckparts.com — the canonical CTP storefront with Supabase admin
- seq-www repository — the canonical SEQ-WWW codebase
- [path to design system reference document]
- [path to deployment script]
Each canonical example should be live, accessible, and recently confirmed working. Stale examples become liabilities (the manager copies a pattern that no longer works).
6. Failure modes¶
What has gone wrong before. Why it went wrong. How to avoid it.
This section is what makes the methodology honest and reusable. A sanitized "everything works" document breaks the moment someone tries to apply it. A document that names the failures upfront prepares the next person to avoid them.
Example entry format:
Failure: [What went wrong, in concrete terms] When it happened: [Date, context] Why it happened: [Root cause analysis] The fix: [What changed in the playbook to prevent recurrence]
Failures aren't embarrassing. They're data. The methodology document is more trustworthy with failure modes documented than without.
7. When to escalate¶
The genuine four-test failures that require principal input. Most work doesn't need escalation — the playbook handles it. But some decisions genuinely need Brandon (or another principal) to weigh in.
Example (good):
- New entity has no documented branding — escalate for color palette, typography exception, logo source
- Entity is for an external client (framework-as-product deployment) — escalate before deployment for licensing and billing structure
- Entity has regulatory constraints unfamiliar to standard framework (e.g., HIPAA for a healthcare-adjacent business) — escalate for compliance scoping
- Cost of deployment exceeds standard budget (e.g., custom domain with premium TLD) — escalate for budget approval
Example (bad): "Escalate if you're unsure."
The bad version makes everything escalation-worthy. The good version names the specific situations that genuinely warrant principal attention so everything else can proceed without it.
Updating the template¶
When a methodology document reveals a section structure that doesn't fit the seven-section template, the template gets updated, not the document. Consistency across documents is what makes the library work as a bootstrap package.
If a manager's domain doesn't have meaningful content for a section (e.g., a manager that has no documented failure modes yet), the section stays in place with a note like "No failure modes documented yet — pending operational experience." Empty sections are honest; missing sections create inconsistency.
Template. Last updated 2026-05-30 by chat-MC1.