How the Skills Are Built

Every skill in the catalog goes through the same six-step build process before it ever lands in a customer’s workspace. The process is deliberate. It is adversarial in places. It exists because change management is deeply human work, and the practitioner using the skill is the one who carries the professional risk if the output is wrong.

The six-step build process

1. Identify the repetitive task. Every skill starts with a real deliverable that a change practitioner produces over and over: a stakeholder map, a resistance diagnostic, a communication cascade, a training needs assessment. The current state gets documented first. How is this actually done today? What does the output usually look like? What takes the most time? Where does quality break down?

2. Adversarial spec review with Claude.The current state and the wish list for the skill go into a working session with Claude. Claude gets asked to play bad cop. Push back on every assumption. Challenge every “the skill should also do X” idea. Test whether the ambition is realistic or whether it will produce a bloated skill that does nothing well. Most skill ideas get cut down at this stage. A few get expanded.

3. Product specification. The skill gets specced out as a product. What does the practitioner get at the end? How does that output change the value they add on the engagement? What edge cases matter? What frameworks does the skill map to? What has to stay out of scope to protect the quality of what stays in?

4. Build a test skill. The first working version gets built. Not a final skill. A test skill. Rough, structurally sound, ready to be broken.

5. Adversarial testing. This is where the process gets brutal. Other AI tools are used to generate a wide range of realistic inputs: messy stakeholder scenarios, contradictory data, half-finished briefs, real-world edge cases. Each input gets fed to the skill. The outputs get inspected. Anywhere the skill produces generic filler, structural drift, or a weak framework application, it gets flagged and reworked.

6. Lock it in. Only after the skill produces consistently strong outputs across the full test range does it get finalized. The final version carries the discipline that came out of the previous five steps. That is what ships to customers.

Output formats the practitioner actually needs

Every skill asks the user which format they want the output in. Word, PowerPoint, Excel, or a combination. Some skills produce multiple required formats by design. The Training Needs Assessment always produces a spreadsheet, then asks whether you want the narrative in Word or PowerPoint. The stakeholder and impact skills produce structured data plus a written brief. The communication skills produce edit-ready drafts.

Practitioners do not have to reformat anything. The output arrives in the shape it needs to be in for the way the work actually gets used inside an organization.

Human in the loop is the design principle

Change management is deeply human work. It cannot be automated. What the skills do is compress the assembly time on the structured, repetitive parts of the work so the practitioner has more time and mental energy for the parts that actually require human judgment and stakeholder engagement.

Every skill assumes the practitioner will review, edit, and adapt the output. That assumption is built into how the skills are structured. Outputs come formatted for review, not for shipping unedited to a client. Judgment checkpoints are called out inside the outputs where the framework demands practitioner interpretation. The practitioner drives. The skill supports.

That is why the six-step build process matters. A skill that produces predictable, structurally sound output that a senior practitioner can review and sign off on is doing exactly what it should. A skill that produces polished-looking output the practitioner is tempted to ship without reading is a liability. The build process is designed to produce the first kind and never the second.

Shifting the workload ratio

Every change practitioner knows this feeling. The analysis and assessment work eats the calendar. Stakeholder mapping. Impact discovery. Readiness assessments. Training needs. Communication drafting. All of it necessary. All of it time-consuming.

Meanwhile the engagement work with leaders, project teams, and impacted stakeholders is what actually drives adoption. Deep engagement is what produces the ROI the sponsor is paying for. And engagement always feels underweighted compared to what the change deserves.

The skills shift that ratio. When the assembly work on a stakeholder map compresses from twelve hours to ninety minutes, those ten and a half hours do not disappear. They redirect to the conversation the practitioner needed to have with the VP of Operations two weeks ago. That is where change actually happens.

Catalog architecture: the layer underneath

Every skill in the catalog can be used on its own. But the catalog was also engineered as a coherent system, and that engineering shows up in three places a buyer’s due diligence team will care about.

Clean IP boundaries per skill. Each skill has defined, documented ownership of its proprietary methods. The Change Narrative Architect owns Shadow Narrative detection and Truth-Anchor construction. The Change Impact Translator owns the Three-Box Framework and WIIFM generation. The Multi-Channel Cascade Mapper owns Core Message Lock. When a concept appears in more than one skill, ownership is explicit and cross-references are documented. This matters for licensing due diligence and for any future IP transfer.

Public methodology is attributed, not claimed. Where a skill uses public or third-party frameworks (Prosci® ADKAR®, Mendelow’s Power-Interest Grid, Kotter’s 8 Accelerators, the McKinsey Influence Model, APMG/CMI Practice Areas, Campbell’s Hero’s Journey), the attribution and non-affiliation is explicit inside the skill. The catalog does not attempt to trademark other people’s work.

Cross-skill handoffs are engineered, not accidental. When one skill produces an output that another skill uses as input, that handoff is designed and documented. A Stakeholder Landscape Mapper output feeds cleanly into a Change Narrative Architect run. A Change Impact Translator output feeds cleanly into a Training Needs Assessment. The catalog was built as a set of skills that work together, not as a folder of independent files.

What this means for the buyer

A firm licensing this catalog is not licensing 14 disconnected Claude skills. It is licensing a coherent, architected system built by a practitioner who spent 30 years learning what good change management looks like, then spent months figuring out how to compress the mechanical work without touching the human judgment.

The skills do the assembly. The practitioner does the change management.

That is the whole design.