How the BlitzMetrics Knowledge System Learns From Itself

START

---
name: add-knowledge-capture-to-existing-workflows
description: Embed an explicit Knowledge Capture step inside the Zoom call, campaign review, and audit workflows so insights are captured by process, not by memory.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Add Knowledge Capture to existing workflows

**Use this when** standing up the Knowledge Capture Pipeline — this task is a gap: the capture step is not yet built into any workflow, which is why insights currently survive only when someone remembers.

## Inputs
- The three insight-producing workflows named by the hub: client Zoom calls, campaign data reviews, and audits (quarterly article audits, website QA audits)
- The Knowledge Capture Note template (see `provide-knowledge-capture-note-template`)
- Edit access to those workflows' checklists/SOPs, plus the SOP Amendment Proposal process

## Steps
1. Map where each workflow ends: the post-Zoom wrap-up, the campaign review's MAA action step, the audit close-out. The capture step belongs at the natural end, while context is hot and before the team disperses.
2. Add the explicit step to each: **Zoom calls** — "Any reusable insight from this call? Generate a Knowledge Capture Note within 24 hours" in the post-call checklist; **campaign reviews** — capture step right after metrics analysis, where surprises surface; **audits** — capture step in the audit wrap-up, feeding findings beyond the audited article itself.
3. Embed the note template (or a one-click link to it) at each capture point — if the capturer has to hunt for the template, the 24-hour window loses an hour to friction.
4. Make the changes legitimately: editing these workflows is itself an SOP change, so file the SOP Amendment Proposal(s) and let weekly review approve with version increment and changelog. The pipeline obeys its own protocol.
5. Verify with one live run of each workflow: confirm the capture step fires, a note gets written within 24 hours, and it lands in the shared capture location.
6. Monitor for 2–4 weeks: if a workflow produces zero notes, the step is in the wrong place or phrased as optional — move it or sharpen it, and amend again.

## Definition of done (QA checklist)
- [ ] All three named workflows (Zoom, campaign reviews, audits) contain an explicit capture step with the template linked at the point of use
- [ ] Workflow edits shipped via approved SOP Amendment Proposals with version increments and changelog entries
- [ ] One live run per workflow produced a real, on-template note within 24 hours
- [ ] 2–4 week adoption check scheduled; silent workflows get the step repositioned
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 3 requires integrating note generation into Zoom, campaign data, and audit workflows. Gap: not yet integrated — the first run is the example.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the integration ships and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) embeds the capture step at the natural end of all three named workflows, ships the edits through the SOP Update Protocol, and loops until the Definition of done fully passes — including one verified live run per workflow producing a real, on-template note within 24 hours.
It self-verifies by watching the live runs rather than trusting the checklist edit: the step either fired and produced a note, or it goes back for repositioning.
Memory across cycles is what makes the 2–4 week adoption check real instead of aspirational: a long-horizon agent actually returns on schedule, remembers which workflows produced zero notes, and keeps repositioning the step until insights flow by process — the integration is monitored into existence, not declared.
Each run it logs a meta-article example via the Meta-Article Prompt, so the integration pattern transfers to every future workflow.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related: provide-knowledge-capture-note-template and create-knowledge-capture-note-template-and-distribute (template first), then generate-knowledge-capture-note-within-24-hours → route-notes-to-sop-update-protocol-or-directly-to-articles; changes ship via create-sop-amendment-proposal-500-words.

END

START

---
name: add-last-audited-column-to-definitive-article-guide-status-table
description: Add a Last Audited column to the Definitive Article Guide status table, initialized to "Not yet audited" for every article, so audit recency becomes visible and enforceable.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Add Last Audited column to Definitive Article Guide status table

**Use this when** implementing the maintenance system — this task is a gap from the Implementation Checklist: the status table currently shows what state each article is in, but not when anyone last verified it.

## Inputs
- Edit access to the status table in the Definitive Article Guide
- The Definitive Article Index (the canonical list of articles the table must cover)

## Steps
1. Open the status table in the Definitive Article Guide and add a **Last Audited** column alongside the Green/Yellow/Red status column.
2. Set the initial value for every existing row to **"Not yet audited"** — exactly that, for all articles. No retroactive dates, no "probably checked in spring": the column tells the truth from day one, and the truth is that the quarterly cycle has not run yet.
3. While in the table, reconcile rows against the Definitive Article Index: every article in the index has a row; every row maps to a real article. Add missing rows (also "Not yet audited") and flag orphan rows.
4. Update the table's usage note so the column is load-bearing: each quarterly audit must stamp this column with the audit date when updating status (Process 1's closing step, `update-status-table-in-definitive-article-guide`).
5. Announce the change to the audit team: from now on, "audited" means a date in this column — a status with no date is an unverified claim.
6. Hand off to `schedule-first-quarterly-audit-cycle` so real dates start replacing "Not yet audited" in Q3 2026.

## Definition of done (QA checklist)
- [ ] Last Audited column exists in the status table with every row initialized to "Not yet audited"
- [ ] Table reconciled against the Definitive Article Index — complete rows, no orphans
- [ ] Usage note updated: quarterly audits must stamp date + status here
- [ ] Audit team notified that undated statuses count as unverified
- [ ] First quarterly cycle queued to begin filling real dates
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — the Implementation Checklist specifies this column with initial value "Not yet audited" for all articles. Gap: column not yet added — running this skill closes it.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the column ships and the first real date lands, then link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) adds the Last Audited column, initializes every row to exactly "Not yet audited," reconciles the table against the Definitive Article Index, and loops until the Definition of done fully passes — complete rows, no orphans, the usage note updated, the team notified that an undated status is an unverified claim.
It self-verifies by re-diffing table rows against the index after the edit: zero articles missing a row, zero rows pointing at nothing.
The column is the system's memory made visible, and a memory-bearing agent keeps it honest across every future audit cycle: it remembers the reconciliation state, flags rows added without the convention, and refuses retroactive dates — the table only ever says what was actually verified, and when.
Each run it logs a meta-article example via the Meta-Article Prompt, so the infrastructure change itself enters the knowledge base.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related: update-status-table-in-definitive-article-guide (the step that writes to this column) → schedule-and-assign-quarterly-auditors → schedule-first-quarterly-audit-cycle.

END

START

---
name: apply-portability-discipline-to-meta-articles
description: Ensure meta-articles separate the transferable general approach from the platform-specific details of that particular run, so documented agent work stays useful after tools change.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Apply portability discipline to meta-articles

**Use this when** writing or auditing meta-articles — the documented runs of real work created via /meta-article-prompt-template — so each one teaches a reusable method, not just a tour of one tool on one day.

## Inputs
- The meta-article(s) to review, or the run about to be documented
- The two-layer standard from Process 4 (methodology = what/why; implementation = how)
- The Meta-Article Prompt Template (/meta-article-prompt-template)

## Steps
1. Pull the meta-articles in scope: existing ones linked from definitive articles as examples, and any new one being written from a fresh run.
2. For each, check that it distinguishes the two layers: the **general approach** — what was done and why, the decisions and method any reader could transfer; and the **platform-specific execution** — the exact tools, versions, and steps used in this particular run.
3. Where the layers are blended, add explicit framing rather than deleting detail: a short "the approach" passage stating the transferable method, and a clearly marked "how we ran it this time" passage holding the tool specifics. Meta-articles need the specifics — they are the proof — but labeled as that run's implementation.
4. Run the reader test: someone on a different platform (different editor, ad manager, transcription tool) must still be able to extract and apply the method. If the method only makes sense inside the named tool, the methodology framing is missing.
5. For future runs, push the fix upstream: if the Meta-Article Prompt Template does not already ask for approach-vs-execution separation, propose that addition via an SOP Amendment Proposal so every future meta-article is born portable.
6. Record reviewed meta-articles and their fixes in the audit notes; recheck new meta-articles as part of the quarterly audit's example checks.

## Definition of done (QA checklist)
- [ ] Every in-scope meta-article has clearly framed approach (transferable) and execution (this run's tools) layers
- [ ] Reader test passed: the method is extractable by someone on a different platform
- [ ] No proof-level detail deleted — specifics retained but labeled as implementation
- [ ] Template-level fix proposed via SOP Amendment if the Meta-Article Prompt lacks the separation requirement
- [ ] Reviewed articles and fixes recorded for the quarterly audit trail
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /meta-article-prompt-template — the canonical meta-article system this discipline applies to; /knowledge-system-maintenance Process 4 extends portability to these documents explicitly.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first portability pass over a meta-article and link it here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) reviews every in-scope meta-article for the two layers — transferable approach versus this run's tooling — and loops until the Definition of done fully passes: layers explicitly framed, no proof-level detail deleted, reader test passed.
It self-verifies by masking the implementation passages and confirming the method still extracts cleanly for someone on a different platform.
This is the recursion folding back on itself: meta-articles are the agent's own logged runs, so memory across cycles means the agent audits the documentation of its own remembered work — and it pushes the approach-vs-execution requirement upstream into the Meta-Article Prompt Template once, via SOP Amendment Proposal, so every future run is born portable instead of being fixed after the fact.
Each run it logs a new meta-article example, which is itself immediately subject to this discipline — that is how the knowledge base compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 4 run order): separate-methodology-layer-what-why-from-implementation-layer-how → review-existing-sops-for-portability-compliance → apply-portability-discipline-to-meta-articles. Concepts: /meta-article-prompt-template, /blog-posting-guidelines.

END

START

---
name: audit-this-maintenance-article-every-6-months
description: Run the 6-month recursive audit of /knowledge-system-maintenance itself — test its five processes against six months of reality and amend, add, or retire them through their own protocol.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Audit this maintenance article every 6 months

**Use this when** the scheduled 6-month recursive review arrives (see `schedule-first-6-month-recursive-review`) — the maintenance system must pass the same tests it imposes on everything else, or it has no authority to impose them.

## Inputs
- /knowledge-system-maintenance (the article under audit) and its version/changelog history
- Six months of operating evidence: status table audit dates, the SOP Amendment Proposal tracker, Knowledge Capture Note volume, portability review grades
- The pattern review output (`review-past-6-months-of-sop-amendment-proposals-for-patterns`)

