Skip to content

CLAUDE.md

Latest commit

 

History

History
57 lines (48 loc) · 2.53 KB

CLAUDE.md

File metadata and controls

57 lines (48 loc) · 2.53 KB
Raw

PartSelect Chat Agent — Case Study

Project Overview

Chat agent for PartSelect.com covering Refrigerator and Dishwasher parts. Users can diagnose appliance issues, look up parts, check compatibility, and get installation guidance.

Stack

  • Frontend: React (Create React App, existing template)
  • Backend: FastAPI (Python), runs on port 8000
  • LLM: OpenRouter API (claude-3-5-sonnet), tool-calling enabled
  • Data: Scraped PartSelect parts stored in JSON + embedded in a local vector store (ChromaDB)

Project Structure

partselect-agent/ ├── frontend/ # React frontend │ ├── src/ │ ├── public/ │ └── package.json ├── backend/ │ ├── main.py # FastAPI app │ ├── agent.py # Orchestrator + tool definitions │ ├── tools/ │ │ ├── search_parts.py │ │ ├── get_part_details.py │ │ ├── check_compatibility.py │ │ ├── get_install_guide.py │ │ └── diagnose_symptom.py │ ├── data/ │ │ ├── parts.json # Scraped parts data │ │ └── scraper.py # PartSelect scraper │ └── vectorstore/ # ChromaDB local store ├── CLAUDE.md └── .env

Key Conventions

  • All backend endpoints prefixed /api/
  • Tool responses always return { success, data, error }
  • Part cards always include: part_number, name, price, image_url, compatibility, url
  • Session state (user's model number) passed in every /api/chat request
  • Scope guard: agent must refuse non-appliance topics gracefully
  • Streaming: /api/chat streams response via SSE

Environment Variables

OPENROUTER_API_KEY=

Workflow Rules

Git Commit Discipline

  • Commit regularly — at minimum once per completed task, more often if logical checkpoints arise
  • Keep each commit small and focused so it is easy for a human to review; avoid bundling unrelated changes
  • Always stage files explicitly: git add <specific-file> — never git add . or git add -A, since the user may have unrelated in-progress changes that should not be included

Task Documentation

  • After planning any non-trivial task, save the spec and implementation plan to docs/tasks/ using a zero-padded numbered filename (e.g. 01-setup-backend.md, 02-data-pipeline.md)
  • Once a task is fully complete, move its file into docs/tasks/done/
  • When picking up a task, read only that task's file plus relevant architecture docs in docs/ — do not read other task files, as they introduce noise and slow down context loading