| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 21 | 13 | 0% |
| Commands | 1 | 10 | 6 | 6% |
| Section tags | 6 | 4 | 3 | 46% |
What each file covers
Sections
0 shared · 21 only in A · 13 only in B- − AGENTS Instructions
- − Contribution Workflow
- − Setup
- − Commands
- − Build
- − Test
- − Lint/Format
- − UI
- − Structure
- − Development Loop
- − 1. source bin/activate-hermit
- − 2. Make changes
- − 3. cargo fmt
- − Run these only if the user has asked you to build/test your changes:
- − 1. cargo build
- − 2. cargo test -p <crate>
- − 3. cargo clippy --all-targets -- -D warnings
- − Rules
- − Code Quality
- − Never
- − Entry Points
- + GitHub Copilot Code Review Instructions
- + Review Philosophy
- + Priority Areas (Review These)
- + Security & Safety
- + Correctness Issues
- + Architecture & Patterns
- + No Doc Updates with Code Changes
- + Project-Specific Context
- + CI Pipeline Context
- + What Our CI Checks (`.github/workflows/ci.yml`)
- + Skip These (Low Value)
- + Response Format
- + When to Stay Silent
Commands
1 shared · 10 only in A · 6 only in B- − cargo build
- − cargo build --release
- − just release-binary
- − cargo test
- − cargo test -p goose
- − cargo test --package goose --test mcp_integration_test
- − just record-mcp-tests
- − cargo fmt
- − just run-ui
- − cargo add
- + cargo fmt --check
- + cargo test --jobs 2
- + pnpm install --frozen-lockfile
- + pnpm run lint:check
- + pnpm run test:run
- + npx
- cargo clippy --all-targets -- -D warnings
Section tags
6 shared · 4 only in A · 3 only in B- − build
- − architecture
- − ui
- − do-not
- + security
- + deployment
- + docs
- setup
- test
- lint-format
- code-style
- git-pr
- agent-behaviour
Line diff
aaif-goose/goose · AGENTS.md
@@ −1 @@
1# AGENTS Instructions
2
3goose is an AI agent framework in Rust with CLI and Electron desktop interfaces.
4
5## Contribution Workflow
6
7The issue is the source of truth for work intended for an upstream pull request. Track issue status on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).
8
9- Before implementing an issue for a pull request, confirm that it is on the board with Status **Ready**.
10- Do not implement issues in **Inbox**, **Needs info**, or **Accepted / design**. Help resolve the issue discussion instead.
11- Read the agreed design, constraints, non-goals, and verification plan before changing code.
12- Keep the implementation within the issue's agreed scope.
13- If implementation reveals a material design change, return to the issue before continuing.
14- Every external pull request must link the Ready issue it implements and explain how the verification plan was performed.
15
16Maintainer-directed work, urgent security fixes, release automation, and local or exploratory changes do not require a Ready issue.
17
18## Setup
19```bash
20source bin/activate-hermit
21cargo build
22```
23
24## Commands
25
26### Build
27```bash
28cargo build # debug
29cargo build --release # release
30just release-binary # release binary
31```
32
33### Test
34```bash
35cargo test # all tests
36cargo test -p goose # specific crate
37cargo test --package goose --test mcp_integration_test
38just record-mcp-tests # record MCP
39```
40
41### Lint/Format
42```bash
43cargo fmt
44cargo clippy --all-targets -- -D warnings
45```
46
47### UI
48```bash
49just run-ui # start desktop
50cd ui/desktop && pnpm run typecheck
51cd ui/desktop && pnpm test # test UI
52```
53
54## Structure
55```
56crates/
57├── goose # core logic
58├── goose-acp-macros # ACP proc macros
59├── goose-cli # CLI entry
60├── goose-mcp # MCP extensions
61├── goose-test # test utilities
62└── goose-test-support # test helpers
63
64ui/desktop/ # Electron app
65```
66
67## Development Loop
68```bash
69# 1. source bin/activate-hermit
70# 2. Make changes
71# 3. cargo fmt
72```
73
74### Run these only if the user has asked you to build/test your changes:
75```
76# 1. cargo build
77# 2. cargo test -p <crate>
78# 3. cargo clippy --all-targets -- -D warnings
79```
80
81## Rules
82
83- Test: Prefer tests/ folder, e.g. crates/goose/tests/
84- Test: When adding features, update goose-self-test.yaml, rebuild, then run `goose run --recipe goose-self-test.yaml` to validate
85- Error: Use anyhow::Result
86- Provider: Implement Provider trait see providers/base.rs
87- MCP: Extensions in crates/goose-mcp/
88- UI Desktop: Use ACP SDK types or local `src/types/*` types. Do not import generated OpenAPI types/client code from `ui/desktop/src/api`
89
90## Code Quality
91
92- Comments: Write self-documenting code - prefer clear names over comments
93- Comments: Never add comments that restate what code does
94- Comments: Only comment for complex algorithms, non-obvious business logic, or "why" not "what"
95- Simplicity: Don't make things optional that don't need to be - the compiler will enforce
96- Simplicity: Booleans should default to false, not be optional
97- Errors: Don't add error context that doesn't add useful information (e.g., `.context("Failed to X")` when error already says it failed)
98- Simplicity: Avoid overly defensive code - trust Rust's type system
99- Logging: Clean up existing logs, don't add more unless for errors or security events
100
101## Never
102
103- Never: Recreate `ui/desktop/src/api` or add `@hey-api/openapi-ts` to `ui/desktop`
104- Cargo.toml: For human-authored dependency changes, use `cargo add` instead of manually editing dependency entries unless there is a specific reason not to.
105- Cargo.toml: Automated dependency bump PRs are exempt; when manual edits are necessary, keep `Cargo.lock` consistent.
106- Never: Skip cargo fmt
107- Never: Merge without running clippy
108- Never: Comment self-evident operations (`// Initialize`, `// Return result`), getters/setters, constructors, or standard Rust idioms
109- Never: Overwrite a live binary in place (e.g. `cp`/`fs.copyFileSync` onto an existing executable) - unlink or atomic-rename the destination first, otherwise macOS SIGKILLs running processes with "Code Signature Invalid"
110
111## Entry Points
112- CLI: crates/goose-cli/src/main.rs
113- UI: ui/desktop/src/main.ts
114- Agent: crates/goose/src/agents/agent.rs
115
aaif-goose/goose · .github/copilot-instructions.md
@@ +1 @@
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
@@ −1 +1 @@
1−# AGENTS Instructions
1+# GitHub Copilot Code Review Instructions
22
3−goose is an AI agent framework in Rust with CLI and Electron desktop interfaces.
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
48
5−## Contribution Workflow
9+## Priority Areas (Review These)
610
7−The issue is the source of truth for work intended for an upstream pull request. Track issue status on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).
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
818
9−- Before implementing an issue for a pull request, confirm that it is on the board with Status **Ready**.
10−- Do not implement issues in **Inbox**, **Needs info**, or **Accepted / design**. Help resolve the issue discussion instead.
11−- Read the agreed design, constraints, non-goals, and verification plan before changing code.
12−- Keep the implementation within the issue's agreed scope.
13−- If implementation reveals a material design change, return to the issue before continuing.
14−- Every external pull request must link the Ready issue it implements and explain how the verification plan was performed.
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)
1530
16−Maintainer-directed work, urgent security fixes, release automation, and local or exploratory changes do not require a Ready issue.
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
1736
18−## Setup
19−```bash
20−source bin/activate-hermit
21−cargo build
22−```
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.
2339
24−## Commands
40+## Project-Specific Context
2541
26−### Build
27−```bash
28−cargo build # debug
29−cargo build --release # release
30−just release-binary # release binary
31−```
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)
3248
33−### Test
34−```bash
35−cargo test # all tests
36−cargo test -p goose # specific crate
37−cargo test --package goose --test mcp_integration_test
38−just record-mcp-tests # record MCP
39−```
49+## CI Pipeline Context
4050
41−### Lint/Format
42−```bash
43−cargo fmt
44−cargo clippy --all-targets -- -D warnings
45−```
51+**Important**: You review PRs immediately, before CI completes. Do not flag issues that CI will catch.
4652
47−### UI
48−```bash
49−just run-ui # start desktop
50−cd ui/desktop && pnpm run typecheck
51−cd ui/desktop && pnpm test # test UI
52−```
53+### What Our CI Checks (`.github/workflows/ci.yml`)
5354
54−## Structure
55−```
56−crates/
57−├── goose # core logic
58−├── goose-acp-macros # ACP proc macros
59−├── goose-cli # CLI entry
60−├── goose-mcp # MCP extensions
61−├── goose-test # test utilities
62−└── goose-test-support # test helpers
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)
6359
64−ui/desktop/ # Electron app
65−```
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
6664
67−## Development Loop
68−```bash
69−# 1. source bin/activate-hermit
70−# 2. Make changes
71−# 3. cargo fmt
72−```
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)
7370
74−### Run these only if the user has asked you to build/test your changes:
75−```
76−# 1. cargo build
77−# 2. cargo test -p <crate>
78−# 3. cargo clippy --all-targets -- -D warnings
79−```
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.
8072
81−## Rules
73+## Skip These (Low Value)
8274
83−- Test: Prefer tests/ folder, e.g. crates/goose/tests/
84−- Test: When adding features, update goose-self-test.yaml, rebuild, then run `goose run --recipe goose-self-test.yaml` to validate
85−- Error: Use anyhow::Result
86−- Provider: Implement Provider trait see providers/base.rs
87−- MCP: Extensions in crates/goose-mcp/
88−- UI Desktop: Use ACP SDK types or local `src/types/*` types. Do not import generated OpenAPI types/client code from `ui/desktop/src/api`
75+Do 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
8986
90−## Code Quality
87+## Response Format
9188
92−- Comments: Write self-documenting code - prefer clear names over comments
93−- Comments: Never add comments that restate what code does
94−- Comments: Only comment for complex algorithms, non-obvious business logic, or "why" not "what"
95−- Simplicity: Don't make things optional that don't need to be - the compiler will enforce
96−- Simplicity: Booleans should default to false, not be optional
97−- Errors: Don't add error context that doesn't add useful information (e.g., `.context("Failed to X")` when error already says it failed)
98−- Simplicity: Avoid overly defensive code - trust Rust's type system
99−- Logging: Clean up existing logs, don't add more unless for errors or security events
89+When you identify an issue:
90+1. **State the problem** (1 sentence)
91+2. **Why it matters** (1 sentence, only if not obvious)
92+3. **Suggested fix** (code snippet or specific action)
10093
101−## Never
94+Example:
95+```
96+This could panic if the vector is empty. Consider using `.get(0)` or add a length check.
97+```
10298
103−- Never: Recreate `ui/desktop/src/api` or add `@hey-api/openapi-ts` to `ui/desktop`
104−- Cargo.toml: For human-authored dependency changes, use `cargo add` instead of manually editing dependency entries unless there is a specific reason not to.
105−- Cargo.toml: Automated dependency bump PRs are exempt; when manual edits are necessary, keep `Cargo.lock` consistent.
106−- Never: Skip cargo fmt
107−- Never: Merge without running clippy
108−- Never: Comment self-evident operations (`// Initialize`, `// Return result`), getters/setters, constructors, or standard Rust idioms
109−- Never: Overwrite a live binary in place (e.g. `cp`/`fs.copyFileSync` onto an existing executable) - unlink or atomic-rename the destination first, otherwise macOS SIGKILLs running processes with "Code Signature Invalid"
99+## When to Stay Silent
110100
111−## Entry Points
112−- CLI: crates/goose-cli/src/main.rs
113−- UI: ui/desktop/src/main.ts
114−- Agent: crates/goose/src/agents/agent.rs
101+If you're uncertain whether something is an issue, don't comment. False positives create noise and reduce trust in the review process.
115102
