Copilot instructions

1# GitHub Copilot Code Review Instructions
2 
3## Review Philosophy
4- Only comment when you have HIGH CONFIDENCE (>80%) that an issue exists
5- Be concise: one sentence per comment when possible
6- Focus on actionable feedback, not observations
7- When reviewing text, only comment on clarity issues if the text is genuinely confusing or could lead to errors. "Could be clearer" is not the same as "is confusing" - stay silent unless HIGH confidence it will cause problems
8 
9## Priority Areas (Review These)
10 
11### Security & Safety
12- Unsafe code blocks without justification
13- Command injection risks (shell commands, user input)
14- Path traversal vulnerabilities
15- Credential exposure or hardcoded secrets
16- Missing input validation on external data
17- Improper error handling that could leak sensitive info
18 
19### Correctness Issues
20- Logic errors that could cause panics or incorrect behavior
21- Race conditions in async code
22- Resource leaks (files, connections, memory)
23- Off-by-one errors or boundary conditions
24- Incorrect error propagation (using `unwrap()` inappropriately)
25- Optional types that don't need to be optional
26- Booleans that should default to false but are set as optional
27- Error context that doesn't add useful information (e.g., `.context("Failed to do X")` when error already says it failed)
28- Overly defensive code that adds unnecessary checks
29- Unnecessary comments that just restate what the code already shows (remove them)
30 
31### Architecture & Patterns
32- Code that violates existing patterns in the codebase
33- Missing error handling (should use `anyhow::Result`)
34- Async/await misuse or blocking operations in async contexts
35- Improper trait implementations
36 
37### No Doc Updates with Code Changes
38- PRs with code changes shouldn't update `/documentation` - docs deploy on merge, code on release. Use `unlisted: true` or remove/hide docs.
39 
40## Project-Specific Context
41 
42- This is a Rust project using cargo workspaces
43- Core crates: `goose` (agent logic and ACP server), `goose-cli` (CLI), `goose-mcp` (MCP servers)
44- Error handling: Use `anyhow::Result`, not `unwrap()` in production code
45- Async runtime: tokio
46- MCP protocol implementations require extra scrutiny
47- Naming convention: In `documentation/docs` and `documentation/blog`, always refer to the project as "goose" (lowercase), never "Goose" (even at the start of sentences)
48 
49## CI Pipeline Context
50 
51**Important**: You review PRs immediately, before CI completes. Do not flag issues that CI will catch.
52 
53### What Our CI Checks (`.github/workflows/ci.yml`)
54 
55**Rust checks:**
56- `cargo fmt --check` - Code formatting (rustfmt)
57- `cargo test --jobs 2` - All tests
58- `cargo clippy --all-targets -- -D warnings` - Linting (clippy)
59 
60**Desktop app checks:**
61- `pnpm install --frozen-lockfile` - Fresh dependency install (in `ui/desktop/`)
62- `pnpm run lint:check` - ESLint + Prettier
63- `pnpm run test:run` - Vitest tests
64 
65**Setup steps CI performs:**
66- Installs system dependencies (libdbus, gnome-keyring, libxcb)
67- Activates hermit environment (`source bin/activate-hermit`)
68- Caches Cargo and pnpm dependencies
69- Runs `pnpm install --frozen-lockfile` before any pnpm scripts (ensures all packages are installed)
70 
71**Key insight**: Commands like `npx` check local `node_modules` first, which CI installs via `pnpm install --frozen-lockfile`. Don't flag these as broken unless you can explain why CI setup wouldn't handle it.
72 
73## Skip These (Low Value)
74 
75Do not comment on:
76- **Style/formatting** - CI handles this (rustfmt, prettier)
77- **Clippy warnings** - CI handles this (clippy)
78- **Test failures** - CI handles this (full test suite)
79- **Missing dependencies** - CI handles this (pnpm install will fail)
80- **Minor naming suggestions** - unless truly confusing
81- **Suggestions to add comments** - for self-documenting code
82- **Refactoring suggestions** - unless there's a clear bug or maintainability issue
83- **Multiple issues in one comment** - choose the single most critical issue
84- **Logging suggestions** - unless for errors or security events (the codebase needs less logging, not more)
85- **Pedantic accuracy in text** - unless it would cause actual confusion or errors. No one likes a reply guy
86 
87## Response Format
88 
89When you identify an issue:
901. **State the problem** (1 sentence)
912. **Why it matters** (1 sentence, only if not obvious)
923. **Suggested fix** (code snippet or specific action)
93 
94Example:
95```
96This could panic if the vector is empty. Consider using `.get(0)` or add a length check.
97```
98 
99## When to Stay Silent
100 
101If you're uncertain whether something is an issue, don't comment. False positives create noise and reduce trust in the review process.
102