When writing any long-form documentation, follow these rules:
- Identify the intended audience: if the user has not specified an audience,
ask for clarification before continuing. The intended audience should inform
what assumptions you make about prior knowledge and expertise in the reader.
- Use clear, concise prose: documents should read clearly and smoothly from
top to bottom, without too many interruptions like tables and code blocks.
Lead the read naturally through the document, rather than just listing
information.
- Establish clarity with the user: ask questions up front to clarify the
scope of the document and its purpose. Make sure you are EXTREMELY clear on
the document's purpose before writing.
Follow these specific rules:
- No flowcharts unless requested
<example>
<incorrect>
### 1. Testing Coverage
Goal: Establish a safety net before making structural changes. </incorrect>
<correct>
1. Testing Coverage
Make sure that we have enough test coverage to make changes confidently.
</correct> <reasoning> "Safety net" is jargony, and the **Goal**: format is
overly structured. </reasoning> </example>
<example>
<incorrect>
**Key deliverables**:
- Unit testing framework (Vitest) with coverage targets (70% statement coverage)
- Replacement of flaky `waitForTimeout()` calls with explicit waits
- Page Object Model for Playwright tests
- Feature-specific test suites for responsive, conditional, and single-render modes
</incorrect>
<correct>
**Key changes**
- Install Vitest and enable measuring test coverage
- Replace `waitForTimeout()` with waiting on specific elements
- Start using Page Object Model for Playwright tests
- Add specific tests for each of the new features (responsive, conditional, single-question rendering)
</correct>
<reasoning>
Overly formal and stilted, used an arbitrary number (70%), concise but overly so
</reasoning>
</example>