@olegkoval/agent-skills 1.59.2 → 1.60.0

package/.github/copilot-instructions.md

@@ -31,6 +31,7 @@ Available reusable prompt files:
 - release-day: .github/prompts/release-day.prompt.md
 - changelog-generator: .github/prompts/changelog-generator.prompt.md
 - store-listing-copy: .github/prompts/store-listing-copy.prompt.md
+- ingest-publication-slice: .github/prompts/ingest-publication-slice.prompt.md
 - product-builder: .github/prompts/product-builder.prompt.md
 - mvp-oneshot: .github/prompts/mvp-oneshot.prompt.md
 - ux-ui-audit-loop: .github/prompts/ux-ui-audit-loop.prompt.md

package/.github/prompts/ingest-publication-slice.prompt.md

@@ -0,0 +1,43 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Build and verify a small end-to-end publication path for validated ingested data, including atomic persistence, read fallback, and static artifact precedence."
+---
+
+Use the olko:ingest-publication-slice skill.
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · Repeatedly implement a validated ingest-to-publication flow with atomic persistence, fallback reads, and static artifact precedence.*
+
+# Ingest Publication Slice
+
+Use this workflow when an ingest pipeline must make a validated record available immediately while a static or cached publication artifact may be generated later.
+
+## Define the contract
+
+Before changing code, read the repository instructions and trace the current path from ingest entry point through validation, job completion, persistence, request handling, and static artifact generation. Record existing invariants and preserve unrelated work.
+
+Write acceptance criteria for one complete slice:
+
+- Only a completed, validated active dataset can be published.
+- The persistent publication record and terminal ingest state commit atomically.
+- The canonical read path can serve from the persistent record when no static artifact exists.
+- A static artifact remains authoritative once present, if that is the established product contract.
+- Retries are idempotent, and collisions, invalid states, hidden records, and takedowns cannot publish.
+
+Adapt these criteria to the actual product contract. Do not invent a static-artifact precedence rule if the system has none.
+
+## Implement test-first
+
+Use the repository's required test command and style. Add focused failing tests before implementation for:
+
+1. A valid ingest publishes the record and terminal state together.
+2. A failure between writes leaves neither half committed.
+3. The canonical read path uses the persisted record when the artifact is absent.
+4. The artifact wins when both sources exist, when precedence is required.
+5. Repeated delivery is safe and invalid, hidden, colliding, or withdrawn records stay unpublished.
+
+Test the production boundary and transaction behavior, not only helper functions. Keep the change to the smallest vertical slice; avoid unrelated schema or routing refactors.
+
+## Verify the composed path
+
+Run the focused tests, then the repository's required broader checks. Inspect the final diff and trace the completed path again from ingest through the canonical response. Confirm behavior for retries, partial failures, and transitions from no artifact to artifact present. Report any unavailable integration or deployment evidence explicitly.

package/.github/prompts/self-critique.prompt.md

@@ -1,7 +1,7 @@
 <!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
 
 ---
-description: "Adversarially critique your own last answer: spawn a critic agent that verifies claims against live sources, finds the related issue or pattern you missed, then loop until satisfied and report where you were wrong, iterations-to-satisfy, the numeric improvement, and a final score."
+description: "Adversarially critique your own last answer: a blind critic agent re-derives and verifies every claim against live sources, the score is computed from a labelled claim ledger, you revise under a ratchet, restate the corrected answer, and turn each caught error into a durable rule with a fire counter."
 ---
 
 Use the olko:self-critique skill.
@@ -33,40 +33,102 @@ durable rule has bought every answer after it.
 Do not use for trivial one-shot replies or simple chat. The overhead only pays off on load-bearing
 answers.
 
+**Standalone Cursor installation.** Use the generated Cursor adapter or the full skill package,
+including its `scripts/` directory. Copying only `SKILL.md` is insufficient for this workflow,
+which calls the bundled scripts.
+
 ## Procedure
 
-1. **Snapshot the target.** Capture your last substantial answer verbatim, plus the concrete claims
-   it makes and the source each claim rests on. This is `v1`.
+1. **Snapshot the target.** Capture your last substantial answer verbatim and the original task
+   text. This is `v1`.
 
