@olegkoval/agent-skills 1.12.0 → 1.14.0

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

@@ -0,0 +1,144 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+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
+
+## Overview
+
+Parse Apple rejection feedback, implement targeted fixes, update App Store Connect metadata, and resubmit — covering the complete cycle from rejection email to approved build.
+
+## When to Use
+
+- Apple review team sends a rejection email
+- App fails automated pre-review checks (binary rejected at upload)
+- Preparing metadata for first-time submission (screenshots, keywords, privacy labels)
+- Resolving App Store Connect errors before submitting for review
+
+## Workflow
+
+### 1. Parse the Rejection
+
+Read the full rejection email. Extract and list:
+
+- **Guideline numbers** violated (e.g., 2.1, 4.2.0, 5.1.1)
+- **Code-level issues** — missing entitlements, incorrect privacy strings, sandbox violations
+- **Metadata issues** — wrong screenshot sizes, subtitle policy, keyword stuffing
+- **UX issues** — crashes described by reviewer, broken flows, missing functionality
+
+Create a numbered fix plan: one item per rejection point, with the type of fix needed.
+
+### 2. Classify Fixes by Type
+
+| Type | Location |
+|------|----------|
+| Privacy usage strings missing | `Info.plist` |
+| Entitlement missing/wrong | `<AppName>.entitlements` |
+| Crash or broken feature | Source code |
+| Screenshots wrong size/content | App Store Connect |
+| Keywords/subtitle/description | App Store Connect |
+| Build number conflict | Xcode + App Store Connect |
+
+### 3. Implement Code Fixes
+
+**Privacy permission strings** (`Info.plist`):
+
+```xml
+<key>NSMicrophoneUsageDescription</key>
+<string>Used for voice input during focus sessions.</string>
+
+<key>NSCalendarsUsageDescription</key>
+<string>Used to sync tasks with your calendar.</string>
+```
+
+**Entitlements** (`<AppName>.entitlements`):
+
+```xml
+<key>com.apple.security.app-sandbox</key>
+<true/>
+<key>com.apple.security.network.client</key>
+<true/>
+<key>com.apple.security.files.user-selected.read-write</key>
+<true/>
+```
+
+**Sandbox violations** — remove `NoEscapeBlock` patterns, replace deprecated APIs, use only sandboxed file access via Security-Scoped Bookmarks when needed.
+
+### 4. Build and Archive
+
+```bash
+# Clean build
+xcodebuild clean \
+  -scheme <AppName> \
+  -destination 'generic/platform=macOS'
+
+# Archive
+xcodebuild archive \
+  -scheme <AppName> \
+  -archivePath build/<AppName>.xcarchive \
+  -destination 'generic/platform=macOS'
+
+# Export for App Store
+xcodebuild -exportArchive \
+  -archivePath build/<AppName>.xcarchive \
+  -exportPath build/export \
+  -exportOptionsPlist ExportOptions.plist
+```
+
+Validate codesigning before upload:
+
+```bash
+codesign --verify --deep --strict --verbose=4 build/export/<AppName>.app
+spctl --assess --verbose=4 build/export/<AppName>.app
+```
+
+### 5. Update App Store Connect Metadata
+
+Navigate: **My Apps → [App] → App Store tab**
+
+Common metadata fixes:
+
+- **App name**: max 30 chars
+- **Subtitle**: max 30 chars, no duplicate keywords from the title field
+- **Keywords**: 100-char total limit, comma-separated, no spaces after commas
+- **Screenshots**: exact pixel dimensions per device type (check Apple's current spec)
+- **Privacy Nutrition Labels**: must accurately reflect data collected/linked to user
+- **Build selection**: select the newly uploaded build before submitting
+
+### 6. Write Reviewer Notes
+
+In the submission form, fill **Notes for Reviewer**:
+
+- Explain each rejection point and what was changed
+- Reference specific guideline numbers: "Addressing 2.1 — added NSMicrophoneUsageDescription to Info.plist"
+- If a feature requires special credentials to test, provide test account details
+
+### 7. Submit and Track
+
+1. Upload via **Xcode Organizer → Distribute App → App Store Connect**
+2. In App Store Connect: select the new build, fill notes, **Submit for Review**
+3. Typical re-review: 24–48h
+4. If rejected again: respond in the **Resolution Center** thread (same case number)
+5. Escalate via Resolution Center for policy disagreements — do not open a new submission
+
+## Build Number Protocol
+
+Apple rejects builds with a duplicate build number. Increment `CFBundleVersion` in `Info.plist` or Xcode target settings before every upload:
+
+```bash
+# Bump build number (e.g., 9 → 10)
+xcrun agvtool new-version -all 10
+```
+
+## Verification
+
+- [ ] Every rejection guideline number has a corresponding fix in the plan
+- [ ] `xcodebuild archive` exits 0 with no warnings about entitlements
+- [ ] `codesign --verify` passes
+- [ ] App Store Connect shows build status as "Ready to Submit"
+- [ ] Reviewer Notes reference each changed item
+- [ ] Build number is higher than any previously uploaded build

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

@@ -0,0 +1,224 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+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)
+
+## Overview
+
+Build a macOS app that lives in the menu bar or notch using SwiftUI's `MenuBarExtra`. Covers the full lifecycle: project setup, window management, entitlements, user interaction (keyboard shortcuts, sound), and App Store preparation.
+
+## When to Use
+
+- User asks to build an app for the macOS menubar, status bar, or notch
+- Adding a menubar presence to an existing macOS app
+- Debugging sandbox rejections or entitlement errors in a SwiftUI app
+
+## Workflow
+
+### 1. Project Setup
+
+Create a new macOS App target in Xcode:
+
+- **Interface**: SwiftUI
+- **App Sandbox**: Enabled (required for App Store)
+- **Bundle ID**: `com.yourname.AppName`
+- **Deployment target**: macOS 13+ (for `MenuBarExtra`)
+
+In `Info.plist`, set:
+
+```xml
+<key>LSUIElement</key>
+<true/>
+```
+
+This hides the app from the Dock — the menu bar becomes the only entry point.
+
+### 2. MenuBarExtra (SwiftUI native)
+
+```swift
+@main
+struct FocusApp: App {
+    var body: some Scene {
+        MenuBarExtra {
+            ContentView()
+                .frame(width: 320, height: 480)
+        } label: {
+            Label("Focus", systemImage: "timer")
+        }
+        .menuBarExtraStyle(.window)
+    }
+}
+```
+
+Use `.menuBarExtraStyle(.window)` for a popover-style panel. Use `.menuBarExtraStyle(.menu)` for a dropdown menu.
+
+### 3. Notch Detection
+
+On MacBooks with a notch, the safe area changes. Detect and adapt:
+
+```swift
+func isNotchPresent() -> Bool {
+    guard let screen = NSScreen.main else { return false }
+    // The notch area is excluded from visibleFrame top
+    let screenHeight = screen.frame.height
+    let visibleTop = screen.visibleFrame.maxY
+    return visibleTop < screenHeight
+}
+```
+
+Position windows below the notch:
+
+```swift
+window.setFrameOrigin(NSPoint(
+    x: window.frame.origin.x,
+    y: NSScreen.main!.frame.height - window.frame.height - notchOffset
+))
+```
+
+### 4. Sandbox Entitlements
+
+Minimum `.entitlements` for a sandboxed menubar app:
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+    <key>com.apple.security.app-sandbox</key>
+    <true/>
+    <!-- Add only what the app actually uses: -->
+    <!-- <key>com.apple.security.network.client</key> -->
+    <!-- <true/> -->
+</dict>
+</plist>
+```
+
+For focus/blocking features that need accessibility:
+
+```xml
+<key>com.apple.security.temporary-exception.apple-events</key>
+<array>
+    <string>com.apple.systemevents</string>
+</array>
+```
+
+### 5. Accessibility Permission (Focus Detection)
+
+To detect which app is in focus (required for distraction blocking):
+
+```swift
+import ApplicationServices
+
+func requestAccessibilityPermission() -> Bool {
+    let options: NSDictionary = [kAXTrustedCheckOptionPrompt.takeUnretainedValue() as String: true]
+    return AXIsProcessTrustedWithOptions(options)
+}
+```
+
+Call this on first launch and prompt the user to grant access in **System Settings → Privacy → Accessibility**.
+
+### 6. Sound Effects
+
+```swift
+import AVFoundation
+
+class SoundPlayer {
+    private var player: AVAudioPlayer?
+
+    func play(_ filename: String, extension ext: String = "mp3") {
+        guard let url = Bundle.main.url(forResource: filename, withExtension: ext) else { return }
+        player = try? AVAudioPlayer(contentsOf: url)
+        player?.play()
+    }
+}
+```
+
+Add sound files to the Xcode target (check **Target Membership** in file inspector).
+
+For system sounds (no file needed):
+
+```swift
+NSSound.beep()
+// or
+NSSound(named: .init("Hero"))?.play()
+```
+
+### 7. Keyboard Shortcuts
+
+Global shortcuts (work when app is not focused) — requires Accessibility permission:
+
+```swift
+NSEvent.addGlobalMonitorForEvents(matching: .keyDown) { event in
+    if event.modifierFlags.contains([.command, .shift]) && event.keyCode == 36 { // ⌘⇧↩
+        // Handle shortcut
+    }
+}
+```
+
+Local shortcuts (SwiftUI):
+
+```swift
+.keyboardShortcut("s", modifiers: [.command, .shift])
+```
+
+### 8. Persistent State (AppStorage)
+
+```swift
+@AppStorage("timerDuration") private var timerDuration: Double = 25 * 60
+@AppStorage("soundEnabled") private var soundEnabled: Bool = true
+```
+
+For complex state, use `UserDefaults` with a suite name to share across extensions.
+
+### 9. Polish Cycle
+
+After each implementation slice:
+
+> **Optional skills**: Steps 1 and 3 require `/critique` and `/whimsy-injector` from the agent-skills catalog. Install them via `skillshare` if not already available; skip these steps if not installed.
+
+1. Run `/critique` — evaluate against Apple HIG, WCAG contrast, interaction consistency
+2. Fix all P0/P1 findings
+3. Run `/whimsy-injector` on completion screens and idle states
+4. Test on a machine **without** a notch to verify layout
+
+### 10. App Store Preparation
+
+See `olko:apple-store-submit` for the full submission and rejection-handling workflow.
+
+Pre-submission checklist:
+
+```bash
+# Validate archive
+xcodebuild archive -scheme <AppName> -archivePath build/<AppName>.xcarchive
+
+# Check sandbox
+codesign --verify --deep --strict build/<AppName>.xcarchive/Products/Applications/<AppName>.app
+
+# Verify entitlements
+codesign -d --entitlements :- build/<AppName>.xcarchive/Products/Applications/<AppName>.app
+```
+
+## Key Pitfalls
+
+| Symptom | Cause | Fix |
+|---------|-------|-----|
+| App appears in Dock | `LSUIElement` missing | Add to `Info.plist` |
+| Menubar icon missing after build | Asset catalog misconfigured | Use PDF or SVG template image, tick **Template Image** |
+| Crash on click | View not loaded in popover window | Add `.frame()` to `MenuBarExtra` content |
+| Sound not playing | File not in target | Check Target Membership in file inspector |
+| Accessibility prompt not shown | Missing entitlement | Add `temporary-exception.apple-events` or use XPC |
+| Notch overlap | Hardcoded y-position | Detect `visibleFrame` vs `frame` delta |
+
+## Verification
+
+- [ ] App does not appear in Dock (`LSUIElement` = true)
+- [ ] MenuBarExtra icon renders as template image (respects dark/light mode)
+- [ ] Sound plays on timer events
+- [ ] Keyboard shortcuts respond both globally and locally
+- [ ] App passes `codesign --verify --deep --strict`
+- [ ] Layout correct on M1 MacBook (no notch) and M3 MacBook Pro (notch)

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.