{"owner":"gohugoio","repo":"hugo","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"files":{"AGENTS.md":"\n* Brevity is good.\n* Assume that the maintainers and readers of the code you write are Go experts:\n   * Don't use comments to explain the obvious.\n   * Use self-explanatory variable and function names.\n   * Use short variable names when the context is clear.\n* If you need to add temporary debug printing, use `hdebug.Printf`.[^1]\n* Never export symbols that's not needed outside of the package.\n* Avoid global state at (almost) all cost.\n* This is a project with a long history; assume that a similiar problem has been solved before, look hard for helper functions before creating new ones.\n* In tests, almost always write end-to-end integration tests using `hugolib.Test` or one of its siblings. Write unit tests only for isolated utilities.\n* In tests, use `qt` matchers (e.g. `b.Assert(err, qt.ErrorMatches, ...)`) instead of raw `if`/`t.Fatal` checks.\n* In tests, always use the latest Hugo specification, e.g. for layouts, it's `layouts/page.html` and not `layouts/_default/single.html`, `layouts/list.html` and not `layouts/_default/list.html`\n* Never name tests `TestIssue1234`; always give the test function a descriptive name, e.g. `TestDisablePathToLower`, and add any issue reference as a Go doc function comment, e.g. `// See issue 1234.`.\n* If you borrow a test case (e.g. from the issue), that test's author must be added as co-author in the commit.\n* If you're a security researcher, read @SECURITY.md carefully.\n* Brevity is good. This applies to code, comments and commit messages. Don't write a novel.\n* Use `./check.sh ./somepackage/...` when iterating.\n* Use `./check.sh` when you're done.\n\n\n[^1]: CI build fail if you forget to remove the debug printing.\n"}}