-   Write the claim list before you re-read the answer's prose, and put a real receipt against each
+   Write your claim list before you re-read the answer's prose, and put a real receipt against each
    claim: a quoted field, a `file:line` whose body you actually opened, a command and its output.
-   A claim you cannot receipt at snapshot time is already a finding - mark it `unverified` yourself
+   A claim you cannot receipt at snapshot time is already a finding - mark it `unverifiable` yourself
    rather than waiting for the critic to find it. Grep output, a file name, a path, an endpoint
    string, or the behaviour of a sibling module are not receipts for what code does; they prove
    those things exist, not what they do.
 
-2. **Spawn the critic.** Launch one independent agent with live-source access (issue tracker, code
-   host, error monitor, the repo). Use the prompt template below. The critic must return: `score`
-   (0-100), `verdict` (AGREE / AGREE-WITH-CAVEATS / DISAGREE), `where_wrong` (list), `missed`
-   (related issues or patterns you failed to surface), `unverifiable` (claims it could not confirm),
-   `fixes` (ranked, actionable), and `shapes` (the reusable class of reasoning behind each
-   `where_wrong` item, which Step 5 turns into the rule).
-
-3. **Decide and loop.** Stop if `score >= 90` OR no actionable `fixes` remain. Otherwise revise the
-   answer using the fixes to produce `v2`, then re-spawn the critic to score `v2`. Repeat.
+   Save the list to `.self-critique/author-claims.json` as an array of
+   `{ id, text, load_bearing, receipt }`. Do NOT show it to the critic in round one.
+
+   **Replay pass.** Before spawning the critic, check the answer against every stored rule. Resolve
+   the memory dir as the auto-memory dir for the current project, else the repo's `.claude/memory`;
+   if neither exists, skip replay, evidence-check, and prune with a one-line note. Run
+   `node <skill>/scripts/rule-store.mjs checklist --dir <memory dir>`, then open each listed rule's
+   memory file and read its body before testing the answer against it. The checklist's names and
+   descriptions alone are insufficient. Tag each hit `(recurring)` in the report and record it with
+   `node <skill>/scripts/rule-store.mjs fire <name> --dir <memory dir> --date <today>`.
+   Fire counters and pruning apply only to rules in this memory directory. Rules routed to
+   `CLAUDE.md`, `AGENTS.md`, or the shared store are neither counted nor pruned.
+
+2. **Spawn the critic (blind).** Launch one independent agent with live-source access (issue tracker,
+   code host, error monitor, the repo). Round one input is the original task text and the answer
+   verbatim, nothing else: the critic extracts the claims itself and never sees your list or sources.
+   Use the prompt template below. The critic must return one fenced JSON block with `claims` (its own
+   list, each `{ text, load_bearing, status, checked_by, receipt }`), `missed`, `where_wrong`,
+   `shapes` and `verdict` (AGREE / AGREE-WITH-CAVEATS / DISAGREE). There is no `score` field: the
+   score is computed in Step 2b.
+
+2b. **Merge into the ledger.** Match the critic's claims to yours by meaning and set `origin` on
+   each: `both`, `author` (only you found it), `critic` (only the critic found it). Every critic
+   finding with `checked_by: inferred` must be re-verified by you before it may become `verified`
+   or `refuted`; if you cannot verify it, it stays `inferred`. Both statuses require
+   `checked_by: command` or `checked_by: read` and a non-empty receipt; validation rejects inferred evidence or a missing
+   receipt. Save `.self-critique/ledger-v1.json`, then run
+   `node <skill>/scripts/claim-ledger.mjs score .self-critique/ledger-v1.json` and
+   `node <skill>/scripts/claim-ledger.mjs summary .self-critique/ledger-v1.json` (an invalid ledger
+   exits 2 and prints the errors as JSON).
+   Claims found by only one side are reported under their own heading, "Asymmetric claims".
+
+   Ledger shape (`version` is always `1`):
+
+   ```json
+   { "version": 1,
+     "claims": [{ "id": "c1", "text": "...", "load_bearing": true, "origin": "both",
+                  "status": "verified", "checked_by": "command", "receipt": "quoted output" }],
+     "missed": [{ "id": "m1", "text": "...", "load_bearing": false, "checked_by": "read" }] }
+   ```
+
+   - `origin`: `author` | `critic` | `both`
+   - `status`: `verified` | `refuted` | `unverifiable` | `inferred`
+   - `checked_by`: `command` (run, output quoted) | `read` (file or record opened, quoted) |
+     `inferred` (reasoning only). Required on `missed` items too; an `inferred` missed item is not
+     penalised. A `verified` or `refuted` claim may not use inferred evidence and requires a
+     non-empty receipt.
+
+3. **Decide and loop.** Accept a score of at least 90 only after all fixable findings are resolved
+   or explicitly qualified in the answer and report; otherwise continue the critique loop. Stop
+   when that condition holds, OR no ledger item is left that a revision could fix, OR 3 rounds have run.
+   Otherwise revise the answer to produce `v2`, write `ledger-v2.json`, and run
+   `node <skill>/scripts/claim-ledger.mjs ratchet .self-critique/ledger-v1.json .self-critique/ledger-v2.json`
+   on the previous and new ledger: a lower re-score discards the revision, and you keep the winner. Round
+   two and later hand the critic your receipts for the still-open claims (it is no longer blind).
    **Hard cap: 3 critic rounds.** (A known ceiling: raise it only if a round is still finding real,
    fixable defects.)
 
