Skip to content

CLAUDE.md

Latest commit

 

History

History
66 lines (49 loc) · 3.1 KB

CLAUDE.md

File metadata and controls

66 lines (49 loc) · 3.1 KB
Raw

PlaceOS is a building automation platform.

Working on this project

This crystal lang library is the control and logic layer, it manages the launching of client defined drivers and logic modules.

Use crystal tool format and ./bin/ameba to format and lint code. Run specs using ./test make sure to run specs using a subagent. You can also run individual spec files or use focus: true to isolate the spec you're working on. Tests can take some time to run.

Make sure to write thorough tests. Reference existing models in the lib folder if you want to see ORM internals. There are some extentions to the ORM in this project in ./lib/placeos-models/base/* if you need to understand why something isn't working.

Make sure to create and maintain a new plan file for each task to keep track of progress.

1. Plan Node Default

  • Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
  • If something goes sideways, STOP and re-plan immediately, don’t keep pushing
  • Use plan mode for verification steps, not just building
  • Write detailed specs upfront to reduce ambiguity

2. Subagent Strategy

  • Use subagents liberally to keep main context window clean
  • Offload research, exploration, and parallel analysis to subagents
  • For complex problems, throw more compute at it via subagents
  • One task per subagent for focused execution

3. Self-Improvement Loop

  • After ANY correction from the user, update tasks/lessons.md with the pattern
  • Write rules for yourself that prevent the same mistake
  • Ruthlessly iterate on these lessons until mistake rate drops
  • Review lessons at session start for relevant project

4. Verification Before Done

  • Never mark a task complete without proving it works
  • Diff behavior between main and your changes when relevant
  • Ask yourself: "Would a staff engineer approve this?"
  • Run tests, check logs, demonstrate correctness

5. Demand Elegance (Balanced)

  • For non-trivial changes, pause and ask: "Is there a more elegant way?"
  • If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
  • Skip this for simple, obvious fixes, don’t over-engineer
  • Challenge your own work before presenting it

6. Autonomous Bug Fixing

  • When given a bug report, don’t ask for hand-holding
  • Don’t start by trying to fix it. Instead, start by writing a test that reproduces the bug. Then, have subagents try to fix the bug and prove it by passing that test.
  • Point at logs, errors, failing tests, then resolve them
  • Zero context switching required from the user

Task Management

  1. Plan First: Write plan to tasks/todo.md with checkable items
  2. Verify Plan: Check in before starting implementation
  3. Track Progress: Mark items complete as you go
  4. Explain Changes: High-level summary at each step
  5. Document Results: Add review section to tasks/todo.md
  6. Capture Lessons: Update tasks/lessons.md after corrections

Core Principles

  • Simplicity First: Make every change as simple as possible. Impact minimal code.
  • No Laziness: Find root causes. No temporary fixes. Senior developer standards.