Usable

View saved version →

---
name: usable-knowledge-capture
description: Capture a verified outcome back into Usable so the next person or agent does not rediscover it. Use after fixing a non-obvious bug, making an architectural decision, finishing an incident investigation, or discovering a constraint that cost real time. Requires the outcome to be verified first, prefers updating an existing item over creating a duplicate, and always asks before writing.
---

# Usable knowledge capture

Knowledge that stays in a chat transcript is lost. This skill writes verified outcomes into
Usable so the next person does not pay the same debugging cost twice.

## Preconditions

Do not write anything until all four hold:

1. **The outcome is verified.** Tests passed, the behavior was observed, the fix is confirmed
   in reality — not predicted. An unverified guess written into durable knowledge is worse
   than no knowledge at all, because it will be trusted later.
2. **Write tooling is available and authorized.** If the Usable MCP server is missing or
   unauthenticated, say so and offer the content for the user to save manually.
3. **The user has confirmed.** Show what you intend to write and where, and wait for a yes.
4. **It is worth keeping.** See the bar below.

## What is worth capturing

Capture when the answer was expensive to find and would be expensive to find again:

- a bug whose root cause was not obvious from the symptom
- an architectural decision, including the options rejected and why
- a constraint discovered the hard way — an API limit, a schema quirk, an ordering
  requirement
- an incident: what broke, why, how it was diagnosed, what fixed it
- a repeatable procedure that took several attempts to get right
- a hypothesis that measurement killed; negative results save the next person a day

Do not capture:

- routine changes obvious from the diff
- restatements of public documentation
- anything unverified
- transient state ("the build is currently red")
- content containing secrets, personal data, or customer data

## Update before you create

Search for existing coverage first. Duplicates fragment the corpus and cause exactly the
conflicting-guidance problem the retrieval workflow has to spend effort resolving.

- Same topic, still accurate, new detail → update it.
- Same topic, now wrong → update it and state what changed and when.
- Genuinely new topic → create, and reference related items.

Prefer one good item that gets maintained over three partial items that rot.

## What to include

- **Title** — specific enough to recognize in a search result. "Badge print claim returns
  500 because FOR UPDATE cannot be used with LEFT JOIN" beats "Fixed printing bug".
- **Context** — the symptom as it was first observed, and where.
- **Root cause** — the actual mechanism, not just the change made.
- **Resolution** — what fixed it, and why that works.
- **Verification** — how you know. Name the tests, commands, or observations.
- **Metadata** — repository, branch, version, or release, when known.
- **Residual risk** — what remains untested or uncertain.
- **Tags** — repository and domain tags so the item is findable later.

Write for a reader who has none of the current conversation's context.

## Before writing: redact

Strip access tokens, API keys, passwords, connection strings with embedded credentials,
internal-only URLs, personal data, customer data, and raw logs containing any of those.
Describe the shape of a value instead of reproducing it.

## Confirmation

Always show the plan and wait:

> I'd like to record this as a solution titled "<title>" in <workspace>, tagged
> `<tags>`. It covers the root cause, the fix, and the verification steps. Save it?

If write tooling is unavailable, say so and hand the content over instead:

> I can't write to Usable — no authorized write tool is configured. Here is the content if
> you'd like to save it yourself: ...

Never write silently, and never treat an earlier "yes" in the conversation as blanket
app

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: usable-knowledge-workflow
description: Ground work in existing team knowledge from Usable before proposing or implementing anything. Use at the start of any implementation, debugging, architecture, review, or "how do we do X here" task, and again whenever scope expands or confidence drops. Retrieves complete sources, ranks them by verification status and freshness, separates evidence from assumptions, and requires verification before success is claimed.
---

# Usable knowledge workflow

Your prior assumptions about a codebase are the least reliable input available to you. This
project keeps its decisions, standards, incident history, and proven solutions in Usable.
Read them before you write anything.

## When to run this

Run it at the start of a task and again when the task changes shape:

- before proposing an approach, a design, or a diff
- before answering "how do we do X in this project"
- when you hit an error whose cause is not obvious from the stack trace alone
- when scope expands beyond what you originally searched for
- when two sources disagree, or a source looks stale

Do not run it for pure syntax questions, arithmetic, or work fully specified by the user.

## The loop

### 1. State the task

Before searching, name four things explicitly:

- the outcome the user wants
- the repository, service, or surface involved
- the domain (auth, billing, ingestion, UI, infra, ...)
- the decision you are about to make on the user's behalf

Vague inputs produce vague retrieval. If you cannot name the decision, ask.

### 2. Search Usable first

Use the Usable search tools with a descriptive, natural-language intent — not keywords.
Describe what you are trying to accomplish as if briefing a knowledgeable colleague.

Good: "How does this service authenticate machine-to-machine callers, and what did we
decide about API key rotation?"

Bad: "auth api key rotate"

Scope the search to the relevant workspace. Add repository tags when they sharpen results,
and drop them when coverage looks thin. Iterate until the results stop improving or the
tool reports it has enough; then stop. If a search tool signals that it has hit an
invocation limit, stop calling it and record the gap instead of looping.

### 3. Retrieve complete sources

Search results are pointers, not evidence. Fetch the full content of every item you intend
to rely on. Do not build a plan on a summary, a title, or a similarity score.

### 4. Rank what you found

Prefer, in order:

1. items marked verified over unverified claims
2. items that match the current repository and branch state
3. items that match the version actually deployed
4. recent items over old ones — treat anything older than about 90 days as suspect
5. specific items over general ones

### 5. Surface conflicts and staleness

If two sources disagree, say so and name both. If a source describes code that no longer
exists, say so. Do not silently pick a winner, and do not average conflicting guidance
into something neither source said.

### 6. Write a knowledge receipt

Before implementing, produce a compact receipt. Keep it short — this is a checkable
artifact, not an essay:

```
Sources:     <titles + IDs actually read, with dates>
Constraints: <rules, standards, prior decisions that bind this work>
Assumptions: <what you are assuming because no source covered it>
Gaps:        <what you looked for and could not find>
```

The Assumptions and Gaps lines are the important ones. An empty Assumptions line on a
non-trivial task usually means you have mislabelled assumptions as facts.

### 7. Implement against the evidence

Plan and execute using what you retrieved. When you deviate from a documented standard,
say that you are deviating and why.

### 8. Verify before claiming success

"Done" is a claim about reality, so it needs evidence:

- ran the tests, and they passed — not "this should pass"
- read the tool output, rather than assuming the tool succeeded
- checked the behavior the user actually ca

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.