## Steps
1. Run the full Process 1 audit on /knowledge-system-maintenance itself: topic coherence (SEO Tree test), structural completeness, information currency, and cross-reference integrity. The maintenance article gets no exemption from its own checks.
2. Test each of the five processes against six months of reality, not theory: Did quarterly audits actually run and stamp the status table? Did amendment proposals flow and get weekly review? Were Knowledge Capture Notes generated within 24 hours? Did portability reviews happen? Is this recursive cycle itself running on schedule?
3. Disposition every process explicitly: **keep** (working as written), **modify** (works but the article describes it wrong — or it needs adjustment), or **remove** (cost exceeds value). Silence is not a disposition.
4. Identify missing processes: recurring problems from the past six months that none of the five processes addresses are candidates for a new sixth process.
5. Ship every change to the article through its own Process 2: SOP Amendment Proposal(s), weekly senior review, version increment, changelog entry. The system editing itself outside its own protocol is the first sign of rot.
6. Update the article's row in the status table with this audit's date and status, and update the corresponding Task Library skills if any process changed — the skills must mirror the hub.
7. Before closing, schedule the next 6-month review with named reviewers. A recursive cycle that does not schedule its own next iteration has terminated.

## Definition of done (QA checklist)
- [ ] All four Process 1 checks run against /knowledge-system-maintenance with findings recorded
- [ ] Each of the five processes explicitly dispositioned keep/modify/remove with six months of evidence cited
- [ ] All article changes shipped via approved SOP Amendment Proposals with version increment and changelog
- [ ] Status table stamped; affected Task Library skills updated to mirror the revised hub
- [ ] Next 6-month review scheduled with named reviewers before this one closes
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 5 defines this self-audit; the article is both the subject and the standard, which is the point of the recursive layer.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first 6-month review and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) is the natural owner of this skill, because the 6-month recursive audit is exactly what a long-horizon agent with memory is for: it runs all four Process 1 checks on /knowledge-system-maintenance itself, tests each of the five processes against six months of remembered evidence, and loops until the Definition of done fully passes — every process explicitly dispositioned keep / modify / remove, no silence.
It self-verifies by shipping every change through the article's own Process 2 and then confirming the version incremented, the changelog recorded it, and the affected Task Library skills were updated to mirror the revised hub — the system editing itself outside its own protocol is the exact failure this audit exists to prevent.
Memory across audit cycles is the entire point: the agent arrives with the status-table dates, amendment flow, capture volume, and portability grades already held from living through them, compares this cycle against the last one, and schedules the next review before closing — a recursive loop that cannot forget is a recursive loop that cannot quietly terminate.
Each run it logs a meta-article example via the Meta-Article Prompt, so the system's self-audits become part of the knowledge base they audit.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 5 run order): review-past-6-months-of-sop-amendment-proposals-for-patterns → audit-this-maintenance-article-every-6-months → schedule the next cycle (schedule-first-6-month-recursive-review for the inaugural one). Concept: /seo-tree.

END

START

---
name: check-information-currency-with-latest-data
description: Refresh a definitive article's facts, numbers, and tool steps against the latest GBP, Ahrefs, client Zoom, and campaign data so the page never teaches stale reality.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Check information currency with latest data

**Use this when** running the quarterly audit's third check — the article is coherent and structurally complete, but its facts may have drifted since the last audit.

## Inputs
- The definitive article under audit, plus its last audit date
- Access to the four named data sources: Google Business Profile, Ahrefs, client Zoom call recordings/notes, and campaign results
- The audit notes for this article and quarter

## Steps
1. Inventory every claim in the article that can drift: metrics, dates, prices, screenshots, tool names, UI steps, rankings, and "currently" statements. List them with their location.
2. Pull the freshest data from each named source: GBP (listings, reviews, profile facts), Ahrefs (rankings, traffic, backlinks the article cites), client Zoom calls (what clients are actually experiencing now), and campaign results (what the method currently produces).
3. Compare each inventoried claim against current data and mark it current, stale, or wrong.
4. Update stale and wrong items in the article: refresh numbers, replace outdated screenshots, correct tool steps. Touch only the implementation facts — keep the methodology layer (what/why) intact per Platform Portability Discipline (Process 4).
5. If a Zoom call or campaign surfaced a reusable insight that belongs in the article but is not yet there, generate a Knowledge Capture Note within 24 hours and route it (Process 3) rather than improvising new content mid-audit.
6. If the *process the article teaches* has materially changed — not just its data — do not silently rewrite it: file an SOP Amendment Proposal (Process 2) so the change gets reviewed, versioned, and changelogged.
7. Record the data-refresh date and what changed in the audit notes; pass the result to the status-table update.

## Definition of done (QA checklist)
- [ ] Drift inventory built and every item dispositioned current / stale / wrong — none left unmarked
- [ ] All four data sources actually consulted (GBP, Ahrefs, client Zooms, campaign results), not just the convenient ones
- [ ] Every stale/wrong item updated in the article or ticketed with owner; methodology layer left intact
- [ ] New insights routed as Knowledge Capture Notes; process changes routed as SOP Amendment Proposals — no silent process edits
- [ ] Refresh date recorded for the status table
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 1 names GBP, Ahrefs, client Zoom calls, and campaign results as the currency sources for this exact check.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first real quarterly run and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) builds the full drift inventory, pulls fresh data from all four named sources (GBP, Ahrefs, client Zooms, campaign results) — not just the convenient ones — and loops until the Definition of done fully passes: every claim dispositioned current, stale, or wrong, and every stale item updated or ticketed.
It self-verifies by diffing the article before and after the refresh to confirm only implementation facts changed and the methodology layer survived untouched.
Memory across audit cycles is what makes this check compound: the agent carries last quarter's claim inventory and refresh dates forward, starts each audit from remembered state instead of re-discovering the page, and flags claims that go stale every single cycle as candidates to restructure rather than re-refresh.
Each run it logs a meta-article example via the Meta-Article Prompt, so the knowledge base records how the refresh was actually done.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 1 run order): verify-structural-completeness-against-8-step-framework → check-information-currency-with-latest-data → validate-cross-reference-integrity-across-articles → update-status-table-in-definitive-article-guide; feeds: generate-knowledge-capture-note-within-24-hours, create-sop-amendment-proposal-500-words.

END

START

---
name: check-topic-coherence-for-each-definitive-article
description: Run the SEO Tree test on a definitive article so every element provably supports its declared topic — the first check of the quarterly audit.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: complete
---

# Check topic coherence for each definitive article

**Use this when** a quarterly audit cycle opens and you are the assigned auditor for a definitive article — run this check first, before structure, currency, or cross-references.

## Inputs
- The definitive article's URL, short URL, and declared topic (the one concept it owns)
- The Definitive Article Guide status table (to record findings)
- The article's position in the SEO Tree (/seo-tree) — root, trunk, branch, or leaf
- Audit notes doc or row for this article and quarter

## Steps
1. Write the article's declared topic as one sentence at the top of your audit notes, taken from its title, first-two-paragraph definition, and short URL. If you cannot state it in one sentence, that is itself a Red finding.
2. Apply the SEO Tree test to every element: for each H2/H3 section, paragraph block, image, embedded video, example, and link, ask "does this directly support the declared topic?" Every element either supports the topic or does not belong on this page.
3. Walk the heading outline specifically. Flag any H2/H3 that actually serves a *different* concept — it likely belongs in that concept's own definitive article. Moving it prevents two pages competing for one topic (content vandalism).
4. Check every linked example: each must demonstrate *this* topic, and its 1–2 sentence relevance note must say why in terms of this topic, not a neighboring one.
5. Check outbound links: cross-links to related definitive articles are correct; links that drag the reader into an unrelated topic mid-article are coherence failures. Confirm the article links upward/across consistent with its SEO Tree position.
6. Record every failing element in the audit notes as: element → why it fails the test → recommended fix (cut, rewrite to serve the topic, or relocate to the correct hub).
7. Fix trivial failures in place. For structural moves (relocating a section to another hub), ticket the article owner or file an SOP Amendment Proposal if the creation process itself allowed the drift.
8. Pass the findings to the status-table update step (Green/Yellow/Red plus audit date) — see `update-status-table-in-definitive-article-guide`.

## Definition of done (QA checklist)
- [ ] Declared topic stated in one sentence in the audit notes
- [ ] Every heading, image, example, and link checked; pass/fail recorded — no element skipped
- [ ] Zero unresolved off-topic elements: each is fixed, relocated, or ticketed with owner and recommended fix
- [ ] Findings recorded for the status table with this quarter's audit date
- [ ] Any reusable insight from the audit captured as a Knowledge Capture Note within 24 hours
- [ ] If this skill's steps no longer match how audits actually run, an SOP Amendment Proposal is filed
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 1 defines this check and applies it to BlitzMetrics' own article library; use its audit criteria verbatim.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first real quarterly run and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) walks every heading, paragraph, image, example, and link of the assigned article against its declared topic and loops until the Definition of done fully passes — no element skipped, zero unresolved off-topic elements, findings stamped for the status table.
It self-verifies by re-running the SEO Tree test on every element it fixed or relocated, confirming the repaired page now reads as one topic end to end.
Because this is the recursive maintenance layer, memory across audit cycles is the mechanism, not a convenience: the agent retains each article's declared-topic sentence and every prior quarter's findings, so this quarter's audit is a diff against remembered state — drift in the same section two cycles running becomes an SOP Amendment Proposal, not another patch.
Each run it logs a meta-article example via the Meta-Article Prompt, filling this skill's "Example needed" slot so the knowledge base compounds with every cycle.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 1 run order): check-topic-coherence-for-each-definitive-article → verify-structural-completeness-against-8-step-framework → check-information-currency-with-latest-data → validate-cross-reference-integrity-across-articles → update-status-table-in-definitive-article-guide; scheduling: schedule-and-assign-quarterly-auditors. Concept: /seo-tree.

END

START

---
name: conduct-first-portability-review-of-blog-posting-guidelines
description: Run the pilot portability review on the Blog Posting Guidelines — separate its methodology from its tool-specific steps and document the worked pattern for every other SOP.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Conduct first portability review of Blog Posting Guidelines

**Use this when** implementing Platform Portability Discipline — this Implementation Checklist task is a gap: /blog-posting-guidelines is the designated pilot, and no SOP has yet been through the separation.

## Inputs
- /blog-posting-guidelines — the full numbered process (Steps 1–17, from video upload through final QA)
- The two-layer method (`separate-methodology-layer-what-why-from-implementation-layer-how`)
- The SOP Amendment Proposal pipeline (the restructure ships through it)

