Website of Peter Westerman

Over twelve months of building twenty products, an enormous volume of knowledge accumulated: which patterns worked and which failed, how to handle recurring technical problems, what the conventions were for each component type, what architectural decisions had been made and why they were made that way rather than the obvious alternative. Most of that knowledge lived in chat transcripts, personal memory, and the implicit patterns visible in code — three of the worst possible storage mechanisms for knowledge that needs to be transferred, referenced, applied consistently, or shared.

Knowledge in chat transcripts is not searchable except by reading. Knowledge in personal memory is inaccessible to AI collaborators unless explicitly stated in every session. Knowledge implicit in code requires reading the code to extract, and even then does not capture reasoning — only decisions. None of these formats produce the compound returns available from knowledge captured in a structured, maintained reference document that travels into every AI session as usable context.

The Personalized Coding Playbook was built to change this. It is a living document that captures the accumulated learning of the entire practice — organized for AI reference use, maintained session by session, and designed to make every future AI collaboration session better than it would be without it.

What the Playbook Contains and Why

The structure of the Playbook reflects deliberate decisions about what knowledge compounds most effectively when captured systematically.

The technology stack section is specific and opinionated — not a generic PHP or WordPress reference, but a description of the exact choices made for this portfolio and the conventions adopted within them. “All plugins use PHP 8.0 minimum, follow PSR-12 naming conventions, use WordPress Coding Standards for WordPress-specific patterns, and follow the singleton pattern for main plugin classes.” This specificity makes the section immediately actionable for AI sessions starting new products.

The architectural patterns section documents the structures that appear across multiple products: the singleton pattern for plugin main classes, the RAG architecture for knowledge-augmented AI products, the WordPress plugin structure that all plugins follow, the PWA architecture for progressive web applications. Each pattern entry includes a clear description, a code example from an existing product, and cross-references to the products that implement it. The cross-references make the documentation verifiable — you can always check what a pattern looks like in production, not just in description.

The API integration section is organized by external service, with the standard integration approach for each service, annotated examples from existing products, and the common error scenarios and their resolutions. This section directly reflects the Shared Library — it documents how to use the shared components correctly rather than how to build them from scratch. After the Shared Library was in place, new products could start a Claude API integration session by simply referencing this section rather than working through the integration from first principles.

The debugging and testing section is the highest time-value section per word. Common failure modes with their symptoms and resolutions, debugging approaches, tools, and lessons from specific debugging incidents. A problem that took three hours to diagnose and fix the first time takes ten minutes when the session references the Playbook section describing exactly that failure mode. The return on documenting each hard-won debugging insight is very high, because every future encounter with the same issue avoids the full diagnostic process.

V1 to V2: The Reorganization for AI Reference

The Playbook’s first version was written as a learning document — a curriculum for someone wanting to understand the codebase and its patterns from the beginning. The organization followed a pedagogical logic: start with fundamentals, build to advanced patterns, connect everything with narrative explanation. This worked well for human reading. It was suboptimal for AI reference during sessions, where the need is to look up a specific convention quickly rather than to understand a comprehensive curriculum.

Version two was reorganized around a different primary use case: fast, specific lookup during a build session. The reorganization principles that made the largest difference:

Conventions before explanations. State the convention in one sentence before explaining it. The AI needs the convention to apply; the explanation is context that aids understanding but should not block access to the convention itself.

Code examples immediately after convention statements. Not descriptions of code — actual code, annotated. The AI can parse and apply a code example faster than it can parse a prose description of the same pattern.

Cross-references to existing implementations. Every pattern links to the products that implement it. “See the GD Chatbot plugin (gd-chatbot/includes/class-rag-engine.php) for a complete implementation of this pattern.” This makes the Playbook self-verifying — any AI session can look up the pattern and then look at the actual implementation to verify it understands the application correctly.

Decision records for non-obvious choices. “Why we use the token bucket approach for rate limiting rather than fixed window: fixed window allows burst traffic at window boundaries that can overwhelm API rate limits in practice.” One sentence. Captures reasoning that the code itself cannot convey. Prevents future sessions from accidentally reversing a decision that had good reasons behind it.

Building Your Own Playbook

The Playbook concept applies to any knowledge work domain where practice knowledge accumulates and compounds value when captured systematically. A management consultant’s equivalent might be called a methodology library: standard frameworks for different engagement types, common client patterns and their implications, lessons from previous engagements organized by situation type. A financial analyst’s equivalent might be a modeling playbook: standard model structures for different asset types, common error patterns and their detection, preferred data sources for specific inputs.

