@olegkoval/agent-skills 1.32.0 → 1.34.0

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-agent-skills",
   "description": "Agent-agnostic skill catalog for Codex, Claude, Cursor, Grok, Copilot, Windsurf, Kiro, and other skill-aware tools.",
-  "version": "1.31.0",
+  "version": "1.33.0",
   "author": {
     "name": "Oleg Koval"
   },
@@ -42,6 +42,8 @@
     "./packages/software-development/codexloop",
     "./packages/software-development/geminiloop",
     "./packages/software-development/add-to-my-skills",
+    "./packages/software-development/wrap-up",
+    "./packages/software-development/retro-analysis",
     "./packages/software-development/ai-tools-setup",
     "./packages/software-development/changelog-generator",
     "./packages/software-development/wikipedia-uk-editor",

package/.cursor-plugin/index.json

@@ -151,6 +151,16 @@
       "source": "./packages/software-development/add-to-my-skills/adapters/cursor",
       "description": "Copy a newly created skill from another repo into this catalog, refresh the README and generated manifests, then commit and push."
     },
+    {
+      "name": "olko:wrap-up",
+      "source": "./packages/software-development/wrap-up/adapters/cursor",
+      "description": "Verify a completed task against its original objective, confirm applicable checks, and safely tidy task-owned artifacts, worktrees, and local branches."
+    },
+    {
+      "name": "olko:retro-analysis",
+      "source": "./packages/software-development/retro-analysis/adapters/cursor",
+      "description": "Produce repository, comparison, and cross-project engineering retrospectives from delivery, code-quality, work-pattern, and trend evidence."
+    },
     {
       "name": "olko:ai-tools-setup",
       "source": "./packages/software-development/ai-tools-setup/adapters/cursor",

package/.grok-plugin/index.json

@@ -161,6 +161,16 @@
       "source": "./packages/software-development/add-to-my-skills/adapters/grok",
       "description": "Copy a newly created skill from another repo into this catalog, refresh the README and generated manifests, then commit and push."
     },
