Ops Base

---
name: ops-base
description: Shared operational framework for meeting documentation, task management, and workflow processes. Base module referenced by the /ops skill.
user-invocable: false
---

# Operations Base Framework

Shared standards for operational documentation across all ops-skills.

**IMPORTANT:** The project CLAUDE.md is the single source of truth for vault-specific details. This skill defines generic frameworks and workflows; CLAUDE.md defines where things go.

---

## CONFIGURATION SYSTEM

Domain skills use a layered configuration system for organization-specific settings.

### Config Resolution Order

1. **Project-level:** `.claude/ops-config.yaml` in the project root
2. **Folder-local** (CR-011): nearest `<folder>/_ops.yaml` walking up from CWD until vault root. Vault root = nearest ancestor containing `_inbox/`, `_outbox/`, or `.obsidian/` (or `VAULT_ROOT` env override).
3. **Vault-wide** (CR-011, optional): `<vault-root>/_config/base.yaml`
4. **Skill defaults:** `~/.claude/skills/ops-config/base.yaml`

First match wins. Later layers provide fallback values.

**Deprecated (v1.16.0, removed v1.17.0):** the previous step "Config skill: `~/.claude/skills/{org}-ops-config/{org}.yaml`" is deprecated. If still present, it acts as a fallback between steps 3 and 4 with a one-time deprecation warning. Migrate by copying the YAML into the matching `<vault>/<org>/_ops.yaml`.

### Config Usage

When processing content, domain skills should:

1. **Determine organization** from:
   - Explicit `organization` field in project CLAUDE.md
   - Project folder name pattern (e.g., `acme-*` -> acme)
   - Participant names matching team members in configs

2. **Load config** following resolution order

3. **Apply config values:**
   - `language`: Determines output language (english/swedish/input)
   - `team`: For participant recognition and attribution
   - `responsibility_matrix`: For owner assignments
   - `terminology`: For consistent term usage
   - `workflows.update_files`: Which files to update
   - `workflows.action_propagation`: Whether to propagate actions
   - `domain_additions`: Extra sections to include

### Available Configs

Organization configs live in the vault folder they describe: `<vault>/<org>/_ops.yaml` (CR-011). The base fallback config `base.yaml` is in `~/.claude/skills/ops-config/`. Optional vault-wide overrides go in `<vault>/_config/base.yaml`.

Pre-CR-011 skill-based configs (`*-ops-config` skills under `~/.claude/skills/`) are deprecated and removed in v1.17.0.

See `~/.claude/skills/ops-config/schema.md` for complete schema definition.

---

## MEETING DOCUMENTATION

### Summary Format

Follow the **TWO-TIER SUMMARY FORMAT** defined in the project CLAUDE.md. That document defines the base structures for both Concise and Detailed Strategic summaries. The `/ops` skill may add supplementary sections via config `domain_additions` or use a custom `summary_sections` structure.

When processing a meeting:
1. Determine if Concise or Detailed Strategic format applies (use criteria from CLAUDE.md)
2. Follow the structure defined in CLAUDE.md for the chosen format
3. Apply any domain-specific additions from the active ops-skill

### Canonical Heading Order (CR-006)

Regardless of which format variant is used, the standard sections **must appear in this order**:

1. **Nästa steg / Next Steps** -- action items first (table format with `#`, `Åtgärd/Action`, `Ägare/Owner`, `Prio/Priority`, `Deadline`)
2. **Beslut / Decisions** -- always include, even if `*(Inga formella beslut)*`
3. **Konklusion / Outcome** -- 1-2 sentences, no minimum length
4. **Diskussion / Discussion** -- narrative content
5. **Bakgrund / Background** -- reference material at the bottom

Use these **canonical heading names only** -- do not produce variants like `Sammanfattning`, `Executive Summary`, `Summary`, `Action Items`, `Åtgärdspunkter`, `Huvudpunkter`, `Key Discussion Points`, or `Decisions Made` in new files. See `/transcript` SKILL.md for the full canonical heading table and Action Item Table format.

### Template Variants by Meeting Length (CR-006)

| Variant | When | Required sections |
|---|---|---|
| **Concise** | <30 min meetings, internal task sessions | Nästa steg, Beslut, Konklusion |
| **Standard** | 30-90 min meetings, most contact samtal, standups | Full canonical structure |
| **Extended** | >90 min meetings, board, strategy, multi-topic | Full structure + per-topic numbered subsections |

