writing-ftd-documents

Invoke the skill and answer its intake questions covering scope, functional needs, technical constraints, and five mandatory output questions (split, language, mode, AC format, filename). It then drafts a right-sized FTD with a mandatory core of scope, user stories, acceptance criteria, DoD, privacy, and security sections.

Feature covers one story and one component (≤150 lines, no sign-off gate). Project covers multiple stories and teams (≤400 lines, Scope Summary sign-off required). Enterprise covers org-wide or regulated work and ships as an indexed multi-file bundle with DPIA, threat model, and compliance evidence.

Bullets are the default for feature and most project scenarios. EARS (Easy Approach to Requirements Syntax) is recommended for enterprise, regulated, or safety-critical contexts where unambiguous 'shall' statements are required. The user always chooses in the intake, and one format is used consistently per document.

Yes, Phase R offers three modes: Audit produces a prioritized gap report without modifying the source, Restructure rewrites legacy documents into FTD format preserving revision history, and Feature-structuring converts loose tickets or notes into FTD-feature format.

Do not use it for business cases, project plans, RFP/tender responses, quick single-endpoint specs, pure architecture diagrams, or user documentation. The skill explicitly declines these and points to the appropriate artifact instead.

Yes, output language can be English or Dutch, including Dutch EARS phrasing with 'zal'. Output modes are Markdown, self-contained HTML with sticky TOC and light/dark toggle, or both, with Markdown always drafted first.