Commit, branch, push, and open or update pull requests in this repository. Use before writing a commit message or PR title/body, pushing, stacking PRs, or when asked to "commit", "open a PR", or "push".
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Commit as you go on a feature branch, one logical change per commit, without
asking. Never commit to main. Push or open a PR only when the user asks.
<user>/<topic> in kebab-case, for example wolf/agent-rules. One concern per
branch. For dependent work, stack branches and open one PR per layer, each based on
the branch below it.
Conventional Commits: type(scope): summary.
The PR title follows the same form; squash merges use it as the commit on main.
feat, fix, perf, refactor, docs, test, ci, build,
chore. A breaking change adds ! (feat!:) and says what breaks in the body.channels, crm, auth, mcp, sync-service. Omit it when the change is
genuinely repo-wide.fix(channels): open conversations without loading their read history, not
fix: update channel loading logic.Run what applies to the files you changed, and fix failures before pushing:
just check # format, lint, code rules on changed files
cargo fmt --all -- --check # any Rust change
cargo x deps --check # Cargo.toml or crate added/removed
cargo x workflows --check # workflow generators changed
cargo x kafka-topics --check # macro_event_topics changed
GitHub Actions workflows are generated from Rust: edit
tooling/xtask/crates/xtask_workflows, never the YAML (see the
workflows rule).
Run the audit skill before handing off; it covers tests and area checks.
Write for a reviewer who hasn't seen the conversation. Use these sections, in order, and drop any that would be empty:
## Why
The problem or goal, with the evidence: the bug and how it shows up, numbers
measured, the user request. Link issues.
## How it works
A short high-level explanation of the approach, plus an ASCII diagram of the
flow, data shape, or before/after when one helps (cross-service flows, state
machines, pipelines). Drop it for small or mechanical changes.
## What
- One bullet per meaningful change, in reading order. Name files or modules
when it helps navigation. Call out decisions and alternatives rejected.
## Follow-ups
- Work deliberately left out, with the reason.
No test plan or testing section in PR descriptions or commit messages: CI shows
the checks, and what you ran goes in your report to the user. Attach proof for
user-visible changes: screenshots or a recording (see the record-proof skill
when it is available).
Open PRs ready for review, not as drafts; if one was created as a draft, mark it ready. A PR whose checks are failing or still running is not done: watch CI and fix failures before handing off.
Push follow-up commits rather than force-pushing over review history, unless the user asks for a rebase. When the scope changes, update the title and the What section to match.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Wrap a new backend endpoint in the TypeScript SDK (packages/sdk), or record it as skipped. Use when `just coverage` fails, or after adding an endpoint to a Rust service.
The English summary is being prepared. Showing the original description.
Add or change an in-app feature tour (a view's guided flyover) in the web app. Use when adding a tour to a view, adding or editing tour steps, pointing a step at a new control, or when a step's target needs something opened first.
The English summary is being prepared. Showing the original description.
Post-change checks before handing off. Works out which checks apply from the files changed (directory AGENTS.md Checks sections and matching .agents/rules), runs or verifies each, and reports pass/fail/skipped. Use before saying work is done, before pushing, or when asked to audit or verify a change.
The English summary is being prepared. Showing the original description.
Enforce hexagonal architecture in the Rust backend. Use before modifying crates/ or Rust services, especially inbound axum/tool/listener adapters, domain services/ports, outbound adapters, authorization, permissions, database access, or external clients.
The English summary is being prepared. Showing the original description.
Use when adding collaborative markdown, notes, or descriptions to a feature with collab surfaces. Covers parent entities, service entry points, authorization, content storage, and lifecycle.
The English summary is being prepared. Showing the original description.
Build a new AI tool end-to-end — Rust implementation, toolset wiring, infra, schema generation, and frontend UI.
The English summary is being prepared. Showing the original description.