|
Full output below. There's other stuff in there, the "working with unfamiliar data or systems" is maybe slightly risky but (seemingly, after a week or two) much more token efficient and effective. I also added the plugins directly to Claude Code:
ty Plugin · claude-code-lsps · enabled
vscode-langservers Plugin · claude-code-lsps · enabled
vtsls Plugin · claude-code-lsps · enabled ~ cat ~/.claude/CLAUDE.md
# Python Environment
- ALWAYS use uv — never use pip, pip install, python, or python3 directly
- Activate venv: `source .venv/bin/activate`
- Install deps: `uv sync`
- Add a dep: `uv add <package>`
- Run scripts: `uv run <script.py>`
- Run tools: `uvx <tool>`# Long-running scripts
- Any script, command, migration, data job, or test run that may take more than 2-3 seconds should emit regular status updates while it runs.
- Prefer progress that is useful for diagnosing where time is going: current phase, item counts, batch numbers, elapsed time, retry/backoff state, or the external service being waited on.
- For loops or batch jobs, log progress periodically rather than only at start/end; keep the cadence readable and avoid flooding output. # Code Intelligence
- LSP servers available: ty (Python), vtsls (JS/TS), vscode-langservers (HTML/CSS/JSON)
- Use LSP for:
- findReferences before any refactor
- goToDefinition when navigating unfamiliar code
- diagnostics after edits to catch type errors
- grep/search is fine for simple lookups in small files
- NEVER refactor without findReferences impact analysis first
- After every edit, check LSP diagnostics before moving on # Documentation
- Context7 is available for up-to-date library docs
- Use `ctx7 docs <libraryId> <query>` to fetch current documentation
- Use `ctx7 library <name> <query>` to find a library ID first # Working with unfamiliar data or systems
- Prefer experimenting on real data over reasoning about it in the abstract. Your outputs are noticeably better when grounded in a concrete sample than when derived from minutes of speculation.
- When a task involves parsing/processing/integrating with some external artifact (a report, an API response, a file format, a third-party tool's output), the FIRST step is to fetch or generate a real example and inspect it. Do not write code against an imagined shape.
- Experiments must be non-destructive: read-only fetches, copies into a scratch dir, dry-run flags. Never mutate the user's real data to learn about it.
- Before assuming you lack credentials, check the current working directory's `.env` file (and `.env.example` for hints about which keys exist) — API keys, tokens, and connection strings for the relevant service are very often already there.
- If you cannot obtain real data on your own (auth genuinely missing, lives on another machine, behind a paywall, etc.), STOP and ask the user to provide a sample rather than guessing.
- Example: asked to process an Amazon sales report, the first action is to fetch (or have the user paste) one actual report and look at its columns — not to draft a parser based on what such a report "probably" contains. |