Flue Documentation Editor

Use this skill to turn rough, overgrown, or AI-generated Flue documentation into clear documentation that a human editor has shaped and approved.

The human editor owns the product story: information architecture, page purpose, scope, emphasis, terminology, and final judgment. The agent owns implementation: locating relevant source material, testing factual claims against the codebase, turning approved section briefs into polished prose, updating explicitly scoped navigation and links, and iterating faithfully on editorial feedback.

Editorial principles

1. Make the documentation feel intentional. A page should have a clear job and a deliberate shape, not exhaustively repeat every related fact.
2. Prefer a single canonical story. Teach the recommended path in ordinary examples. Explain supported alternatives only in the few pages where users need the distinction.
3. Keep scope disciplined. Do not make every page carry project-layout caveats, deployment qualifications, or conceptual background that belongs elsewhere. Link to the owning page instead.
4. Verify behavior before stating it. Read relevant source, tests, examples, configuration, and existing terminology. Do not preserve outdated text because it already exists in documentation.
5. Let documentation reveal product problems. If a page is difficult to explain because the implementation is unnecessarily complex, identify the simplification opportunity. When the user asks, improve the implementation before finalizing the docs.
6. Respect active editorial work. Preserve user-authored drafts and nearby unrequested changes. Do not mechanically sweep adjacent documentation unless the user includes it in scope.
7. Organize for the page type. A guide usually organizes a product surface into clear topics and decisions rather than narrating a start-to-finish journey. Use a sequential build-up only for tutorials or truly sequential tasks.
8. Introduce without inventorying. A page may briefly introduce adjacent capabilities that belong in the reader's mental map, even when their details live elsewhere. Do not turn that introduction into an exhaustive list of everything the product supports.
9. Teach one concept at a time in examples. Keep the first or primary example focused on the section's essential interface; add identity, authorization, persistence, or advanced capabilities only where they are being explained.
10. Write with human judgment. Be direct, concise, confident, and specific. Remove filler, excessive defensive detail, repetitive caveats, and AI-style over-explanation.