AGENT SKILL

mci

Identify and capture Minimum Coherent Insights — the smallest learning that changes future behavior.

License 许可
Apache-2.0
所属仓库
usurobor/cnos
最近更新
2026-11-07
Stars
★ 9
Forks
0

01 前言 Front Matter

name
mci
scope
task-local
triggers
[ "MCI", "model update", "learn", "reflect", "trace", "note" ]
description
Identify and capture Minimum Coherent Insights — the smallest learning that changes future behavior.
activation_status
on-demand — not activation-loaded since cycle/385. Core MCI rules (transferable-lesson tests, capture/imperative/trigger, migrate flow) are absorbed into cap/SKILL.md. Load this file on-demand for scope/specificity detail.
governing_question
How does the agent extract a single insight that prevents the next instance of the same mistake?

03 SKILL.md 正文

MCI

How to identify and capture Minimum Coherent Insights.

Core Principle

Coherent insight: the smallest learning that changes future behavior.

MCI = Minimum Coherent Insight. Not a vague takeaway — a specific lesson that, once known, prevents the same mistake or enables a new capability.

Failure mode: confusing feelings with insights. "That was hard" is not an insight. "Verify assumptions before acting" is.

1. Identify

Extract the transferable lesson.

1.1. Ask "what would I tell past-me?"

  • ❌ "I learned a lot" → ✅ "Check the return type before calling"
  • ❌ "That was tricky" → ✅ "Config files are loaded before env vars"

1.2. Distinguish observation from insight

  • Observation: what happened
  • Insight: what it means for the future
  • ❌ "The deploy failed" → ✅ "Always run migrations before deploy"

1.3. Make it transferable

  • Would this help someone else in a similar situation?
  • ❌ "I should have checked" → ✅ "Validate inputs at system boundaries"

2. Scope

Smallest learning that changes behavior.

2.1. Specific enough to apply

  • ❌ "Be more careful" → ✅ "Run tests before pushing"
  • ❌ "Think harder" → ✅ "Write the expected output before writing the code"

2.2. General enough to transfer

  • ❌ "Don't forget the semicolon on line 47" → ✅ "Syntax errors often hide at statement boundaries"
  • ❌ "Check config.yaml" → ✅ "Check config files when behavior differs from code"

2.3. One insight per capture

  • Don't bundle unrelated learnings
  • ❌ "Learned about deploys and also testing and also code review" → ✅ Three separate MCIs

3. Capture

Write it down or lose it.

3.1. Capture immediately

  • Insights decay fast
  • ❌ "Will write it up later" → ✅ Write it now

3.2. State as imperative when possible

  • ❌ "I realized X is important" → ✅ "Always do X"
  • ❌ "It turns out Y matters" → ✅ "Check Y first"

3.3. Include the trigger

  • What situation does this apply to?
  • ❌ "Validate inputs" → ✅ "Validate inputs at system boundaries"
  • ❌ "Test edge cases" → ✅ "Test edge cases when parsing user input"

4. Migrate

Insights should flow to where they'll be used.

4.1. Daily → Weekly → Skill

  • Same insight appearing multiple times? Migrate it up
  • ❌ Same lesson in 4 daily threads → ✅ Add to relevant skill

4.2. Choose the right home

  • Where would future-you look for this?
  • ❌ Buried in a daily thread → ✅ In the skill for that task

4.3. Delete after migrating

  • Don't duplicate insights across locations
  • ❌ Copy to skill, keep in daily → ✅ Move to skill, mark done in daily

MCI vs MCA

MCI MCA
Learning Action
Changes future behavior Solves current problem
"Always X" "Do X now"
Migrates to skills Completes when done

Prefer MCA over MCI. If you can act, act. Insights are what remain after acting.


Quick Test

Before capturing, ask:

  1. Is this specific enough to apply?
  2. Is this general enough to transfer?
  3. Would past-me have avoided the problem with this knowledge?

If any answer is "no" — refine it.

04 同仓库更多 Skills

usurobor
usurobor/cnos

issues/triage

Issue triage doctrine pointer. Use when classifying a new issue, deciding dispatch eligibility, or deciding whether to close/supersede/defer.

★ 9
usurobor
usurobor/cnos

issues/taxonomy

Issue label taxonomy pointer. Use when classifying an issue's kind/area/priority/effort/status/protocol/dispatch labels, or when the board needs to interpret them.

★ 9
usurobor
usurobor/cnos

issues/map

Issue-board (Issue Pivot) generation domain. Use when reasoning about `cn issues map`'s fetch, taxonomy-parse, effort-computation, and render pipeline, or about the board's JSON/HTML output contract.

律师与法务前端开发
★ 9
usurobor
usurobor/cnos

issues

cnos.issues package entrypoint. Use when reasoning about issue taxonomy, the Issue Pivot / issue-board (`cn issues map`), the read-only CDS issue-state evaluator (`cn issues fsm evaluate`), or the current command-dispatch disposition of issue tooling.

★ 9
usurobor
usurobor/cnos

receipt-stream

Cross-cycle receipt-stream doctrine for protocol-iteration. Use when γ closes a cycle and writes the per-cycle iteration artifact (`cdd-iteration.md`), when γ updates the cross-cycle aggregator at `.cdd/iterations/INDEX.md`, when ε reads the receipt stream across cycles to surface protocol-gap patterns, when a finding's disposition lands a cross-repo patch and the cross-repo trace bundle attaches, or when a courtesy empty-findings stub is written for a `protocol_gap_count == 0` cycle.

★ 9
usurobor
usurobor/cnos

mid-flight

Mid-flight γ→in-flight-α rescue channel. Use when γ needs to change a load-bearing fact (pinned axis, scope, AC, blocker) after α has begun coding, when γ edits the cycle's GitHub issue body mid-cycle, or when a spec change lands on origin/main while α/β polling sessions are in-flight.

★ 9