Project: workspace-doctolib · Branch: HEAD · 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 effectiveness. 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 evaluate this prompt against prompt engineering best practices and provide actionable feedback covering: 1. Clarity and specificity 2. Structure and organization 3. Context provided vs missing context 4. Ambiguities that could lead to incorrect output 5. Typos and formatting issues 6. Suggestions for improvement with concrete rewrites where helpful
Turn 1 — Assistant
PROMPT SCORE: 2/5
QUICK ASSESSMENT: - Context & Role: - No role defined for the AI; no expertise level specified (e.g., "You are a senior React architect") - Structure: - Requirements are a flat bullet list with no logical grouping; tasks (plan, document, test) are mixed with constraints - Examples: - No examples of expected output format, component API shape, or what the markdown plan should contain - Reasoning: - No request to think through trade-offs, justify architectural decisions, or reason step-by-step before writing the plan - Control: - Output destination is specified (@tmp folder) but format/sections of the markdown plan are not defined; no length or depth guidance
TOP 3 IMPROVEMENTS:
-
Define a role and frame the task explicitly at the top, e.g.: "You are a senior React architect. Your task is to produce a detailed implementation plan in markdown at /tmp/dmp-document-list-plan.md. Do not write any code yet."
-
Group requirements into labeled sections before listing them, so the model can map them to plan sections. Current flat list mixes UI behavior, API integration, filtering, caching, testing, and infra concerns with no separation. Suggested sections: Component API & Props, Data Fetching & Caching, Filtering & Pagination, Sorting & Selection, Access Control, Test Strategy.
-
Specify the exact structure of the expected markdown output, otherwise the model will invent a structure. Example: "The plan must include these sections in order: 1. Component Overview, 2. Props API (with TypeScript interface), 3. Data layer & caching strategy, 4. Filter/sort/pagination design, 5. Feature switch integration, 6. Test strategy (unit, integration, e2e)."
ADDITIONAL ISSUES:
Typos and broken references to fix before use:
- "floder" should be "folder"
- "acoording" should be "according"
- "@@/Users/..." has a double @ on the last package reference
- "Unde the hood" should be "Under the hood"
- The Figma URL and Confluence URL are not accessible to the model at inference time; their content must be summarized inline or the relevant details extracted and pasted directly into the prompt
Missing context that will cause vague output:
- The prompt references /Users/USER/workspace/doctolib/treatment-plan/packages/tpf-national-health-records/src/business/types/document.ts but does not paste its contents; the model cannot read local files unless a tool is invoked
- The eSante Connect text file at @tmp/Documentation_eSanteConnect-JSON-2.1.0_EN.txt is referenced but not included; the model needs the relevant hl_findDocuments and hl_getDocumentsContent API signatures to plan the data layer correctly
- "another component" is mentioned twice (eye icon, multi-select) with no name or description; this ambiguity will produce a generic plan
IMPROVED VERSION:
You are a senior React architect working in a TypeScript monorepo. Your task is to write a detailed implementation plan — no code yet — and save it as a markdown file at /tmp/dmp-document-list-plan.md.
## Feature Summary
A full-page modal is triggered by clicking a folder icon (entry point). It displays a filterable, sortable, paginated list of patient documents fetched from the NHR (National Health Records) package. The modal header shows "#{patient name} - Mon Espace Sante".
## Constraints
- The entry point (folder icon) is gated behind an account cohort feature switch.
- All data operations go through the package at:
/Users/USER/workspace/doctolib/treatment-plan/packages/tpf-national-health-records
- The package internally calls hl_findDocuments (list) and hl_getDocumentsContent (single document fetch) from the eSante Connect API.
- Document type definitions are in:
/Users/USER/workspace/doctolib/treatment-plan/packages/tpf-national-health-records/src/business/types/document.ts
[PASTE FILE CONTENTS HERE]
## Relevant API Signatures (from eSante Connect)
[PASTE the hl_findDocuments and hl_getDocumentsContent request/response shapes from Documentation_eSanteConnect-JSON-2.1.0_EN.txt here]
## Component Requirements
**Filtering (v1 — triggers re-fetch):**
- Document category (local filter, no re-fetch)
- Procedure date (local filter)
- Share date (re-fetch required)
- Status (re-fetch required)
- Visibility (re-fetch required)
- The filter system must be injectable: the component accepts a `filters` prop so custom filters can be added without modifying the component.
**Columns:**
- Configurable via a `columns` prop (column definition array).
- Columns can individually declare `sortable: true`; sorting triggers re-fetch.
**Row behavior:**
- Clicking the eye icon fetches the document content and opens it in a DocumentViewer component (describe its props interface in the plan).
- Rows are multi-selectable; selected rows open multiple documents in DocumentViewer.
**Pagination:**
- Must compose correctly with active filters and sort state.
**Caching:**
- Plan a caching strategy: what is cached, cache keys, invalidation triggers.
## Required Plan Sections (in this order)
1. Component Overview — purpose, placement in the component tree, entry point integration
2. Props API — TypeScript interface for the main component, filter injection pattern, column config shape
3. Data Layer — how hl_findDocuments is called, parameters mapped from filter/sort/pagination state
4. Caching Strategy — cache keys, invalidation rules, optimistic vs stale-while-revalidate trade-offs
5. Filter & Pagination Design — which filters are local vs remote, state management approach
6. Document Viewing — DocumentViewer component interface, single vs multi-document flow
7. Feature Switch Integration — how the folder icon entry point is conditionally rendered
8. Test Strategy — unit tests (filter logic, column config), integration tests (fetch + render), e2e tests (modal open, filter, view document)
Think through each section step by step before writing it. For any architectural decision with multiple valid approaches, briefly state the trade-off and your recommendation.
Key changes made: role defined, output file path made explicit, Figma/Confluence URLs replaced with inline descriptions (since the model cannot fetch URLs), local file references flagged for the user to paste inline, flat bullet list replaced with labeled sections, output structure prescribed, and chain-of-thought requested for architectural decisions.