{"owner":"astral-sh","repo":"uv","hasSkills":true,"totalSkillsCount":7,"totalTokensCount":1915,"categories":["anthropic-skill","root-instruction","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":[".codex/skills/load-github-action-thread/SKILL.md",".codex/skills/load-github-action-thread/agents/openai.yaml","AGENTS.md","test/packages/README.md","test/packages/built-by-uv/README.md","test/packages/fake-uv/README.md","test/packages/package.name.with.dots/README.md"],"skills":{".codex/skills/load-github-action-thread/SKILL.md":"---\nname: load-github-action-thread\ndescription:\n  Download retained Codex GitHub Action thread artifacts and load their rollout history into the\n  local Codex app. Use when asked to open, load, import, resume, or inspect a Codex automation\n  thread from a GitHub Actions run or a related GitHub issue or pull request.\n---\n\n# Load GitHub Action Thread\n\nWhen given an issue instead of a run, find the related issue-triage run first. Resolve the issue\ntitle and number, then match the run display title:\n\n```bash\nrepository=astral-sh/uv\nissue=20477\nissue_title=\"$(gh issue view \"$issue\" --repo \"$repository\" --json title --jq '.title')\"\nissue_number=\"$(gh issue view \"$issue\" --repo \"$repository\" --json number --jq '.number')\"\n\ngh run list --repo \"$repository\" --workflow issue-triage.yml --limit 500 \\\n  --json databaseId,displayTitle,event,status,conclusion,createdAt,url \\\n  | jq -c --arg title \"$issue_title\" '.[] | select(.displayTitle == $title)'\n```\n\nUse the newest matching run. An issue-triage run can contain both the triage and bug-reproduction\nthreads. Also check for directly dispatched bug-reproduction runs; their display title does not\ninclude the issue title. If the issue title changed or a run was manually dispatched, list recent\ncandidates and confirm them from their logs:\n\n```bash\ngh run list --repo \"$repository\" --workflow reproduce-bug.yml --limit 100 \\\n  --json databaseId,event,status,conclusion,createdAt,url\ngh run view <run-id> --repo \"$repository\" --log | rg -m 2 \"ISSUE: $issue_number|issue: $issue_number\"\n```\n\nWhen given a pull request, find its security-review run from the pull request checks. The check link\ncontains the Actions run URL and can be passed directly to the loader:\n\n```bash\npull_request=20482\ngh pr checks \"$pull_request\" --repo \"$repository\" --json name,workflow,state,link \\\n  --jq '.[] | select(.name | test(\"review\"; \"i\"))'\n```\n\nThe security-review job only runs for eligible same-repository pull requests; a skipped review has\nno thread artifact to load.\n\nRun the repository utility with the GitHub Actions run URL:\n\n```bash\n./agents/scripts/load-github-action-thread.sh https://github.com/astral-sh/uv/actions/runs/123456789\n```\n\nThe utility downloads every matching `codex-thread-*` artifact, finds the root `codex exec` rollout\nfor each step, and forks it into an interactive local Codex thread. Subagent rollouts are ignored;\nthey inherit the root prompt and would otherwise produce duplicate-looking tasks. The first line of\nthe root preview becomes the task title, including the step, source number, and issue or pull\nrequest title. Forking is required because `codex-action` uses `codex exec`; copying an `exec`\nrollout into `~/.codex/sessions` alone does not make it visible in the Codex app.\n\nFor a numeric run ID, pass the repository when it cannot be inferred from the current checkout:\n\n```bash\n./agents/scripts/load-github-action-thread.sh 123456789 --repo astral-sh/uv\n```\n\nUse `--artifact PATTERN` to select a particular retained thread and `--cwd PATH` to attach the\nimported history to a different local checkout:\n\n```bash\n./agents/scripts/load-github-action-thread.sh 123456789 \\\n  --repo astral-sh/uv \\\n  --artifact 'codex-thread-reproduce-bug-*' \\\n  --cwd /path/to/uv\n```\n\nThe utility requires `gh`, `jq`, and `codex`, plus `zstd` for compressed rollouts. It prints the\nresolved title and a `codex://threads/<id>` link for every imported task and automatically opens the\nCodex app when exactly one task is imported on macOS. For multiple steps, return a Markdown list\nwith a clickable link labeled by the corresponding task title without repeatedly switching the app:\n\n```markdown\n- [Issue triage for #20477: Example issue](codex://threads/<id>)\n- [Bug reproduction for #20477: Example issue](codex://threads/<id>)\n```\n\nUse the matching step title for `codex-thread-pull-request-security-review-*` and\n`codex-thread-release-prepare-*`.\n",".codex/skills/load-github-action-thread/agents/openai.yaml":"interface:\n  display_name: \"Load GitHub Action Thread\"\n  short_description: \"Download and load a Codex Action thread\"\n  default_prompt: \"Use $load-github-action-thread to find and load the Codex GitHub Action threads for a run, issue, or pull request, then return links to the imported tasks.\"\n","AGENTS.md":"- Read CONTRIBUTING.md for guidelines on how to run tools\n- ALWAYS ensure that new tests use the same style as existing tests for all parts of the test\n- ALWAYS check whether the behavior of a new test is already covered by an existing test\n- DO NOT run integration test scenarios in loops or share their snapshots with\n  `insta::allow_duplicates!`. Write explicit command invocations and snapshots; use separate named\n  tests for independent scenarios\n- DO NOT repeat integration tests for every quiet level, flag alias, boolean spelling, or unrelated\n  option combination. Include a variant only when it exercises behavior specific to the change;\n  shared parsing and rendering belong in tests for their owning layer\n- PREFER explicit fixture setup and command arguments over local helpers that hide the inputs just\n  to reduce repetition. Reuse existing `uv-test` helpers for common setup, file reads, filters, and\n  cleanup\n- PREFER integration tests, e.g., at `it/...` over unit tests\n- PREFER putting integration tests in the relevant existing test module. Keep fixtures focused on\n  the behavior under test. Explain a non-obvious regression scenario in a test doc comment\n- PREFER running specific tests over running the entire test suite\n- PREFER `insta` snapshots following patterns in nearby tests over substring assertions\n- PREFER `uv_snapshot!` for command output over manual output parsing, sorting, or reconstructed\n  snapshots. Use existing context filters for nondeterminism without hiding the behavior under test\n- When making changes for Windows from Unix, use `cargo xwin clippy` to check compilation\n- NEVER perform builds with the release profile, unless asked or reproducing performance issues\n- AVOID using `panic!`, `unreachable!`, `.unwrap()`, unsafe code, and clippy rule ignores\n- PREFER patterns like `if let` to handle fallibility\n- PREFER exhaustive `match` expressions without wildcard (`_`) arms over `matches!`, so new enum\n  variants require explicit handling\n- ALWAYS write `SAFETY` comments following our usual style when writing `unsafe` code\n- PREFER `#[expect()]` over `[allow()]` if clippy must be disabled\n- PREFER let chains (`if let` combined with `&&`) over nested `if let` statements\n- NEVER update all dependencies in the lockfile and ALWAYS use `cargo update --precise` to make\n  lockfile changes\n- NEVER assume clippy warnings or test failures are pre-existing, it is very rare that `main` has\n  warnings\n- ALWAYS use `.github/automations-dispatch.json` to trigger privileged workflows from GitHub webhook\n  events instead of adding `pull_request_target` workflows\n- NEVER suppress the `dangerous-triggers` security lint; extend the automation dispatcher in a\n  separate pull request if it does not support the required event\n- PREFER top-level imports over local imports or fully qualified names\n- AVOID shortening variable names, e.g., use `version` instead of `ver`, and `requires_python`\n  instead of `rp`\n- PREFER [`TypeName`] references when writing Rust doc comments\n- DO NOT leak our conversation, prompt, or iteration history into code comments, pull request\n  descriptions, or other maintainer-facing prose. Write for readers who have not seen our\n  conversation.\n- PREFER comments that explain the current behavior and rationale. Avoid past-facing wording like\n  \"preserve the existing behavior\"; explain the actual backwards-compatibility constraint instead.\n- ALWAYS check if a new or modified test needs a `#[cfg(feature = \"test-...\")]` gate\n","test/packages/README.md":"# packages\n\nA collection of packages used to test editable installs and bespoke behaviors in packaging setups\nand definitions.\n","test/packages/built-by-uv/README.md":"# built_by_uv\n\nA package to be built with the uv build backend that uses all features exposed by the build backend.\n","test/packages/fake-uv/README.md":"This fake uv package symlinks the Python module of uv in-tree and has a fake `uv` binary, allowing\ntesting of the Python module behaviors. Consumers can replace the `uv` binary with a debug binary or\nsimilar if they need it to actually work.\n","test/packages/package.name.with.dots/README.md":"# package.name.with.dots\n\nTest package for verifying Windows executable handling with dotted package names.\n\nThis package is used to test the fix for the uvx Windows executable bug where package names\ncontaining dots were incorrectly handled when adding Windows executable extensions.\n"},"files":{".codex/skills/load-github-action-thread/SKILL.md":"---\nname: load-github-action-thread\ndescription:\n  Download retained Codex GitHub Action thread artifacts and load their rollout history into the\n  local Codex app. Use when asked to open, load, import, resume, or inspect a Codex automation\n  thread from a GitHub Actions run or a related GitHub issue or pull request.\n---\n\n# Load GitHub Action Thread\n\nWhen given an issue instead of a run, find the related issue-triage run first. Resolve the issue\ntitle and number, then match the run display title:\n\n```bash\nrepository=astral-sh/uv\nissue=20477\nissue_title=\"$(gh issue view \"$issue\" --repo \"$repository\" --json title --jq '.title')\"\nissue_number=\"$(gh issue view \"$issue\" --repo \"$repository\" --json number --jq '.number')\"\n\ngh run list --repo \"$repository\" --workflow issue-triage.yml --limit 500 \\\n  --json databaseId,displayTitle,event,status,conclusion,createdAt,url \\\n  | jq -c --arg title \"$issue_title\" '.[] | select(.displayTitle == $title)'\n```\n\nUse the newest matching run. An issue-triage run can contain both the triage and bug-reproduction\nthreads. Also check for directly dispatched bug-reproduction runs; their display title does not\ninclude the issue title. If the issue title changed or a run was manually dispatched, list recent\ncandidates and confirm them from their logs:\n\n```bash\ngh run list --repo \"$repository\" --workflow reproduce-bug.yml --limit 100 \\\n  --json databaseId,event,status,conclusion,createdAt,url\ngh run view <run-id> --repo \"$repository\" --log | rg -m 2 \"ISSUE: $issue_number|issue: $issue_number\"\n```\n\nWhen given a pull request, find its security-review run from the pull request checks. The check link\ncontains the Actions run URL and can be passed directly to the loader:\n\n```bash\npull_request=20482\ngh pr checks \"$pull_request\" --repo \"$repository\" --json name,workflow,state,link \\\n  --jq '.[] | select(.name | test(\"review\"; \"i\"))'\n```\n\nThe security-review job only runs for eligible same-repository pull requests; a skipped review has\nno thread artifact to load.\n\nRun the repository utility with the GitHub Actions run URL:\n\n```bash\n./agents/scripts/load-github-action-thread.sh https://github.com/astral-sh/uv/actions/runs/123456789\n```\n\nThe utility downloads every matching `codex-thread-*` artifact, finds the root `codex exec` rollout\nfor each step, and forks it into an interactive local Codex thread. Subagent rollouts are ignored;\nthey inherit the root prompt and would otherwise produce duplicate-looking tasks. The first line of\nthe root preview becomes the task title, including the step, source number, and issue or pull\nrequest title. Forking is required because `codex-action` uses `codex exec`; copying an `exec`\nrollout into `~/.codex/sessions` alone does not make it visible in the Codex app.\n\nFor a numeric run ID, pass the repository when it cannot be inferred from the current checkout:\n\n```bash\n./agents/scripts/load-github-action-thread.sh 123456789 --repo astral-sh/uv\n```\n\nUse `--artifact PATTERN` to select a particular retained thread and `--cwd PATH` to attach the\nimported history to a different local checkout:\n\n```bash\n./agents/scripts/load-github-action-thread.sh 123456789 \\\n  --repo astral-sh/uv \\\n  --artifact 'codex-thread-reproduce-bug-*' \\\n  --cwd /path/to/uv\n```\n\nThe utility requires `gh`, `jq`, and `codex`, plus `zstd` for compressed rollouts. It prints the\nresolved title and a `codex://threads/<id>` link for every imported task and automatically opens the\nCodex app when exactly one task is imported on macOS. For multiple steps, return a Markdown list\nwith a clickable link labeled by the corresponding task title without repeatedly switching the app:\n\n```markdown\n- [Issue triage for #20477: Example issue](codex://threads/<id>)\n- [Bug reproduction for #20477: Example issue](codex://threads/<id>)\n```\n\nUse the matching step title for `codex-thread-pull-request-security-review-*` and\n`codex-thread-release-prepare-*`.\n",".codex/skills/load-github-action-thread/agents/openai.yaml":"interface:\n  display_name: \"Load GitHub Action Thread\"\n  short_description: \"Download and load a Codex Action thread\"\n  default_prompt: \"Use $load-github-action-thread to find and load the Codex GitHub Action threads for a run, issue, or pull request, then return links to the imported tasks.\"\n","AGENTS.md":"- Read CONTRIBUTING.md for guidelines on how to run tools\n- ALWAYS ensure that new tests use the same style as existing tests for all parts of the test\n- ALWAYS check whether the behavior of a new test is already covered by an existing test\n- DO NOT run integration test scenarios in loops or share their snapshots with\n  `insta::allow_duplicates!`. Write explicit command invocations and snapshots; use separate named\n  tests for independent scenarios\n- DO NOT repeat integration tests for every quiet level, flag alias, boolean spelling, or unrelated\n  option combination. Include a variant only when it exercises behavior specific to the change;\n  shared parsing and rendering belong in tests for their owning layer\n- PREFER explicit fixture setup and command arguments over local helpers that hide the inputs just\n  to reduce repetition. Reuse existing `uv-test` helpers for common setup, file reads, filters, and\n  cleanup\n- PREFER integration tests, e.g., at `it/...` over unit tests\n- PREFER putting integration tests in the relevant existing test module. Keep fixtures focused on\n  the behavior under test. Explain a non-obvious regression scenario in a test doc comment\n- PREFER running specific tests over running the entire test suite\n- PREFER `insta` snapshots following patterns in nearby tests over substring assertions\n- PREFER `uv_snapshot!` for command output over manual output parsing, sorting, or reconstructed\n  snapshots. Use existing context filters for nondeterminism without hiding the behavior under test\n- When making changes for Windows from Unix, use `cargo xwin clippy` to check compilation\n- NEVER perform builds with the release profile, unless asked or reproducing performance issues\n- AVOID using `panic!`, `unreachable!`, `.unwrap()`, unsafe code, and clippy rule ignores\n- PREFER patterns like `if let` to handle fallibility\n- PREFER exhaustive `match` expressions without wildcard (`_`) arms over `matches!`, so new enum\n  variants require explicit handling\n- ALWAYS write `SAFETY` comments following our usual style when writing `unsafe` code\n- PREFER `#[expect()]` over `[allow()]` if clippy must be disabled\n- PREFER let chains (`if let` combined with `&&`) over nested `if let` statements\n- NEVER update all dependencies in the lockfile and ALWAYS use `cargo update --precise` to make\n  lockfile changes\n- NEVER assume clippy warnings or test failures are pre-existing, it is very rare that `main` has\n  warnings\n- ALWAYS use `.github/automations-dispatch.json` to trigger privileged workflows from GitHub webhook\n  events instead of adding `pull_request_target` workflows\n- NEVER suppress the `dangerous-triggers` security lint; extend the automation dispatcher in a\n  separate pull request if it does not support the required event\n- PREFER top-level imports over local imports or fully qualified names\n- AVOID shortening variable names, e.g., use `version` instead of `ver`, and `requires_python`\n  instead of `rp`\n- PREFER [`TypeName`] references when writing Rust doc comments\n- DO NOT leak our conversation, prompt, or iteration history into code comments, pull request\n  descriptions, or other maintainer-facing prose. Write for readers who have not seen our\n  conversation.\n- PREFER comments that explain the current behavior and rationale. Avoid past-facing wording like\n  \"preserve the existing behavior\"; explain the actual backwards-compatibility constraint instead.\n- ALWAYS check if a new or modified test needs a `#[cfg(feature = \"test-...\")]` gate\n","test/packages/README.md":"# packages\n\nA collection of packages used to test editable installs and bespoke behaviors in packaging setups\nand definitions.\n","test/packages/built-by-uv/README.md":"# built_by_uv\n\nA package to be built with the uv build backend that uses all features exposed by the build backend.\n","test/packages/fake-uv/README.md":"This fake uv package symlinks the Python module of uv in-tree and has a fake `uv` binary, allowing\ntesting of the Python module behaviors. Consumers can replace the `uv` binary with a debug binary or\nsimilar if they need it to actually work.\n","test/packages/package.name.with.dots/README.md":"# package.name.with.dots\n\nTest package for verifying Windows executable handling with dotted package names.\n\nThis package is used to test the fix for the uvx Windows executable bug where package names\ncontaining dots were incorrectly handled when adding Windows executable extensions.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/astral-sh/uv/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"- Read CONTRIBUTING.md for guidelines on how to run tools\n- ALWAYS ensure that new tests use the same style as existing tests for all parts of the test\n- ALWAYS check whether the behavior of a new test is already covered by an existing test\n- DO NOT run integration test scenarios in loops or share their snapshots with\n  `insta::allow_duplicates!`. Write explicit command invocations and snapshots; use separate named\n  tests for independent scenarios\n- DO NOT repeat integration tests for every quiet level, flag alias, boolean spelling, or unrelated\n  option combination. Include a variant only when it exercises behavior specific to the change;\n  shared parsing and rendering belong in tests for their owning layer\n- PREFER explicit fixture setup and command arguments over local helpers that hide the inputs just\n  to reduce repetition. Reuse existing `uv-test` helpers for common setup, file reads, filters, and\n  cleanup\n- PREFER integration tests, e.g., at `it/...` over unit tests\n- PREFER putting integration tests in the relevant existing test module. Keep fixtures focused on\n  the behavior under test. Explain a non-obvious regression scenario in a test doc comment\n- PREFER running specific tests over running the entire test suite\n- PREFER `insta` snapshots following patterns in nearby tests over substring assertions\n- PREFER `uv_snapshot!` for command output over manual output parsing, sorting, or reconstructed\n  snapshots. Use existing context filters for nondeterminism without hiding the behavior under test\n- When making changes for Windows from Unix, use `cargo xwin clippy` to check compilation\n- NEVER perform builds with the release profile, unless asked or reproducing performance issues\n- AVOID using `panic!`, `unreachable!`, `.unwrap()`, unsafe code, and clippy rule ignores\n- PREFER patterns like `if let` to handle fallibility\n- PREFER exhaustive `match` expressions without wildcard (`_`) arms over `matches!`, so new enum\n  variants require explicit handling\n- ALWAYS write `SAFETY` comments following our usual style when writing `unsafe` code\n- PREFER `#[expect()]` over `[allow()]` if clippy must be disabled\n- PREFER let chains (`if let` combined with `&&`) over nested `if let` statements\n- NEVER update all dependencies in the lockfile and ALWAYS use `cargo update --precise` to make\n  lockfile changes\n- NEVER assume clippy warnings or test failures are pre-existing, it is very rare that `main` has\n  warnings\n- ALWAYS use `.github/automations-dispatch.json` to trigger privileged workflows from GitHub webhook\n  events instead of adding `pull_request_target` workflows\n- NEVER suppress the `dangerous-triggers` security lint; extend the automation dispatcher in a\n  separate pull request if it does not support the required event\n- PREFER top-level imports over local imports or fully qualified names\n- AVOID shortening variable names, e.g., use `version` instead of `ver`, and `requires_python`\n  instead of `rp`\n- PREFER [`TypeName`] references when writing Rust doc comments\n- DO NOT leak our conversation, prompt, or iteration history into code comments, pull request\n  descriptions, or other maintainer-facing prose. Write for readers who have not seen our\n  conversation.\n- PREFER comments that explain the current behavior and rationale. Avoid past-facing wording like\n  \"preserve the existing behavior\"; explain the actual backwards-compatibility constraint instead.\n- ALWAYS check if a new or modified test needs a `#[cfg(feature = \"test-...\")]` gate\n","isInternal":false,"tokens":757,"sizeBytes":3505},{"name":"openai.yaml","path":".codex/skills/load-github-action-thread/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/astral-sh/uv/HEAD/.codex/skills/load-github-action-thread/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"interface:\n  display_name: \"Load GitHub Action Thread\"\n  short_description: \"Download and load a Codex Action thread\"\n  default_prompt: \"Use $load-github-action-thread to find and load the Codex GitHub Action threads for a run, issue, or pull request, then return links to the imported tasks.\"\n","isInternal":false,"tokens":66,"sizeBytes":294},{"name":"SKILL.md","path":".codex/skills/load-github-action-thread/SKILL.md","rawUrl":"https://raw.githubusercontent.com/astral-sh/uv/HEAD/.codex/skills/load-github-action-thread/SKILL.md","title":"load-github-action-thread","category":"anthropic-skill","format":"markdown","content":"---\nname: load-github-action-thread\ndescription:\n  Download retained Codex GitHub Action thread artifacts and load their rollout history into the\n  local Codex app. Use when asked to open, load, import, resume, or inspect a Codex automation\n  thread from a GitHub Actions run or a related GitHub issue or pull request.\n---\n\n# Load GitHub Action Thread\n\nWhen given an issue instead of a run, find the related issue-triage run first. Resolve the issue\ntitle and number, then match the run display title:\n\n```bash\nrepository=astral-sh/uv\nissue=20477\nissue_title=\"$(gh issue view \"$issue\" --repo \"$repository\" --json title --jq '.title')\"\nissue_number=\"$(gh issue view \"$issue\" --repo \"$repository\" --json number --jq '.number')\"\n\ngh run list --repo \"$repository\" --workflow issue-triage.yml --limit 500 \\\n  --json databaseId,displayTitle,event,status,conclusion,createdAt,url \\\n  | jq -c --arg title \"$issue_title\" '.[] | select(.displayTitle == $title)'\n```\n\nUse the newest matching run. An issue-triage run can contain both the triage and bug-reproduction\nthreads. Also check for directly dispatched bug-reproduction runs; their display title does not\ninclude the issue title. If the issue title changed or a run was manually dispatched, list recent\ncandidates and confirm them from their logs:\n\n```bash\ngh run list --repo \"$repository\" --workflow reproduce-bug.yml --limit 100 \\\n  --json databaseId,event,status,conclusion,createdAt,url\ngh run view <run-id> --repo \"$repository\" --log | rg -m 2 \"ISSUE: $issue_number|issue: $issue_number\"\n```\n\nWhen given a pull request, find its security-review run from the pull request checks. The check link\ncontains the Actions run URL and can be passed directly to the loader:\n\n```bash\npull_request=20482\ngh pr checks \"$pull_request\" --repo \"$repository\" --json name,workflow,state,link \\\n  --jq '.[] | select(.name | test(\"review\"; \"i\"))'\n```\n\nThe security-review job only runs for eligible same-repository pull requests; a skipped review has\nno thread artifact to load.\n\nRun the repository utility with the GitHub Actions run URL:\n\n```bash\n./agents/scripts/load-github-action-thread.sh https://github.com/astral-sh/uv/actions/runs/123456789\n```\n\nThe utility downloads every matching `codex-thread-*` artifact, finds the root `codex exec` rollout\nfor each step, and forks it into an interactive local Codex thread. Subagent rollouts are ignored;\nthey inherit the root prompt and would otherwise produce duplicate-looking tasks. The first line of\nthe root preview becomes the task title, including the step, source number, and issue or pull\nrequest title. Forking is required because `codex-action` uses `codex exec`; copying an `exec`\nrollout into `~/.codex/sessions` alone does not make it visible in the Codex app.\n\nFor a numeric run ID, pass the repository when it cannot be inferred from the current checkout:\n\n```bash\n./agents/scripts/load-github-action-thread.sh 123456789 --repo astral-sh/uv\n```\n\nUse `--artifact PATTERN` to select a particular retained thread and `--cwd PATH` to attach the\nimported history to a different local checkout:\n\n```bash\n./agents/scripts/load-github-action-thread.sh 123456789 \\\n  --repo astral-sh/uv \\\n  --artifact 'codex-thread-reproduce-bug-*' \\\n  --cwd /path/to/uv\n```\n\nThe utility requires `gh`, `jq`, and `codex`, plus `zstd` for compressed rollouts. It prints the\nresolved title and a `codex://threads/<id>` link for every imported task and automatically opens the\nCodex app when exactly one task is imported on macOS. For multiple steps, return a Markdown list\nwith a clickable link labeled by the corresponding task title without repeatedly switching the app:\n\n```markdown\n- [Issue triage for #20477: Example issue](codex://threads/<id>)\n- [Bug reproduction for #20477: Example issue](codex://threads/<id>)\n```\n\nUse the matching step title for `codex-thread-pull-request-security-review-*` and\n`codex-thread-release-prepare-*`.\n","frontmatter":{"name":"load-github-action-thread","description":"Download retained Codex GitHub Action thread artifacts and load their rollout history into the local Codex app. Use when asked to open, load, import, resume, or inspect a Codex automation thread from a GitHub Actions run or a related GitHub issue or pull request."},"isInternal":false,"tokens":940,"sizeBytes":3912},{"name":"README.md","path":"test/packages/built-by-uv/README.md","rawUrl":"https://raw.githubusercontent.com/astral-sh/uv/HEAD/test/packages/built-by-uv/README.md","title":"built-by-uv Documentation","category":"plugin-manifest","format":"markdown","content":"# built_by_uv\n\nA package to be built with the uv build backend that uses all features exposed by the build backend.\n","isInternal":false,"tokens":25,"sizeBytes":116},{"name":"README.md","path":"test/packages/fake-uv/README.md","rawUrl":"https://raw.githubusercontent.com/astral-sh/uv/HEAD/test/packages/fake-uv/README.md","title":"fake-uv Documentation","category":"plugin-manifest","format":"markdown","content":"This fake uv package symlinks the Python module of uv in-tree and has a fake `uv` binary, allowing\ntesting of the Python module behaviors. Consumers can replace the `uv` binary with a debug binary or\nsimilar if they need it to actually work.\n","isInternal":false,"tokens":55,"sizeBytes":242},{"name":"README.md","path":"test/packages/package.name.with.dots/README.md","rawUrl":"https://raw.githubusercontent.com/astral-sh/uv/HEAD/test/packages/package.name.with.dots/README.md","title":"package.name.with.dots Documentation","category":"plugin-manifest","format":"markdown","content":"# package.name.with.dots\n\nTest package for verifying Windows executable handling with dotted package names.\n\nThis package is used to test the fix for the uvx Windows executable bug where package names\ncontaining dots were incorrectly handled when adding Windows executable extensions.\n","isInternal":false,"tokens":50,"sizeBytes":285},{"name":"README.md","path":"test/packages/README.md","rawUrl":"https://raw.githubusercontent.com/astral-sh/uv/HEAD/test/packages/README.md","title":"packages Documentation","category":"plugin-manifest","format":"markdown","content":"# packages\n\nA collection of packages used to test editable installs and bespoke behaviors in packaging setups\nand definitions.\n","isInternal":false,"tokens":22,"sizeBytes":127}],"systemPromptSnippet":"<yakaai_skills repo=\"astral-sh/uv\">\n<!-- File: AGENTS.md (Tokens: ~757 | Category: root-instruction) -->\n- Read CONTRIBUTING.md for guidelines on how to run tools\n- ALWAYS ensure that new tests use the same style as existing tests for all parts of the test\n- ALWAYS check whether the behavior of a new test is already covered by an existing test\n- DO NOT run integration test scenarios in loops or share their snapshots with\n  `insta::allow_duplicates!`. Write explicit command invocations and snapshots; use separate named\n  tests for independent scenarios\n- DO NOT repeat integration tests for every quiet level, flag alias, boolean spelling, or unrelated\n  option combination. Include a variant only when it exercises behavior specific to the change;\n  shared parsing and rendering belong in tests for their owning layer\n- PREFER explicit fixture setup and command arguments over local helpers that hide the inputs just\n  to reduce repetition. Reuse existing `uv-test` helpers for common setup, file reads, filters, and\n  cleanup\n- PREFER integration tests, e.g., at `it/...` over unit tests\n- PREFER putting integration tests in the relevant existing test module. Keep fixtures focused on\n  the behavior under test. Explain a non-obvious regression scenario in a test doc comment\n- PREFER running specific tests over running the entire test suite\n- PREFER `insta` snapshots following patterns in nearby tests over substring assertions\n- PREFER `uv_snapshot!` for command output over manual output parsing, sorting, or reconstructed\n  snapshots. Use existing context filters for nondeterminism without hiding the behavior under test\n- When making changes for Windows from Unix, use `cargo xwin clippy` to check compilation\n- NEVER perform builds with the release profile, unless asked or reproducing performance issues\n- AVOID using `panic!`, `unreachable!`, `.unwrap()`, unsafe code, and clippy rule ignores\n- PREFER patterns like `if let` to handle fallibility\n- PREFER exhaustive `match` expressions without wildcard (`_`) arms over `matches!`, so new enum\n  variants require explicit handling\n- ALWAYS write `SAFETY` comments following our usual style when writing `unsafe` code\n- PREFER `#[expect()]` over `[allow()]` if clippy must be disabled\n- PREFER let chains (`if let` combined with `&&`) over nested `if let` statements\n- NEVER update all dependencies in the lockfile and ALWAYS use `cargo update --precise` to make\n  lockfile changes\n- NEVER assume clippy warnings or test failures are pre-existing, it is very rare that `main` has\n  warnings\n- ALWAYS use `.github/automations-dispatch.json` to trigger privileged workflows from GitHub webhook\n  events instead of adding `pull_request_target` workflows\n- NEVER suppress the `dangerous-triggers` security lint; extend the automation dispatcher in a\n  separate pull request if it does not support the required event\n- PREFER top-level imports over local imports or fully qualified names\n- AVOID shortening variable names, e.g., use `version` instead of `ver`, and `requires_python`\n  instead of `rp`\n- PREFER [`TypeName`] references when writing Rust doc comments\n- DO NOT leak our conversation, prompt, or iteration history into code comments, pull request\n  descriptions, or other maintainer-facing prose. Write for readers who have not seen our\n  conversation.\n- PREFER comments that explain the current behavior and rationale. Avoid past-facing wording like\n  \"preserve the existing behavior\"; explain the actual backwards-compatibility constraint instead.\n- ALWAYS check if a new or modified test needs a `#[cfg(feature = \"test-...\")]` gate\n\n<!-- File: .codex/skills/load-github-action-thread/agents/openai.yaml (Tokens: ~66 | Category: anthropic-skill) -->\ninterface:\n  display_name: \"Load GitHub Action Thread\"\n  short_description: \"Download and load a Codex Action thread\"\n  default_prompt: \"Use $load-github-action-thread to find and load the Codex GitHub Action threads for a run, issue, or pull request, then return links to the imported tasks.\"\n\n<!-- File: .codex/skills/load-github-action-thread/SKILL.md (Tokens: ~940 | Category: anthropic-skill) -->\n---\nname: load-github-action-thread\ndescription:\n  Download retained Codex GitHub Action thread artifacts and load their rollout history into the\n  local Codex app. Use when asked to open, load, import, resume, or inspect a Codex automation\n  thread from a GitHub Actions run or a related GitHub issue or pull request.\n---\n\n# Load GitHub Action Thread\n\nWhen given an issue instead of a run, find the related issue-triage run first. Resolve the issue\ntitle and number, then match the run display title:\n\n```bash\nrepository=astral-sh/uv\nissue=20477\nissue_title=\"$(gh issue view \"$issue\" --repo \"$repository\" --json title --jq '.title')\"\nissue_number=\"$(gh issue view \"$issue\" --repo \"$repository\" --json number --jq '.number')\"\n\ngh run list --repo \"$repository\" --workflow issue-triage.yml --limit 500 \\\n  --json databaseId,displayTitle,event,status,conclusion,createdAt,url \\\n  | jq -c --arg title \"$issue_title\" '.[] | select(.displayTitle == $title)'\n```\n\nUse the newest matching run. An issue-triage run can contain both the triage and bug-reproduction\nthreads. Also check for directly dispatched bug-reproduction runs; their display title does not\ninclude the issue title. If the issue title changed or a run was manually dispatched, list recent\ncandidates and confirm them from their logs:\n\n```bash\ngh run list --repo \"$repository\" --workflow reproduce-bug.yml --limit 100 \\\n  --json databaseId,event,status,conclusion,createdAt,url\ngh run view <run-id> --repo \"$repository\" --log | rg -m 2 \"ISSUE: $issue_number|issue: $issue_number\"\n```\n\nWhen given a pull request, find its security-review run from the pull request checks. The check link\ncontains the Actions run URL and can be passed directly to the loader:\n\n```bash\npull_request=20482\ngh pr checks \"$pull_request\" --repo \"$repository\" --json name,workflow,state,link \\\n  --jq '.[] | select(.name | test(\"review\"; \"i\"))'\n```\n\nThe security-review job only runs for eligible same-repository pull requests; a skipped review has\nno thread artifact to load.\n\nRun the repository utility with the GitHub Actions run URL:\n\n```bash\n./agents/scripts/load-github-action-thread.sh https://github.com/astral-sh/uv/actions/runs/123456789\n```\n\nThe utility downloads every matching `codex-thread-*` artifact, finds the root `codex exec` rollout\nfor each step, and forks it into an interactive local Codex thread. Subagent rollouts are ignored;\nthey inherit the root prompt and would otherwise produce duplicate-looking tasks. The first line of\nthe root preview becomes the task title, including the step, source number, and issue or pull\nrequest title. Forking is required because `codex-action` uses `codex exec`; copying an `exec`\nrollout into `~/.codex/sessions` alone does not make it visible in the Codex app.\n\nFor a numeric run ID, pass the repository when it cannot be inferred from the current checkout:\n\n```bash\n./agents/scripts/load-github-action-thread.sh 123456789 --repo astral-sh/uv\n```\n\nUse `--artifact PATTERN` to select a particular retained thread and `--cwd PATH` to attach the\nimported history to a different local checkout:\n\n```bash\n./agents/scripts/load-github-action-thread.sh 123456789 \\\n  --repo astral-sh/uv \\\n  --artifact 'codex-thread-reproduce-bug-*' \\\n  --cwd /path/to/uv\n```\n\nThe utility requires `gh`, `jq`, and `codex`, plus `zstd` for compressed rollouts. It prints the\nresolved title and a `codex://threads/<id>` link for every imported task and automatically opens the\nCodex app when exactly one task is imported on macOS. For multiple steps, return a Markdown list\nwith a clickable link labeled by the corresponding task title without repeatedly switching the app:\n\n```markdown\n- [Issue triage for #20477: Example issue](codex://threads/<id>)\n- [Bug reproduction for #20477: Example issue](codex://threads/<id>)\n```\n\nUse the matching step title for `codex-thread-pull-request-security-review-*` and\n`codex-thread-release-prepare-*`.\n\n<!-- File: test/packages/built-by-uv/README.md (Tokens: ~25 | Category: plugin-manifest) -->\n# built_by_uv\n\nA package to be built with the uv build backend that uses all features exposed by the build backend.\n\n<!-- File: test/packages/fake-uv/README.md (Tokens: ~55 | Category: plugin-manifest) -->\nThis fake uv package symlinks the Python module of uv in-tree and has a fake `uv` binary, allowing\ntesting of the Python module behaviors. Consumers can replace the `uv` binary with a debug binary or\nsimilar if they need it to actually work.\n\n<!-- File: test/packages/package.name.with.dots/README.md (Tokens: ~50 | Category: plugin-manifest) -->\n# package.name.with.dots\n\nTest package for verifying Windows executable handling with dotted package names.\n\nThis package is used to test the fix for the uvx Windows executable bug where package names\ncontaining dots were incorrectly handled when adding Windows executable extensions.\n\n<!-- File: test/packages/README.md (Tokens: ~22 | Category: plugin-manifest) -->\n# packages\n\nA collection of packages used to test editable installs and bespoke behaviors in packaging setups\nand definitions.\n</yakaai_skills>"}