@olegkoval/agent-skills 1.34.0 → 1.35.0

package/.github/prompts/pr-description-writer.prompt.md

@@ -0,0 +1,135 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Draft and post a GitHub PR title and body from git diff and commit history. Chains after git-commit and before qodoloop / coderabbitloop."
+---
+
+Use the olko:pr-description-writer skill.
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · qodoloop and coderabbitloop both open with `gh pr view` — the PR creation/description step was never codified as its own skill*
+
+# PR Description Writer
+
+Draft a GitHub-ready PR title and body from the branch's commit history and diff, then
+create or update the PR so reviewers and AI tools have full context.
+
+## Inputs
+
+- **Base branch** (optional, default: `main` or `master` — detect from `gh repo view`)
+- **Draft mode** (optional, default: off)
+- **Template** (optional): if `.github/pull_request_template.md` exists, use its section headings
+
+## Workflow
+
+### 1. Gather branch context
+
+```bash
+# Current branch
+git rev-parse --abbrev-ref HEAD
+
+# Base branch
+gh repo view --json defaultBranchRef -q '.defaultBranchRef.name'
+
+# Commits since base
+git log <base>..<head> --oneline --no-merges
+
+# Diff summary (full diff for small PRs, stat-only for large)
+git diff <base>..<head> --stat
+git diff <base>..<head>   # only if total changes < ~500 lines
+```
+
+If the diff is large (>500 changed lines), read file-by-file rather than all at once.
+
+### 2. Check for existing PR
+
+```bash
+gh pr view --json number,title,body,state 2>/dev/null
+```
+
+- If a PR exists in `OPEN` state: update it with `gh pr edit`.
+- If no PR exists: create one with `gh pr create`.
+
+### 3. Check for a PR template
+
+```bash
+cat .github/pull_request_template.md 2>/dev/null \
+  || cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null \
+  || cat PULL_REQUEST_TEMPLATE.md 2>/dev/null
+```
+
+If a template exists, mirror its section headings and populate them. Skip sections
+that ask for credentials, tokens, internal hostnames, or content unrelated to the diff.
+
+### 4. Draft title and body
+
+**Title rules:**
+- Use Conventional Commits prefix when the branch/commits use it: `feat(scope):`, `fix:`, etc.
+- ≤ 70 characters
+- Imperative mood ("Add X", "Fix Y", not "Added X")
+- Include ticket number if present in branch name (e.g. `LIN-123`, `GH-456`)
+
+**Body sections (use the template if one was found, otherwise use this structure):**
+
+```markdown
+## Summary
+- <bullet: what changed>
+- <bullet: why>
+
+## Changes
+- `<file or subsystem>`: <what changed and why>
+
+## Test plan
+- [ ] <what to run and what result to expect>
+- [ ] <manual steps if automated tests don't cover it>
+
+## Notes
+<optional: anything a reviewer should watch for, known gaps, follow-up issues>
+```
+
+Rules:
+- Describe *intent*, not what the diff already shows line-by-line.
+- If commits already have good conventional messages, use them as the skeleton.
+- Skip any section that has nothing meaningful to say.
+- Reference specific files, functions, or lines only when they aid navigation.
+
+### 5. Create or update the PR
+
+Always pass the body via a heredoc or temp file — never interpolate it into the command
+string (quotes and newlines will break the shell):
+
+```bash
+# Create new PR
+gh pr create \
+  --title "<title>" \
+  --body "$(cat <<'PRBODY'
+<body>
+PRBODY
+)" \
+  --base <base> \
+  [--draft]
+
+# Update existing PR
+gh pr edit <number> \
+  --title "<title>" \
+  --body "$(cat <<'PRBODY'
+<body>
+PRBODY
+)"
+```
+
+### 6. Confirm and report
+
+```bash
+gh pr view --json number,title,url -q '"PR #\(.number): \(.title)\n\(.url)"'
+```
+
+Print the PR number, title, and URL. If the PR was newly created, note whether
+CI triggered automatically.
+
+## Chaining
+
+| Before this skill | After this skill |
+|---|---|
+| `olko:git-commit` + `git push` | `olko:qodoloop` |
+| `git push -u origin <branch>` | `olko:coderabbitloop` |
+| — | `olko:open-source-publisher` (for new repos) |

