{"owner":"Giskard-AI","repo":"giskard-oss","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\ngiskard-oss — behavioral config for interactive coding assistants with a human in the loop.\n\n## Workflow Orchestration\n\n### 1. Plan Mode Default\n– Enter plan mode for ANY non-trivial task (3+ steps or touches multiple libs)\n– Brainstorm first (design → spec), then write an implementation plan\n– Save specs and plans in the repo's established planning docs. Prefer `docs/specs/` and `docs/plans/`; if the repo already uses another planning directory, follow that convention.\n– If something goes sideways, STOP and re-plan immediately\n\n### 2. Subagent Strategy\n– Use subagents or equivalent isolated work sessions when the assistant supports them\n– Prefer a fresh subagent/session per task; controller curates exactly the context each one needs\n– Two-stage review after each task: spec compliance first, then code quality\n\n### 3. Self-Improvement Loop\n– After ANY correction: self-document the rule (naming, file headers, examples); only add to AGENTS.md if it cannot be self-documented\n– When a correction changes what was implemented vs. what the plan says: update the plan file immediately so reviewers never see a mismatch\n\n### 4. Verification Before Done\n– Never mark a task complete without proving it works\n– Run: `make format && make check && make test-unit PACKAGE=<affected-lib>`\n– Show actual output. Never assume tests pass.\n– Ask yourself: \"Would a staff engineer approve this?\"\n\n### 5. Demand Elegance\n– Pause and ask \"is there a more elegant solution?\"\n– Skip for simple fixes — don't over-engineer\n\n### 6. Autonomous Bug Fixing\n– When given a bug report with clear scope: just fix it\n– No `# type: ignore`, no patched test assertions — fix the root cause\n\n### 7. Commit Hygiene\n– Use Conventional Commits for every commit message (for example, `fix(llm): update google interactions translator`)\n\n## Task Management\n1. Brainstorm → Spec → Plan — save to the repo's established planning docs, preferably `docs/specs/` and `docs/plans/`\n2. Verify Plan — check in before starting\n3. Track Progress — mark items complete as you go\n4. Explain Changes — high-level summary at each step\n5. Document Results — add review section to the plan file\n6. Capture Lessons — update AGENTS.md directly after corrections\n\n## Core Principles\n– Simplicity First: make every change as simple as possible; prefer deleting lines over adding them\n– No Laziness: find root causes; no band-aids, no temporary fixes; senior developer standards\n– Minimal Impact: only touch what's necessary; no side effects; no reformatting untouched lines\n\n## Cursor Cloud specific instructions\n\nNon-obvious context for cloud agents (startup refresh is `make install` then `make install-tools`; `uv` is on `PATH` for login shells via `~/.bashrc`).\n\n– This repo is a `uv` workspace monorepo of pure Python libraries (`libs/giskard-*`). There is no server, daemon, or CLI to start — \"running\" the product means importing the libraries from Python or running `pytest`. Prefer Makefile targets over raw `uv`/`pytest` (`make help`).\n– Import namespace is `giskard.<sublib>` (e.g. `import giskard.checks`), not `giskard_checks`.\n– Do not run full `make setup` in this VM: its `pre-commit-install` step fails with `Cowardly refusing to install hooks with core.hooksPath set`. That is expected (global `core.hooksPath`) and harmless — use `make install` + `make install-tools` instead; git hooks are not needed to validate work.\n– Lint/test/build/run all work without secrets: `make lint`, `make test-unit [PACKAGE=<lib>]`, and importing the libs. Unit tests exclude anything marked `functional`.\n– Functional/integration tests are excluded by default and require live LLM provider API keys (e.g. `OPENAI_API_KEY`, `GOOGLE_API_KEY`, `ANTHROPIC_API_KEY`); `giskard-scan` may also reach Hugging Face Hub. Do not expect these to run without those secrets and network access.\n– `make check` runs `security` (`pip-audit`) and license checks (`check-licenses`/`check-notices`) that reach the network (PyPI / license metadata); if offline these steps can fail even when the code is fine.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\ngiskard-oss — behavioral config for interactive coding assistants with a human in the loop.\n\n## Workflow Orchestration\n\n### 1. Plan Mode Default\n– Enter plan mode for ANY non-trivial task (3+ steps or touches multiple libs)\n– Brainstorm first (design → spec), then write an implementation plan\n– Save specs and plans in the repo's established planning docs. Prefer `docs/specs/` and `docs/plans/`; if the repo already uses another planning directory, follow that convention.\n– If something goes sideways, STOP and re-plan immediately\n\n### 2. Subagent Strategy\n– Use subagents or equivalent isolated work sessions when the assistant supports them\n– Prefer a fresh subagent/session per task; controller curates exactly the context each one needs\n– Two-stage review after each task: spec compliance first, then code quality\n\n### 3. Self-Improvement Loop\n– After ANY correction: self-document the rule (naming, file headers, examples); only add to AGENTS.md if it cannot be self-documented\n– When a correction changes what was implemented vs. what the plan says: update the plan file immediately so reviewers never see a mismatch\n\n### 4. Verification Before Done\n– Never mark a task complete without proving it works\n– Run: `make format && make check && make test-unit PACKAGE=<affected-lib>`\n– Show actual output. Never assume tests pass.\n– Ask yourself: \"Would a staff engineer approve this?\"\n\n### 5. Demand Elegance\n– Pause and ask \"is there a more elegant solution?\"\n– Skip for simple fixes — don't over-engineer\n\n### 6. Autonomous Bug Fixing\n– When given a bug report with clear scope: just fix it\n– No `# type: ignore`, no patched test assertions — fix the root cause\n\n### 7. Commit Hygiene\n– Use Conventional Commits for every commit message (for example, `fix(llm): update google interactions translator`)\n\n## Task Management\n1. Brainstorm → Spec → Plan — save to the repo's established planning docs, preferably `docs/specs/` and `docs/plans/`\n2. Verify Plan — check in before starting\n3. Track Progress — mark items complete as you go\n4. Explain Changes — high-level summary at each step\n5. Document Results — add review section to the plan file\n6. Capture Lessons — update AGENTS.md directly after corrections\n\n## Core Principles\n– Simplicity First: make every change as simple as possible; prefer deleting lines over adding them\n– No Laziness: find root causes; no band-aids, no temporary fixes; senior developer standards\n– Minimal Impact: only touch what's necessary; no side effects; no reformatting untouched lines\n\n## Cursor Cloud specific instructions\n\nNon-obvious context for cloud agents (startup refresh is `make install` then `make install-tools`; `uv` is on `PATH` for login shells via `~/.bashrc`).\n\n– This repo is a `uv` workspace monorepo of pure Python libraries (`libs/giskard-*`). There is no server, daemon, or CLI to start — \"running\" the product means importing the libraries from Python or running `pytest`. Prefer Makefile targets over raw `uv`/`pytest` (`make help`).\n– Import namespace is `giskard.<sublib>` (e.g. `import giskard.checks`), not `giskard_checks`.\n– Do not run full `make setup` in this VM: its `pre-commit-install` step fails with `Cowardly refusing to install hooks with core.hooksPath set`. That is expected (global `core.hooksPath`) and harmless — use `make install` + `make install-tools` instead; git hooks are not needed to validate work.\n– Lint/test/build/run all work without secrets: `make lint`, `make test-unit [PACKAGE=<lib>]`, and importing the libs. Unit tests exclude anything marked `functional`.\n– Functional/integration tests are excluded by default and require live LLM provider API keys (e.g. `OPENAI_API_KEY`, `GOOGLE_API_KEY`, `ANTHROPIC_API_KEY`); `giskard-scan` may also reach Hugging Face Hub. Do not expect these to run without those secrets and network access.\n– `make check` runs `security` (`pip-audit`) and license checks (`check-licenses`/`check-notices`) that reach the network (PyPI / license metadata); if offline these steps can fail even when the code is fine.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\ngiskard-oss — behavioral config for interactive coding assistants with a human in the loop.\n\n## Workflow Orchestration\n\n### 1. Plan Mode Default\n– Enter plan mode for ANY non-trivial task (3+ steps or touches multiple libs)\n– Brainstorm first (design → spec), then write an implementation plan\n– Save specs and plans in the repo's established planning docs. Prefer `docs/specs/` and `docs/plans/`; if the repo already uses another planning directory, follow that convention.\n– If something goes sideways, STOP and re-plan immediately\n\n### 2. Subagent Strategy\n– Use subagents or equivalent isolated work sessions when the assistant supports them\n– Prefer a fresh subagent/session per task; controller curates exactly the context each one needs\n– Two-stage review after each task: spec compliance first, then code quality\n\n### 3. Self-Improvement Loop\n– After ANY correction: self-document the rule (naming, file headers, examples); only add to AGENTS.md if it cannot be self-documented\n– When a correction changes what was implemented vs. what the plan says: update the plan file immediately so reviewers never see a mismatch\n\n### 4. Verification Before Done\n– Never mark a task complete without proving it works\n– Run: `make format && make check && make test-unit PACKAGE=<affected-lib>`\n– Show actual output. Never assume tests pass.\n– Ask yourself: \"Would a staff engineer approve this?\"\n\n### 5. Demand Elegance\n– Pause and ask \"is there a more elegant solution?\"\n– Skip for simple fixes — don't over-engineer\n\n### 6. Autonomous Bug Fixing\n– When given a bug report with clear scope: just fix it\n– No `# type: ignore`, no patched test assertions — fix the root cause\n\n### 7. Commit Hygiene\n– Use Conventional Commits for every commit message (for example, `fix(llm): update google interactions translator`)\n\n## Task Management\n1. Brainstorm → Spec → Plan — save to the repo's established planning docs, preferably `docs/specs/` and `docs/plans/`\n2. Verify Plan — check in before starting\n3. Track Progress — mark items complete as you go\n4. Explain Changes — high-level summary at each step\n5. Document Results — add review section to the plan file\n6. Capture Lessons — update AGENTS.md directly after corrections\n\n## Core Principles\n– Simplicity First: make every change as simple as possible; prefer deleting lines over adding them\n– No Laziness: find root causes; no band-aids, no temporary fixes; senior developer standards\n– Minimal Impact: only touch what's necessary; no side effects; no reformatting untouched lines\n\n## Cursor Cloud specific instructions\n\nNon-obvious context for cloud agents (startup refresh is `make install` then `make install-tools`; `uv` is on `PATH` for login shells via `~/.bashrc`).\n\n– This repo is a `uv` workspace monorepo of pure Python libraries (`libs/giskard-*`). There is no server, daemon, or CLI to start — \"running\" the product means importing the libraries from Python or running `pytest`. Prefer Makefile targets over raw `uv`/`pytest` (`make help`).\n– Import namespace is `giskard.<sublib>` (e.g. `import giskard.checks`), not `giskard_checks`.\n– Do not run full `make setup` in this VM: its `pre-commit-install` step fails with `Cowardly refusing to install hooks with core.hooksPath set`. That is expected (global `core.hooksPath`) and harmless — use `make install` + `make install-tools` instead; git hooks are not needed to validate work.\n– Lint/test/build/run all work without secrets: `make lint`, `make test-unit [PACKAGE=<lib>]`, and importing the libs. Unit tests exclude anything marked `functional`.\n– Functional/integration tests are excluded by default and require live LLM provider API keys (e.g. `OPENAI_API_KEY`, `GOOGLE_API_KEY`, `ANTHROPIC_API_KEY`); `giskard-scan` may also reach Hugging Face Hub. Do not expect these to run without those secrets and network access.\n– `make check` runs `security` (`pip-audit`) and license checks (`check-licenses`/`check-notices`) that reach the network (PyPI / license metadata); if offline these steps can fail even when the code is fine.\n","category":"root","tokens":1015}]}