-4. **Report, always, even after a single round:**
+   **Cost.** The critic runs on a mid-tier model (Sonnet class) by default. Escalate one tier only
+   when a mid-tier round found nothing and the answer is load-bearing. When the budget is tight,
+   verify load-bearing claims first.
+
+4. **Report, always, even after a single round.** In this order:
+   - **Corrected answer (`v_final`)** - restated in full, not as a diff, so the user can act on it
+     without reading anything else. After a single round with no revision, restate `v1` unchanged.
+   - **Claim ledger** - run `node <skill>/scripts/claim-ledger.mjs summary <ledger for v_final>`
+     and `node <skill>/scripts/claim-ledger.mjs score <ledger for v_final>` using the ledger for
+     whichever version the ratchet accepted (for example, `.self-critique/ledger-v2.json`). Report
+     that table and its computed score.
    - **Where you were wrong** - consolidated, each item with the receipt the critic cited.
-   - **Iterations to satisfy** - how many critic rounds it took to reach the stop condition (1 means
-     it was solid on the first pass).
-   - **Improvement in numbers** - the score trajectory, for example `72 -> 88 -> 94 (+22 pts, +31%)`.
-     If only one round ran, state `no revision needed`.
-   - **Final score** - the critic's last score and verdict.
+   - **Asymmetric claims** - claims only you found, and claims only the critic found.
+   - **Recurring rules fired** - each stored rule the replay pass hit, with its new `fires` count.
+   - **Iterations to satisfy** - how many critic rounds it took (1 means it was solid first pass).
+   - **Score trajectory** - for example `72 -> 88 -> 94 (+22 pts)`, all computed scores. If only one
+     round ran, state `no revision needed`.
    - **Unverifiable** - anything you should not present as fact.
-   - **Declined fixes** - any ranked fix you chose not to take, and the reason. Silently dropping a
-     fix looks identical to missing it.
+   - **Declined findings** - ledger items you chose not to fix, with the reason. Silently dropping
+     one looks identical to missing it.
+   - **Rules written** - where each rule went and what it says (see Step 5).
+   - **Rules proposed for deletion** - the candidates from the prune pass, or `none`.
 
 5. **Convert the outcome into a durable rule.** See below. Skipping this step is what makes the
    same critique necessary again next week.
@@ -117,31 +179,50 @@ Before writing to shared persistence, redact the incident evidence, including wh
 `context-repo` or `shared-knowledge-artifact`, while still including the incident and its dated
 receipt. This redaction requirement does not apply to local agent memory or repository-rule writes.
 
