feat: bootstrap he maintainer skill

he-maintainer/references/go.md

@@ -0,0 +1,32 @@
+# Go Harness Notes
+
+Use this reference for Go repositories.
+
+## Common files to inspect
+
+- `go.mod`
+- `go.sum`
+- `cmd/`
+- `internal/`
+- `pkg/`
+- `Makefile`
+- `.golangci.*`
+
+## Common validation commands
+
+Typical examples:
+
+- `go test ./...`
+- `go build ./...`
+- `golangci-lint run`
+- `make test`
+- `make build`
+
+Prefer repo-defined commands when available.
+
+## Common guardrails
+
+- avoid broad package churn when a local fix is enough
+- identify whether generated code exists before editing
+- note whether integration tests require external services
+- keep command examples copy-pasteable

he-maintainer/references/monorepo.md

@@ -0,0 +1,23 @@
+# Monorepo Harness Notes
+
+Use this reference when the repository contains multiple apps, packages, crates, or services.
+
+## What to map clearly
+
+- workspace root vs package roots
+- shared libraries vs deployable apps
+- root-level commands vs package-level commands
+- ownership boundaries between packages
+
+## Common risks
+
+- commands at the root may not validate a specific package well
+- agents may edit shared packages when a local override is safer
+- build, lint, and test commands may vary by package manager and workspace tool
+
+## Good harness patterns
+
+- include a short workspace map
+- show how to run commands for one package
+- define allowed scope for a task
+- prefer targeted validation for the touched package first

he-maintainer/references/node-typescript.md

@@ -0,0 +1,39 @@
+# Node / TypeScript Harness Notes
+
+Use this reference for Node.js or TypeScript repositories.
+
+## Common files to inspect
+
+- `package.json`
+- `tsconfig.json`
+- `eslint.config.*` or `.eslintrc*`
+- `vitest.config.*`, `jest.config.*`, `playwright.config.*`
+- `src/`, `apps/`, `packages/`, `tests/`
+
+## Common validation commands
+
+Prefer commands already defined by the repo. Typical examples:
+
+- `npm test`
+- `npm run lint`
+- `npm run build`
+- `npm run typecheck`
+- `pnpm test`
+- `pnpm lint`
+- `pnpm build`
+- `pnpm tsc --noEmit`
+
+## Suggested AGENTS.md sections
+
+- project purpose
+- important directories
+- install / build / test / lint commands
+- constraints on schema, dependencies, and generated files
+- validation order
+
+## Common guardrails
+
+- do not edit generated clients unless the task is specifically about generation
+- avoid lockfile churn unless dependencies truly changed
+- prefer targeted tests before full test suite
+- note whether e2e tests are slow or environment-dependent

he-maintainer/references/python.md

@@ -0,0 +1,33 @@
+# Python Harness Notes
+
+Use this reference for Python repositories.
+
+## Common files to inspect
+
+- `pyproject.toml`
+- `requirements.txt`
+- `poetry.lock`
+- `uv.lock`
+- `src/`
+- `tests/`
+- `tox.ini`
+- `noxfile.py`
+
+## Common validation commands
+
+Typical examples:
+
+- `pytest`
+- `ruff check .`
+- `mypy .`
+- `python -m build`
+- `tox`
+
+Prefer environment-specific commands already documented by the repo.
+
+## Common guardrails
+
+- avoid mixing package managers in guidance
+- be explicit about virtualenv or tool runner if required
+- note when tests depend on services, fixtures, or secrets
+- prefer local, minimal edits over package-wide rewrites

he-maintainer/references/rust.md

@@ -0,0 +1,28 @@
+# Rust Harness Notes
+
+Use this reference for Rust repositories.
+
+## Common files to inspect
+
+- `Cargo.toml`
+- `Cargo.lock`
+- `src/`
+- `crates/`
+- `tests/`
+- `rust-toolchain.toml`
+
+## Common validation commands
+
+Typical examples:
+
+- `cargo test`
+- `cargo build`
+- `cargo clippy --all-targets --all-features -- -D warnings`
+- `cargo fmt --check`
+
+## Common guardrails
+
+- do not casually update `Cargo.lock`
+- check for workspace crates before describing structure
+- prefer the smallest crate-local change that solves the task
+- distinguish unit, integration, and benchmark targets when relevant

he-maintainer/references/scoring-rubric.md

@@ -0,0 +1,51 @@
+# Harness Health Scoring Rubric
+
+Use this when asked to audit or score a repository's harness quality.
+
+## Dimensions
+
+### 1. Project map clarity
+- strong: key directories and entrypoints are documented and current
+- partial: some structure is documented but stale or incomplete
+- weak: little or no useful repo map exists
+
+### 2. Validation commands
+- strong: build, test, lint, and typecheck are clear and runnable
+- partial: some commands exist but are incomplete or ambiguous
+- weak: commands are missing, stale, or unverified
+
+### 3. Fast feedback
+- strong: targeted checks or quick tests exist
+- partial: only slower validation exists
+- weak: no obvious quick validation path
+
+### 4. Task templates
+- strong: reusable templates exist for common work types
+- partial: ad hoc instructions exist but are inconsistent
+- weak: every task must be reinvented
+
+### 5. Guardrails
+- strong: high-risk areas and forbidden changes are explicit
+- partial: some constraints exist but are vague
+- weak: almost no constraints are documented
+
+### 6. Doc-code alignment
+- strong: harness docs match the current repo layout and commands
+- partial: mixed accuracy
+- weak: obviously stale or misleading
+
+## Output format
+
+Keep the score compact. Example:
+
+- project map clarity: partial
+- validation commands: strong
+- fast feedback: weak
+- task templates: weak
+- guardrails: partial
+- doc-code alignment: partial
+
+Top priorities:
+1. Add a fast unit test or package-scoped validation command
+2. Refresh AGENTS.md directory map
+3. Document forbidden change areas