compound
Use when the user explicitly asks to save, curate, or consolidate what was learned, or closes a meaningful knowledge-work session. Not for remote, publish, deploy, or irreversible changes.
Install
npx skills add https://github.com/OutlineDriven/outline-driven-development/tree/main/.devin/skills/compound
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install outlinedriven-outline-driven-development@llmmart
git clone https://github.com/OutlineDriven/outline-driven-development.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole outlinedriven/outline-driven-development collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Knowledge compound
Contract
| Field | Bound contract |
|---|---|
| Trigger | User explicitly asks to save, curate, or consolidate what was learned, or closes a meaningful knowledge-work session. |
| Authority | Reversible local: writes only docs/solutions/.md records and repo-root CONCEPTS.md; rollback is version control. No remote mutation. Never silently deletes stale entries. |
| Side effect | Writes typed docs/solutions/.md records and repo-root CONCEPTS.md; may update stale entries, but never silently delete them. |
| Done | At most three specific typed learnings or an honest none are proposed; duplicates and contradictions are checked; the user approves; saved records carry type, retrieval tags, confidence, date, source, Context, and Implication; confirmation names retrieval tags. |
Inputs
- Session transcript (required): the accumulated context of the current session, from which learnings are extracted.
- docs/solutions/ directory (optional): the shared learning-doc store, also written by
autolearn. An absent directory counts as an empty store and is created on the first approved write.
Procedure
- Scan docs/solutions/ recursively (
**/*.md, excludingREADME.md) for existing records. Load each record and extract its frontmatter tags, type, and source. Records written byautolearnlive in category subdirectories and carry its own schema; read them for overlap, never rewrite them to this schema. Done when: every existing record is loaded with its frontmatter. - Check for stale and conflicting entries: compare the extracted tags of each existing record against the candidate learnings. An entry is stale when its tags overlap with a new candidate and its content contradicts or supersedes the candidate. An entry conflicts when it shares tags but states the opposite. Flag each stale or conflicting entry by name with the overlap reason; do not delete or overwrite it. Done when: every stale or conflicting entry is flagged by name with its overlap reason.
- Propose at most three specific learnings drawn from the session transcript. Classify each with a type (e.g., pattern, caveat, reference, decision, concept, fix, lesson). Reject a fourth or fifth as scope creep; propose none if the session yielded no durable learning. Done when: at most three learnings are proposed with types, or an honest none is proposed.
- For each proposed learning:
- Check against the stale-knowledge inventory: if a duplicate or contradiction exists by shared tag, flag it explicitly rather than overwriting. Done when: the duplicate or contradiction is flagged or none exists.
- Assign retrieval tags, confidence level (high/medium/low), date (ISO 8601), and source context. Done when: tags, confidence, date, and source are assigned.
- Draft frontmatter per the Record schema below: type, tags, confidence, date, source, Context (what triggered the learning), Implication (what changes as a result). Done when: frontmatter is drafted with all seven fields.
- Present the proposed records to the user for approval. Include the stale/conflict flags so the user can decide whether to update, merge, or consolidate. Done when: the proposed records and flags are presented for approval.
- On user approval: write each approved record to docs/solutions/.md using the drafted frontmatter and a prose body derived from the session. If a record updates or consolidates an existing entry, preserve the original entry's history line. Done when: every approved record is written with valid frontmatter and history preserved.
- Confirm completion by naming the retrieval tags for each saved record. Done when: the retrieval tags for each saved record are named in the confirmation.
Failure and recovery
| Failure class | Result |
|---|---|
| docs/solutions/ exists but is unreadable | Block: skill cannot execute; report the path and the read error. |
| User rejects all proposed learnings | Non-converged: nothing is written; report "No knowledge records saved." |
| Write fails (disk error, permission) | Rollback: do not leave a partial record; report the error and the record that failed. |
| Duplicate tag detected, user unresponsive | Non-converged: do not write; confirm explicitly before proceeding. |
Output
Markdown files written to docs/solutions/ (or the configured directory), each with frontmatter (type, tags, confidence, date, source, Context, Implication), plus a terminal confirmation naming retrieval tags for each saved record.
Record schema
Canonical frontmatter contract for docs/solutions/{slug}.md records. All seven fields are required.
| Field | Type | Description |
|---|---|---|
type |
string | Learning type: pattern, caveat, reference, decision, concept, fix, lesson. |
tags |
array[string] | Retrieval keywords, lowercase and hyphen-separated. Used for duplicate and contradiction detection. |
confidence |
enum | high, medium, or low. |
date |
string | ISO 8601 date (YYYY-MM-DD). |
source |
string | Where the learning originated: session context, PR, issue, or codebase area. |
Context |
string | What triggered the learning: the situation or problem that produced it. |
Implication |
string | What changes as a result: the actionable consequence of the learning. |
Body
Prose body derived from the session, expanding on Context and Implication with the substance of the learning. No fixed section structure; let the learning shape dictate the prose.
Filename
{slug}.md: a sanitized, descriptive slug derived from the learning's core idea. No date suffix (the date field carries that).
YAML safety
Wrap array items in double quotes when a value starts with any of: ` [ ] { } , * & ! | > % @ ?. Also quote when a value contains ": ". Scalar fields have a separate failure mode: an unquoted # truncates at the comment, an unquoted : reframes as a mapping.
Consolidation
When a new record supersedes or contradicts an existing entry (flagged in step 2), the user may approve a consolidation: merge the new record into the existing file, preserve the original as a history line, and update the frontmatter date and Context/Implication to reflect the consolidated state. Never silently delete the superseded entry.
Vocabulary capture: CONCEPTS.md (optional)
When a durable project term with a precise local meaning surfaces during curation, reconcile CONCEPTS.md per references/concepts.md. The glossary is a shared surface; follow the one-definition-per-concept discipline. This is optional and never blocks the primary curation flow.
Files (outline-driven-development)
-
agents
-
openai.yaml 192 B
interface: display_name: "Compound" short_description: "Use when the user explicitly asks to save, curate, or consolidate what was learned, or closes a meaningful knowledge-work session."
-
-
references
-
concepts.md 6.3 KB
# `CONCEPTS.md` vocabulary rules Sync-lineage note: `skills/autolearn/references/concepts.md` is the sibling file. It contains autolearn's independent entry schema and reconciliation model for the same `CONCEPTS.md` surface; it is not a copy of this file. Don't merge them. `CONCEPTS.md` defines words with codebase-specific meanings. It is a shared reference that `docs/solutions/` and AGENTS.md can cite without redefining those words. The file lives at the repo root. Terms enter through accretion or seeding, as described below. Create the file when either path first produces a qualifying entry. ## How terms enter: accretion and seeding Two paths populate the file, and they cover different gaps: - Accretion: a learning surfaces a term whose meaning wasn't obvious, so it gets defined. This reliably catches *peripheral* terms, because friction is what surfaces them. - Seeding: a run proactively defines the **core domain nouns** of the area it is working in. This catches the *stable-central* terms accretion never reaches: the nouns a system is built around rarely break, so they rarely appear in a learning, yet they are exactly what a reader needs to orient. Without seeding, the file fills with peripheral mechanics and never names what the project is about. ### Seed goal Define the core domain nouns the area's **declared domain model** exposes that meet the qualifying bar (see "What earns a slot"). The codebase sets the count: seed every term that genuinely qualifies, none added to reach a number and none pulled from beyond the declared model to inflate one. A small domain yields a few; a large one, more. The bound is the **source** (the declared domain model of the area in scope: schema, core types, primary models, top-level domain docs, not a full-codebase trawl) and the **bar** (the same "a new engineer would need this defined" test), never a fixed quantity. ### Scope of a seed - A **scoped run** (a learning capture, or a refresh narrowed to an area) seeds only that area's core nouns, and defines only terms it actually investigated against code. It does not reach for repo-wide nouns it never touched. - A **repo-wide bootstrap** (an explicit "create CONCEPTS.md" request) seeds the whole project's declared domain model. This is the only path that produces a coherent "what is this project" glossary; a scoped run cannot, and should not pretend to. ## Be opinionated When the team uses several words for the same concept, pick the best one and retire the rest. Record retired synonyms as aliases on the entry (see "Per entry"). Settled distinctions go to the Flagged ambiguities tail. The glossary is not a record of all words the team has ever used; it is the team's agreed-upon vocabulary. ## The file stands on its own Each entry must teach its concept to a reader who has no access to the codebase, PR history, architecture meetings, or Slack. This rules out: - Implementation specifics (file paths, class names, function signatures, table names, library calls) - Status fields, dates, owners on the entries - Examples or current-config values drawn from the code: specific thresholds, counts, or enum values that will change. State the behavior, not the number: "each skill sets its own actionable threshold" rather than "surfaces at 50, fixes at 75." - Links to PRs, issues, channels, or roadmap milestones - Version-specific claims ("currently uses X; migrating to Y") Cross-references between entries within `CONCEPTS.md` are fine; they resolve internally. General programming vocabulary (caches, queues, jobs, sessions) and everyday domain English need no redefinition either. But if an entry leans on another *project-specific* term to make sense, that term must be defined here too; an undefined project-specific sibling is itself a candidate to add. ## What earns a slot A term qualifies when its meaning here is precise enough that a new engineer would need it defined to follow conversations, tickets, or code. General programming vocabulary does not belong, even when used heavily. ## Per entry A definition is one sentence: what the term means in this domain and what distinguishes it from neighboring terms. A term with non-obvious behavioral rules (lifecycle, cancellation semantics, ownership invariants) earns a second paragraph for those rules, never to elaborate on the definition itself. When retired synonyms exist, list them as an aliases line directly under the definition: *Avoid: Booking, appointment*. Entities typically need more depth than value types; status concepts may need transition notes. ## Relationships (optional) When relationships between entries carry load-bearing meaning (ownership, cardinality, lifecycle dependencies that span entries), capture them in a `## Relationships` section near the top of the file or its cluster. Skip this section when entries stand on their own; include it only when the domain's structure is part of the terms' meaning. ## Organization Cluster concepts by domain relationship, entities with their states, processes with their stages, so readers can see the structure. A flat list works when the file is small. Reshape it as the file grows. ## Flagged ambiguities (tail of file) When two terms were used interchangeably and the team settled on a distinction, record the resolution as a one-line note: *"'account' had been used for both Customer and User; these are distinct."* This section is the audit trail for opinions the team has formed. ## One illustrative entry: shape, not template ``` ## Booking ### Reservation A future commitment to seat a Party at a specified date and time. *Avoid:* Booking, appointment A Reservation owns its Party but does not own a Table, Tables are acquired only when the Party arrives, through a Seating. Lifecycle: Booked, Seated, Completed, No-Show. Cancellation before a Seating is non-destructive; cancellation after a Seating is recorded as a No-Show. ### Party The guests committed to a Reservation. Each Reservation has exactly one Party. Party size is the count promised at booking, not the count who arrive. ### Table A physical seating unit with fixed capacity. Tables are shared resources, they do not belong to Reservations and are allocated only on the day-of through Seatings. ### Seating The act of placing a Party at a Table once the Party arrives. A Reservation has at most one Seating; a Table accumulates many Seatings across its lifetime. ```
-
-
SKILL.md 6.7 KB
--- name: compound description: 'Use when the user explicitly asks to save, curate, or consolidate what was learned, or closes a meaningful knowledge-work session. Not for remote, publish, deploy, or irreversible changes.' --- # Knowledge compound ## Contract | Field | Bound contract | |---|---| | Trigger | User explicitly asks to save, curate, or consolidate what was learned, or closes a meaningful knowledge-work session. | | Authority | Reversible local: writes only docs/solutions/{slug}.md records and repo-root CONCEPTS.md; rollback is version control. No remote mutation. Never silently deletes stale entries. | | Side effect | Writes typed docs/solutions/{slug}.md records and repo-root CONCEPTS.md; may update stale entries, but never silently delete them. | | Done | At most three specific typed learnings or an honest none are proposed; duplicates and contradictions are checked; the user approves; saved records carry type, retrieval tags, confidence, date, source, Context, and Implication; confirmation names retrieval tags. | ## Inputs - Session transcript (required): the accumulated context of the current session, from which learnings are extracted. - docs/solutions/ directory (optional): the shared learning-doc store, also written by `autolearn`. An absent directory counts as an empty store and is created on the first approved write. ## Procedure 1. Scan docs/solutions/ recursively (`**/*.md`, excluding `README.md`) for existing records. Load each record and extract its frontmatter tags, type, and source. Records written by `autolearn` live in category subdirectories and carry its own schema; read them for overlap, never rewrite them to this schema. Done when: every existing record is loaded with its frontmatter. 2. Check for stale and conflicting entries: compare the extracted tags of each existing record against the candidate learnings. An entry is stale when its tags overlap with a new candidate and its content contradicts or supersedes the candidate. An entry conflicts when it shares tags but states the opposite. Flag each stale or conflicting entry by name with the overlap reason; do not delete or overwrite it. Done when: every stale or conflicting entry is flagged by name with its overlap reason. 3. Propose at most three specific learnings drawn from the session transcript. Classify each with a type (e.g., pattern, caveat, reference, decision, concept, fix, lesson). Reject a fourth or fifth as scope creep; propose none if the session yielded no durable learning. Done when: at most three learnings are proposed with types, or an honest none is proposed. 4. For each proposed learning: a. Check against the stale-knowledge inventory: if a duplicate or contradiction exists by shared tag, flag it explicitly rather than overwriting. Done when: the duplicate or contradiction is flagged or none exists. b. Assign retrieval tags, confidence level (high/medium/low), date (ISO 8601), and source context. Done when: tags, confidence, date, and source are assigned. c. Draft frontmatter per the Record schema below: type, tags, confidence, date, source, Context (what triggered the learning), Implication (what changes as a result). Done when: frontmatter is drafted with all seven fields. 5. Present the proposed records to the user for approval. Include the stale/conflict flags so the user can decide whether to update, merge, or consolidate. Done when: the proposed records and flags are presented for approval. 6. On user approval: write each approved record to docs/solutions/{slug}.md using the drafted frontmatter and a prose body derived from the session. If a record updates or consolidates an existing entry, preserve the original entry's history line. Done when: every approved record is written with valid frontmatter and history preserved. 7. Confirm completion by naming the retrieval tags for each saved record. Done when: the retrieval tags for each saved record are named in the confirmation. ## Failure and recovery | Failure class | Result | |---|---| | docs/solutions/ exists but is unreadable | Block: skill cannot execute; report the path and the read error. | | User rejects all proposed learnings | Non-converged: nothing is written; report "No knowledge records saved." | | Write fails (disk error, permission) | Rollback: do not leave a partial record; report the error and the record that failed. | | Duplicate tag detected, user unresponsive | Non-converged: do not write; confirm explicitly before proceeding. | ## Output Markdown files written to docs/solutions/ (or the configured directory), each with frontmatter (type, tags, confidence, date, source, Context, Implication), plus a terminal confirmation naming retrieval tags for each saved record. ## Record schema Canonical frontmatter contract for `docs/solutions/{slug}.md` records. All seven fields are required. | Field | Type | Description | |---|---|---| | `type` | string | Learning type: pattern, caveat, reference, decision, concept, fix, lesson. | | `tags` | array[string] | Retrieval keywords, lowercase and hyphen-separated. Used for duplicate and contradiction detection. | | `confidence` | enum | `high`, `medium`, or `low`. | | `date` | string | ISO 8601 date (`YYYY-MM-DD`). | | `source` | string | Where the learning originated: session context, PR, issue, or codebase area. | | `Context` | string | What triggered the learning: the situation or problem that produced it. | | `Implication` | string | What changes as a result: the actionable consequence of the learning. | ### Body Prose body derived from the session, expanding on Context and Implication with the substance of the learning. No fixed section structure; let the learning shape dictate the prose. ### Filename `{slug}.md`: a sanitized, descriptive slug derived from the learning's core idea. No date suffix (the `date` field carries that). ### YAML safety Wrap array items in double quotes when a value starts with any of: `` ` `` `[` `]` `{` `}` `,` `*` `&` `!` `|` `>` `%` `@` `?`. Also quote when a value contains `": "`. Scalar fields have a separate failure mode: an unquoted ` #` truncates at the comment, an unquoted `: ` reframes as a mapping. ### Consolidation When a new record supersedes or contradicts an existing entry (flagged in step 2), the user may approve a consolidation: merge the new record into the existing file, preserve the original as a history line, and update the frontmatter `date` and `Context`/`Implication` to reflect the consolidated state. Never silently delete the superseded entry. ## Vocabulary capture: CONCEPTS.md (optional) When a durable project term with a precise local meaning surfaces during curation, reconcile CONCEPTS.md per `references/concepts.md`. The glossary is a shared surface; follow the one-definition-per-concept discipline. This is optional and never blocks the primary curation flow.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.