Default to Standard. There is **no minimum length** for the Konklusion section -- a short meeting still has an outcome.

### Template Contracts (CR-018)

Recurring meeting series erode format rules by **silent template forking**, not random noise: the model pattern-matches the previous file of the same series, so one deviating file re-seeds the whole series (a dropped table column, a reintroduced banished heading), and every subsequent file is internally consistent -- which is exactly why per-file review never catches it. The counter-measure is a declared per-meeting-type **shape contract**, checked at save time.

**Registry** (org or folder-local config, `workflows.meeting_templates`): each entry declares a `match` glob for the series and the expected shape; a `default` entry covers everything unmatched (falling back to the CR-006 canonical order and the `strings` action-table headers):

```yaml
workflows:
  meeting_templates:
    mode: warn                      # warn (default) | strict
    weekly-management:
      match: "meetings/management/2*-Weekly-*"
      headings: [Nästa steg, Beslut, Konklusion, Diskussion, Bakgrund]
      action_table: ["#", "Åtgärd", "Ägare", "Prio", "Deadline"]
```

**The check** (run by `/ops` and `/transcript` as the last pre-save step, after Swedish-character validation). Resolve the matching contract (most specific `match` wins, else `default`) and verify exactly three things:

1. **H2 heading sequence** equals the contract's `headings` (order and canonical names; banished variants fail).
2. **Action-table header row** equals the contract's `action_table`.
3. **Empty Beslut carries the marker**: a `## Beslut` section with no decisions must contain the `no_decisions_marker` string -- absence-by-omission fails.

**On mismatch:** `mode: warn` (default) -- save, report the exact diff to the user, log an `edge_case`. `mode: strict` -- show the diff and ask before saving. A deliberate format change is made by **editing the contract**, never by letting a file drift: that turns an accidental fork into an explicit, reviewable decision.

Orgs with no `meeting_templates` config get the `default` CR-006 contract in warn mode -- the check is never fully off.

---

## STATUS / RESULTS REPORTING (CR-069)

A **status report** is the measurement-driven sibling of the meeting summary above. Where a summary is *event-driven* (input = a transcript, looking backward at what was said), a status report is *measurement-driven* (input = a data source + a period, looking forward at where something stands). A daily product-metrics readout, a campaign-performance report, a project-health check, an experiment result -- all the same shape.

**This is a shared standard, not a skill.** A skill produces a status report by **referencing** this standard -- exactly as meeting summaries reference the TWO-TIER format. The skill supplies the domain (the data source, the metric names, the reconciliation identities, the freshness thresholds); this standard supplies the structure and the discipline. Do **not** put status reporting inside `/ops`: `/ops` processes meetings (input = transcript), and a status report's input is a data source, not a conversation.

### Required elements

A conforming status report has all six:

1. **Scorecard first.** Lead with 3-6 headline measures as a **trend** (movement over a period), never a point-in-time snapshot, plus one line naming the single biggest thing slowing progress. The reader gets the verdict before any detail.
2. **Trend anchoring / partial-period guard.** Compute deltas over *complete* periods; if the latest data point is a partial period (an early-in-the-day snapshot, an in-progress week), anchor the trend on the last complete period and label the partial one -- a partial delta must not read as a stall or a spike.
3. **Reconciliation invariants.** The report declares the identities its own numbers must satisfy (a total equals the sum of its parts; two independently-computed figures of the same quantity agree) and states in the footer that they hold. A failing invariant blocks publication.
4. **Honest provenance and blind spots.** Stamp the data source and as-of timestamp; name explicitly what the data *cannot* show (a quantity there is no feed for). Never imply a metric that was not measured, or present a coarser or older series as current.
5. **Data-freshness gate -- warn, do not fail silently.** Before writing, check each source against a declared freshness expectation *and its own cadence*; if a source is stale, or is a lower-cadence rollup than the report implies, WARN at the top of the report (or refuse to publish a stale one).
6. **Owner-ranked actions.** Close with what to do, ranked by impact, each with a named owner and the number that justifies it. A recommendation without an owner is not an action.

### The contract

A producing skill declares its report's domain rules; this standard requires only that they **exist and are honoured**. The concrete metrics, thresholds, reconciliation identities, and cadences live in the skill (or its per-report template), not here. A status-report skill states, in its SKILL.md, which data sources it reads, their freshness expectations and cadences, and the reconciliation identities -- the analogue of the meeting `meeting_templates` contract. Absence of any of the six required elements is a format failure, reported the same way (warn by default).

