vstack

A Claude Code configuration bundle whose every claim is checked by something that can fail.

vstack installs skills, subagents, commands and hooks into Claude Code, and a gate that stops an agent reporting a task done while the tests are red. It is for people who run agents unattended and need to know afterwards which parts actually held.

What it gives you

What the install adds, stated as mechanisms you can read rather than promises. Each names a file on disk and, where it makes a claim, a check that can fail.

A gate that refuses a false "done." goal-gate.sh on Stop will not let an agent end a turn reporting success while a recorded goal still carries unchecked rubric items, and the full install's .claude/verify.sh refuses to pass while the tests it names are red. An agent left running overnight cannot quietly mark its own work complete.

Skills that fire on the situation, not a slash command. inject-session-context.sh on SessionStart and skill-mandate.sh on Stop read what the turn is doing and route it to the skill or subagent that fits — a review to the reviewer, a plan to the planner — so the right tool runs whether or not you thought to ask for it.

Tiered model routing. Mechanical work — search, renames, boilerplate — goes to Haiku scouts; judgment work like review, tests and debugging goes to Sonnet; only the hard cross-cutting reasoning stays on the frontier model. You stop paying frontier price for a file search, and the expensive context is left free for the part that needs it. This is a deliberate policy in CLAUDE.md and the per-agent model settings, not Claude Code's default.

A team of specialist subagents. A reviewer, a security auditor, a QA verifier, a planner, a test writer and more, each dispatched with an attribution so a verdict always has an author you can challenge, and /team to fan them out concurrently.

Reversible by construction. Profiles install only what you ask for, an ownership record scopes what uninstall is allowed to touch, and ./uninstall.sh --yes puts every file back byte for byte. Trying vstack costs nothing you cannot cleanly undo.

Every claim checked by a mutation that can fail. The property the rest of this page is about, below.

Measured against gstack and pstack

