@olegkoval/agent-skills 1.69.3 → 1.69.4

package/.github/copilot-instructions.md

@@ -53,6 +53,7 @@ Available reusable prompt files:
 - 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/.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/.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/README.md

@@ -318,13 +318,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/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/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/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/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/catalog/skills.json

@@ -1120,6 +1120,14 @@
       "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.69.4",
   "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.69.4",
   "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.69.4",
   "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.69.4",
   "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.69.4",
   "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.69.4",
   "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.69.4",
   "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.69.4",
   "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.69.4",
   "author": {
     "name": "Oleg Koval"
   },

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.69.4",
   "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.69.4",
   "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.69.4",
   "author": {
     "name": "Oleg Koval"
   },

package/scripts/lib/catalog.mjs

@@ -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.',