This standard is business-agnostic: it names no product, org, or dataset. It applies equally to a company's daily metrics report and a personal project's progress check.

---

## TASK MANAGEMENT

### Priority Levels
- **P0:** Critical blocker affecting operations/revenue
- **P1:** High priority, needed this week
- **P2:** Important, needed within 2 weeks
- **P3:** Research/exploration, flexible timing

### Status Indicators
- BLOCKED - External dependency
- IN PROGRESS - Active work
- ON TRACK - Progressing well
- TODO - Planned, not started
- PLANNED - Future sprint
- COMPLETE - Finished

### Task Document Lifecycle

Consult the project CLAUDE.md for task document locations within the relevant ops/ domain.

#### 1. Creation (Pre-Meeting)
**Content:**
- Investigation areas
- Research questions
- Technical requirements
- Decision points

#### 2. Active Period
- Update progress regularly
- Link to related documents
- Track dependencies

#### 3. Post-Meeting
- Mark completed items
- Create new task doc for follow-ups
- Archive when complete or after 30 days

### Per-Folder _tasks.yaml (v2)

Tasks are tracked in distributed `_tasks.yaml` files (v2 schema) at each folder level. Each file has `context` (folder identity) and `scope` (root/org/project/personal). The `/tasks` skill manages these files, and the visualisation app aggregates them.

| File | Signals | Used by |
|------|---------|---------|
| `_tasks.yaml` | Folder with tracked tasks | `/tasks`, `/ops`, visualisation |

#### Task-ledger resolution (CR-040)

**The local ledger is the default, not an invariant.** A folder may declare that the work it
coordinates is tracked somewhere else -- an issue tracker, or a change-request registry inside the
codebase the folder shadows. Read `workflows.task_ledger` from the effective config (folder -> org ->
default) **before touching any `_tasks.yaml`**:

| `mode` | Meaning | Behaviour |
|--------|---------|-----------|
| `local` | Default, and what an absent key means | Today's behaviour: find or create the per-folder ledger, import and update items |
| `external` | The work lives in a declared system of record | **Never create `_tasks.yaml`, and never walk to the nearest ancestor.** Implementation items are recorded **by reference** (the `reference_field` value) in the summary; only coordination that has no item in that system goes to the folder's declared coordination surface |
| `none` | No ledger, no external pointer | Coordination lives in the summaries. For small or short-lived folders |

```yaml
workflows:
  task_ledger:
    mode: external                 # local (default) | external | none
    system: "Codebase issue registry"      # required when external
    pointer: "docs/issues/REGISTRY.md"     # required when external
    reference_field: cr_id         # cr_id | jira_key | url
```

**Why the ancestor walk is the dangerous half.** Creating an unwanted ledger is visible. Walking up
and writing a folder's coordination items into a *parent's* ledger is not -- the items land where
nobody looks for them, and the folder appears to have no open work.

**One item, one home** (the CR-022 rule, generalised): an item goes to the external system **or** the
local ledger **or** the triage doc -- never two of them. Where a system of record already exists, a
second ledger with the same owners and the same items is not redundancy, it is a competing truth.

---

## DOCUMENTATION STRUCTURE

Consult the project CLAUDE.md for:
- **Vault structure** and folder organization (VAULT STRUCTURE section)
- **Meeting routing** -- which meetings go where (MEETING ROUTING table)
- **File naming conventions** -- YYMMDD patterns per meeting type (MEETING FILENAME FORMAT section)
- **Ops routing** -- which operational docs go where (OPS ROUTING table)
- **Archive policy** and locations (ARCHIVE POLICY section)
- **Team structure** and responsibility matrix (TEAM section)

