{
  "markdown": "# Repo Harness\n\nVendor-neutral Agent Skills for bootstrapping and auditing the engineering\nharness around a software repository.\n\nRepo Harness helps an unfamiliar human or coding agent understand where to\nwork, which constraints apply, how to get useful feedback, and how to verify a\nchange safely.\n\n| Skill | Purpose |\n| --- | --- |\n| `harness:start` | Bootstrap or improve a repository harness |\n| `harness:audit` | Evaluate an existing repository harness |\n\n## How it works\n\nAn engineering harness is the context, constraints, workflows, feedback loops,\nand verification infrastructure around a codebase. Repo Harness evaluates\nthose capabilities rather than checking for particular filenames.\n\n```mermaid\nflowchart TD\n    request[\"Repository request\"] --> intent{\"Intent\"}\n    intent --> start[\"harness:start\"]\n    start --> startFlow[\"Discover gaps → minimal changes → verify\"]\n    intent --> audit[\"harness:audit\"]\n    audit --> auditFlow[\"Inspect → score seven dimensions → prioritize\"]\n```\n\nThe two skills share an evidence-first approach but have distinct\nresponsibilities: `harness:start` can carry an explicitly requested plan\nthrough implementation and safe verification, while `harness:audit` stops at\nevidence-backed findings and prioritized improvements.\n\n### `harness:start`\n\nBootstrap or improve the minimum useful harness for the current repository.\nDiscovery comes before questions; existing conventions and sources of truth\nare reused before new files, commands, or documentation are proposed.\n\n### `harness:audit`\n\nEvaluate how safely and efficiently an unfamiliar human or coding agent can\nunderstand, modify, and verify the repository. Audits are non-mutating and\nstatic by default; safe runtime validation is optional only when explicitly\nrequested. Findings are not implemented by the audit skill.\n\n## Audit dimensions\n\n| Dimension | Question it answers |\n| --- | --- |\n| **Context** | Can an unfamiliar contributor understand the project and its domain? |\n| **Navigation** | Can they find where a change belongs and where deeper context lives? |\n| **Constraints** | Can they discover invariants, boundaries, generated files, migrations, and risky areas? |\n| **Verification** | Can they prove a change works and matches repository expectations? |\n| **Feedback Loops** | Does the repository provide fast, useful, reproducible feedback? |\n| **Operational Understanding** | Can they run and debug the project at the level its scope requires? |\n| **Agent Readiness** | Can a coding agent make and verify a safe, bounded change? |\n\n## Principles and safety\n\n- Discover before asking.\n- Use evidence before assumptions.\n- Evaluate capabilities, not file presence.\n- Prefer executable knowledge and one source of truth.\n- Preserve existing conventions and minimize harness surface area.\n- Do not perform a generic code review.\n- `harness:audit` is non-mutating by default.\n- `harness:start` may modify the repository only when requested.\n- Both skills classify a command and its full chain before execution.\n- Unsafe, destructive, credentialed, externally side-effectful, or unclear\n  operations are not run automatically.\n- Commands that deploy, publish, alter production or shared state, require\n  credentials, or have unclear effects require approval or an explicit report\n  that runtime verification was not executed.\n- If verification is skipped or blocked, it is never reported as passing.\n\n## Skill structure\n\n```text\nrepo-harness/\n├── .claude-plugin/plugin.json\n├── .codex-plugin/plugin.json\n├── gemini-extension.json\n├── skills/\n│   ├── start/\n│   │   ├── SKILL.md\n│   │   └── references/\n│   └── audit/\n│       ├── SKILL.md\n│       └── references/\n├── tests/\n│   ├── README.md\n│   ├── start/\n│   └── audit/\n├── docs/spec.md\n├── README.md\n└── LICENSE\n```\n\nThe `skills/` tree is the behavioral source of truth. Each `SKILL.md`\ndefines one focused behavior with supporting references; the tests are\nconceptual behavioral scenarios rather than a runner or fixture repository.\nNo particular file is mandatory: equivalent capability elsewhere in the\nrepository counts. The structure shown here is a map, not a required template.\n\n## Installation\n\nThe runtime manifests identify the `harness` plugin namespace and point\nruntimes at the two skills in `skills/`.\n\n### Antigravity / Antigravity CLI\n\nRemote installation:\n\n```bash\nagy plugin install https://github.com/amnotwallas/repo-harness\n```\n\nLocal development installation:\n\n```bash\nagy plugin install /path/to/repo-harness\n```\n\nLaunch the CLI with:\n\n```bash\nagy\n```\n\nThe installation and namespaced invocation flow in [Usage](#usage) has been\nverified end-to-end with the actual Antigravity CLI.\n\n### Claude Code\n\nFor local development:\n\n```bash\nclaude --plugin-dir /path/to/repo-harness\n```\n\nThe `.claude-plugin/plugin.json` manifest validates successfully and names\nthe plugin namespace `harness`. The expected namespaced commands are in\n[Usage](#usage); authenticated end-to-end invocation was not verified.\nPersistent installation uses available marketplaces, but no marketplace name\nor installation command is assumed here.\n\n### Codex\n\nThe existing `.codex-plugin/plugin.json` package names the plugin `harness`\nand points to `./skills/`.\n\nIf an existing configured Codex marketplace contains `repo-harness`, use its\n`harness` entry with this selector syntax:\n\n```text\ncodex plugin add harness@MARKETPLACE_NAME\n```\n\nReplace `MARKETPLACE_NAME` with that configured marketplace. This is a syntax\ntemplate, not a universally copy-paste-ready command. No direct repository URL\ninstallation command is assumed here.\n\nFor standalone local Agent Skills usage:\n\n```bash\nmkdir -p ~/.agents/skills\n\nln -s /path/to/repo-harness/skills/start ~/.agents/skills/harness-start\nln -s /path/to/repo-harness/skills/audit ~/.agents/skills/harness-audit\n```\n\n## Usage\n\nExact command syntax depends on the runtime. The preferred namespaced commands\nare available where plugin namespacing is supported; they are not universal:\n\n```text\n/harness:start\n/harness:audit\n```\n\nFor standalone Codex Agent Skills, use:\n\n```text\n$harness-start\n$harness-audit\n```\n\nNatural-language discovery remains the universal fallback:\n\n```text\nSet up the engineering harness for this repository.\n\nAudit the engineering harness of this repository.\n```\n\n## Behavioral tests\n\nThe conceptual scenarios in [`tests/start/`](tests/start/) and\n[`tests/audit/`](tests/audit/) currently include 15 scenarios: 7 for\n`harness:start` and 8 for `harness:audit`.\n\nEach scenario is evaluated against supplied repository evidence rather than\nexact wording, arbitrary scores, or a file checklist.\n\nThey cover:\n\n- `harness:start`: healthy and minimal projects, vendor-neutral guidance,\n  runtime command safety, secret-file safety, verification boundaries, and\n  independence from external skills.\n- `harness:audit`: poor harnesses, capability evidence, missing-path\n  contracts, dependency contracts, static runtime inference, secret-file\n  safety, stale documentation, and monorepos.\n- Boundary behavior preventing either skill from taking the other's\n  responsibility.\n\n## Status\n\nEarly v0.1 / pre-release.\n\n## License\n\nReleased under the [MIT License](LICENSE).\n",
  "bytes": 7183,
  "sha": "e320bd08f31fd73263b69b335f6ca9cdf34c7e416e7887a6a9a4f66a5e9f7a1a",
  "repo_slug": "amnotwallas/repo-harness",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_amnotwallas_repo_harness_d118799d/readme"
}