System: MWMS
Document Type: Protocol
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, AI Business Systems Brain, AI Manager, AI Employee Router, Brain Room, Course Absorption System, Newsletter Intelligence, Opportunity System, Content Brain, Ads Brain, Sales Brain, Future AIBS Client Systems
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: No Development Action Authorized By This Page
Source Of Truth: MCR
Purpose
The purpose of this document is to define the MWMS AI Skill Builder And Audit Protocol.
This protocol establishes how MWMS decides when a repeated AI workflow should become a formal AI skill, how that skill should be structured, how it should be tested, how it should be maintained, and how it should be retired when no longer useful.
MWMS must not rely on repeated one-off prompting for work that happens again and again.
Repeated work must become reusable procedural intelligence.
A skill is not a prompt.
A skill is a governed way of doing work.
This protocol exists because as MWMS grows, the system will contain more Brains, AI Employees, workflows, client systems, dashboards, reports, task queues, course absorption flows, newsletter intelligence flows, offer evaluation flows, creative production flows, and developer handoffs.
Without a skill-building protocol, MWMS risks:
repeating the same instructions every session
creating inconsistent AI outputs
losing good workflows inside chat threads
building too many vague AI Employees
duplicating procedures across Brains
allowing skills to drift
allowing outdated rules to remain active
allowing skills to conflict with context libraries
allowing tools to be mistaken for skills
creating client-facing workflows before procedures are proven
The AI Skill Builder And Audit Protocol turns repeated MWMS work into reusable, testable, auditable operating procedure.
Scope
This protocol applies to all MWMS AI skills, reusable workflows, AI Employee procedures, and future client-facing skill systems.
This includes skills used by:
HeadOffice Brain
AI Manager
AI Employee Router
Brain Room
Task Executor systems
Course Absorption System
Newsletter Intelligence
Opportunity System
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Creative Brain
Sales Brain
Conversion Brain
Offer Brain
Operations Brain
AI Business Systems Brain
future AIBS client systems
This protocol applies when MWMS needs to convert a repeated workflow into a reusable AI skill.
It does not authorize technical build work, automation deployment, plugin changes, Supabase changes, WordPress changes, or M developer action.
Core Definition
An AI Skill is a reusable procedural playbook that tells an AI Employee how to perform a specific type of work correctly.
An AI Skill defines:
what work is being done
when the skill should be used
which Brain owns it
which AI Employee uses it
what input is required
what context is required
what steps must be followed
what rules must not be broken
what output must be produced
what validation is required
where the output goes next
what failure signals require review
how the skill improves over time
A skill is different from a tool.
A tool gives access.
A skill defines procedure.
A tool lets an AI Employee do something.
A skill teaches the AI Employee how to do the work properly.
Core Principle
The core principle of this protocol is:
Repeated work becomes a skill only when MWMS has a specific way of doing it and needs reliable execution over time.
Not every prompt becomes a skill.
Not every task becomes a skill.
Not every idea becomes a skill.
A skill should be created only when it reduces drift, saves repeated instruction, improves output quality, and supports a real MWMS workflow.
Skill Creation Test
Before creating a formal AI skill, MWMS must apply the Skill Creation Test.
A task should become a skill only when the answer is yes to all three questions.
Question 1: Does This Task Repeat?
The task should happen more than once.
Examples:
course absorption
newsletter signal filtering
offer evaluation
developer handoff creation
MCR duplicate risk checking
content brief creation
VEO3 script generation
client report drafting
dashboard signal preparation
If the task is one-off, a normal prompt or temporary instruction is enough.
Question 2: Does MWMS Have A Specific Way Of Doing It?
The task should have a defined process, standard, judgment method, checklist, or operating rule.
Examples:
Course absorption must apply value, novelty, superiority, and fit tests.
Developer handoffs must include exact file, exact location, what not to touch, test steps, and expected result.
Newsletter intelligence must filter for business relevance and route signals correctly.
If the task has no specific MWMS method, the skill is not ready.
Question 3: Would AI Drift Without Guidance?
If generic AI output would likely be wrong, vague, incomplete, off-format, unsafe, or require heavy rewriting, the task may need a skill.
Drift signals include:
wrong structure
missing MWMS rules
generic output
wrong Brain routing
invented information
wrong destination
missing validation
wrong tone
weak specificity
unwanted extra work
If AI can already complete the task well with a simple prompt, a formal skill may not be needed.
Skill Creation Decision
If all three answers are yes, build the skill.
If only one or two answers are yes, do not formalize yet.
Possible outcomes:
Create Skill Now
Use Temporary Prompt
Park Skill Idea
Merge With Existing Skill
Update Existing Skill
Reject Skill
No skill decision should remain ambiguous.
Skill Structure Standard
Every formal MWMS AI skill should include the following sections.
Skill Identity
Defines the name, owning Brain, assigned AI Employee, purpose, status, version, and related standards.
Skill Trigger
Defines when the skill should activate.
Triggers may include:
specific task type
specific user request
specific workflow stage
specific input source
specific Brain Room message type
specific queue event
specific review state
specific output need
Skill Input
Defines what the skill can process.
Input may include:
course transcript
newsletter email
offer page
sales page
screenshot
WordPress page list
Supabase row
research source
client document
Brain Room message
developer file
pasted user instruction
Skill Context
Defines what context the skill must read before acting.
Context may include:
current user request
relevant source material
owning Brain
supporting Brains
related standards
approved context library
current save point
developer boundary
risk level
required output format
destination
human review requirement
Skill Procedure
Defines the steps the AI Employee must follow.
This is the heart of the skill.
It should include:
input normalization
source review
task classification
context selection
rule application
output creation
validation
handoff
learning capture
Skill Rules
Defines non-negotiable rules.
Examples:
do not invent proof
do not summarize weak course material as useful
do not touch M’s active build area
do not create duplicate MCR pages
do not use retired language
do not route generic newsletter noise to dashboards
do not give vague developer instructions
Skill Output
Defines exactly what the skill produces.
Examples:
absorption report
MCR page output
developer handoff
newsletter intelligence record
offer evaluation report
content brief
VEO3 script
validation report
failure log
handoff package
Skill Validation
Defines how the output is checked.
Validation may include:
source grounding
specificity
Brain routing
duplicate risk
format compliance
human review requirement
compliance review
tool permission boundary
destination check
quality threshold
Skill Handoff
Defines where the output goes next.
Possible destinations:
MCR
HeadOffice review
Brain Room
AI Manager
Routed Actions
Newsletter Queue Review
Parking System
Research Brain
Finance Brain
Experimentation Brain
M developer handoff
AIBS client review
archive
Skill Improvement
Defines how the skill will improve after use.
Improvement may occur after:
user correction
validation failure
workflow change
new standard creation
tool change
output drift
repeated manual fix
client requirement change
new failure pattern
Skill Record Template
Every formal skill should eventually be recorded using the following structure.
Skill Name:
Skill Type:
Owning Brain:
Assigned AI Employee:
Skill Purpose:
When To Use This Skill:
Required Input:
Required Context:
Related Standards:
Skill Procedure:
Required Output:
Validation Requirement:
Human Review Requirement:
Tool Permission Boundary:
Forbidden Actions:
Handoff Destination:
Failure Triggers:
Expected Outcome:
Skill Status:
Skill Version:
Last Reviewed:
Skill Types
MWMS classifies AI skills by type.
Intake Skills
Used when raw information first enters MWMS.
Examples:
Messy Input Intake Skill
Source Completeness Check Skill
Brain Ownership Detection Skill
Course Block Intake Skill
Extraction Skills
Used to pull useful signal from source material.
Examples:
Course Framework Extraction Skill
Newsletter Signal Extraction Skill
Offer Claim Extraction Skill
VOC Extraction Skill
Evaluation Skills
Used to judge value, quality, suitability, risk, or readiness.
Examples:
Course Absorption Value Skill
Offer Test Suitability Skill
Finance Risk Review Skill
Experiment Signal Quality Skill
Creation Skills
Used to create structured work products.
Examples:
Full Page Output Creation Skill
Content Brief Creation Skill
VEO3 Script Creation Skill
Developer Brief Creation Skill
Client Report Drafting Skill
Validation Skills
Used to check outputs before use.
Examples:
MCR Page Validation Skill
Developer Instruction Validation Skill
Newsletter Signal Validation Skill
Offer Evaluation Validation Skill
Routing Skills
Used to send work to the right Brain, person, queue, or workflow.
Examples:
Brain Routing Skill
Research Handoff Skill
Finance Review Routing Skill
M Developer Handoff Skill
Tool Use Skills
Used when a skill requires interaction with a tool or system.
Examples:
Gmail Newsletter Read Skill
Supabase Row Review Skill
WordPress Page List Review Skill
File Review Skill
Reporting Skills
Used to create decision-ready reports.
Examples:
Course Absorption Report Skill
Newsletter Intelligence Report Skill
Offer Evaluation Report Skill
AIBS Client Report Skill
Failure Handling Skills
Used when work fails or becomes unclear.
Examples:
Failure Classification Skill
Escalation Decision Skill
Failure Log Creation Skill
Kaizen Lesson Capture Skill
Outcome Measurement Skills
Used to judge whether the work mattered.
Examples:
Outcome Scoring Skill
Business Value Capture Skill
Workflow Usefulness Review Skill
Risk Reduction Capture Skill
Skill Statuses
MWMS uses the following skill statuses.
Proposed
The skill idea exists but no procedure is defined.
Draft
The skill has been written but not tested.
Manual Use
The skill can be used manually with human review.
Proven Manual Use
The skill has been used repeatedly and works well.
Assisted Use
The skill can support assisted workflows but still needs oversight.
Controlled Automation Candidate
The skill may later support automation but requires readiness review first.
Parked
The skill may be useful later but is not currently active.
Deprecated
The skill has been replaced by a better skill or standard.
Retired
The skill is no longer used.
Skill Build Workflow
MWMS uses the following workflow to build a skill.
Step 1: Identify Repeated Work
Identify a task that keeps happening.
Examples:
The user repeatedly asks for course blocks to be absorbed.
The user repeatedly asks for full page output.
The user repeatedly asks for developer handoffs for M.
The user repeatedly asks for newsletter insights to be filtered.
Step 2: Apply Skill Creation Test
Ask:
Does this repeat?
Does MWMS have a specific way of doing it?
Would AI drift without guidance?
If yes to all three, proceed.
Step 3: Capture Raw Process
Write down how the work is actually done.
Do not over-polish at this stage.
Capture:
sequence
judgment calls
if/then branches
rejection rules
quality checks
common mistakes
output expectations
Step 4: Extract Decision Logic
Identify what makes the workflow MWMS-specific.
Look for:
when to continue
when to stop
when to escalate
when to park
when to reject
when to update an existing page
when to create a new page
when to involve another Brain
when human review is required
Step 5: Define Triggers
Write the natural-language triggers that should activate the skill.
Good triggers are specific.
Bad trigger:
Use this for marketing.
Good trigger:
Use this when a course block is finished and the user asks to take it apart for MWMS absorption.
Step 6: Define Required Context
List what the AI Employee must know before using the skill.
Examples:
current source material
current user instruction
owning Brain
relevant standards
output destination
M developer boundary
current save point
approved context library
Step 7: Define Procedure
Turn the raw process into step-by-step operating logic.
The procedure should be clear enough that another AI Employee could follow it.
Step 8: Define Output
Specify exactly what the skill produces.
If output format is unclear, the skill is not ready.
Step 9: Define Validation
Define how to check whether the output is acceptable.
Step 10: Test With Real Inputs
Run the skill against real MWMS examples.
Do not only test with clean examples.
Use messy, realistic prompts.
Step 11: Identify Drift
Look for:
wrong output
wrong structure
generic language
missing rules
invented information
wrong Brain mapping
wrong handoff
extra unwanted work
Step 12: Refine Only The Failing Section
When a skill fails, update only the section that caused the drift.
Do not rewrite the whole skill unless the structure is fundamentally broken.
Step 13: Assign Status
After testing, assign the correct status:
Draft
Manual Use
Proven Manual Use
Assisted Use
Controlled Automation Candidate
Step 14: Review Over Time
Skills must be reviewed after repeated use, failure, or workflow change.
Skill Audit Protocol
Skills must be audited to prevent drift, duplication, conflict, bloat, and outdated behaviour.
The purpose of the audit is to ensure each skill remains useful, current, specific, and aligned with MWMS governance.
Audit Cadence
Skills should be audited:
quarterly for active skills
after repeated failure
after major workflow change
after related standard changes
after tool permission changes
before automation consideration
before client-facing deployment
after user correction reveals a repeated issue
Audit Questions
For each skill, ask:
Is the skill still used?
Does the task still repeat?
Does the skill still match the current MWMS process?
Does the skill use the correct context?
Does the skill reference current standards?
Does the skill produce the right output?
Does the output require polishing or rewriting?
Does the skill trigger correctly?
Does it trigger when it should not?
Does it overlap another skill?
Does it conflict with another skill?
Does it have clear forbidden actions?
Does it include validation?
Does it include a handoff destination?
Does it protect M’s active build boundaries?
Does it require human review?
Should it be refreshed, split, merged, parked, deprecated, or retired?
Audit Outcomes
Every skill audit must end with one clear outcome.
Refresh
The skill is still useful but needs updated rules, triggers, procedure, context, or validation.
Merge
The skill overlaps another skill and should be combined.
Split
The skill is too broad and should become two or more smaller skills.
Park
The skill may be useful later but is not currently active.
Deprecate
The skill is replaced by a better standard, workflow, or skill.
Retire
The skill is no longer needed.
Promote
The skill is proven and may move from manual use to assisted use or controlled automation candidate.
Skill Drift Signals
A skill may be drifting if:
the user keeps correcting it
the output sounds generic
the output ignores MWMS structure
the AI needs repeated reminders
the skill misses required context
the skill creates the wrong output format
the skill routes work incorrectly
the skill invents missing information
the skill ignores human review requirements
the skill uses outdated language
the skill conflicts with a newer standard
the skill fails to protect M’s active build areas
the output needs rewriting rather than polishing
The rewrite-versus-polish rule is important.
If the user is only polishing small details, the skill may be fine.
If the user is rewriting structure, logic, or output, the skill needs review.
Skill Refresh Rules
When refreshing a skill:
change only what is needed
preserve working sections
update triggers if activation is poor
update context requirements if missing context caused failure
update forbidden actions if the AI overstepped
update output format if the result is inconsistent
update validation if weak work passed through
update handoff if output destination is unclear
record the change in the skill version
Do not rebuild every skill from scratch when a small fix will work.
Skill Retirement Rules
A skill should be retired when:
it has not been used for a long period
the workflow no longer exists
the owning Brain has changed direction
the procedure is obsolete
the skill creates more confusion than value
a better skill replaced it
a standard replaced the need for it
the output repeatedly fails
the task is no longer important
Retired skills should be archived, not deleted immediately, unless governance decides deletion is safe.
Skill And Context Library Relationship
Skills should not duplicate large context libraries.
A skill should read the relevant context where possible.
The context file stores what is true.
The skill defines what to do.
Examples:
Voice Architecture stores voice rules.
Voice Checker Skill checks content against voice rules.
Offer Profile stores offer truth.
Offer Copy Skill uses the offer truth to create copy.
Objection Library stores buyer objections.
Sales Script Skill uses objections to build sales handling.
Duplicating context inside multiple skills creates maintenance drift.
The rule is:
Source truth lives in the context library. Procedure lives in the skill.
Skill And Tool Relationship
Skills must not authorize tool access.
Tool access is governed separately.
A skill may say what to do with a tool if permission already exists.
A skill must not grant permission to:
write to Supabase
edit WordPress
send emails
change dashboards
publish content
modify files
touch code
access client data
Tool permission boundaries must be respected.
The rule is:
Skills instruct behaviour. Tool permissions control access.
Human Review Rule
Human review is required for high-risk skills.
High-risk skills include:
developer handoff skills
MCR page creation skills
MCR cleanup skills
paid traffic decision skills
finance decision skills
compliance review skills
client-facing report skills
automation candidate skills
WordPress or Supabase tool-use skills
public content approval skills
Skills may improve speed, but they do not remove human governance.
Client Skill Isolation Rule
Future AIBS client skills must be isolated.
A client-specific skill must not leak:
client voice
client strategy
client data
client objections
client sales process
client reporting preferences
client confidential context
into MWMS internal systems or another client system.
Client skills must be permissioned, scoped, and reviewed.
Governance Role
HeadOffice owns the MWMS AI Skill Builder And Audit Protocol.
HeadOffice is responsible for:
approving formal skill creation
preventing unnecessary skill sprawl
ensuring skills belong to a Brain
ensuring skills align with AI Employee Role Cards
ensuring skills reference correct context
ensuring skills respect tool permissions
ensuring skills include validation
ensuring skills include handoff destinations
ensuring high-risk skills require human review
ensuring duplicate skills are merged or retired
ensuring skill audits occur
protecting M’s active build boundaries
protecting future client systems
Individual Brains may propose skills, but HeadOffice governs cross-Brain, high-risk, automation-related, and client-facing skill usage.
Relationship To Other MWMS Standards
This protocol supports and must align with:
MWMS Document Structure Standard
MWMS AI Agent Skill Library Framework
MWMS AI Agent Memory And Context Framework
MWMS Offer Context Library Standard
MWMS Client IP Excavation Framework
MWMS AI Employee Role Card Standard
MWMS AI Employee Capability Stack Framework
MWMS AI Tool Permission And Access Framework
MWMS AI Agent Context Pack Template
MWMS Agentic Work Unit Standard
MWMS AI Workflow Pipeline Standard
MWMS AI Output Validation Standard
MWMS Messy Input Normalization Framework
MWMS AI Employee Handoff Protocol
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Outcome Measurement Framework
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS Course Absorption Operating Rule
MWMS Page Naming Standard
MWMS Architecture Registry
AI Business Systems Brain Canon
This protocol provides the practical build-and-audit procedure for skills inside the wider AI Agent Skill Library.
Drift Protection
This protocol protects MWMS from:
repeating the same prompt work every session
turning one-off tasks into unnecessary skills
creating vague skills
building skills without owning Brains
building skills without AI Employee ownership
creating skills without triggers
creating skills without validation
creating skills without handoff destinations
allowing stale skills to remain active
allowing skills to conflict
duplicating context inside skills
treating tools as skills
automating unproven procedures
letting client-specific skills leak into other systems
allowing output drift to continue unnoticed
Any repeated AI task that causes repeated correction should be reviewed for skill creation or skill refresh.
Architectural Intent
The architectural intent of the MWMS AI Skill Builder And Audit Protocol is to convert repeated AI work into reusable procedural intelligence.
MWMS is not building a folder of prompts.
MWMS is building a governed AI workforce.
That workforce needs:
context
memory
skills
tools
validation
handoffs
audits
improvement loops
The long-term goal is that every important AI Employee can answer:
What skill should I use?
Why should I use it?
What input do I need?
What context must I read?
What steps must I follow?
What must I avoid?
What output must I produce?
How should I validate it?
Where does it go next?
What failure signals stop the work?
When should this skill be updated?
When MWMS can answer those questions consistently, AI Employees become more reliable, more scalable, easier to govern, and easier to package into future AIBS client systems.
Change Log
v1.0 — Initial Draft
Created the MWMS AI Skill Builder And Audit Protocol as the build-and-maintenance protocol for reusable AI skills across MWMS.
This protocol defines the skill creation test, skill structure, skill record template, skill types, skill statuses, skill build workflow, audit cadence, audit questions, audit outcomes, drift signals, refresh rules, retirement rules, context library relationship, tool relationship, human review rule, client isolation rule, governance role, drift protection, and architectural intent.
Change Impact Declaration
Pages Created:
MWMS AI Skill Builder And Audit Protocol
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
MWMS Architecture Registry
HeadOffice Page Registry
AI Business Systems Brain Page Registry
Canon Version Update Required:
No
Change Log Entry Required:
Yes
Employee Impact Check
Employees impacted:
HeadOffice Manager Employee
AI Manager
AI Employee Router
Course Absorption Agent
Newsletter Signal Extraction Agent
Offer Strategist Employee
Content Planner Employee
Creative Strategist Employee
Sales Strategist Employee
Developer Support Agent
AI Business Systems Architect Employee
Required behaviour updates:
AI Employees must not treat one-off prompts as formal skills.
AI Employees must recommend skill creation only when a task repeats, has a specific MWMS method, and would drift without guidance.
AI Employees must define triggers, required input, required context, procedure, forbidden actions, output, validation, handoff, and failure triggers for formal skills.
AI Employees must audit active skills for drift, duplication, conflict, stale context, weak triggers, missing validation, and poor output quality.
AI Employees must treat context libraries as source truth and skills as procedures that use that truth.
END MWMS AI SKILL BUILDER AND AUDIT PROTOCOL v1.0