feature-doc-splitter-cn

Functional Document Splitter

Overview

Use this skill to organize an early draft of functional requirements into a set of three actionable documents: an overview document, a frontend implementation document, and a backend implementation document.

The output must be grounded in the real code structure, clearly separate frontend and backend responsibilities, define shared contracts, add the necessary Mermaid diagrams, and explicitly write uncertainties into assumptions or items to be confirmed. When new UI surfaces are involved, also determine whether to reserve optional placeholders for Pencil design mockups.

When to Use

Use this skill when the user requests the following:

• Split an initial functional requirements document into overview, frontend, and backend implementation documents.
• Organize a rough product description into technical documents that can be developed directly.
• Before writing a feature implementation document, review the existing code to map out modules and conventions.
• Need to add Mermaid business flow diagrams, interaction flow diagrams, sequence diagrams, or an interface contract index.
• Need to first ask the user whether to reserve optional Pencil design mockup placeholders for new frontend UI surfaces.

Do Not Use

Do not use this skill in the following scenarios:

• Implementing feature code directly.
• Writing only a single, non-split PRD or promotional description.
• Drawing specific UI visual mockups in Pencil.
• Designing only a backend API and not needing to split into three feature documents.
• Doing only frontend component development and not needing an overview and backend implementation document.

Usage Instructions

Execute according to the following process, and always split the three output documents by responsibility.

Required Outputs

Create or update three documents:

• Overview document: goals, background, scope, non-goals, business objects, end-to-end flows, cross-platform contracts, required Mermaid diagrams, launch planning, risks, and acceptance criteria.
• Frontend implementation document: only describe frontend routing, pages, sections, components, state, Hooks, API integration points, interaction states, Mermaid flow diagrams, tests, and optional Pencil design mockup placeholders for new UI.
• Backend implementation document: only describe backend data models, migrations, API routes, Schemas, services, validation rules, statistical formulas, tasks, notification or event creation, Mermaid flow diagrams, tests, and acceptance criteria.

The overview document must reference the frontend and backend implementation documents using project-relative paths, and must include Mermaid code blocks.

Workflow

1. First read the repository rules.

   • Before editing, read the relevant AGENTS.md。
   • Follow local documentation style, placement directories, naming, and package management conventions.
   • Preserve user changes unrelated to the task.

2. Read the initial requirements document in full.

   • Identify user goals, participating roles, business terms, leaderboard or statistical rules, visible UI, backend data requirements, notification requirements, and implicit permissions.
   • Write unclear content into "Assumptions" or "Items to Be Confirmed"; do not silently invent things in the document.

3. Review the code before writing the document.

   • Use rg and targeted file reading to find existing pages, routes, components, Hooks, generated API clients, models, Schemas, services, tests, notification code, and statistics or ranking logic.
   • Prioritize reusing existing modules and project conventions; do not create unnecessary abstractions for a one-off requirement.
   • If an existing component or module can be reused, clearly document the reuse path in the documentation; do not create design draft placeholders.

4. Define the document set.

   • The three documents use consistent naming.
   • Links uniformly use project-relative paths.
   • Both the frontend and backend documents must be able to independently guide the corresponding role's implementation, and must not depend on reading the other side's internal details.
   • Shared contracts go in the overview document; each implementation document only repeats the portion that its own side needs to consume.

5. Write the overview document.

   • Include the overall goal, business background, scope, non-goals, terminology, roles, data ownership, interface contract index, phased plan, acceptance criteria, risks, and dependencies.
   • The overview document always includes at least one Mermaid end-to-end business flow diagram.
   • When multi-role or multi-system collaboration is involved, add a Mermaid sequence diagram or interaction flow diagram.

6. Write the frontend implementation document.

   • Include routes or entry points, page or panel changes, component list, state model, data loading, API client usage, empty/loading/error states, permissions, copy or internationalization, necessary tracking, and tests.
   • Include one Mermaid frontend business logic flow diagram and one Mermaid user interaction flow diagram.
   • Before defining or creating any Pencil placeholder, first ask the user whether one is needed; if the user has already clearly stated that they need or do not need one, follow what the user expressed.
   • If the user does not need a Pencil placeholder, do not create .pen files, and briefly record this decision in the documentation.
   • If the user needs a Pencil placeholder, define it only for genuinely new pages, views, sections, panels, blocks, or components.
   • For parts that reuse existing UI, clearly mark "reuse existing components, no design draft placeholder needed".

7. Write the backend implementation document.

   • Include models, migrations, API endpoints, request and response schemas, operationId, service classes, validation, deduplication or idempotency, permission checks, statistics formulas, events, tasks, and tests.
   • Include one Mermaid backend business or statistics flow diagram.
   • When there is collaboration among APIs, services, databases, events, or notification systems, add a Mermaid sequence diagram.
   • If the project uses a generated client, state the OpenAPI generation impact.

8. Create design draft placeholders only after the user confirms they are needed.

   • If the user has not stated a preference in advance, ask a concise yes/no question before creating placeholder files.
   • If the user declines or indicates that placeholders are not needed, do not create .pen files.
   • Create .pen files only when a newly added frontend UI surface needs subsequent manual design and the user wants to reserve placeholders.
   • Do not create .pen files for reusing existing components, simple copy changes, existing list rows, existing tabs, or existing entry buttons.
   • Place placeholder files near the feature documentation, for example docs/features/<feature>/pencil/<surface>.pen。
   • If the project uses Pencil .pen JSON files, an empty placeholder may contain only:

{"version":"2.13","children":[]}

1. Verification results.
   • Check link and title consistency, Mermaid syntax, document responsibility boundaries, and whether the overview document contains Mermaid code blocks.
   • Confirm that no machine-related absolute paths have been written, unless the user explicitly requests it.
   • If a .pen placeholder was created, validate the JSON format.
   • Run repository documentation or skill validation commands when available; otherwise at least run git diff --check。
   • Finally, explain the checks that have been run.

Responsibility separation rules

• Frontend documentation should not describe backend internal implementation details.
• Backend documentation should not describe frontend components and layout decisions.
• When existing interface contracts are sufficient, do not force the design of new backend APIs.
• When a new interface is truly needed, clearly specify the method, path, operationId, authentication, request Schema, response Schema, error codes, pagination, sorting, and frontend consumption expectations.
• If the frontend uses generated API code, require the generated client path and regeneration command to be specified, to avoid scattered handwritten API call layers.
• Paths in the documentation should uniformly use project-relative paths.

Mermaid requirements

When Mermaid node text contains punctuation, wrap the node label in quotes.

Minimum diagrams:

• Overview: a required end-to-end business process diagram.
• Overview: when multiple systems or multiple roles are involved, add a sequence diagram or interaction flow diagram.
• Frontend: user interaction flow diagram.
• Frontend: frontend business logic or state transition diagram.
• Backend: backend interface/service/data flow diagram.
• Backend: when persistence, tasks, or events are involved, add a sequence diagram or statistics flow diagram.

Final reply

Briefly explain the documents created or updated, list the Pencil placeholders created or explicitly deleted, and report the validation results.