@olegkoval/agent-skills 1.17.0 → 1.18.0

package/packages/software-development/git-commit/adapters/grok/plugin.json

@@ -0,0 +1,6 @@
+{
+  "name": "olko:git-commit",
+  "version": "0.1.0",
+  "description": "Create conventional commits with diff-aware staging and message generation.",
+  "skills": "skills/"
+}

package/packages/software-development/git-commit/adapters/grok/skills/git-commit/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: git-commit
+description: 'Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping'
+license: MIT
+allowed-tools: Bash
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git and a writable repository.
+metadata:
+  targets: [_source-only]
+  author: Oleg Koval
+  tags:
+    - git
+    - commit
+    - conventional-commits
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# Git Commit with Conventional Commits
+
+## Overview
+
+Create standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message.
+
+## Conventional Commit Format
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+## Commit Types
+
+| Type       | Purpose                        |
+| ---------- | ------------------------------ |
+| `feat`     | New feature                    |
+| `fix`      | Bug fix                        |
+| `docs`     | Documentation only             |
+| `style`    | Formatting/style (no logic)    |
+| `refactor` | Code refactor (no feature/fix) |
+| `perf`     | Performance improvement        |
+| `test`     | Add/update tests               |
+| `build`    | Build system/dependencies      |
+| `ci`       | CI/config changes              |
+| `chore`    | Maintenance/misc               |
+| `revert`   | Revert commit                  |
+
+## Breaking Changes
+
+```
+# Exclamation mark after type/scope
+feat!: remove deprecated endpoint
+
+# BREAKING CHANGE footer
+feat: allow config to extend other configs
+
+BREAKING CHANGE: `extends` key behavior changed
+```
+
+## Workflow
+
+### 1. Analyze Diff
+
+```bash
+# If files are staged, use staged diff
+git diff --staged
+
+# If nothing staged, use working tree diff
+git diff
+
+# Also check status
+git status --porcelain
+```
+
+### 2. Stage Files (if needed)
+
+If nothing is staged or you want to group changes differently:
+
+```bash
+# Stage specific files
+git add path/to/file1 path/to/file2
+
+# Stage by pattern
+git add *.test.*
+git add src/components/*
+
+# Interactive staging
+git add -p
+```
+
+**Never commit secrets** (.env, credentials.json, private keys).
+
+### 3. Generate Commit Message
+
+Analyze the diff to determine:
+
+- **Type**: What kind of change is this?
+- **Scope**: What area/module is affected?
+- **Description**: One-line summary of what changed (present tense, imperative mood, <72 chars)
+
+### 4. Execute Commit
+
+```bash
+# Single line
+git commit -m "<type>[scope]: <description>"
+
+# Multi-line with body/footer
+git commit -m "$(cat <<'EOF'
+<type>[scope]: <description>
+
+<optional body>
+
+<optional footer>
+EOF
+)"
+```
+
+## Best Practices
+
+- One logical change per commit
+- Present tense: "add" not "added"
+- Imperative mood: "fix bug" not "fixes bug"
+- Reference issues: `Closes #123`, `Refs #456`
+- Keep description under 72 characters
+
+## Git Safety Protocol
+
+- NEVER update git config
+- NEVER run destructive commands (--force, hard reset) without explicit request
+- NEVER skip hooks (--no-verify) unless user asks
+- NEVER force push to main/master
+- If commit fails due to hooks, fix and create NEW commit (don't amend)

package/packages/software-development/macos-menubar-app/adapters/grok/plugin.json

@@ -0,0 +1,6 @@
+{
+  "name": "olko:macos-menubar-app",
+  "version": "0.1.0",
+  "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.",
+  "skills": "skills/"
+}

package/packages/software-development/macos-menubar-app/adapters/grok/skills/macos-menubar-app/SKILL.md

@@ -0,0 +1,238 @@
+---
+name: macos-menubar-app
+description: Build a production-quality macOS menubar or notch app in SwiftUI — covering MenuBarExtra setup, sandbox entitlements, keyboard shortcuts, sound effects, accessibility permissions, and /critique-driven polish cycles. Use when starting or extending a macOS agent app that lives in the status bar or Mac notch area.
+license: MIT
+allowed-tools: Bash, Read, Write, Edit
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires Xcode 15+, macOS 13+ deployment target, and an Apple Developer account for App Store distribution.
+metadata:
+  targets: [_source-only]
+  author: Oleg Koval
+  tags:
+    - macos
+    - swiftui
+    - menubar
+    - notch
+    - xcode
+    - apple
+    - sandbox
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+> 🤖 *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/packages/software-development/mvp-oneshot/adapters/grok/plugin.json

@@ -0,0 +1,6 @@
+{
+  "name": "olko:mvp-oneshot",
+  "version": "0.1.0",
+  "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.",
+  "skills": "skills/"
+}

package/packages/software-development/mvp-oneshot/adapters/grok/skills/mvp-oneshot/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: mvp-oneshot
+description: Use when a user has a rough product idea and wants to go from idea to a shippable one-week MVP in a single pass. Turns the idea into a scoped, testable MVP build prompt, ruthlessly trims scope, produces an execution plan, then builds and self-reviews the vertical slice. Activates on "build an MVP for", "I have an idea for", "turn this idea into an MVP/plan", "scope this down", or "oneshot this".
+license: MIT
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Building the vertical slice requires a writable repository and a stack compatible with the generated implementation.
+metadata:
+  targets: [_source-only]
+  author: Oleg Koval
+  tags:
+    - mvp
+    - product
+    - scoping
+    - prompt-chain
+    - planning
+    - startup
+    - oneshot
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# 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/packages/software-development/obsidian-pr-sync/adapters/grok/plugin.json

@@ -0,0 +1,6 @@
+{
+  "name": "olko:obsidian-pr-sync",
+  "version": "0.1.0",
+  "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.",
+  "skills": "skills/"
+}