Deep dive · Cluster 3 of 3

Agent capability

Hooks, skills, and gates: the pre-configured discipline that ships with the environment, and why the discipline is the load-bearing feature. The case study shows what these produce in real project work.

The problem raw AI subscriptions do not solve

A group Claude or ChatGPT subscription gets you access, not a workflow. Every student prompts differently. No one enforces "read the project decisions page before writing," "file numerical claims with their corpus tag," or "commit the log entry as its own commit so git blame can trust the record." The AI's helpfulness ends up depending entirely on how well each user prompts it and how much project convention they hold in their head.

The wiki-grounded research agent's differentiator is that the discipline is in the artifact, not in each user's memory. The environment ships with pre-configured skills, hooks, and gates that carry the workflow. A new user does not need to know how to use the pattern correctly; the pattern's hooks tell the agent what to do at every step. What follows is the three concrete artifacts that make that true.

Skills: pre-configured procedures the agent runs

A skill is a Markdown file at .claude/skills/ that Claude Code auto-loads and consults when a task matches the skill's description. Each skill is a documented procedure: what the task is, what to capture, the step-by-step, what to skip, and how to report back. The base llm-wiki-memory-template ships three:

Skill	Description
`wiki-source`	Ingest a new source document (paper, article, design doc, README, external reference) into the wiki. Creates a source-summary page and links it into the existing wiki neighborhood.
`wiki-experiment`	File experiment results to the wiki following the SCHEMA Ingest procedure. Use after an experiment run produces metrics, ablations, or comparisons worth keeping as durable project memory.
`wiki-lint`	Periodic health-check for orphans, dead links, stale claims, missing frontmatter, and `untyped` placeholder pages.

Here is the actual frontmatter block from the wiki-source skill file:

---
name: wiki-source
description: Ingest a new source document (paper, article, design doc,
  README, external reference) into the wiki. Creates a source-summary
  page and links it into the existing wiki neighborhood.
---

The body underneath is an 11-step procedure the agent follows verbatim. It names the frontmatter fields to add, the typed edges to draw, the index category to update under, the log entry to append, and the verification step to run before commit. Excerpt from the actual procedure:

Step 3: Create a source-summary page named after the source. Frontmatter: type: source-summary, up: to the closest existing parent page, and source: set to a URL or filesystem path. Add supports: / criticizes: / extends: typed edges to other wiki pages where the relationship is clear.

Step 8: Append a ## [YYYY-MM-DD] ingest | Source title entry to log_<repo>.md. The first bullet is the attribution line - by: <name> via claude-code, where <name> is the output of git config user.name in the wiki repo (read it, do not invent it).

Two properties matter. First, the procedure is specific: it names frontmatter fields, categories, and file paths. No agent-judgment inserted where a rule is available. Second, it is uniform across users: every ingest done by every user in this environment goes through the same 11 steps. A new student running /wiki-source on their first paper produces a page indistinguishable from the tenth paper the senior postdoc filed, because both are following the same skill.

Case study tie-back. In the web_forager story, Chris Frederick's demo branch was filed as a wiki page not because he decided to be thorough, but because the ingest skill's procedure required it. The typed edges (extends: [[Experiment-7-Question-Deepen]], related: [[Experiment-8-Second-Entity]]) that later carried the audit cascade were in the frontmatter because the skill's step 3 said to add them.

Hooks: reminders and enforcements at session boundaries

A hook is a shell script that Claude Code runs at a specific event: SessionStart when a session begins, PostToolUse after every tool call, and others. The base template ships a SessionStart hook that solves the "the wiki exists but the agent forgot to check it" problem by loading three blocks of context at every session boot, before the user has typed anything.

Block 1: orientation reminder

Emitted verbatim on every session start:

<system-reminder>
This project uses the wiki at wiki/<repo>.wiki/ as durable memory.
It is a separate git repository with its own remote, NOT a subdirectory of
the main repo. Read SCHEMA_<repo>.md before non-trivial wiki edits.
Update the wiki proactively when experiment results, decisions, or
syntheses emerge.

Every wiki edit ends with a commit in the wiki's own repo:
  git -C wiki/<repo>.wiki add <files>
  git -C wiki/<repo>.wiki commit -m "..."
Run these without asking, local commits are reversible. Push only on
explicit request.

Slash commands available: /wiki-experiment, /wiki-source, /wiki-lint.
</system-reminder>

Block 2: the wiki index

