@olegkoval/agent-skills 1.34.0 → 1.35.0

package/packages/software-development/promptctl/adapters/grok/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:promptctl",
-  "version": "0.1.0",
-  "description": "Use promptctl for template-based prompt engineering, scoring, and workflow automation.",
-  "skills": "skills/"
-}

package/packages/software-development/promptctl/adapters/kiro/steering/promptctl.md

@@ -1,80 +0,0 @@
-<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
-
----
-inclusion: manual
-description: "Use promptctl for template-based prompt engineering, scoring, and workflow automation."
----
-
-# 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.
-
-## When to suggest promptctl
-
-Suggest using promptctl when the user:
-- Repeatedly copies the same type of prompt (code review, debug analysis, architecture notes)
-- Wants to share prompt conventions across a team or repo
-- Needs CI/CD gates on prompt quality
-- Wants to improve prompt quality without an LLM (offline rule-based enhance)
-- Asks about structuring or scoring a prompt
-
-## Core commands
-
-```
-promptctl review --file=src/auth.ts          # Code review prompt
-promptctl debug --file=src/handler.go        # Systematic debug analysis
-promptctl arch --file=docs/design.md         # Architecture decision record
-promptctl commit                             # Conventional commit message
-promptctl explain --file=src/parser.ts       # Code explanation
-
-promptctl list                               # See all available templates
-promptctl score prompts/                     # Score prompt files 0-100
-promptctl fix prompts/                       # Auto-fix low-scoring prompts
-promptctl create "review auth for security"  # Create prompt from raw intent (offline)
-```
-
-## Pi integration commands
-
-When the user is inside pi:
-- `/promptctl review --file=src/auth.ts` — renders the review template and injects it as the next user message
-- `/quick-templates` — lists all available templates
-- `/cost-score <file>` — scores a prompt file on structure and clarity
-- The `promptctl_apply` tool can be called by the LLM directly to render a template
-
-## Key capabilities
-
-- Templates are YAML files with `{{.variable}}` substitution — stored in `~/.promptctl/templates/` or `.promptctl/templates/` in your project
-- `--file=path` auto-populates `{{.file_content}}`, `{{.file_name}}`, `{{.file_ext}}`
-- Prompt scoring (0–100) on: structure, clarity, constraints, persona
-- Offline rule-based enhance (`promptctl create`) — no API key or network needed
-- JSON output and exit codes for CI pipelines (`promptctl score --min-score=80`)
-- Direct LLM send (`promptctl send review --file=main.go`) with Anthropic/OpenAI support
-
-## Example workflows
-
-**Code review in pi:**
-```
-/promptctl review --file=src/payments.ts --focus=security
-```
-
-**Debug analysis:**
-```
-/promptctl debug --file=src/worker.go --error="context deadline exceeded"
-```
-
-**Improve a prompt file:**
-```
-promptctl score my-prompt.md
-promptctl fix my-prompt.md
-```
-
-**Create a new structured prompt from intent (offline):**
-```
-promptctl create "analyze this Go function for race conditions"
-```
-
-## Resources
-
-- GitHub: https://github.com/oleg-koval/promptctl
-- Website: https://prompt-ctl.com
-- Install: `brew tap oleg-koval/tap && brew install promptctl`

package/packages/software-development/qodoloop/adapters/claude/plugin.json

@@ -1,5 +0,0 @@
-{
-  "name": "olko-qodoloop",
-  "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.",
-  "skills": "./skills"
-}

package/packages/software-development/qodoloop/adapters/codex/README.md

