Evergreen Technical Book
Core Lens
Technical books become durable when the printed or stable manuscript teaches long-lived principles, decision frames, mental models, and workflows while volatile commands, UI walkthroughs, vendor details, and version-specific steps live in updateable companion resources.
Use this skill to:
- Decide what belongs in a technical book versus a website, repo, worksheet, video, or checklist.
- Reduce version drift without making the book abstract.
- Design update policies for companion resources.
- Keep self-hosting, DevOps, software, or infrastructure books useful for years.
- Revise drafts that are overloaded with tool minutia.
Reference Routing
| Need |
Read |
| Evergreen concepts and terminology |
references/core/knowledge.md |
| Durability and split rules |
references/core/rules.md |
| Book vs companion examples |
references/core/examples.md |
| Fast durability checklist |
references/core/checklist.md |
| Split book and companion resources |
workflows/split-book-and-companion.md |
Workflow
1. Identify The Durable Promise
State the reader outcome that should remain valuable for several years.
If the promise depends on one vendor, one UI, or one narrow tool version, decide whether the book is intentionally edition-based or should be reframed.
2. Classify Content By Half-Life
Tag each major section or artifact:
- Durable: concepts, tradeoffs, failure modes, principles, mental models.
- Semi-durable: workflows, architecture patterns, checklists, example configurations.
- Volatile: UI clicks, prices, vendor policies, exact package versions, screenshots, short-lived tools.
3. Split The Content
Keep the book concrete, but move volatile detail to companion resources when it would quickly date the manuscript.
The book should still deliver the core promise without requiring an upsell, hidden resource, or fragile link.
4. Design Companion Resources
For each companion item, define:
- Purpose.
- Owner.
- Update trigger.
- Stable URL or repository path.
- Version or last-reviewed note.
- How the book references it without breaking if it changes.
5. Add Update Hooks
Create a maintenance plan:
- Versioned examples.
- Changelog or last-reviewed dates.
- Issue/report path for readers.
- Periodic review cadence.
- Replacement policy for stale tools.
Output Format
When helping with an evergreen technical book, return:
- Durability diagnosis.
- Book vs companion split table.
- Recommended scope cuts or moves.
- Companion resource plan.
- Update policy and review cadence.
- Manuscript wording for volatile references.
Quality Bar
Do not solve drift by making the book vague. Keep the reader's path concrete while making volatile details easy to update and easy to skip when they age.
1---2name: evergreen-technical-book3description: Keep technical nonfiction durable by separating timeless concepts, decision frameworks, and reader outcomes from fast-changing tool walkthroughs, UI steps, versions, vendor details, and companion resources. Use when scoping, outlining, revising, or updating technical books, self-hosting guides, software manuals, DevOps books, or other technical manuscripts that risk becoming outdated.4license: MIT5---67# Evergreen Technical Book89## Core Lens1011Technical books become durable when the printed or stable manuscript teaches long-lived principles, decision frames, mental models, and workflows while volatile commands, UI walkthroughs, vendor details, and version-specific steps live in updateable companion resources.1213Use this skill to:1415- Decide what belongs in a technical book versus a website, repo, worksheet, video, or checklist.16- Reduce version drift without making the book abstract.17- Design update policies for companion resources.18- Keep self-hosting, DevOps, software, or infrastructure books useful for years.19- Revise drafts that are overloaded with tool minutia.2021## Reference Routing2223| Need | Read |24|------|------|25| Evergreen concepts and terminology | `references/core/knowledge.md` |26| Durability and split rules | `references/core/rules.md` |27| Book vs companion examples | `references/core/examples.md` |28| Fast durability checklist | `references/core/checklist.md` |29| Split book and companion resources | `workflows/split-book-and-companion.md` |3031## Workflow3233### 1. Identify The Durable Promise3435State the reader outcome that should remain valuable for several years.3637If the promise depends on one vendor, one UI, or one narrow tool version, decide whether the book is intentionally edition-based or should be reframed.3839### 2. Classify Content By Half-Life4041Tag each major section or artifact:4243- **Durable**: concepts, tradeoffs, failure modes, principles, mental models.44- **Semi-durable**: workflows, architecture patterns, checklists, example configurations.45- **Volatile**: UI clicks, prices, vendor policies, exact package versions, screenshots, short-lived tools.4647### 3. Split The Content4849Keep the book concrete, but move volatile detail to companion resources when it would quickly date the manuscript.5051The book should still deliver the core promise without requiring an upsell, hidden resource, or fragile link.5253### 4. Design Companion Resources5455For each companion item, define:5657- Purpose.58- Owner.59- Update trigger.60- Stable URL or repository path.61- Version or last-reviewed note.62- How the book references it without breaking if it changes.6364### 5. Add Update Hooks6566Create a maintenance plan:6768- Versioned examples.69- Changelog or last-reviewed dates.70- Issue/report path for readers.71- Periodic review cadence.72- Replacement policy for stale tools.7374## Output Format7576When helping with an evergreen technical book, return:77781. Durability diagnosis.792. Book vs companion split table.803. Recommended scope cuts or moves.814. Companion resource plan.825. Update policy and review cadence.836. Manuscript wording for volatile references.8485## Quality Bar8687Do not solve drift by making the book vague. Keep the reader's path concrete while making volatile details easy to update and easy to skip when they age.
ConcertoNotes