## Steps
1. Open /blog-posting-guidelines and walk every numbered step (1–17), classifying each instruction as **methodology** (what/why: "transcribe the video and correct every error," "add internal links following the entity-linking decision tree") or **implementation** (how: Descript and its blue-underlined words, Grammarly/ChatGPT proofing, RankMath scores, LinkWhisper suggestions, WordPress block editor specifics).
2. Note why this article is the pilot: it is dense with named tools, so it stress-tests the discipline — if separation works here, it works anywhere.
3. Restructure each step so the methodology line leads and the tool-specific execution sits beneath it as a clearly labeled implementation block. Delete nothing — the tool detail is what makes the SOP runnable today; it just must be swappable tomorrow.
4. Run the portability test: with all implementation blocks removed, Steps 1–17 must still describe a complete, executable content process on any equivalent toolchain. Patch methodology gaps the test exposes.
5. Ship the restructure through the SOP Update Protocol: amendment proposal(s) within the 500-word format (split by section if needed), weekly senior review, version increment, changelog entry.
6. Document the worked pattern — classification calls that were hard, formatting choices, time taken — as the pilot playbook for `review-existing-sops-for-portability-compliance` to apply across the rest of the library.
7. Capture lessons as Knowledge Capture Notes within 24 hours of finishing; the pilot's purpose is to teach the system, not just fix one article.

## Definition of done (QA checklist)
- [ ] All numbered steps of /blog-posting-guidelines classified with zero unlabeled mixed instructions remaining
- [ ] Portability test passed: methodology layer alone still teaches the full process; no tool detail deleted, only layered
- [ ] Restructure approved via SOP Amendment Proposal(s) with version increment and changelog
- [ ] Pilot playbook documented and handed to the library-wide compliance review
- [ ] Lessons filed as Knowledge Capture Notes within 24 hours
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — the Implementation Checklist names Blog Posting Guidelines as the portability pilot; /blog-posting-guidelines is the document under review.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the pilot ships and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) walks all numbered steps of /blog-posting-guidelines, classifies every instruction as methodology or implementation, restructures so the method leads and the tool detail sits beneath it clearly labeled, and loops until the Definition of done fully passes — zero unlabeled mixed instructions, nothing deleted, the restructure shipped through the SOP Update Protocol.
It self-verifies by running the portability test: with every implementation block removed, Steps 1–17 must still describe a complete, executable content process on any equivalent toolchain, and the agent patches the methodology gaps the test exposes.
Memory is how the pilot teaches the system: the agent retains the worked pattern — the hard classification calls, the formatting choices, the time taken — and carries it directly into the library-wide compliance review, so every subsequent SOP inherits the pilot's lessons instead of rediscovering them.
Each run it logs a meta-article example via the Meta-Article Prompt and files the lessons as Knowledge Capture Notes within 24 hours, exactly as the skill demands of humans.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 4): separate-methodology-layer-what-why-from-implementation-layer-how (method) → conduct-first-portability-review-of-blog-posting-guidelines (pilot) → review-existing-sops-for-portability-compliance → apply-portability-discipline-to-meta-articles. Concept: /blog-posting-guidelines.

END

START

---
name: create-knowledge-capture-note-template-and-distribute
description: Build the Knowledge Capture Note template and distribute it into the team's actual workflows, then confirm real notes start flowing — the implementation milestone for Process 3.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Create Knowledge Capture Note template and distribute

**Use this when** implementing the maintenance system — this Implementation Checklist task is a gap: until the template exists *and* lives where work happens, the Knowledge Capture Pipeline is theory.

## Inputs
- The four-field template spec from Process 3 (see `provide-knowledge-capture-note-template`): source, insight in 1–3 sentences, destination, priority
- The shared capture location, plus the Zoom / campaign-review / audit workflow checklists
- The team roster (everyone who touches client calls, campaigns, or audits)

## Steps
1. Build the template per the spec — Source, Insight (1–3 sentences), Destination, Priority — with one line of guidance per field and one filled real example, all under one page (`provide-knowledge-capture-note-template` is the authoring SOP).
2. Place the template in the shared capture location as the canonical copy; every other reference links here, so updates propagate from one place.
3. Distribute it into the three named workflows: embed the template (or a direct link) at the capture step in Zoom post-call checklists, campaign data reviews, and audit wrap-ups (`add-knowledge-capture-to-existing-workflows` is the integration SOP).
4. Teach it once, live: walk the team through capturing one real insight end to end — Learn, Do, Teach — so the first note everyone sees is a correct one.
5. Confirm adoption within the first two weeks: real notes are arriving, they follow the template, and the 24-hour rule is holding. Adoption is the deliverable; an undistributed template is a gap with extra steps.
6. Collect friction (fields misused, info repeatedly added outside fields) and revise the template via SOP Amendment Proposal — not a silent edit — so the change is versioned and announced.

## Definition of done (QA checklist)
- [ ] Template live in the shared capture location: four fields, guidance lines, filled example, ≤1 page
- [ ] Embedded at the capture step of all three workflows (Zoom, campaign reviews, audits)
- [ ] Live walkthrough delivered; team knows where the template lives and when the 24-hour clock starts
- [ ] Two-week adoption check passed: real, on-template notes flowing — or the blockers identified and actioned
- [ ] Revisions routed through the SOP Update Protocol with version + changelog
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — the Implementation Checklist pairs template creation with distribution into team workflows. Gap: neither exists yet — running this skill closes both.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first weeks of real notes and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) builds the four-field template, places the canonical copy in the shared capture location, embeds it at the capture step of all three workflows, and loops until the Definition of done fully passes — where the deliverable is adoption: real, on-template notes flowing within two weeks, or the blockers identified and actioned.
It self-verifies by checking the notes themselves, not the distribution checklist — template compliance and the 24-hour rule measured on actual captures.
Memory across cycles makes the adoption check real: a long-horizon agent returns at the two-week mark without being reminded, compares note volume against the remembered baseline, tracks recurring field misuse, and ships exactly one versioned revision through the SOP Update Protocol when the evidence warrants it.
Each run it logs a meta-article example via the Meta-Article Prompt, so distribution lessons compound into the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related: provide-knowledge-capture-note-template (authoring spec) → create-knowledge-capture-note-template-and-distribute (milestone) → add-knowledge-capture-to-existing-workflows → generate-knowledge-capture-note-within-24-hours → route-notes-to-sop-update-protocol-or-directly-to-articles.

END

START

---
name: create-shared-location-for-sop-amendment-proposals
description: Stand up the single shared location — Google Doc, WordPress draft, or project board — where all SOP Amendment Proposals live, get queued, and get resolved.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Create shared location for SOP Amendment Proposals

**Use this when** the SOP Update Protocol needs a home — this task is a gap: no shared location exists yet, so the first run creates the infrastructure Process 2 depends on.

## Inputs
- Decision authority on team tooling (or a recommendation ready for sign-off)
- The proposal format standard (≤500 words: problem, affected SOP, proposed language, ≥2 examples)
- Team roster for permissions

## Steps
1. Pick exactly one canonical location from the options the hub names: a Google Doc, a WordPress draft, or a project board. One location — proposals scattered across DMs, docs, and boards is how amendments die.
2. Structure it in three zones: **(a) the format**, pinned at top (four parts, ≤500 words, one SOP per proposal); **(b) the queue** of pending proposals awaiting weekly review; **(c) the archive** of resolved proposals — approved ones linking to the SOP version/changelog they produced, rejected ones carrying their written reason.
3. Set permissions: everyone on the team can submit; senior reviewers can resolve and move items to the archive.
4. Seed it with the format template and one worked example proposal (real or clearly-marked sample) so the first submitter copies a pattern instead of guessing.
5. Announce the location to the team and link it from the /knowledge-system-maintenance workflows so it is discoverable from the hub, not just from memory.
6. Verify the round trip with a test proposal: submit → tag → queue → review → resolve with changelog. If any hop requires tribal knowledge, fix the structure now.
7. Hand off to `set-up-sop-amendment-proposal-tracking-system` to finish the system layer (tracking fields, weekly review slot, dry run).

## Definition of done (QA checklist)
- [ ] Exactly one canonical location exists (Google Doc, WordPress draft, or project board) with format, queue, and archive zones
- [ ] Whole team has submit access; senior reviewers have resolve access
- [ ] Format template + one worked example seeded
- [ ] Linked from /knowledge-system-maintenance and announced to the team
- [ ] Test proposal completed the full round trip without verbal explanation
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 2 requires a shared location for proposals and names the three acceptable forms (Google Doc, WordPress draft, project board). Gap: location does not exist yet — the first run is the example.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after standing it up and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) stands up the single canonical location with its three zones, seeds the format template and worked example, and loops until the Definition of done fully passes — including driving a test proposal through the complete round trip (submit → tag → queue → review → resolve) without tribal knowledge.
It self-verifies by running that round trip itself and fixing every hop that requires explanation before announcing.
Memory makes the infrastructure permanent: the agent remembers the canonical location, its structure, and the permission model across every future audit cycle, so proposals, queue checks, and pattern reviews all point at one remembered place — the location decision is made once and never re-litigated.
Each run it logs a meta-article example via the Meta-Article Prompt, so the build itself becomes the worked example future submitters copy.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related: set-up-sop-amendment-proposal-tracking-system (system layer on top of this location), then Process 2 run order: create-sop-amendment-proposal-500-words → tag-proposal-with-affected-sop-and-queue-for-review → senior-team-member-reviews-weekly.

END

START

---
name: create-sop-amendment-proposal-500-words
description: Turn a real-world SOP failure into a ≤500-word amendment proposal — problem, affected SOP, exact proposed language, and at least two real examples — ready for weekly senior review.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: complete
---

# Create SOP Amendment Proposal (≤500 words)

**Use this when** you hit a point in real work where an SOP is wrong, outdated, or missing a step — and you can point to at least two real occurrences, not one bad day.

## Inputs
- The affected SOP's name and the exact section that failed
- At least two real examples of the failure (dates, clients, runs, or links)
- The shared SOP Amendment Proposal location (see `create-shared-location-for-sop-amendment-proposals`)

