Learnings & skills

inline’s memory 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 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:

Every skill’s name and description are always visible to the reviewer — a lightweight catalog it can scan on any PR.
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, 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.