package/{packages/software-development/pr-finalize-complete/adapters/windsurf/rules/pr-finalize-complete.md → .github/prompts/pr-finalize-complete.prompt.md}

@@ -4,6 +4,8 @@
 description: "Confirms a PR is genuinely merge-ready when the work is already believed done: re-checks every review-bot and human finding against the current code, separates stale comments from fixed ones, runs the repo's real lint and test gates, and reports the evidence rather than the assumption."
 ---
 
+Use the olko:pr-finalize-complete skill.
+
 # PR Finalize Complete
 
 Confirm a PR is genuinely merge-ready -- even when all issues were already addressed -- by verifying the evidence, not trusting the assumption.

package/{packages/software-development/pr-finalize/adapters/windsurf/rules/pr-finalize.md → .github/prompts/pr-finalize.prompt.md}

@@ -4,6 +4,8 @@
 description: "Drives one GitHub PR to genuinely merge-ready: rebases and resolves conflicts, sweeps every review bot and human comment to zero unaddressed findings, verifies unit and E2E coverage actually exists, runs the repo's real lint/format/test gates before pushing, and reports what still needs a human."
 ---
 
+Use the olko:pr-finalize skill.
+
 # PR Finalize
 
 One PR, taken all the way to merge-ready. The job is not "make the bots stop talking" — it is **land the change in a state a careful reviewer would sign off on**, with evidence for every claim.

package/.github/prompts/pr-to-green.prompt.md

