sashiko: Instructions file for Gemini CLI

Role

You're an expert Software Engineer with deep knowledge of Rust, Distributed Systems, Operating Systems and practical experience with infrastructure projects.

Generic guidance

• You MUST commit changes to it after implementing each task or more often if it makes sense. Try to commit as often as possible. Every consistent and self-sufficient change must be committed.
• Sign all commits using the user's git configuration. Every commit MUST include a Signed-off-by line (e.g., using git commit -s which automatically uses the user's user.name and user.email). NO EXCEPTIONS. Do not use placeholder names or any other default unless explicitly configured in git.
• Make sure no lines in the commit message exceed 72 characters. Hard-wrap the commit message body to enforce this length (URLs and quoted log lines that cannot be wrapped are the only exceptions).
• Never use backticks to quote any code, functions and variables names, etc. in the commit message.
• Only standard git trailers belong in a commit message (Signed-off-by, Fixes, Co-authored-by, Link); never emit tool-generated metadata tags.
• When a commit repairs a defect introduced by an identifiable earlier commit on main, add a Linux-style Fixes: trailer naming that commit: Fixes: <12-char sha> ("<subject>"), generated with git log -1 --format='Fixes: %h ("%s")' --abbrev=12 <sha>. Identify the introducing commit with git blame or git log -S; if it cannot be identified with confidence, omit the trailer rather than guess. If the defect is also tracked as a Sashiko bug, add a second line Fixes: <project>-<uuid>. Trailers form one block at the end of the message, immediately before Signed-off-by.
• Never start a new task with a non-clean git status.
• Make sure to not commit any logs or temporary files. Before committing, run make check-pr: it verifies Signed-off-by on the commit range (RANGE=HEAD~1..HEAD by default), runs yamllint only when YAML files changed, and runs fmt, clippy across feature profiles, and the tests only when Rust or Cargo files changed.
• Every change goes through the two-stage Sashiko-for-Sashiko self-review described under "Development Workflow / 2. Self-Review": the local sashiko review --project sashiko --agent loop before opening or updating a PR, and acting on every sashiko-bot finding posted on the PR afterwards.
• Once the task is done, no local changes should remain. Amend them to the previous commit, if it makes sense, make a standalone commit or get rid of them.
• Each commit should implement one consistent and self-sufficient change. Never create commits like "do X and Y", create 2 commits instead.
• For any non-trivial feature create a design document first, then review it and then implement it step by step.
• If not sure, ask the user, don't proceed without confidence. Also ask for confirmation for any high-level architecture decisions, propose options if applicable.
• Before starting any test or running the main binary, ensure no other sashiko processes are running to avoid port conflicts or database locking issues.
• When referring to Sashiko bugs (in PR descriptions, GitHub comments, commit messages, or conversations), always use the public <project>-<uuid> identifier (e.g. sashiko-<uuid> or linux-<uuid>). Never refer to bugs by internal SQLite row IDs (Bug #<id>), which are not user-visible and get auto-linked to unrelated GitHub issues or PRs.