Emitted after the reminder: the full contents of index_<repo>.md, so the agent sees the catalog of every wiki page with one-line descriptions before the first user turn. The hook's comment names the intent: with the index in context at turn 0, the agent answers wiki-pageable questions without an extra Read/Grep tool call. The wiki becomes memory, not search.

Block 3: the last 5 log entries

Emitted last: the tail of the wiki's log, so the agent knows what has happened recently and can pick up mid-thread without waiting for the user to summarize.

The cost is a few thousand tokens at session start, paid once. The payoff is that the agent enters every conversation already knowing the project's memory catalog and its recent history. No user needs to remember to say "check the wiki first."

A companion PostToolUse hook fires after tool calls and is where per-project verifications can attach. The two hooks together mean the wiki-first discipline is enforced by the harness, not left to prompt engineering.

Case study tie-back. When Chris Sweet opened a review session on the web_forager wiki, the SessionStart hook put the current index and the last 5 log entries in his session's context automatically. That included Chris Frederick's most recent ingest entry ("by: Chris Frederick via claude-code") flagging the demo branch as pageable content. Following the entry to Experiment-11-Productionization was one link away because the log had loaded it into context on session boot.

The verification gate: pre-commit checklist

The verification gate lives at wiki/agents/verification-gate.md. It is a procedural honesty check that runs against every wiki write, right before git commit. Every ingest skill (wiki-source, wiki-experiment, and any future write skill) invokes it as its penultimate step, before staging or committing.

The gate's criteria are organized in four categories. Concrete criteria shown; the full list lives in the template file.

Numerical claims

Every numerical claim is backed by a real script output, cached judge result, or external citation. Estimated or projected values are explicitly marked as such and tagged with the basis of the estimate.
Every numerical claim is tagged with its corpus / dataset / configuration scope. A bare "73.3%" is ambiguous; "73.3% on the 281-chunk gold-only corpus" is honest.
No cross-corpus gap arithmetic is presented as a direct gap. If page A reports X% on corpus 1 and page B reports Y% on corpus 2, the wiki must not state "(X − Y)pp gap" without a same-corpus measurement.

Cross-references and structure

Every new typed-edge reference in frontmatter is paired with a body-level back-reference on the target page. Broken back-references are not acceptable.
Every new body link [Display](Page-Name) resolves to an existing wiki page.
Frontmatter is valid YAML and includes type: and up:, plus any typed edges that apply.

Index and log

index_<repo>.md lists every new page in the right category with a one-line description.
log_<repo>.md has a dated entry covering this write, with 2 to 5 bullets of substance.

Honest reporting

Bad results, contradicted claims, and worsened metrics are filed truthfully. No polishing, no "needs more investigation" hedges that hide a real negative result.
No projection or speculation is filed as a measured fact.

The procedure is: re-read each page from disk (not from the in-context draft, which can hide edit-window artifacts), run the criteria top to bottom, fix and re-run on failure, only proceed to commit when every criterion passes. This is a sequential gate: no shortcuts.

Case study tie-back. The web_forager story is a live example of the honest-reporting criterion doing load-bearing work. The demo branch's reported coverage was 17/17. When Chris Sweet cross-referenced against the actual entity files, real evidence-based coverage was 8/17. Because the wiki's convention is "file the reported-vs-real table inline with the finding," the counter-evidence was visible on the same page as the claim, not hidden in a follow-up. The projection-as-fact failure mode was caught at read-time, not months later.

Discipline gates: rationalizations named in advance

The discipline-gates.md file names universally-wrong rationalizations the agent might use to justify a bad write, and pairs each with the counter that defeats it. Excerpt from the actual table:

Rationalization	Why it's wrong
"I'll add the corpus tag / frontmatter / cross-references later"	Later never comes. Do it now while context is fresh. Unindexed and untagged content drifts faster than it can be cleaned.
"The estimate / projection is fine to file"	Honest reporting is non-negotiable: numbers in the wiki must be backed by a real script output, a cached judge result, or an external citation. Projections must be marked as such, not slipped in as fact.
"The cross-corpus comparison is close enough to cite directly"	A gap arithmetic between rows on different corpora is not a gap. Tag every number with its corpus and refuse the direct subtraction.
"I have enough context, the log / index need not be read first"	Session-start ritual exists for a reason. Reading the recent log entries and skimming the index is the cheapest way to avoid contradicting yesterday's findings.
"Quick note, I'll wire it into the wiki later"	A wiki page without inbound links is invisible to retrieval. Inline back-references from related pages while writing, not after.
"Good enough to commit"	Verification before commit is non-negotiable. The Verification Gate is a small criteria list, running it costs seconds and catches the failure modes above.