### General Naming Rules (slug contract, CR-021)
- All filenames use `YYMMDD-` prefix -- **always this format, never ISO** (`2026-03-12-`). A folder may only deviate if its own CLAUDE.md explicitly declares another format.
- Use hyphens between words
- **Diacritics: keep å/ä/ö in filenames.** Never transliterate (`mote`), never digit-substitute (`m0te`), never mix policies within one filename (`förberedelse-...-utlosen`). CR-007 covered file *content*; this extends it to the filename -- run the same driftword check against the slug before saving.
- **Role keyword is mandatory:** the resolved `{strings.filename_keywords}` word (`summary`/`agenda`/`standup` — English in every language since CR-089; legacy `samtal`/`förberedelse`/`sammanfattning` files are never renamed and are still read) must appear in the slug so the file's role is machine-readable. An agenda must never be named like a summary -- `/ops`, `/outbox` and the agenda generator select files by these keywords.
- Proper names are capitalized (e.g., `Alex-Bob`); all other slug tokens are lowercase
- Only CHANGELOG.md and README.md are uppercase; all other files use lowercase
- See CLAUDE.md's MEETING FILENAME FORMAT for specific patterns per meeting type
- Retroactive cleanup is **opt-in only** via `/ops normalize --filenames <folder>` (renames + rewrites inbound references it can find); never rename existing files implicitly -- links point at current names

---

## WORKFLOW PROCESSES

### Meeting Workflow
1. **Prepare** - Review context, create agenda
2. **Record** - Capture decisions and actions
3. **Process** - Create structured summary
4. **Update** - CHANGELOG, tasks, priority matrix
5. **Archive** - Move completed items

### Change Log Format
```markdown
## [YYYY-MM-DD] - Description
**Meeting:** Duration | **Participants:** Names
**Summary:** [Link](path/to/summary.md)

**Key Changes:**
- Area: Change description
- Area: Change description
- Status: NEW/ONGOING/RESOLVED
```

---

## RAW SOURCE ARCHIVE (CR-085)

**The one definition. `/ops` and `/transcript` both run this; neither restates it.**

A summary is a reading of something that was said. Without the source, a disagreement about what
was said has no arbiter — and the absence cannot announce itself, because the summary looks
complete either way.

**When:** after the summary has a target folder, before post-processing.

**Skip only if:** the user explicitly said not to save the raw material, or there is no target
folder (summary printed, nothing written).

### Where and what

- **Location:** `<vault-root>/.transcripts/`, created if missing. Always this one central folder,
  whatever folder the summary went to. Find the root by walking up until the directory holding
  `_inbox`/`_outbox`/`_contacts`.
- **Filename:** the summary's stem plus `-raw`, so the pair matches trivially.
- **Content:** frontmatter, then the **verbatim** input, unedited and uncleaned.

```markdown
---
type: raw-transcript
date: YYMMDD
source: <store name> | pasted | file
source_id: <document id in the store>      # what makes this traceable to the recording
source_file: <original filename>
duration: <as reported>
variant: <transcript variant, where the store offers several>
summary: <relative path to the primary summary>
summaries:                                  # every summary this input fed
  - <relative path>
disposition: <one line: how the session was split, and why>
created_files:
  - <every file this run created or updated>
---

<verbatim text>
```

`source_id` matters more than it looks: without it the archive proves only that *something* was
said. With it, the raw file points back at the recording it came from.

Several recordings merged into one summary go in **one** file with clear separators, each keeping
its own metadata line.

### One input, several destinations

One session can cover separable subjects belonging in different folders.

- **One raw file per input, never one per summary.** The input is what happened; the summaries are
  readings of it.
- `summaries:` lists them all; `summary:` stays as the primary for backward compatibility.
- `disposition:` states the split in one line.
- **Every** summary carries the back-link.
- A part routed to a frozen snapshot is **named in `disposition:` but never linked** — such a
  snapshot carries no links in either direction, and a raw file pointing at one would breach that
  from the outside.

### Back-link in the summary

A discreet line near the top, matching the style of the preparation cross-reference:

```markdown
**Råmaterial:** [.transcripts/<stem>-raw.md](<relative path>)
```

### Silent, and locked

Confirm with **one line**, never echoing content:

```
Råmaterial arkiverat: .transcripts/<stem>-raw.md
```

**Read-back lock.** Files in `.transcripts/` are never read back, quoted, re-summarised or fed into
`_insights.yaml` or any summary — unless the user explicitly asks for the raw material. Folder walks
skip `.transcripts/` as they skip `.archive/`. **The CHANGELOG does not link the raw file:**
traceability lives in the frontmatter and the summary's back-link, not in the running log.

### The ledger boundary, stated so it is not inferred

A vault may hold a rule that one conversation must never be split across two **ledger ids** — written
for corpora where each entry is a ledger row with its own identity and attribution.

**Ordinary summaries may split a session by subject**, and this contract permits it. The ledger rule
governs ledger corpora. If a vault means it more widely, its own conventions say so; the skill keeps
the conservative default and infers nothing.