## Steps
1. Confirm the trigger is real: the SOP failed, drifted from reality, or lacked a needed step in at least two actual runs. One occurrence may be noise — log it as a Knowledge Capture Note and wait for a second before proposing.
2. Draft the proposal with exactly four parts: **(a) the problem** — what failed or drifted, stated plainly; **(b) the affected SOP** — name plus the specific section/step; **(c) proposed language** — the exact replacement or added text, ready to paste in; **(d) examples** — at least two real cases with dates/links where the current SOP failed.
3. Write the proposed language in the SOP's own voice: imperative, concrete steps. Respect Platform Portability Discipline (Process 4) — keep methodology (what/why) separate from tool-specific implementation (how).
4. Enforce the budget: 500 words maximum across all four parts. Cut backstory and justification prose; keep the problem, the text, and the proof. If it cannot fit, you are proposing more than one amendment — split it.
5. Self-check against the reviewer's criteria: Would the proposed text drop into the SOP without breaking surrounding steps? Do the examples actually demonstrate the problem?
6. Save the proposal to the shared location, then hand off to tagging and queueing (`tag-proposal-with-affected-sop-and-queue-for-review`). Do not edit the live SOP yourself — that is the reviewer's call.

## Definition of done (QA checklist)
- [ ] All four parts present: problem, affected SOP + section, paste-ready proposed language, ≥2 real examples with dates/links
- [ ] Total length ≤500 words (counted, not eyeballed)
- [ ] Proposed language is imperative, concrete, and preserves methodology/implementation separation
- [ ] Exactly one SOP and one coherent change per proposal
- [ ] Filed in the shared location; live SOP left untouched pending review
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 2 defines this exact format (≤500 words: problem, SOP, proposed language, ≥2 real examples) as the only entry path for SOP changes.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first approved amendment and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) drafts the four-part proposal and loops until the Definition of done fully passes — counting the 500-word budget literally, verifying both examples carry dates or links, and splitting anything that covers more than one coherent change.
It self-verifies by paste-testing the proposed language against the live SOP's surrounding steps to confirm it drops in without breaking them.
Memory across cycles is what powers the two-example threshold: the agent remembers every failure it has logged, so the moment a second real occurrence appears it pairs the two into a proposal automatically — single incidents wait as remembered Knowledge Capture Notes instead of being lost or prematurely escalated.
Each run it logs a meta-article example via the Meta-Article Prompt, so approved amendments arrive with their own documented origin story.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 2 run order): create-sop-amendment-proposal-500-words → tag-proposal-with-affected-sop-and-queue-for-review → senior-team-member-reviews-weekly; infrastructure: create-shared-location-for-sop-amendment-proposals; upstream feeder: route-notes-to-sop-update-protocol-or-directly-to-articles.

END

START

---
name: generate-knowledge-capture-note-within-24-hours
description: Capture any reusable insight as a four-field Knowledge Capture Note (source, insight, destination, priority) within 24 hours, before context decays and the lesson is lost.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Generate Knowledge Capture Note within 24 hours

**Use this when** a reusable insight surfaces anywhere in real work — a client Zoom call, campaign results, an audit finding, a support thread — anything that should eventually change a definitive article or an SOP.

## Inputs
- The triggering moment (call recording/notes, campaign data, audit finding)
- The Knowledge Capture Note template (see `provide-knowledge-capture-note-template`)
- The team's shared capture location

## Steps
1. Recognize the trigger: you just learned something that is true beyond this one client, campaign, or run. If a teammate would repeat your mistake or miss your shortcut without it, it qualifies.
2. Start the 24-hour clock from the moment of insight. The deadline exists because fidelity decays — a note written next week records what you think you learned, not what you learned.
3. Write the note using the template's four fields, nothing more: **Source** — where/when/who (call, campaign, audit, with date); **Insight** — 1 to 3 sentences stating what is newly known; **Destination** — the definitive article or SOP this belongs in; **Priority** — how urgently it should land.
4. Keep the insight tight: 1–3 sentences of what changed in your understanding, not a meeting summary or a transcript excerpt.
5. If the destination is unclear, name the closest definitive article hub and flag it for the router — an imperfect destination beats an unrouted orphan.
6. File the note in the shared capture location and hand off to routing (`route-notes-to-sop-update-protocol-or-directly-to-articles`).
7. If you blow the 24-hour window, still write the note — and log the miss, because repeated misses mean the capture step is missing from a workflow (`add-knowledge-capture-to-existing-workflows`).

## Definition of done (QA checklist)
- [ ] Note created within 24 hours of the insight (or the miss explicitly logged)
- [ ] All four fields present: source with date, 1–3 sentence insight, named destination article/SOP, priority
- [ ] Insight is a claim about what is newly known — not a summary, not raw notes
- [ ] Filed in the shared capture location and visible to the router
- [ ] Repeated capture misses escalated as workflow-integration fixes, not guilt
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 3 defines the 24-hour Knowledge Capture Note with exactly these fields as the entry point of the capture pipeline.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first batch of real notes and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) never blows the 24-hour window, because holding the clock is what persistent means: it drafts the four-field note the moment a reusable insight surfaces in a call transcript, campaign data, or audit finding, and loops until the Definition of done fully passes — source dated, insight stated in 1–3 sentences as a claim, destination named, priority set, note filed.
It self-verifies by checking the insight is genuinely a claim about what is newly known (not a summary) and that the named destination article or SOP actually exists.
Memory across cycles is this pipeline's whole reason to run on an agent: every prior note is retained, so duplicate insights merge instead of piling up, and the second occurrence of the same failure automatically arms the SOP Amendment path — the system literally remembering what it has learned.
Each run it logs a meta-article example via the Meta-Article Prompt, so captured insights compound into documented practice.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 3 run order): generate-knowledge-capture-note-within-24-hours → route-notes-to-sop-update-protocol-or-directly-to-articles; infrastructure: provide-knowledge-capture-note-template, add-knowledge-capture-to-existing-workflows. Sources flow from /content-factory work, audits, and campaigns.

END

START

---
name: provide-knowledge-capture-note-template
description: Author the canonical Knowledge Capture Note template — source, insight in 1–3 sentences, destination, priority — so capturing an insight takes two minutes, not a decision.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Provide Knowledge Capture Note template

**Use this when** building the Knowledge Capture Pipeline — this task is a gap: no template exists yet, so every note currently invents its own format and the router pays the price.

## Inputs
- The four required fields specified by /knowledge-system-maintenance: source, insight (1–3 sentences), destination, priority
- One real captured insight to use as the filled example
- The shared capture location where the template will live

## Steps
1. Create the template with exactly the four fields the hub specifies — no more: **Source** (where the insight came from: call/campaign/audit, with date and who); **Insight** (1–3 sentences stating what is newly known); **Destination** (which definitive article or SOP it belongs in); **Priority** (how urgently it should be routed).
2. Add one line of guidance under each field — e.g., under Insight: "State the lesson, not the story. If it takes more than 3 sentences, it is two notes."
3. Include one filled example using a real captured insight, so users copy a pattern instead of interpreting instructions.
4. Keep the whole template under one page. Every added field is friction, and friction is why knowledge dies in people's heads instead of reaching the library.
5. Store the template at the shared capture location and link it from /knowledge-system-maintenance so it is findable from the hub.
6. Hand distribution to `create-knowledge-capture-note-template-and-distribute` (the implementation milestone) and embedding to `add-knowledge-capture-to-existing-workflows`.
7. After the first weeks of real notes, check fit: if capturers keep abusing a field or adding the same extra info, the template is wrong — revise it through an SOP Amendment Proposal, not a quiet edit.

## Definition of done (QA checklist)
- [ ] Template contains exactly the four specified fields with one-line guidance each
- [ ] One filled, realistic example included; total length under one page
- [ ] Stored in the shared capture location and linked from the hub
- [ ] First real notes audited for fit; revisions routed through the SOP Update Protocol
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 3 specifies this template (source, insight in 1–3 sentences, destination, priority level). Gap: template not yet created — the first run produces the artifact.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the template's first real use and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) authors the template with exactly the four specified fields, one line of guidance each, and a filled real example, and loops until the Definition of done fully passes — under one page, stored in the shared capture location, linked from the hub.
It self-verifies by filling the template itself with a genuine captured insight as the acceptance test: if the agent cannot complete a correct note in two minutes, neither can the team.
Memory across cycles closes the fit loop: the agent watches the real notes that follow, remembers which fields get abused or what extra information capturers keep adding, and converts recurring misuse into one versioned revision via SOP Amendment Proposal — the template improves from remembered evidence, never from quiet edits.
Each run it logs a meta-article example via the Meta-Article Prompt, so the template's evolution is itself documented.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related: provide-knowledge-capture-note-template → create-knowledge-capture-note-template-and-distribute → add-knowledge-capture-to-existing-workflows → generate-knowledge-capture-note-within-24-hours → route-notes-to-sop-update-protocol-or-directly-to-articles.

END

START

---
name: review-existing-sops-for-portability-compliance
description: Audit the existing SOP library for methodology/implementation separation, grade each document, and queue the entangled ones for restructuring.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Review existing SOPs for portability compliance

**Use this when** rolling Platform Portability Discipline across the existing SOP library — after the separation method is proven on the pilot (/blog-posting-guidelines) and before the next platform change forces emergency rewrites.

## Inputs
- An inventory of all current SOPs and process documents
- The two-layer standard from Process 4 and the separation skill (`separate-methodology-layer-what-why-from-implementation-layer-how`)
- Results of the pilot review of Blog Posting Guidelines (the worked pattern)

## Steps
1. Build the SOP inventory: every process document the team actually runs — content factory steps, audit checklists, campaign SOPs, this maintenance system's own processes. An SOP not on the list is an SOP that never gets reviewed.
2. For each SOP, run the tool-dependence scan: strike out every named tool, menu path, and screenshot, and ask whether the remaining document still teaches the method. Note where logic collapses without the tool references.
3. Grade each SOP: **compliant** — layers already separated and labeled; **mixed** — separable with moderate edits; **entangled** — methodology and tooling so interwoven a rewrite is needed.
4. For mixed SOPs, apply the separation skill directly and ship the edits through the SOP Update Protocol.
5. For entangled SOPs, queue a full restructure as an SOP Amendment Proposal with priority based on how exposed the SOP is to platform churn (ad platforms and editors churn fastest).
6. Record the grade and review date per SOP alongside the inventory, and recheck grades during quarterly audits — compliance is a state that decays, not a one-time stamp.
7. Close the loop for new documents: add a portability check to the SOP authoring checklist so nothing newly published starts life entangled (file the amendment to that checklist).