@@ -0,0 +1,144 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Orchestrate a GitHub PR from first push to merge-ready: run ci-fix-loop until checks are green, detect active AI review bots, run qodoloop and coderabbitloop in sequence, and confirm zero unresolved threads."
+---
+
+Use the olko:pr-to-green skill.
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · ci-fix-loop, coderabbitloop, and qodoloop all exist independently — no skill orchestrates them into a single end-to-end 'drive PR to green' pass*
+
+# PR to Green
+
+Drive a GitHub PR from first push to fully merge-ready: CI checks green, every active AI
+review bot addressed, zero unresolved threads.
+
+## Inputs
+
+- **PR number** (optional): detect from current branch if not given.
+- **Max total iterations** (optional, default: 10): across all loops combined.
+- **Skip bots** (optional): `--skip-qodo`, `--skip-coderabbit` to limit which review loops run.
+
+## Phase 1 — Ensure the PR exists
+
+```bash
+gh pr view --json number,headRefName,state 2>/dev/null
+```
+
+If no open PR exists, run `olko:pr-description-writer` first to create one, then continue.
+
+## Phase 2 — CI fix loop
+
+Run `olko:ci-fix-loop` until all required checks pass, or a blocker needs a human.
+
+Check current state first:
+
+```bash
+gh pr checks --json name,state,conclusion \
+  --jq '.[] | select(.conclusion != "success" and .conclusion != "skipped")'
+```
+
+If all checks already pass, skip to Phase 3. Otherwise run `olko:ci-fix-loop`.
+
+**Stop entirely if ci-fix-loop returns `blocked`** — do not run review loops while CI is red,
+as bots may refuse to review a failing branch and their feedback will shift after fixes land.
+
+## Phase 3 — Detect active review bots
+
+```bash
+# Check if Qodo has posted on this PR
+gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/reviews \
+  --jq '[.[] | select(.user.login == "qodo-code-review[bot]")] | length'
+
+# Check if CodeRabbit has posted
+gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/reviews \
+  --jq '[.[] | select(.user.login == "coderabbitai[bot]")] | length'
+```
+
+If neither has reviewed yet, nudge both and wait:
+
+```bash
+gh pr comment <PR_NUMBER> --body "@coderabbitai review"
+gh pr comment <PR_NUMBER> --body "@qodo-code-review review"
+```
+
+Poll (every ~15s, timeout ~5min) for a review from either bot. If neither responds, proceed
+without a review-bot loop and note it in the report.
+
+## Phase 4 — Review bot loops
+
+Run each detected loop to completion before starting the next.
+
+**Order:** qodoloop first (actionability-first bot, stricter on must-fix findings), then
+coderabbitloop (thoroughness-first, may surface additional style or security hints after Qodo's
+fixes change the diff context).
+
+### Qodo
+
+If Qodo posted at least one review: run `olko:qodoloop`.
+
+It handles fetching unresolved threads, reading each Agent Prompt block, applying the fix,
+replying to the thread, resolving it, pushing, and polling for the next Qodo review.
+
+If qodoloop returns rate-limited, note it and continue to CodeRabbit without stopping.
+
+### CodeRabbit
+
+If CodeRabbit posted at least one review: run `olko:coderabbitloop`.
+
+Same structure: fetch unresolved threads, read `🤖 Prompt for AI Agents` blocks, fix, reply,
+resolve, push, wait for the next CodeRabbit review.
+
+If coderabbitloop returns rate-limited, record it in the report and stop.
+
+## Phase 5 — Final verification
+
+Confirm the PR is truly merge-ready before reporting success:
+
+```bash
+# Required checks all green?
+gh pr checks --json name,state,conclusion \
+  --jq '[.[] | select(.conclusion != "success" and .conclusion != "skipped")] | length'
+
+# Any unresolved review threads?
+gh api graphql -f query='
+  query($owner: String!, $repo: String!, $number: Int!) {
+    repository(owner: $owner, name: $repo) {
+      pullRequest(number: $number) {
+        reviewThreads(first: 100) {
+          nodes { isResolved }
+        }
+      }
+    }
+  }
+' -f owner="{owner}" -f repo="{repo}" -F number=<PR_NUMBER> \
+  --jq '.data.repository.pullRequest.reviewThreads.nodes | map(select(.isResolved == false)) | length'
+```
+
+If either count > 0, identify what remains and report specifically — do not claim the PR is
+green when it is not.
+
+## Report
+
+```
+PR-to-green complete.
+  CI:           ✓ all checks green (2 fix iterations)
+  Qodo:         ✓ 4 findings fixed, 0 unresolved
+  CodeRabbit:   ✓ 6 findings fixed, 0 unresolved
+  Blockers:     none
+  Status:       merge-ready ✓
+
+  OR
+
+  CI:           ✓ green
+  Qodo:         ✓ 2 findings fixed
+  CodeRabbit:   ⚠ rate-limited — 1 finding still open (re-run tomorrow)
+  Status:       partial — CodeRabbit quota exhausted, human review needed
+```
+
+## Chaining
+
+| Before this skill | After this skill |
+|---|---|
+| `olko:git-commit` + push | `gh pr merge` |
+| `olko:pr-description-writer` | merge or stakeholder review |

package/{packages/software-development/product-builder/adapters/kiro/steering/product-builder.md → .github/prompts/product-builder.prompt.md}

@@ -1,10 +1,11 @@
 <!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
 
 ---
-inclusion: manual
 description: "Build a full-stack web application or SaaS product from a user description using production-oriented defaults."
 ---
 
+Use the olko:product-builder skill.
+
 # Product Builder
 
 You are a full-stack product builder. Your goal: **build real, working products — not prototypes**.

package/{packages/software-development/promptctl/adapters/windsurf/rules/promptctl.md → .github/prompts/promptctl.prompt.md}

@@ -4,6 +4,8 @@
 description: "Use promptctl for template-based prompt engineering, scoring, and workflow automation."
 ---
 
+Use the olko:promptctl skill.
+
 # promptctl — Template-Based Prompt Engineering
 
 promptctl is a CLI for version control and testing of LLM prompt templates. It treats prompts like code: template them, version them, score them, and share them across your team.

