{"owner":"valkey-io","repo":"valkey","hasSkills":true,"totalSkillsCount":3,"totalTokensCount":3615,"categories":["copilot-instructions","root-instruction","command-prompt"],"hasMcp":false,"mcpConfig":null,"found":[".github/copilot-instructions.md","AGENTS.md","src/commands/README.md"],"skills":{".github/copilot-instructions.md":"# Valkey Project Instructions\n\nYou are an expert code reviewer for the Valkey project. Provide helpful, constructive feedback on code quality, safety, and adherence to project standards.\n\n## 1. Review Tone & Focus\n- **Tone:** Be professional, direct, constructive, and empathetic.\n- **Focus:** Critique the *code*, never the *person*.\n- **Constructive:** Suggest improvements, explain *why*, provide examples.\n\n## 2. Critical Checks\n- **DCO:** **Flag missing** `Signed-off-by: Name <email>` in commits. Every commit needs it.\n- **Security:** If PR fixes a security vulnerability, flag it: \"Security fixes should be reported privately to security@lists.valkey.io, not via public PRs.\"\n\n## 3. Major Decision Detection\nFlag PRs that appear to be \"Technical Major Decisions\" requiring TSC consensus:\n- Fundamental changes to core datastructures\n- New data structures or APIs\n- Backward compatibility breaks\n- New user-visible fields requiring long-term maintenance\n- New external libraries affecting runtime behavior\n\n**Action:** Comment mentioning **@core-team** that this appears to require TSC review and ask if consensus was reached in a linked Issue.\n\n## 4. Documentation Reminder\nIf PR changes user-facing behavior (new commands, changed semantics, new config):\n- **Remind** author that docs at [valkey-doc](https://github.com/valkey-io/valkey-doc) may need updating.\n- **Suggest** linking PR to related Issue with \"Fixes #xyz\" pattern if applicable.\n\n## 5. Governance Changes\n**ANY change to `GOVERNANCE.md`** requires special attention - comment mentioning **@core-team** for review.\n","AGENTS.md":"# AGENTS.md\n\n## Scope\n- These instructions apply to the entire repository unless a deeper `AGENTS.md` overrides them.\n\n## Repo overview\n- This is the Valkey server codebase.\n- The main implementation lives under `src/`.\n- Unit tests live under `src/unit`\n- Integration tests live under `tests/`.\n- Top-level `Makefile` forwards most targets into `src/Makefile`.\n\n## Working guidelines\n- Keep changes minimal and easy to backport.\n- Match the style of the surrounding code instead of introducing new patterns.\n- Avoid unrelated refactors in the same change.\n\n## Build\n- Default build: `make`\n- Clean rebuild when build settings or bundled deps change: `make distclean && make`\n\n## Unit tests\n- Unit tests live under `src/unit/` and use GoogleTest (gtest/gmock).\n- Build and run all unit tests: `make -C src test-unit`\n- Unit tests cover data-structure and low-level logic changes.\n- A single test filter can be run with: `make -C src test-unit && ./src/unit/valkey-unit-gtests --gtest_filter='<TestSuite>.<TestName>'`\n- **Write tests in minimal C++.** GTest provides the test runner, but test code should look like C. No STL containers (`std::vector`, `std::string`, `std::set`), no STL algorithms, no `auto`, no lambdas, no templates, no RAII. Use fixed-size C arrays, `sds`, `qsort`, and explicit types. See `src/unit/README.md` for full guidelines and examples.\n\n## Integration tests\n- Integration tests live under `tests/` and are written in Tcl.\n- Run the full integration suite: `make test` (from the repo root).\n- Run a single test file: `./runtest --single <path/to/test.tcl>`\n- Additional specialized suites:\n  - Cluster tests: `./runtest-cluster`\n  - Sentinel tests: `./runtest-sentinel`\n  - Module API tests: `./runtest-moduleapi`\n- For targeted validation, run the smallest relevant test scope first before broader suites.\n\n## Code style\n- Follow the repository conventions described in `DEVELOPMENT_GUIDE.md`.\n- Most formatting is enforced by `clang-format`.\n- CI uses `clang-format-18` across `*.c`, `*.h`, `*.cpp`, and `*.hpp` files.\n- When touching C/C++ sources or headers, run `clang-format-18 -i` on the modified files before finalizing when the tool is available.\n- Use comments for non-obvious behavior and rationale, not for restating code.\n\n## Tests\n- Code changes should include relevant tests when the repo already has a matching test location.\n- Data-structure and low-level logic changes usually belong in `src/unit/` (C++ gtest).\n- End-to-end behavior changes usually belong in `tests/` (Tcl integration tests).\n- If behavior or commands change, check whether related documentation also needs updating.\n\n## Files to avoid touching unless required\n- Do not commit local runtime artifacts such as `dump.rdb`, `nodes.conf`, `*.log`, or ad hoc cluster directories unless the task explicitly requires them.\n- Treat vendored dependency code under `deps/` as special-case changes; modify it only when the task clearly requires it.\n\n## Pull Requests\nAlways push to the user's fork. Never push to the upstream valkey-io/valkey repository. Never push directly to unstable. If a user fork does not exist, ask the contributor to create one.\n","src/commands/README.md":"Command JSON files\n==================\n\nThis directory contains JSON files, one for each command.\n\nEach JSON file contains all the information about the command itself. It is the\n\"single source of truth\" (SSOT) for the command's metadata.\n\nThese JSON files were originally not intended to be used directly, since they\ncontain internals and some fields like \"acl_categories\" that are not the final\nACL categories. (Valkey will apply some implicit rules to compute the final ACL\ncategories.) However, people see JSON files and use them directly anyway.\n\nAny third party who needs access to command information were originally supposed\nto get it from `COMMAND INFO` and `COMMAND DOCS`. These commands can be combined\ninto a JSON file by the script `utils/generate-commands-json.py`. Confusingly\nenough, this JSON file as a slightly different format!\n\nStructure\n---------\n\nEach JSON file contains an object with a single key. The key is the command name\nin uppercase, e.g. \"HSCAN\" (hscan.json). The value is a JSON object with the\nfollowing keys. To be safe, assume all of them are optional.\n\n* `\"summary\"`: a string with a short description of the command. One sentence.\n* `\"complexity\"`: a string like `\"O(1)\"` or longer, like `\"O(1) for every call. O(N) for a complete iteration, including enough command calls for the cursor to return back to 0. N is the number of elements inside the collection.\"`.\n* `\"group\"`: a string used for categorization in documentation. One of these:\n  * `\"bitmap\"`\n  * `\"cluster\"`\n  * `\"connection\"`\n  * `\"generic\"`\n  * `\"geo\"`\n  * `\"hash\"`\n  * `\"hyperloglog\"`\n  * `\"list\"`\n  * `\"pubsub\"`\n  * `\"scripting\"`\n  * `\"sentinel\"`\n  * `\"server\"`\n  * `\"set\"`\n  * `\"sorted_set\"`\n  * `\"stream\"`\n  * `\"string\"`\n  * `\"transactions\"`\n* `\"since\"`: a string with a version number, like \"7.0.0\". It's the version\n  (Redis OSS or Valkey) where the command was introduced.\n* `\"arity\"`: The number of arguments, including the command name itself. A\n  negative number means \"at least\", e.g. -3 means at least 3.\n* `\"container\"`: Only present for subcommands. See below.\n* `\"history\"`: An array of changes, each change represented by a 2-element array\n  on the form `[VERSION, DESCRIPTION]`. Omit if empty. Don't add an empty array.\n* `\"function\"`: The name of the C function in Valkey's source code implementing\n  the command. (Don't use it for anything else.)\n* `\"command_flags\"`: An array of flags represented as strings. Command flags:\n  * `\"ADMIN\"`\n  * `\"ALL_DBS\"`\n  * `\"ALLOW_BUSY\"`\n  * `\"ASKING\"`\n  * `\"BLOCKING\"`\n  * `\"DENYOOM\"`\n  * `\"FAST\"`\n  * `\"LOADING\"`\n  * `\"MAY_REPLICATE\"`\n  * `\"NO_ASYNC_LOADING\"`\n  * `\"NO_AUTH\"`\n  * `\"NO_MANDATORY_KEYS\"`\n  * `\"NO_MULTI\"`\n  * `\"NOSCRIPT\"`\n  * `\"ONLY_SENTINEL\"`\n  * `\"PROTECTED\"`\n  * `\"PUBSUB\"`\n  * `\"READONLY\"`\n  * `\"SENTINEL\"`\n  * `\"SKIP_MONITOR\"`\n  * `\"SKIP_SLOWLOG\"`\n  * `\"STALE\"`\n  * `\"TOUCHES_ARBITRARY_KEYS\"`\n  * `\"WRITE\"`\n* `\"acl_categories\"`: A list of ACL categories in uppercase. Note that the\n  effective ACL categories include \"implicit ACL categories\" explained below.\n  * `\"ADMIN\"`\n  * `\"BITMAP\"`\n  * `\"CONNECTION\"`\n  * `\"DANGEROUS\"`\n  * `\"GEO\"`\n  * `\"HASH\"`\n  * `\"HYPERLOGLOG\"`\n  * `\"KEYSPACE\"`\n  * `\"LIST\"`\n  * `\"SCRIPTING\"`\n  * `\"SET\"`\n  * `\"SORTEDSET\"`\n  * `\"STREAM\"`\n  * `\"STRING\"`\n  * `\"TRANSACTION\"`\n* `\"get_dbid_args\"`: The name of the C function in Valkey's source code\n  implementing retrieval of database ID arguments from commands that accept\n  database ID as an argument.\n* `\"command_tips\"`: Optional. A list of one or more of these strings:\n  * `\"NONDETERMINISTIC_OUTPUT\"`\n  * `\"NONDETERMINISTIC_OUTPUT_ORDER\"`\n  * `\"REQUEST_POLICY:ALL_NODES\"`\n  * `\"REQUEST_POLICY:ALL_SHARDS\"`\n  * `\"REQUEST_POLICY:MULTI_SHARD\"`\n  * `\"REQUEST_POLICY:SPECIAL\"`\n  * `\"RESPONSE_POLICY:AGG_LOGICAL_AND\"`\n  * `\"RESPONSE_POLICY:AGG_MIN\"`\n  * `\"RESPONSE_POLICY:AGG_SUM\"`\n  * `\"RESPONSE_POLICY:ALL_SUCCEEDED\"`\n  * `\"RESPONSE_POLICY:ONE_SUCCEEDED\"`\n  * `\"RESPONSE_POLICY:SPECIAL\"`\n* `\"key_specs\"`: An array of key specifications. See below.\n* `\"reply_schema\"`: A [JSON Schema](https://json-schema.org/) that describes the\n  reply of the command. This isn't complete. For example, JSON Schema can't\n  distinguish arrays from sets, commands returning a set are declared to return\n  an array.\n* `\"arguments\"`: An array of arguments. Each argument is an object with the following keys:\n  * `\"name\"`: A string identifying the argument. It's unique among the arguments.\n  * `\"type\"`: The type of the argument.\n    * `\"block\"`: A group of arguments. The elements are in the key `\"arguments\"`.\n    * `\"double\"`: A number, not necessarily an integer.\n    * `\"integer\"`: An integer.\n    * `\"key\"`: A string representing a key in the database.\n    * `\"oneof\"`: One of a list of alternatives. The alternatives are in the key `\"arguments\"`.\n    * `\"pattern\"`: A string representing a glob-style pattern.\n    * `\"pure-token\"`: A fixed string. The string is in the key `\"token\"`.\n    * `\"string\"`: A string.\n    * `\"unix-time\"`: An integer representing a unix time in either seconds or milliseconds.\n  * `\"arguments\"`: A list with the same structure as its parent. Present if type is \"block\" or \"oneof\".\n  * `\"display\"`: (\"entries-read\", \"key\" or \"pattern\")\n  * `\"key_spec_index\"`: An index into the `\"key_specs\"` array. Only if `\"type\"` is `\"key\"`.\n  * `\"multiple\":` true if the argument can be repeated multiple times. Omitted means false.\n  * `\"multiple_token\"`: Unclear meaning. Maybe meaningless.\n  * `\"optional\":` True if the argument is optional. Omitted means false.\n  * `\"since\"`: Version (string) when the argument was introduced.\n  * `\"token\"`: A string indicating a fixed string value. This is always present\n    if type is \"pure-token\". If type is anything else, then `\"token\"` indicates\n    the argument is preceded by an extra (fixed string) argument.\n\nACL categories\n-----------------------\n\nThe ACL categories specified as `\"acl_categories\"` are the ones that are actually used.\n**Note:** commands categories should follow specific rules that are checked in `utils/generate-command-code.py`\n\n**ACL Category Rules:**\n* Command flag WRITE implies ACL category WRITE.\n* Command flag READONLY and not ACL category SCRIPTING implies ACL category READ.\n  \"Exclude scripting commands from the RO category.\"\n* Command flag ADMIN implies ACL categories ADMIN and DANGEROUS.\n* Command flag PUBSUB implies ACL category PUBSUB.\n* Command flag FAST implies ACL category FAST.\n* Command flag BLOCKING implies ACL category BLOCKING.\n* Not ACL category FAST implies ACL category SLOW. \"If it's not fast, it's slow.\"\n\nKey specs\n---------\n\nKey specifications are specified in the array `\"key_specs\"` key of a command.\n\nEach element in this array is an object with the following keys:\n\n* `\"flags\"`: An array of strings indicating what kind of access is the command does on the key.\n  * `\"ACCESS\"`\n  * `\"DELETE\"`\n  * `\"INCOMPLETE\"`\n  * `\"INSERT\"`\n  * `\"NOT_KEY\"`\n  * `\"OW\"`\n  * `\"RM\"`\n  * `\"RO\"`\n  * `\"RW\"`\n  * `\"UPDATE\"`\n  * `\"VARIABLE_FLAGS\"`\n* `\"begin_search\"`: How to find the first key used by this key spec. It's an\n  object with only one key. The key determines the method for finding the first\n  key. Here are the possible forms of the `\"begin_search\"` object:\n  * `{\"index\": {\"pos\": N}}`: The first key is at position N in the command line,\n    where 0 is the command name.\n  * `{\"keyword\": KEYWORD, \"startfrom\": N}`: The first key is found by searching\n    for an argument with the exact value KEYWORD starting from index N in the\n    command line. The first key is the argument after the keyword.\n  * `{\"unknown\": null}`: Finding the keys of this command is too complicated to\n    explain.\n* `\"find_keys\"`: How to find the remaining keys of this key spec. It's an object\n  on one of these forms:\n  * `{\"range\": {\"lastkey\": LAST, \"step\": STEP, \"limit\": LIMIT}}`: A range of keys.\n    * LAST: If LAST is positive, it's the index of the last key relative to the\n      first key. If last is negative, then -1 is the end of the whole command\n      line, -2 is the penultimate argument of the command, and so on.\n    * STEP: The number of arguments to skip to find the next one. Typically 1.\n    * LIMIT: If LAST is -1, we use the limit to stop the search by a factor. 0\n      and 1 mean no limit. 2 means half of the remaining arguments, 3 means a\n      third, and so on.\n\nCommands with subcommands\n-------------------------\n\nCommands with subcommands are special. Examples of commands with subcommands are\n`CLUSTER` and `ACL`. Their first argument is a subcommand which determines the\nsyntax of the rest the command, which is stored in its own JSON file.\n\nFor example `CLUSTER INFO` is stored in a file called `cluster-info.json`. The\ntoplevel key is called `\"INFO\"`. Within the body, there's a key called\n`\"container\"` with the value `\"CLUSTER\"`. The file `cluster.json` exists by it\ndoesn't have an `\"arguments\"` key.\n\nAppendix\n--------\n\nHow to list all the `group`, `command_flags` and `acl_categories`, etc. used in all these files:\n\n    cat *.json | jq '.[].group'             | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].command_flags'     | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].acl_categories'    | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].arguments[]?.type' | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n"},"files":{".github/copilot-instructions.md":"# Valkey Project Instructions\n\nYou are an expert code reviewer for the Valkey project. Provide helpful, constructive feedback on code quality, safety, and adherence to project standards.\n\n## 1. Review Tone & Focus\n- **Tone:** Be professional, direct, constructive, and empathetic.\n- **Focus:** Critique the *code*, never the *person*.\n- **Constructive:** Suggest improvements, explain *why*, provide examples.\n\n## 2. Critical Checks\n- **DCO:** **Flag missing** `Signed-off-by: Name <email>` in commits. Every commit needs it.\n- **Security:** If PR fixes a security vulnerability, flag it: \"Security fixes should be reported privately to security@lists.valkey.io, not via public PRs.\"\n\n## 3. Major Decision Detection\nFlag PRs that appear to be \"Technical Major Decisions\" requiring TSC consensus:\n- Fundamental changes to core datastructures\n- New data structures or APIs\n- Backward compatibility breaks\n- New user-visible fields requiring long-term maintenance\n- New external libraries affecting runtime behavior\n\n**Action:** Comment mentioning **@core-team** that this appears to require TSC review and ask if consensus was reached in a linked Issue.\n\n## 4. Documentation Reminder\nIf PR changes user-facing behavior (new commands, changed semantics, new config):\n- **Remind** author that docs at [valkey-doc](https://github.com/valkey-io/valkey-doc) may need updating.\n- **Suggest** linking PR to related Issue with \"Fixes #xyz\" pattern if applicable.\n\n## 5. Governance Changes\n**ANY change to `GOVERNANCE.md`** requires special attention - comment mentioning **@core-team** for review.\n","AGENTS.md":"# AGENTS.md\n\n## Scope\n- These instructions apply to the entire repository unless a deeper `AGENTS.md` overrides them.\n\n## Repo overview\n- This is the Valkey server codebase.\n- The main implementation lives under `src/`.\n- Unit tests live under `src/unit`\n- Integration tests live under `tests/`.\n- Top-level `Makefile` forwards most targets into `src/Makefile`.\n\n## Working guidelines\n- Keep changes minimal and easy to backport.\n- Match the style of the surrounding code instead of introducing new patterns.\n- Avoid unrelated refactors in the same change.\n\n## Build\n- Default build: `make`\n- Clean rebuild when build settings or bundled deps change: `make distclean && make`\n\n## Unit tests\n- Unit tests live under `src/unit/` and use GoogleTest (gtest/gmock).\n- Build and run all unit tests: `make -C src test-unit`\n- Unit tests cover data-structure and low-level logic changes.\n- A single test filter can be run with: `make -C src test-unit && ./src/unit/valkey-unit-gtests --gtest_filter='<TestSuite>.<TestName>'`\n- **Write tests in minimal C++.** GTest provides the test runner, but test code should look like C. No STL containers (`std::vector`, `std::string`, `std::set`), no STL algorithms, no `auto`, no lambdas, no templates, no RAII. Use fixed-size C arrays, `sds`, `qsort`, and explicit types. See `src/unit/README.md` for full guidelines and examples.\n\n## Integration tests\n- Integration tests live under `tests/` and are written in Tcl.\n- Run the full integration suite: `make test` (from the repo root).\n- Run a single test file: `./runtest --single <path/to/test.tcl>`\n- Additional specialized suites:\n  - Cluster tests: `./runtest-cluster`\n  - Sentinel tests: `./runtest-sentinel`\n  - Module API tests: `./runtest-moduleapi`\n- For targeted validation, run the smallest relevant test scope first before broader suites.\n\n## Code style\n- Follow the repository conventions described in `DEVELOPMENT_GUIDE.md`.\n- Most formatting is enforced by `clang-format`.\n- CI uses `clang-format-18` across `*.c`, `*.h`, `*.cpp`, and `*.hpp` files.\n- When touching C/C++ sources or headers, run `clang-format-18 -i` on the modified files before finalizing when the tool is available.\n- Use comments for non-obvious behavior and rationale, not for restating code.\n\n## Tests\n- Code changes should include relevant tests when the repo already has a matching test location.\n- Data-structure and low-level logic changes usually belong in `src/unit/` (C++ gtest).\n- End-to-end behavior changes usually belong in `tests/` (Tcl integration tests).\n- If behavior or commands change, check whether related documentation also needs updating.\n\n## Files to avoid touching unless required\n- Do not commit local runtime artifacts such as `dump.rdb`, `nodes.conf`, `*.log`, or ad hoc cluster directories unless the task explicitly requires them.\n- Treat vendored dependency code under `deps/` as special-case changes; modify it only when the task clearly requires it.\n\n## Pull Requests\nAlways push to the user's fork. Never push to the upstream valkey-io/valkey repository. Never push directly to unstable. If a user fork does not exist, ask the contributor to create one.\n","src/commands/README.md":"Command JSON files\n==================\n\nThis directory contains JSON files, one for each command.\n\nEach JSON file contains all the information about the command itself. It is the\n\"single source of truth\" (SSOT) for the command's metadata.\n\nThese JSON files were originally not intended to be used directly, since they\ncontain internals and some fields like \"acl_categories\" that are not the final\nACL categories. (Valkey will apply some implicit rules to compute the final ACL\ncategories.) However, people see JSON files and use them directly anyway.\n\nAny third party who needs access to command information were originally supposed\nto get it from `COMMAND INFO` and `COMMAND DOCS`. These commands can be combined\ninto a JSON file by the script `utils/generate-commands-json.py`. Confusingly\nenough, this JSON file as a slightly different format!\n\nStructure\n---------\n\nEach JSON file contains an object with a single key. The key is the command name\nin uppercase, e.g. \"HSCAN\" (hscan.json). The value is a JSON object with the\nfollowing keys. To be safe, assume all of them are optional.\n\n* `\"summary\"`: a string with a short description of the command. One sentence.\n* `\"complexity\"`: a string like `\"O(1)\"` or longer, like `\"O(1) for every call. O(N) for a complete iteration, including enough command calls for the cursor to return back to 0. N is the number of elements inside the collection.\"`.\n* `\"group\"`: a string used for categorization in documentation. One of these:\n  * `\"bitmap\"`\n  * `\"cluster\"`\n  * `\"connection\"`\n  * `\"generic\"`\n  * `\"geo\"`\n  * `\"hash\"`\n  * `\"hyperloglog\"`\n  * `\"list\"`\n  * `\"pubsub\"`\n  * `\"scripting\"`\n  * `\"sentinel\"`\n  * `\"server\"`\n  * `\"set\"`\n  * `\"sorted_set\"`\n  * `\"stream\"`\n  * `\"string\"`\n  * `\"transactions\"`\n* `\"since\"`: a string with a version number, like \"7.0.0\". It's the version\n  (Redis OSS or Valkey) where the command was introduced.\n* `\"arity\"`: The number of arguments, including the command name itself. A\n  negative number means \"at least\", e.g. -3 means at least 3.\n* `\"container\"`: Only present for subcommands. See below.\n* `\"history\"`: An array of changes, each change represented by a 2-element array\n  on the form `[VERSION, DESCRIPTION]`. Omit if empty. Don't add an empty array.\n* `\"function\"`: The name of the C function in Valkey's source code implementing\n  the command. (Don't use it for anything else.)\n* `\"command_flags\"`: An array of flags represented as strings. Command flags:\n  * `\"ADMIN\"`\n  * `\"ALL_DBS\"`\n  * `\"ALLOW_BUSY\"`\n  * `\"ASKING\"`\n  * `\"BLOCKING\"`\n  * `\"DENYOOM\"`\n  * `\"FAST\"`\n  * `\"LOADING\"`\n  * `\"MAY_REPLICATE\"`\n  * `\"NO_ASYNC_LOADING\"`\n  * `\"NO_AUTH\"`\n  * `\"NO_MANDATORY_KEYS\"`\n  * `\"NO_MULTI\"`\n  * `\"NOSCRIPT\"`\n  * `\"ONLY_SENTINEL\"`\n  * `\"PROTECTED\"`\n  * `\"PUBSUB\"`\n  * `\"READONLY\"`\n  * `\"SENTINEL\"`\n  * `\"SKIP_MONITOR\"`\n  * `\"SKIP_SLOWLOG\"`\n  * `\"STALE\"`\n  * `\"TOUCHES_ARBITRARY_KEYS\"`\n  * `\"WRITE\"`\n* `\"acl_categories\"`: A list of ACL categories in uppercase. Note that the\n  effective ACL categories include \"implicit ACL categories\" explained below.\n  * `\"ADMIN\"`\n  * `\"BITMAP\"`\n  * `\"CONNECTION\"`\n  * `\"DANGEROUS\"`\n  * `\"GEO\"`\n  * `\"HASH\"`\n  * `\"HYPERLOGLOG\"`\n  * `\"KEYSPACE\"`\n  * `\"LIST\"`\n  * `\"SCRIPTING\"`\n  * `\"SET\"`\n  * `\"SORTEDSET\"`\n  * `\"STREAM\"`\n  * `\"STRING\"`\n  * `\"TRANSACTION\"`\n* `\"get_dbid_args\"`: The name of the C function in Valkey's source code\n  implementing retrieval of database ID arguments from commands that accept\n  database ID as an argument.\n* `\"command_tips\"`: Optional. A list of one or more of these strings:\n  * `\"NONDETERMINISTIC_OUTPUT\"`\n  * `\"NONDETERMINISTIC_OUTPUT_ORDER\"`\n  * `\"REQUEST_POLICY:ALL_NODES\"`\n  * `\"REQUEST_POLICY:ALL_SHARDS\"`\n  * `\"REQUEST_POLICY:MULTI_SHARD\"`\n  * `\"REQUEST_POLICY:SPECIAL\"`\n  * `\"RESPONSE_POLICY:AGG_LOGICAL_AND\"`\n  * `\"RESPONSE_POLICY:AGG_MIN\"`\n  * `\"RESPONSE_POLICY:AGG_SUM\"`\n  * `\"RESPONSE_POLICY:ALL_SUCCEEDED\"`\n  * `\"RESPONSE_POLICY:ONE_SUCCEEDED\"`\n  * `\"RESPONSE_POLICY:SPECIAL\"`\n* `\"key_specs\"`: An array of key specifications. See below.\n* `\"reply_schema\"`: A [JSON Schema](https://json-schema.org/) that describes the\n  reply of the command. This isn't complete. For example, JSON Schema can't\n  distinguish arrays from sets, commands returning a set are declared to return\n  an array.\n* `\"arguments\"`: An array of arguments. Each argument is an object with the following keys:\n  * `\"name\"`: A string identifying the argument. It's unique among the arguments.\n  * `\"type\"`: The type of the argument.\n    * `\"block\"`: A group of arguments. The elements are in the key `\"arguments\"`.\n    * `\"double\"`: A number, not necessarily an integer.\n    * `\"integer\"`: An integer.\n    * `\"key\"`: A string representing a key in the database.\n    * `\"oneof\"`: One of a list of alternatives. The alternatives are in the key `\"arguments\"`.\n    * `\"pattern\"`: A string representing a glob-style pattern.\n    * `\"pure-token\"`: A fixed string. The string is in the key `\"token\"`.\n    * `\"string\"`: A string.\n    * `\"unix-time\"`: An integer representing a unix time in either seconds or milliseconds.\n  * `\"arguments\"`: A list with the same structure as its parent. Present if type is \"block\" or \"oneof\".\n  * `\"display\"`: (\"entries-read\", \"key\" or \"pattern\")\n  * `\"key_spec_index\"`: An index into the `\"key_specs\"` array. Only if `\"type\"` is `\"key\"`.\n  * `\"multiple\":` true if the argument can be repeated multiple times. Omitted means false.\n  * `\"multiple_token\"`: Unclear meaning. Maybe meaningless.\n  * `\"optional\":` True if the argument is optional. Omitted means false.\n  * `\"since\"`: Version (string) when the argument was introduced.\n  * `\"token\"`: A string indicating a fixed string value. This is always present\n    if type is \"pure-token\". If type is anything else, then `\"token\"` indicates\n    the argument is preceded by an extra (fixed string) argument.\n\nACL categories\n-----------------------\n\nThe ACL categories specified as `\"acl_categories\"` are the ones that are actually used.\n**Note:** commands categories should follow specific rules that are checked in `utils/generate-command-code.py`\n\n**ACL Category Rules:**\n* Command flag WRITE implies ACL category WRITE.\n* Command flag READONLY and not ACL category SCRIPTING implies ACL category READ.\n  \"Exclude scripting commands from the RO category.\"\n* Command flag ADMIN implies ACL categories ADMIN and DANGEROUS.\n* Command flag PUBSUB implies ACL category PUBSUB.\n* Command flag FAST implies ACL category FAST.\n* Command flag BLOCKING implies ACL category BLOCKING.\n* Not ACL category FAST implies ACL category SLOW. \"If it's not fast, it's slow.\"\n\nKey specs\n---------\n\nKey specifications are specified in the array `\"key_specs\"` key of a command.\n\nEach element in this array is an object with the following keys:\n\n* `\"flags\"`: An array of strings indicating what kind of access is the command does on the key.\n  * `\"ACCESS\"`\n  * `\"DELETE\"`\n  * `\"INCOMPLETE\"`\n  * `\"INSERT\"`\n  * `\"NOT_KEY\"`\n  * `\"OW\"`\n  * `\"RM\"`\n  * `\"RO\"`\n  * `\"RW\"`\n  * `\"UPDATE\"`\n  * `\"VARIABLE_FLAGS\"`\n* `\"begin_search\"`: How to find the first key used by this key spec. It's an\n  object with only one key. The key determines the method for finding the first\n  key. Here are the possible forms of the `\"begin_search\"` object:\n  * `{\"index\": {\"pos\": N}}`: The first key is at position N in the command line,\n    where 0 is the command name.\n  * `{\"keyword\": KEYWORD, \"startfrom\": N}`: The first key is found by searching\n    for an argument with the exact value KEYWORD starting from index N in the\n    command line. The first key is the argument after the keyword.\n  * `{\"unknown\": null}`: Finding the keys of this command is too complicated to\n    explain.\n* `\"find_keys\"`: How to find the remaining keys of this key spec. It's an object\n  on one of these forms:\n  * `{\"range\": {\"lastkey\": LAST, \"step\": STEP, \"limit\": LIMIT}}`: A range of keys.\n    * LAST: If LAST is positive, it's the index of the last key relative to the\n      first key. If last is negative, then -1 is the end of the whole command\n      line, -2 is the penultimate argument of the command, and so on.\n    * STEP: The number of arguments to skip to find the next one. Typically 1.\n    * LIMIT: If LAST is -1, we use the limit to stop the search by a factor. 0\n      and 1 mean no limit. 2 means half of the remaining arguments, 3 means a\n      third, and so on.\n\nCommands with subcommands\n-------------------------\n\nCommands with subcommands are special. Examples of commands with subcommands are\n`CLUSTER` and `ACL`. Their first argument is a subcommand which determines the\nsyntax of the rest the command, which is stored in its own JSON file.\n\nFor example `CLUSTER INFO` is stored in a file called `cluster-info.json`. The\ntoplevel key is called `\"INFO\"`. Within the body, there's a key called\n`\"container\"` with the value `\"CLUSTER\"`. The file `cluster.json` exists by it\ndoesn't have an `\"arguments\"` key.\n\nAppendix\n--------\n\nHow to list all the `group`, `command_flags` and `acl_categories`, etc. used in all these files:\n\n    cat *.json | jq '.[].group'             | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].command_flags'     | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].acl_categories'    | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].arguments[]?.type' | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/valkey-io/valkey/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\n## Scope\n- These instructions apply to the entire repository unless a deeper `AGENTS.md` overrides them.\n\n## Repo overview\n- This is the Valkey server codebase.\n- The main implementation lives under `src/`.\n- Unit tests live under `src/unit`\n- Integration tests live under `tests/`.\n- Top-level `Makefile` forwards most targets into `src/Makefile`.\n\n## Working guidelines\n- Keep changes minimal and easy to backport.\n- Match the style of the surrounding code instead of introducing new patterns.\n- Avoid unrelated refactors in the same change.\n\n## Build\n- Default build: `make`\n- Clean rebuild when build settings or bundled deps change: `make distclean && make`\n\n## Unit tests\n- Unit tests live under `src/unit/` and use GoogleTest (gtest/gmock).\n- Build and run all unit tests: `make -C src test-unit`\n- Unit tests cover data-structure and low-level logic changes.\n- A single test filter can be run with: `make -C src test-unit && ./src/unit/valkey-unit-gtests --gtest_filter='<TestSuite>.<TestName>'`\n- **Write tests in minimal C++.** GTest provides the test runner, but test code should look like C. No STL containers (`std::vector`, `std::string`, `std::set`), no STL algorithms, no `auto`, no lambdas, no templates, no RAII. Use fixed-size C arrays, `sds`, `qsort`, and explicit types. See `src/unit/README.md` for full guidelines and examples.\n\n## Integration tests\n- Integration tests live under `tests/` and are written in Tcl.\n- Run the full integration suite: `make test` (from the repo root).\n- Run a single test file: `./runtest --single <path/to/test.tcl>`\n- Additional specialized suites:\n  - Cluster tests: `./runtest-cluster`\n  - Sentinel tests: `./runtest-sentinel`\n  - Module API tests: `./runtest-moduleapi`\n- For targeted validation, run the smallest relevant test scope first before broader suites.\n\n## Code style\n- Follow the repository conventions described in `DEVELOPMENT_GUIDE.md`.\n- Most formatting is enforced by `clang-format`.\n- CI uses `clang-format-18` across `*.c`, `*.h`, `*.cpp`, and `*.hpp` files.\n- When touching C/C++ sources or headers, run `clang-format-18 -i` on the modified files before finalizing when the tool is available.\n- Use comments for non-obvious behavior and rationale, not for restating code.\n\n## Tests\n- Code changes should include relevant tests when the repo already has a matching test location.\n- Data-structure and low-level logic changes usually belong in `src/unit/` (C++ gtest).\n- End-to-end behavior changes usually belong in `tests/` (Tcl integration tests).\n- If behavior or commands change, check whether related documentation also needs updating.\n\n## Files to avoid touching unless required\n- Do not commit local runtime artifacts such as `dump.rdb`, `nodes.conf`, `*.log`, or ad hoc cluster directories unless the task explicitly requires them.\n- Treat vendored dependency code under `deps/` as special-case changes; modify it only when the task clearly requires it.\n\n## Pull Requests\nAlways push to the user's fork. Never push to the upstream valkey-io/valkey repository. Never push directly to unstable. If a user fork does not exist, ask the contributor to create one.\n","isInternal":false,"tokens":749,"sizeBytes":3156},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/valkey-io/valkey/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# Valkey Project Instructions\n\nYou are an expert code reviewer for the Valkey project. Provide helpful, constructive feedback on code quality, safety, and adherence to project standards.\n\n## 1. Review Tone & Focus\n- **Tone:** Be professional, direct, constructive, and empathetic.\n- **Focus:** Critique the *code*, never the *person*.\n- **Constructive:** Suggest improvements, explain *why*, provide examples.\n\n## 2. Critical Checks\n- **DCO:** **Flag missing** `Signed-off-by: Name <email>` in commits. Every commit needs it.\n- **Security:** If PR fixes a security vulnerability, flag it: \"Security fixes should be reported privately to security@lists.valkey.io, not via public PRs.\"\n\n## 3. Major Decision Detection\nFlag PRs that appear to be \"Technical Major Decisions\" requiring TSC consensus:\n- Fundamental changes to core datastructures\n- New data structures or APIs\n- Backward compatibility breaks\n- New user-visible fields requiring long-term maintenance\n- New external libraries affecting runtime behavior\n\n**Action:** Comment mentioning **@core-team** that this appears to require TSC review and ask if consensus was reached in a linked Issue.\n\n## 4. Documentation Reminder\nIf PR changes user-facing behavior (new commands, changed semantics, new config):\n- **Remind** author that docs at [valkey-doc](https://github.com/valkey-io/valkey-doc) may need updating.\n- **Suggest** linking PR to related Issue with \"Fixes #xyz\" pattern if applicable.\n\n## 5. Governance Changes\n**ANY change to `GOVERNANCE.md`** requires special attention - comment mentioning **@core-team** for review.\n","isInternal":false,"tokens":361,"sizeBytes":1588},{"name":"README.md","path":"src/commands/README.md","rawUrl":"https://raw.githubusercontent.com/valkey-io/valkey/HEAD/src/commands/README.md","title":"Command: /readme","category":"command-prompt","format":"markdown","content":"Command JSON files\n==================\n\nThis directory contains JSON files, one for each command.\n\nEach JSON file contains all the information about the command itself. It is the\n\"single source of truth\" (SSOT) for the command's metadata.\n\nThese JSON files were originally not intended to be used directly, since they\ncontain internals and some fields like \"acl_categories\" that are not the final\nACL categories. (Valkey will apply some implicit rules to compute the final ACL\ncategories.) However, people see JSON files and use them directly anyway.\n\nAny third party who needs access to command information were originally supposed\nto get it from `COMMAND INFO` and `COMMAND DOCS`. These commands can be combined\ninto a JSON file by the script `utils/generate-commands-json.py`. Confusingly\nenough, this JSON file as a slightly different format!\n\nStructure\n---------\n\nEach JSON file contains an object with a single key. The key is the command name\nin uppercase, e.g. \"HSCAN\" (hscan.json). The value is a JSON object with the\nfollowing keys. To be safe, assume all of them are optional.\n\n* `\"summary\"`: a string with a short description of the command. One sentence.\n* `\"complexity\"`: a string like `\"O(1)\"` or longer, like `\"O(1) for every call. O(N) for a complete iteration, including enough command calls for the cursor to return back to 0. N is the number of elements inside the collection.\"`.\n* `\"group\"`: a string used for categorization in documentation. One of these:\n  * `\"bitmap\"`\n  * `\"cluster\"`\n  * `\"connection\"`\n  * `\"generic\"`\n  * `\"geo\"`\n  * `\"hash\"`\n  * `\"hyperloglog\"`\n  * `\"list\"`\n  * `\"pubsub\"`\n  * `\"scripting\"`\n  * `\"sentinel\"`\n  * `\"server\"`\n  * `\"set\"`\n  * `\"sorted_set\"`\n  * `\"stream\"`\n  * `\"string\"`\n  * `\"transactions\"`\n* `\"since\"`: a string with a version number, like \"7.0.0\". It's the version\n  (Redis OSS or Valkey) where the command was introduced.\n* `\"arity\"`: The number of arguments, including the command name itself. A\n  negative number means \"at least\", e.g. -3 means at least 3.\n* `\"container\"`: Only present for subcommands. See below.\n* `\"history\"`: An array of changes, each change represented by a 2-element array\n  on the form `[VERSION, DESCRIPTION]`. Omit if empty. Don't add an empty array.\n* `\"function\"`: The name of the C function in Valkey's source code implementing\n  the command. (Don't use it for anything else.)\n* `\"command_flags\"`: An array of flags represented as strings. Command flags:\n  * `\"ADMIN\"`\n  * `\"ALL_DBS\"`\n  * `\"ALLOW_BUSY\"`\n  * `\"ASKING\"`\n  * `\"BLOCKING\"`\n  * `\"DENYOOM\"`\n  * `\"FAST\"`\n  * `\"LOADING\"`\n  * `\"MAY_REPLICATE\"`\n  * `\"NO_ASYNC_LOADING\"`\n  * `\"NO_AUTH\"`\n  * `\"NO_MANDATORY_KEYS\"`\n  * `\"NO_MULTI\"`\n  * `\"NOSCRIPT\"`\n  * `\"ONLY_SENTINEL\"`\n  * `\"PROTECTED\"`\n  * `\"PUBSUB\"`\n  * `\"READONLY\"`\n  * `\"SENTINEL\"`\n  * `\"SKIP_MONITOR\"`\n  * `\"SKIP_SLOWLOG\"`\n  * `\"STALE\"`\n  * `\"TOUCHES_ARBITRARY_KEYS\"`\n  * `\"WRITE\"`\n* `\"acl_categories\"`: A list of ACL categories in uppercase. Note that the\n  effective ACL categories include \"implicit ACL categories\" explained below.\n  * `\"ADMIN\"`\n  * `\"BITMAP\"`\n  * `\"CONNECTION\"`\n  * `\"DANGEROUS\"`\n  * `\"GEO\"`\n  * `\"HASH\"`\n  * `\"HYPERLOGLOG\"`\n  * `\"KEYSPACE\"`\n  * `\"LIST\"`\n  * `\"SCRIPTING\"`\n  * `\"SET\"`\n  * `\"SORTEDSET\"`\n  * `\"STREAM\"`\n  * `\"STRING\"`\n  * `\"TRANSACTION\"`\n* `\"get_dbid_args\"`: The name of the C function in Valkey's source code\n  implementing retrieval of database ID arguments from commands that accept\n  database ID as an argument.\n* `\"command_tips\"`: Optional. A list of one or more of these strings:\n  * `\"NONDETERMINISTIC_OUTPUT\"`\n  * `\"NONDETERMINISTIC_OUTPUT_ORDER\"`\n  * `\"REQUEST_POLICY:ALL_NODES\"`\n  * `\"REQUEST_POLICY:ALL_SHARDS\"`\n  * `\"REQUEST_POLICY:MULTI_SHARD\"`\n  * `\"REQUEST_POLICY:SPECIAL\"`\n  * `\"RESPONSE_POLICY:AGG_LOGICAL_AND\"`\n  * `\"RESPONSE_POLICY:AGG_MIN\"`\n  * `\"RESPONSE_POLICY:AGG_SUM\"`\n  * `\"RESPONSE_POLICY:ALL_SUCCEEDED\"`\n  * `\"RESPONSE_POLICY:ONE_SUCCEEDED\"`\n  * `\"RESPONSE_POLICY:SPECIAL\"`\n* `\"key_specs\"`: An array of key specifications. See below.\n* `\"reply_schema\"`: A [JSON Schema](https://json-schema.org/) that describes the\n  reply of the command. This isn't complete. For example, JSON Schema can't\n  distinguish arrays from sets, commands returning a set are declared to return\n  an array.\n* `\"arguments\"`: An array of arguments. Each argument is an object with the following keys:\n  * `\"name\"`: A string identifying the argument. It's unique among the arguments.\n  * `\"type\"`: The type of the argument.\n    * `\"block\"`: A group of arguments. The elements are in the key `\"arguments\"`.\n    * `\"double\"`: A number, not necessarily an integer.\n    * `\"integer\"`: An integer.\n    * `\"key\"`: A string representing a key in the database.\n    * `\"oneof\"`: One of a list of alternatives. The alternatives are in the key `\"arguments\"`.\n    * `\"pattern\"`: A string representing a glob-style pattern.\n    * `\"pure-token\"`: A fixed string. The string is in the key `\"token\"`.\n    * `\"string\"`: A string.\n    * `\"unix-time\"`: An integer representing a unix time in either seconds or milliseconds.\n  * `\"arguments\"`: A list with the same structure as its parent. Present if type is \"block\" or \"oneof\".\n  * `\"display\"`: (\"entries-read\", \"key\" or \"pattern\")\n  * `\"key_spec_index\"`: An index into the `\"key_specs\"` array. Only if `\"type\"` is `\"key\"`.\n  * `\"multiple\":` true if the argument can be repeated multiple times. Omitted means false.\n  * `\"multiple_token\"`: Unclear meaning. Maybe meaningless.\n  * `\"optional\":` True if the argument is optional. Omitted means false.\n  * `\"since\"`: Version (string) when the argument was introduced.\n  * `\"token\"`: A string indicating a fixed string value. This is always present\n    if type is \"pure-token\". If type is anything else, then `\"token\"` indicates\n    the argument is preceded by an extra (fixed string) argument.\n\nACL categories\n-----------------------\n\nThe ACL categories specified as `\"acl_categories\"` are the ones that are actually used.\n**Note:** commands categories should follow specific rules that are checked in `utils/generate-command-code.py`\n\n**ACL Category Rules:**\n* Command flag WRITE implies ACL category WRITE.\n* Command flag READONLY and not ACL category SCRIPTING implies ACL category READ.\n  \"Exclude scripting commands from the RO category.\"\n* Command flag ADMIN implies ACL categories ADMIN and DANGEROUS.\n* Command flag PUBSUB implies ACL category PUBSUB.\n* Command flag FAST implies ACL category FAST.\n* Command flag BLOCKING implies ACL category BLOCKING.\n* Not ACL category FAST implies ACL category SLOW. \"If it's not fast, it's slow.\"\n\nKey specs\n---------\n\nKey specifications are specified in the array `\"key_specs\"` key of a command.\n\nEach element in this array is an object with the following keys:\n\n* `\"flags\"`: An array of strings indicating what kind of access is the command does on the key.\n  * `\"ACCESS\"`\n  * `\"DELETE\"`\n  * `\"INCOMPLETE\"`\n  * `\"INSERT\"`\n  * `\"NOT_KEY\"`\n  * `\"OW\"`\n  * `\"RM\"`\n  * `\"RO\"`\n  * `\"RW\"`\n  * `\"UPDATE\"`\n  * `\"VARIABLE_FLAGS\"`\n* `\"begin_search\"`: How to find the first key used by this key spec. It's an\n  object with only one key. The key determines the method for finding the first\n  key. Here are the possible forms of the `\"begin_search\"` object:\n  * `{\"index\": {\"pos\": N}}`: The first key is at position N in the command line,\n    where 0 is the command name.\n  * `{\"keyword\": KEYWORD, \"startfrom\": N}`: The first key is found by searching\n    for an argument with the exact value KEYWORD starting from index N in the\n    command line. The first key is the argument after the keyword.\n  * `{\"unknown\": null}`: Finding the keys of this command is too complicated to\n    explain.\n* `\"find_keys\"`: How to find the remaining keys of this key spec. It's an object\n  on one of these forms:\n  * `{\"range\": {\"lastkey\": LAST, \"step\": STEP, \"limit\": LIMIT}}`: A range of keys.\n    * LAST: If LAST is positive, it's the index of the last key relative to the\n      first key. If last is negative, then -1 is the end of the whole command\n      line, -2 is the penultimate argument of the command, and so on.\n    * STEP: The number of arguments to skip to find the next one. Typically 1.\n    * LIMIT: If LAST is -1, we use the limit to stop the search by a factor. 0\n      and 1 mean no limit. 2 means half of the remaining arguments, 3 means a\n      third, and so on.\n\nCommands with subcommands\n-------------------------\n\nCommands with subcommands are special. Examples of commands with subcommands are\n`CLUSTER` and `ACL`. Their first argument is a subcommand which determines the\nsyntax of the rest the command, which is stored in its own JSON file.\n\nFor example `CLUSTER INFO` is stored in a file called `cluster-info.json`. The\ntoplevel key is called `\"INFO\"`. Within the body, there's a key called\n`\"container\"` with the value `\"CLUSTER\"`. The file `cluster.json` exists by it\ndoesn't have an `\"arguments\"` key.\n\nAppendix\n--------\n\nHow to list all the `group`, `command_flags` and `acl_categories`, etc. used in all these files:\n\n    cat *.json | jq '.[].group'             | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].command_flags'     | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].acl_categories'    | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].arguments[]?.type' | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n","isInternal":false,"tokens":2505,"sizeBytes":9446}],"systemPromptSnippet":"<yakaai_skills repo=\"valkey-io/valkey\">\n<!-- File: AGENTS.md (Tokens: ~749 | Category: root-instruction) -->\n# AGENTS.md\n\n## Scope\n- These instructions apply to the entire repository unless a deeper `AGENTS.md` overrides them.\n\n## Repo overview\n- This is the Valkey server codebase.\n- The main implementation lives under `src/`.\n- Unit tests live under `src/unit`\n- Integration tests live under `tests/`.\n- Top-level `Makefile` forwards most targets into `src/Makefile`.\n\n## Working guidelines\n- Keep changes minimal and easy to backport.\n- Match the style of the surrounding code instead of introducing new patterns.\n- Avoid unrelated refactors in the same change.\n\n## Build\n- Default build: `make`\n- Clean rebuild when build settings or bundled deps change: `make distclean && make`\n\n## Unit tests\n- Unit tests live under `src/unit/` and use GoogleTest (gtest/gmock).\n- Build and run all unit tests: `make -C src test-unit`\n- Unit tests cover data-structure and low-level logic changes.\n- A single test filter can be run with: `make -C src test-unit && ./src/unit/valkey-unit-gtests --gtest_filter='<TestSuite>.<TestName>'`\n- **Write tests in minimal C++.** GTest provides the test runner, but test code should look like C. No STL containers (`std::vector`, `std::string`, `std::set`), no STL algorithms, no `auto`, no lambdas, no templates, no RAII. Use fixed-size C arrays, `sds`, `qsort`, and explicit types. See `src/unit/README.md` for full guidelines and examples.\n\n## Integration tests\n- Integration tests live under `tests/` and are written in Tcl.\n- Run the full integration suite: `make test` (from the repo root).\n- Run a single test file: `./runtest --single <path/to/test.tcl>`\n- Additional specialized suites:\n  - Cluster tests: `./runtest-cluster`\n  - Sentinel tests: `./runtest-sentinel`\n  - Module API tests: `./runtest-moduleapi`\n- For targeted validation, run the smallest relevant test scope first before broader suites.\n\n## Code style\n- Follow the repository conventions described in `DEVELOPMENT_GUIDE.md`.\n- Most formatting is enforced by `clang-format`.\n- CI uses `clang-format-18` across `*.c`, `*.h`, `*.cpp`, and `*.hpp` files.\n- When touching C/C++ sources or headers, run `clang-format-18 -i` on the modified files before finalizing when the tool is available.\n- Use comments for non-obvious behavior and rationale, not for restating code.\n\n## Tests\n- Code changes should include relevant tests when the repo already has a matching test location.\n- Data-structure and low-level logic changes usually belong in `src/unit/` (C++ gtest).\n- End-to-end behavior changes usually belong in `tests/` (Tcl integration tests).\n- If behavior or commands change, check whether related documentation also needs updating.\n\n## Files to avoid touching unless required\n- Do not commit local runtime artifacts such as `dump.rdb`, `nodes.conf`, `*.log`, or ad hoc cluster directories unless the task explicitly requires them.\n- Treat vendored dependency code under `deps/` as special-case changes; modify it only when the task clearly requires it.\n\n## Pull Requests\nAlways push to the user's fork. Never push to the upstream valkey-io/valkey repository. Never push directly to unstable. If a user fork does not exist, ask the contributor to create one.\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~361 | Category: copilot-instructions) -->\n# Valkey Project Instructions\n\nYou are an expert code reviewer for the Valkey project. Provide helpful, constructive feedback on code quality, safety, and adherence to project standards.\n\n## 1. Review Tone & Focus\n- **Tone:** Be professional, direct, constructive, and empathetic.\n- **Focus:** Critique the *code*, never the *person*.\n- **Constructive:** Suggest improvements, explain *why*, provide examples.\n\n## 2. Critical Checks\n- **DCO:** **Flag missing** `Signed-off-by: Name <email>` in commits. Every commit needs it.\n- **Security:** If PR fixes a security vulnerability, flag it: \"Security fixes should be reported privately to security@lists.valkey.io, not via public PRs.\"\n\n## 3. Major Decision Detection\nFlag PRs that appear to be \"Technical Major Decisions\" requiring TSC consensus:\n- Fundamental changes to core datastructures\n- New data structures or APIs\n- Backward compatibility breaks\n- New user-visible fields requiring long-term maintenance\n- New external libraries affecting runtime behavior\n\n**Action:** Comment mentioning **@core-team** that this appears to require TSC review and ask if consensus was reached in a linked Issue.\n\n## 4. Documentation Reminder\nIf PR changes user-facing behavior (new commands, changed semantics, new config):\n- **Remind** author that docs at [valkey-doc](https://github.com/valkey-io/valkey-doc) may need updating.\n- **Suggest** linking PR to related Issue with \"Fixes #xyz\" pattern if applicable.\n\n## 5. Governance Changes\n**ANY change to `GOVERNANCE.md`** requires special attention - comment mentioning **@core-team** for review.\n\n<!-- File: src/commands/README.md (Tokens: ~2505 | Category: command-prompt) -->\nCommand JSON files\n==================\n\nThis directory contains JSON files, one for each command.\n\nEach JSON file contains all the information about the command itself. It is the\n\"single source of truth\" (SSOT) for the command's metadata.\n\nThese JSON files were originally not intended to be used directly, since they\ncontain internals and some fields like \"acl_categories\" that are not the final\nACL categories. (Valkey will apply some implicit rules to compute the final ACL\ncategories.) However, people see JSON files and use them directly anyway.\n\nAny third party who needs access to command information were originally supposed\nto get it from `COMMAND INFO` and `COMMAND DOCS`. These commands can be combined\ninto a JSON file by the script `utils/generate-commands-json.py`. Confusingly\nenough, this JSON file as a slightly different format!\n\nStructure\n---------\n\nEach JSON file contains an object with a single key. The key is the command name\nin uppercase, e.g. \"HSCAN\" (hscan.json). The value is a JSON object with the\nfollowing keys. To be safe, assume all of them are optional.\n\n* `\"summary\"`: a string with a short description of the command. One sentence.\n* `\"complexity\"`: a string like `\"O(1)\"` or longer, like `\"O(1) for every call. O(N) for a complete iteration, including enough command calls for the cursor to return back to 0. N is the number of elements inside the collection.\"`.\n* `\"group\"`: a string used for categorization in documentation. One of these:\n  * `\"bitmap\"`\n  * `\"cluster\"`\n  * `\"connection\"`\n  * `\"generic\"`\n  * `\"geo\"`\n  * `\"hash\"`\n  * `\"hyperloglog\"`\n  * `\"list\"`\n  * `\"pubsub\"`\n  * `\"scripting\"`\n  * `\"sentinel\"`\n  * `\"server\"`\n  * `\"set\"`\n  * `\"sorted_set\"`\n  * `\"stream\"`\n  * `\"string\"`\n  * `\"transactions\"`\n* `\"since\"`: a string with a version number, like \"7.0.0\". It's the version\n  (Redis OSS or Valkey) where the command was introduced.\n* `\"arity\"`: The number of arguments, including the command name itself. A\n  negative number means \"at least\", e.g. -3 means at least 3.\n* `\"container\"`: Only present for subcommands. See below.\n* `\"history\"`: An array of changes, each change represented by a 2-element array\n  on the form `[VERSION, DESCRIPTION]`. Omit if empty. Don't add an empty array.\n* `\"function\"`: The name of the C function in Valkey's source code implementing\n  the command. (Don't use it for anything else.)\n* `\"command_flags\"`: An array of flags represented as strings. Command flags:\n  * `\"ADMIN\"`\n  * `\"ALL_DBS\"`\n  * `\"ALLOW_BUSY\"`\n  * `\"ASKING\"`\n  * `\"BLOCKING\"`\n  * `\"DENYOOM\"`\n  * `\"FAST\"`\n  * `\"LOADING\"`\n  * `\"MAY_REPLICATE\"`\n  * `\"NO_ASYNC_LOADING\"`\n  * `\"NO_AUTH\"`\n  * `\"NO_MANDATORY_KEYS\"`\n  * `\"NO_MULTI\"`\n  * `\"NOSCRIPT\"`\n  * `\"ONLY_SENTINEL\"`\n  * `\"PROTECTED\"`\n  * `\"PUBSUB\"`\n  * `\"READONLY\"`\n  * `\"SENTINEL\"`\n  * `\"SKIP_MONITOR\"`\n  * `\"SKIP_SLOWLOG\"`\n  * `\"STALE\"`\n  * `\"TOUCHES_ARBITRARY_KEYS\"`\n  * `\"WRITE\"`\n* `\"acl_categories\"`: A list of ACL categories in uppercase. Note that the\n  effective ACL categories include \"implicit ACL categories\" explained below.\n  * `\"ADMIN\"`\n  * `\"BITMAP\"`\n  * `\"CONNECTION\"`\n  * `\"DANGEROUS\"`\n  * `\"GEO\"`\n  * `\"HASH\"`\n  * `\"HYPERLOGLOG\"`\n  * `\"KEYSPACE\"`\n  * `\"LIST\"`\n  * `\"SCRIPTING\"`\n  * `\"SET\"`\n  * `\"SORTEDSET\"`\n  * `\"STREAM\"`\n  * `\"STRING\"`\n  * `\"TRANSACTION\"`\n* `\"get_dbid_args\"`: The name of the C function in Valkey's source code\n  implementing retrieval of database ID arguments from commands that accept\n  database ID as an argument.\n* `\"command_tips\"`: Optional. A list of one or more of these strings:\n  * `\"NONDETERMINISTIC_OUTPUT\"`\n  * `\"NONDETERMINISTIC_OUTPUT_ORDER\"`\n  * `\"REQUEST_POLICY:ALL_NODES\"`\n  * `\"REQUEST_POLICY:ALL_SHARDS\"`\n  * `\"REQUEST_POLICY:MULTI_SHARD\"`\n  * `\"REQUEST_POLICY:SPECIAL\"`\n  * `\"RESPONSE_POLICY:AGG_LOGICAL_AND\"`\n  * `\"RESPONSE_POLICY:AGG_MIN\"`\n  * `\"RESPONSE_POLICY:AGG_SUM\"`\n  * `\"RESPONSE_POLICY:ALL_SUCCEEDED\"`\n  * `\"RESPONSE_POLICY:ONE_SUCCEEDED\"`\n  * `\"RESPONSE_POLICY:SPECIAL\"`\n* `\"key_specs\"`: An array of key specifications. See below.\n* `\"reply_schema\"`: A [JSON Schema](https://json-schema.org/) that describes the\n  reply of the command. This isn't complete. For example, JSON Schema can't\n  distinguish arrays from sets, commands returning a set are declared to return\n  an array.\n* `\"arguments\"`: An array of arguments. Each argument is an object with the following keys:\n  * `\"name\"`: A string identifying the argument. It's unique among the arguments.\n  * `\"type\"`: The type of the argument.\n    * `\"block\"`: A group of arguments. The elements are in the key `\"arguments\"`.\n    * `\"double\"`: A number, not necessarily an integer.\n    * `\"integer\"`: An integer.\n    * `\"key\"`: A string representing a key in the database.\n    * `\"oneof\"`: One of a list of alternatives. The alternatives are in the key `\"arguments\"`.\n    * `\"pattern\"`: A string representing a glob-style pattern.\n    * `\"pure-token\"`: A fixed string. The string is in the key `\"token\"`.\n    * `\"string\"`: A string.\n    * `\"unix-time\"`: An integer representing a unix time in either seconds or milliseconds.\n  * `\"arguments\"`: A list with the same structure as its parent. Present if type is \"block\" or \"oneof\".\n  * `\"display\"`: (\"entries-read\", \"key\" or \"pattern\")\n  * `\"key_spec_index\"`: An index into the `\"key_specs\"` array. Only if `\"type\"` is `\"key\"`.\n  * `\"multiple\":` true if the argument can be repeated multiple times. Omitted means false.\n  * `\"multiple_token\"`: Unclear meaning. Maybe meaningless.\n  * `\"optional\":` True if the argument is optional. Omitted means false.\n  * `\"since\"`: Version (string) when the argument was introduced.\n  * `\"token\"`: A string indicating a fixed string value. This is always present\n    if type is \"pure-token\". If type is anything else, then `\"token\"` indicates\n    the argument is preceded by an extra (fixed string) argument.\n\nACL categories\n-----------------------\n\nThe ACL categories specified as `\"acl_categories\"` are the ones that are actually used.\n**Note:** commands categories should follow specific rules that are checked in `utils/generate-command-code.py`\n\n**ACL Category Rules:**\n* Command flag WRITE implies ACL category WRITE.\n* Command flag READONLY and not ACL category SCRIPTING implies ACL category READ.\n  \"Exclude scripting commands from the RO category.\"\n* Command flag ADMIN implies ACL categories ADMIN and DANGEROUS.\n* Command flag PUBSUB implies ACL category PUBSUB.\n* Command flag FAST implies ACL category FAST.\n* Command flag BLOCKING implies ACL category BLOCKING.\n* Not ACL category FAST implies ACL category SLOW. \"If it's not fast, it's slow.\"\n\nKey specs\n---------\n\nKey specifications are specified in the array `\"key_specs\"` key of a command.\n\nEach element in this array is an object with the following keys:\n\n* `\"flags\"`: An array of strings indicating what kind of access is the command does on the key.\n  * `\"ACCESS\"`\n  * `\"DELETE\"`\n  * `\"INCOMPLETE\"`\n  * `\"INSERT\"`\n  * `\"NOT_KEY\"`\n  * `\"OW\"`\n  * `\"RM\"`\n  * `\"RO\"`\n  * `\"RW\"`\n  * `\"UPDATE\"`\n  * `\"VARIABLE_FLAGS\"`\n* `\"begin_search\"`: How to find the first key used by this key spec. It's an\n  object with only one key. The key determines the method for finding the first\n  key. Here are the possible forms of the `\"begin_search\"` object:\n  * `{\"index\": {\"pos\": N}}`: The first key is at position N in the command line,\n    where 0 is the command name.\n  * `{\"keyword\": KEYWORD, \"startfrom\": N}`: The first key is found by searching\n    for an argument with the exact value KEYWORD starting from index N in the\n    command line. The first key is the argument after the keyword.\n  * `{\"unknown\": null}`: Finding the keys of this command is too complicated to\n    explain.\n* `\"find_keys\"`: How to find the remaining keys of this key spec. It's an object\n  on one of these forms:\n  * `{\"range\": {\"lastkey\": LAST, \"step\": STEP, \"limit\": LIMIT}}`: A range of keys.\n    * LAST: If LAST is positive, it's the index of the last key relative to the\n      first key. If last is negative, then -1 is the end of the whole command\n      line, -2 is the penultimate argument of the command, and so on.\n    * STEP: The number of arguments to skip to find the next one. Typically 1.\n    * LIMIT: If LAST is -1, we use the limit to stop the search by a factor. 0\n      and 1 mean no limit. 2 means half of the remaining arguments, 3 means a\n      third, and so on.\n\nCommands with subcommands\n-------------------------\n\nCommands with subcommands are special. Examples of commands with subcommands are\n`CLUSTER` and `ACL`. Their first argument is a subcommand which determines the\nsyntax of the rest the command, which is stored in its own JSON file.\n\nFor example `CLUSTER INFO` is stored in a file called `cluster-info.json`. The\ntoplevel key is called `\"INFO\"`. Within the body, there's a key called\n`\"container\"` with the value `\"CLUSTER\"`. The file `cluster.json` exists by it\ndoesn't have an `\"arguments\"` key.\n\nAppendix\n--------\n\nHow to list all the `group`, `command_flags` and `acl_categories`, etc. used in all these files:\n\n    cat *.json | jq '.[].group'             | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].command_flags'     | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].acl_categories'    | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n    cat *.json | jq '.[].arguments[]?.type' | grep -F '\"' | sed 's/^ *//;s/, *$//;s/^/  * `/;s/$/`/' | sort | uniq\n</yakaai_skills>"}