Properties4
5The Lithos Feature Skill (lithos-feature) defines how to write feature documentation pages in vault/2.features/. These pages describe individual Lithos capabilities in depth, combining conceptual explanations with practical usage examples.
Purpose
Feature pages are the backbone of the Lithos documentation. Each page covers a single capability — such as the Interactive Graph, Structured Data, or MCP Server — and explains both the "why" and the "how." The skill ensures these pages follow a consistent structure, meet volumetry requirements, and use Obsidian features like callouts and wikilinks effectively.
The key distinction from general documentation (covered by the Lithos Documentation Skill) is the emphasis on demonstration. Feature pages use ::tabs components to show both the rendered output and the source code side by side. This "Preview/Code" pattern helps readers understand exactly what syntax produces what result, reducing the gap between documentation and practice.
Content Requirements
Volumetry Standards
Feature pages have higher content expectations than guide or API reference pages. Each page targets 1000-2000 words, structured as 2-3 major sections (H2) with 2-3 subsections (H3) each. Every subsection contains at least 3 substantive paragraphs of 3-5 sentences. This depth is necessary because feature pages serve as the primary reference for each capability.
Cross-linking is essential. Each feature page should reference at least 3 other pages in the vault — related features, relevant guide pages, or API references. These links create the web of connections that powers the Interactive Graph and helps readers navigate between related concepts.
2.features/ directory must always contain at least 2 files. When reorganizing or deleting features, verify the folder maintains its minimum population.Writing Style
Feature documentation should balance accessibility with technical depth. Open with a clear statement of what the feature does and why it matters. Progress from high-level concepts to specific configuration details. End with integration notes showing how the feature connects with the broader Lithos ecosystem.
Avoid generic claims ("This is powerful") in favor of specific demonstrations. If a feature enables something, show it. If it solves a problem, explain the problem first. The goal is for readers to understand not just how to use a feature, but when and why they would choose to use it.