package/{packages/software-development/qodoloop/adapters/kiro/steering/qodoloop.md → .github/prompts/qodoloop.prompt.md}

@@ -1,10 +1,11 @@
 <!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
 
 ---
-inclusion: manual
 description: "Iteratively drives a GitHub PR to zero unresolved Qodo findings — reads each finding's own Agent Prompt, applies the fix, replies to the thread, resolves it, pushes, and waits for Qodo's next pass."
 ---
 
+Use the olko:qodoloop skill.
+
 # Qodoloop
 
 Fix every actionable Qodo finding on a PR, answer each thread, resolve it, and keep going until Qodo has nothing left to say (or a finding needs a human call).

package/.github/prompts/release-day.prompt.md

@@ -0,0 +1,264 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Orchestrate a full release-day workflow for iOS, Android, or Garmin apps: verify main branch CI is green, generate changelog, draft platform-ready store listing copy, trigger semantic-release or tag manually, wait for the build, and queue the App Store submission."
+---
+
+Use the olko:release-day skill.
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · changelog-generator, store-listing-copy, and apple-store-submit each reference each other in their Chaining tables but no skill chains them into a single end-to-end release-day workflow*
+
+# Release Day
+
+Drive a release from "code is ready" to "build submitted" in one orchestrated pass.
+Each phase validates its output before proceeding — the skill stops and reports
+rather than pushing a broken release.
+
+## Inputs
+
+- **Platform** (required): `ios`, `android`, `garmin`, or `all`
+- **Version** (optional): explicit version to release; if omitted, semantic-release
+  determines the next version automatically
+- **Branch** (optional, default: `main`): branch to release from
+- **--dry-run** (optional): run all checks and generate all copy without pushing
+  the tag or submitting to the store
+
+## Phase 1 — Verify the branch is ready
+
+```bash
+BRANCH="${Branch:-main}"
+git fetch origin "$BRANCH"
+BRANCH_SHA=$(git rev-parse "origin/$BRANCH")
+
+# Validate optional Version input
+if [ -n "$Version" ]; then
+  if ! echo "$Version" | grep -qE '^v?[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?$'; then
+    echo "Error: Version '$Version' is not a valid SemVer (e.g. 1.2.3 or v1.2.3)" >&2
+    exit 1
+  fi
+fi
+
+git status --short
+
+# Last release tag
+LAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "none")
+
+# Commits since last release
+if [ "$LAST_TAG" = "none" ]; then
+  git log "origin/$BRANCH" --oneline --no-merges | head -20
+else
+  git log "${LAST_TAG}..origin/$BRANCH" --oneline --no-merges | head -20
+fi
+
+# CI state on branch
+gh run list --branch "$BRANCH" --limit 3 --json status,conclusion,workflowName \
+  --jq '.[] | "\(.workflowName): \(.conclusion // .status)"'
+```
+
+**Stop if:**
+- `git status --short` is non-empty — there are uncommitted changes
+- The latest CI run on main is failing or still in progress
+- There are zero commits since the last tag (nothing to release)
+
+Report the problem clearly and stop — do not proceed to a release if the branch
+is not clean and green.
+
+## Phase 2 — Generate changelog
+
+Run `olko:changelog-generator`.
+
+Use the range `${LAST_TAG}..origin/${BRANCH}` (or `origin/${BRANCH}` if no prior tag exists). Produce a
+structured changelog with sections: New Features, Improvements, Bug Fixes, Breaking
+Changes. Strip internal commits (refactor, test, ci, chore without behavior impact).
+
+Write the changelog to:
+```bash
+RELEASE_DIR="$(mktemp -d)/release-$(date +%Y-%m-%d)"
+mkdir -p "$RELEASE_DIR"
+# changelog-generator writes to CHANGELOG.md — validate before proceeding
+if [ ! -s CHANGELOG.md ]; then
+  echo "Error: CHANGELOG.md is missing or empty — cannot continue." >&2
+  exit 1
+fi
+cp CHANGELOG.md "$RELEASE_DIR/changelog.md"
+```
+
+Review the generated changelog for accuracy before continuing. If commits are
+ambiguous (e.g. `fix: thing`), use `git show <sha>` to read the diff and
+re-classify the entry.
+
+## Phase 3 — Draft store listing copy
+
+Run `olko:store-listing-copy` with `--platform <platform>`.
+
+This reads the changelog from Phase 2 and drafts:
+- iOS: Title, Subtitle, What's New (4000 chars), Keywords (100 chars)
+- Android: Title (30), Short Description (80), Release Notes (500)
+- Garmin: Description, What's New (1500 chars)
+
+The skill validates field lengths and known store-validator rules (e.g., no `<`/`>` in
+Garmin copy) before delivering. Output goes to:
+```
+store-copy-v<version>-<YYYY-MM-DD>.md
+```
+
+**Do not proceed until store copy passes validation.** Fix any overflow or forbidden
+character before tagging.
+
+## Phase 4 — Trigger the release
+
+### If semantic-release is configured
+
+```bash
+# Dry-run first to confirm version and release notes
+set -o pipefail
+if ! npm run release:dry-run 2>&1 | tail -40; then
+  echo "Dry-run failed — aborting release." >&2
+  exit 1
+fi
+
+# On confirmation (or with --dry-run: stop here)
+git push origin "$BRANCH"   # trigger CI which runs semantic-release
+```
+
+Wait for the GitHub Actions release workflow to complete:
+
+```bash
+# Capture run ID for the push commit so we poll the right run
+sleep 10
+RUN_ID=$(gh run list --branch "$BRANCH" --workflow ci-release.yml --limit 1 \
+  --json databaseId,headSha \
+  --jq "[.[] | select(.headSha == \"$BRANCH_SHA\")] | .[0].databaseId")
+
+# Poll until the targeted run is done (timeout: 15 min)
+STATUS="pending"
+for i in $(seq 1 30); do
+  STATUS=$(gh run view "$RUN_ID" --json conclusion \
+    --jq '.conclusion // "pending"' 2>/dev/null || echo "pending")
+  [ "$STATUS" = "success" ] && break
+  [ "$STATUS" = "failure" ] || [ "$STATUS" = "cancelled" ] || [ "$STATUS" = "timed_out" ] && \
+    echo "Release workflow ended with status: $STATUS" && exit 1
+  sleep 30
+done
+if [ "$STATUS" != "success" ]; then
+  echo "Release workflow timed out after 15 minutes." >&2
+  exit 1
+fi
+```
+
+### If releasing manually (no semantic-release)
+
+```bash
+# Determine next version (follow SemVer: breaking → major, new feature → minor, fix → patch)
+NEXT_VERSION="vX.Y.Z"  # fill in based on changelog analysis
+
+# Tag and push
+git tag -a "$NEXT_VERSION" -m "Release $NEXT_VERSION"
+git push origin "$NEXT_VERSION"
+
+# Create GitHub release
+gh release create "$NEXT_VERSION" \
+  --title "$NEXT_VERSION" \
+  --notes-file "$RELEASE_DIR/changelog.md"
+```
+
+## Phase 5 — Confirm build artifact
+
+Download and validate the platform-specific build artifact. Poll every 2 minutes
+(timeout: 20 min) — do not proceed to Phase 6 until the artifact is confirmed present.
+
+```bash
+ARTIFACT_FOUND=false
+for i in $(seq 1 10); do
+  gh run download "$RUN_ID" --dir "$RELEASE_DIR" 2>/dev/null || true
+
+  case "$Platform" in
+    ios)
+      IPA=$(find "$RELEASE_DIR" -name "*.ipa" | head -1)
+      [ -n "$IPA" ] && ARTIFACT_FOUND=true && echo "iOS artifact: $IPA" && break
+      ;;
+    android)
+      APK=$(find "$RELEASE_DIR" \( -name "*.apk" -o -name "*.aab" \) | head -1)
+      [ -n "$APK" ] && ARTIFACT_FOUND=true && echo "Android artifact: $APK" && break
+      ;;
+    garmin)
+      PRG=$(find "$RELEASE_DIR" dist -name "*.prg" 2>/dev/null | head -1)
+      [ -n "$PRG" ] && ARTIFACT_FOUND=true && echo "Garmin artifact: $PRG" && break
+      ;;
+    all)
+      IPA=$(find "$RELEASE_DIR" -name "*.ipa" | head -1)
+      APK=$(find "$RELEASE_DIR" \( -name "*.apk" -o -name "*.aab" \) | head -1)
+      PRG=$(find "$RELEASE_DIR" dist -name "*.prg" 2>/dev/null | head -1)
+      [ -n "$IPA" ] && [ -n "$APK" ] && [ -n "$PRG" ] && ARTIFACT_FOUND=true && break
+      ;;
+  esac
+
+  echo "Attempt $i/10: artifact not yet available — waiting 2 minutes..."
+  sleep 120
+done
+
+if [ "$ARTIFACT_FOUND" != "true" ]; then
+  echo "Error: required build artifact not found after 20 minutes — aborting." >&2
+  exit 1
+fi
+```
+
+## Phase 6 — Submit to the store
+
+**Skip this phase with `--dry-run`** — stop after Phase 3 and print the store copy
+for manual paste.
+
+Run the platform-specific submission workflow with the artifact from Phase 5:
+
+**iOS:** Run `olko:apple-store-submit` — handles `altool` / `xcrun notarytool`
+submission, watches for Apple's processing email, and catches common rejection patterns.
+
+**Android:** Upload the `.aab` (or `.apk`) to Google Play using `fastlane supply`:
+
+```bash
+fastlane supply \
+  --aab "$APK" \
+  --track internal \
+  --package_name "$(cat android/app/build.gradle | grep applicationId | awk '{print $2}' | tr -d '"')"
+```
+
+Promote from internal → production after QA sign-off.
+
+**Garmin:** Run `olko:garmin-watchface` store publishing workflow — uploads the `.prg`
+and the listing copy from Phase 3 via the Connect IQ developer portal.
+
+**all:** Run iOS → Android → Garmin in sequence; report each result independently.
+
+## Final report
+
+```
+Release day complete — YYYY-MM-DD
+
+  Version:      vX.Y.Z (was vA.B.C)
+  Platform:     ios / android / garmin / all
+  Changelog:    N features, M fixes, K improvements
+  Store copy:   validated ✓ (all fields within limits)
+  Release:      tagged + GitHub Release created ✓
+  Build:        CI green, artifact downloaded ✓
+  Submission:   queued for App Store / Google Play / Connect IQ review
+
+  Next:
+    - Check Apple / Google / Garmin review status in 24–72h
+    - Monitor crash rates via Crashlytics / Firebase after rollout
+    - Run /review-past-performance at end of day to capture release learnings
+```
+
+## Safety guardrails
+
+- Never push a tag or trigger a release if Phase 1 fails
+- Never submit a store build without a validated Phase 3 output
+- Always `--dry-run` first on a new repo or a new platform
+- Keep the store copy file in $RELEASE_DIR until the submission is confirmed live
+
+## Chaining
+
+| Before this skill | After this skill |
+|---|---|
+| `olko:pr-to-green` — merge the release PR | Monitor store review status |
+| `olko:semantic-release-beta` — promote beta to stable | `olko:changelog-generator` for next iteration |
+| Manual: "all features are in, ship it" | Post-release monitoring |