@@ -1,20 +0,0 @@
-# Codex Adapter for qodoloop
-
-This is a Codex-specific adapter for the `olko:qodoloop` skill.
-The canonical skill definition is in `../../SKILL.md`.
-
-## Usage
-
-Invoke in a Codex session:
-
-```text
-Use the olko:qodoloop skill to drive this PR to zero unresolved Qodo findings.
-```
-
-## Workflow
-
-See `../../SKILL.md` for the full workflow: wait for Qodo's review of the current head, fetch
-unresolved inline review threads via paginated GraphQL, read each finding's own Agent Prompt,
-apply the fix, commit and push once the fix is durable, then reply to each thread (resolving fixed
-ones, leaving blocked ones open) and repeat until clean, a rate limit is hit, or the iteration cap
-is reached. The procedure is plain `git`/`gh` and is agent-agnostic.

package/packages/software-development/qodoloop/adapters/cursor/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:qodoloop",
-  "version": "0.1.0",
-  "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.",
-  "skills": "skills/"
-}

package/packages/software-development/qodoloop/adapters/grok/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:qodoloop",
-  "version": "0.1.0",
-  "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.",
-  "skills": "skills/"
-}

package/packages/software-development/qodoloop/adapters/windsurf/rules/qodoloop.md

@@ -1,138 +0,0 @@
-<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
-
----
-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."
----
-
-# 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).
-
-## Inputs
-
-- **PR number** (optional): detect from the current branch if not given.
-- **Include optional findings** (optional, default off): Qodo tags each finding "Review recommended" (actionable) or "Optional" (informational/lower-confidence). By default only "Review recommended" findings count toward done; pass `--include-optional` to also fix and resolve the optional ones.
-
-## How Qodo actually posts (verified against a live install — don't assume otherwise)
-
-Qodo runs as `qodo-code-review[bot]` and posts **two independent things** per review pass, not one:
-
-1. A rollup **issue comment** titled `<h3>Code Review by Qodo</h3>` — human-readable, all findings in one place. A separate `<h3>PR Summary by Qodo</h3>` comment is a plain description, not a review — ignore it. While running, Qodo posts `<h3>Qodo is busy working</h3>` as its own comment (not an edit of a prior one).
-2. A **formal PR review** (`state: COMMENTED`) carrying one **inline review comment per finding**, each a real, resolvable GitHub review thread at the finding's file/line — same machinery as any human inline comment.
-
-**Use the inline threads as the source of truth.** They carry `isResolved` state natively (fetch via GraphQL, see `references/graphql-queries.md`), so "done" is answerable directly instead of re-parsing the rollup's HTML on every iteration. Each thread's body contains a `<details><summary>Agent Prompt</summary>` (or `**Agent Prompt**`) section with a ready-made fix spec, and a severity badge image whose `alt` text is `Remediation recommended` or `Informational` (recommended ↔ "Review recommended", informational ↔ "Optional").
-
-Qodo has **no check run to poll** — there is nothing in `gh pr checks` to wait on. Completion means a new `qodo-code-review[bot]` comment/review appears after your push; poll comments, not checks.
-
-**Rate limit is a real terminal state, not a bug.** A completed-looking comment reading "Qodo reviews are paused" / "you've reached your PR review limit" means Qodo will not review again this cycle — stop and report it, don't loop waiting for something that isn't coming.
-
-## Instructions
-
-### 1. Identify the PR
-
-```bash
-gh pr view --json number,headRefName,headRefOid -q '{number, branch: .headRefName, sha: .headRefOid}'
-```
-
-Check out the branch if not already on it, **then require a clean working
-tree** (`git status --porcelain` empty) before touching anything:
-
-```bash
-[ -z "$(git status --porcelain)" ] || { echo "working tree not clean — refusing to start, would risk committing unrelated changes"; exit 1; }
-```
-
-This is the precondition step E's scoped `git add <file>` depends on: staging
-only the files a fix touched is safe *because* the tree started clean, so
-nothing else could be sitting in those files. Skip this check and a file
-with pre-existing local edits will have those edits swept into the fix
-commit right along with it — the exact failure `git add -A` had, just
-narrower.
-
-### 2. Loop (max 5 iterations)
-
-#### A. Wait for a review of the current head
-
-On **iteration 1**, if there is nothing to push yet (you haven't fixed anything in this loop), don't wait for a brand-new review — use whatever Qodo has already posted as your starting point and go straight to step B. Otherwise:
-
-```bash
-SINCE=$(date -u +%Y-%m-%dT%H:%M:%SZ)
-git push
-```
-
-Poll (every ~10s, timeout ~5min), fetching **every page** of comments, not just the first:
-
-```bash
-gh api --paginate "repos/{owner}/{repo}/issues/<PR_NUMBER>/comments?per_page=100" | jq -s '
-  add | map(select(.user.login == "qodo-code-review[bot]")) | sort_by(.created_at)'
-```
-
-From the comments created **after `$SINCE`** (ignore anything older — that's leftover from a prior push, not this one):
-- Any of them contains "review limit" or "paused" → **stop the loop now**, go to Report with `blocked: rate-limited`.
-- The latest one starts with `<h3>Code Review by Qodo</h3>` → proceed to step B.
-- Otherwise (nothing yet, or only "Qodo is busy working") → sleep 10s and poll again, up to the 5-minute timeout.
-
-#### B. Fetch unresolved findings
-
-Run the paginated GraphQL query in `references/graphql-queries.md` (`unresolvedQodoThreads`) — **follow `pageInfo.hasNextPage`/`endCursor` until it's exhausted**; a PR with more than 100 Qodo threads silently loses every finding past the first page otherwise. For each unresolved thread from `qodo-code-review[bot]`: parse the finding title, severity (recommended/optional), file/line, and the **Agent Prompt** block.
-
-Build the working set: all `recommended` threads, plus `optional` ones too if `--include-optional`.
-
-#### C. Check exit conditions
-
-Stop if the working set is empty, or max iterations reached.
-
-#### D. Fix each finding
-
-For each thread in the working set, in order: read the Agent Prompt in full — it already names the issue, the context, the fix focus files/lines, and often the suggested fix. Apply it. Do not go beyond its stated scope. Track two lists as you go: **fixed** (thread id + the exact files you touched for it) and **blocked** (thread id + why — the prompt's suggestion was wrong, unsafe, or needs a product decision). Do not force a fix into the blocked list; do not resolve anything yet.
-
-#### E. Commit and push
-
-If **fixed** is empty, skip straight to F (nothing to commit). Otherwise, stage **only the files you touched in D** — never `git add -A`, which can sweep in unrelated local changes or secrets that have nothing to do with this loop:
-
-```bash
-git add <files touched by this iteration's fixes>
-git commit -m "address Qodo review feedback (qodoloop iteration N)"
-git push
-```
-
-Confirm the push actually succeeded before moving on — a resolved thread whose fix never made it to the branch is worse than an unresolved one.
-
-#### F. Answer each finding
-
-This is the "answer to the comments" half of the job, not optional cleanup — and it only runs **after** E's push is confirmed durable, so a thread is never marked resolved while its fix still only exists locally:
-
-- **Fixed** findings: reply with one or two sentences (what you changed and why), **then** resolve:
-  ```bash
-  gh api graphql -f query='
-    mutation($threadId: ID!, $body: String!) {
-      addPullRequestReviewThreadReply(input: {pullRequestReviewThreadId: $threadId, body: $body}) {
-        comment { id }
-      }
-    }' -f threadId="$THREAD_ID" -f body="$REPLY_TEXT"
-  ```
-  Pass the thread id and reply text as GraphQL **variables** (`-f threadId=... -f body=...`), never interpolated into the query string itself — a reply containing a quote, backtick, or newline breaks (or worse, injects into) a hand-built query. Then resolve with `resolveReviewThread` (see references file).
-- **Blocked** findings: reply explaining exactly why (false positive / needs a human call), but **do not resolve** — leave the thread open. A blocked finding that gets silently resolved is a false "done".
-
-Go back to step A.
-
-### 3. Report
-
-| Field              | Value |
-|--------------------|-------|
-| Iterations         | N     |
-| Findings resolved  | N     |
-| Findings blocked   | N (with reasons, left unresolved) |
-| Remaining          | N (if any) |
-| Blocked            | rate-limited / human-intervention / max-iterations / none |
-
-```text
-Qodoloop complete.
-  Iterations:  2
-  Resolved:    4 (fixed, replied + resolved)
-  Blocked:     1 (needs a human call, replied, left unresolved)
-  Remaining:   0
-```
-
-## References
-
-- `references/graphql-queries.md` — the exact `unresolvedQodoThreads` query and the `resolveReviewThread` / `addPullRequestReviewThreadReply` mutations, with field notes.

package/packages/software-development/relay/adapters/claude/plugin.json

@@ -1,5 +0,0 @@
-{
-  "name": "olko-relay",
-  "description": "Use claude-relay to run long or rate-limit-prone tasks autonomously across subscription accounts.",
-  "skills": "./skills"
-}

package/packages/software-development/relay/adapters/grok/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:relay",
-  "version": "0.1.0",
-  "description": "Use claude-relay to run long or rate-limit-prone tasks autonomously across subscription accounts.",
-  "skills": "skills/"
-}

package/packages/software-development/release-day/adapters/claude/plugin.json

@@ -1,5 +0,0 @@
-{
-  "name": "olko-release-day",
-  "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.",
-  "skills": "./skills"
-}

package/packages/software-development/release-day/adapters/codex/README.md

@@ -1,19 +0,0 @@
-# Codex Adapter for release-day
-
-This is a Codex-specific adapter for the `olko:release-day` skill.
-The canonical skill definition is in `../../SKILL.md`.
-
-## Usage
-
-Invoke in a Codex session:
-
-```text
-Use the olko:release-day skill to cut the iOS release for version 2.5.0.
-```
-
-## Workflow
-
-See `../../SKILL.md` for the full workflow: verify the main branch CI is green, generate
-a changelog from git history, draft platform-ready store listing copy, trigger
-semantic-release or tag manually, wait for the build artifact, and queue the App Store
-submission. Supports iOS, Android, and Garmin. The procedure is agent-agnostic.

package/packages/software-development/release-day/adapters/cursor/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:release-day",
-  "version": "0.1.0",
-  "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.",
-  "skills": "skills/"
-}

package/packages/software-development/release-day/adapters/grok/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:release-day",
-  "version": "0.1.0",
-  "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.",
-  "skills": "skills/"
-}