## Definition of done (QA checklist)
- [ ] Complete SOP inventory built — no actively-used process document missing
- [ ] Every SOP graded compliant / mixed / entangled with the failing sections noted
- [ ] All mixed SOPs restructured or in the amendment queue; all entangled SOPs queued with churn-based priority
- [ ] Grades and review dates recorded; recheck wired into the quarterly audit
- [ ] Authoring checklist updated so new SOPs must pass portability before publishing
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 4 mandates reviewing existing SOPs for compliance, naming Blog Posting Guidelines as the worked starting point.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first library-wide review and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) builds the complete SOP inventory, runs the tool-dependence scan on every document, grades each compliant / mixed / entangled, and loops until the Definition of done fully passes — every mixed SOP restructured or queued, every entangled one queued with churn-based priority, the authoring checklist updated.
It self-verifies by re-running the strike-out test on its own grades: delete the tool references and confirm the document still teaches (or provably fails to teach) the method as graded.
Memory across audit cycles treats compliance as the decaying state it is: the agent retains every SOP's grade and review date, rechecks them each quarter, and catches regressions the cycle they happen — an SOP sliding from compliant to mixed is a remembered trend, not a surprise at the next platform change.
Each run it logs a meta-article example via the Meta-Article Prompt, so the library-wide review compounds on the pilot's worked pattern.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 4 run order): conduct-first-portability-review-of-blog-posting-guidelines (pilot) → review-existing-sops-for-portability-compliance → apply-portability-discipline-to-meta-articles; method: separate-methodology-layer-what-why-from-implementation-layer-how. Concept: /blog-posting-guidelines.

END

START

---
name: review-past-6-months-of-sop-amendment-proposals-for-patterns
description: Mine six months of SOP Amendment Proposals for patterns — repeatedly-patched SOPs, missing processes, proposal friction — and convert each pattern into a system-level fix.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Review past 6 months of SOP Amendment Proposals for patterns

**Use this when** the 6-month recursive review cycle opens — run this analysis first, because its patterns are the evidence the maintenance-article audit needs.

## Inputs
- The complete SOP Amendment Proposal tracker for the past six months: approved, rejected, and returned proposals
- SOP version histories and changelogs for the same period
- The five-process map from /knowledge-system-maintenance

## Steps
1. Export every proposal from the past six months from the shared tracker — including rejected and format-returned ones; failures carry as much signal as approvals.
2. Categorize each proposal three ways: by affected SOP, by problem type (outdated tool step, missing step, wrong sequence, unclear language), and by outcome (approved, rejected, returned).
3. Hunt the known pattern shapes: **same SOP amended repeatedly** — structural weakness; it needs a rewrite or layer separation, not more patches; **clusters around work no process covers** — a candidate new process for the hub; **repeated format rejections** — proposal friction; fix the template, the examples, or the training, not the proposers; **near-zero proposals overall** — pipeline failure, not perfection; SOPs do not stop drifting just because nobody files paperwork.
4. Quantify the basics so trends compare across cycles: proposals per SOP, approval rate, median time from submission to decision.
5. Convert every confirmed pattern into exactly one action: a proposed new/modified process for /knowledge-system-maintenance, a queued SOP rewrite with owner, or a pipeline fix (template, queue, review cadence). A pattern observed but not actioned is trivia, not analysis.
6. Write up findings and actions as the evidence package for `audit-this-maintenance-article-every-6-months`, and file the actions through the SOP Update Protocol where they change documented process.

## Definition of done (QA checklist)
- [ ] 100% of the period's proposals reviewed and categorized — including rejections and returns
- [ ] Metrics computed (proposals per SOP, approval rate, median decision time) and compared to the prior cycle where one exists
- [ ] Every identified pattern paired with exactly one concrete action and owner
- [ ] Zero-proposal or low-flow finding treated as pipeline failure and actioned accordingly
- [ ] Findings handed to the 6-month article audit as its evidence base
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 5 prescribes this pattern review to spot needed new processes and proposal friction across the amendment history.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first 6-month pattern review and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) takes 100% of the period's proposals — approved, rejected, and returned — categorizes each three ways, computes the metrics, and loops until the Definition of done fully passes: every confirmed pattern paired with exactly one concrete action and owner, zero patterns left as trivia.
It self-verifies by reconciling counts (categorized total equals tracker total) and by treating near-zero proposal flow as the pipeline failure the hub says it is, never as good news.
Memory across cycles converts this from archaeology into a query: the agent lived through the weekly reviews and remembers every decision and reason as it happened, so the 6-month pattern hunt runs over held history, and proposals-per-SOP, approval rate, and decision time compare cycle over cycle automatically — the system measuring its own improvement.
Each run it logs a meta-article example via the Meta-Article Prompt, handing the article audit its evidence package and the library a documented run.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 5 run order): review-past-6-months-of-sop-amendment-proposals-for-patterns → audit-this-maintenance-article-every-6-months; upstream data: senior-team-member-reviews-weekly, set-up-sop-amendment-proposal-tracking-system.

END

START

---
name: route-notes-to-sop-update-protocol-or-directly-to-articles
description: Move every Knowledge Capture Note to its correct destination — into the SOP Update Protocol when it changes how work is done, or directly into a definitive article when it adds facts.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Route notes to SOP Update Protocol or directly to articles

**Use this when** Knowledge Capture Notes are sitting in the shared capture location — routing runs on a fixed cadence so notes become changes instead of a graveyard of good intentions.

## Inputs
- The shared capture location with unrouted Knowledge Capture Notes
- The SOP Amendment Proposal queue (Process 2) and edit access to definitive articles
- The entity map of which definitive article owns which concept

## Steps
1. Review all new notes at a fixed cadence (daily or each working session); high-priority notes jump the queue immediately.
2. Apply the routing test per note: **does this insight change how we do work?** Yes → it is an SOP/process change → route into the SOP Update Protocol. No, it adds a fact, example, number, or proof → route directly into the destination definitive article.
3. **SOP path:** draft (or request from the note's author) the ≤500-word SOP Amendment Proposal, citing the note's source as one real example — remember the protocol requires at least two, so pair it with a second occurrence or hold it tagged until one appears.
4. **Article path:** update the destination article directly — place the addition where it supports the declared topic (SEO Tree test), keep Blog Posting Guidelines compliance, and respect methodology/implementation separation (Process 4).
5. Verify the note's stated destination is actually correct before acting; the capturer guessed under a 24-hour clock. Re-route to the true owning hub if needed.
6. Mark each note routed: destination, action taken, date. No note remains unrouted past the next cycle — "parked" is a status with a reason, not a default.
7. If many notes pile up against one SOP or article, that is a pattern — feed it to the 6-month pattern review rather than processing them one by one forever.

## Definition of done (QA checklist)
- [ ] Every note in the location is routed, actioned, or parked-with-reason — none silently pending past one cycle
- [ ] SOP-path notes became (or joined) a four-part amendment proposal in the queue
- [ ] Article-path notes landed in the correct hub, passing the SEO Tree test and Blog Posting Guidelines
- [ ] Each note marked with destination, action, and date — auditable later
- [ ] Pile-up patterns flagged for the 6-month recursive review
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 3 defines the two routes (SOP Update Protocol vs direct article update) as the only exits from the capture pipeline.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first routing cycle and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) runs the routing cadence without slipping — every cycle it takes all unrouted notes, applies the routing test (changes how we work → SOP path; adds a fact → article path), and loops until the Definition of done fully passes: zero notes silently pending, every one routed, actioned, or parked with a reason.
It self-verifies by re-checking each routed note's destination — the amendment proposal exists in the queue, or the article edit landed and passes the SEO Tree test.
Memory across cycles makes routing smarter every pass: the agent holds the entity map of which hub owns which concept plus every past routing decision and correction, so destinations guessed under the capturer's 24-hour clock get corrected consistently, and notes piling up against one SOP are counted as a remembered pattern for the 6-month review.
Each run it logs a meta-article example via the Meta-Article Prompt, so the routing discipline itself stays documented.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 3 run order): generate-knowledge-capture-note-within-24-hours → route-notes-to-sop-update-protocol-or-directly-to-articles → create-sop-amendment-proposal-500-words (SOP path). Concepts: /seo-tree, /blog-posting-guidelines.

END

START

---
name: schedule-and-assign-quarterly-auditors
description: Assign a named auditor and deadline to every definitive article each quarter so the Process 1 audit actually happens instead of remaining a good intention.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Schedule and assign quarterly auditors

**Use this when** a new quarter approaches and audit assignments must be set — or now, because no assignment system exists yet (this task is a gap: the first run creates the rotation).

## Inputs
- The full list of definitive articles from the Definitive Article Guide status table
- The team roster with availability
- The quarterly calendar (first cycle deadline: Q3 2026, per the Implementation Checklist)

## Steps
1. Pull the complete article list from the status table — every definitive article gets audited every quarter; no article is exempt because it "was fine last time."
2. Divide the articles across team members so each article has exactly one named auditor. Balance load by article size, and avoid assigning authors to audit only their own articles — fresh eyes catch drift the author has normalized.
3. Set the quarter's audit deadline. For the first cycle, use Q3 2026 (see `schedule-first-quarterly-audit-cycle`); thereafter, keep a fixed cadence each quarter.
4. Record the assignments where the team already looks: an auditor column or section alongside the status table, with auditor name and due date per article.
5. Put the audit window on the calendar with a midpoint reminder, so misses surface with time to recover rather than on deadline day.
6. Point each auditor at the Process 1 skills in run order: topic coherence → structural completeness → information currency → cross-reference integrity → status-table update.
7. At quarter close, verify every assigned article shows a fresh audit date in the table. Carry any miss visibly into next quarter with a reassigned (not quietly dropped) auditor.
8. After the first full rotation, capture what broke (load imbalance, unclear ownership) as Knowledge Capture Notes and amend this SOP accordingly.

