@olegkoval/agent-skills 1.69.3 → 1.70.0

package/.github/copilot-instructions.md

@@ -50,9 +50,11 @@ Available reusable prompt files:
 - agent-ops-retro: .github/prompts/agent-ops-retro.prompt.md
 - crash-course: .github/prompts/crash-course.prompt.md
 - wrap-up: .github/prompts/wrap-up.prompt.md
+- team-retrospective: .github/prompts/team-retrospective.prompt.md
 - obsidian-pr-sync: .github/prompts/obsidian-pr-sync.prompt.md
 - obsidian-task-rollover: .github/prompts/obsidian-task-rollover.prompt.md
 - morning-routine: .github/prompts/morning-routine.prompt.md
+- app-store-regional-pricing: .github/prompts/app-store-regional-pricing.prompt.md
 - apple-store-submit: .github/prompts/apple-store-submit.prompt.md
 - macos-menubar-app: .github/prompts/macos-menubar-app.prompt.md
 - garmin-watchface: .github/prompts/garmin-watchface.prompt.md

package/.github/prompts/app-store-regional-pricing.prompt.md

@@ -0,0 +1,28 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Research, propose, and verify App Store and in-app purchase prices by storefront using affordability evidence and Apple price points."
+---
+
+Use the olko:app-store-regional-pricing skill.
+
+# App Store regional pricing
+
+Use for storefront pricing that reflects local affordability, including one-time purchases and subscriptions. Do not confuse the app download price with a separate in-app purchase.
+
+1. Identify the exact app, product ID, purchase type, base storefront, current schedule, availability, effective dates, and any existing custom prices. Inspect the live schedule before proposing changes; never assume exchange-rate equalization is purchasing-power pricing.
+2. Establish the user's base price and commercial constraints. Research current, dated primary sources for affordability (for example World Bank income or GDP per capita and PPP data), taxes, applicable Apple rules, and relevant market evidence. GDP per capita is a rough proxy, not a measure of every customer's income. Record missing or stale data and avoid unsupported precision.
+3. Propose a transparent, reproducible price ladder and country assignments, with the actual Apple storefront currency and allowed price point for each. Account for tax treatment, Apple proceeds, minimum viable revenue, and commercial judgment; distinguish observed figures from proposed estimates. Review outliers, dollar-denominated storefronts, and availability. Do not claim a price is objectively fair or promise a currency the storefront does not support.
+4. Follow the user's authorized scope for changes. Preserve the base and unrelated existing prices unless requested. For material unresolved business choices, present concrete options before applying them. Do not buy, submit for review, or release the app as a side effect.
+5. Use the existing project workflow, CLI, or connected UI to configure custom storefront prices. Check effective dates, current and future schedules, and whether the change replaces existing overrides. Apple states manually managed regions are not automatically updated for exchange rate or tax changes; identify the monitoring owner and review cadence.
+6. Reopen the saved schedule and verify the exact product, dates, storefronts, amounts, currencies, and unaffected base. Report applied versus proposed prices and remaining coverage. If sandbox or storefront purchase testing is unavailable, say so. Note that the customer's Apple account storefront determines the price, not necessarily physical location.
+
+## Post-launch review
+
+- Confirm the app is actually available for sale and record the launch date before interpreting sales. If it has not launched, report the review as pending; schedule the first review only if a real scheduling tool can anchor it to 30 days after the actual launch. Set a fixed calendar date only after the launch date is recorded. Do not claim a reminder was created without a verified schedule.
+- At approximately 30 days and 90 days after launch, and quarterly thereafter, retrieve the latest available App Store Connect Analytics and Sales and Trends reports using an authorized workflow. Record the report dates, timezone, product, storefront, currency, report freshness, and missing or suppressed data. Distinguish downloads, product-page views, purchases, refunds, and proceeds; do not count TestFlight or sandbox activity as sales.
+- Compare storefront purchase conversion only when the numerator and denominator cover the same product, audience, and period. Compare net proceeds and refunds as well as unit sales, and segment by acquisition source where available. Record sample sizes and avoid conclusions from sparse data, privacy thresholds, or incomplete reporting. Pricing is one possible cause of differences, not proof of causation.
+- Recheck manual prices against current exchange rates, taxes, local purchasing-power indicators, and Apple price points. List changes since the previous review, markets needing attention, and the dates and sources of evidence. Account for Apple commissions and local tax treatment without guessing actual proceeds.
+- Recommend a small, reversible set of changes with current and proposed prices, expected tradeoffs, and follow-up date. Respect the user's authorization and product-specific pricing rules; verify each saved schedule and distinguish scheduled changes from active prices. Never promise a future review will happen without a functioning automation or explicit follow-up.
+
+Primary references: [Set a price for an In-App Purchase](https://developer.apple.com/help/app-store-connect/manage-in-app-purchases/set-a-price-for-an-in-app-purchase), [Apple pricing](https://developer.apple.com/in-app-purchase/), [World Bank data](https://data.worldbank.org/indicator/NY.GDP.PCAP.PP.CD). Check current documentation for product-specific behavior before making changes.

package/.github/prompts/team-retrospective.prompt.md

@@ -0,0 +1,31 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Collect each task agent’s factual retrospective and safely dismiss the team after successful work."
+---
+
+Use the olko:team-retrospective skill.
+
+# Team retrospective
+
+Run after a multi-agent task is complete and its applicable checks are green,
+before dismissing its agents. Explicit user instructions to retain agents or
+finish early take precedence. Do not spawn agents solely to run this skill.
+
+1. Identify agents, tabs, and sessions owned by this task using the environment's
+   actual inventory and recorded ownership. Preserve other tasks and sessions.
+2. Ask each reachable agent for a concise factual report: what went wrong, failed
+   approaches, tool or coordination problems, resolutions, and unresolved items.
+   Ask them to distinguish direct observation from inference. A clean report may
+   say no issues. Do not request new implementation or speculative findings.
+3. Collect each response, or label it unavailable with the reason. Preserve useful
+   findings and a concise summary in an appropriate task artifact; avoid secrets,
+   unnecessary transcripts, and public disclosure. Report recurring issues and
+   unresolved items to the user. Claims remain reports until independently verified.
+4. Confirm work and required handoffs are preserved. Dismiss the task-owned agents
+   and close only their task-owned tabs or panes when safe; verify the result.
+   Follow the environment's skill and safety rules. Never stop a shared server or
+   close another task's session. Respect explicit instructions to keep agents.
+5. If work is blocked, unfinished, or still active, preserve the agents and report
+   the blocker instead of treating the task as green. If the environment cannot
+   contact or dismiss an agent, report the limitation; never claim it was dismissed.

package/.github/prompts/wrap-up.prompt.md

@@ -30,6 +30,8 @@ Use this as a proportional end-of-task audit. Preserve pre-existing work and do
 - Check the diff and untracked files for keys, tokens, passwords, private keys, connection strings, cookies, personal data, and credentials in logs or examples. Report locations without printing values; recommend environment variables or a secret manager where relevant.
 - Decide from the actual change whether README, architecture or API docs, OpenAPI, CHANGELOG, CONTRIBUTING, `.env.example`, ADRs, or runbooks need an update. Name the exact change needed. Skip documentation for trivial internal changes unless it helps future maintenance.
 
+Before cleanup, when a completed task used a team and its applicable checks are green, invoke `olko:team-retrospective` to collect each agent’s report and safely dismiss task-owned agents. If unavailable, report the limitation; do not claim closeout ran.
+
 ## 4. Prepare safe cleanup
 
 - Propose cleanup commands only. Do not remove any file, branch, or worktree automatically, including generated or temporary files. Never propose deletion of an unknown untracked file, broad directory, or unresolved glob.

package/.kiro/steering/app-store-regional-pricing.md

@@ -0,0 +1,27 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+inclusion: manual
+description: "Research, propose, and verify App Store and in-app purchase prices by storefront using affordability evidence and Apple price points."
+---
+
+# App Store regional pricing
+
+Use for storefront pricing that reflects local affordability, including one-time purchases and subscriptions. Do not confuse the app download price with a separate in-app purchase.
+
+1. Identify the exact app, product ID, purchase type, base storefront, current schedule, availability, effective dates, and any existing custom prices. Inspect the live schedule before proposing changes; never assume exchange-rate equalization is purchasing-power pricing.
+2. Establish the user's base price and commercial constraints. Research current, dated primary sources for affordability (for example World Bank income or GDP per capita and PPP data), taxes, applicable Apple rules, and relevant market evidence. GDP per capita is a rough proxy, not a measure of every customer's income. Record missing or stale data and avoid unsupported precision.
+3. Propose a transparent, reproducible price ladder and country assignments, with the actual Apple storefront currency and allowed price point for each. Account for tax treatment, Apple proceeds, minimum viable revenue, and commercial judgment; distinguish observed figures from proposed estimates. Review outliers, dollar-denominated storefronts, and availability. Do not claim a price is objectively fair or promise a currency the storefront does not support.
+4. Follow the user's authorized scope for changes. Preserve the base and unrelated existing prices unless requested. For material unresolved business choices, present concrete options before applying them. Do not buy, submit for review, or release the app as a side effect.
+5. Use the existing project workflow, CLI, or connected UI to configure custom storefront prices. Check effective dates, current and future schedules, and whether the change replaces existing overrides. Apple states manually managed regions are not automatically updated for exchange rate or tax changes; identify the monitoring owner and review cadence.
+6. Reopen the saved schedule and verify the exact product, dates, storefronts, amounts, currencies, and unaffected base. Report applied versus proposed prices and remaining coverage. If sandbox or storefront purchase testing is unavailable, say so. Note that the customer's Apple account storefront determines the price, not necessarily physical location.
+
+## Post-launch review
+
+- Confirm the app is actually available for sale and record the launch date before interpreting sales. If it has not launched, report the review as pending; schedule the first review only if a real scheduling tool can anchor it to 30 days after the actual launch. Set a fixed calendar date only after the launch date is recorded. Do not claim a reminder was created without a verified schedule.
+- At approximately 30 days and 90 days after launch, and quarterly thereafter, retrieve the latest available App Store Connect Analytics and Sales and Trends reports using an authorized workflow. Record the report dates, timezone, product, storefront, currency, report freshness, and missing or suppressed data. Distinguish downloads, product-page views, purchases, refunds, and proceeds; do not count TestFlight or sandbox activity as sales.
+- Compare storefront purchase conversion only when the numerator and denominator cover the same product, audience, and period. Compare net proceeds and refunds as well as unit sales, and segment by acquisition source where available. Record sample sizes and avoid conclusions from sparse data, privacy thresholds, or incomplete reporting. Pricing is one possible cause of differences, not proof of causation.
+- Recheck manual prices against current exchange rates, taxes, local purchasing-power indicators, and Apple price points. List changes since the previous review, markets needing attention, and the dates and sources of evidence. Account for Apple commissions and local tax treatment without guessing actual proceeds.
+- Recommend a small, reversible set of changes with current and proposed prices, expected tradeoffs, and follow-up date. Respect the user's authorization and product-specific pricing rules; verify each saved schedule and distinguish scheduled changes from active prices. Never promise a future review will happen without a functioning automation or explicit follow-up.
+
+Primary references: [Set a price for an In-App Purchase](https://developer.apple.com/help/app-store-connect/manage-in-app-purchases/set-a-price-for-an-in-app-purchase), [Apple pricing](https://developer.apple.com/in-app-purchase/), [World Bank data](https://data.worldbank.org/indicator/NY.GDP.PCAP.PP.CD). Check current documentation for product-specific behavior before making changes.

package/.kiro/steering/team-retrospective.md

@@ -0,0 +1,30 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+inclusion: manual
+description: "Collect each task agent’s factual retrospective and safely dismiss the team after successful work."
+---
+
+# Team retrospective
+
+Run after a multi-agent task is complete and its applicable checks are green,
+before dismissing its agents. Explicit user instructions to retain agents or
+finish early take precedence. Do not spawn agents solely to run this skill.
+
+1. Identify agents, tabs, and sessions owned by this task using the environment's
+   actual inventory and recorded ownership. Preserve other tasks and sessions.
+2. Ask each reachable agent for a concise factual report: what went wrong, failed
+   approaches, tool or coordination problems, resolutions, and unresolved items.
+   Ask them to distinguish direct observation from inference. A clean report may
+   say no issues. Do not request new implementation or speculative findings.
+3. Collect each response, or label it unavailable with the reason. Preserve useful
+   findings and a concise summary in an appropriate task artifact; avoid secrets,
+   unnecessary transcripts, and public disclosure. Report recurring issues and
+   unresolved items to the user. Claims remain reports until independently verified.
+4. Confirm work and required handoffs are preserved. Dismiss the task-owned agents
+   and close only their task-owned tabs or panes when safe; verify the result.
+   Follow the environment's skill and safety rules. Never stop a shared server or
+   close another task's session. Respect explicit instructions to keep agents.
+5. If work is blocked, unfinished, or still active, preserve the agents and report
+   the blocker instead of treating the task as green. If the environment cannot
+   contact or dismiss an agent, report the limitation; never claim it was dismissed.

package/.kiro/steering/wrap-up.md

@@ -29,6 +29,8 @@ Use this as a proportional end-of-task audit. Preserve pre-existing work and do
 - Check the diff and untracked files for keys, tokens, passwords, private keys, connection strings, cookies, personal data, and credentials in logs or examples. Report locations without printing values; recommend environment variables or a secret manager where relevant.
 - Decide from the actual change whether README, architecture or API docs, OpenAPI, CHANGELOG, CONTRIBUTING, `.env.example`, ADRs, or runbooks need an update. Name the exact change needed. Skip documentation for trivial internal changes unless it helps future maintenance.
 
+Before cleanup, when a completed task used a team and its applicable checks are green, invoke `olko:team-retrospective` to collect each agent’s report and safely dismiss task-owned agents. If unavailable, report the limitation; do not claim closeout ran.
+
 ## 4. Prepare safe cleanup
 
 - Propose cleanup commands only. Do not remove any file, branch, or worktree automatically, including generated or temporary files. Never propose deletion of an unknown untracked file, broad directory, or unresolved glob.

package/.windsurf/rules/app-store-regional-pricing.md

@@ -0,0 +1,26 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Research, propose, and verify App Store and in-app purchase prices by storefront using affordability evidence and Apple price points."
+---
+
+# App Store regional pricing
+
+Use for storefront pricing that reflects local affordability, including one-time purchases and subscriptions. Do not confuse the app download price with a separate in-app purchase.
+
+1. Identify the exact app, product ID, purchase type, base storefront, current schedule, availability, effective dates, and any existing custom prices. Inspect the live schedule before proposing changes; never assume exchange-rate equalization is purchasing-power pricing.
+2. Establish the user's base price and commercial constraints. Research current, dated primary sources for affordability (for example World Bank income or GDP per capita and PPP data), taxes, applicable Apple rules, and relevant market evidence. GDP per capita is a rough proxy, not a measure of every customer's income. Record missing or stale data and avoid unsupported precision.
+3. Propose a transparent, reproducible price ladder and country assignments, with the actual Apple storefront currency and allowed price point for each. Account for tax treatment, Apple proceeds, minimum viable revenue, and commercial judgment; distinguish observed figures from proposed estimates. Review outliers, dollar-denominated storefronts, and availability. Do not claim a price is objectively fair or promise a currency the storefront does not support.
+4. Follow the user's authorized scope for changes. Preserve the base and unrelated existing prices unless requested. For material unresolved business choices, present concrete options before applying them. Do not buy, submit for review, or release the app as a side effect.
+5. Use the existing project workflow, CLI, or connected UI to configure custom storefront prices. Check effective dates, current and future schedules, and whether the change replaces existing overrides. Apple states manually managed regions are not automatically updated for exchange rate or tax changes; identify the monitoring owner and review cadence.
+6. Reopen the saved schedule and verify the exact product, dates, storefronts, amounts, currencies, and unaffected base. Report applied versus proposed prices and remaining coverage. If sandbox or storefront purchase testing is unavailable, say so. Note that the customer's Apple account storefront determines the price, not necessarily physical location.
+
+## Post-launch review
+
+- Confirm the app is actually available for sale and record the launch date before interpreting sales. If it has not launched, report the review as pending; schedule the first review only if a real scheduling tool can anchor it to 30 days after the actual launch. Set a fixed calendar date only after the launch date is recorded. Do not claim a reminder was created without a verified schedule.
+- At approximately 30 days and 90 days after launch, and quarterly thereafter, retrieve the latest available App Store Connect Analytics and Sales and Trends reports using an authorized workflow. Record the report dates, timezone, product, storefront, currency, report freshness, and missing or suppressed data. Distinguish downloads, product-page views, purchases, refunds, and proceeds; do not count TestFlight or sandbox activity as sales.
+- Compare storefront purchase conversion only when the numerator and denominator cover the same product, audience, and period. Compare net proceeds and refunds as well as unit sales, and segment by acquisition source where available. Record sample sizes and avoid conclusions from sparse data, privacy thresholds, or incomplete reporting. Pricing is one possible cause of differences, not proof of causation.
+- Recheck manual prices against current exchange rates, taxes, local purchasing-power indicators, and Apple price points. List changes since the previous review, markets needing attention, and the dates and sources of evidence. Account for Apple commissions and local tax treatment without guessing actual proceeds.
+- Recommend a small, reversible set of changes with current and proposed prices, expected tradeoffs, and follow-up date. Respect the user's authorization and product-specific pricing rules; verify each saved schedule and distinguish scheduled changes from active prices. Never promise a future review will happen without a functioning automation or explicit follow-up.
+
+Primary references: [Set a price for an In-App Purchase](https://developer.apple.com/help/app-store-connect/manage-in-app-purchases/set-a-price-for-an-in-app-purchase), [Apple pricing](https://developer.apple.com/in-app-purchase/), [World Bank data](https://data.worldbank.org/indicator/NY.GDP.PCAP.PP.CD). Check current documentation for product-specific behavior before making changes.

package/.windsurf/rules/team-retrospective.md

@@ -0,0 +1,29 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Collect each task agent’s factual retrospective and safely dismiss the team after successful work."
+---
+
+# Team retrospective
+
+Run after a multi-agent task is complete and its applicable checks are green,
+before dismissing its agents. Explicit user instructions to retain agents or
+finish early take precedence. Do not spawn agents solely to run this skill.
+
+1. Identify agents, tabs, and sessions owned by this task using the environment's
+   actual inventory and recorded ownership. Preserve other tasks and sessions.
+2. Ask each reachable agent for a concise factual report: what went wrong, failed
+   approaches, tool or coordination problems, resolutions, and unresolved items.
+   Ask them to distinguish direct observation from inference. A clean report may
+   say no issues. Do not request new implementation or speculative findings.
+3. Collect each response, or label it unavailable with the reason. Preserve useful
+   findings and a concise summary in an appropriate task artifact; avoid secrets,
+   unnecessary transcripts, and public disclosure. Report recurring issues and
+   unresolved items to the user. Claims remain reports until independently verified.
+4. Confirm work and required handoffs are preserved. Dismiss the task-owned agents
+   and close only their task-owned tabs or panes when safe; verify the result.
+   Follow the environment's skill and safety rules. Never stop a shared server or
+   close another task's session. Respect explicit instructions to keep agents.
+5. If work is blocked, unfinished, or still active, preserve the agents and report
+   the blocker instead of treating the task as green. If the environment cannot
+   contact or dismiss an agent, report the limitation; never claim it was dismissed.

package/.windsurf/rules/wrap-up.md

@@ -28,6 +28,8 @@ Use this as a proportional end-of-task audit. Preserve pre-existing work and do
 - Check the diff and untracked files for keys, tokens, passwords, private keys, connection strings, cookies, personal data, and credentials in logs or examples. Report locations without printing values; recommend environment variables or a secret manager where relevant.
 - Decide from the actual change whether README, architecture or API docs, OpenAPI, CHANGELOG, CONTRIBUTING, `.env.example`, ADRs, or runbooks need an update. Name the exact change needed. Skip documentation for trivial internal changes unless it helps future maintenance.
 
+Before cleanup, when a completed task used a team and its applicable checks are green, invoke `olko:team-retrospective` to collect each agent’s report and safely dismiss task-owned agents. If unavailable, report the limitation; do not claim closeout ran.
+
 ## 4. Prepare safe cleanup
 
 - Propose cleanup commands only. Do not remove any file, branch, or worktree automatically, including generated or temporary files. Never propose deletion of an unknown untracked file, broad directory, or unresolved glob.

package/README.md

@@ -304,6 +304,7 @@ Look back and improve: self-critique, retrospectives, performance review, rapid
 | [self-critique](plugins/olko-reflection/skills/self-critique/SKILL.md) | Adversarially critiques your own last answer: a blind critic agent re-derives and verifies every claim against live sources, the score is computed from a labelled claim ledger, you revise under a ratchet, restate the corrected answer, and turn each caught error into a durable rule with a fire counter | Checking a substantial answer before the user has to |
 | [review-past-performance](plugins/olko-reflection/skills/review-past-performance/SKILL.md) | Pulls 24h of ICM memories, git history, and skill analytics; detects repeated mistakes and slow workflows; proposes 1-3 concrete fixes | Daily self-improvement loop or codifying a repeated workflow |
 | [retro-analysis](plugins/olko-reflection/skills/retro-analysis/SKILL.md) | Produces repository, comparison, and cross-project retrospectives from delivery, code-quality, work-pattern, and trend evidence | The user asks for a retro over shipped work ("run a retrospective", "how did this quarter go", "what did we ship") or a scheduled retro job fires; for agent-operations retros use agent-ops-retro, for a single finished change use wrap-up |
+| [team-retrospective](plugins/olko-reflection/skills/team-retrospective/SKILL.md) | Collects agent reports and safely dismisses a completed team | During wrap-up of a green multi-agent task |
 | [agent-ops-retro](plugins/olko-reflection/skills/agent-ops-retro/SKILL.md) | Retrospective on how the agents themselves are being operated: mines local transcripts and reads the reports other jobs already produce to surface what the human keeps repeating, what the guardrails caught, and where delivery leaked, carrying unactioned findings forward | Checking agent usage, delegation cost, or repeating corrections across sessions rather than shipped code |
 | [crash-course](plugins/olko-reflection/skills/crash-course/SKILL.md) | Expert tutor for rapid, source-grounded learning of any topic: a timed 4-hour sprint plus cheat-sheet, learning-ladder, quiz-me, Feynman, and resource-curation modes | Ramping up on an unfamiliar codebase, project, or concept under time pressure |
 | [wrap-up](plugins/olko-reflection/skills/wrap-up/SKILL.md) | Verifies work against its original objective, checks applicable gates, audits task-owned artifacts, and proposes safe cleanup | A change is believed done and the user says "wrap up", "we are done here", or "clean up after this", or before handing work off; for a retro over repository history use retro-analysis |
@@ -318,13 +319,14 @@ Keep an Obsidian vault in sync with work: PR sync, task rollover, morning routin
 | [obsidian-task-rollover](plugins/olko-obsidian/skills/obsidian-task-rollover/SKILL.md) | Migrates unchecked tasks from today's Obsidian daily note to the next workday under `## Carried over` | End-of-day bullet-journal task migration |
 | [morning-routine](plugins/olko-obsidian/skills/morning-routine/SKILL.md) | Runs the complete start-of-day setup in one pass: rolls over unfinished Obsidian tasks, syncs open GitHub PRs into today's daily note, and sweeps safe Dependabot patch bumps | Starting the workday by chaining obsidian-task-rollover, obsidian-pr-sync, and dependabot-triage in sequence |
 
-### olko-apple-kit (2)
+### olko-apple-kit (3)
 
 Build and ship Apple platform apps: macOS menubar apps, App Store submissions.
 
 | Skill | What it does | Use when |
 |-------|-------------|----------|
 | [apple-store-submit](plugins/olko-apple-kit/skills/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 |
+| [app-store-regional-pricing](plugins/olko-apple-kit/skills/app-store-regional-pricing/SKILL.md) | Researches affordability and configures storefront-specific App Store prices | Pricing apps and in-app purchases for different markets |
 | [macos-menubar-app](plugins/olko-apple-kit/skills/macos-menubar-app/SKILL.md) | Builds a production-quality macOS menubar or notch app in SwiftUI, MenuBarExtra setup, sandbox entitlements, keyboard shortcuts, sound effects | Building a native macOS utility that lives in the menu bar or Dynamic Island notch |
 
 ### olko-garmin-kit (1)

package/adapters/claude/olko-apple-kit/skills/app-store-regional-pricing/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: app-store-regional-pricing
+description: Research and configure App Store and in-app purchase prices by storefront using affordability evidence and available Apple price points.
+license: MIT
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# App Store regional pricing
+
+Use for storefront pricing that reflects local affordability, including one-time purchases and subscriptions. Do not confuse the app download price with a separate in-app purchase.
+
+1. Identify the exact app, product ID, purchase type, base storefront, current schedule, availability, effective dates, and any existing custom prices. Inspect the live schedule before proposing changes; never assume exchange-rate equalization is purchasing-power pricing.
+2. Establish the user's base price and commercial constraints. Research current, dated primary sources for affordability (for example World Bank income or GDP per capita and PPP data), taxes, applicable Apple rules, and relevant market evidence. GDP per capita is a rough proxy, not a measure of every customer's income. Record missing or stale data and avoid unsupported precision.
+3. Propose a transparent, reproducible price ladder and country assignments, with the actual Apple storefront currency and allowed price point for each. Account for tax treatment, Apple proceeds, minimum viable revenue, and commercial judgment; distinguish observed figures from proposed estimates. Review outliers, dollar-denominated storefronts, and availability. Do not claim a price is objectively fair or promise a currency the storefront does not support.
+4. Follow the user's authorized scope for changes. Preserve the base and unrelated existing prices unless requested. For material unresolved business choices, present concrete options before applying them. Do not buy, submit for review, or release the app as a side effect.
+5. Use the existing project workflow, CLI, or connected UI to configure custom storefront prices. Check effective dates, current and future schedules, and whether the change replaces existing overrides. Apple states manually managed regions are not automatically updated for exchange rate or tax changes; identify the monitoring owner and review cadence.
+6. Reopen the saved schedule and verify the exact product, dates, storefronts, amounts, currencies, and unaffected base. Report applied versus proposed prices and remaining coverage. If sandbox or storefront purchase testing is unavailable, say so. Note that the customer's Apple account storefront determines the price, not necessarily physical location.
+
+## Post-launch review
+
+- Confirm the app is actually available for sale and record the launch date before interpreting sales. If it has not launched, report the review as pending; schedule the first review only if a real scheduling tool can anchor it to 30 days after the actual launch. Set a fixed calendar date only after the launch date is recorded. Do not claim a reminder was created without a verified schedule.
+- At approximately 30 days and 90 days after launch, and quarterly thereafter, retrieve the latest available App Store Connect Analytics and Sales and Trends reports using an authorized workflow. Record the report dates, timezone, product, storefront, currency, report freshness, and missing or suppressed data. Distinguish downloads, product-page views, purchases, refunds, and proceeds; do not count TestFlight or sandbox activity as sales.
+- Compare storefront purchase conversion only when the numerator and denominator cover the same product, audience, and period. Compare net proceeds and refunds as well as unit sales, and segment by acquisition source where available. Record sample sizes and avoid conclusions from sparse data, privacy thresholds, or incomplete reporting. Pricing is one possible cause of differences, not proof of causation.
+- Recheck manual prices against current exchange rates, taxes, local purchasing-power indicators, and Apple price points. List changes since the previous review, markets needing attention, and the dates and sources of evidence. Account for Apple commissions and local tax treatment without guessing actual proceeds.
+- Recommend a small, reversible set of changes with current and proposed prices, expected tradeoffs, and follow-up date. Respect the user's authorization and product-specific pricing rules; verify each saved schedule and distinguish scheduled changes from active prices. Never promise a future review will happen without a functioning automation or explicit follow-up.
+
+Primary references: [Set a price for an In-App Purchase](https://developer.apple.com/help/app-store-connect/manage-in-app-purchases/set-a-price-for-an-in-app-purchase), [Apple pricing](https://developer.apple.com/in-app-purchase/), [World Bank data](https://data.worldbank.org/indicator/NY.GDP.PCAP.PP.CD). Check current documentation for product-specific behavior before making changes.

package/adapters/claude/olko-reflection/skills/team-retrospective/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: team-retrospective
+description: Collect a factual retrospective from each task-owned agent and safely dismiss the team after successful work. Use during wrap-up of a completed, green multi-agent task or when explicitly requested.
+license: MIT
+compatibility: Codex, Claude Code, and other agent environments with delegation controls.
+metadata:
+  author: Oleg Koval
+  tags:
+    - agents
+    - retrospective
+    - delegation
+    - cleanup
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# Team retrospective
+
+Run after a multi-agent task is complete and its applicable checks are green,
+before dismissing its agents. Explicit user instructions to retain agents or
+finish early take precedence. Do not spawn agents solely to run this skill.
+
+1. Identify agents, tabs, and sessions owned by this task using the environment's
+   actual inventory and recorded ownership. Preserve other tasks and sessions.
+2. Ask each reachable agent for a concise factual report: what went wrong, failed
+   approaches, tool or coordination problems, resolutions, and unresolved items.
+   Ask them to distinguish direct observation from inference. A clean report may
+   say no issues. Do not request new implementation or speculative findings.
+3. Collect each response, or label it unavailable with the reason. Preserve useful
+   findings and a concise summary in an appropriate task artifact; avoid secrets,
+   unnecessary transcripts, and public disclosure. Report recurring issues and
+   unresolved items to the user. Claims remain reports until independently verified.
+4. Confirm work and required handoffs are preserved. Dismiss the task-owned agents
+   and close only their task-owned tabs or panes when safe; verify the result.
+   Follow the environment's skill and safety rules. Never stop a shared server or
+   close another task's session. Respect explicit instructions to keep agents.
+5. If work is blocked, unfinished, or still active, preserve the agents and report
+   the blocker instead of treating the task as green. If the environment cannot
+   contact or dismiss an agent, report the limitation; never claim it was dismissed.

package/adapters/claude/olko-reflection/skills/wrap-up/SKILL.md

@@ -43,6 +43,8 @@ Use this as a proportional end-of-task audit. Preserve pre-existing work and do
 - Check the diff and untracked files for keys, tokens, passwords, private keys, connection strings, cookies, personal data, and credentials in logs or examples. Report locations without printing values; recommend environment variables or a secret manager where relevant.
 - Decide from the actual change whether README, architecture or API docs, OpenAPI, CHANGELOG, CONTRIBUTING, `.env.example`, ADRs, or runbooks need an update. Name the exact change needed. Skip documentation for trivial internal changes unless it helps future maintenance.
 
+Before cleanup, when a completed task used a team and its applicable checks are green, invoke `olko:team-retrospective` to collect each agent’s report and safely dismiss task-owned agents. If unavailable, report the limitation; do not claim closeout ran.
+
 ## 4. Prepare safe cleanup
 
 - Propose cleanup commands only. Do not remove any file, branch, or worktree automatically, including generated or temporary files. Never propose deletion of an unknown untracked file, broad directory, or unresolved glob.

package/adapters/codex/olko-apple-kit/README.md

@@ -4,5 +4,6 @@
 
 Use the canonical skills directly:
 
+- `plugins/olko-apple-kit/skills/app-store-regional-pricing/SKILL.md`
 - `plugins/olko-apple-kit/skills/apple-store-submit/SKILL.md`
 - `plugins/olko-apple-kit/skills/macos-menubar-app/SKILL.md`

package/adapters/codex/olko-reflection/README.md

@@ -10,3 +10,4 @@ Use the canonical skills directly:
 - `plugins/olko-reflection/skills/agent-ops-retro/SKILL.md`
 - `plugins/olko-reflection/skills/crash-course/SKILL.md`
 - `plugins/olko-reflection/skills/wrap-up/SKILL.md`
+- `plugins/olko-reflection/skills/team-retrospective/SKILL.md`

package/adapters/cursor/olko-apple-kit/skills/app-store-regional-pricing/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: app-store-regional-pricing
+description: Research and configure App Store and in-app purchase prices by storefront using affordability evidence and available Apple price points.
+license: MIT
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# App Store regional pricing
+
+Use for storefront pricing that reflects local affordability, including one-time purchases and subscriptions. Do not confuse the app download price with a separate in-app purchase.
+
+1. Identify the exact app, product ID, purchase type, base storefront, current schedule, availability, effective dates, and any existing custom prices. Inspect the live schedule before proposing changes; never assume exchange-rate equalization is purchasing-power pricing.
+2. Establish the user's base price and commercial constraints. Research current, dated primary sources for affordability (for example World Bank income or GDP per capita and PPP data), taxes, applicable Apple rules, and relevant market evidence. GDP per capita is a rough proxy, not a measure of every customer's income. Record missing or stale data and avoid unsupported precision.
+3. Propose a transparent, reproducible price ladder and country assignments, with the actual Apple storefront currency and allowed price point for each. Account for tax treatment, Apple proceeds, minimum viable revenue, and commercial judgment; distinguish observed figures from proposed estimates. Review outliers, dollar-denominated storefronts, and availability. Do not claim a price is objectively fair or promise a currency the storefront does not support.
+4. Follow the user's authorized scope for changes. Preserve the base and unrelated existing prices unless requested. For material unresolved business choices, present concrete options before applying them. Do not buy, submit for review, or release the app as a side effect.
+5. Use the existing project workflow, CLI, or connected UI to configure custom storefront prices. Check effective dates, current and future schedules, and whether the change replaces existing overrides. Apple states manually managed regions are not automatically updated for exchange rate or tax changes; identify the monitoring owner and review cadence.
+6. Reopen the saved schedule and verify the exact product, dates, storefronts, amounts, currencies, and unaffected base. Report applied versus proposed prices and remaining coverage. If sandbox or storefront purchase testing is unavailable, say so. Note that the customer's Apple account storefront determines the price, not necessarily physical location.
+
+## Post-launch review
+
+- Confirm the app is actually available for sale and record the launch date before interpreting sales. If it has not launched, report the review as pending; schedule the first review only if a real scheduling tool can anchor it to 30 days after the actual launch. Set a fixed calendar date only after the launch date is recorded. Do not claim a reminder was created without a verified schedule.
+- At approximately 30 days and 90 days after launch, and quarterly thereafter, retrieve the latest available App Store Connect Analytics and Sales and Trends reports using an authorized workflow. Record the report dates, timezone, product, storefront, currency, report freshness, and missing or suppressed data. Distinguish downloads, product-page views, purchases, refunds, and proceeds; do not count TestFlight or sandbox activity as sales.
+- Compare storefront purchase conversion only when the numerator and denominator cover the same product, audience, and period. Compare net proceeds and refunds as well as unit sales, and segment by acquisition source where available. Record sample sizes and avoid conclusions from sparse data, privacy thresholds, or incomplete reporting. Pricing is one possible cause of differences, not proof of causation.
+- Recheck manual prices against current exchange rates, taxes, local purchasing-power indicators, and Apple price points. List changes since the previous review, markets needing attention, and the dates and sources of evidence. Account for Apple commissions and local tax treatment without guessing actual proceeds.
+- Recommend a small, reversible set of changes with current and proposed prices, expected tradeoffs, and follow-up date. Respect the user's authorization and product-specific pricing rules; verify each saved schedule and distinguish scheduled changes from active prices. Never promise a future review will happen without a functioning automation or explicit follow-up.
+
+Primary references: [Set a price for an In-App Purchase](https://developer.apple.com/help/app-store-connect/manage-in-app-purchases/set-a-price-for-an-in-app-purchase), [Apple pricing](https://developer.apple.com/in-app-purchase/), [World Bank data](https://data.worldbank.org/indicator/NY.GDP.PCAP.PP.CD). Check current documentation for product-specific behavior before making changes.

package/adapters/cursor/olko-reflection/skills/team-retrospective/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: team-retrospective
+description: Collect a factual retrospective from each task-owned agent and safely dismiss the team after successful work. Use during wrap-up of a completed, green multi-agent task or when explicitly requested.
+license: MIT
+compatibility: Codex, Claude Code, and other agent environments with delegation controls.
+metadata:
+  author: Oleg Koval
+  tags:
+    - agents
+    - retrospective
+    - delegation
+    - cleanup
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# Team retrospective
+
+Run after a multi-agent task is complete and its applicable checks are green,
+before dismissing its agents. Explicit user instructions to retain agents or
+finish early take precedence. Do not spawn agents solely to run this skill.
+
+1. Identify agents, tabs, and sessions owned by this task using the environment's
+   actual inventory and recorded ownership. Preserve other tasks and sessions.
+2. Ask each reachable agent for a concise factual report: what went wrong, failed
+   approaches, tool or coordination problems, resolutions, and unresolved items.
+   Ask them to distinguish direct observation from inference. A clean report may
+   say no issues. Do not request new implementation or speculative findings.
+3. Collect each response, or label it unavailable with the reason. Preserve useful
+   findings and a concise summary in an appropriate task artifact; avoid secrets,
+   unnecessary transcripts, and public disclosure. Report recurring issues and
+   unresolved items to the user. Claims remain reports until independently verified.
+4. Confirm work and required handoffs are preserved. Dismiss the task-owned agents
+   and close only their task-owned tabs or panes when safe; verify the result.
+   Follow the environment's skill and safety rules. Never stop a shared server or
+   close another task's session. Respect explicit instructions to keep agents.
+5. If work is blocked, unfinished, or still active, preserve the agents and report
+   the blocker instead of treating the task as green. If the environment cannot
+   contact or dismiss an agent, report the limitation; never claim it was dismissed.

package/adapters/cursor/olko-reflection/skills/wrap-up/SKILL.md

@@ -43,6 +43,8 @@ Use this as a proportional end-of-task audit. Preserve pre-existing work and do
 - Check the diff and untracked files for keys, tokens, passwords, private keys, connection strings, cookies, personal data, and credentials in logs or examples. Report locations without printing values; recommend environment variables or a secret manager where relevant.
 - Decide from the actual change whether README, architecture or API docs, OpenAPI, CHANGELOG, CONTRIBUTING, `.env.example`, ADRs, or runbooks need an update. Name the exact change needed. Skip documentation for trivial internal changes unless it helps future maintenance.
 
+Before cleanup, when a completed task used a team and its applicable checks are green, invoke `olko:team-retrospective` to collect each agent’s report and safely dismiss task-owned agents. If unavailable, report the limitation; do not claim closeout ran.
+
 ## 4. Prepare safe cleanup
 
 - Propose cleanup commands only. Do not remove any file, branch, or worktree automatically, including generated or temporary files. Never propose deletion of an unknown untracked file, broad directory, or unresolved glob.

package/adapters/grok/olko-apple-kit/skills/app-store-regional-pricing/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: app-store-regional-pricing
+description: Research and configure App Store and in-app purchase prices by storefront using affordability evidence and available Apple price points.
+license: MIT
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# App Store regional pricing
+
+Use for storefront pricing that reflects local affordability, including one-time purchases and subscriptions. Do not confuse the app download price with a separate in-app purchase.
+
+1. Identify the exact app, product ID, purchase type, base storefront, current schedule, availability, effective dates, and any existing custom prices. Inspect the live schedule before proposing changes; never assume exchange-rate equalization is purchasing-power pricing.
+2. Establish the user's base price and commercial constraints. Research current, dated primary sources for affordability (for example World Bank income or GDP per capita and PPP data), taxes, applicable Apple rules, and relevant market evidence. GDP per capita is a rough proxy, not a measure of every customer's income. Record missing or stale data and avoid unsupported precision.
+3. Propose a transparent, reproducible price ladder and country assignments, with the actual Apple storefront currency and allowed price point for each. Account for tax treatment, Apple proceeds, minimum viable revenue, and commercial judgment; distinguish observed figures from proposed estimates. Review outliers, dollar-denominated storefronts, and availability. Do not claim a price is objectively fair or promise a currency the storefront does not support.
+4. Follow the user's authorized scope for changes. Preserve the base and unrelated existing prices unless requested. For material unresolved business choices, present concrete options before applying them. Do not buy, submit for review, or release the app as a side effect.
+5. Use the existing project workflow, CLI, or connected UI to configure custom storefront prices. Check effective dates, current and future schedules, and whether the change replaces existing overrides. Apple states manually managed regions are not automatically updated for exchange rate or tax changes; identify the monitoring owner and review cadence.
+6. Reopen the saved schedule and verify the exact product, dates, storefronts, amounts, currencies, and unaffected base. Report applied versus proposed prices and remaining coverage. If sandbox or storefront purchase testing is unavailable, say so. Note that the customer's Apple account storefront determines the price, not necessarily physical location.
+
+## Post-launch review
+
+- Confirm the app is actually available for sale and record the launch date before interpreting sales. If it has not launched, report the review as pending; schedule the first review only if a real scheduling tool can anchor it to 30 days after the actual launch. Set a fixed calendar date only after the launch date is recorded. Do not claim a reminder was created without a verified schedule.
+- At approximately 30 days and 90 days after launch, and quarterly thereafter, retrieve the latest available App Store Connect Analytics and Sales and Trends reports using an authorized workflow. Record the report dates, timezone, product, storefront, currency, report freshness, and missing or suppressed data. Distinguish downloads, product-page views, purchases, refunds, and proceeds; do not count TestFlight or sandbox activity as sales.
+- Compare storefront purchase conversion only when the numerator and denominator cover the same product, audience, and period. Compare net proceeds and refunds as well as unit sales, and segment by acquisition source where available. Record sample sizes and avoid conclusions from sparse data, privacy thresholds, or incomplete reporting. Pricing is one possible cause of differences, not proof of causation.
+- Recheck manual prices against current exchange rates, taxes, local purchasing-power indicators, and Apple price points. List changes since the previous review, markets needing attention, and the dates and sources of evidence. Account for Apple commissions and local tax treatment without guessing actual proceeds.
+- Recommend a small, reversible set of changes with current and proposed prices, expected tradeoffs, and follow-up date. Respect the user's authorization and product-specific pricing rules; verify each saved schedule and distinguish scheduled changes from active prices. Never promise a future review will happen without a functioning automation or explicit follow-up.
+
+Primary references: [Set a price for an In-App Purchase](https://developer.apple.com/help/app-store-connect/manage-in-app-purchases/set-a-price-for-an-in-app-purchase), [Apple pricing](https://developer.apple.com/in-app-purchase/), [World Bank data](https://data.worldbank.org/indicator/NY.GDP.PCAP.PP.CD). Check current documentation for product-specific behavior before making changes.

package/adapters/grok/olko-reflection/skills/team-retrospective/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: team-retrospective
+description: Collect a factual retrospective from each task-owned agent and safely dismiss the team after successful work. Use during wrap-up of a completed, green multi-agent task or when explicitly requested.
+license: MIT
+compatibility: Codex, Claude Code, and other agent environments with delegation controls.
+metadata:
+  author: Oleg Koval
+  tags:
+    - agents
+    - retrospective
+    - delegation
+    - cleanup
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# Team retrospective
+
+Run after a multi-agent task is complete and its applicable checks are green,
+before dismissing its agents. Explicit user instructions to retain agents or
+finish early take precedence. Do not spawn agents solely to run this skill.
+
+1. Identify agents, tabs, and sessions owned by this task using the environment's
+   actual inventory and recorded ownership. Preserve other tasks and sessions.
+2. Ask each reachable agent for a concise factual report: what went wrong, failed
+   approaches, tool or coordination problems, resolutions, and unresolved items.
+   Ask them to distinguish direct observation from inference. A clean report may
+   say no issues. Do not request new implementation or speculative findings.
+3. Collect each response, or label it unavailable with the reason. Preserve useful
+   findings and a concise summary in an appropriate task artifact; avoid secrets,
+   unnecessary transcripts, and public disclosure. Report recurring issues and
+   unresolved items to the user. Claims remain reports until independently verified.
+4. Confirm work and required handoffs are preserved. Dismiss the task-owned agents
+   and close only their task-owned tabs or panes when safe; verify the result.
+   Follow the environment's skill and safety rules. Never stop a shared server or
+   close another task's session. Respect explicit instructions to keep agents.
+5. If work is blocked, unfinished, or still active, preserve the agents and report
+   the blocker instead of treating the task as green. If the environment cannot
+   contact or dismiss an agent, report the limitation; never claim it was dismissed.

package/adapters/grok/olko-reflection/skills/wrap-up/SKILL.md

@@ -43,6 +43,8 @@ Use this as a proportional end-of-task audit. Preserve pre-existing work and do
 - Check the diff and untracked files for keys, tokens, passwords, private keys, connection strings, cookies, personal data, and credentials in logs or examples. Report locations without printing values; recommend environment variables or a secret manager where relevant.
 - Decide from the actual change whether README, architecture or API docs, OpenAPI, CHANGELOG, CONTRIBUTING, `.env.example`, ADRs, or runbooks need an update. Name the exact change needed. Skip documentation for trivial internal changes unless it helps future maintenance.
 
+Before cleanup, when a completed task used a team and its applicable checks are green, invoke `olko:team-retrospective` to collect each agent’s report and safely dismiss task-owned agents. If unavailable, report the limitation; do not claim closeout ran.
+
 ## 4. Prepare safe cleanup
 
 - Propose cleanup commands only. Do not remove any file, branch, or worktree automatically, including generated or temporary files. Never propose deletion of an unknown untracked file, broad directory, or unresolved glob.

package/adapters/hermes/olko-apple-kit/README.md

@@ -5,5 +5,6 @@
 Run `./scripts/install-hermes-symlinks.sh` from the repository root to link these skills
 into the active Hermes profile. The canonical packages are:
 
+- `plugins/olko-apple-kit/skills/app-store-regional-pricing/SKILL.md`
 - `plugins/olko-apple-kit/skills/apple-store-submit/SKILL.md`
 - `plugins/olko-apple-kit/skills/macos-menubar-app/SKILL.md`

package/adapters/hermes/olko-reflection/README.md

@@ -11,3 +11,4 @@ into the active Hermes profile. The canonical packages are:
 - `plugins/olko-reflection/skills/agent-ops-retro/SKILL.md`
 - `plugins/olko-reflection/skills/crash-course/SKILL.md`
 - `plugins/olko-reflection/skills/wrap-up/SKILL.md`
+- `plugins/olko-reflection/skills/team-retrospective/SKILL.md`

package/catalog/skills.json

@@ -1029,6 +1029,28 @@
             "grok",
             "hermes"
           ]
+        },
+        {
+          "name": "team-retrospective",
+          "lookupName": "olko:team-retrospective",
+          "path": "plugins/olko-reflection/skills/team-retrospective",
+          "description": "Collect each task agent\u2019s factual retrospective and safely dismiss the team after successful work.",
+          "tags": [
+            "agents",
+            "retrospective",
+            "delegation",
+            "cleanup"
+          ],
+          "adapters": [
+            "codex",
+            "claude",
+            "cursor",
+            "copilot",
+            "windsurf",
+            "kiro",
+            "grok",
+            "hermes"
+          ]
         }
       ]
     },
@@ -1120,6 +1142,28 @@
       "name": "olko-apple-kit",
       "description": "Build and ship Apple platform apps: macOS menubar apps, App Store submissions.",
       "skills": [
+        {
+          "name": "app-store-regional-pricing",
+          "lookupName": "olko:app-store-regional-pricing",
+          "path": "plugins/olko-apple-kit/skills/app-store-regional-pricing",
+          "description": "Research, propose, and verify App Store and in-app purchase prices by storefront using affordability evidence and Apple price points.",
+          "tags": [
+            "apple",
+            "app-store",
+            "pricing",
+            "localization"
+          ],
+          "adapters": [
+            "codex",
+            "claude",
+            "cursor",
+            "copilot",
+            "windsurf",
+            "kiro",
+            "grok",
+            "hermes"
+          ]
+        },
         {
           "name": "apple-store-submit",
           "lookupName": "olko:apple-store-submit",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@olegkoval/agent-skills",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "private": false,
   "publishConfig": {
     "access": "public"

package/plugins/olko-apple-kit/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-apple-kit",
   "description": "Build and ship Apple platform apps: macOS menubar apps, App Store submissions.",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-apple-kit/skills/app-store-regional-pricing/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: app-store-regional-pricing
+description: Research and configure App Store and in-app purchase prices by storefront using affordability evidence and available Apple price points.
+license: MIT
+---
+
+# App Store regional pricing
+
+Use for storefront pricing that reflects local affordability, including one-time purchases and subscriptions. Do not confuse the app download price with a separate in-app purchase.
+
+1. Identify the exact app, product ID, purchase type, base storefront, current schedule, availability, effective dates, and any existing custom prices. Inspect the live schedule before proposing changes; never assume exchange-rate equalization is purchasing-power pricing.
+2. Establish the user's base price and commercial constraints. Research current, dated primary sources for affordability (for example World Bank income or GDP per capita and PPP data), taxes, applicable Apple rules, and relevant market evidence. GDP per capita is a rough proxy, not a measure of every customer's income. Record missing or stale data and avoid unsupported precision.
+3. Propose a transparent, reproducible price ladder and country assignments, with the actual Apple storefront currency and allowed price point for each. Account for tax treatment, Apple proceeds, minimum viable revenue, and commercial judgment; distinguish observed figures from proposed estimates. Review outliers, dollar-denominated storefronts, and availability. Do not claim a price is objectively fair or promise a currency the storefront does not support.
+4. Follow the user's authorized scope for changes. Preserve the base and unrelated existing prices unless requested. For material unresolved business choices, present concrete options before applying them. Do not buy, submit for review, or release the app as a side effect.
+5. Use the existing project workflow, CLI, or connected UI to configure custom storefront prices. Check effective dates, current and future schedules, and whether the change replaces existing overrides. Apple states manually managed regions are not automatically updated for exchange rate or tax changes; identify the monitoring owner and review cadence.
+6. Reopen the saved schedule and verify the exact product, dates, storefronts, amounts, currencies, and unaffected base. Report applied versus proposed prices and remaining coverage. If sandbox or storefront purchase testing is unavailable, say so. Note that the customer's Apple account storefront determines the price, not necessarily physical location.
+
+## Post-launch review
+
+- Confirm the app is actually available for sale and record the launch date before interpreting sales. If it has not launched, report the review as pending; schedule the first review only if a real scheduling tool can anchor it to 30 days after the actual launch. Set a fixed calendar date only after the launch date is recorded. Do not claim a reminder was created without a verified schedule.
+- At approximately 30 days and 90 days after launch, and quarterly thereafter, retrieve the latest available App Store Connect Analytics and Sales and Trends reports using an authorized workflow. Record the report dates, timezone, product, storefront, currency, report freshness, and missing or suppressed data. Distinguish downloads, product-page views, purchases, refunds, and proceeds; do not count TestFlight or sandbox activity as sales.
+- Compare storefront purchase conversion only when the numerator and denominator cover the same product, audience, and period. Compare net proceeds and refunds as well as unit sales, and segment by acquisition source where available. Record sample sizes and avoid conclusions from sparse data, privacy thresholds, or incomplete reporting. Pricing is one possible cause of differences, not proof of causation.
+- Recheck manual prices against current exchange rates, taxes, local purchasing-power indicators, and Apple price points. List changes since the previous review, markets needing attention, and the dates and sources of evidence. Account for Apple commissions and local tax treatment without guessing actual proceeds.
+- Recommend a small, reversible set of changes with current and proposed prices, expected tradeoffs, and follow-up date. Respect the user's authorization and product-specific pricing rules; verify each saved schedule and distinguish scheduled changes from active prices. Never promise a future review will happen without a functioning automation or explicit follow-up.
+
+Primary references: [Set a price for an In-App Purchase](https://developer.apple.com/help/app-store-connect/manage-in-app-purchases/set-a-price-for-an-in-app-purchase), [Apple pricing](https://developer.apple.com/in-app-purchase/), [World Bank data](https://data.worldbank.org/indicator/NY.GDP.PCAP.PP.CD). Check current documentation for product-specific behavior before making changes.

package/plugins/olko-creative/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-creative",
   "description": "Creative and personal projects: photo galleries, music players, listings, wiki editing.",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-garmin-kit/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-garmin-kit",
   "description": "Build, test and publish Garmin Connect IQ watch faces.",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-git-tools/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-git-tools",
   "description": "Everyday git and GitHub CLI operations: conventional commits, branch hygiene.",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-github-pr/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-github-pr",
   "description": "Drive GitHub pull requests to merge-ready: review-bot loops, CI fixes, descriptions, dependency triage.",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-obsidian/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-obsidian",
   "description": "Keep an Obsidian vault in sync with work: PR sync, task rollover, morning routine.",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-product/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-product",
   "description": "Take a product idea to a shippable build: MVP passes, full-stack scaffolds, UX/UI quality loops, launch plans.",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-reflection/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-reflection",
   "description": "Look back and improve: self-critique, retrospectives, performance review, rapid learning.",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-reflection/skills/team-retrospective/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: team-retrospective
+description: Collect a factual retrospective from each task-owned agent and safely dismiss the team after successful work. Use during wrap-up of a completed, green multi-agent task or when explicitly requested.
+license: MIT
+compatibility: Codex, Claude Code, and other agent environments with delegation controls.
+metadata:
+  author: Oleg Koval
+  tags:
+    - agents
+    - retrospective
+    - delegation
+    - cleanup
+---
+
+# Team retrospective
+
+Run after a multi-agent task is complete and its applicable checks are green,
+before dismissing its agents. Explicit user instructions to retain agents or
+finish early take precedence. Do not spawn agents solely to run this skill.
+
+1. Identify agents, tabs, and sessions owned by this task using the environment's
+   actual inventory and recorded ownership. Preserve other tasks and sessions.
+2. Ask each reachable agent for a concise factual report: what went wrong, failed
+   approaches, tool or coordination problems, resolutions, and unresolved items.
+   Ask them to distinguish direct observation from inference. A clean report may
+   say no issues. Do not request new implementation or speculative findings.
+3. Collect each response, or label it unavailable with the reason. Preserve useful
+   findings and a concise summary in an appropriate task artifact; avoid secrets,
+   unnecessary transcripts, and public disclosure. Report recurring issues and
+   unresolved items to the user. Claims remain reports until independently verified.
+4. Confirm work and required handoffs are preserved. Dismiss the task-owned agents
+   and close only their task-owned tabs or panes when safe; verify the result.
+   Follow the environment's skill and safety rules. Never stop a shared server or
+   close another task's session. Respect explicit instructions to keep agents.
+5. If work is blocked, unfinished, or still active, preserve the agents and report
+   the blocker instead of treating the task as green. If the environment cannot
+   contact or dismiss an agent, report the limitation; never claim it was dismissed.

package/plugins/olko-reflection/skills/wrap-up/SKILL.md

@@ -42,6 +42,8 @@ Use this as a proportional end-of-task audit. Preserve pre-existing work and do
 - Check the diff and untracked files for keys, tokens, passwords, private keys, connection strings, cookies, personal data, and credentials in logs or examples. Report locations without printing values; recommend environment variables or a secret manager where relevant.
 - Decide from the actual change whether README, architecture or API docs, OpenAPI, CHANGELOG, CONTRIBUTING, `.env.example`, ADRs, or runbooks need an update. Name the exact change needed. Skip documentation for trivial internal changes unless it helps future maintenance.
 
+Before cleanup, when a completed task used a team and its applicable checks are green, invoke `olko:team-retrospective` to collect each agent’s report and safely dismiss task-owned agents. If unavailable, report the limitation; do not claim closeout ran.
+
 ## 4. Prepare safe cleanup
 
 - Propose cleanup commands only. Do not remove any file, branch, or worktree automatically, including generated or temporary files. Never propose deletion of an unknown untracked file, broad directory, or unresolved glob.

package/plugins/olko-release/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-release",
   "description": "Ship a release: semantic-release setup, changelogs, store listing copy, release-day routine.",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-skill-meta/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-skill-meta",
   "description": "Author and maintain agent skills and the AI toolchain itself.",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-web-ops/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-web-ops",
   "description": "Operate a website: WAF rules, search console audits, analytics bootstrap, docs indexes.",
-  "version": "1.69.3",
+  "version": "1.70.0",
   "author": {
     "name": "Oleg Koval"
   },

package/scripts/lib/catalog.mjs

@@ -29,7 +29,7 @@ export const PLUGIN_ASSIGNMENT = {
   },
   'olko-reflection': {
     description: 'Look back and improve: self-critique, retrospectives, performance review, rapid learning.',
-    skills: ['self-critique', 'review-past-performance', 'retro-analysis', 'agent-ops-retro', 'crash-course', 'wrap-up'],
+    skills: ['self-critique', 'review-past-performance', 'retro-analysis', 'agent-ops-retro', 'crash-course', 'wrap-up', 'team-retrospective'],
   },
   'olko-obsidian': {
     description: 'Keep an Obsidian vault in sync with work: PR sync, task rollover, morning routine.',
@@ -37,7 +37,7 @@ export const PLUGIN_ASSIGNMENT = {
   },
   'olko-apple-kit': {
     description: 'Build and ship Apple platform apps: macOS menubar apps, App Store submissions.',
-    skills: ['apple-store-submit', 'macos-menubar-app'],
+    skills: ['apple-store-submit', 'app-store-regional-pricing', 'macos-menubar-app'],
   },
   'olko-garmin-kit': {
     description: 'Build, test and publish Garmin Connect IQ watch faces.',