+    {
+      "name": "olko:wrap-up",
+      "source": "./packages/software-development/wrap-up/adapters/grok",
+      "description": "Verify a completed task against its original objective, confirm applicable checks, and safely tidy task-owned artifacts, worktrees, and local branches."
+    },
+    {
+      "name": "olko:retro-analysis",
+      "source": "./packages/software-development/retro-analysis/adapters/grok",
+      "description": "Produce repository, comparison, and cross-project engineering retrospectives from delivery, code-quality, work-pattern, and trend evidence."
+    },
     {
       "name": "olko:ai-tools-setup",
       "source": "./packages/software-development/ai-tools-setup/adapters/grok",

package/.kiro/steering/retro-analysis.md

@@ -0,0 +1,186 @@
+<!-- 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."
+---
+
+# 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/.kiro/steering/wrap-up.md

@@ -0,0 +1,77 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+inclusion: manual
+description: "Verify a completed task against its original objective, confirm applicable checks, and safely tidy task-owned artifacts, worktrees, and local branches."
+---
+
+# Wrap Up
+
+Run this skill manually from time to time or as the final step after a task reaches its goal. It is a delivery audit and cleanup pass, not permission to expand scope or hide unfinished work.
+
+## 1. Reconstruct the task
+
+- Read the original request, acceptance criteria, task plan, and final diff.
+- Write a short objective statement and an acceptance matrix: each requested outcome, its evidence, and its status.
+- Compare the result with the original idea, not merely with the implementation plan. Mark anything ambiguous or unverified as `UNKNOWN` rather than assuming it is complete.
+- Identify the exact repositories, worktrees, branches, files, services, and temporary paths owned by this task. Preserve pre-existing user work.
+
+## 2. Verify the implementation
+
+- Inspect the final diff and confirm every requested behavior is implemented.
+- Check related tests, types, docs, configuration, migrations, and feature flags where the change requires them.
+- Run the repository-defined checks appropriate to the change. Follow local instructions and use the project’s package scripts rather than bypassing its tooling.
+- Prefer the smallest meaningful verification first, then the full applicable suite. Record exact commands and results.
+- If a check fails, determine whether it is caused by this task. Do not call the task green because an unrelated check happened to pass.
+- For user-facing behavior, require real browser/device or human evidence when that is part of acceptance; automated tests alone are not visual acceptance.
+
+## 3. Verify delivery state
+
+Keep these gates separate and evidence-backed:
+
+- Local worktree: branch, `HEAD`, tracked changes, and untracked files.
+- Remote: tracking branch and remote SHA, verified with Git or the existing provider CLI.
+- PR: current title/body, merge state, review threads, and required checks, when applicable.
+- CI: current-head status, not an old successful run.
+- Deployment: actual deployed version or endpoint health, when applicable.
+- Device or human QA: real acceptance evidence, when applicable.
+
+Do not claim remote, PR, CI, deployment, or QA completion from a local test or commit alone. Do not push, merge, deploy, or delete a remote branch as a side effect of this skill unless the task explicitly authorized it.
+
+## 4. Clean task-owned artifacts
+
+Clean only paths created by this task or explicitly named for cleanup.
+
+- Remove known temporary files, test output, logs, copied fixtures, and scratch directories after capturing any required evidence.
+- Never recursively delete a broad directory, the workspace root, an unresolved glob, or an unknown untracked file.
+- For dirty paths that predate this task or cannot be attributed confidently, leave them in place and report them.
+- Check the repository’s worktree list and remove only task-owned worktrees that are clean and no longer needed. Use an exact path; never remove a worktree containing uncommitted user work.
+
+## 5. Clean local branches safely
+
+- Confirm the task branch has the intended commit and that the remote branch contains the same work when remote delivery was required.
+- If the remote branch is merged, verify the merge state before deleting the local branch.
+- If the remote branch is pushed but unmerged, treat it as the recovery point. Delete the local branch only when the task is delivered, the remote branch is confirmed intact, the worktree is clean, and the user’s workflow permits local deletion. Otherwise preserve it and report why.
+- Never use force branch deletion or destructive checkout/reset commands unless the user explicitly requests that exact recovery operation.
+- Before deleting a branch, verify it is not checked out by another worktree and that no unique local commits would be lost.
+
+## 6. Report the result
+
+Lead with the outcome. Include concise evidence, cleanup performed, items intentionally preserved, and the smallest next action for any blocker. Always finish with this receipt, using `NOT_APPLICABLE` for out-of-scope gates and `NOT_RUN` for applicable checks that were not executed:
+
+```text
+OBJECTIVE:
+CHANGED:
+NOT_CHANGED:
+TESTS:
+BUILD:
+REMOTE:
+PR:
+CI:
+DEPLOYMENT:
+DEVICE_OR_HUMAN_QA:
+KNOWN_LIMITATIONS:
+FINAL_STATUS:
+```
+
+`FINAL_STATUS` must be exactly one of `DELIVERED`, `BLOCKED`, or `INTENTIONALLY_UNCHANGED`. Use `BLOCKED` when required evidence or cleanup cannot safely be completed; name the blocker and next action. Never promote a partial result to `DELIVERED`.

package/.windsurf/rules/retro-analysis.md

@@ -0,0 +1,185 @@
+<!-- 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/.windsurf/rules/wrap-up.md

@@ -0,0 +1,76 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Verify a completed task against its original objective, confirm applicable checks, and safely tidy task-owned artifacts, worktrees, and local branches."
+---
+
+# Wrap Up
+
+Run this skill manually from time to time or as the final step after a task reaches its goal. It is a delivery audit and cleanup pass, not permission to expand scope or hide unfinished work.
+
+## 1. Reconstruct the task
+
+- Read the original request, acceptance criteria, task plan, and final diff.
+- Write a short objective statement and an acceptance matrix: each requested outcome, its evidence, and its status.
+- Compare the result with the original idea, not merely with the implementation plan. Mark anything ambiguous or unverified as `UNKNOWN` rather than assuming it is complete.
+- Identify the exact repositories, worktrees, branches, files, services, and temporary paths owned by this task. Preserve pre-existing user work.
+
+## 2. Verify the implementation
+
+- Inspect the final diff and confirm every requested behavior is implemented.
+- Check related tests, types, docs, configuration, migrations, and feature flags where the change requires them.
+- Run the repository-defined checks appropriate to the change. Follow local instructions and use the project’s package scripts rather than bypassing its tooling.
+- Prefer the smallest meaningful verification first, then the full applicable suite. Record exact commands and results.
+- If a check fails, determine whether it is caused by this task. Do not call the task green because an unrelated check happened to pass.
+- For user-facing behavior, require real browser/device or human evidence when that is part of acceptance; automated tests alone are not visual acceptance.
+
+## 3. Verify delivery state
+
+Keep these gates separate and evidence-backed:
+
+- Local worktree: branch, `HEAD`, tracked changes, and untracked files.
+- Remote: tracking branch and remote SHA, verified with Git or the existing provider CLI.
+- PR: current title/body, merge state, review threads, and required checks, when applicable.
+- CI: current-head status, not an old successful run.
+- Deployment: actual deployed version or endpoint health, when applicable.
+- Device or human QA: real acceptance evidence, when applicable.
+
+Do not claim remote, PR, CI, deployment, or QA completion from a local test or commit alone. Do not push, merge, deploy, or delete a remote branch as a side effect of this skill unless the task explicitly authorized it.
+
+## 4. Clean task-owned artifacts
+
+Clean only paths created by this task or explicitly named for cleanup.
+
+- Remove known temporary files, test output, logs, copied fixtures, and scratch directories after capturing any required evidence.
+- Never recursively delete a broad directory, the workspace root, an unresolved glob, or an unknown untracked file.
+- For dirty paths that predate this task or cannot be attributed confidently, leave them in place and report them.
+- Check the repository’s worktree list and remove only task-owned worktrees that are clean and no longer needed. Use an exact path; never remove a worktree containing uncommitted user work.
+
+## 5. Clean local branches safely
+
+- Confirm the task branch has the intended commit and that the remote branch contains the same work when remote delivery was required.
+- If the remote branch is merged, verify the merge state before deleting the local branch.
+- If the remote branch is pushed but unmerged, treat it as the recovery point. Delete the local branch only when the task is delivered, the remote branch is confirmed intact, the worktree is clean, and the user’s workflow permits local deletion. Otherwise preserve it and report why.
+- Never use force branch deletion or destructive checkout/reset commands unless the user explicitly requests that exact recovery operation.
+- Before deleting a branch, verify it is not checked out by another worktree and that no unique local commits would be lost.
+
+## 6. Report the result
+
+Lead with the outcome. Include concise evidence, cleanup performed, items intentionally preserved, and the smallest next action for any blocker. Always finish with this receipt, using `NOT_APPLICABLE` for out-of-scope gates and `NOT_RUN` for applicable checks that were not executed:
+
+```text
+OBJECTIVE:
+CHANGED:
+NOT_CHANGED:
+TESTS:
+BUILD:
+REMOTE:
+PR:
+CI:
+DEPLOYMENT:
+DEVICE_OR_HUMAN_QA:
+KNOWN_LIMITATIONS:
+FINAL_STATUS:
+```
+
+`FINAL_STATUS` must be exactly one of `DELIVERED`, `BLOCKED`, or `INTENTIONALLY_UNCHANGED`. Use `BLOCKED` when required evidence or cleanup cannot safely be completed; name the blocker and next action. Never promote a partial result to `DELIVERED`.

package/README.md

@@ -3,7 +3,7 @@
   <p><strong>Agent-agnostic skill catalog for Codex, Claude, Cursor, Grok, Copilot, Windsurf, Kiro, and other skill-aware tools.</strong></p>
   <p>
     <img src="https://img.shields.io/badge/license-MIT-16a34a" alt="MIT license">
-    <img src="https://img.shields.io/badge/skills-47-2563eb" alt="47 skills">
+    <img src="https://img.shields.io/badge/skills-49-2563eb" alt="49 skills">
     <img src="https://img.shields.io/badge/platforms-Codex%20%7C%20Claude%20%7C%20Cursor%20%7C%20Grok%20%7C%20Copilot%20%7C%20Windsurf%20%7C%20Kiro-111827" alt="Codex Claude Cursor Grok Copilot Windsurf Kiro">
     <img src="https://img.shields.io/badge/status-public%20catalog-16a34a" alt="Public catalog">
   </p>
@@ -139,15 +139,17 @@ packages/{category}/{skill}/SKILL.md
 
 </details>
 
-## All 47 Skills
+## All 49 Skills
 
 Each entry links to its `SKILL.md`. Reference any skill by its `olko:*` lookup name in a new agent session.
 
-### Software development (41)
+### Software development (43)
 
 | Skill | What it does | Use when |
 |-------|-------------|----------|
 | [add-to-my-skills](packages/software-development/add-to-my-skills/SKILL.md) | Copies a newly created skill from another repo into this catalog, refreshes the README and generated manifests, then commits and pushes | Adding a skill you wrote elsewhere into this catalog |
+| [wrap-up](packages/software-development/wrap-up/SKILL.md) | Verifies a completed task against its original objective, confirms applicable checks, and safely tidies task-owned artifacts, worktrees, and local branches | Periodic or end-of-task delivery and cleanup review |
+| [retro-analysis](packages/software-development/retro-analysis/SKILL.md) | Produces repository, comparison, and cross-project retrospectives from delivery, code-quality, work-pattern, and trend evidence | Recurring engineering retrospective or “what did we ship?” analysis |
 | [ai-tools-setup](packages/software-development/ai-tools-setup/SKILL.md) | Sets up, repairs, and reports on the RTK + ICM + Vox AI development toolkit — installs missing tools, fixes broken hooks and MCP config | Bootstrapping AI dev tools on a new machine or diagnosing broken integrations |
 | [apple-store-submit](packages/software-development/apple-store-submit/SKILL.md) | Handles App Store rejection emails end-to-end — parses rejection reasons, creates a fix plan, implements code changes, and prepares resubmission | Responding to App Store rejections for privacy strings, entitlements, or guideline violations |
 | [changelog-generator](packages/software-development/changelog-generator/SKILL.md) | Transforms git commits into polished user-facing changelogs by categorising changes and rewriting technical commit messages | Preparing release notes, app store update descriptions, or a public changelog |
@@ -294,7 +296,7 @@ See [docs/skill-anatomy.md](docs/skill-anatomy.md) for the package format.
 ```text
 agent-skills/
 ├── packages/
-│   ├── software-development/   (39 skills)
+│   ├── software-development/   (43 skills)
 │   ├── marketing/              (3 skills)
 │   ├── music/                  (1 skill)
 │   └── photography/            (1 skill)