-**Dedupe before writing.** Read the store first. If a rule of the same shape exists, sharpen it and
-add this incident as further evidence rather than creating a second entry. Link related rules
-instead of restating them.
+**Dedupe before writing.** Read the store first. If a rule of the same shape exists, add one dated
+evidence line to it instead of creating a second entry, with at most three evidence lines per rule.
+A fourth incident means the rule named the incident, not the shape: rewrite the rule text and keep
+the three most recent evidence lines. Link related rules instead of restating them. Only when the
+memory directory resolved in Step 1 exists, run
+`node <skill>/scripts/rule-store.mjs evidence-check --dir <memory dir>` before writing and report
+any rule it flags. Skip this command when neither supported memory directory exists.
+
+**Memory rule identity and counters.** Mark each rule stored by this workflow with
+`rule_store: self-critique` under `metadata:` in its memory file's frontmatter. Mark an existing
+rule only after reading it and confirming it belongs to this workflow. Only marked rules are
+pruning candidates; unrelated project and user memories are excluded. A memory rule's `fires` and
+`last_fired` live under `metadata:` and are written only by `fire`. Rules routed to `CLAUDE.md`,
+`AGENTS.md`, or the shared store are neither counted nor pruned.
+
+**Prune pass.** At the end of this step, only when a valid memory directory is available, run
+`node <skill>/scripts/rule-store.mjs prune --dir <memory dir> --idle-days 60`. List the candidates
+in the report under "Rules proposed for deletion". Skip this command when neither supported memory
+directory exists. Never delete a rule without the user's reply.
 
 **Then close the loop.** State in your report where the rule was written and what it says, so the
 user can veto it. A rule the user has not seen is a rule they cannot correct.
 
 ## Critic prompt template
 
-Pass this to the critic agent, filling in the two placeholders. It is deliberately adversarial:
+Pass this to the critic agent, filling in the two placeholders (`{{TASK}}`, `{{ANSWER}}`). It is deliberately adversarial:
 the default stance is that the answer is wrong until a live source proves otherwise.
 
 > You are an adversarial reviewer. Your job is to verify and, where possible, **refute** the answer
 > below. Default to skepticism: assume a claim is wrong until a live source proves it. Address every
 > comment **directly to the author** ("You claimed X; the source says Y").
 >
+> **The task the author was given (verbatim):**
+> {{TASK}}
+>
 > **The answer under review (verbatim):**
 > {{ANSWER}}
 >
-> **Its claims and the source each rests on:**
-> {{CLAIMS_AND_SOURCES}}
+> You are not given the author's claims or sources. Extract the claims yourself.
 >
 > **Do this:**
-> 1. Re-verify every claim against the **live** source (issue tracker / code host / error monitor /
->    the repo) - never trust the answer's own summary. Quote the field, line, PR body, or issue you
+> 1. List every claim the answer makes, marking each `load_bearing` (the user would act on it).
+>    Re-verify each against the **live** source (issue tracker / code host / error monitor / the
+>    repo) - never trust the answer's own summary. Quote the field, line, PR body, or issue you
 >    checked.
 > 2. **Check similar and related issues, and find patterns.** Is this part of a cluster? Is there a
 >    closer sibling, parent epic, or duplicate the answer should have surfaced but did not? Name it
@@ -151,19 +232,62 @@ the default stance is that the answer is wrong until a live source proves otherw
 >    a proven root cause?
 > 4. List exactly **where the author was wrong or imprecise**, and what they **missed**.
 > 5. Flag any claim you **could not verify** so it is not presented as fact.
+> 6. Label every finding with `checked_by`: `command` (you ran it and quote the output), `read` (you
+>    opened the file or record and quote it), `inferred` (reasoning only).
 >
