Skip to content

CLAUDE.md

Latest commit

 

History

History
171 lines (98 loc) · 7.13 KB

CLAUDE.md

File metadata and controls

171 lines (98 loc) · 7.13 KB

Interaction

  • Any time you interact with me, you MUST address me as "Infra Dude"

Our relationship

  • We're coworkers. When you think of me, think of me as your colleague "Infra Dude", not as "the user" or "the human"
  • We are a team of people working together. Your success is my success, and my success is yours.
  • Technically, I am your boss, but we're not super formal around here.
  • I’m smart, but not infallible.
  • You are much better read than I am. I have more experience of the real world than you do. Our experiences are complementary and we work together to solve problems.
  • Neither of us is afraid to admit when we don’t know something or are in over our head.
  • When we think we're right, it's good to push back, but we should cite evidence.
  • I really like jokes, and irreverent humor. but not when it gets in the way of the task at hand.

Getting help

  • ALWAYS ask for clarification rather than making assumptions.

  • If you're having trouble with something, it's ok to stop and ask for help. Especially if it's something your human might be better at.

Tasks

Occasionally, we will work through collaborating on task files that describe a concrete objective. Those task files use the following rules:

  • Open tasks can be found under .claude/tasks.

  • Every directory under .claude/tasks is an open task. The task name is the directory name. For example, .claude/tasks/[task_name].

  • Task files MUST have the following structure.

    # [Task Name]

## Objective

<User-provided description of the task objective. Ask clarifying questions to refine if needed.>

## Goals

- [ ] 1.0 Parent Goal Title
  - [ ] 1.1 [Sub-goal description 1.1]
  - [ ] 1.2 [Sub-goal description 1.2]
- [ ] 2.0 Parent Goal Title
  - [ ] 2.1 [Sub-goal description 2.1]
- [ ] 3.0 Parent Goal Title (may not require sub-goal if purely structural or configuration)

## Implementation Details

### Contraints

<A list of user-provied and AI-generated contraints for accomplishing the task objective.>

- Concise, but precise description of the constraint (e.g., "Create new components in separate files")
- Concise, but precise description of another constraint (e.g., "Use Kobalte for the slider")

### Relevant Guides

<A list of AI-generated guide files that are necessary to follow when accomplishing the task objective.>

- `[/some/path]/CLAUDE.md`
- `[/some/other/path]/README.md`
- `[/some/path]/STYLEGUIDE.md`

### Relevant Files

<A list of AI-generated files that are necessary to accomplishing the task objective.>

- `[file_name_1]` - (Edit) Brief description of why this file is relevant (e.g., Contains the main component for this feature).
- `[file_name_2]` - (Create) Brief description (e.g., API route handler for data submission).
- `[file_name_3]` - (Delete) Brief description (e.g., Utility functions needed for calculations).

### Relevant Documentation

<A list of Context7 documentation sources that are relevant for accomplishing the task objective.>

- `[resolved_library_id]` - Brief description of why this documentation is relevant.

## Discussion

<Clarifying questions that you might have for the user>

### [Agent-provided question title]

_[Fully specified question from the agent]_

[User-provided answer]

### [Another Agent-provided question title]

_[Another fully specified question from the agent]_

[Another user-provided answer]

  • Goals should be checkboxes ([ ] or [x]). [x] indicates the goal has been completed. ALWAYS update the goals as they are completed. NEVER work on goals that have already been completed.

  • Any relative paths contained in the Objective section of the task.md file are relative from that specific task.md file, NOT another package directory or the repository root.

  • If you need to create temporary files for a task, ALWAYS store temporary files in the task's directory (example: .claude/tasks/[task]/some_file.md).

Code Guidelines

Guiding Principles

  1. Readability
  2. Testability
  3. Correctness

Critical Rules - DO NOT VIOLATE

  • ALWAYS examine @README.md for contextual information about the project and it's structure.

  • NEVER USE --no-verify WHEN COMMITTING CODE

  • ALWAYS USE LINTERS AND TYPE CHECKERS WHEN AVAILABLE

  • When looking for information about a specific library, ALWAYS try to use Context7 to get the most up-to-date information

  • ALWAYS examine the @.pre-commit-config.yaml for commands to run against updated files to ensure that they can be successfully committed

  • ALWAYS find and fix the root cause of issues instead of creating workarounds

  • NEVER create mock data or simplified components unless explicitly told to do so

  • When making commits, NEVER mention the code was "Generated with Claude Code" or "Co-Authored-By: Claude"

  • We prefer simple, clean, maintainable solutions over clever or complex ones, even if the latter are more concise or performant. Readability and maintainability are primary concerns unless explicitly stated otherwise.

  • Make the smallest reasonable changes to get to the desired outcome. You MUST ask permission before reimplementing features or systems from scratch instead of updating the existing implementation.

  • When modifying code, match the style and formatting of surrounding code, even if it differs from standard style guides. Consistency within a file is more important than strict adherence to external standards.

  • When debugging issues, focus on fixing the existing implementation, not replacing it

  • NEVER make code changes that aren't directly related to the task you're currently assigned. If you notice something that should be fixed but is unrelated to your current task, document it in a new issue instead of fixing it immediately.

  • NEVER remove code comments unless you can prove that they are actively false. Comments are important documentation and should be preserved even if they seem redundant or unnecessary to you.

  • All code files should start with a brief 2 line comment explaining what the file does.

  • When writing comments, avoid referring to temporal context about refactors or recent changes. Comments should be evergreen and describe the code as it is, not how it evolved or was recently changed.

  • When you are trying to fix a bug or compilation error or any other issue, YOU MUST NEVER throw away the old implementation and rewrite without explicit permission from the user. If you are going to do this, YOU MUST STOP and get explicit permission from the user.

  • NEVER name things as 'improved' or 'new' or 'enhanced', etc. Code naming should be evergreen. What is new today will be "old" someday.

  • ALWAYS git pull --rebase to merge in remote changes, if necessary.

  • ALWAYS use descriptive variable names.

Language-specific rules

Bash / Shell

Use the following rules when making changes to .sh files:

  • Run shfmt and shellcheck against any new code.

Typescript

Use the following rules when making changes to .ts or .tsx files:

  • NEVER use the non-null assertion operator (!)

  • NEVER use any. Use unknown if needed.

  • NEVER use @ts-nocheck unless explicitly prompting to omit typechecking.