The structure that works regardless of domain: organize by task type rather than by time period. Not “what I learned in Q3” but “how I structure a competitive analysis” or “the standard approach for a cash flow model.” Task organization is faster to look up and easier to maintain than chronological organization. The goal is a reference you can navigate in under thirty seconds to find what you need during a session, not a diary that tells the story of your professional development.

Include both the what and the why. Conventions alone produce consistent behavior. Conventions with their reasoning produce intelligent behavior — AI sessions that understand why a convention exists will apply it appropriately, including knowing when a situation is genuinely exceptional and the convention should be adapted rather than followed. The reasoning is the most easily lost knowledge in any practice; it is also the most valuable to preserve.

The maintenance cadence that produces the best results: a brief Playbook update at the end of every significant project, while the learnings are fresh and the decisions are recent. Five to fifteen minutes per project. Over twenty projects, this produces a comprehensive, current reference that reflects actual practice rather than remembered practice. The difference between documentation written from recent memory and documentation written from memory six months later is the difference between a reliable reference and a reference that is accurate in the obvious cases and wrong in the subtle ones.

The Playbook as a Transfer Document

A specific use of the Playbook that proved unexpectedly valuable: as a transfer document when bringing new AI assistance to a project for the first time. Not a new person — a new AI session starting on a product that had been built over many months. Without the Playbook, each new session on a product required reading the existing code to understand what patterns were in use, what conventions had been established, and what architectural decisions had been made. That code archaeology process was slow and imperfect: code shows decisions, not reasoning.

With the Playbook loaded as context, a new session on a product could immediately apply the established patterns correctly. The Playbook told the AI what singleton pattern to use, what the database conventions were, how the admin panel should be structured, what the API integration patterns were. The session could begin with productive work rather than with pattern discovery. The transfer was immediate and accurate.

This use of the Playbook as a transfer document is a concrete demonstration of why knowledge capture matters in any practice. Knowledge that lives only in the practitioner’s head transfers slowly, incompletely, and at a high cost. Knowledge that lives in a well-organized reference document transfers instantly, accurately, and at essentially no cost. The Playbook made the AI an effective collaborator on any product in the portfolio from the first session, not after a ramp-up period. That value accrued every time a session opened on a product that had not been worked on recently.

The Living vs. Static Document Distinction

The Playbook only produces its intended value as a living document — one that is updated when the practice evolves, when better patterns replace old ones, when new integrations are added, when lessons from debugging incidents are captured. A static Playbook — written once and not updated — degrades in value as the practice evolves away from what the document describes.

The specific update triggers that kept the Playbook current across the twelve months: when a new pattern was established that should be the standard going forward. When a debugging incident revealed a failure mode that should be documented for future reference. When the Shared Library was updated in ways that changed the integration patterns. When a product was built using a new approach that improved on what the Playbook had documented.

These triggers are not frequent — perhaps once or twice per month on average. Each update takes fifteen to thirty minutes. The cumulative maintenance investment across twelve months is approximately five to ten hours. The return is a Playbook that remains accurate, useful, and value-producing across the entire year rather than for only the first few months. The maintenance investment is among the highest-ROI activities in the practice, measured by value produced per hour invested.

How Recent AI Innovations Change This Picture

The personalized playbook described in this post — a documented, systematized knowledge base encoding the patterns, preferences, and conventions of the AI collaboration practice — was built and maintained manually. Recent AI platform innovations provide direct infrastructure support for this kind of knowledge system, and the implications for how to build and maintain it are significant.

Agent Skills are the platform-formalized version of the playbook concept. The playbook content described in this post — coding patterns, architecture decisions, naming conventions, error handling preferences, testing standards — is exactly what Agent Skills are designed to encode. Rather than maintaining a markdown document that must be manually loaded into each session, a Skills-based playbook is version-controlled, portable across Claude applications, and automatically loaded when relevant.

The composability of Agent Skills changes the granularity of the playbook. The original playbook was essentially one large context document, loaded entirely whenever the AI needed any part of it. Skills can be composed selectively: a frontend session loads frontend skills; a backend session loads backend skills; a debugging session loads debugging skills. The AI gets the specific knowledge it needs for the current task without being loaded with unrelated context.

Organizational skill management — available through Anthropic’s enterprise platform — extends the personal playbook concept to team scale. A playbook built as an individual knowledge system becomes an organizational asset when formalized as managed Skills. New team members get the same AI collaboration context as experienced ones. The knowledge embedded in the playbook is no longer dependent on individual humans who built it; it is accessible to anyone with access to the organizational skill library. For organizations deploying AI at scale, this changes how institutional knowledge about effective AI collaboration is preserved and transmitted.