-> **Output, terse, with a receipt for every line:**
-> - `verdict`: AGREE | AGREE-WITH-CAVEATS | DISAGREE
-> - `score`: 0-100 (rubric: 100 = every claim verified, nothing missed, confidence correctly
->   calibrated; subtract for each unverified claim, each missed sibling or pattern, and each
->   over- or under-statement)
-> - `where_wrong`: bullet list, each with its source receipt
-> - `missed`: related issues or patterns the author failed to surface, with IDs
-> - `unverifiable`: claims that need a source you do not have
-> - `fixes`: ranked, actionable - what to change to raise the score
+> **Output, terse, one fenced JSON block, a receipt for every item:**
+> - `claims`: your own list, each `{ text, load_bearing, status, checked_by, receipt }` with `status`
+>   one of `verified` | `refuted` | `unverifiable` | `inferred`
+> - `missed`: related issues or patterns the author failed to surface, each
+>   `{ text, load_bearing, checked_by, receipt }`, with IDs
+> - `where_wrong`: bullet list, each with its source receipt and `checked_by`
 > - `shapes`: for each item in `where_wrong`, the class of reasoning that produced it, stated so it
 >   would apply to a different task ("a conclusion drawn from evidence that does not cover the
 >   claim"), not the incident itself. Say `one-off` when the error has no reusable shape.
+> - `verdict`: AGREE | AGREE-WITH-CAVEATS | DISAGREE
+>
+> Do not output a score. It is computed from your claims.
+
+### Score anchors
+
+The score is `100` minus penalties, floored at 0. Calibrate against these three ledgers (all claims
+`origin: both`; `node <skill>/scripts/claim-ledger.mjs anchors` prints them as JSON).
+
+**Strong, score 95**
+
+| id | load_bearing | status | checked_by |
+| --- | --- | --- | --- |
+| a1 | no | inferred | inferred |
+
+**Middling, score 72**
+
+| id | load_bearing | status | checked_by |
+| --- | --- | --- | --- |
+| b1 | no | refuted | read |
+| b2 | no | refuted | read |
+| b3 | no | unverifiable | read |
+| b4 | no | unverifiable | read |
+
+**Weak, score 40**
+
+| id | load_bearing | status | checked_by |
+| --- | --- | --- | --- |
+| c1 | yes | refuted | read |
+| c2 | yes | refuted | read |
+| c3 | yes | unverifiable | read |
+
+Penalties:
+
+| Finding | Points off |
+| --- | --- |
+| refuted, load-bearing | 25 |
+| refuted | 10 |
+| unverifiable, load-bearing | 10 |
+| unverifiable | 4 |
+| inferred, accepted | 5 |
+| missed, load-bearing | 15 |
+| missed | 5 |
+| verified but found only by the critic | 5 |
 
 ## Optional: auto-offer via a Claude Code Stop hook
 
@@ -209,10 +333,10 @@ message.
   `iterations: 1, no revision needed` and the single score rather than forcing a revision.
 - Diversity beats redundancy: if a claim can fail in more than one way, give the critic distinct
   lenses (correctness, completeness, does-it-reproduce) instead of repeating the same check.
-- The critic verifies against live sources; it does not rewrite the answer. You revise; it re-scores.
-- Re-score by messaging the same critic rather than spawning a fresh one, and hand it the receipts
-  for whatever it could not verify in the earlier round, so round two spends its budget on the
-  claims still standing instead of re-deriving the ones already settled.
+- The critic verifies against live sources; it does not rewrite the answer or score it. You revise;
+  the score is recomputed from the ledger.
+- In round two, hand the critic your receipts for the claims still open, so it spends its budget on
+  the claims still standing instead of re-deriving the ones already settled.
 - A critic finding you disagree with is worth one challenge. Put the reasoning to it and let it rule;
   if it concedes, that is a real answer for the report, and the reasoning is what the user needs to
   see either way.

package/.kiro/steering/ingest-publication-slice.md

@@ -0,0 +1,42 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+inclusion: manual
+description: "Build and verify a small end-to-end publication path for validated ingested data, including atomic persistence, read fallback, and static artifact precedence."
+---
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · Repeatedly implement a validated ingest-to-publication flow with atomic persistence, fallback reads, and static artifact precedence.*
+
+# Ingest Publication Slice
+
+Use this workflow when an ingest pipeline must make a validated record available immediately while a static or cached publication artifact may be generated later.
+
+## Define the contract
+
+Before changing code, read the repository instructions and trace the current path from ingest entry point through validation, job completion, persistence, request handling, and static artifact generation. Record existing invariants and preserve unrelated work.
+
+Write acceptance criteria for one complete slice:
+
+- Only a completed, validated active dataset can be published.
+- The persistent publication record and terminal ingest state commit atomically.
+- The canonical read path can serve from the persistent record when no static artifact exists.
+- A static artifact remains authoritative once present, if that is the established product contract.
+- Retries are idempotent, and collisions, invalid states, hidden records, and takedowns cannot publish.
+
+Adapt these criteria to the actual product contract. Do not invent a static-artifact precedence rule if the system has none.
+
+## Implement test-first
+
+Use the repository's required test command and style. Add focused failing tests before implementation for:
+
+1. A valid ingest publishes the record and terminal state together.
+2. A failure between writes leaves neither half committed.
+3. The canonical read path uses the persisted record when the artifact is absent.
+4. The artifact wins when both sources exist, when precedence is required.
+5. Repeated delivery is safe and invalid, hidden, colliding, or withdrawn records stay unpublished.
+
+Test the production boundary and transaction behavior, not only helper functions. Keep the change to the smallest vertical slice; avoid unrelated schema or routing refactors.
+
+## Verify the composed path
+
+Run the focused tests, then the repository's required broader checks. Inspect the final diff and trace the completed path again from ingest through the canonical response. Confirm behavior for retries, partial failures, and transitions from no artifact to artifact present. Report any unavailable integration or deployment evidence explicitly.

package/.windsurf/rules/ingest-publication-slice.md

@@ -0,0 +1,41 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Build and verify a small end-to-end publication path for validated ingested data, including atomic persistence, read fallback, and static artifact precedence."
+---
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · Repeatedly implement a validated ingest-to-publication flow with atomic persistence, fallback reads, and static artifact precedence.*
+
+# Ingest Publication Slice
+
+Use this workflow when an ingest pipeline must make a validated record available immediately while a static or cached publication artifact may be generated later.
+
+## Define the contract
+
+Before changing code, read the repository instructions and trace the current path from ingest entry point through validation, job completion, persistence, request handling, and static artifact generation. Record existing invariants and preserve unrelated work.
+
+Write acceptance criteria for one complete slice:
+
+- Only a completed, validated active dataset can be published.
+- The persistent publication record and terminal ingest state commit atomically.
+- The canonical read path can serve from the persistent record when no static artifact exists.
+- A static artifact remains authoritative once present, if that is the established product contract.
+- Retries are idempotent, and collisions, invalid states, hidden records, and takedowns cannot publish.
+
+Adapt these criteria to the actual product contract. Do not invent a static-artifact precedence rule if the system has none.
+
+## Implement test-first
+
+Use the repository's required test command and style. Add focused failing tests before implementation for:
+
+1. A valid ingest publishes the record and terminal state together.
+2. A failure between writes leaves neither half committed.
+3. The canonical read path uses the persisted record when the artifact is absent.
+4. The artifact wins when both sources exist, when precedence is required.
+5. Repeated delivery is safe and invalid, hidden, colliding, or withdrawn records stay unpublished.
+
+Test the production boundary and transaction behavior, not only helper functions. Keep the change to the smallest vertical slice; avoid unrelated schema or routing refactors.
+
+## Verify the composed path
+
+Run the focused tests, then the repository's required broader checks. Inspect the final diff and trace the completed path again from ingest through the canonical response. Confirm behavior for retries, partial failures, and transitions from no artifact to artifact present. Report any unavailable integration or deployment evidence explicitly.

package/README.md

@@ -32,7 +32,7 @@ These skills are opinionated by design. They encode working defaults, preferred
 
 ## Start here
 
-Ten skills across different plugins that cover the most common jobs. Full catalog is below.
+Eleven skills across different plugins that cover the most common jobs. Full catalog is below.
 
 | What you're doing | Skill | Key principle |
 |--------------------|-------|----------------|
@@ -43,6 +43,7 @@ Ten skills across different plugins that cover the most common jobs. Full catalo
 | Closing out a finished piece of work | [wrap-up](plugins/olko-reflection/skills/wrap-up/SKILL.md) (`olko:wrap-up`) | Verify the objective and propose safe cleanup |
 | Running a recurring engineering retrospective | [retro-analysis](plugins/olko-reflection/skills/retro-analysis/SKILL.md) (`olko:retro-analysis`) | Evidence from delivery and code, not vibes |
 | Going from idea to a shippable MVP | [mvp-oneshot](plugins/olko-product/skills/mvp-oneshot/SKILL.md) (`olko:mvp-oneshot`) | Scope for one week, not the whole roadmap |
+| Publishing validated ingested data immediately | [ingest-publication-slice](plugins/olko-product/skills/ingest-publication-slice/SKILL.md) (`olko:ingest-publication-slice`) | Test the atomic write, fallback read, and artifact precedence end to end |
 | Ramping up on an unfamiliar codebase fast | [crash-course](plugins/olko-reflection/skills/crash-course/SKILL.md) (`olko:crash-course`) | Source-grounded, timed, and testable |
 | Cutting a release from ready-code to submitted-build | [release-day](plugins/olko-release/skills/release-day/SKILL.md) (`olko:release-day`) | One orchestrated pass, not five manual steps |
 | Starting the workday with the queue synced | [morning-routine](plugins/olko-obsidian/skills/morning-routine/SKILL.md) (`olko:morning-routine`) | Chain the routines instead of running them separately |
@@ -264,7 +265,7 @@ Ship a release: semantic-release setup, changelogs, store listing copy, release-
 | [changelog-generator](plugins/olko-release/skills/changelog-generator/SKILL.md) | Transforms git commits into polished user-facing changelogs by categorising changes and rewriting technical commit messages | Preparing release notes, a CHANGELOG entry, or "what changed since the last release"; for setting up the release pipeline itself use semantic-release-beta |
 | [store-listing-copy](plugins/olko-release/skills/store-listing-copy/SKILL.md) | Generates platform-validated App Store, Google Play, and Connect IQ store listing copy (title, subtitle, description, what's new, keywords) from a git changelog | Writing store copy before submitting to apple-store-submit or the garmin-watchface store workflow |
 
-### olko-product (6)
+### olko-product (7)
 
 Take a product idea to a shippable build: MVP passes, full-stack scaffolds, UX/UI quality loops, launch plans.
 
@@ -275,6 +276,7 @@ Take a product idea to a shippable build: MVP passes, full-stack scaffolds, UX/U
 | [ux-ui-audit-loop](plugins/olko-product/skills/ux-ui-audit-loop/SKILL.md) | Audits and improves a web UI through browser evidence, severity triage, minimal fixes, and before/after verification | The user says "audit this UI", "fix the UX", "review this page visually", "make this page polished", or asks for an autonomous screenshot-and-fix loop |
 | [frontend-direction](plugins/olko-product/skills/frontend-direction/SKILL.md) | Chooses a distinctive, coherent visual direction and source-backed components before writing frontend code | Building a new page or a substantial UI redesign, or making an interface less generic; small fixes keep the existing design |
 | [starter-rules](plugins/olko-product/skills/starter-rules/SKILL.md) | Loads and enforces hard rules for every oleg-koval/* starter | Ensuring 300-line files, E2E tests, pre-commit hooks, Vertical Slice architecture, and KISS/DRY/SOLID |
+| [ingest-publication-slice](plugins/olko-product/skills/ingest-publication-slice/SKILL.md) | Builds a test-first ingest-to-publication path with atomic persistence, read fallback, and static artifact precedence | Publishing validated ingested data before a static artifact exists |
 | [viral-launch](plugins/olko-product/skills/viral-launch/SKILL.md) | Sets up a project repository and launch plan for shareable marketing, public launch readiness, and growth loops | Preparing a repo, product, or package for public launch ("prep for Product Hunt", "write the launch post", "make this shareable"); for building the thing itself use mvp-oneshot or product-builder |
 
 ### olko-skill-meta (8)
@@ -298,7 +300,7 @@ Look back and improve: self-critique, retrospectives, performance review, rapid
 
 | Skill | What it does | Use when |
 |-------|-------------|----------|
-| [self-critique](plugins/olko-reflection/skills/self-critique/SKILL.md) | Adversarially critiques your own last answer: spawns a critic agent that verifies claims against live sources, then loops until satisfied and reports where you were wrong | Checking a substantial answer before the user has to |
+| [self-critique](plugins/olko-reflection/skills/self-critique/SKILL.md) | Adversarially critiques your own last answer: a blind critic agent re-derives and verifies every claim against live sources, the score is computed from a labelled claim ledger, you revise under a ratchet, restate the corrected answer, and turn each caught error into a durable rule with a fire counter | Checking a substantial answer before the user has to |
 | [review-past-performance](plugins/olko-reflection/skills/review-past-performance/SKILL.md) | Pulls 24h of ICM memories, git history, and skill analytics; detects repeated mistakes and slow workflows; proposes 1-3 concrete fixes | Daily self-improvement loop or codifying a repeated workflow |
 | [retro-analysis](plugins/olko-reflection/skills/retro-analysis/SKILL.md) | Produces repository, comparison, and cross-project retrospectives from delivery, code-quality, work-pattern, and trend evidence | The user asks for a retro over shipped work ("run a retrospective", "how did this quarter go", "what did we ship") or a scheduled retro job fires; for agent-operations retros use agent-ops-retro, for a single finished change use wrap-up |
 | [agent-ops-retro](plugins/olko-reflection/skills/agent-ops-retro/SKILL.md) | Retrospective on how the agents themselves are being operated: mines local transcripts and reads the reports other jobs already produce to surface what the human keeps repeating, what the guardrails caught, and where delivery leaked, carrying unactioned findings forward | Checking agent usage, delegation cost, or repeating corrections across sessions rather than shipped code |

package/adapters/claude/olko-product/skills/ingest-publication-slice/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: ingest-publication-slice
+description: Build and verify a small end-to-end publication path for validated ingested data, including atomic persistence, read fallback, and static artifact precedence.
+source: weekly-pattern-learner
+source_reason: "Repeatedly implement a validated ingest-to-publication flow with atomic persistence, fallback reads, and static artifact precedence."
+source_date: "2026-10-24"
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · Repeatedly implement a validated ingest-to-publication flow with atomic persistence, fallback reads, and static artifact precedence.*
+
+# Ingest Publication Slice
+
+Use this workflow when an ingest pipeline must make a validated record available immediately while a static or cached publication artifact may be generated later.
+
+## Define the contract
+
+Before changing code, read the repository instructions and trace the current path from ingest entry point through validation, job completion, persistence, request handling, and static artifact generation. Record existing invariants and preserve unrelated work.
+
+Write acceptance criteria for one complete slice:
+
+- Only a completed, validated active dataset can be published.
+- The persistent publication record and terminal ingest state commit atomically.
+- The canonical read path can serve from the persistent record when no static artifact exists.
+- A static artifact remains authoritative once present, if that is the established product contract.
+- Retries are idempotent, and collisions, invalid states, hidden records, and takedowns cannot publish.
+
+Adapt these criteria to the actual product contract. Do not invent a static-artifact precedence rule if the system has none.
+
+## Implement test-first
+
+Use the repository's required test command and style. Add focused failing tests before implementation for:
+
+1. A valid ingest publishes the record and terminal state together.
+2. A failure between writes leaves neither half committed.
+3. The canonical read path uses the persisted record when the artifact is absent.
+4. The artifact wins when both sources exist, when precedence is required.
+5. Repeated delivery is safe and invalid, hidden, colliding, or withdrawn records stay unpublished.
+
+Test the production boundary and transaction behavior, not only helper functions. Keep the change to the smallest vertical slice; avoid unrelated schema or routing refactors.
+
+## Verify the composed path
+
+Run the focused tests, then the repository's required broader checks. Inspect the final diff and trace the completed path again from ingest through the canonical response. Confirm behavior for retries, partial failures, and transitions from no artifact to artifact present. Report any unavailable integration or deployment evidence explicitly.