@olegkoval/agent-skills 1.13.0 → 1.14.0

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-agent-skills",
   "description": "Agent-agnostic skill catalog for Codex, Claude, Cursor, and other skill-aware tools.",
-  "version": "1.12.0",
+  "version": "1.13.0",
   "author": {
     "name": "Oleg Koval"
   },
@@ -17,6 +17,7 @@
     "./packages/software-development/promptctl",
     "./packages/music/fill-music-player",
     "./packages/software-development/product-builder",
+    "./packages/software-development/mvp-oneshot",
     "./packages/software-development/starter-rules",
     "./packages/software-development/review-past-performance",
     "./packages/software-development/open-source-publisher",

package/.cursor-plugin/index.json

@@ -41,6 +41,11 @@
       "source": "./packages/software-development/product-builder/adapters/cursor",
       "description": "Build a full-stack web application or SaaS product from a user description using production-oriented defaults."
     },
+    {
+      "name": "olko:mvp-oneshot",
+      "source": "./packages/software-development/mvp-oneshot/adapters/cursor",
+      "description": "Turn a rough product idea into a shippable one-week MVP in one pass via a four-role prompt chain: scope a build prompt, ruthlessly trim it, plan the build, and self-review the vertical slice."
+    },
     {
       "name": "olko:starter-rules",
       "source": "./packages/software-development/starter-rules/adapters/cursor",

package/.kiro/steering/apple-store-submit.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Handle Apple App Store rejection emails end-to-end: parse rejection reasons, plan fixes, implement code changes, navigate App Store Connect, and resubmit."
 ---
 
-
 > 🤖 *Auto-generated by **weekly-pattern-learner** · App Store rejection handling workflow observed in FocusNotch App Store session, Jun 2026 (92 user turns covering rejection → plan → code fixes → metadata → resubmit)*
 
 # Apple App Store Submission & Rejection Handling

package/.kiro/steering/cloudflare-block-countries.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Block specific countries via Cloudflare WAF Custom Rules using the Cloudflare API. Handles creating new rulesets and updating existing ones across single or multiple zones."
 ---
 
-
 # Cloudflare Country Block via WAF Custom Rules
 
 Block traffic from specific countries using Cloudflare WAF Custom Rules and the Cloudflare API.

package/.kiro/steering/docs-index-keeper.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Keep a Markdown docs index in sync through pre-commit, CI, or one-off maintenance flows."
 ---
 
-
 # docs-index-keeper
 
 Use this skill when a repository keeps docs under `docs/` and needs a Markdown index table updated automatically as docs are added or changed.

package/.kiro/steering/fill-music-player.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Fill a portable music player with a curated random selection from a source music library while balancing formats, artists, albums, and capacity."
 ---
 
-
 # fill-music-player
 
 Curates a DJ-balanced selection of tracks from a source music library and copies them to a portable player, respecting device capacity and supported formats.

package/.kiro/steering/gallery.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Create photo galleries with AI-assisted layout curation and sequencing."
 ---
 
-
 # Gallery Workflow
 
 Composed skill that creates photo galleries by orchestrating atomic scripts and sub-agents.

package/.kiro/steering/gh-cli.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Use the GitHub CLI effectively for repositories, PRs, Actions, releases, and more."
 ---
 
-
 # GitHub CLI (gh)
 
 Comprehensive reference for GitHub CLI (gh) - work seamlessly with GitHub from the command line.

package/.kiro/steering/git-commit.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Create conventional commits with diff-aware staging and message generation."
 ---
 
-
 # Git Commit with Conventional Commits
 
 ## Overview

package/.kiro/steering/macos-menubar-app.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Build a production-quality macOS menubar or notch app in SwiftUI — MenuBarExtra, sandbox entitlements, keyboard shortcuts, sound effects, accessibility permissions, and App Store preparation."
 ---
 
-
 > 🤖 *Auto-generated by **weekly-pattern-learner** · SwiftUI macOS menubar app pattern observed in FocusNotch session, Jun 2026 (364 user turns, ~48 MB transcript covering idea → spec → impl → critique cycles → App Store)*
 
 # macOS Menubar / Notch App (SwiftUI)

package/.kiro/steering/mvp-oneshot.md

@@ -0,0 +1,164 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+inclusion: manual
+description: "Turn a rough product idea into a shippable one-week MVP in one pass via a four-role prompt chain: scope a build prompt, ruthlessly trim it, plan the build, and self-review the vertical slice."
+---
+
+# MVP Oneshot
+
+You are a senior startup engineer running a four-role prompt chain in a single pass.
+Goal: take a rough idea and **oneshot a shippable one-week MVP** — a scoped build
+prompt, a trimmed scope, an execution plan, and the working vertical slice.
+
+## Governing mindset (applies to every phase)
+
+- Ship the smallest useful version. Optimize for **learning and speed**, not elegance.
+- Cut scope hard. If a feature is not needed to prove value, it is not in the MVP.
+- Prefer boring, reliable, already-installed choices over clever new ones.
+- Call out bad assumptions out loud. Concrete implementation over theory.
+- If the plan does not fit a one-week solo build, reduce it until it does.
+
+## Inputs
+
+Collect (or infer) these: idea, target user, business goal, constraints, tech stack,
+deadline, known risks. **Ask at most 5 clarifying questions, and only when a missing
+detail would change the build.** Otherwise infer sensible defaults and state every
+assumption explicitly. Do not stall — a stated assumption beats a blocking question.
+
+## The chain — run all four phases in order, in one pass
+
+Run the phases back-to-back without waiting between them. Show each phase's output,
+then continue. Phases 1->2 happen before any code; phase 4 runs before and after
+the build.
+
+### Phase 1 — Prompt Architect
+
+Turn the idea into one crisp, opinionated **MVP Build Prompt**. Specific, scoped,
+testable, no fluff. Emit it with these sections:
+
+- Title
+- One-sentence problem statement
+- Target user
+- MVP goal
+- Non-goals
+- Core user journeys
+- Required features
+- Excluded (nice-to-haves explicitly cut from the MVP)
+- Suggested stack
+- Data model sketch
+- API sketch
+- Acceptance criteria
+- Risks and open questions
+
+### Phase 2 — Scope Cop
+
+Review the Phase 1 prompt and be ruthless. Favor speed over completeness. Output:
+
+- **Cut** — scope creep, vague requirements, anything not needed to prove value
+- **Keep** — the irreducible core
+- **Defer** — real but post-MVP
+- **Missing clarifications** — assumptions to make explicit
+- **Revised MVP Build Prompt** — implementation-ready, one-week-sized
+
+The revised prompt from this phase is the **source of truth** for the build.
+
+### Phase 3 — Builder
+
+Treat the revised prompt as source of truth. Build a working vertical slice — only
+what a user needs to complete the core journey. No features outside the MVP, no
+TODO stubs.
+For anything ambiguous, make the smallest reasonable assumption and list it. Output:
+
+1. Short execution plan
+2. Exact file/module changes
+3. Implementation order (small tasks, each with acceptance criteria)
+4. Test strategy (cover the core journey end to end)
+5. Verification checklist
+6. Risks and blockers
+
+Then implement the slice, smallest diffs that work.
+
+### Phase 4 — Reviewer
+
+Sanity-check before coding and again after the slice exists. Confirm: scope still
+fits one week, acceptance criteria are testable, the core journey works end to
+end, no smuggled-in scope creep, assumptions are documented. Flag anything that
+breaks these and fix it.
+
+## Reusable prompt templates
+
+The four phases above can also be run as standalone prompts in separate sessions.
+Paste the relevant block, fill the bracketed input.
+
+### Phase 1 template — Prompt Architect
+
+```prompt
+You are Prompt Architect. Turn a rough product idea into a crisp MVP Build Prompt
+another agent can execute.
+
+Input: idea, target user, business goal, constraints, tech stack, deadline,
+known risks.
+
+1. Ask up to 5 clarifying questions only if critical details are missing.
+2. Otherwise infer reasonable defaults and state assumptions explicitly.
+3. Produce one MVP Build Prompt that is scoped, testable, opinionated, and fluff-free.
+
+Output sections: Title; One-sentence problem statement; Target user; MVP goal;
+Core user journeys; Required features; Excluded; Suggested stack; Data model sketch;
+API sketch; Acceptance criteria; Risks and open questions.
+
+Rules: ship in 1 week not 1 month; cut anything not needed for first real user value;
+optimize for learning not elegance; be strict about scope; no generic advice.
+
+Idea: [PASTE IDEA HERE]
+```
+
+### Phase 2 template — Scope Cop
+
+```prompt
+You are Scope Cop. Remove anything that does not belong in a first version.
+
+Find scope creep, vague requirements, missing assumptions, features to cut, and
+dependencies that slow shipping. Make it something a solo founder can ship fast.
+
+Output: What to cut; What to keep; What to defer; Missing clarifications;
+Revised MVP Build Prompt (implementation-ready).
+
+Rules: be ruthless; favor speed over completeness; if a feature is not needed to
+prove value, cut it; keep the revised prompt implementation-ready.
+
+Prompt to review: [PASTE MVP BUILD PROMPT HERE]
+```
+
+### Phase 3 template — Builder
+
+```prompt
+You are Builder. Implement the MVP from the prompt below as source of truth.
+
+Ship a working vertical slice. For ambiguity, make the smallest reasonable
+assumption and list it. No features outside the MVP. Prefer boring, reliable choices.
+
+Output: short execution plan; exact file/module changes; implementation order;
+test strategy; verification checklist; risks and blockers. Each task gets acceptance
+criteria. Build only what is required to complete the core journey.
+
+Prompt to implement: [PASTE REVISED MVP BUILD PROMPT HERE]
+```
+
+### Phase 4 template — Reviewer
+
+```prompt
+You are Reviewer. Sanity-check the plan/slice before shipping.
+
+Confirm: scope fits one week; acceptance criteria are testable; the core journey
+works end to end; no scope creep crept back in; assumptions are documented. Flag
+and fix anything that breaks these.
+
+Plan/slice to review: [PASTE PLAN OR DIFF HERE]
+```
+
+## When stuck or uncertain
+
+Do not stall the chain. Make the smallest reasonable assumption, state it, and keep
+moving. The shortest path to a shippable slice is the right path.

package/.kiro/steering/obsidian-pr-sync.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Fetch open GitHub PRs assigned to you or requesting your review, and write a grouped, age-sorted '## PRs to review' section into today's Obsidian daily note. Idempotent — re-running replaces the section."
 ---
 
-
 # Obsidian PR Sync
 
 Fetch all open PRs where the user is assigned or requested as reviewer, filter out

package/.kiro/steering/obsidian-task-rollover.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Bullet-journal end-of-day task migration: copy unchecked tasks from today's Obsidian daily note to the next workday's note under '## Carried over', and mark them [>] in the source. Skips weekends, idempotent."
 ---
 
-
 # Obsidian Task Rollover
 
 Bullet-journal–style end-of-day task migration. Unfinished tasks (`- [ ]`) from

package/.kiro/steering/open-source-publisher.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Prepare an open-source repository for public publishing with a minimal icon, social preview image, GitHub Pages site, README standardization, CI/CD checks, release hygiene, and optional donation setup."
 ---
 
-
 # open-source-publisher
 
 Use this skill to audit whether an OSS repository is ready to publish, then help only with missing or weak pieces: recognizable icon, shareable social image, GitHub Pages site, standardized README, CI/CD hygiene, release readiness, and optional donation links.

package/.kiro/steering/product-builder.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Build a full-stack web application or SaaS product from a user description using production-oriented defaults."
 ---
 
-
 # Product Builder
 
 You are a full-stack product builder. Your goal: **build real, working products — not prototypes**.

package/.kiro/steering/promptctl.md

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

package/.kiro/steering/review-past-performance.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Self-improvement loop that pulls the last 24h of ICM memories, git history, and skill analytics to detect repeated mistakes, slow workflows, and missing coverage, then proposes 1-3 concrete improvements."
 ---
 
-
 # /review-past-performance
 
 Self-improvement loop. Analyze recent sessions, find durable patterns, propose fixes.

package/.kiro/steering/search-console-indexing-audit.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Analyze Google Search Console Coverage CSV exports and correlate them with sitemap, robots, canonical, redirect, and noindex signals."
 ---
 
-
 # search-console-indexing-audit
 
 Use this skill to turn Google Search Console Coverage exports into a concrete indexing fix plan.

package/.kiro/steering/semantic-release-beta.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Set up semantic-release-npm-github-publish with stable main releases and prerelease beta releases on a beta branch."
 ---
 
-
 # semantic-release-beta
 
 Use this skill when a project needs a reusable beta prerelease workflow with:

package/.kiro/steering/starter-rules.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Load and enforce hard rules for every oleg-koval/* starter: 300-line files, E2E tests, pre-commit hooks, Vertical Slice architecture, no comments, KISS/DRY/SOLID."
 ---
 
-
 # Starter Rules
 
 ## Overview

package/.kiro/steering/viral-launch.md

@@ -5,7 +5,6 @@ inclusion: manual
 description: "Set up a project repository and launch plan for shareable marketing, public launch readiness, and growth loops."
 ---
 
-
 # viral-launch
 
 Use this skill when a user wants to launch a project, make a repo marketable, improve discoverability, or build shareable launch assets.

package/.windsurf/rules/apple-store-submit.md

@@ -4,7 +4,6 @@
 description: "Handle Apple App Store rejection emails end-to-end: parse rejection reasons, plan fixes, implement code changes, navigate App Store Connect, and resubmit."
 ---
 
-
 > 🤖 *Auto-generated by **weekly-pattern-learner** · App Store rejection handling workflow observed in FocusNotch App Store session, Jun 2026 (92 user turns covering rejection → plan → code fixes → metadata → resubmit)*
 
 # Apple App Store Submission & Rejection Handling

package/.windsurf/rules/cloudflare-block-countries.md

@@ -4,7 +4,6 @@
 description: "Block specific countries via Cloudflare WAF Custom Rules using the Cloudflare API. Handles creating new rulesets and updating existing ones across single or multiple zones."
 ---
 
-
 # Cloudflare Country Block via WAF Custom Rules
 
 Block traffic from specific countries using Cloudflare WAF Custom Rules and the Cloudflare API.

package/.windsurf/rules/docs-index-keeper.md

@@ -4,7 +4,6 @@
 description: "Keep a Markdown docs index in sync through pre-commit, CI, or one-off maintenance flows."
 ---
 
-
 # docs-index-keeper
 
 Use this skill when a repository keeps docs under `docs/` and needs a Markdown index table updated automatically as docs are added or changed.

package/.windsurf/rules/fill-music-player.md

@@ -4,7 +4,6 @@
 description: "Fill a portable music player with a curated random selection from a source music library while balancing formats, artists, albums, and capacity."
 ---
 
-
 # fill-music-player
 
 Curates a DJ-balanced selection of tracks from a source music library and copies them to a portable player, respecting device capacity and supported formats.

package/.windsurf/rules/gallery.md

@@ -4,7 +4,6 @@
 description: "Create photo galleries with AI-assisted layout curation and sequencing."
 ---
 
-
 # Gallery Workflow
 
 Composed skill that creates photo galleries by orchestrating atomic scripts and sub-agents.

package/.windsurf/rules/gh-cli.md

@@ -4,7 +4,6 @@
 description: "Use the GitHub CLI effectively for repositories, PRs, Actions, releases, and more."
 ---
 
-
 # GitHub CLI (gh)
 
 Comprehensive reference for GitHub CLI (gh) - work seamlessly with GitHub from the command line.

package/.windsurf/rules/git-commit.md

@@ -4,7 +4,6 @@
 description: "Create conventional commits with diff-aware staging and message generation."
 ---
 
-
 # Git Commit with Conventional Commits
 
 ## Overview

package/.windsurf/rules/macos-menubar-app.md

@@ -4,7 +4,6 @@
 description: "Build a production-quality macOS menubar or notch app in SwiftUI — MenuBarExtra, sandbox entitlements, keyboard shortcuts, sound effects, accessibility permissions, and App Store preparation."
 ---
 
-
 > 🤖 *Auto-generated by **weekly-pattern-learner** · SwiftUI macOS menubar app pattern observed in FocusNotch session, Jun 2026 (364 user turns, ~48 MB transcript covering idea → spec → impl → critique cycles → App Store)*
 
 # macOS Menubar / Notch App (SwiftUI)

package/.windsurf/rules/mvp-oneshot.md

@@ -0,0 +1,163 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Turn a rough product idea into a shippable one-week MVP in one pass via a four-role prompt chain: scope a build prompt, ruthlessly trim it, plan the build, and self-review the vertical slice."
+---
+
+# MVP Oneshot
+
+You are a senior startup engineer running a four-role prompt chain in a single pass.
+Goal: take a rough idea and **oneshot a shippable one-week MVP** — a scoped build
+prompt, a trimmed scope, an execution plan, and the working vertical slice.
+
+## Governing mindset (applies to every phase)
+
+- Ship the smallest useful version. Optimize for **learning and speed**, not elegance.
+- Cut scope hard. If a feature is not needed to prove value, it is not in the MVP.
+- Prefer boring, reliable, already-installed choices over clever new ones.
+- Call out bad assumptions out loud. Concrete implementation over theory.
+- If the plan does not fit a one-week solo build, reduce it until it does.
+
+## Inputs
+
+Collect (or infer) these: idea, target user, business goal, constraints, tech stack,
+deadline, known risks. **Ask at most 5 clarifying questions, and only when a missing
+detail would change the build.** Otherwise infer sensible defaults and state every
+assumption explicitly. Do not stall — a stated assumption beats a blocking question.
+
+## The chain — run all four phases in order, in one pass
+
+Run the phases back-to-back without waiting between them. Show each phase's output,
+then continue. Phases 1->2 happen before any code; phase 4 runs before and after
+the build.
+
+### Phase 1 — Prompt Architect
+
+Turn the idea into one crisp, opinionated **MVP Build Prompt**. Specific, scoped,
+testable, no fluff. Emit it with these sections:
+
+- Title
+- One-sentence problem statement
+- Target user
+- MVP goal
+- Non-goals
+- Core user journeys
+- Required features
+- Excluded (nice-to-haves explicitly cut from the MVP)
+- Suggested stack
+- Data model sketch
+- API sketch
+- Acceptance criteria
+- Risks and open questions
+
+### Phase 2 — Scope Cop
+
+Review the Phase 1 prompt and be ruthless. Favor speed over completeness. Output:
+
+- **Cut** — scope creep, vague requirements, anything not needed to prove value
+- **Keep** — the irreducible core
+- **Defer** — real but post-MVP
+- **Missing clarifications** — assumptions to make explicit
+- **Revised MVP Build Prompt** — implementation-ready, one-week-sized
+
+The revised prompt from this phase is the **source of truth** for the build.
+
+### Phase 3 — Builder
+
+Treat the revised prompt as source of truth. Build a working vertical slice — only
+what a user needs to complete the core journey. No features outside the MVP, no
+TODO stubs.
+For anything ambiguous, make the smallest reasonable assumption and list it. Output:
+
+1. Short execution plan
+2. Exact file/module changes
+3. Implementation order (small tasks, each with acceptance criteria)
+4. Test strategy (cover the core journey end to end)
+5. Verification checklist
+6. Risks and blockers
+
+Then implement the slice, smallest diffs that work.
+
+### Phase 4 — Reviewer
+
+Sanity-check before coding and again after the slice exists. Confirm: scope still
+fits one week, acceptance criteria are testable, the core journey works end to
+end, no smuggled-in scope creep, assumptions are documented. Flag anything that
+breaks these and fix it.
+
+## Reusable prompt templates
+
+The four phases above can also be run as standalone prompts in separate sessions.
+Paste the relevant block, fill the bracketed input.
+
+### Phase 1 template — Prompt Architect
+
+```prompt
+You are Prompt Architect. Turn a rough product idea into a crisp MVP Build Prompt
+another agent can execute.
+
+Input: idea, target user, business goal, constraints, tech stack, deadline,
+known risks.
+
+1. Ask up to 5 clarifying questions only if critical details are missing.
+2. Otherwise infer reasonable defaults and state assumptions explicitly.
+3. Produce one MVP Build Prompt that is scoped, testable, opinionated, and fluff-free.
+
+Output sections: Title; One-sentence problem statement; Target user; MVP goal;
+Core user journeys; Required features; Excluded; Suggested stack; Data model sketch;
+API sketch; Acceptance criteria; Risks and open questions.
+
+Rules: ship in 1 week not 1 month; cut anything not needed for first real user value;
+optimize for learning not elegance; be strict about scope; no generic advice.
+
+Idea: [PASTE IDEA HERE]
+```
+
+### Phase 2 template — Scope Cop
+
+```prompt
+You are Scope Cop. Remove anything that does not belong in a first version.
+
+Find scope creep, vague requirements, missing assumptions, features to cut, and
+dependencies that slow shipping. Make it something a solo founder can ship fast.
+
+Output: What to cut; What to keep; What to defer; Missing clarifications;
+Revised MVP Build Prompt (implementation-ready).
+
+Rules: be ruthless; favor speed over completeness; if a feature is not needed to
+prove value, cut it; keep the revised prompt implementation-ready.
+
+Prompt to review: [PASTE MVP BUILD PROMPT HERE]
+```
+
+### Phase 3 template — Builder
+
+```prompt
+You are Builder. Implement the MVP from the prompt below as source of truth.
+
+Ship a working vertical slice. For ambiguity, make the smallest reasonable
+assumption and list it. No features outside the MVP. Prefer boring, reliable choices.
+
+Output: short execution plan; exact file/module changes; implementation order;
+test strategy; verification checklist; risks and blockers. Each task gets acceptance
+criteria. Build only what is required to complete the core journey.
+
+Prompt to implement: [PASTE REVISED MVP BUILD PROMPT HERE]
+```
+
+### Phase 4 template — Reviewer
+
+```prompt
+You are Reviewer. Sanity-check the plan/slice before shipping.
+
+Confirm: scope fits one week; acceptance criteria are testable; the core journey
+works end to end; no scope creep crept back in; assumptions are documented. Flag
+and fix anything that breaks these.
+
+Plan/slice to review: [PASTE PLAN OR DIFF HERE]
+```
+
+## When stuck or uncertain
+
+Do not stall the chain. Make the smallest reasonable assumption, state it, and keep
+moving. The shortest path to a shippable slice is the right path.

package/.windsurf/rules/obsidian-pr-sync.md

@@ -4,7 +4,6 @@
 description: "Fetch open GitHub PRs assigned to you or requesting your review, and write a grouped, age-sorted '## PRs to review' section into today's Obsidian daily note. Idempotent — re-running replaces the section."
 ---
 
-
 # Obsidian PR Sync
 
 Fetch all open PRs where the user is assigned or requested as reviewer, filter out

package/.windsurf/rules/obsidian-task-rollover.md

@@ -4,7 +4,6 @@
 description: "Bullet-journal end-of-day task migration: copy unchecked tasks from today's Obsidian daily note to the next workday's note under '## Carried over', and mark them [>] in the source. Skips weekends, idempotent."
 ---
 
-
 # Obsidian Task Rollover
 
 Bullet-journal–style end-of-day task migration. Unfinished tasks (`- [ ]`) from

package/.windsurf/rules/open-source-publisher.md

@@ -4,7 +4,6 @@
 description: "Prepare an open-source repository for public publishing with a minimal icon, social preview image, GitHub Pages site, README standardization, CI/CD checks, release hygiene, and optional donation setup."
 ---
 
-
 # open-source-publisher
 
 Use this skill to audit whether an OSS repository is ready to publish, then help only with missing or weak pieces: recognizable icon, shareable social image, GitHub Pages site, standardized README, CI/CD hygiene, release readiness, and optional donation links.

package/.windsurf/rules/product-builder.md

@@ -4,7 +4,6 @@
 description: "Build a full-stack web application or SaaS product from a user description using production-oriented defaults."
 ---
 
-
 # Product Builder
 
 You are a full-stack product builder. Your goal: **build real, working products — not prototypes**.

package/.windsurf/rules/promptctl.md

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

package/.windsurf/rules/review-past-performance.md

@@ -4,7 +4,6 @@
 description: "Self-improvement loop that pulls the last 24h of ICM memories, git history, and skill analytics to detect repeated mistakes, slow workflows, and missing coverage, then proposes 1-3 concrete improvements."
 ---
 
-
 # /review-past-performance
 
 Self-improvement loop. Analyze recent sessions, find durable patterns, propose fixes.

package/.windsurf/rules/search-console-indexing-audit.md

@@ -4,7 +4,6 @@
 description: "Analyze Google Search Console Coverage CSV exports and correlate them with sitemap, robots, canonical, redirect, and noindex signals."
 ---
 
-
 # search-console-indexing-audit
 
 Use this skill to turn Google Search Console Coverage exports into a concrete indexing fix plan.