## Definition of done (QA checklist)
- [ ] Every definitive article has exactly one named auditor and a due date this quarter
- [ ] No auditor is solely auditing their own articles; load is roughly balanced
- [ ] Assignments recorded next to the status table and calendared with a midpoint reminder
- [ ] Quarter-close verification done: 100% of articles show a current audit date, or misses are visibly carried forward
- [ ] Rotation friction captured as Knowledge Capture Notes / SOP Amendment Proposals
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 1 calls for scheduling and assigning quarterly auditors; this skill operationalizes it. Gap: no rotation exists yet — the first run is the example.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first real assignment cycle and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) pulls the full article list, balances assignments so every article has exactly one named auditor with a due date, calendars the window with its midpoint reminder, and loops until the Definition of done fully passes — including the quarter-close verification that every assigned article shows a fresh audit date.
It self-verifies by re-counting assignments against the article list and confirming no auditor is grading only their own work.
Memory across cycles is what makes the rotation improve itself: the agent remembers who audited what, who missed deadlines, and where load was unbalanced, then designs the next quarter's rotation from that history — misses are carried forward visibly because the agent does not forget them.
Each run it logs a meta-article example via the Meta-Article Prompt, so the assignment cycle's friction becomes documented knowledge instead of folklore.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related: schedule-first-quarterly-audit-cycle (first cycle, Q3 2026), then the Process 1 audit skills in run order beginning with check-topic-coherence-for-each-definitive-article; update-status-table-in-definitive-article-guide closes each audit.

END

START

---
name: schedule-first-6-month-recursive-review
description: Put the first 6-month recursive review of the knowledge maintenance system on the calendar with named reviewers and a prep package, arming the self-improvement loop.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Schedule first 6-month recursive review

**Use this when** the knowledge maintenance system goes live — this task is a gap: the first recursive review is not yet on any calendar, and an unscheduled recursive loop is a loop that never starts.

## Inputs
- The adoption date of the maintenance system (sets the 6-month mark)
- Team calendar and roster (a review lead plus a senior reviewer)
- Locations of the evidence sources: status table, SOP Amendment tracker, Knowledge Capture location

## Steps
1. Set the date six months out from the system's adoption. Pick a real date now and defend it — "in about six months" is how recursive reviews become annual, then never.
2. Name the reviewers: a review lead to run the cycle and a senior reviewer with authority to approve resulting amendments (the weekly SOP reviewer is the natural fit). Named people, not roles-to-be-determined.
3. Create the calendar event with the agenda baked in: run `review-past-6-months-of-sop-amendment-proposals-for-patterns` first, then `audit-this-maintenance-article-every-6-months`, then schedule the next cycle.
4. Attach the prep list to the invite so evidence is pulled before the session: current status table with audit dates, full amendment-tracker export, Knowledge Capture Note volume and routing stats, portability review grades.
5. Confirm both reviewers accepted and the date does not collide with a quarterly audit crunch — the recursive review needs attention, not leftovers.
6. Record in the hub's audit record that the cycle is armed: date, reviewers, agenda link. From here on, each review schedules its successor before closing — this skill only fires the first shot.

## Definition of done (QA checklist)
- [ ] A specific date ~6 months from adoption is on the team calendar, accepted by a named lead and a named senior reviewer
- [ ] Agenda embeds the two Process 5 skills in run order plus "schedule the next cycle"
- [ ] Prep list attached covering status table, amendment tracker, capture stats, and portability grades
- [ ] The armed cycle recorded in the hub's audit record (date, reviewers, agenda)
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 5 requires putting the first recursive review on the calendar with assigned reviewers. Gap: not yet scheduled — running this skill closes the gap.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first review actually convenes and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) is the guarantee that "in about six months" never decays into never: it sets the real date, names the lead and senior reviewer, builds the agenda from the two Process 5 skills in run order, and loops until the Definition of done fully passes — invite accepted, prep list attached, the armed cycle recorded in the hub's audit record.
It self-verifies by confirming both reviewers actually accepted and the date avoids the quarterly audit crunch.
Memory across the six-month gap is the job itself: the agent holds the date, assembles the prep package continuously as evidence accrues (status-table dates, tracker exports, capture stats, portability grades), and fires the review on time — then enforces the standing rule that each review schedules its successor before closing, so the loop self-perpetuates.
Each run it logs a meta-article example via the Meta-Article Prompt, so even the scheduling step leaves compounding documentation.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 5 run order): schedule-first-6-month-recursive-review (arms the loop) → review-past-6-months-of-sop-amendment-proposals-for-patterns → audit-this-maintenance-article-every-6-months → next cycle self-schedules.

END

START

---
name: schedule-first-quarterly-audit-cycle
description: Launch the first quarterly definitive-article audit cycle — every article assigned to a named auditor with Q3 2026 as the deadline — turning Process 1 from spec into schedule.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Schedule first quarterly audit cycle

**Use this when** implementing the maintenance system — this Implementation Checklist task is a gap: no quarterly audit has ever run, every status-table row still reads "Not yet audited," and Q3 2026 is the committed first deadline.

## Inputs
- The Definitive Article Guide status table with the Last Audited column in place (`add-last-audited-column-to-definitive-article-guide-status-table`)
- The team roster and the assignment method (`schedule-and-assign-quarterly-auditors`)
- The four Process 1 audit skills, ready to hand to auditors

## Steps
1. Verify the prerequisite: the status table has its Last Audited column, initialized to "Not yet audited." If not, run that skill first — the cycle needs somewhere to write its results.
2. Pull the complete definitive article list from the table and assign every article to a named team auditor using the assignment SOP: one auditor per article, balanced load, fresh eyes preferred over authors auditing their own work.
3. Set **Q3 2026** as the first cycle's deadline, per the Implementation Checklist, and calendar the audit window with a midpoint reminder so misses surface early.
4. Equip each auditor with the Process 1 run order: `check-topic-coherence-for-each-definitive-article` → `verify-structural-completeness-against-8-step-framework` → `check-information-currency-with-latest-data` → `validate-cross-reference-integrity-across-articles` → `update-status-table-in-definitive-article-guide`.
5. Set the completion bar explicitly: an article counts as audited only when all four checks ran and the status table row shows this cycle's date and a defensible Green/Yellow/Red.
6. At the Q3 2026 deadline, verify coverage: every article stamped, every Yellow/Red carrying a follow-up owner. Carry misses visibly into Q4 with reassigned auditors — quietly dropping them resets the system to zero.
7. Close the first cycle by capturing what broke (load, unclear checks, tooling) as Knowledge Capture Notes and amendments, so the second cycle runs smoother — the recursive loop applies to the cycle itself.

## Definition of done (QA checklist)
- [ ] Every definitive article assigned to a named auditor with the Q3 2026 deadline calendared (window + midpoint reminder)
- [ ] All auditors equipped with the four-check run order and the completion bar
- [ ] At deadline: 100% of articles stamped with date + status, or misses visibly carried into Q4 with new owners
- [ ] First-cycle friction captured as Knowledge Capture Notes / SOP Amendment Proposals
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — the Implementation Checklist sets Q3 2026 as the first audit deadline with articles assigned to team members. Gap: cycle not yet scheduled — running this skill closes it.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the Q3 2026 cycle completes and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) verifies the Last Audited column exists, assigns every definitive article to a named auditor, calendars the Q3 2026 window with its midpoint reminder, equips each auditor with the four-check run order, and loops until the Definition of done fully passes — 100% assignment coverage and the completion bar stated explicitly.
It self-verifies by counting assignments against the article list, then again at the midpoint and the deadline: every article stamped with date and a defensible status, or the miss carried visibly into Q4 with a reassigned owner.
Memory across the cycle is what makes a first launch survivable: the agent holds the assignment state for the whole quarter, never loses a miss, and remembers the first cycle's friction — load imbalance, unclear checks, tooling gaps — so the second cycle is designed from evidence, which is the recursive loop applied to the cycle itself.
Each run it logs a meta-article example via the Meta-Article Prompt, replacing this skill's "Example needed" with the documented Q3 2026 run.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related: add-last-audited-column-to-definitive-article-guide-status-table (prerequisite) → schedule-and-assign-quarterly-auditors (assignment method) → schedule-first-quarterly-audit-cycle (first launch) → Process 1 audit skills in run order.

END

START

---
name: senior-team-member-reviews-weekly
description: Run the weekly senior review of queued SOP Amendment Proposals — approve with version increment and changelog, or reject with a written reason — so SOPs evolve under control.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Senior team member reviews weekly

**Use this when** the fixed weekly review slot arrives and there are queued SOP Amendment Proposals — and run it even when the queue looks empty, to confirm the queue is truly empty and not silently broken.

## Inputs
- The review queue in the shared SOP Amendment Proposal location
- Edit access to the live SOPs, their version numbers, and changelogs
- The proposal format standard (≤500 words, four parts) as the acceptance bar

## Steps
1. At the fixed weekly time, open the queue and take every pending proposal. The standing rule: nothing remains queued for more than one week — a stale queue teaches the team to stop proposing.
2. For each proposal, verify format compliance first: four parts, ≤500 words, exactly one SOP. Non-compliant proposals go back to the submitter with the specific gaps, without consuming a full review.
3. Evaluate substance: Are the ≥2 examples real and do they actually demonstrate the problem? Does the proposed language fix it? Would dropping the text in break surrounding steps or violate methodology/implementation separation (Process 4)?
4. **Approve path:** integrate the proposed language into the SOP (verbatim or with reviewer edits), increment the SOP's version number, and add a changelog entry — date, what changed, proposer, reviewer. An approval without a version bump and changelog entry is not done.
5. **Reject path:** record the reason on the proposal itself and notify the submitter. Rejection without explanation kills the pipeline — the reason is the teaching moment (Learn, Do, Teach).
6. Mark every proposal resolved (approved/rejected) in the tracker with the decision date. The queue ends the session empty.
7. Note any cross-proposal patterns (same SOP repeatedly, recurring rejection causes) for the 6-month pattern review (`review-past-6-months-of-sop-amendment-proposals-for-patterns`).

