{"owner":"valkey-io","repo":"valkey","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":[".github/copilot-instructions.md","AGENTS.md"],"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"}}