evergreen-writing

Writes and reviews Markdown documentation and code comments against evergreen, why-first, and SSOT checklists.

1|Updated Jan 31, 2026
One-click install
npx skills add https://github.com/tktcorporation/cli-sim-game-escape --skill evergreen-writing-tktcorporation
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: evergreen-writing
Source: https://github.com/tktcorporation/cli-sim-game-escape/tree/main/.claude/skills/evergreen-writing
Command: npx skills add https://github.com/tktcorporation/cli-sim-game-escape --skill evergreen-writing-tktcorporation

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Documentation and code comments often become stale, duplicate existing content, or confuse new readers with time-dependent phrasing and unexplained jargon. This Skill provides a structured checklist workflow that keeps Markdown docs and code comments accurate and readable for readers months later. ## Core Features & Use Cases - Four-phase writing workflow: Identify the reader and purpose before writing, apply Evergreen/Why-First/SSOT/Reader-Friendly principles while writing, then run three self-check rounds after writing. - Time-dependent expression detection: Uses grep patterns to find phrases like "currently", "previously", PR numbers, commit SHAs, and author names, with a rewrite table for replacing them. - SSOT enforcement: Checks for duplicated information across files with grep and converts duplicates into references. - Use Case: When asked to update a README, add a design doc to docs/, or write JSDoc for an exported function, the Skill walks through pre-writing planning, principle-aware drafting, and post-writing lint verification. ## Quick Start Use the evergreen-writing skill to review and rewrite this README so it contains no time-dependent expressions and follows the why-first principle.

Frequently Asked Questions about evergreen-writing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write documentation that stays accurate over time?

Avoid time-dependent words like "currently", "previously", and "planned", and never reference PR numbers, commit SHAs, or author names. State facts as present declarations and explain the reasoning behind decisions instead of describing what the code does.

How to check Markdown files for stale or time-dependent phrases?

Run grep with patterns matching words like "previously", "currently", "future", and "planned", plus patterns for PR references and commit hashes. The Skill provides ready-made grep commands and a rewrite table for replacing each flagged expression.

What is the SSOT principle in documentation?

SSOT (Single Source of Truth) means each piece of information lives in exactly one place. Before writing, grep the repository for existing coverage of the topic; update the existing file or add a reference link instead of duplicating content.

When should I not write a code comment?

Skip comments on self-evident getters and functions whose purpose is obvious from their types. Comments are required only for public exported functions (JSDoc/docstring) and non-trivial logic where the reasoning is not visible in the code.

Does this checklist apply to changelogs and plans?

No. CHANGELOG files, .changeset entries, and docs/plans/ are explicitly out of scope because they legitimately contain history and dates. The checklist targets evergreen documents like READMEs, design docs, and rules files.