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.