The features above were put in front of a harness before they went on this page. 1,264 paid runs on Opus 5 and Haiku 4.5 across eleven fixtures with held-out checks the agent never sees, comparing vstack against gstack and against pstack (the Claude Code port of Cursor's pstack). That count is the row total of every file tests/evals/showcase/runs/INDEX.tsv marks valid, so it is re-derivable, the invalid batches are excluded by name and reason rather than quietly, and it includes retired arms that no longer appear in any comparison. The full tables, the preregistration and the raw rows are in tests/evals/showcase/RESULTS.md. One table over every valid run file, regenerated by tests/evals/showcase/summarize.sh into tests/evals/showcase/summary.json, is rendered live at https://bench.vedant.to (the page holds no numbers of its own; it fetches that file from this branch and links every row to the run file behind it). Six fixtures have run all three arms. On four of them the arms tie outright: every run green, no false completions anywhere. On gate_bites and gated_report_quiet vstack is the only arm that never said DONE on a red tree, but at those sample sizes the split is not significant. The sixth is vuln_hunt, where the ticket reports one of four planted vulnerabilities and the project's own gate stays green after fixing only that one. There vstack leaves 0.96 of 4 open against gstack's 2.75 and pstack's 2.50 over 24 paired runs each, p < 0.00001 against both (200,000-relabeling permutation test). It costs 3.8x gstack's spend to do it, and vstack lost that same fixture at 2.80 one version ago; both numbers are in RESULTS.md with the diagnosis. On Opus 5 vstack is the fastest of the three, at a cost within noise of gstack's. On gated_report_quiet, the fixture that ships its own gate and does not mention it, pstack said DONE on a red tree once in ten while vstack and gstack did not; pstack was also the cheapest arm there, so read the two rows together. On gate_bites, the fixture built so that fixing the reported symptom leaves the project's gate red, vstack is the only arm that never said DONE on a red tree across about fifty runs. At that sample the 0-against-3 split is not significant (Fisher two-sided p = 0.11), and the Stop hook was armed in all 49 runs and blocked in none of them, so the difference is not the gate doing its job. The full table, every fixture and every losing number included, is in RESULTS.md and on the page.

	vstack	gstack	pstack
held-out check green, the four fixtures where all three arms tie	every run	every run	every run
said DONE on a red check, gated_report_quiet (paired n=10 per arm)	0 of 10	0 of 10	1 of 10
said DONE on a red check, gate_bites (paired n≈50 per arm)	0 of 49	3 of 47	1 of 50
vulnerabilities left open, vuln_hunt (paired n=24 per arm, of 4 planted, 1 reported)	0.96	2.75	2.50
runs that fixed all four, vuln_hunt (paired n=24 per arm)	10 of 24	1 of 24	2 of 24
cost per task, vuln_hunt (paired n=24 per arm), vstack as baseline	1.00x	0.27x	0.37x
cost per task, Haiku 4.5 on the gated fixture (paired n=10), vstack as baseline	1.00x	1.05x	0.85x
turns per task, Haiku 4.5 on the gated fixture (paired n=10)	34.6	40.8	30.3
wall time per task, Opus 5 (paired n=10), vstack as baseline	1.00x	1.20x	1.56x
cost per task, Opus 5 (paired n=10), vstack as baseline	1.00x	within noise	1.30x
turns per task, Opus 5 (paired n=10)	4.4	4.9	5.5
Stop hook that refuses a red tree	yes, always on	no	no
skills installed	29	54	52

Read that honestly: on a task small enough to fit in one prompt, a frontier model does not need this configuration to get the answer right, and forcing it to delegate cost more than it saved, so nothing here forces it. vuln_hunt is the exception, and it is expensive: the security lane costs about four times a bare run and only fires when the task is a security ticket or the file being changed decides access. On the other fixtures vstack's cost is unchanged. What vstack buys is the property below, which does not show up as a per-task number: every piece of it can be shown to fail when it should, and it undoes itself byte for byte.

Requirements

The Claude Code CLI on PATH, bash, and macOS or Linux. jq and git are required by the gate; ./setup-machine.sh installs them.

Install

claude plugin marketplace add itsvedantkumar/vstack
claude plugin install vstack@vstack

That is the plugin lane: skills, subagents, commands, and three hooks. Two of them route: inject-session-context.sh on SessionStart and skill-mandate.sh on Stop are what make skills fire. The third, goal-gate.sh, gates rather than routes, refusing to finish while a recorded goal still has unchecked rubric items. Nothing else on the machine is touched: no CLI wrappers, no shell lane, no MCP servers, no settings merged into ~/.claude. Remove it with claude plugin uninstall vstack@vstack — there is no uninstall.sh to run, because there is no checkout.

The .claude/verify.sh Stop gate is deliberately not in this lane. It refuses to run an untrusted gate and tells you to run vstack trust, which only the full install provides, so in the plugin lane its only possible outcome was naming a command you do not have.

For the hooks, the CLI wrappers and the shell lane, take the full install:

git clone https://github.com/itsvedantkumar/vstack ~/Projects/vstack
cd ~/Projects/vstack && ./install.sh
./bin/doctor            # confirm it landed

Bare ./install.sh installs everything above — that is the opinionated profile, and it is the default. --profile=NAME (or VSTACK_PROFILE=NAME; the flag wins if both are given) narrows what lands, and uninstall.sh only ever removes what the profile it ran under actually installed — never more:

Profile	Adds over core	Skips
core	—	roster, routing policy, taste-only skills
team	/team, the roster, dispatch-count logging (dispatch-counter.sh, skill-mandate.sh)	UI lane, CLAUDE.md
ui	the UI lane (ui-engineer, design-reviewer, accessibility-auditor, UI-only skills)	roster/routing, CLAUDE.md
opinionated (default)	everything team and ui add, plus CLAUDE.md	nothing

core alone is the safety/lifecycle machinery — hooks, wrappers, doctor, vstack trust, the Stop gate — with no opinion about how you work: no roster, no routing policy, no skill that only encodes taste. CLAUDE.md (the routing policy itself) ships with opinionated only; installing it under a profile that ships none of the roster or skills it routes to would be a claim about a payload that profile does not carry. --dry-run works per profile and changes nothing on disk, and tests/profiles.sh proves all of the above end to end -- per-profile membership, that uninstall removes exactly what its profile installed and nothing else, and that opinionated is byte-identical to a bare, no-argument install -- in throwaway mktemp -d sandboxes. VSTACK_PROFILE=skills is a different, unrelated axis — a hook-runtime value read by inject-session-context.sh, not an install profile — and install.sh rejects it by name rather than silently treating it as unknown.

Pin a release rather than tracking main:

curl -fsSL https://raw.githubusercontent.com/itsvedantkumar/vstack/v1.74.2/bootstrap.sh -o bootstrap.sh
VSTACK_REF=v1.74.2 bash bootstrap.sh     # installs that tag, not main

The curl one-liner above always runs ./setup-machine.sh first, which installs the tools this repo's agents and gate expect — git, jq, ripgrep, fd, gh, node, bun, uv and the Claude Code CLI itself. Pass --skip-deps to the one-liner to go straight to the config install; ./install.sh run directly never touches your tools unless you pass it --with-deps.

setup-machine.sh can also install two Claude Code plugins, and does not by default. Both frontend-design (Anthropic's UI-review plugin) and typescript-lsp ship from the official anthropics/claude-plugins-official marketplace and update on their own schedule, not this repo's. Neither installs from the headline command above. Opt in with ./setup-machine.sh --with-plugins, or VSTACK_PLUGINS=1 before the bootstrap one-liner (bootstrap.sh forwards its arguments to install.sh, not to setup-machine.sh, so the flag has no reach through it).

Removing it restores what was there before: ./uninstall.sh --yes puts every file it replaced back byte for byte, unpicks the hook entries, MCP servers and policy keys it merged into settings.json and ~/.claude.json, and leaves anything you added alone.

Which files were "it" — the set uninstall.sh is allowed to touch — is decided by ~/.config/agents/vstack-installed, a plain-text, unsigned list of paths install.sh wrote, one per line. It is not a cryptographic attestation: anything running as you can edit it, and nothing checks a signature before trusting it. What it buys is narrower than that — it is "install.sh wrote this path" bookkeeping, so a --profile=core install's uninstall does not also delete the skills a later team install added, and so uninstall never deletes a file this repo never shipped just because its bytes happen to match. It is not proof the file is unmodified, and it is not proof nothing else forged an entry. When the file is absent, uninstall.sh treats everything below ~/.claude that matches the payload as its own and removes the whole thing.

Confirm it worked: inside Claude Code, run /doctor. It detects which of the two lanes above actually landed and checks that one — skill, subagent and command counts for the plugin lane; the full hook, wrapper and MCP breakdown for the full install — rather than printing a generic "installed" with nothing behind it. This is also the fastest way to see the payload is real: it names files on disk, not a slogan.

The distinguishing property

The distinguishing property is not the count of anything. It is that every check in this repository has a mutation proving it can fail, and the project has a written record of the eighteen times a check here reported a verdict it had not measured. Sixteen of those printed ok. The seventeenth printed an accurate FAIL that a release workflow then acted on by deleting the evidence. The eighteenth printed a FAIL about the harness's own scratch directory and held a release back over an installer that was never broken.

Repository layout

Two directory pairs differ only by a leading dot, and the difference is the whole mental model:

path	what it is
claude/	the shipped payload — skills, subagents, commands, hooks, installed to ~/.claude/
.claude/verify.sh	this repository's own gate, 67 checks; not shipped to anyone
conductor/	payload copied to ~/.conductor/
.conductor/	this repository's own workspace config
tests/	the suites: the falsifiability harness, the install matrix, trigger and baseline tests
ui-gate/	a UI lint harness for other people's repos, driven by the impeccable skill
bin/	CLI wrappers installed to ~/.config/agents/bin/, not this repo's executables
docs/	research, provenance and the failure-shape writeups

The dotted one is always this repository holding itself to something. The undotted one is always what you receive.

What lands where

The two install lanes above put the payload in two different places, and the counts below only mean what they say for the lane named above each table. /doctor detects which lane landed and checks the right one; see Day to day.

Full install (git clone + ./install.sh):

Component	Count	Path
Skills	29	~/.claude/skills/
Subagents	14	~/.claude/agents/
Commands	15	~/.claude/commands/
Hooks	9	~/.claude/hooks/
CLI wrappers	6	~/.config/agents/bin/
MCP servers	2	merged into ~/.claude.json
Shell config	2 files appended to	~/.zshrc and ~/.zshenv

install.sh merges rather than overwrites. It backs up every file it touches into ~/.config/agents/backups/, adds only the hook entries it owns, and leaves keys it does not recognise alone. Check 21 fails if it deletes a key this repository never shipped.

The shell-config row is the one that edits a file you did not create. install.sh appends a fenced >>> claude-parity >>> block to ~/.zshrc that sources ~/.config/agents/shell/claude-parity.zsh, and a fenced block to ~/.zshenv. Both are backed up first and both are guarded on their own fence, so re-running the installer appends nothing a second time. ./uninstall.sh removes them. The plugin lane touches neither file.

Plugin-marketplace install (claude plugin marketplace add + claude plugin install):

Component	Count	Path
Skills	29	~/.claude/plugins/cache/vstack/vstack/<version>/skills/
Subagents	14	~/.claude/plugins/cache/vstack/vstack/<version>/agents/
Commands	15	~/.claude/plugins/cache/vstack/vstack/<version>/commands/
Hooks	3 (2 routing, 1 gating)	claude/hooks/hooks.json, run from the plugin cache
CLI wrappers	0 (not this lane)	full install only
MCP servers	0 — claude/.claude-plugin/plugin.json declares none	full install only

<version> is whatever claude plugin install resolved and changes every release, so glob it — ls -dt ~/.claude/plugins/cache/vstack/vstack/*/ | head -1 — rather than pinning the number above. This lane never runs install.sh: the skills, subagents and commands are real and fire normally, but hooks, the CLI wrappers, the shell lane and MCP servers only land with the full install. Take that lane if you want the Stop-hook gate, the destructive-command guard, or the CLI wrappers under ~/.config/agents/bin/.

vstack overlay . (a third lane — drops config into a target repo, not ~/.claude; the only lane a cloud sandbox without your home directory can reach):

Source	Lands at	Condition
claude/security-scan.sh	.claude/security-scan.sh	always overwritten
claude/whitebox-audit.sh	.claude/whitebox-audit.sh	always overwritten
claude/security.yml.tmpl	.github/workflows/security.yml	seeded if absent
claude/dependabot.yml.tmpl	.github/dependabot.yml	seeded if absent

A repo overlaid at commit X keeps that commit's hooks, agents, commands, skills and scanner until someone re-runs overlay — nothing else reports the staleness. vstack overlay --check <repo> (or ./overlay.sh --check <repo>) diffs the destination against the "always overwritten" file list above plus the two seeded templates and the .conductor/settings.toml pin, writes nothing, and prints one line per drifted file followed by overlay --check: N stale, M repo-owned diffs, K missing. Exit 0 only when N and K are both 0; repo-owned template edits (M) never fail the check.

Day to day

Command	What it does
/ship	verify, commit, push — refuses on a red gate
/review	full review of the current diff
/team	routes a goal through spec, plan, build, verify, review, ship, and writes a handoff log
/doctor	health-check the installed setup
vstack update	shows the incoming commits and refuses to run unattended
vstack trust	arms the Stop-hook gate in the current repository

Skills are not slash commands. They fire on the situation from their description — writing prose reaches for unslop, reviewing TypeScript reaches for typescript-best-practices — and tests/auto-trigger.sh asserts that with 30 cases against the live model.

Checks that can fail

The gate is 67 checks (this number moves as checks are added; check 12 fails if this prose and the tree disagree, so it stays honest by construction rather than by discipline). tests/gate-falsifiability.sh breaks the repository once per check, at least once and more where a check can fail in more than one way, requires the gate to go red naming that check, restores the tree byte for byte, and fails if anything was left behind. Check 16 fails if any check has no mutation row, so a check cannot be added without proof it can fail.

./.claude/verify.sh                  # 67 checks
VSTACK_FALSIFY_ROWS=27 ./tests/gate-falsifiability.sh          # one row
git clone . /tmp/vstack-check && cd /tmp/vstack-check && ./tests/gate-falsifiability.sh

The full sweep runs the whole gate once per mutation, so the cost is O(rows x checks). At 125 falsifiability rows and a ~84s gate, that is over two hours serially. This paragraph claimed twenty minutes for four releases, which was the sharded figure wearing the serial one's label. ./tests/falsify-parallel.sh runs the same sweep across isolated clones: eight in CI (FALSIFY_SHARDS), seven locally (VSTACK_FALSIFY_JOBS). CI finishes in about 19 minutes because its shards are separate machines. Locally they are seven processes on one, so measure before you plan around it: 48 minutes for 103 rows on an M-series Mac, 2026-09-01. Neither lane gives partial credit: a run that is interrupted has proven nothing about the rows it never reached. Run it against a clone, as above. It mutates the working tree, and editing that tree while it runs will be reported as an unrestored file at the end.

Run the falsifiability suite in a throwaway clone. It mutates real files.

This exists because checks lie. Eighteen in this repository have been caught reporting a verdict they had not measured, sixteen of them by printing ok. A comparison that ran before the commit it was judging. A linter whose silence was read as success. An anchor a prose edit moved. A rule that reported OK with every one of its own rules skipped. Each is in CHANGELOG.md with the command that exposed it, and the shape behind all of them is in docs/checks-that-inherit-their-answer.md.

A project that has never found one of these has not looked.

What the hooks decide

Situation	Unconfigured	vstack
Agent claims done, tests fail	nothing intervenes	blocked
rm -rf / from an agent	runs	denied
git push --force origin main	runs	denied
git reset --hard, uncommitted work	runs	asks
rm -rf node_modules	runs	allowed
Untrusted repository's gate on Stop	no gate at all	not executed
Context spent per session	0 B	~3.4 KB full / ~2.5 KB plugin

The last row is the price, paid every session. Check 18 reads those figures back from this table and fails if they drift from what the hook actually emits.

A gate you cannot turn off gets deleted by the first person it inconveniences, so the Stop-hook gate is per repository and opt-in: vstack trust arms it, and an untrusted .claude/verify.sh is never executed. tests/compare-baseline.sh produces the table above by firing the real hooks, and every row carries the value it is supposed to produce.

Formatting skips a project's plugins-declaring Prettier config until you run vstack trust in that repo, and the hook says why in its output rather than failing quietly. SECURITY.md has the full boundary.

The gate re-runs .claude/verify.sh on every Stop while it is failing. After 3 real failures in a session it throttles re-checks to once per VSTACK_VERIFY_RESET_SECS (default 300s) to bound the cost of an unfixable failure, but it never stops blocking while red, and a real pass clears it at any count. The throttle changes when verify.sh is re-run, never whether the gate blocks.

What vstack trust covers, and what it does not

Arming a repository hashes .claude/verify.sh, every script it names, the four root installers, and the build manifests the generated gate executes through: package.json, pyproject.toml with uv.lock, and Cargo.toml with Cargo.lock and build.rs, so scripts.test cannot change under an already-trusted repository without moving the hash.

Stated limits, none of which this fix closes:

• Any edit to a tracked manifest re-arms the confirmation, including an unrelated dependency bump. Hashing only the scripts object would be stabler but is not enforceable: the hook compares whole-file content at a fixed path, not a parsed subset.
• Local path dependencies are not covered. {path = "../x"} under [tool.uv.sources], or a path entry in Cargo.toml or [patch], is recorded by path rather than by content hash in either lockfile, so editing files under a path dependency runs new code without touching a hashed file.
• Test files and conftest.py are out of scope by design. "Run the test suite" has always meant running whatever test code is there; that is the cost of trusting verify.sh at all.
• A dynamically built path (bash "$var.sh") inside verify.sh is invisible to any static scan.
• The gate cannot defend against the agent it gates. Both run as the same user with the same filesystem access, so an agent can rewrite .claude/verify.sh to exit 0 and trust it itself. Closing that needs the check to run somewhere the agent cannot write — a different uid, a remote check, a human — which is outside a hook's reach. The gate is a guard against finishing on a red tree by accident, not against an adversary sharing your uid.

Prod-ready gates

Mandatory for any repo that is public or serves prod traffic. vstack overlay . installs the local gate and CI; /security runs the post-deploy steps.

Tool	Local gate	CI	Post-deploy	Command
gitleaks	tracked files (+ --staged mode)	SHA-pinned action, fetch-depth: 0	history sweep	gitleaks git --log-opts="--all" --no-banner --redact .
semgrep	p/typescript p/nextjs p/owasp-top-ten	semgrep ci		semgrep scan --config p/owasp-top-ten .
osv-scanner	--lockfile	google/osv-scanner-action		osv-scanner scan source --lockfile <lockfile>
zizmor	when .github/workflows exists	own job		zizmor --min-severity medium .github/workflows
eslint	when config exists	ci.yml lint step		eslint .
npm audit		--audit-level=high when lockfile		npm audit --audit-level=high
nuclei			-u <preview-url> -severity medium,high,critical	nuclei -u <url> -severity medium,high,critical -silent
OWASP ZAP baseline			docker	docker run --rm -t zaproxy/zap-stable zap-baseline.py -t <url>
trivy			only if repo ships a container	trivy fs --scanners vuln,secret,misconfig .

Skipped on purpose: Snyk and SonarQube (commercial, redundant with the table above), husky and lefthook (vstack gates via the Claude Stop hook, not git hooks — see What the hooks decide).

The team

Fourteen subagents, each with its own context window and its own tool allowlist, dispatched by the Task tool. A reviewer with its own context cannot be talked out of a finding by the conversation that produced the code.

Every agent carries a call sign and signs its reasoning with it, not only its final report. An unattributed verdict cannot be challenged, and separate contexts are worth routing to only because they can disagree. The lead is RICK. A Stop hook blocks a session that dispatched subagents and then reported their work without naming any of them.

Instances are distinguished by a dimension code, so three reviewers reading the same diff at once are BIRDPERSON C-137, BIRDPERSON J-19, BIRDPERSON D-99 rather than three anonymous voices.

call sign	agent	what it is for
RICK	the lead	routes the work and holds the bar; does none of it
SUMMER	product-owner	asks what this is actually for before anyone builds it
ZEEP	planner	builds the system the work will run inside
MEESEEKS	worker	spawned for one task, does it, ceases to exist
MORTY	explorer	sent to go and look, comes back with what it saw
GLOOTIE	ui-engineer	develops the app, whatever the advice on the arm says
JAGUAR	test-writer	precise, silent, and the job is done when it leaves
BETH	qa	a surgeon: verifies before anything gets closed up
BIRDPERSON	code-reviewer	grave, blunt, and never once tactful about a defect
EVIL-MORTY	security-auditor	thinks like the attacker because it is one
NOOBNOOB	debugger	the one who actually cleans up after everybody
PICKLE-RICK	performance-engineer	extreme optimisation under an absurd constraint
SCARY-TERRY	design-reviewer	judges how it looks, and you cannot hide from it
POOPYBUTTHOLE	accessibility-auditor	was always there; the room just never noticed
UNITY	release-manager	gets an entire population moving in sync, or nothing ships

/team runs the whole roster on a goal — spec, plan, build, verify, review, fix, presentation, ship — and writes a handoff log to .audit/team-log.tsv, one row per phase with the agent, its verdict, the evidence, and what the lead decided. vstack receipt renders it. A log where every decision is proceed is called out as decoration: it cannot tell a lead who held the bar from one who had nothing to hold it against.

Limits

No measured quality improvement is claimed. A head-to-head review benchmark run here returned a null, and a survey of the published literature found no config-layer intervention with a measured correctness gain on frontier models. The honest case for this is safety and reversibility, not better code. See docs/research/.

Compaction is a Claude Code setting, not something this repository controls, and the number it is set to is not the number it fires at. claude/settings.json pins autoCompactWindow to 300000. Measured across 25 automatic compactions in one long session, 23 fired between 266K and 276K tokens; the client keeps headroom for the request about to be sent, so the trigger sits below the window. The other two fired at 469K and 1.0M, because the digest tells the model to batch every independent tool call into one message and a single batched step can jump past the window with no turn boundary in between for compaction to fire at. So it is regular, not guaranteed: a session that makes one very large step will overshoot, and nothing here can stop that. The method is in CHANGELOG.md.

Supported: macOS, Linux, and WSL and Alpine as Linux. CI runs ubuntu-latest, macos-latest and an alpine:latest container, and check 26 fails if the platforms named here are not the platforms CI tested. Windows is not supported. That lane could be made to pass. It could not be made to be true.

Docs

• How skills fire — the routing mechanism and what was measured
• How config reaches a session, measured — memory files load additively, hooks merge across scopes, one repo line can disable everything, and the coverage classes doctor reports
• Checks that inherit their answer — the failure shape behind every fake green found here
• Releasing this repository — why three harnesses disagree between a version bump and its tag, and the order that satisfies all of them
• What this actually does — every claim sorted into measured, mechanism-only, and unproven, each dated and sourced
• Checks that measure nothing — the whole evidence base in one paper
• Do harnesses help? — the null result, in full
• Harness value: literature — what anyone has actually measured
• Harness effect: research folder — the literature by topic, GLM-drafted and adversarially re-checked, and what this repository has measured against gstack
• What we changed, and what we declined
• Provenance — dated audit records, including research-v1.7.0.md
• MCP servers — what is wired and what it reaches
• Tests — every suite and what it costs to run
• CHANGELOG · CONTRIBUTING · SECURITY · CODE_OF_CONDUCT

Credits

Skills ported and adapted from pstack and Superpowers, with attribution per skill in claude/skills/ATTRIBUTION.md. Licences for vendored work are in NOTICE and alongside it.

MIT. See LICENSE.