{"owner":"aaif-goose","repo":"goose","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".github/copilot-instructions.md"],"files":{"AGENTS.md":"# AGENTS Instructions\n\ngoose is an AI agent framework in Rust with CLI and Electron desktop interfaces.\n\n## Contribution Workflow\n\nThe 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).\n\n- Before implementing an issue for a pull request, confirm that it is on the board with Status **Ready**.\n- Do not implement issues in **Inbox**, **Needs info**, or **Accepted / design**. Help resolve the issue discussion instead.\n- Read the agreed design, constraints, non-goals, and verification plan before changing code.\n- Keep the implementation within the issue's agreed scope.\n- If implementation reveals a material design change, return to the issue before continuing.\n- Every external pull request must link the Ready issue it implements and explain how the verification plan was performed.\n- Structure new issues on the matching template in `.github/ISSUE_TEMPLATE/` and set the issue type (e.g. Bug, Feature). `gh issue create` does not apply templates automatically.\n\nMaintainer-directed work, urgent security fixes, release automation, and local or exploratory changes do not require a Ready issue.\n\n## Agent Loop Migration\n\nWe are replacing the legacy agent loop in `crates/goose/src/agents/agent.rs` with the state machine in `crates/goose/src/agents/state_machine/`. The state-machine path is enabled with `GOOSE_STATE_MACHINE=1`.\n\nUntil the migration is complete, changes to agent-loop behavior must be implemented and tested in both paths. When reviewing code, check whether a change to either path also applies to the other and flag missing parity.\n\n## Setup\n```bash\nsource bin/activate-hermit\ncargo build\n```\n\n## Commands\n\n### Build\n```bash\ncargo build                   # debug\ncargo build --release         # release  \njust release-binary           # release binary\n```\n\n### Test\n```bash\ncargo test                   # all tests\ncargo test -p goose          # specific crate\ncargo test --package goose --test mcp_integration_test\njust record-mcp-tests        # record MCP\n```\n\n### Lint/Format\n```bash\ncargo fmt\ncargo clippy --all-targets -- -D warnings\n```\n\n### UI\n```bash\njust run-ui                  # start desktop\ncd ui/desktop && pnpm run typecheck\ncd ui/desktop && pnpm test   # test UI\n```\n\n## Structure\n```\ncrates/\n├── goose              # core logic\n├── goose-acp-macros   # ACP proc macros\n├── goose-cli          # CLI entry\n├── goose-mcp          # MCP extensions\n├── goose-test         # test utilities\n└── goose-test-support # test helpers\n\nui/desktop/            # Electron app\n```\n\n## Development Loop\n```bash\n# 1. source bin/activate-hermit\n# 2. Make changes\n# 3. cargo fmt\n```\n\n### Run these only if the user has asked you to build/test your changes:\n```\n# 1. cargo build\n# 2. cargo test -p <crate>\n# 3. cargo clippy --all-targets -- -D warnings\n```\n\n## Rules\n\n- Test: Prefer tests/ folder, e.g. crates/goose/tests/\n- Test: When adding features, update goose-self-test.yaml, rebuild, then run `goose run --recipe goose-self-test.yaml` to validate\n- Error: Use anyhow::Result\n- Provider: Implement Provider trait see providers/base.rs\n- MCP: Extensions in crates/goose-mcp/\n- UI Desktop: Use ACP SDK types or local `src/types/*` types. Do not import generated OpenAPI types/client code from `ui/desktop/src/api`\n\n## Code Quality\n\n- Comments: Write self-documenting code - prefer clear names over comments\n- Comments: Never add comments that restate what code does\n- Comments: Only comment for complex algorithms, non-obvious business logic, or \"why\" not \"what\"\n- Simplicity: Don't make things optional that don't need to be - the compiler will enforce\n- Simplicity: Booleans should default to false, not be optional\n- Errors: Don't add error context that doesn't add useful information (e.g., `.context(\"Failed to X\")` when error already says it failed)\n- Simplicity: Avoid overly defensive code - trust Rust's type system\n- Logging: Clean up existing logs, don't add more unless for errors or security events\n\n## Never\n\n- Never: Recreate `ui/desktop/src/api` or add `@hey-api/openapi-ts` to `ui/desktop`\n- Cargo.toml: For human-authored dependency changes, use `cargo add` instead of manually editing dependency entries unless there is a specific reason not to.\n- Cargo.toml: Automated dependency bump PRs are exempt; when manual edits are necessary, keep `Cargo.lock` consistent.\n- Never: Skip cargo fmt\n- Never: Merge without running clippy\n- Never: Comment self-evident operations (`// Initialize`, `// Return result`), getters/setters, constructors, or standard Rust idioms\n- 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\"\n\n## Entry Points\n- CLI: crates/goose-cli/src/main.rs\n- UI: ui/desktop/src/main.ts\n- Agent: crates/goose/src/agents/agent.rs\n",".github/copilot-instructions.md":"# GitHub Copilot Code Review Instructions\n\n## Review Philosophy\n- Only comment when you have HIGH CONFIDENCE (>80%) that an issue exists\n- Be concise: one sentence per comment when possible\n- Focus on actionable feedback, not observations\n- 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\n\n## Priority Areas (Review These)\n\n### Security & Safety\n- Unsafe code blocks without justification\n- Command injection risks (shell commands, user input)\n- Path traversal vulnerabilities\n- Credential exposure or hardcoded secrets\n- Missing input validation on external data\n- Improper error handling that could leak sensitive info\n\n### Correctness Issues\n- Logic errors that could cause panics or incorrect behavior\n- Race conditions in async code\n- Resource leaks (files, connections, memory)\n- Off-by-one errors or boundary conditions\n- Incorrect error propagation (using `unwrap()` inappropriately)\n- Optional types that don't need to be optional\n- Booleans that should default to false but are set as optional\n- Error context that doesn't add useful information (e.g., `.context(\"Failed to do X\")` when error already says it failed)\n- Overly defensive code that adds unnecessary checks\n- Unnecessary comments that just restate what the code already shows (remove them)\n\n### Architecture & Patterns\n- Code that violates existing patterns in the codebase\n- Missing error handling (should use `anyhow::Result`)\n- Async/await misuse or blocking operations in async contexts\n- Improper trait implementations\n\n### No Doc Updates with Code Changes\n- PRs with code changes shouldn't update `/documentation` - docs deploy on merge, code on release. Use `unlisted: true` or remove/hide docs.\n\n## Project-Specific Context\n\n- This is a Rust project using cargo workspaces\n- Core crates: `goose` (agent logic and ACP server), `goose-cli` (CLI), `goose-mcp` (MCP servers)\n- Error handling: Use `anyhow::Result`, not `unwrap()` in production code\n- Async runtime: tokio\n- MCP protocol implementations require extra scrutiny\n- Naming convention: In `documentation/docs` and `documentation/blog`, always refer to the project as \"goose\" (lowercase), never \"Goose\" (even at the start of sentences)\n\n## CI Pipeline Context\n\n**Important**: You review PRs immediately, before CI completes. Do not flag issues that CI will catch.\n\n### What Our CI Checks (`.github/workflows/ci.yml`)\n\n**Rust checks:**\n- `cargo fmt --check` - Code formatting (rustfmt)\n- `cargo test --jobs 2` - All tests\n- `cargo clippy --all-targets -- -D warnings` - Linting (clippy)\n\n**Desktop app checks:**\n- `pnpm install --frozen-lockfile` - Fresh dependency install (in `ui/desktop/`)\n- `pnpm run lint:check` - ESLint + Prettier\n- `pnpm run test:run` - Vitest tests\n\n**Setup steps CI performs:**\n- Installs system dependencies (libdbus, gnome-keyring, libxcb)\n- Activates hermit environment (`source bin/activate-hermit`)\n- Caches Cargo and pnpm dependencies\n- Runs `pnpm install --frozen-lockfile` before any pnpm scripts (ensures all packages are installed)\n\n**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.\n\n## Skip These (Low Value)\n\nDo not comment on:\n- **Style/formatting** - CI handles this (rustfmt, prettier)\n- **Clippy warnings** - CI handles this (clippy)\n- **Test failures** - CI handles this (full test suite)\n- **Missing dependencies** - CI handles this (pnpm install will fail)\n- **Minor naming suggestions** - unless truly confusing\n- **Suggestions to add comments** - for self-documenting code\n- **Refactoring suggestions** - unless there's a clear bug or maintainability issue\n- **Multiple issues in one comment** - choose the single most critical issue\n- **Logging suggestions** - unless for errors or security events (the codebase needs less logging, not more)\n- **Pedantic accuracy in text** - unless it would cause actual confusion or errors. No one likes a reply guy\n\n## Response Format\n\nWhen you identify an issue:\n1. **State the problem** (1 sentence)\n2. **Why it matters** (1 sentence, only if not obvious)\n3. **Suggested fix** (code snippet or specific action)\n\nExample:\n```\nThis could panic if the vector is empty. Consider using `.get(0)` or add a length check.\n```\n\n## When to Stay Silent\n\nIf you're uncertain whether something is an issue, don't comment. False positives create noise and reduce trust in the review process.\n"}}