{"owner":"gitbutlerapp","repo":"gitbutler","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# GitButler Agent Instructions\n\nGitButler is a Rust/Svelte/React/TypeScript monorepo.\n\nApply all relevant instruction files. If instructions conflict, resolve them in\nthis order:\n\n1. Explicit human instructions\n2. Nearest nested `AGENTS.md`\n3. This file\n\n## Repo Map\n\n- `crates/` - Rust crates.\n- `apps/desktop/` - Tauri/Svelte desktop app.\n- `apps/web/` - Svelte web app.\n- `apps/lite/` - Electron/React desktop app.\n- `packages/` - shared TypeScript packages, including the SDK.\n- `e2e/` - Playwright, WebdriverIO, and blackbox end-to-end tests.\n\n## Working Style\n\n- Treat questions about the codebase as read-only unless the user asks for changes.\n- Make focused, reviewable changes; avoid unrelated rewrites.\n- Use the simplest design that solves the actual problem; do not add\n  speculative machinery, and remove machinery your change makes unnecessary.\n- Inspect nearby code before introducing patterns.\n- Prefer existing APIs, tests, and conventions.\n- Before declaring shared behavior done, check each applicable surface and contract\n  (desktop, web, Lite, CLI/TUI, N-API, SDK, and docs) and update it or explicitly\n  determine that it is unaffected.\n- Run targeted validation for the area touched.\n- Before adding new machinery to fix a behavior bug, reproduce the bug in a failing\n  test and survey the target file's existing loops and classifications as candidate\n  hosts; let the tests, not the diagnosis, set how much implementation the fix needs.\n- When a fix calls for a new mechanism (a new module, a new public API, or a parallel\n  walk where one already exists), propose the intended shape before building it.\n\n## Scoped Instructions\n\n- For Rust work under `crates/`, follow `crates/AGENTS.md`.\n- For Lite work under `apps/lite/`, follow `apps/lite/AGENTS.md`.\n"},"files":{"AGENTS.md":"# GitButler Agent Instructions\n\nGitButler is a Rust/Svelte/React/TypeScript monorepo.\n\nApply all relevant instruction files. If instructions conflict, resolve them in\nthis order:\n\n1. Explicit human instructions\n2. Nearest nested `AGENTS.md`\n3. This file\n\n## Repo Map\n\n- `crates/` - Rust crates.\n- `apps/desktop/` - Tauri/Svelte desktop app.\n- `apps/web/` - Svelte web app.\n- `apps/lite/` - Electron/React desktop app.\n- `packages/` - shared TypeScript packages, including the SDK.\n- `e2e/` - Playwright, WebdriverIO, and blackbox end-to-end tests.\n\n## Working Style\n\n- Treat questions about the codebase as read-only unless the user asks for changes.\n- Make focused, reviewable changes; avoid unrelated rewrites.\n- Use the simplest design that solves the actual problem; do not add\n  speculative machinery, and remove machinery your change makes unnecessary.\n- Inspect nearby code before introducing patterns.\n- Prefer existing APIs, tests, and conventions.\n- Before declaring shared behavior done, check each applicable surface and contract\n  (desktop, web, Lite, CLI/TUI, N-API, SDK, and docs) and update it or explicitly\n  determine that it is unaffected.\n- Run targeted validation for the area touched.\n- Before adding new machinery to fix a behavior bug, reproduce the bug in a failing\n  test and survey the target file's existing loops and classifications as candidate\n  hosts; let the tests, not the diagnosis, set how much implementation the fix needs.\n- When a fix calls for a new mechanism (a new module, a new public API, or a parallel\n  walk where one already exists), propose the intended shape before building it.\n\n## Scoped Instructions\n\n- For Rust work under `crates/`, follow `crates/AGENTS.md`.\n- For Lite work under `apps/lite/`, follow `apps/lite/AGENTS.md`.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# GitButler Agent Instructions\n\nGitButler is a Rust/Svelte/React/TypeScript monorepo.\n\nApply all relevant instruction files. If instructions conflict, resolve them in\nthis order:\n\n1. Explicit human instructions\n2. Nearest nested `AGENTS.md`\n3. This file\n\n## Repo Map\n\n- `crates/` - Rust crates.\n- `apps/desktop/` - Tauri/Svelte desktop app.\n- `apps/web/` - Svelte web app.\n- `apps/lite/` - Electron/React desktop app.\n- `packages/` - shared TypeScript packages, including the SDK.\n- `e2e/` - Playwright, WebdriverIO, and blackbox end-to-end tests.\n\n## Working Style\n\n- Treat questions about the codebase as read-only unless the user asks for changes.\n- Make focused, reviewable changes; avoid unrelated rewrites.\n- Use the simplest design that solves the actual problem; do not add\n  speculative machinery, and remove machinery your change makes unnecessary.\n- Inspect nearby code before introducing patterns.\n- Prefer existing APIs, tests, and conventions.\n- Before declaring shared behavior done, check each applicable surface and contract\n  (desktop, web, Lite, CLI/TUI, N-API, SDK, and docs) and update it or explicitly\n  determine that it is unaffected.\n- Run targeted validation for the area touched.\n- Before adding new machinery to fix a behavior bug, reproduce the bug in a failing\n  test and survey the target file's existing loops and classifications as candidate\n  hosts; let the tests, not the diagnosis, set how much implementation the fix needs.\n- When a fix calls for a new mechanism (a new module, a new public API, or a parallel\n  walk where one already exists), propose the intended shape before building it.\n\n## Scoped Instructions\n\n- For Rust work under `crates/`, follow `crates/AGENTS.md`.\n- For Lite work under `apps/lite/`, follow `apps/lite/AGENTS.md`.\n","category":"root","tokens":445}]}