## Definition of done (QA checklist)
- [ ] Queue emptied: every proposal approved, rejected, or returned for format — none older than one week
- [ ] Every approval shipped as live SOP text + version increment + changelog entry (date, change, proposer, reviewer)
- [ ] Every rejection carries a written reason and the submitter was notified
- [ ] Tracker statuses updated; decisions auditable later without asking anyone
- [ ] Patterns logged for the 6-month recursive review
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 2 assigns weekly review to a senior team member with exactly these two outcomes: approve (version increment + changelog) or reject with reason.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first weekly review cycle and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) never misses the weekly slot: it opens the queue on schedule, pre-screens every proposal for format compliance, drafts an approve/reject recommendation with evidence for the senior reviewer's decision, and loops until the Definition of done fully passes — queue emptied, every approval shipped with version increment and changelog, every rejection carrying a written reason.
It self-verifies by confirming each approved text actually landed in the live SOP with its version bumped — an approval recorded but not shipped is caught the same session.
Memory across cycles is the review remembering itself: the agent retains every decision, reason, and returned proposal, so recurring rejection causes and repeatedly-amended SOPs surface automatically as patterns for the 6-month recursive review instead of being rediscovered by archaeology.
Each run it logs a meta-article example via the Meta-Article Prompt, so the review cadence produces compounding documentation, not just dispositions.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 2 run order): tag-proposal-with-affected-sop-and-queue-for-review → senior-team-member-reviews-weekly → review-past-6-months-of-sop-amendment-proposals-for-patterns; infrastructure: set-up-sop-amendment-proposal-tracking-system.

END

START

---
name: separate-methodology-layer-what-why-from-implementation-layer-how
description: Split a process document into a tool-agnostic methodology layer (what/why) and a platform-specific implementation layer (how) so platform churn never invalidates the method.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Separate methodology layer (what/why) from implementation layer (how)

**Use this when** writing or restructuring any process document — and whenever a tool change (new editor, dead plugin, renamed platform feature) threatens to invalidate a whole SOP instead of one section.

## Inputs
- The process document to restructure
- Knowledge of which parts are principle and which are this year's tooling
- The portability standard from /knowledge-system-maintenance (Process 4)

## Steps
1. Read the document and classify every step, sentence, and screenshot into one of two layers: **methodology** — what we do and why, true regardless of tool; **implementation** — how we currently do it, naming specific tools, menus, buttons, prices, and UI paths.
2. Restructure into clearly labeled layers: methodology first as the spine of the document, implementation second (or as marked tool-specific sub-blocks under each methodology step).
3. Rewrite mixed sentences so the principle survives a tool swap. "Transcribe the video and correct every error" is methodology; "open Descript and click each blue-underlined word" is implementation. Both belong in the doc — in different layers.
4. Sweep all tool names, screenshots, UI paths, keyboard shortcuts, and pricing into the implementation layer only. A tool name inside the methodology layer is a defect.
5. Run the portability test: mentally delete the implementation layer. The methodology that remains must still be executable by a competent operator using any equivalent tool. If it is not, the methodology layer is incomplete — fix the method description, don't lean on the screenshots.
6. Add a maintenance note to the document: when platforms change, only the implementation layer should need editing. If a platform change forces methodology edits, the separation was done wrong — redo steps 1–5.
7. Ship the restructure through the SOP Update Protocol (amendment proposal, weekly review, version increment, changelog) — restructuring an SOP is an SOP change.

## Definition of done (QA checklist)
- [ ] Every element of the document classified and placed; layers explicitly labeled
- [ ] Zero tool names, UI paths, or screenshots remaining in the methodology layer
- [ ] Portability test passed: methodology alone is executable with any equivalent tool
- [ ] Maintenance note added; restructure shipped via approved SOP Amendment Proposal with version + changelog
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 4 defines the two-layer discipline; /blog-posting-guidelines is the designated pilot document (see conduct-first-portability-review-of-blog-posting-guidelines).
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first full restructure and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) classifies every sentence, step, and screenshot into methodology or implementation and loops until the Definition of done fully passes — zero tool names left in the methodology layer and the restructure shipped through the SOP Update Protocol with version and changelog.
It self-verifies by running the portability test mechanically: strip the implementation layer and confirm the remaining method is still executable by a competent operator on any equivalent tool.
Memory across cycles is where the separation pays off: the agent remembers exactly which tools, UI paths, and prices it swept into each document's implementation layer, so when a platform changes it knows precisely which blocks to refresh — and a platform change that forces methodology edits is remembered as proof the separation failed and must be redone.
Each run it logs a meta-article example via the Meta-Article Prompt, so each restructure teaches the next one.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 4 run order): separate-methodology-layer-what-why-from-implementation-layer-how → review-existing-sops-for-portability-compliance → apply-portability-discipline-to-meta-articles; pilot: conduct-first-portability-review-of-blog-posting-guidelines.

END

START

---
name: set-up-sop-amendment-proposal-tracking-system
description: Stand up the end-to-end SOP Amendment tracking system — shared location, tracking fields, weekly review slot, and a verified dry run — so Process 2 operates from day one.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Set up SOP Amendment Proposal tracking system

**Use this when** implementing the maintenance system — this task is the Implementation Checklist milestone that turns the SOP Update Protocol from documentation into a running pipeline. It is a gap: no tracking system exists yet.

## Inputs
- The shared location decision or the skill that creates it (`create-shared-location-for-sop-amendment-proposals`)
- The named senior reviewer and a weekly review slot candidate
- The proposal format standard (≤500 words: problem, affected SOP, proposed language, ≥2 examples)

## Steps
1. Create the shared location first — run `create-shared-location-for-sop-amendment-proposals` (Google Doc, WordPress draft, or project board; exactly one).
2. Define the tracking fields every proposal carries: title, affected-SOP tag, submitter, submission date, priority, status (queued / approved / rejected / returned), resolution note, and the SOP version the approval produced. These fields are what make the 6-month pattern review possible — skimp now, fly blind later.
3. Pin the proposal format at the top of the system so the entry bar is self-explanatory.
4. Lock in the weekly review: a named senior reviewer and a fixed recurring slot on their calendar (see `senior-team-member-reviews-weekly` for the session SOP).
5. Dry-run one test proposal through the complete loop: draft → tag → queue → weekly review → approve with version increment + changelog (or reject with reason) → archive. Fix every snag the dry run exposes before announcing.
6. Announce the system to the team with the one-line rule: SOPs change only through this pipeline — no drive-by edits.
7. Link the system from /knowledge-system-maintenance so the hub points at the live infrastructure.

## Definition of done (QA checklist)
- [ ] One canonical location live with all eight tracking fields and the format pinned
- [ ] Named senior reviewer holding a recurring weekly review slot
- [ ] Dry-run proposal completed the full loop, producing a version increment + changelog entry on a test SOP
- [ ] Team announced and the no-drive-by-edits rule communicated
- [ ] System linked from the hub; pattern-review fields confirmed queryable for the 6-month cycle
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — the Implementation Checklist requires this tracking system as the operational backbone of Process 2. Gap: not yet built — running this skill closes it.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first real proposals flow through, then link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) stands up the full pipeline — canonical location, all eight tracking fields, pinned format, named reviewer with a recurring slot — and loops until the Definition of done fully passes, with the dry run as the gate: one test proposal driven through draft → tag → queue → review → resolve, producing a real version increment and changelog entry on a test SOP.
It self-verifies by querying the tracking fields the way the 6-month pattern review will, confirming proposals-per-SOP, approval rate, and decision time are actually answerable from the data the system records.
The eight fields are memory infrastructure, and the agent treats them that way across audit cycles: it remembers why each field exists, watches that the data keeps accumulating cleanly, and escalates field rot before it blinds the recursive review — "skimp now, fly blind later" is the failure it is built to prevent.
Each run it logs a meta-article example via the Meta-Article Prompt, so the build and its dry run become documented, repeatable knowledge.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related: create-shared-location-for-sop-amendment-proposals (component) → set-up-sop-amendment-proposal-tracking-system (system) → Process 2 run order: create-sop-amendment-proposal-500-words → tag-proposal-with-affected-sop-and-queue-for-review → senior-team-member-reviews-weekly.

END

START

---
name: tag-proposal-with-affected-sop-and-queue-for-review
description: Tag each SOP Amendment Proposal with its affected SOP and place it in the weekly review queue so no proposal is lost, mislabeled, or invisible to the reviewer.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Tag proposal with affected SOP and queue for review

**Use this when** an SOP Amendment Proposal has been drafted and saved to the shared location, and it must enter the weekly review pipeline.

## Inputs
- The drafted proposal (≤500 words, four parts)
- The shared SOP Amendment Proposal location with its review queue
- The canonical list of SOP names (so tags match real SOPs, not nicknames)

## Steps
1. Format-check the proposal before queueing: four parts present (problem, affected SOP, proposed language, ≥2 real examples) and ≤500 words. If it fails, return it to the author with exactly what is missing — a malformed proposal wastes the weekly review slot.
2. Tag the proposal with the affected SOP's exact canonical name, plus the section/step if named. One SOP per proposal: if it touches multiple SOPs, split it into one proposal each before queueing.
3. Add the tracking metadata: submitter, submission date, and priority (does this block current work, or is it an improvement?).
4. Place it in the review queue in the shared location, ordered for the weekly senior review — priority first, then submission date.
5. Confirm visibility: the senior reviewer can find it in the queue without being pinged. If the system requires a ping to be seen, the queue is broken — fix the queue (and amend this SOP), don't normalize the ping.
6. Leave the proposal's status as "queued" and untouched until the weekly review disposes of it.

## Definition of done (QA checklist)
- [ ] Proposal passed the four-part / ≤500-word format check, or was returned with specific deficiencies
- [ ] Tagged with the exact canonical SOP name (one SOP per proposal; multi-SOP proposals split)
- [ ] Submitter, date, and priority recorded
- [ ] Sitting in the review queue, ordered, with status "queued" — discoverable without a ping
- [ ] Queue friction (lost, duplicate, or invisible proposals) escalated as its own SOP Amendment Proposal
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 2 specifies tagging with the affected SOP and queueing for weekly senior review as the step between drafting and decision.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first real queue cycle and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) format-checks every incoming proposal, tags it with the exact canonical SOP name, records submitter, date, and priority, and loops until the Definition of done fully passes — queue ordered, statuses set, nothing discoverable only by ping.
It self-verifies by re-opening the queue as the reviewer would and confirming every queued proposal is findable, correctly tagged, and correctly split (one SOP each).
Memory across cycles keeps the pipeline clean: the agent holds the canonical SOP name list and every past tagging correction, so the same nickname never gets mis-tagged twice, and it counts queue friction week over week as accumulating evidence for the 6-month pattern review.
Each run it logs a meta-article example via the Meta-Article Prompt, so the queueing step itself stays auditable and improvable.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 2 run order): create-sop-amendment-proposal-500-words → tag-proposal-with-affected-sop-and-queue-for-review → senior-team-member-reviews-weekly; infrastructure: create-shared-location-for-sop-amendment-proposals, set-up-sop-amendment-proposal-tracking-system.