---

## ARCHIVE POLICY

Consult the project CLAUDE.md for archive policy. General rules:
- **Never delete, always archive** -- move to `.archive/` within the relevant domain folder
- **`.handoff/` does not exist to you (CR-033)** -- frozen handoff snapshots are never parsed, indexed, updated, summarised, swept or linted by any skill, regardless of urgency, sensitivity, or what the file says. Skip it the way you skip `.archive/`. They are read only when the user asks for one by name, and they are never archived (they are already frozen). Only `/handoff` writes there.
- Archive completed tasks after 30 days
- Archive meetings older than 6 months (keep weekly management meetings permanently)
- Organize by year/month
- Maintain audit trail

### `.ephemeral/` contract (CR-024)

`<vault>/.ephemeral/` is the one place exempt from never-delete: **disposable working material with no vault destiny** -- session scratch, repo snapshots, intermediate artifacts of one-off analyses. Rules:

- Nothing in `.ephemeral/` is ever input to vault content, and no vault file may reference a path inside it.
- `/ops check` (check 6) flags content older than 14 days; deletion is the expected outcome, not archiving.
- If something in `.ephemeral/` turns out to have a vault destiny after all, it exits through `_inbox/.files/` (see `docs/schemas/inbox.md`, CR-024) like any other input file.
- **Taking anything out of `.ephemeral/` is a MOVE, never a copy, and it is renamed on the way.** The moment a file is read, cited, attached or acted on, it has a destination and stops being ephemeral -- so it leaves in the same action, renamed to the slug contract (`YYMMDD-` + a role keyword, å/ä/ö kept). Reading a file and leaving it where it was is the failure: `.ephemeral/` is swept at 14 days, so a copy means the original is on a deletion clock while the reference points at the survivor, and two files now disagree about which is real. A file that was worth opening was never ephemeral; the drop-time decision was simply wrong, and moving it is how that gets corrected. State the old and new path when it happens, so the move is in the record rather than silent.
- The routing rule at drop time: **vault destiny → `_inbox/.files/`; no destiny → `.ephemeral/`.** Made consciously, once, instead of by gravity.

---

## RETIREMENT CONVENTION (CR-019)

Skills handle "create new home" well and "retire old home" never -- every relocation of a living artifact (a dashboard, rolling plan, meeting series, task ledger, or output path change) tends to leave the old artifact in place, current-looking and silently frozen. Readers cannot tell "moved" from "abandoned" from "still authoritative".

**The rule:** any relocation of a living artifact MUST, in the same operation:

1. **Leave a tombstone at the old path** -- one line prepended to the old file (or a stub README in the old folder):
   ```markdown
   > **Flyttad (YYMMDD):** se [new-path](relative/link/to/new-path)
   ```
2. **Log the move** in the affected folder's CHANGELOG.
3. **Update or remove stale pointers** the skill itself created (root symlinks, dashboard links).

This applies to skills moving their own output (e.g. a skill changing its output location must tombstone the old file, not leave two live-looking copies) and to user-driven moves processed through a skill (e.g. a 1-on-1 series moving to a new folder gets a forward-pointer README in the old one). `/ops check` detects violations after the fact; this convention prevents them at move time.

---

## CROSS-REFERENCING

### Link Standards
- Previous meeting: `[See: YYMMDD-Meeting.md]`
- Task document: `[Tasks: ../tasks/YYMMDD.md]`
- Changelog entry: `[CHANGELOG: YYYY-MM-DD]`
- Use relative paths for reliability

---

## OUTPUT INSTRUCTIONS

When processing content:

1. **Load configuration:**
   - Determine organization from context
   - Load config following resolution order
   - Fall back to base.yaml if no match

2. **Identify content type:**
   - Meeting transcript -> Create appropriate summary format
   - Task description -> Create task document
   - General input -> Create relevant documentation

3. **For meetings:**
   - Determine if Concise or Detailed Strategic format (see CLAUDE.md TWO-TIER SUMMARY FORMAT)
   - Extract participants, decisions, action items
   - Match participants to `team` from config for attribution
   - Include relevant metrics if mentioned
   - Consult CLAUDE.md for correct filename pattern and output location
   - Apply `domain_additions` sections from config

4. **For tasks:**
   - Assign priority level (P0-P3)
   - Set initial status
   - Identify dependencies
   - Use `responsibility_matrix` from config for owner assignment
   - Consult CLAUDE.md for task document location within relevant ops/ domain

