@devflow-core/dsh-devflow 0.1.0

package/assets/skills/devflow-cut/references/native-capability-checklist.md

@@ -0,0 +1,112 @@
+# Native Capability Checklist
+
+Use this before adding a dependency, wrapper, generic helper, or custom framework layer. The goal is not code golf. The goal is fewer owned moving parts while keeping correctness, security, accessibility, and verification.
+
+## Browser And HTML
+
+| You think you need | Check first |
+|---|---|
+| Date picker | `<input type="date">` |
+| Time picker | `<input type="time">` |
+| Color picker | `<input type="color">` |
+| Range slider | `<input type="range">` |
+| Modal/dialog library | `<dialog>` and `showModal()` |
+| Accordion/FAQ component | `<details><summary>...</summary>...</details>` |
+| Searchable dropdown | `<input list>` and `<datalist>` |
+| Progress/gauge | `<progress>` or `<meter>` |
+| Tooltip | `title` for simple hints, CSS pseudo-elements for styled hints |
+| Auto-growing textarea | `field-sizing: content` where supported |
+| Sticky header | `position: sticky` |
+
+## CSS
+
+| You think you need JS for | Check first |
+|---|---|
+| Responsive layout | Grid/flex with `minmax`, `auto-fit`, `auto-fill` |
+| Component-level responsive layout | Container queries |
+| Dark mode | `prefers-color-scheme` |
+| Reduced motion | `prefers-reduced-motion` |
+| Sticky header | `position: sticky` |
+| Text truncation | `text-overflow`, line clamp |
+| Scroll carousel | Scroll snap |
+| Theming | CSS custom properties |
+| Aspect ratio boxes | `aspect-ratio` |
+| Parent-state styling | `:has(...)` |
+| Native CSS nesting | nested selectors |
+
+## JavaScript And Browser APIs
+
+| You think you need | Check first |
+|---|---|
+| Query-string parser | `URLSearchParams` |
+| Deep clone | `structuredClone` |
+| Currency/number formatting | `Intl.NumberFormat` |
+| Date formatting | `Intl.DateTimeFormat` |
+| Relative time | `Intl.RelativeTimeFormat` |
+| Plural rules | `Intl.PluralRules` |
+| UUID | `crypto.randomUUID()` |
+| Clipboard helper | `navigator.clipboard` |
+| Infinite scroll | `IntersectionObserver` |
+| Resize listener | `ResizeObserver` |
+| DOM mutation watcher | `MutationObserver` |
+| Abort fetch on timeout | `AbortSignal.timeout()` |
+| Simple event bus | `EventTarget` and `CustomEvent` |
+
+## Node.js
+
+| You think you need | Check first |
+|---|---|
+| `mkdirp` / `make-dir` | `fs.mkdirSync(path, { recursive: true })` |
+| `rimraf` | `fs.rmSync(path, { recursive: true, force: true })` |
+| `path-exists` | `fs.existsSync` |
+| JSON file helpers | `fs.readFileSync` + `JSON.parse`, `fs.writeFileSync` + `JSON.stringify` |
+| `object-assign` | `Object.assign` or spread |
+| array unique | `new Set()` |
+| array flatten | `Array.prototype.flat()` |
+| stream check | `value instanceof stream.Readable` |
+| path normalization | `path.normalize`, `path.posix`, or `path.win32` |
+
+## Python
+
+| You think you need | Check first |
+|---|---|
+| simple data records | `dataclasses.dataclass` |
+| basic timezone support | `zoneinfo.ZoneInfo` |
+| JSON | `json` |
+| CLI parsing | `argparse` |
+| caching | `functools.lru_cache` |
+| path handling | `pathlib.Path` |
+| basic iteration helpers | `itertools` |
+| partial/reduce helpers | `functools.partial`, `functools.reduce` |
+| dict merge | `dict_a | dict_b` on Python 3.9+ |
+
+## Database
+
+| App code temptation | Database primitive |
+|---|---|
+| Uniqueness checks | `UNIQUE` constraint |
+| Referential integrity | `FOREIGN KEY` |
+| Value ranges | `CHECK` constraint |
+| Pagination | `LIMIT` / `OFFSET` or cursor query |
+| Deduplication | `DISTINCT` / conflict handling |
+| Running totals or ranking | Window functions |
+| JSON query | Native JSON support |
+| Full-text search basics | Built-in FTS / text indexes |
+| Insert/update timestamps | column defaults and update triggers |
+
+## Shell And Platform
+
+| You think you need | Check first |
+|---|---|
+| custom file finder | `rg --files`, `find`, or platform search |
+| custom process runner | package scripts or existing task runner |
+| generated config loader | existing env/config conventions |
+| new project metadata format | existing `package.json`, manifest, TOML, YAML, or platform manifest |
+
+## Required Output
+
+```text
+Native Check：checked <layer>; native option <used/not enough>; reason <why>
+```
+
+If the native option is not enough, name the current limitation and the proof. Do not cite future flexibility as a reason.

