{"owner":"ProvableHQ","repo":"snarkOS","hasSkills":true,"totalSkillsCount":1,"totalTokensCount":525,"categories":["root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Agent Guidelines\n\n## Formatting and Lints\n\nAlways run the following after any code modification:\n\n```bash\ncargo +nightly-2026-04-02 fmt\ncargo clippy --workspace --all-targets --all-features -- -D warnings\n```\n\nFormatting requires the nightly `.github/workflows/ci.yml` pins as `FMT_TOOLCHAIN` --\n`.rustfmt.toml` uses nightly-only options, and plain `cargo fmt` drops them\nsilently rather than refusing.\n\n## Code comments\n\nComments must describe the state of the code today -- not a previous state or an\nalternative state.\n\nException: Comments may describe an alternative possible state of the code,\n*if* they are documenting a hazard that a future developer may otherwise walk into.\n\nComments must not describe the rationale for a change.\n\n**Rationale may appear in: the commit message and the pull request.**\nYou may self-comment on your own github pull request at select positions in the code to aide reviewers.\n\nComments must help someone who has never heard of this change you are making.\n\nComments must not state the obvious. Comments that explain what attributes\ndo or how language constructs work are unhelpful.\n\n## Pull requests\n- Follow `.github/PULL_REQUEST_TEMPLATE.md`.\n- Write the PR README in Simplified Technical English. Use short sentences, the active voice, and one idea per sentence.\n- Keep the pull request description succinct and DRY.\n- Explain each commit in one line.\n\n## Modifying BFT Code\n\nWhen making changes to BFT-related code (anything under `node/bft/`), run the following checks in order:\n\n### 1. Unit tests\n\n```bash\ncargo test -p snarkos-node-bft --lib\n```\n\n### 2. Build with test features\n\nThe CI scripts invoke `snarkos` by name, so the binary must be on PATH. Build it with the\n`test_network` feature and prepend the output directory to PATH:\n\n```bash\ncargo build --features test_network\nexport PATH=\"$PWD/target/debug:$PATH\"\n```\n\n### 3. Devnet test\n\n```bash\n.ci/test_devnet.sh\n```\n\n### 4. Additional CI tests\n\nAsk the user whether they want to run the following tests before merging. These cannot run\nconcurrently and take significant time in total, so they are not always run on every change.\n\n```bash\n.ci/test_partial_upgrade.sh\n.ci/test_full_upgrade.sh\n.ci/test_restart_majority.sh\n.ci/test_reset_minority.sh\n.ci/test_restart_all.sh\n```\n"},"files":{"AGENTS.md":"# Agent Guidelines\n\n## Formatting and Lints\n\nAlways run the following after any code modification:\n\n```bash\ncargo +nightly-2026-04-02 fmt\ncargo clippy --workspace --all-targets --all-features -- -D warnings\n```\n\nFormatting requires the nightly `.github/workflows/ci.yml` pins as `FMT_TOOLCHAIN` --\n`.rustfmt.toml` uses nightly-only options, and plain `cargo fmt` drops them\nsilently rather than refusing.\n\n## Code comments\n\nComments must describe the state of the code today -- not a previous state or an\nalternative state.\n\nException: Comments may describe an alternative possible state of the code,\n*if* they are documenting a hazard that a future developer may otherwise walk into.\n\nComments must not describe the rationale for a change.\n\n**Rationale may appear in: the commit message and the pull request.**\nYou may self-comment on your own github pull request at select positions in the code to aide reviewers.\n\nComments must help someone who has never heard of this change you are making.\n\nComments must not state the obvious. Comments that explain what attributes\ndo or how language constructs work are unhelpful.\n\n## Pull requests\n- Follow `.github/PULL_REQUEST_TEMPLATE.md`.\n- Write the PR README in Simplified Technical English. Use short sentences, the active voice, and one idea per sentence.\n- Keep the pull request description succinct and DRY.\n- Explain each commit in one line.\n\n## Modifying BFT Code\n\nWhen making changes to BFT-related code (anything under `node/bft/`), run the following checks in order:\n\n### 1. Unit tests\n\n```bash\ncargo test -p snarkos-node-bft --lib\n```\n\n### 2. Build with test features\n\nThe CI scripts invoke `snarkos` by name, so the binary must be on PATH. Build it with the\n`test_network` feature and prepend the output directory to PATH:\n\n```bash\ncargo build --features test_network\nexport PATH=\"$PWD/target/debug:$PATH\"\n```\n\n### 3. Devnet test\n\n```bash\n.ci/test_devnet.sh\n```\n\n### 4. Additional CI tests\n\nAsk the user whether they want to run the following tests before merging. These cannot run\nconcurrently and take significant time in total, so they are not always run on every change.\n\n```bash\n.ci/test_partial_upgrade.sh\n.ci/test_full_upgrade.sh\n.ci/test_restart_majority.sh\n.ci/test_reset_minority.sh\n.ci/test_restart_all.sh\n```\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/ProvableHQ/snarkOS/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Agent Guidelines\n\n## Formatting and Lints\n\nAlways run the following after any code modification:\n\n```bash\ncargo +nightly-2026-04-02 fmt\ncargo clippy --workspace --all-targets --all-features -- -D warnings\n```\n\nFormatting requires the nightly `.github/workflows/ci.yml` pins as `FMT_TOOLCHAIN` --\n`.rustfmt.toml` uses nightly-only options, and plain `cargo fmt` drops them\nsilently rather than refusing.\n\n## Code comments\n\nComments must describe the state of the code today -- not a previous state or an\nalternative state.\n\nException: Comments may describe an alternative possible state of the code,\n*if* they are documenting a hazard that a future developer may otherwise walk into.\n\nComments must not describe the rationale for a change.\n\n**Rationale may appear in: the commit message and the pull request.**\nYou may self-comment on your own github pull request at select positions in the code to aide reviewers.\n\nComments must help someone who has never heard of this change you are making.\n\nComments must not state the obvious. Comments that explain what attributes\ndo or how language constructs work are unhelpful.\n\n## Pull requests\n- Follow `.github/PULL_REQUEST_TEMPLATE.md`.\n- Write the PR README in Simplified Technical English. Use short sentences, the active voice, and one idea per sentence.\n- Keep the pull request description succinct and DRY.\n- Explain each commit in one line.\n\n## Modifying BFT Code\n\nWhen making changes to BFT-related code (anything under `node/bft/`), run the following checks in order:\n\n### 1. Unit tests\n\n```bash\ncargo test -p snarkos-node-bft --lib\n```\n\n### 2. Build with test features\n\nThe CI scripts invoke `snarkos` by name, so the binary must be on PATH. Build it with the\n`test_network` feature and prepend the output directory to PATH:\n\n```bash\ncargo build --features test_network\nexport PATH=\"$PWD/target/debug:$PATH\"\n```\n\n### 3. Devnet test\n\n```bash\n.ci/test_devnet.sh\n```\n\n### 4. Additional CI tests\n\nAsk the user whether they want to run the following tests before merging. These cannot run\nconcurrently and take significant time in total, so they are not always run on every change.\n\n```bash\n.ci/test_partial_upgrade.sh\n.ci/test_full_upgrade.sh\n.ci/test_restart_majority.sh\n.ci/test_reset_minority.sh\n.ci/test_restart_all.sh\n```\n","isInternal":false,"tokens":525,"sizeBytes":2279}],"systemPromptSnippet":"<yakaai_skills repo=\"ProvableHQ/snarkOS\">\n<!-- File: AGENTS.md (Tokens: ~525 | Category: root-instruction) -->\n# Agent Guidelines\n\n## Formatting and Lints\n\nAlways run the following after any code modification:\n\n```bash\ncargo +nightly-2026-04-02 fmt\ncargo clippy --workspace --all-targets --all-features -- -D warnings\n```\n\nFormatting requires the nightly `.github/workflows/ci.yml` pins as `FMT_TOOLCHAIN` --\n`.rustfmt.toml` uses nightly-only options, and plain `cargo fmt` drops them\nsilently rather than refusing.\n\n## Code comments\n\nComments must describe the state of the code today -- not a previous state or an\nalternative state.\n\nException: Comments may describe an alternative possible state of the code,\n*if* they are documenting a hazard that a future developer may otherwise walk into.\n\nComments must not describe the rationale for a change.\n\n**Rationale may appear in: the commit message and the pull request.**\nYou may self-comment on your own github pull request at select positions in the code to aide reviewers.\n\nComments must help someone who has never heard of this change you are making.\n\nComments must not state the obvious. Comments that explain what attributes\ndo or how language constructs work are unhelpful.\n\n## Pull requests\n- Follow `.github/PULL_REQUEST_TEMPLATE.md`.\n- Write the PR README in Simplified Technical English. Use short sentences, the active voice, and one idea per sentence.\n- Keep the pull request description succinct and DRY.\n- Explain each commit in one line.\n\n## Modifying BFT Code\n\nWhen making changes to BFT-related code (anything under `node/bft/`), run the following checks in order:\n\n### 1. Unit tests\n\n```bash\ncargo test -p snarkos-node-bft --lib\n```\n\n### 2. Build with test features\n\nThe CI scripts invoke `snarkos` by name, so the binary must be on PATH. Build it with the\n`test_network` feature and prepend the output directory to PATH:\n\n```bash\ncargo build --features test_network\nexport PATH=\"$PWD/target/debug:$PATH\"\n```\n\n### 3. Devnet test\n\n```bash\n.ci/test_devnet.sh\n```\n\n### 4. Additional CI tests\n\nAsk the user whether they want to run the following tests before merging. These cannot run\nconcurrently and take significant time in total, so they are not always run on every change.\n\n```bash\n.ci/test_partial_upgrade.sh\n.ci/test_full_upgrade.sh\n.ci/test_restart_majority.sh\n.ci/test_reset_minority.sh\n.ci/test_restart_all.sh\n```\n</yakaai_skills>"}