System: MWMS
Document Type: Protocol
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.1
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, AIBS 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
Last Reviewed: 2026-06-20
Source / Origin: MWMS AI Skill Builder And Audit Protocol v1.0 + AI Automations by Jack — Lessons 125, 138 and 144 covering reusable Skills, expert-workflow conversion, skill discovery, specialist capabilities, project scope, installation verification, parallel skill use and Claude Code persistent instruction patterns
Related Pages: MWMS AI Agent Skill Library Framework, MWMS Source Material To AI Skill Conversion Framework, MWMS Manual Build Versus Skill Build Decision Rule, MWMS AI Employee Capability Stack Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Agent Memory And Context Framework, MWMS AI Output Validation Standard, MWMS Independent Model Review And Rescue Routing Framework, MWMS AI Work Session Closure And Knowledge Commitment Protocol
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
AIBS 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
Capability Gap And Duplicate Check
Before building a skill, MWMS must confirm that a genuine capability gap exists.
A capability gap exists when a repeated task cannot be performed reliably because the current AI Employee lacks:
a stable procedure
required decision logic
required validation
required context
required tool-use guidance
required output structure
required failure handling
Required questions:
What repeated task is failing or consuming unnecessary effort?
Which AI Employee currently performs the task?
Is the problem caused by missing procedure, missing context, missing tools, or weak execution?
Does an existing skill already cover the task?
Would updating or composing existing skills solve the problem?
Can the result be validated?
Does the skill create enough value to justify maintenance?
Possible outcomes:
Use Existing Skill
Update Existing Skill
Compose Existing Skills
Create New Skill
Use Temporary Prompt
Park Skill Idea
Reject Skill
Capability Gap Rule
No demonstrated capability gap, no new formal skill.
A different name does not prove that a different skill is required.
Skill Scope Standard
Every formal skill must define where it may operate.
Recommended scope types:
Organisation-Level Skill
Applies across approved MWMS systems.
Brain-Level Skill
Owned and used primarily inside one Brain.
Workflow-Level Skill
Used only inside a named workflow.
Project-Level Skill
Used only inside a defined project.
Client-Level Skill
Used only for one client and isolated from all others.
Experimental Skill
Used only in a controlled test environment.
Scope must define:
allowed Brains
allowed projects
allowed clients
allowed environments
allowed data
forbidden environments
expiry where relevant
promotion requirements
Skill Scope Rule
Use the narrowest safe scope.
Project-level or client-level procedures must not silently become global MWMS skills.
Skill Invocation Standard
Every skill must define how it is activated.
Possible invocation methods:
direct user instruction
AI Manager routing
Work Unit assignment
workflow state change
approved scheduled trigger
explicit skill command
dependency activation
approved natural-language recognition
Automatic skill invocation is allowed only when:
the trigger is unambiguous
the skill scope matches
required context exists
required tools are approved
the active version is confirmed
human approval requirements remain intact
no higher-authority rule blocks execution
Invocation Rule
Skills should be easy to discover and difficult to misuse.
Natural-language recognition must not override Canon, permissions, project boundaries or human review.
External Skill Intake Protocol
Externally sourced skills must be treated as untrusted candidates until reviewed.
For each external skill, record:
External Skill Name
Source
Creator
Source Date
Claimed Purpose
Files Included
Instructions Included
Tools Required
Permissions Requested
External Connections
Credentials Referenced
Overlap With Existing MWMS Skills
Potential Value
Known Risks
Required Tests
Decision
Possible decisions:
Reject
Park
Extract Principles Only
Convert To MWMS Skill
Merge Into Existing Skill
Install In Isolated Test
Approve For Limited Use
External Skill Rule
Popularity, downloads, ratings, creator reputation or claims such as “cheat code” do not establish MWMS value, safety or readiness.
Skill Installation Verification
A skill is not operational merely because files have been copied into a folder or an AI platform reports that the skill is installed.
Installation verification must confirm:
required files exist
the active instructions load correctly
dependencies are available
permissions match the approved boundary
credentials are not embedded
the skill activates when it should
the skill does not activate when it should not
the output matches the required format
failure states remain visible
logging works
shutdown or revocation works where relevant
Installation states:
Not Installed
Installed Unverified
Installed In Test
Verified For Manual Use
Verified For Assisted Use
Blocked
Suspended
Installation Rule
No verified installation, no operational use.
Skill Dependency And Composition Protocol
Some skills depend on other skills.
Dependencies must be:
identified
version-compatible
available
loaded in the correct order
tested as part of the complete workflow
Several skills may be composed inside one Work Unit.
Skill composition must define:
sequence
ownership
shared context
handoff
validation gates
final authority
conflict rules
cost
stop conditions
Example:
Course Absorption Value Extraction Skill may depend on:
Messy Input Normalization Skill
MCR Duplicate Risk Check Skill
Full Page Output Creation Skill
Output Validation Skill
Session Closure Skill
Composition Rule
Composed skills must not create conflicting instructions or hidden authority.
Where conflict exists:
apply current Canon
apply the higher-authority standard
apply the more specific approved skill
compare active versions
escalate unresolved conflict
Parallel Skill Execution Protocol
Skills may run in parallel only when their tasks are genuinely separable.
Parallel execution may be useful for:
independent research streams
source verification
financial review
compliance review
visual analysis
alternative architecture exploration
content-format planning
Parallel execution must define:
Parallel Group ID
Work Unit ID
skills running
shared input
separate responsibility
expected output
synthesis owner
conflict rule
cost limit
completion gate
Parallel Rule
Parallel execution must reduce elapsed time or improve independent analysis.
It must not create uncontrolled duplication, conflicting outputs or unnecessary cost.
Skill Asset Bundle Standard
A complete skill may require supporting assets.
A Skill Asset Bundle may include:
primary skill record
procedure file
input schema
output template
validation checklist
example inputs
approved example outputs
test cases
tool requirements
dependency list
failure examples
Rescue Route
change history
supporting reference material
Asset Bundle Rule
Supporting assets remain subordinate to the active Skill Record and current Canon.
Examples are guidance, not authority.
Skill Testing Standard
Every formal skill must be tested before stronger operational use.
Testing should include:
trigger test
exclusion test
scope test
input test
messy-input test
context test
dependency test
permission test
procedure test
output-format test
validation test
failure test
Rescue Route test
handoff test
outcome test
cost test
Negative tests must confirm that the skill stops safely when:
required input is missing
context is incomplete
permissions are absent
the scope is wrong
a dependency fails
a tool is unavailable
a quota is exceeded
human review is required
Possible test results:
Untested
Test Failed
Test Passed
Passed With Conditions
Proven Manual Use
Controlled Automation Candidate
Suspended
Testing Rule
A documented skill is not automatically a proven skill.
Skill Cost And Quota Control
Skills may consume:
model quota
API quota
tool credits
compute
storage
browser actions
rendering time
human review time
maintenance time
Each operational skill should define:
expected cost
maximum cost
maximum runs
maximum retries
maximum parallel workers
maximum source volume
stop threshold
escalation threshold
Cost Rule
A skill that costs more to operate, review and maintain than the value it creates should be improved, restricted, merged, parked or retired.
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:
Capability Gap Addressed:
Skill Scope:
Allowed Environments:
Allowed Projects Or Clients:
When To Use This Skill:
Required Input:
Required Context:
Invocation Method:
Automatic Invocation Allowed:
Source Authority Requirement:
Related Standards:
Skill Procedure:
Required Output:
Validation Requirement:
Human Review Requirement:
Tool Permission Boundary:
Required Dependencies:
Environment Assumptions:
Forbidden Actions:
Handoff Destination:
Failure Triggers:
Retry Limit:
Rescue Threshold:
Rescue Route:
Expected Outcome:
Outcome Evidence:
Cost Boundary:
Skill Status:
Skill Version:
Last Tested:
Test Result:
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.
Step 15: Define Scope
Confirm whether the skill is organisation-level, Brain-level, workflow-level, project-level, client-level or experimental.
Step 16: Inspect Dependencies
Confirm required skills, tools, files, systems, permissions and environment assumptions.
Step 17: Create Test Cases
Create both positive and negative test cases.
Step 18: Verify Installation
Confirm the skill loads, activates, produces the correct output and stops safely.
Step 19: Record Outcome And Cost
Record whether the skill saved time, improved quality, reduced risk or created other measurable value.
Step 20: Approve, Restrict Or Reject
Assign one clear operational decision:
Approve For Manual Use
Approve For Assisted Use
Approve With Restrictions
Return To Draft
Park
Reject
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?
Is the skill operating within its approved scope?
Are dependencies current and available?
Has installation been verified?
Does natural-language invocation activate correctly?
Does the skill remain cost-effective?
Are quota and retry limits appropriate?
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.
Restrict
The skill remains useful but must operate within a narrower scope, reduced permission set or manual-only mode.
Suspend
The skill must stop operating until a material dependency, safety, validation, cost or permission problem is resolved.
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
an external skill was installed without inspection
the skill activates outside its approved scope
a dependency is missing or outdated
installation has not been verified
parallel execution creates duplicate or conflicting work
cost or quota usage is uncontrolled
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 skills define scope
ensuring external skills are inspected
ensuring installation is verified
ensuring dependencies are controlled
ensuring parallel execution has synthesis authority
ensuring skill cost remains proportionate
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 Source Material To AI Skill Conversion Framework
MWMS Manual Build Versus Skill Build Decision Rule
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
AIBS 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?
How is this skill invoked?
Where is this skill allowed to operate?
What dependencies must be available?
Has installation been verified?
How much should this skill cost?
When should this skill be updated, restricted, suspended, or retired?
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
Version: v1.1
Date: 2026-06-20
Author: HeadOffice
Change:
Updated the MWMS AI Skill Builder And Audit Protocol using the AI Automations by Jack lessons covering reusable Skills, expert-workflow conversion, automatic skill discovery, project and organisation scope, installation verification, specialist capabilities, parallel skill execution and persistent instruction systems.
Added:
Capability Gap And Duplicate Check
Skill Scope Standard
Skill Invocation Standard
External Skill Intake Protocol
Skill Installation Verification
Skill Dependency And Composition Protocol
Parallel Skill Execution Protocol
Skill Asset Bundle Standard
Skill Testing Standard
Skill Cost And Quota Control
Expanded Skill Record Template
Expanded Skill Build Workflow
Restrict audit outcome
Suspend audit outcome
installation, dependency, scope, invocation, cost and quota audit checks
new Skill Drift Signals
expanded HeadOffice governance responsibilities
Purpose of update:
To evolve the protocol from a basic skill creation and audit process into a complete controlled build, inspection, testing, installation, scope, dependency, invocation, cost and lifecycle protocol for MWMS and future AIBS client systems.
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:
None
Pages Updated:
MWMS AI Skill Builder And Audit Protocol
Pages Deprecated:
None
Standalone Pages Not Created:
MWMS External Skill Intake Protocol
MWMS Skill Installation Verification Standard
MWMS Skill Scope Framework
MWMS Parallel Skill Execution Protocol
MWMS Skill Cost And Quota Standard
Registries Requiring Update:
None confirmed by the supplied source.
Canon Version Update Required:
No
Change Log Entry Required:
Yes
Strategic Absorption Result
MWMS gains a stronger practical protocol for deciding whether a skill should exist, inspecting external skill packages, defining scope and invocation, verifying installation, controlling dependencies and parallel use, testing failure states, measuring cost and auditing the complete lifecycle before stronger operational authority is granted.
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
AIBS 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 OF FULL FILE OUTPUT