package/assets/skills/devflow-docs-followup/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: devflow-docs-followup
+description: "Use when the user explicitly asks to create or discuss completion documentation, or automatically only after a verified feature implementation with an actual source-behavior or interface-contract change. Do not automatically ask for documentation after validation-only, documentation-only, rule-only, skill-only, or no-diff PASS results. Ask the current Codex user which documents to create; never create any until explicitly confirmed."
+---
+
+# DevFlow Docs Follow-Up
+
+Ask the current Codex user whether a verified feature implementation needs follow-up documentation. Do not create any document until the user explicitly confirms it.
+
+## Entry Gate
+
+1. For a direct user request to create or discuss completion documentation, proceed with the requested documentation flow; a feature implementation diff is not required.
+2. For an automatic completion handoff, confirm both current `devflow-prove` `PASS` evidence and task evidence of an actual feature implementation that changes source behavior or an interface contract. Inspect the task diff, touched files, or equivalent user-provided baseline.
+3. Do not automatically ask about documentation for validation-only, documentation-only, rule-only, skill-only, or no-diff `PASS` results. Stop without an inquiry.
+4. If completion evidence is absent, stop and return to the appropriate proof route. Do not ask about documentation for an unverified feature.
+5. Address the current Codex user, not the feature's eventual end user.
+
+## Inquiry
+
+Ask once, allowing one or more selections:
+
+```text
+The feature is verified. Do you need any follow-up documentation?
+
+1. Technical solution document
+2. Frontend API handoff document
+3. Feature-flow troubleshooting document
+4. No documents
+
+Reply with one or more numbers, or say none.
+```
+
+Rules:
+
+- Treat only an explicit selection as approval to create that document type.
+- Treat silence, an ambiguous reply, or an unselected item as not approved.
+- Treat `none` as a completed follow-up with no files written.
+- If the user selects more than one type, create only those selected types.
+
+## Evidence And Landing
+
+Before writing a selected document, read the current diff, implementation, tests, commands, and user-confirmed decisions. Use project documentation conventions and templates when they exist.
+
+When the target project has no relevant convention, use these fallback locations:
+
+| Document type | Fallback path |
+|---|---|
+| Technical solution | `docs/technical/YYYY-MM-DD-<short-kebab-name>.md` |
+| Frontend API handoff | `docs/frontend-handoff/YYYY-MM-DD-<short-kebab-name>.md` |
+| Feature-flow troubleshooting | `docs/troubleshooting/YYYY-MM-DD-<short-kebab-name>.md` |
+
+Do not invent code paths, API contracts, payload fields, errors, or verification results. If the selected document lacks evidence, name the missing evidence and report that document as `BLOCKED`.
+
+## Document Templates
+
+### Technical Solution Document
+
+Use these sections:
+
+```text
+Goal:
+Context:
+Affected modules and data flow:
+Key decisions and trade-offs:
+Implementation summary:
+Verification:
+Limitations and follow-up:
+```
+
+### Frontend API Handoff Document
+
+Use these sections only for actual interface changes:
+
+```text
+Change summary:
+Affected endpoint or event:
+Authentication and authorization:
+Request fields:
+Response fields:
+Errors and compatibility:
+Frontend integration examples:
+Verification:
+```
+
+If the selected work has no interface contract evidence, do not manufacture a handoff document. State that it is not applicable or request the missing contract source.
+
+### Feature-Flow Troubleshooting Document
+
+Use these sections:
+
+```text
+Entry condition:
+User and system flow:
+Module, service, and data path:
+State transitions and decision branches:
+Failure symptoms and checks:
+Troubleshooting steps:
+Verification:
+```
+
+## Completion Output
+
+Report the follow-up result without hiding unselected or blocked items:
+
+```text
+Documentation follow-up:
+- Completion evidence: <command or user-provided proof>
+- Selected: <document types or none>
+- Created: <paths or none>
+- Blocked: <missing evidence or none>
+- Not created: <unselected document types>
+```
+
+## Anti-Rationalization
+
+| Excuse | Reality |
+|---|---|
+| "These documents are usually useful." | Useful is not approval. Ask the user first. |
+| "The feature is almost complete." | Wait for completion evidence before asking. |
+| "I can infer the API fields." | Only document contracts supported by current evidence. |
+| "The user selected one document, so create all three." | Selection is per document type. |
+
+## Verification
+
+Before leaving this skill, confirm:
+
+- [ ] Completion evidence exists.
+- [ ] The current Codex user received the four-option inquiry only after the automatic gate passed or for a direct documentation request.
+- [ ] Every created document had explicit user approval.
+- [ ] Every document statement is supported by current evidence.
+- [ ] Unselected documents were not created.
+- [ ] The completion output lists created, blocked, and unselected items.