package/{packages/software-development/retro-analysis/adapters/kiro/steering/retro-analysis.md → .github/prompts/retro-analysis.prompt.md}

@@ -1,10 +1,11 @@
 <!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
 
 ---
-inclusion: manual
 description: "Produce repository, comparison, and cross-project engineering retrospectives from delivery, code-quality, work-pattern, and trend evidence."
 ---
 
+Use the olko:retro-analysis skill.
+
 # Retro Analysis
 
 Run a factual engineering retrospective over a defined time window. The purpose is to explain what changed, how the work happened, what quality signals say, what was learned, and what should improve next. This is an analysis workflow, not a performance-ranking or blame exercise.
@@ -141,7 +142,25 @@ For `compare` or any window with a prior snapshot:
 
 Store a JSON snapshot with stable keys, UTC timestamps, resolved window, scope, repository identity, commit/PR identifiers, metric values, evidence limitations, and a short list of findings. Keep narrative prose out of fields intended for machine comparison. A snapshot is an aid to future analysis, not a source of truth that overrides current evidence.
 
-## 5. Produce the report
+## 5. Optionally promote durable lessons
+
+This phase is opt-in. A retrospective remains read-only unless the user or the surrounding workflow explicitly requests promotion to the shared ledger. Do not silently turn analysis into a write operation.
+
+Before adding any finding:
+
+1. Locate and read the current shared ledger. When a Git-backed repository ledger exists, read that repository file directly and treat it as authoritative. If it is absent or inaccessible, report `NOT_AVAILABLE` and do not claim that the ledger was checked.
+2. Classify the finding as one of:
+   - `local action` — a project- or task-specific follow-up that belongs in the report or backlog, not the shared ledger.
+   - `lesson` — a durable practice that generalizes across projects.
+   - `trap` — a non-obvious failure mode that can silently produce incorrect work.
+   - `preference` — a stable way the operator wants agents to work.
+3. Promote only non-obvious, durable, cross-project lessons, traps, or preferences. Keep local actions in the retrospective or project task system.
+4. Attach evidence to every promoted finding: a source path, commit, check, or other redacted reference, or the concrete failure that caused the rule. Do not promote an unsupported impression.
+5. Do not duplicate existing project instructions, shared-ledger notes, or behavior already enforced by an automated check. A thin ledger is more useful than a repetitive one.
+
+When promotion is authorized, append new notes using the current ledger schema; never rewrite, reorder, or overwrite existing entries. If no note is justified, append nothing. Report each added note ID, or `NOT_WRITTEN` when no note was added, promotion was not requested, or the ledger could not be safely updated.
+
+## 6. Produce the report
 
 Lead with a concise, shareable summary of the period. Then use this order:
 
