admin/portfolio
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
556940c3c813c6c2f57542325d971c611869eff2
portfolio/Ralph/RALPH_PROMPT.md
T

11 KiB
Raw Blame History

Ralph Wiggum Loop - Iteration Prompt

You are operating inside an automated loop. Each iteration you receive fresh context - you have NO memory of previous iterations. Your only persistence is the filesystem.

You are implementing Design 7: The Clinical Record — a Patient Medical Record (PMR) system that presents Andy's CV as a clinician would view a patient record. This is a visual redesign rebuilding existing components to achieve absolute thematic fidelity to real NHS clinical software.

The Concept: The "patient" is Andy's career. Users navigate a genuine NHS clinical software interface (similar to EMIS Web, SystmOne, Vision) with a patient banner, sidebar navigation, consultation journal, medications table, clinical alerts, and a login sequence. The clinical metaphor lives in the LAYOUT and VISUAL PRESENTATION — the sidebar labels use CV-friendly terms (Experience, Skills, Achievements, Projects, Education, Contact) while each view is laid out like its clinical equivalent (consultation journal, medications table, problems list, etc.).

IMPORTANT — Sidebar Label Convention: The sidebar uses CV-intuitive labels, NOT clinical jargon. But each view's content is presented in the clinical format:

  • Summary → Patient summary layout
  • Experience (not "Consultations") → Consultation journal layout with History/Examination/Plan
  • Skills (not "Medications") → Medications table layout with dosages/frequency
  • Achievements (not "Problems") → Problems list layout with traffic lights
  • Projects (not "Investigations") → Investigation results layout
  • Education (not "Documents") → Attached documents layout
  • Contact (not "Referrals") → Referral form layout