package/assets/skills/devflow-docs-followup/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Completion Document Follow-Up"
+  short_description: "Offer post-completion technical and handoff docs."
+  default_prompt: "Use $devflow-docs-followup to ask which completion documents to create."

package/assets/skills/devflow-find-fault/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: devflow-find-fault
+description: "Use when a user explicitly asks to find faults, identify the biggest omission, surface blind spots, name uncertainty, run an unease check, 不安感检查, 找茬, 最大遗漏是什么, 我没有意识到什么, 需求细节是否确认, or 眼下你最没有把握的事情是什么. It can run at any task stage and does not read, require, modify, or hand off to devflow-prove, PUA, Build, Learn, or any completion state."
+---
+
+# DevFlow Find Fault
+
+Run an independent, user-requested critique of the current task materials. This skill identifies gaps and uncertainty without declaring global task status.
+
+## Entry Gate
+
+1. Confirm the user explicitly requested find-fault review.
+2. Identify the target materials from the user's request, current files, diff, requirements, tests, or supplied evidence.
+3. Ask one smallest question when the target is unclear.
+4. As an independent manual review, do not read, require, or alter `devflow-prove`, PUA, Build, Learn, or any lifecycle state.
+
+On DeepSeek Harness (DSH), run this review as a fresh `subagent` with no conversation seed so the critique is genuinely independent of the main agent's reasoning; the subagent returns findings only and never declares lifecycle status, edits files, or invokes another skill.
+
+## Post-Implementation Unease Check
+
+When target materials include an implemented feature, diff, or completion-ready result, also inspect whether the implementation has silently decided business behavior the user never confirmed. This check is for requirement-confidence gaps, not code quality or test coverage.
+
+1. Compare explicit requirements, conversation evidence, acceptance criteria, and current behavior against the implementation.
+2. List every material decision with no direct confirmation, especially: ordering, filtering, defaults, empty states, pagination, permissions, state transitions, exceptions, retries, boundary inputs, and conflicting actor outcomes.
+3. For each decision, state the encoded behavior or implicit assumption, plausible alternative interpretations, impact if wrong, the confirmation question, and a temporary recommendation.
+4. Do not invent a missing requirement. Mark the item as an inference or unknown until the user confirms it.
+
+### Unease Risk Classification
+
+| Level | Meaning | Typical signals | Completion constraint |
+|---|---|---|---|
+| **High** | A missing decision could materially change the business result, user rights, data correctness, security, money/inventory, irreversible state, or produce clearly different outcomes under reasonable interpretations. | Permission boundary, settlement rule, destructive transition, ownership, data visibility, compliance, or mutually exclusive workflow result. | Do not state that the feature fully meets requirements. Request user confirmation before that claim. |
+| **Medium** | A missing decision changes primary-path experience or rule consistency, but is reversible and does not directly threaten protected rights or correctness. | Sort priority, filter composition, default value, pagination, empty state, retry, or normal error path. | Label the implementation `pending confirmation`; explicitly surface it before delivery. |
+| **Low** | A missing decision does not change business semantics, is easy to reverse, and has a clear ordinary convention. | Non-core wording, visual spacing, or a presentational detail with no rule impact. | Record it; it does not block a completion claim. |
+
+If context is too sparse to classify safely, use the highest plausible level and explain the missing evidence. Risk level expresses impact if the assumption is wrong, not confidence in the finding.
+
+### Unease Decision Format
+
+```text
+- Decision: <unconfirmed business detail>
+  Current implementation / assumption: <observed behavior or inference>
+  Alternative interpretations: <plausible alternatives>
+  Risk: high / medium / low — <impact rationale>
+  Evidence: <explicit requirement, code/diff behavior, or none>
+  Confirmation needed: <one user-facing question>
+  Temporary recommendation: <reversible default, or do not proceed for high risk>
+```
+
+
+Always answer these questions:
+
+1. What is the biggest omission in the current situation?
+2. What might the user or agent not have recognized?
+3. What is currently least certain?
+
+Also answer every additional question the user explicitly supplies.
+
+For each answer, distinguish:
+
+- **Facts**: directly supported by inspected material.
+- **Inference**: a reasoned conclusion that needs confirmation.
+- **Unknowns**: missing material that prevents a reliable conclusion.
+- **Next step**: the smallest manual action that would reduce the uncertainty.
+
+## Required Output
+
+```text
+Find-fault target: <scope reviewed>
+Questions and answers:
+- Biggest omission: <answer>; facts: <facts>; inference: <inference or none>; unknowns: <unknowns or none>; confidence: high/medium/low; next step: <smallest manual action>
+- Unrecognized blind spot: <answer>; facts: <facts>; inference: <inference or none>; unknowns: <unknowns or none>; confidence: high/medium/low; next step: <smallest manual action>
+- Least certain point: <answer>; facts: <facts>; inference: <inference or none>; unknowns: <unknowns or none>; confidence: high/medium/low; next step: <smallest manual action>
+- User question: <question>; answer: <answer>; facts: <facts>; inference: <inference or none>; unknowns: <unknowns or none>; confidence: high/medium/low; next step: <smallest manual action>
+Unease check: run / not applicable — <why>
+- Decision: <unconfirmed business detail>; current implementation / assumption: <observed behavior or inference>; alternative interpretations: <plausible alternatives>; risk: high/medium/low — <impact rationale>; evidence: <facts or none>; confirmation needed: <one user-facing question>; temporary recommendation: <reversible default, or do not proceed for high risk>
+Findings:
+- Critical: <finding or none>; evidence: <facts>; confidence: high/medium/low
+- Important: <finding or none>; evidence: <facts>; confidence: high/medium/low
+- Observation: <finding or none>; evidence: <facts>; confidence: high/medium/low
+Context limitations: <unavailable material or none>
+Suggested next action: <manual action for the user, or none>
+```
+
+`Suggested next action` is advice only. Do not automatically edit files, create tasks, invoke another skill, or change lifecycle state.
+
+## Anti-Rationalization
+
+| Excuse | Reality |
+|---|---|
+| "There is no proof of a problem." | Name the uncertainty instead of inventing certainty. |
+| "A hypothesis is enough." | Label hypotheses as inference and show their evidence gap. |
+| "The default questions are enough." | Answer each explicit user question too. |
+| "Another skill has a status." | Do not read or change that status. |
+| "The implementation is reasonable." | Reasonable defaults are still unconfirmed decisions; run the unease check. |
+| "Tests pass, so requirements are met." | Tests prove encoded behavior, not that the user confirmed its business rule. |
+| "It is only a UI detail." | Classify impact first; ordering, filters, defaults, and empty states can change user outcomes. |
+
+## Verification
+
+Before leaving this skill, confirm:
+
+- [ ] The user explicitly requested find-fault review.
+- [ ] All three default questions were answered.
+- [ ] Each user-supplied question was answered.
+- [ ] Facts, inference, unknowns, confidence, next steps, and limitations are visible.
+- [ ] For implemented targets, the unease check ran and every material unconfirmed decision has risk, rationale, confirmation question, and temporary recommendation.
+- [ ] High-risk unease decisions are not presented as fully requirement-complete; medium-risk decisions are marked `pending confirmation`.
+- [ ] No lifecycle state, code, or other skill was changed or invoked.