The table exists because purely-declarative rules ("don't file projections as facts") fail: the agent rationalizes exceptions between lint passes. Naming the rationalization in advance turns the rule into something the agent recognizes as a red flag before writing.

The same file defines three gate types the environment uses:

Design Gate. Gather → Assess → Propose plan → Get approval → Execute. Used before any multi-step write where the layout decision is non-obvious.
Verification Gate. Create → Read back → Check criteria → Fix failures → Commit. Used before every wiki write. This is the pre-commit checklist above.
Sequential Gate. Step N must pass before step N+1 can begin. Used inside ingests where structural correctness must precede content review.

And a Skill Dependency Chain: when one skill runs, other procedures MUST also run. Not "should" — must:

When this runs...	...this MUST also run
Wiki experiment ingest	Verification Gate over the created/edited pages
Wiki source ingest	Verification Gate over the created summary
Any wiki write that introduces a new typed edge	Update the reciprocal edge on the target page
Any wiki write to a numbered claim	Append a dated update entry to the log

These are agent-agnostic. Every overlay (Claude Code, Cursor, future) references the same discipline-gates.md file rather than reimplementing its rules. When a new rationalization is added to the table, every overlay picks it up automatically. DRY from day one.

Domain-specific variants: extending the discipline

A variant template inherits everything above and adds its own domain-specific gates on top. The llm-wiki-proposal-template is a live example. Its proposal-edit skill inherits the base template's verification gate and adds proposal-writing refusals that make no sense outside a proposal-drafting context:

Unsourced numerical claims. The skill refuses to insert a percentage, throughput, or accuracy number into the proposal draft unless it is backed by a real experimental result or an external citation. Estimates get marked, not slipped in.
Numerical superiority claims over published baselines. Softens to "competitive with" until rigorous head-to-head benchmarks are captured in the wiki.
Auto-promoting a draft to canonical. The skill writes to _draft.docx. Renaming to the canonical filename is a human step, done after review in Word's Compare Documents. The skill will not do this automatically.
Auto-committing the main repo. The skill commits the wiki (for the audit trail) but never the main repo. Human review gates the main-repo commit.

The pattern is: the base template's discipline is universal; variants add domain-specific gates for the failure modes that variant sees. A future onboarding-template variant would add different refusals. A grant-authoring variant that files against agency-specific formats adds different index categories. The base template does not know about proposals; the proposal template does not have to know about generic wiki-lint. Placement stays clean.

Multi-AI: the same discipline across overlays

The verification gate, the discipline gates, and the write protocol are agent-agnostic policy files. Every overlay references them rather than reimplementing them. This is what makes the multi-AI story real rather than aspirational.

The Claude Code overlay installs skills under .claude/skills/ and hooks under .claude/hooks/. Its per-skill files reference wiki/agents/verification-gate.md at their commit step.
The Cursor overlay installs rules under .cursor/rules/wiki-*.mdc. Its per-rule files reference the same wiki/agents/verification-gate.md file.
The "none" overlay ships no per-agent files; the discipline is in CLAUDE.md and the SCHEMA for the agent to read directly.
A future OpenAI-family overlay installs whatever the platform supports, and references the same policy files.

When a Claude Code session and a Cursor session both write to the same wiki (as they can and do), both are held to the same gates. The by: <human> via <agent> attribution line on every log entry captures which tool did each write, so an audit of who claimed what and through which agent is one git log away. Vendor lock-in becomes a swap of the overlay files, not a re-authoring of the project's memory.

Raw AI subscription: every user prompts differently. Discipline lives in memory.

Configured environment: skills, hooks, and gates carry the discipline. Every session starts from a known baseline, every write goes through the same pre-commit check, and every overlay honors the same policy files.

The claim in one paragraph

The wiki-grounded research agent's differentiator is not that Claude is smart. It is that the environment codifies the discipline that keeps a shared wiki honest and useful under real project stress. Skills document the ingest procedures every user follows. Hooks put the wiki's memory in the agent's context at every session boot. The verification gate catches projection-as-fact and missing cross-references at write time. The discipline gates name in advance the rationalizations the agent might use to justify a bad write. Together they mean the pattern holds up in a real multi-author project, which the case study demonstrates on 15 rewrite passes of a live web-scraping project. When a new PI adopts this environment, they inherit the discipline; they do not have to invent it.