# Learnings & skills

# Learnings & skills

inline's [memory](./repo-memory.html) is what it figures out on its own. **Learnings** and **skills** are how *you* teach it — the difference being size and structure. A learning is a one-line rule; a skill is a documented pack of expertise.

## Learnings

A learning is a short, explicit convention inline applies on every review. Two ways they're created:

- **Taught** — comment `@inline learn <rule>` on a PR, and inline records it. ("We always use `zod` for request validation." "Never flag missing JSDoc.")
- **Proposed** — the [feedback loop](./feedback-loop.html) drafts a suppression rule when your team repeatedly dismisses the same finding pattern. These arrive **inactive**; an admin approves or deletes them.

Each learning carries:

| Setting | Meaning |
| --- | --- |
| **Rule** | The convention text inline applies during review. |
| **Scope** | This repository only, or the whole workspace. |
| **Source** | Whether you taught it, or the feedback loop proposed it from dismissals. |
| **Active** | Whether it's currently applied. |
| **Evidence** | For proposals, the dismissals that justified it. |

Manage them under **Learnings** in the portal: approve proposals, toggle active state, change scope, or delete. inline never activates a proposed learning itself — that's always a human decision.

## Skills

A skill is a larger, reusable unit of review expertise. Where a learning is a sentence, a skill is a document — the right home for domain knowledge like "how we review database migrations" or "our API-versioning rules."

Skills use **progressive disclosure** to stay cheap:

1. Every skill's **name and description** are always visible to the reviewer — a lightweight catalog it can scan on any PR.
2. The full **body** is loaded only when the reviewer decides that skill is relevant to the change in front of it.

So a repo can have many skills attached without every review paying to read all of them — inline pulls in only the ones a given PR actually needs.

### Authoring

A skill has a short **name**, a **description** (this is what inline matches against, so make it precise about *when* to use the skill), and a **body** of the actual guidance. Create and edit them under **Skills** in the portal.

### Attaching

- **Workspace-wide** — the skill applies to every repo in the workspace.
- **Per-repo** — attach a skill to just the repositories that need it.

Skills resolve the same way for both the PR review pipeline and the [MCP ad-hoc review](./mcp.html), so a skill you author improves reviews everywhere inline runs.

## Which to use

- A **rule** you can state in a sentence → a **learning**.
- A **body of knowledge** with structure, examples, and conditions → a **skill**.
- Something inline should discover and maintain itself → leave it to [memory](./repo-memory.html).