package/assets/skills/devflow-learn/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: devflow-learn
+description: "Use after every verified DevFlow PASS to proactively extract useful reusable knowledge, or when the user says wrong, not like that, changed wrong, remember, learn, 沉淀, 下次不要, 放错位置, 改歪了, 没改对, 不是我要的, 少了, 少个, 缺漏, 遗漏, or when a repeated user correction, reusable pitfall, project convention, or .copilot learning-card update appears."
+---
+
+# DevFlow Learn
+
+Turn verified work, corrections, and pitfalls into reusable intercept rules without bloating context.
+
+## Completion Review
+
+Every `devflow-prove` judgment of `PASS` must enter this lightweight review before final completion reporting. Review both successful and failed paths from the completed task; do not wait for a correction or pitfall signal.
+
+Extract only knowledge that can help a future task:
+
+- a proven implementation or reuse pattern
+- a decision tied to a constraint or tradeoff
+- an effective validation method
+- a non-obvious repository convention or invariant
+- a costly, counterintuitive, repeated, or project-wide lesson
+- a confirmed project-business fact that may require knowledge-package maintenance
+
+`PASS` requires the review, not a new record. If no useful reusable knowledge remains after classification, report that result and create nothing.
+
+| Review result | Action | Store |
+|---|---|---|
+| Reusable execution experience or proven work pattern | Create or update one focused card | `.copilot/cards/` |
+| Confirmed business fact changed | Report a project-knowledge candidate and wait for user confirmation | `docs/project-knowledge/` after confirmation via `devflow-project-knowledge` |
+| Ordinary detail, one-off fact, already-covered lesson, or pure refactor without insight | Report no useful record | none |
+
+Project-knowledge candidates include changed domain semantics, rules, boundaries, entity/DTO/enum meaning, API or table boundaries, module responsibility, job behavior, and task entry points. `devflow-learn` must not update the package itself or infer business facts without evidence.
+
+## Process
+
+1. Detect the learning signal:
+   - `devflow-prove` `PASS` completion review, user correction, repeated user correction, repeated user challenge, repeated missing-piece complaint, changed-wrong result, wrong assumption, repeated failure, skipped validation, missed project convention, misplaced content, or non-obvious pitfall
+2. Probe `.copilot/LEARNING_INDEX.md`. Read `.copilot/LEARNING_INDEX.md` when it exists; otherwise record that learning recall is absent.
+3. Match the current task against card Trigger and Scope. Read only matched cards; do not load all `.copilot/cards/**`.
+4. Extract a candidate from the task's implementation, decisions, proof, and business impact.
+5. Decide whether to record:
+   - record if the candidate is cross-task reusable and proven useful, costly if missed, counterintuitive, non-obvious, repeated, or project-wide
+   - report a project-knowledge candidate if code-backed business semantics changed; wait for user confirmation before calling `devflow-project-knowledge`
+   - skip if it is ordinary narration, a one-off fact, already covered, or too context-specific
+6. Create `.copilot/LEARNING_INDEX.md`, `.copilot/cards/`, and one focused card only when the result belongs in project learning; do not create empty learning storage after a no-record review.
+7. Update `.copilot/LEARNING_INDEX.md` when a card changed.
+8. Report learning closure before completion.
+
+## Repeat Correction Gate
+
+Repeated correction is not optional learning. If the user corrects the same boundary, placement, workflow, or wording rule twice in one task lifecycle, create or update a learning card before claiming completion.
+
+Repeated challenge is also not optional learning. If the user says the result was wrong, changed wrong, missed the target, missing pieces, or not what they wanted twice in one task lifecycle, record the next-time intercept after `devflow-pua` identifies the reusable mistake pattern.
+
+Repeated missing-piece feedback is also not optional learning when the same task already went through recovery. If the user says "少了这个/少个那个/缺漏/遗漏/漏了" after a prior attempt or after a method switch, record the missing coverage pattern and the next method switch rule.
+
+Required pressure-recovery card action:
+
+```text
+- Trigger: <task signal>, user challenge, changed wrong, repeated miss, repeated missing-piece complaint
+- Lesson: <what goal/result was misunderstood>
+- Next action: Next time encountering <X>, first stop the current path, classify the user-view miss, build a Coverage Map for missing pieces, restate the desired result, ask or infer the pointed result questions, then switch to a different/opposite method before editing.
+```
+
+Misplaced content counts as a reusable pitfall when a rule, prompt, method detail, plan, or explanation was put in the wrong artifact, such as:
+
+- README-style explanation inside `AGENTS.md`
+- runtime method details under `docs/` instead of `skills/*/references/*`
+- brand/project summaries inside skill `description`
+- plan or audit material inside a runtime prompt
+
+Required card action:
+
+```text
+- Trigger: <artifact or task signal>, wrong place, misplaced content, repeated correction
+- Lesson: <what was placed in the wrong artifact>
+- Next action: Next time editing <artifact>, first check the target owner, then put <content type> in <correct place>, not <wrong place>.
+```
+
+## Storage Contract
+
+Project learning lives in:
+
+```text
+.copilot/
+  LEARNING_INDEX.md
+  cards/<short-kebab-name>.md
+```
+
+Keep cards small. A card must answer what to do next time.
+
+Learning storage is lazily created only by this skill after a qualifying reusable execution lesson. Recall does not create it.
+
+## Knowledge Boundaries
+
+| Store | Owns | Does not own |
+|---|---|---|
+| `graphify-out/` | Structural code graph, communities, and dependency relationships | Execution lessons or curated business guidance |
+| `.copilot/cards/` | Execution experience, intercept rules, and proven work patterns | Business reference documentation |
+| `docs/project-knowledge/` | Curated, code-backed business facts, boundaries, and task entry points | Agent mistakes or raw implementation history |
+
+Handoff: `devflow-prove PASS` -> `devflow-learn` review -> project-knowledge candidate -> user confirmation -> `devflow-project-knowledge` lazy maintenance of `docs/project-knowledge/`. Only after a verified feature implementation with an actual source-behavior or interface-contract change may `devflow-learn` hand off to `devflow-docs-followup` for an optional documentation inquiry. Do not automatically hand off validation-only, documentation-only, rule-only, skill-only, or no-diff `PASS` results.
+
+## Card Format
+
+```text
+# <Short Name>
+
+- Trigger: <next time signal>
+- Lesson: <what this work taught>
+- Next action: Next time encountering <X>, first do <Y>, do not do <Z>.
+- Scope: session | project | global | skill | module
+- Related: <files or commands>
+- Evidence: <checked source, command, or verified correction that supports this card>
+- Invalidation: <changed contract, failed proof, or review trigger that requires this card to be revised or retired>
+```
+
+## Index Format
+
+```text
+# Learning Index
+
+Read this index first. Only read a card when its trigger matches the current task.
+
+| Card | Trigger | Scope | Confidence |
+|---|---|---|---:|
+| [Card Name](cards/card-name.md) | trigger words | project | 0.5 |
+```
+
+## Promotion Rules
+
+| Signal count | Action |
+|---:|---|
+| 1 | Create/update card, confidence 0.3-0.5 |
+| 2 | Raise confidence and force recall before acting |
+| 3 | Propose `AGENTS.md` or platform rule update |
+| 4+ | Propose skill or command automation |
+| User explicitly says remember/learn/沉淀 | Promote immediately if scope is clear |
+
+## Completion Output
+
+Always report:
+
+```text
+Learning closure:
+- Learning signal: PASS review/correction/pitfall/none
+- Recall record: none/index/card
+- Knowledge recall: none/learning index + matched card/project knowledge candidate
+- Review result: learning card/project-knowledge candidate/no useful record
+- New sediment: none/learning card/rule/skill
+- Next intercept: next time <X>, first do <Y>, do not do <Z>
+```
+
+## Anti-Rationalization
+
+| Excuse | Reality |
+|---|---|
+| "This was just a correction." | Corrections reveal future intercepts. Check if reusable. |
+| "The task passed, so there is nothing to learn." | PASS proves the work; proactively review its implementation, decision, proof, and business impact. |
+| "The user already told me where it goes." | Repeated placement corrections must become a card so the next run recalls them before acting. |
+| "The user only complained about quality." | Repeated challenge is a reusable signal when the miss pattern can repeat. |
+| "I'll remember it." | Memory without an index is not recallable. |
+| "Let's store everything." | Too many cards become noise; record only repeatable or costly lessons. |
+| "Read all cards just in case." | Index first, matched card only. |
+
+## Verification
+
+Before leaving this skill, confirm:
+
+- [ ] Learning signal was classified.
+- [ ] Every `PASS` ran a proactive completion review before final completion reporting.
+- [ ] `LEARNING_INDEX.md` was checked or created.
+- [ ] Only matched cards were read.
+- [ ] Repeated user corrections, repeated user challenges, and misplaced content were recorded or explicitly classified as already covered.
+- [ ] New or updated card has trigger, lesson, next action, scope, related files, evidence, and invalidation condition.
+- [ ] Business-semantic changes were reported as candidates and await user confirmation before knowledge-package maintenance.
+- [ ] Completion output includes learning closure.