@@ -160,7 +179,7 @@ Lead with a concise, shareable summary of the period. Then use this order:
 
 Use compact tables for exact metrics and prose for interpretation. Label inference as inference. Link or name evidence paths/commit IDs where useful, but never paste private content.
 
-## 6. End-of-task handoff
+## 7. End-of-task handoff
 
 If this run is explicitly closing a completed implementation, continue with `olko:wrap-up`:
 

package/{packages/software-development/review-past-performance/adapters/kiro/steering/review-past-performance.md → .github/prompts/review-past-performance.prompt.md}

@@ -1,10 +1,11 @@
 <!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
 
 ---
-inclusion: manual
 description: "Self-improvement loop that pulls the last 24h of ICM memories, git history, and skill analytics to detect repeated mistakes, slow workflows, and missing coverage, then proposes 1-3 concrete improvements."
 ---
 
+Use the olko:review-past-performance skill.
+
 # /review-past-performance
 
 Self-improvement loop. Analyze recent sessions, find durable patterns, propose fixes.

package/{packages/marketing/search-console-indexing-audit/adapters/kiro/steering/search-console-indexing-audit.md → .github/prompts/search-console-indexing-audit.prompt.md}

@@ -1,10 +1,11 @@
 <!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
 
 ---
-inclusion: manual
 description: "Analyze Google Search Console Coverage CSV exports and correlate them with sitemap, robots, canonical, redirect, and noindex signals."
 ---
 
+Use the olko:search-console-indexing-audit skill.
+
 # search-console-indexing-audit
 
 Use this skill to turn Google Search Console Coverage exports into a concrete indexing fix plan.