Skip to content

Latest commit

 

History

History
50 lines (36 loc) · 2.87 KB

agents.md

File metadata and controls

50 lines (36 loc) · 2.87 KB
alwaysApply
true

Definition

  • The app's name is Philo.

Commit Discipline

  • Commit after every discrete action. Each meaningful change (e.g. adding a feature, fixing a bug, refactoring, updating docs, adding a test) must be committed individually before moving on.
  • Commit messages must use the intent as the title and a concise summary of what was done as the description/body.
  • Do not batch unrelated changes into a single commit.
  • If a task involves multiple steps, commit after each step — not all at the end.

Branching (Git Butler)

  • Use Git Butler to manage branches so independent work can run concurrently.
  • If the current branch is main, commit directly on main.
  • If the current branch name is gitbutler/workspace or starts with gitbutler/workspace, use the /commit-msg skill to draft the commit message, create a GitButler virtual branch for the logical change, and push that virtual branch.
  • Prefer one branch and PR per logical unit of work.
  • If a change depends on another open change, use stacked branches and stacked PRs so dependency order is explicit.
  • Only split work into multiple PRs when dependency or review scope makes it necessary.

Releases

  • When asked to create a release: bump the version in apps/desktop/src-tauri/Cargo.toml and apps/desktop/src-tauri/tauri.conf.json, run pnpm run release:check, then commit, push, and create the release with gh release create. Do not create the release if pnpm run release:check fails. The CI workflow (.github/workflows/release.yml) will automatically build and upload platform binaries (.dmg, .exe, etc.) to the release.
  • Releases must be published immediately — do not use --draft.
  • Include release notes with concise, descriptive bullet points explaining what changed (e.g. - Add @ autocomplete dropdown for selecting tasks by ID or title). Do not just list version numbers or raw commit messages.
  • Each bullet should describe the user-facing change, not implementation details.

Comments

  • By default, avoid writing comments at all.
  • If you write one, it should be about "Why", not "What".

General

  • Avoid creating unnecessary structs, enums, or traits if they are not shared. Prefer inlining types when they're only used in one place.
  • Run turbo typecheck --force && dprint fmt before committing.
  • Run cargo fmt --check and apply cargo fmt before committing Rust changes.
  • Run cargo clippy and fix any warnings before committing Rust changes.
  • Run cargo check periodically while making Rust changes to catch errors early — don't wait until the end.
  • Run cargo build after Rust code changes to verify compilation before committing.
  • Keep commits small and reviewable.

TypeScript

  • Avoid creating a bunch of types/interfaces if they are not shared. Especially for function props. Just inline them.
  • After some amount of TypeScript changes, run turbo typecheck.