package/packages/software-development/retro-analysis/adapters/claude/plugin.json

@@ -1,5 +0,0 @@
-{
-  "name": "olko-retro-analysis",
-  "description": "Produce repository, comparison, and cross-project engineering retrospectives from delivery, code-quality, work-pattern, and trend evidence.",
-  "skills": "./skills"
-}

package/packages/software-development/retro-analysis/adapters/codex/README.md

@@ -1,16 +0,0 @@
-# Codex adapter: retro-analysis
-
-Use this adapter when the user asks for a retrospective, trend review, “what did we ship?”, recurring engineering analysis, or a cross-project/global retro.
-
-Invoke it as `olko:retro-analysis` with `24h`, `7d`, `14d`, `30d`, `compare`, `compare 14d`, or `global [window]`. Resolve calendar windows in the user's local timezone and state the exact scope before analyzing it.
-
-Codex-specific defaults:
-
-- Use repository Git evidence and `gh` provider evidence when available; keep local, remote, PR, CI, deployment, and device/human QA claims separate.
-- Inspect the repository's existing scripts and instructions before running checks. For Node projects, use the project's `npm run` scripts rather than raw `node` commands.
-- Preserve dirty worktrees and unrelated artifacts. Do not fetch, push, merge, deploy, delete branches, or clean temporary files as a side effect of analysis.
-- Treat unavailable or stale provider/session data as a limitation, not as a zero or a green result.
-- Write only the bounded `.context/retros/` snapshot described by the canonical skill when persistence is in scope; never include secrets or raw private session content.
-- If the retrospective closes a completed implementation, follow it with `olko:wrap-up` for the delivery receipt and task-owned cleanup.
-
-Return the full narrative report followed by the canonical `RETRO_STATUS` block. Do not convert the report into a delivery claim unless `olko:wrap-up` has separately verified delivery.

