Acknowledgments
This note records lineage for Merlon Docs’ documentation philosophy. It supports academic and intellectual integrity. It is not an operative instruction set — agents follow the parent skill and Shard single responsibility and idea mitosis.
What Merlon Docs adapted
Section titled “What Merlon Docs adapted”| Source | What we took | What we did not import wholesale |
|---|---|---|
| Single responsibility (software design) | One reason to change, applied to documentation shards (concern × audience × job) | Class/module SRP as a code style guide inside durable docs |
| Library / information architecture practice | Classify and shelve settled concepts so retrieval stays trustworthy | A full cataloging standard or library system |
| Diátaxis (Daniele Procida, 2020) | Four documentation needs (tutorial, how-to, reference, explanation) as a job axis for mitosis | Requiring every guide tree to be four Diátaxis top-level folders |
| Cynefin (Dave Snowden and collaborators) | Sense-making for settled vs emergent ideas — durable shards hold current Clear/Complicated truth; probes stay out of durable guides | Full Cynefin methods, workshops, or domain jargon in every shard |
| Product development practice (epics, stories, BDD, TDD) | Discovery and verification belong in process tools; durable shards hold as-it-works-now intent | Treating epics/stories as Merlon Docs content types |
Merlon Docs’ default Code Repository Archetype (features / client / developer / glossary) is an audience-and-job packaging for software systems. A project can define other archetypes on the same engine without changing the skill.