Task Library
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
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
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
File in the zip: skills/knowledge-system-maintenance/separate-methodology-layer-what-why-from-implementation-layer-how.md. Download the Task Library zip.
Index: Task Library. Article guidelines.