package/packages/software-development/retro-analysis/adapters/cursor/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:retro-analysis",
-  "version": "0.1.0",
-  "description": "Produce repository, comparison, and cross-project engineering retrospectives from delivery, code-quality, work-pattern, and trend evidence.",
-  "skills": "skills/"
-}

package/packages/software-development/retro-analysis/adapters/grok/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:retro-analysis",
-  "version": "0.1.0",
-  "description": "Produce repository, comparison, and cross-project engineering retrospectives from delivery, code-quality, work-pattern, and trend evidence.",
-  "skills": "skills/"
-}

package/packages/software-development/retro-analysis/adapters/windsurf/rules/retro-analysis.md

@@ -1,185 +0,0 @@
-<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
-
----
-description: "Produce repository, comparison, and cross-project engineering retrospectives from delivery, code-quality, work-pattern, and trend evidence."
----
-
-# 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.
-
-Use it manually at the end of a day, week, sprint, or release; on a recurring schedule; or when asked what was shipped, where time went, or how delivery quality is trending. When a specific implementation has just reached its goal, run this analysis before or alongside `olko:wrap-up` so the delivery audit and the broader retrospective remain distinct.
-
-## Invocation
-
-Accept one of these arguments:
-
-- no argument or `7d`: the previous seven calendar days
-- `24h`: the previous 24 hours
-- `14d` or `30d`: the previous N calendar days
-- `compare` or `compare 14d`: compare the selected window with the immediately preceding window of equal length
-- `global`, `global 14d`: aggregate across discoverable repositories and agent sessions
-
-If the argument is invalid, print the accepted forms and stop. Do not silently choose a different window.
-
-Calendar windows are aligned to midnight in the operator's local timezone. A short hourly window may use a relative timestamp. State the resolved start, end, timezone, scope, and comparison window at the beginning of the report.
-
-## Safety and evidence rules
-
-- Be read-only by default. Do not push, merge, deploy, close issues, edit source, or rewrite history.
-- A local retro may write one task-owned snapshot under `.context/retros/` when that directory exists or when persistence is explicitly requested. Never overwrite an existing snapshot; use a date and window-specific filename.
-- Do not fetch or refresh remote refs unless the user or the surrounding workflow authorized that read-side state change. If refs may be stale, say so and use the available evidence.
-- Preserve dirty work, untracked files, existing snapshots, credentials, and unrelated temporary artifacts.
-- Never infer delivery from a local commit. Treat local Git, remote/PR state, CI, deployment, and device or human QA as separate evidence gates.
-- Do not expose secrets, tokens, private prompts, or raw session content. Use aggregate counts and redacted references only.
-- Missing data is `UNKNOWN`, not zero. Distinguish “none found” from “not available”.
-- Do not turn commit count, lines changed, hours, or AI-assisted activity into a simplistic productivity score. Use them as context for the narrative.
-
-## 1. Establish scope and baseline
-
-For repository mode:
-
-1. Identify the repository, current branch, `HEAD`, configured author, base branch, and working-tree state.
-2. Preserve and report pre-existing dirty paths; do not include their changes as delivered work unless the evidence links them to the window.
-3. Use the repository's local timezone for calendar boundaries. Use UTC timestamps in stored machine-readable data.
-4. Read only relevant project documentation and task artifacts needed to interpret the changes. Do not invent milestones, objectives, or acceptance criteria.
-5. Locate prior snapshots in `.context/retros/` and load the immediately preceding comparable snapshot when available.
-
-For global mode:
-
-1. Discover repositories from the configured workspace locations or an existing discovery tool. If discovery is unavailable, report that limitation and continue with explicitly supplied paths.
-2. For each repository, collect the same bounded evidence as repository mode and skip missing, inaccessible, or non-Git directories.
-3. Optionally include available agent/session summaries or tool telemetry, but only as aggregate, redacted evidence. Do not require a specific agent vendor, plugin, or telemetry format.
-4. Keep per-project results separate before producing cross-project totals. Never hide a repository-level failure in an aggregate.
-
-## 2. Collect raw evidence
-
-Capture enough raw data to reproduce the analysis. Prefer stable Git/provider CLIs already present in the environment. Save only the normalized snapshot unless raw artifacts were explicitly requested.
-
-### Repository history
-
-Collect, bounded to the resolved window and scope:
-
-- commit hash, author, timestamp, subject, body, and parent information
-- insertions, deletions, files changed, and test-file versus production-file changes
-- commit type signals from Conventional Commit prefixes, labels, or equivalent repository conventions
-- pull request or merge request references present in commits, and provider state when a provider CLI is available
-- changed-file frequency, churn, and hotspots; distinguish generated, vendored, lockfile, and source files when possible
-- per-author commit and file ownership signals, including co-authors and AI-assisted markers only when explicitly present
-
-Use `git log --shortstat` or equivalent for commit-level change counts and `git diff --numstat` or equivalent for test/source proportions. If a command cannot run, record the command and reason; do not substitute invented values.
-
-### Delivery and quality signals
-
-Inspect only signals that exist in the repository or authorized provider tooling:
-
-- branch and remote tracking state, current PR title/body, review state, and current-head checks
-- test files, test commands, recent test-related commits, and known failing or skipped checks
-- changelog, release notes, issue/task references, and plan artifacts when present
-- TODO/backlog markers when a project-maintained backlog exists
-- regression fixes, reverted changes, follow-up fixes, and repeated failure patterns
-- optional review or static-analysis summaries, clearly labeling unavailable or rate-limited providers
-
-Never call an absent test suite “healthy”; report `NOT_AVAILABLE`. Never call a skipped check green.
-
-### Work-pattern signals
-
-When timestamps are available:
-
-- build an hour-of-day histogram in local time
-- group commits or activity into sessions separated by at least 45 minutes of inactivity
-- classify sessions as deep (3+ hours), medium (1–3 hours), or micro (<1 hour)
-- count active days, longest streak, and context switches between repositories or work areas
-
-Treat commit timestamps as a proxy, not proof of keyboard time. If session telemetry exists, prefer it and name the source.
-
-## 3. Compute the analysis
-
-Use the evidence to calculate, or explicitly mark unavailable, the following dimensions:
-
-### Shipping and scope
-
-- features, fixes, refactors, docs, tests, chores, and releases shipped
-- commits, weighted commits, active days, contributors, and referenced PRs
-- version range or release identifiers when the repository exposes them
-- logical lines changed and raw lines changed, reported separately
-- plan or objective items completed, deferred, or still open when a plan is available
-
-### Quality and maintainability
-
-- test lines or test files changed relative to production changes
-- test commands run and their current result
-- regressions, reverts, repeated fixes, and hotspots with high churn
-- type, lint, build, security, review, and release signals when available
-- backlog/TODO health only when there is a maintained source to inspect
-
-Do not reward large diffs or penalize small ones without explaining their context. A small change that closes a high-value objective can be the most important shipment.
-
-### Focus and delivery flow
-
-- commit-type mix and fix ratio; flag a high fix ratio as a signal for investigation, not a diagnosis
-- PR/MR size buckets and time-to-merge when provider data is available
-- work sessions, time-of-day distribution, context switching, and focus patterns
-- planned versus unplanned work, if the plan and change evidence support the comparison
-- the single most consequential shipment or decision, with evidence and caveats
-
-### People and collaboration
-
-For multi-author work, provide a factual per-author view of commits, change volume, areas touched, review or PR participation, and notable contributions. Include a team view of ownership concentration, cross-review, handoffs, and shared hotspots. Avoid ranking people by raw LOC or commit count.
-
-Use the configured Git author as the personal focus only when it is unambiguous. Otherwise produce a team report and state that no personal identity was selected.
-
-## 4. Compare and track trends
-
-For `compare` or any window with a prior snapshot:
-
-- compare features/fixes, commits, active days, contributors, PRs, change volume, test signals, regressions, and backlog movement
-- identify meaningful directional changes and explain whether the evidence is strong, weak, or incomplete
-- preserve the same metric definitions between periods; do not compare a repository window to a global window as if they were equivalent
-- report streaks, recurring hotspots, repeated failure modes, and unresolved improvements only when snapshots support them
-
-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
-
-Lead with a concise, shareable summary of the period. Then use this order:
-
-1. **Scope and evidence** — window, timezone, repositories, branch/base, sources, and limitations.
-2. **Summary table** — shipping, activity, quality, and delivery metrics with `UNKNOWN` where needed.
-3. **What shipped** — the most important features, fixes, releases, or decisions, tied to commits/PRs.
-4. **Trends** — comparison with the previous period, if available.
-5. **Time and sessions** — active days, session shape, time distribution, and context switching.
-6. **Quality and test health** — checks, regressions, churn hotspots, review signals, and open risks.
-7. **Plan completion** — objective items completed, deferred, or missing evidence.
-8. **Focus and collaboration** — personal or team analysis with fair context.
-9. **Top wins** — three evidence-backed wins when enough evidence exists.
-10. **Improvements** — three concrete, small, actionable improvements; fewer is fine when evidence is limited.
-11. **Next-period habits** — explicit habits or experiments with an owner or trigger when known.
-12. **Limitations** — missing refs, unavailable provider data, stale telemetry, dirty work, or ambiguous attribution.
-
-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
-
-If this run is explicitly closing a completed implementation, continue with `olko:wrap-up`:
-
-- use the retro to check that the delivered work matches the original idea and to capture follow-up items
-- let `wrap-up` perform the separate local/remote/PR/CI/deployment/QA gates and task-owned cleanup
-- preserve the retro snapshot and report any limitation instead of deleting evidence
-
-For a periodic or global retrospective, do not clean worktrees, branches, logs, or temporary files unless the user explicitly asks for that separate cleanup. Analysis alone must not alter delivery state.
-
-## Minimal final status
-
-End every run with:
-
-```text
-RETRO_STATUS: DONE | DONE_WITH_LIMITATIONS | BLOCKED
-WINDOW: <resolved window and timezone>
-SCOPE: <repository or repositories>
-SNAPSHOT: <path, NOT_WRITTEN, or NOT_AVAILABLE>
-TOP_FINDINGS: <short summary>
-NEXT_ACTIONS: <short actionable list>
-```
-
-Use `BLOCKED` only when the requested scope cannot be analyzed safely or the required evidence is inaccessible. A partial but clearly labeled report is `DONE_WITH_LIMITATIONS`.

package/packages/software-development/review-past-performance/adapters/claude/plugin.json

@@ -1,5 +0,0 @@
-{
-  "name": "olko-review-past-performance",
-  "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.",
-  "skills": "./skills"
-}

package/packages/software-development/review-past-performance/adapters/codex/README.md

@@ -1,3 +0,0 @@
-# Codex adapter
-
-Use the canonical skill directly from `packages/software-development/review-past-performance/SKILL.md`.

package/packages/software-development/review-past-performance/adapters/cursor/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:review-past-performance",
-  "version": "0.1.0",
-  "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.",
-  "skills": "skills/"
-}

package/packages/software-development/review-past-performance/adapters/grok/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:review-past-performance",
-  "version": "0.1.0",
-  "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.",
-  "skills": "skills/"
-}