Project: doctolib-tmp · Branch: master · Mode:  · Model: claude-sonnet-4-6

Stats: 1 user messages, 0 tool calls, tools used: none.

Conversation

Turn 1 — User

Please review the following prompt for quality, clarity, and prompt engineering best practices. The user wants to use this prompt to plan a React component implementation.

---

Plan the React implementation of a component, as described in the figma project: https://www.figma.com/design/D5jfoP7Ed1teAOvL0yH2gV/%F0%9F%87%AB%F0%9F%87%B7--MOOSE--DMP-Segur-V2-2026?node-id=3187-100822&p=f&t=a49cAvm38JZ45YND-0, on page 3.1+1a - Workflows and API Calls. It describes a component that after clicking in the floder icon in the entry point, a full page modal is shown to list of documents
  - according with https://doctolib.atlassian.net/wiki/spaces/PTA/pages/3709042879/NHR+-+Architecture+Proposal, the list should display documents from the type defined at @/Users/USER/workspace/doctolib/treatment-plan/packages/tpf-national-health-records/src/business/types/document.ts
  - the "#{name of the patient} - #{DMP title}" should be displayed. For the figma design, the DMP title is "Mon Espace Sante"
  - a list of filters for the documents. For the first vesion, must be Document category, Precedure date, share date, status and visibility. The component should be generic/customizable enough to inject custom filters
  - columns can also be configured and must be configurable in the component.
  - clicking in the "eye" icon, should fetch the document and show it in another component
  - the rows should be able to be selectable to show multiple documents in another component
  - the columns can be sortable, acoording with configuration.
  - filters like share date, status and visibility needs a re-fetch of documents to show in the table.
  - it must be able to handle pagination with filters
  - the entrypoint of this component (the folder icon) must be under a account cohort feature switch
  - Think about how data can be cached and how the cache can be invalidated to give a better user experience.
  - Elaborate a test strategy.
  - Write the detailed plan at @tmp folder, in markdown format
  - Unde the hood, @/Users/USER/workspace/doctolib/treatment-plan/packages/ will be layer over the operations done described on @tmp/Documentation_eSanteConnect-JSON-2.1.0_EN.txt: it will perform hl_findDocuments and then hl_getDocumentsContent to show the document. This project will only iteract with the package @@/Users/USER/workspace/doctolib/treatment-plan/packages/tpf-national-health-records

---

Please provide:
1. An overall assessment of the prompt quality
2. Specific issues found (clarity, structure, completeness, ambiguities)
3. Actionable suggestions for improvement
4. A revised version of the prompt that addresses the issues found

Turn 1 — Assistant

PROMPT SCORE: 2/5 ✅

QUICK ASSESSMENT:
- Context & Role: ❌ - No role defined for the AI; no expertise level or behavioral guidelines specified
- Structure: ⚠️ - Requirements exist but are scattered bullet points with no logical grouping, priority order, or clear separation between concerns
- Examples: ❌ - No examples of expected output, component API shape, or plan format provided
- Reasoning: ❌ - No request for step-by-step thinking, trade-off analysis, or architectural reasoning before conclusions
- Control: ⚠️ - Output destination specified (tmp folder, markdown) but no template, section headings, or depth expectations defined

---

TOP 3 IMPROVEMENTS:

1. Define a role and output contract upfront. Without a role, the AI has no persona to reason from. Without an output template, the plan structure will be arbitrary. Add: "You are a senior frontend engineer. Produce a technical implementation plan with these sections: [Architecture, Data Flow, Component API, State Management, Testing Strategy, Open Questions]."

2. Group requirements into logical categories before listing them. The current prompt mixes UI behavior, data fetching, caching, feature flags, and testing in a single flat list. This makes it hard to reason about dependencies and priorities. Organize into: UI/UX Requirements, Data Layer, Configuration/Extensibility, Infrastructure, and Testing.

3. Resolve or flag the ambiguities explicitly. The prompt references a Figma URL (requires login), a Confluence page (requires login), a local file path for documentation, and two different package path formats (@/Users/... vs @@/Users/...). The AI cannot access any of these. The prompt should inline the essential constraints or explicitly ask the AI to flag assumptions where external context is inaccessible.