5. **Execute workflows:**
   - Update files listed in `workflows.update_files`
   - If `workflows.action_propagation.enabled`, propagate to target files

6. **Apply language:**
   - `english`: Output in English regardless of input
   - `swedish`: Output in Swedish regardless of input
   - `input`: Match the transcript's language
   - `per_claude_md`: Follow the project CLAUDE.md LANGUAGE POLICY for per-file-type rules

7. **CRITICAL -- Swedish character enforcement (when `swedish_chars: strict`):**

   **`swedish_chars: strict` resolution at write time (CR-007):**
   1. If the target folder has its own CLAUDE.md with explicit `swedish_chars`, use that
   2. Else if the folder is under an ops-aligned venture (e.g., `acme/`, `delta/`, `echo/`), use that venture's config
   3. Else if the folder matches a `language_inheritance.apply_swedish_chars_strict_to` glob from base.yaml (default: `_projects/**`, `_contacts/**`, `_private/**`, `_inbox/**`), **inherit `strict` from base**
   4. Else use base default (which is `strict` since CR-007)

   This means files written under `_projects/bravo-project/` or any other sub-tree without its own CLAUDE.md are still subject to strict-mode enforcement.

   **Enforcement rules:**
   - **BEFORE writing ANY file**, verify that every Swedish word uses correct å, ä, ö
   - NEVER write "for" when you mean "för", "ar" when you mean "är", "pa" when you mean "på"
   - This is a BLOCKING requirement -- do not write files with missing Swedish characters
   - The full substitution list lives in `~/.claude/skills/ops-config/swedish_substitutions.yaml`
   - To remediate existing files written before CR-007, use `/ops normalize <file>` (see ops/SKILL.md)
   - Common mistakes to catch:
     - för (NOT "for"), är (NOT "ar"), på (NOT "pa"), från (NOT "fran")
     - möte (NOT "mote"), nästa (NOT "nasta"), första (NOT "forsta")
     - företag (NOT "foretag"), pågående (NOT "pagaende"), behövs (NOT "behovs")
     - månader (NOT "manader"), lösning (NOT "losning"), användning (NOT "anvandning")
     - kräver (NOT "kraver"), förberedelse (NOT "forberedelse"), kärnteam (NOT "karnteam")
     - besökare (NOT "besokare"), återanvändbar (NOT "ateranvandbar")
     - leverantör (NOT "leverantor"), affärsutveckling (NOT "affarsutveckling")
     - välgörenhet (NOT "valgorenhet"), varumärke (NOT "varumarke")
     - domän (NOT "doman"), mätare (NOT "matare"), stöd (NOT "stod")
     - André (NOT "Andre"), ändamål (NOT "andamal"), ägande (NOT "agande")
   - English technical terms, status labels, and proper nouns stay English regardless
   - This rule applies to ALL output: summaries, CHANGELOG entries, priority matrices, dashboards, ops-configs, CLAUDE.md

8. **Always include:**
   - Suggested CHANGELOG entry
   - Cross-references to related documents
   - Next steps or follow-up items

9. **Execution feedback capture (silent):**
   If `workflows.knowledge_extraction.evolution.enabled` is true, silently log noteworthy execution events to `_insights.yaml` in the target folder. This step produces no visible output.

   **What to capture:**

   | Type | When | Example |
   |------|------|---------|
   | `edge_case` | Ambiguous input required guessing or user disambiguation | Name matched multiple contacts, unclear meeting routing, language detection uncertain |
   | `correction` | User corrected or overrode skill output after seeing it | Changed file location, corrected participant names, modified summary structure |

   **When NOT to capture:** Normal, successful execution. Most invocations produce zero feedback entries. Only log when something unexpected happened or the user intervened.

   **Entry format:**
   ```yaml
   - id: [next_id]
     type: edge_case          # or correction
     date: YYMMDD
     summary: "One sentence describing what happened"
     detail: "How it was resolved"
     source:
       file: "transcript-or-summary-filename.md"
       skill: ops              # or transcript, inbox, etc.
       step: "step number where it occurred"
     tags: [max, five, keywords]
     status: active
   ```

   Follow the same `_insights.yaml` format, dedup rules, vocabulary guard, and reusability rules as knowledge extraction (Step 5.5 in /ops, Step 3.5 in /transcript).