{"owner":"j178","repo":"prek","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"## Code Quality\n\n- Write elegant, efficient, and concise code. Prefer simple, clear designs;\n  concise does not mean clever.\n- Prefer the smallest coherent change. Reuse existing mechanisms and avoid wrappers\n  or abstractions for speculative or unmeasured gains.\n- Prefer direct `if` or `match` control flow and explicit state types over clever\n  combinators, wrappers, or invalid boolean/`Option` combinations. Prefer plain\n  `if`/`else` to `.then()` or `.then_some()`.\n- Try hard to avoid `panic!`, `unreachable!`, `.unwrap()`, and `.expect()`. Encode\n  those constraints in the type system instead. More explicit code or a larger\n  refactor is acceptable when it avoids these calls.\n- Do not narrate code in comments. Explain invariants and unusual decisions in plain\n  language that makes sense to a first-time reader. Be more verbose when clarity\n  requires it.\n- Fix Clippy findings. If suppression is necessary, prefer a narrow\n  `#[expect(...)]` with a reason.\n\n## Writing Style\n\n- Write natural, direct English that sounds like a human collaborator, not a\n  template or an AI-generated response.\n- Avoid canned introductions, generic filler, repetition, and unnecessary\n  summaries.\n- Avoid dash-heavy prose, especially em dashes or `-` used to join thoughts.\n  Prefer a period, comma, colon, or an explicit conjunction. For example, prefer\n  `This is safe because the fallback still validates the state.` over\n  `This is safe - the fallback still validates the state.`\n\n## Build and Tests\n\n- Linked worktrees must share the primary Cargo target. Before running `cargo` or a\n  Cargo-backed `mise` task, set:\n\n    ```sh\n    export CARGO_TARGET_DIR=\"$(dirname \"$(git rev-parse --path-format=absolute --git-common-dir)\")/target\"\n    ```\n\n- Check existing coverage and nearby style before adding a test. Prefer focused\n  tests; do not run the full integration suite by default.\n\n- In integration tests, prefer `cmd_snapshot!` snapshot coverage over\n  string assertions such as `contains`.\n\n- Regenerate `insta` snapshots with the relevant test and review them with\n  `cargo insta review`; do not edit them manually.\n\n## GitHub Interaction\n\n- Draft GitHub comments locally. Do not post, submit reviews, resolve threads, or\n  otherwise mutate GitHub state without explicit authorization.\n\n## Pull Requests\n\n- Keep commits focused with short imperative subjects. Never publish unrelated\n  history or changes.\n- Use the shortest practical branch name without a `codex/` prefix.\n- Use a moderately descriptive title that clearly states the core action while\n  remaining concise. Prefer `Build and reuse a run-scoped file index` over\n  `Build run file index once`.\n- Keep the PR body short; it may be only `Closes #<issue no>`.\n- Do not include verification steps in the PR body.\n- Add an appropriate `bug`, `enhancement`, `performance`, `internal`, `ci`, or\n  `documentation` label.\n- Do not create a draft PR unless explicitly requested.\n- On an existing PR branch, amend only a trivial same-scope change; otherwise add a\n  commit. Do not push or alter review state unless explicitly requested.\n"},"files":{"AGENTS.md":"## Code Quality\n\n- Write elegant, efficient, and concise code. Prefer simple, clear designs;\n  concise does not mean clever.\n- Prefer the smallest coherent change. Reuse existing mechanisms and avoid wrappers\n  or abstractions for speculative or unmeasured gains.\n- Prefer direct `if` or `match` control flow and explicit state types over clever\n  combinators, wrappers, or invalid boolean/`Option` combinations. Prefer plain\n  `if`/`else` to `.then()` or `.then_some()`.\n- Try hard to avoid `panic!`, `unreachable!`, `.unwrap()`, and `.expect()`. Encode\n  those constraints in the type system instead. More explicit code or a larger\n  refactor is acceptable when it avoids these calls.\n- Do not narrate code in comments. Explain invariants and unusual decisions in plain\n  language that makes sense to a first-time reader. Be more verbose when clarity\n  requires it.\n- Fix Clippy findings. If suppression is necessary, prefer a narrow\n  `#[expect(...)]` with a reason.\n\n## Writing Style\n\n- Write natural, direct English that sounds like a human collaborator, not a\n  template or an AI-generated response.\n- Avoid canned introductions, generic filler, repetition, and unnecessary\n  summaries.\n- Avoid dash-heavy prose, especially em dashes or `-` used to join thoughts.\n  Prefer a period, comma, colon, or an explicit conjunction. For example, prefer\n  `This is safe because the fallback still validates the state.` over\n  `This is safe - the fallback still validates the state.`\n\n## Build and Tests\n\n- Linked worktrees must share the primary Cargo target. Before running `cargo` or a\n  Cargo-backed `mise` task, set:\n\n    ```sh\n    export CARGO_TARGET_DIR=\"$(dirname \"$(git rev-parse --path-format=absolute --git-common-dir)\")/target\"\n    ```\n\n- Check existing coverage and nearby style before adding a test. Prefer focused\n  tests; do not run the full integration suite by default.\n\n- In integration tests, prefer `cmd_snapshot!` snapshot coverage over\n  string assertions such as `contains`.\n\n- Regenerate `insta` snapshots with the relevant test and review them with\n  `cargo insta review`; do not edit them manually.\n\n## GitHub Interaction\n\n- Draft GitHub comments locally. Do not post, submit reviews, resolve threads, or\n  otherwise mutate GitHub state without explicit authorization.\n\n## Pull Requests\n\n- Keep commits focused with short imperative subjects. Never publish unrelated\n  history or changes.\n- Use the shortest practical branch name without a `codex/` prefix.\n- Use a moderately descriptive title that clearly states the core action while\n  remaining concise. Prefer `Build and reuse a run-scoped file index` over\n  `Build run file index once`.\n- Keep the PR body short; it may be only `Closes #<issue no>`.\n- Do not include verification steps in the PR body.\n- Add an appropriate `bug`, `enhancement`, `performance`, `internal`, `ci`, or\n  `documentation` label.\n- Do not create a draft PR unless explicitly requested.\n- On an existing PR branch, amend only a trivial same-scope change; otherwise add a\n  commit. Do not push or alter review state unless explicitly requested.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"## Code Quality\n\n- Write elegant, efficient, and concise code. Prefer simple, clear designs;\n  concise does not mean clever.\n- Prefer the smallest coherent change. Reuse existing mechanisms and avoid wrappers\n  or abstractions for speculative or unmeasured gains.\n- Prefer direct `if` or `match` control flow and explicit state types over clever\n  combinators, wrappers, or invalid boolean/`Option` combinations. Prefer plain\n  `if`/`else` to `.then()` or `.then_some()`.\n- Try hard to avoid `panic!`, `unreachable!`, `.unwrap()`, and `.expect()`. Encode\n  those constraints in the type system instead. More explicit code or a larger\n  refactor is acceptable when it avoids these calls.\n- Do not narrate code in comments. Explain invariants and unusual decisions in plain\n  language that makes sense to a first-time reader. Be more verbose when clarity\n  requires it.\n- Fix Clippy findings. If suppression is necessary, prefer a narrow\n  `#[expect(...)]` with a reason.\n\n## Writing Style\n\n- Write natural, direct English that sounds like a human collaborator, not a\n  template or an AI-generated response.\n- Avoid canned introductions, generic filler, repetition, and unnecessary\n  summaries.\n- Avoid dash-heavy prose, especially em dashes or `-` used to join thoughts.\n  Prefer a period, comma, colon, or an explicit conjunction. For example, prefer\n  `This is safe because the fallback still validates the state.` over\n  `This is safe - the fallback still validates the state.`\n\n## Build and Tests\n\n- Linked worktrees must share the primary Cargo target. Before running `cargo` or a\n  Cargo-backed `mise` task, set:\n\n    ```sh\n    export CARGO_TARGET_DIR=\"$(dirname \"$(git rev-parse --path-format=absolute --git-common-dir)\")/target\"\n    ```\n\n- Check existing coverage and nearby style before adding a test. Prefer focused\n  tests; do not run the full integration suite by default.\n\n- In integration tests, prefer `cmd_snapshot!` snapshot coverage over\n  string assertions such as `contains`.\n\n- Regenerate `insta` snapshots with the relevant test and review them with\n  `cargo insta review`; do not edit them manually.\n\n## GitHub Interaction\n\n- Draft GitHub comments locally. Do not post, submit reviews, resolve threads, or\n  otherwise mutate GitHub state without explicit authorization.\n\n## Pull Requests\n\n- Keep commits focused with short imperative subjects. Never publish unrelated\n  history or changes.\n- Use the shortest practical branch name without a `codex/` prefix.\n- Use a moderately descriptive title that clearly states the core action while\n  remaining concise. Prefer `Build and reuse a run-scoped file index` over\n  `Build run file index once`.\n- Keep the PR body short; it may be only `Closes #<issue no>`.\n- Do not include verification steps in the PR body.\n- Add an appropriate `bug`, `enhancement`, `performance`, `internal`, `ci`, or\n  `documentation` label.\n- Do not create a draft PR unless explicitly requested.\n- On an existing PR branch, amend only a trivial same-scope change; otherwise add a\n  commit. Do not push or alter review state unless explicitly requested.\n","category":"root","tokens":775}]}