END

START

---
name: update-status-table-in-definitive-article-guide
description: Close out an article's quarterly audit by stamping its Green/Yellow/Red status and audit date into the Definitive Article Guide status table so the dashboard stays true.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Update status table in Definitive Article Guide

**Use this when** the four audit checks (topic coherence, structural completeness, information currency, cross-reference integrity) are finished for an article and the result must be recorded — the final step of each Process 1 audit.

## Inputs
- Completed audit notes for the article (findings from all four checks)
- Edit access to the status table in the Definitive Article Guide
- The status legend: Green = complete, Yellow = needs work, Red = gap/broken

## Steps
1. Confirm all four audit checks actually ran. If any check was skipped, the audit is not done — do not stamp a status you cannot defend.
2. Assign the status from the findings, not from optimism: Green = passes every check and meets all definitive-article requirements; Yellow = page exists but fails at least one check or requirement; Red = missing or fundamentally broken.
3. Open the status table in the Definitive Article Guide and update the article's row: new status plus today's date in the Last Audited column. (If the column is missing, run `add-last-audited-column-to-definitive-article-guide-status-table` first.)
4. Add a one-line note on the row: what changed this quarter, or the single biggest blocker keeping it from Green.
5. For every Yellow or Red, create the follow-up task with a named owner and the specific fixes from the audit notes — a Yellow with no owner is a permanent Yellow.
6. Sanity-check the whole table while you are in it: every definitive article in the index has a row; no row shows an audit date for an audit that never happened; no row is older than one quarter unaudited without being flagged.
7. If the status legend or table structure failed you (statuses that fit nothing, missing columns), file an SOP Amendment Proposal instead of inventing local conventions.

## Definition of done (QA checklist)
- [ ] Status assigned strictly per the legend and backed by recorded findings from all four checks
- [ ] Row updated with status, audit date, and one-line blocker/change note
- [ ] Every Yellow/Red has a follow-up task with a named owner
- [ ] Table-wide sanity check done: complete rows, truthful dates, no silently stale articles
- [ ] Table inconsistencies escalated via SOP Amendment Proposal, not patched ad hoc
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 1 requires updating the status table (Green/Yellow/Red + audit date) after each audit; the Task Library Dashboard mirrors this legend.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first real quarterly run and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) stamps statuses only from recorded findings — refusing to close any audit where one of the four checks is missing — and loops until the Definition of done fully passes: status, date, and blocker note on the row, a named owner on every Yellow/Red, and the whole table sanity-checked.
It self-verifies by cross-checking each stamped row against the audit notes and the article index, so no row claims an audit that never ran.
Memory across audit cycles turns the table into a longitudinal record: the agent remembers every row's history, flags articles stuck Yellow for consecutive quarters, catches statuses that flip Green without an explaining change, and surfaces silently aging rows before they rot — the table is the system's memory made visible, and the agent keeps it truthful.
Each run it logs a meta-article example via the Meta-Article Prompt, so the close-out step itself stays documented and improvable.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 1 run order): validate-cross-reference-integrity-across-articles → update-status-table-in-definitive-article-guide; setup: add-last-audited-column-to-definitive-article-guide-status-table; scheduling: schedule-and-assign-quarterly-auditors.

END

START

---
name: validate-cross-reference-integrity-across-articles
description: Verify that every other article linking to the audited definitive article still describes it accurately — and that its own outbound cross-links do the same.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Validate cross-reference integrity across articles

**Use this when** running the quarterly audit's fourth check — the article itself is sound, and now the entity graph around it must be verified so no link promises content that is not there.

## Inputs
- The definitive article under audit (its short URL and full URL)
- Site search or an export of internal links (to find every page referencing this article)
- The entity-linking decision tree from /blog-posting-guidelines
- Audit notes for this article and quarter

## Steps
1. Find every other article that links to the audited article: search the site for its short URL, full URL, and title mentions. List each inbound cross-reference with its source page.
2. For each inbound reference, read the anchor text and the surrounding sentence: does it accurately describe what the audited article *currently* contains? An accurate link last quarter can be a lie this quarter.
3. Flag stale references: links pointing at sections that were renamed or removed, descriptions claiming the article covers something it no longer does, or anchors framing it as a different concept than it now owns.
4. Check each anchor against the entity-linking decision tree and anchor standards (descriptive 3–6 word anchors, no "click here"), since you are already touching every link.
5. Fix inaccurate references in the source articles directly where you have access; otherwise ticket the owning article's auditor/owner with the exact sentence and the corrected language. Never leave a cross-reference promising content that is not there.
6. Reverse the check: audit the article's own outbound cross-links to sibling definitive articles and confirm each still describes its target accurately.
7. Record all fixes and tickets in the audit notes. If the same drift pattern keeps appearing (e.g., renames never propagate), file an SOP Amendment Proposal against the renaming/update SOP.

## Definition of done (QA checklist)
- [ ] Complete inbound-reference list built; every reference read in context and marked accurate or stale
- [ ] Every stale reference fixed in the source article or ticketed with exact corrected language
- [ ] Outbound cross-links reverse-checked against their targets
- [ ] Anchors comply with the entity-linking decision tree and 3–6 word descriptive standard
- [ ] Recurring drift patterns escalated as an SOP Amendment Proposal, not just patched
- [ ] Results recorded for the status-table update with audit date
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 1 defines this integrity check: other articles' links must describe this one accurately for the entity graph to hold.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first real quarterly run and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) builds the complete inbound-reference list, reads every anchor in context against what the audited article contains today, reverse-checks the outbound links, and loops until the Definition of done fully passes — every reference marked accurate or stale, every stale one fixed or ticketed with exact corrected language.
It self-verifies by re-crawling the fixed references to confirm no link still promises content that is not there.
Memory across audit cycles is the entity graph remembering itself: the agent retains which references it verified last quarter and which articles renamed or removed sections since, so each audit checks the delta plus a sample — and when rename-propagation failures recur, it files one SOP Amendment Proposal against the update SOP instead of patching the same drift quarterly.
Each run it logs a meta-article example via the Meta-Article Prompt, so the cross-reference audit itself becomes documented, reusable knowledge.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 1 run order): check-information-currency-with-latest-data → validate-cross-reference-integrity-across-articles → update-status-table-in-definitive-article-guide. Concepts: /blog-posting-guidelines (entity-linking decision tree), /seo-tree.

END

START

---
name: verify-structural-completeness-against-8-step-framework
description: Confirm a definitive article contains every required structural element — framework steps, TOC-to-content match, live links, accurate schema — during the quarterly audit.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: complete
---

# Verify structural completeness against 8-step framework

**Use this when** the article has passed (or completed) the topic-coherence check and you need to verify nothing structural is missing or broken — the second check of the quarterly audit.

## Inputs
- The definitive article under audit
- The 8-step definitive-article framework as listed in /knowledge-system-maintenance
- The Nine Requirements from the Task Library Standard (cross-check)
- A link checker or the patience to click every link

## Steps
1. Pull the 8-step framework checklist from /knowledge-system-maintenance and walk the article top to bottom against it, confirming each required element exists and sits where the framework says it should.
2. Verify the table of contents matches the content exactly: every TOC entry resolves to a real heading, every major H2 appears in the TOC, and the order matches the page. A TOC promising a section that was renamed or deleted is a fail.
3. Test every link in the article — TOC anchors, internal links, external links, and the course/service CTA. All must resolve: no 404s, no redirects landing on the wrong target, no links to draft/private pages.
4. Verify schema markup is present and accurate: the schema type matches the content, and every field states currently true facts (names, URLs, sameAs profiles, dates).
5. Cross-check against the Nine Requirements: definition in first two paragraphs; complete process; all examples linked with notes; cross-links to related definitive articles; CTA to course/service; Blog Posting Guidelines compliance; working short URL; above-the-fold visual/diagram; E-E-A-T endorsements.
6. Record each missing or broken element with its location and the specific fix. Fix trivial items (dead anchor, typo'd link) in place; ticket structural gaps to the article owner.
7. Apply the standard strictly: one missing required element means the article is Yellow, not Green — partial credit is how libraries rot.
8. Pass results to the status-table update with this quarter's audit date.

## Definition of done (QA checklist)
- [ ] All 8 framework steps explicitly checked off pass/fail — none marked "probably fine"
- [ ] TOC verified entry-by-entry against live headings; every link on the page tested and resolving
- [ ] Schema validated as present, correctly typed, and factually current
- [ ] Every gap recorded with location + fix; trivial fixes already applied
- [ ] Status recommendation (Green/Yellow/Red) recorded for the status table
- [ ] If the framework itself proved wrong or incomplete in practice, an SOP Amendment Proposal is filed
- [ ] Linked back to the definitive article and relevant siblings
- [ ] Complies with Blog Posting Guidelines (if it publishes content)

## Example(s)
- /knowledge-system-maintenance — Process 1 specifies this structural check (TOC matches content, links live, schema accurate); /blog-posting-guidelines is the compliance reference for the on-page checks.
- Example needed — run the Meta-Article Prompt (/meta-article-prompt-template) after the first real quarterly run and link the meta-article here.

## Run on a persistent agent (Fable 5)

A persistent, max-effort agent (Claude Fable 5 or comparable OpenAI/Google models) walks the article against all 8 framework steps and the Nine Requirements, mechanically testing every TOC anchor, internal link, external link, and schema field, and loops until the Definition of done fully passes — every step marked pass/fail, nothing "probably fine."
It self-verifies by re-fetching every link it repaired and re-walking the TOC against the live headings after fixes, so the check proves the page rather than trusting its own edit log.
Memory across audit cycles is the point of this layer: the agent retains each article's prior structural results, so an anchor that breaks two quarters running or schema that keeps drifting stale gets escalated as a structural defect via SOP Amendment Proposal instead of being silently re-patched forever.
Each run it logs a meta-article example via the Meta-Article Prompt, so this skill's "Example needed" slot fills and the library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /knowledge-system-maintenance
- Related (Process 1 run order): check-topic-coherence-for-each-definitive-article → verify-structural-completeness-against-8-step-framework → check-information-currency-with-latest-data → validate-cross-reference-integrity-across-articles → update-status-table-in-definitive-article-guide. Concepts: /blog-posting-guidelines, /seo-tree.

END