Your Task This Iteration

  1. Read the Design Guidance in the reference file (REQUIRED for visual components): Each reference file in Ralph/refs/ contains a "Design Guidance (from /frontend-design)" section at the bottom with pre-generated design direction, code patterns, and implementation details. You MUST read this section before writing code — it provides the aesthetic direction and code examples for the component. Do NOT invoke the /frontend-design skill at runtime — the guidance is already embedded in the ref files.

  2. Read the plan: Open IMPLEMENTATION_PLAN.md and find the highest-priority unchecked item (- [ ]). Items are listed in priority order - pick the first unchecked one.

  3. Read accumulated learnings: Open progress.txt and read the "Codebase Patterns" section. This contains learnings from previous iterations about PMR design system, data architecture, animation approach, and clinical system authenticity.

  4. Read guardrails: Open guardrails.md and read ALL guardrails. These are hard rules you MUST follow. Key guardrails include:

    • Light-mode only (clinical systems don't have dark mode)
    • Instant view switching (no animations between views)
    • Proper semantic table markup for all data tables
    • Traffic lights must always have text labels
    • Exact NHS blue color (#005EB8)
    • ECG must end with flatline (not fade to white)
    • Login typing animation specifics
    • Consultation History/Examination/Plan format
    • Coded entries in [XXX000] format
    • Sidebar labels are CV-friendly (Experience, Skills, etc.), NOT clinical jargon

  5. Implement the item: Complete the single task you selected. Keep changes focused - one task per iteration. Write production-quality React/TypeScript code that faithfully reproduces a clinical information system. This is a design showcase requiring absolute thematic fidelity.

  6. Run quality checks: Execute the quality check commands listed in IMPLEMENTATION_PLAN.md under "Quality Checks". Fix any issues before proceeding.

  7. Visual Review (Tasks 1b-11 only — skip for non-visual tasks like Task 1, 12-15): After quality checks pass, verify your work visually in the browser using the Claude in Chrome browser tools: a. Call tabs_context_mcp to get available tabs (create if empty). b. Navigate to http://localhost:5173 (dev server runs throughout the loop). c. First load only: The app plays a boot→ECG→login→PMR sequence (~15s). Use computer with action: "wait", duration: 15 then take a screenshot. On subsequent navigations in the same tab, the app stays in PMR phase — no waiting needed. d. Navigate to the hash route for your task's view:

    • Task 1b (Boot/ECG): Refresh page, screenshot during boot sequence, then again during ECG animation
    • Task 2 (Login): Refresh page, wait ~8s (after boot+ECG), screenshot the login screen
    • Task 3 (Banner): Any PMR view — review the patient banner at top
    • Task 4 (Sidebar): Any PMR view — review left sidebar
    • Task 5 (Layout/Breadcrumb): Any PMR view — review overall composition
    • Task 6: #summary | Task 7: #experience | Task 8: #skills
    • Task 9: #achievements | Task 10: #projects then #education | Task 11: #contact e. Take a screenshot (computer with action: "screenshot") and compare against your reference file. f. Check specifically: colors match spec, correct font (Inter vs Geist Mono), proper spacing, 1px solid #E5E7EB borders, 4px border-radius, layout alignment, NHS blue #005EB8. g. If discrepancies are found: fix them, re-run quality checks, take another screenshot to confirm. h. Note the visual review outcome in your progress.txt entry (step 10).

  8. Commit your changes: Stage and commit all changes with a descriptive message referencing the task you completed.

  9. Mark the item complete: In IMPLEMENTATION_PLAN.md, change the item from - [ ] to - [x].

  10. Update progress.txt: Append to the "Iteration Log" section with:

  • Which task you completed
  • Any learnings or codebase patterns discovered (add to "Codebase Patterns" section)
  • Any issues encountered
  • Design decisions made (if visual component)
  • Visual review outcome (what was checked, any fixes made)

  1. Commit the progress update: Stage and commit the updated IMPLEMENTATION_PLAN.md and progress.txt.

  2. Recommend model for next iteration: Look at the NEXT unchecked task in IMPLEMENTATION_PLAN.md (the one after the task you just completed). Assess its complexity and output a model recommendation on its own line:

    <next-model>sonnet</next-model>

    or

    <next-model>opus</next-model>

    Use this decision framework:

    • Use sonnet for: configuration tasks, search/utility implementation, responsive fixes, accessibility audits, tasks with very prescriptive specs, tasks that are mostly wiring/plumbing
    • Use opus for: visual component rebuilds that invoke /frontend-design (design quality matters), complex animation work, tasks requiring strong aesthetic judgment, tasks where the previous iteration left issues that need creative problem-solving
    • Default to sonnet if unsure — it's cheaper and handles well-specified tasks fine
    • If there IS no next task (you just completed the last one), skip this step

  3. Determine if another iteration is needed: Review your work and the codebase. The project needs another iteration if ANY of these are true:

    • Any task in the checklist is unchecked (- [ ]) or blocked (- [B])
    • Quality checks would fail (run them to verify)
    • There are uncommitted changes
    • progress.txt has open questions or guidance for "next iteration"
    • The implementation doesn't fully satisfy the plan requirements
    • You have lingering doubts about correctness or completeness

  4. Send completion signal ONLY if truly complete: If and ONLY if the project definitely does NOT need another iteration — all tasks verified done, quality checks pass, no guidance for next iteration — output this exact signal on its own line:

    <promise>COMPLETE</promise>

    DO NOT output this string if there's any chance another iteration is needed. When in doubt, do NOT send the promise — leave it for the next iteration to determine.

Critical Rules

  • ALWAYS read the "Design Guidance" section in the ref file before writing visual component code — do NOT invoke /frontend-design at runtime (it's pre-baked into the ref files)
  • Do NOT invoke the /frontend-design skill — the design guidance is already embedded in each ref file. Invoking it at runtime will consume your context and stall the iteration.
  • ALWAYS visually review visual components (Tasks 1b-11) in the browser — use Claude in Chrome tools to screenshot and verify against the spec before committing
  • Only work on ONE task per iteration
  • Always read progress.txt AND guardrails.md before starting — previous iterations may have left important context
  • If a task is blocked or unclear, document why in progress.txt and move to the next unchecked item
  • Keep commits atomic and well-described
  • If quality checks fail, fix the issues before committing
  • The visual quality bar is HIGH — this must look like real clinical software
  • Preserve clinical system authenticity — instant navigation, proper tables, NHS blue, coded entries, traffic lights
  • Sidebar labels are CV-friendly — Experience (not Consultations), Skills (not Medications), etc.
  • Use TypeScript strictly — no any types, proper interfaces for all PMR data structures
  • Follow the established project structure — components in src/components/, data in src/data/, types in src/types/
  • Respect prefers-reduced-motion — animations must have instant fallbacks

Reference Files

Each task in the implementation plan references specific files in Ralph/refs/:

  • Ralph/refs/ref-boot-ecg.md — Boot sequence + ECG animation improvements
  • Ralph/refs/ref-design-system.md — Colors, typography, spacing, borders, motion
  • Ralph/refs/ref-transition-login.md — ECG flatline + login sequence
  • Ralph/refs/ref-banner-sidebar.md — Patient banner + sidebar + navigation
  • Ralph/refs/ref-summary-alert.md — Summary view + clinical alert
  • Ralph/refs/ref-consultations.md — Experience view (consultation journal layout)
  • Ralph/refs/ref-medications.md — Skills view (medications table layout)
  • Ralph/refs/ref-problems.md — Achievements view (problems list layout)
  • Ralph/refs/ref-investigations-documents.md — Projects + Education views
  • Ralph/refs/ref-referrals.md — Contact view (referral form layout)
  • Ralph/refs/ref-interactions.md — Interactions, responsive, accessibility
  • References/CV_v4.md — Source CV content (roles, achievements, numbers, dates)

Read ONLY the referenced file(s) for each task. Do NOT read goal.md directly.

Design Document Highlights

Color Palette (Light-mode only):

  • Main content: #F5F7FA
  • Cards: #FFFFFF
  • Sidebar: #1E293B
  • NHS blue: #005EB8
  • Green (active): #22C55E
  • Amber (alerts): #F59E0B

Typography:

  • Inter for general text
  • Geist Mono for coded entries and data values

Key Interactions:

  • Login sequence: typing username/password character-by-character
  • Clinical alert: slides down, acknowledges with checkmark → collapse
  • Consultation entries: expand/collapse with History/Examination/Plan
  • Medications table: sortable columns, expandable prescribing history
  • Sidebar: instant view switching, no animations

Responsive Strategy:

  • Desktop (>1024px): 220px sidebar with labels
  • Tablet (768-1024px): 56px icon-only sidebar
  • Mobile (<768px): Bottom navigation bar
Reference in New Issue View Git Blame Copy Permalink