---

IMPROVED VERSION:

The original scores 2/5 (two ❌ and two ⚠️), so a rewrite is warranted.

You are a senior frontend engineer specializing in React, TypeScript, and complex data table UIs.

Plan the implementation of a full-page modal document list component for the National Health Records (NHR/DMP) feature.
Write the detailed plan to the tmp/ folder as tmp/dmp-document-list-plan.md.

Context

This component is part of the DMP (Dossier Medical Partagé) integration. It is triggered by clicking a folder icon
entry point in the UI. The entry point must be gated behind an account cohort feature switch.

The component fetches documents by calling two operations from the
tpf-national-health-records package (located at
/Users/USER/workspace/doctolib/treatment-plan/packages/tpf-national-health-records):
1. hl_findDocuments - retrieves the document list (supports filters and pagination)
2. hl_getDocumentsContent - retrieves document content for display

The document type contract is defined at:
/Users/USER/workspace/doctolib/treatment-plan/packages/tpf-national-health-records/src/business/types/document.ts

This project interacts ONLY with the tpf-national-health-records package. Do not plan integrations with other packages.

Read both files above before planning to ensure the plan is grounded in the actual type definitions and package API.

UI Requirements

- Display a header: {patientName} - {dmpTitle} (e.g., "Jean Dupont - Mon Espace Sante")
- Show a filterable, sortable, paginated table of documents
- Default filters (v1): Document Category, Procedure Date, Share Date, Status, Visibility
  - Share Date, Status, and Visibility filters trigger a re-fetch (server-side filtering)
  - Document Category and Procedure Date may be client-side if feasible
- Columns must be configurable via a prop (array of column definitions)
- Sorting must be configurable per column via the column definition
- Clicking the eye icon on a row fetches and displays the document in a separate viewer component
- Rows must be selectable (multi-select) to display multiple documents simultaneously in the viewer

Component API Requirements

Design the component to be generic and extensible:
- Accept a filters prop to inject custom filter components alongside the default ones
- Accept a columns prop to define which columns appear and their behavior (label, accessor, sortable, render)
- Accept a patientName prop and a dmpTitle prop for the header
- Define clear TypeScript interfaces for all props

Data & Caching Requirements

- Plan how document list results can be cached (consider React Query or equivalent)
- Explain cache key strategy (how filters and pagination params compose the cache key)
- Explain cache invalidation strategy (when should stale data be refetched vs served from cache)
- Handle loading, error, and empty states explicitly

Plan Structure

Produce the plan in tmp/dmp-document-list-plan.md with these exact sections:

1. Architecture Overview - component tree diagram (text-based), responsibilities of each component
2. Component API - TypeScript interface definitions for all props
3. Data Flow - sequence of API calls, how filters/pagination interact with hl_findDocuments
4. State Management - what lives in local state vs server state (React Query), cache key design
5. Feature Flag Integration - how the entry point is gated
6. Testing Strategy - unit, integration, and E2E test cases with specific scenarios listed
7. Open Questions - list any ambiguities that require product or design clarification before implementation

Constraints

- Use TypeScript. All props and data types must be explicitly typed.
- Use React Query v5 (v4 is deprecated in this codebase).
- Use functional components with hooks only.
- Do not add cross-engine dependencies outside of tpf-national-health-records.
- Before writing the plan, read the type definitions file and reason through the data model explicitly.

KEY CHANGES MADE:
- Added a role definition with domain expertise
- Grouped requirements into named sections (UI, Component API, Data, Constraints)
- Provided an explicit output template with required section headings
- Removed inaccessible external URLs (Figma, Confluence) and replaced with inline constraints
- Fixed the double-@@ typo in the package path
- Made the filter re-fetch behavior unambiguous (server-side vs client-side)
- Added explicit instruction to read the type file before planning, grounding the output in real code
- Specified React Query v5 explicitly, matching the codebase constraint in CLAUDE.md