1Password CLI

Follow the official CLI get-started steps. Don't guess install commands.

References

• references/get-started.md (install + app integration + sign-in flow)
• references/cli-examples.md (real op examples)

Workflow

1. Check OS + shell.
2. Verify CLI present: op --version.
3. Confirm desktop app integration is enabled (per get-started) and the app is unlocked.
4. REQUIRED: create a fresh tmux session for all op commands (no direct op calls outside tmux).
5. Sign in / authorize inside tmux: op signin (expect app prompt).
6. Verify access inside tmux: op whoami (must succeed before any secret read).
7. If multiple accounts: use --account or OP_ACCOUNT.

REQUIRED tmux session (tmux)

The shell tool uses a fresh TTY per command. To avoid re-prompts and failures, always run op inside a dedicated tmux session with a fresh socket/session name.

Example (see tmux skill for socket conventions, do not reuse old session names):

SOCKET_DIR="${PILOTDECK_TMUX_SOCKET_DIR:-${TMPDIR:-/tmp}/pilotdeck-tmux-sockets}"
mkdir -p "$SOCKET_DIR"
SOCKET="$SOCKET_DIR/pilotdeck-op.sock"
SESSION="op-auth-$(date +%Y%m%d-%H%M%S)"

tmux -S "$SOCKET" new -d -s "$SESSION" -n shell
tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op signin --account my.1password.com" Enter
tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op whoami" Enter
tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op vault list" Enter
tmux -S "$SOCKET" capture-pane -p -J -t "$SESSION":0.0 -S -200
tmux -S "$SOCKET" kill-session -t "$SESSION"

Guardrails

• Never paste secrets into logs, chat, or code.
• Prefer op run / op inject over writing secrets to disk.
• If sign-in without app integration is needed, use op account add.
• If a command returns "account is not signed in", re-run op signin inside tmux and authorize in the app.
• Do not run op outside tmux; stop and ask if tmux is unavailable.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/1password
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Apple Notes CLI

Use memo notes to manage Apple Notes directly from the terminal. Create, view, edit, delete, search, move notes between folders, and export to HTML/Markdown.

Setup

• Install (Homebrew): brew tap antoniorodr/memo && brew install antoniorodr/memo/memo
• Manual (pip): pip install . (after cloning the repo)
• macOS-only; if prompted, grant Automation access to Notes.app.

View Notes

• List all notes: memo notes
• Filter by folder: memo notes -f "Folder Name"
• Search notes (fuzzy): memo notes -s "query"

Create Notes

• Add a new note: memo notes -a
  • Opens an interactive editor to compose the note.
• Quick add with title: memo notes -a "Note Title"

Edit Notes

• Edit existing note: memo notes -e
  • Interactive selection of note to edit.

Delete Notes

• Delete a note: memo notes -d
  • Interactive selection of note to delete.

Move Notes

• Move note to folder: memo notes -m
  • Interactive selection of note and destination folder.

Export Notes

• Export to HTML/Markdown: memo notes -ex
  • Exports selected note; uses Mistune for markdown processing.

Limitations

• Cannot edit notes containing images or attachments.
• Interactive prompts may require terminal access.

Notes

• macOS-only.
• Requires Apple Notes.app to be accessible.
• For automation, grant permissions in System Settings > Privacy & Security > Automation.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/apple-notes
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Apple Reminders CLI (remindctl)

Use remindctl to manage Apple Reminders directly from the terminal.

When to Use

Use when:

• User explicitly mentions "reminder" or "Reminders app"
• Creating personal to-dos with due dates that sync to iOS
• Managing Apple Reminders lists
• User wants tasks to appear in their iPhone/iPad Reminders app

When NOT to Use

Do not use when:

• Scheduling OpenClaw tasks or alerts -> use cron tool with systemEvent instead
• Calendar events or appointments -> use Apple Calendar
• Project/work task management -> use Notion, GitHub Issues, or task queue
• One-time notifications -> use cron tool for timed alerts
• User says "remind me" but means an OpenClaw alert -> clarify first

Setup

• Install: brew install steipete/tap/remindctl
• macOS-only; grant Reminders permission when prompted
• Check status: remindctl status
• Request access: remindctl authorize

Common Commands

View Reminders

remindctl                    # Today's reminders
remindctl today              # Today
remindctl tomorrow           # Tomorrow
remindctl week               # This week
remindctl overdue            # Past due
remindctl all                # Everything
remindctl 2026-01-04         # Specific date

Manage Lists

remindctl list               # List all lists
remindctl list Work          # Show specific list
remindctl list Projects --create    # Create list
remindctl list Work --delete        # Delete list

Create Reminders

remindctl add "Buy milk"
remindctl add --title "Call mom" --list Personal --due tomorrow
remindctl add --title "Meeting prep" --due "2026-02-15 09:00"

Complete/Delete

remindctl complete 1 2 3     # Complete by ID
remindctl delete 4A83 --force  # Delete by ID

Output Formats

remindctl today --json       # JSON for scripting
remindctl today --plain      # TSV format
remindctl today --quiet      # Counts only

Date Formats

Accepted by --due and date filters:

• today, tomorrow, yesterday
• YYYY-MM-DD
• YYYY-MM-DD HH:mm
• ISO 8601 (2026-01-04T12:34:56Z)

Example: Clarifying User Intent

User: "Remind me to check on the deploy in 2 hours"

Ask: "Do you want this in Apple Reminders (syncs to your phone) or as an OpenClaw alert (I'll message you here)?"

• Apple Reminders -> use this skill
• OpenClaw alert -> use cron tool with systemEvent

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/apple-reminders
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Bear Notes

Use grizzly to create, read, and manage notes in Bear on macOS.

Requirements

• Bear app installed and running
• For some operations (add-text, tags, open-note --selected), a Bear app token (stored in ~/.config/grizzly/token)

Getting a Bear Token

For operations that require a token (add-text, tags, open-note --selected), you need an authentication token:

1. Open Bear -> Help -> API Token -> Copy Token
2. Save it: echo "YOUR_TOKEN" > ~/.config/grizzly/token

Common Commands

Create a note

echo "Note content here" | grizzly create --title "My Note" --tag work
grizzly create --title "Quick Note" --tag inbox < /dev/null

Open/read a note by ID

grizzly open-note --id "NOTE_ID" --enable-callback --json

Append text to a note

echo "Additional content" | grizzly add-text --id "NOTE_ID" --mode append --token-file ~/.config/grizzly/token

List all tags

grizzly tags --enable-callback --json --token-file ~/.config/grizzly/token

Search notes (via open-tag)

grizzly open-tag --name "work" --enable-callback --json

Options

Common flags:

• --dry-run - Preview the URL without executing
• --print-url - Show the x-callback-url
• --enable-callback - Wait for Bear's response (needed for reading data)
• --json - Output as JSON (when using callbacks)
• --token-file PATH - Path to Bear API token file

Configuration

Grizzly reads config from (in priority order):

1. CLI flags
2. Environment variables (GRIZZLY_TOKEN_FILE, GRIZZLY_CALLBACK_URL, GRIZZLY_TIMEOUT)
3. .grizzly.toml in current directory
4. ~/.config/grizzly/config.toml

Example ~/.config/grizzly/config.toml:

token_file = "~/.config/grizzly/token"
callback_url = "http://127.0.0.1:42123/success"
timeout = "5s"

Notes

• Bear must be running for commands to work
• Note IDs are Bear's internal identifiers (visible in note info or via callbacks)
• Use --enable-callback when you need to read data back from Bear
• Some operations require a valid token (add-text, tags, open-note --selected)

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/bear-notes
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

blogwatcher

Track blog and RSS/Atom feed updates with the blogwatcher CLI.

Install

• Go: go install github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest

Quick start

• blogwatcher --help

Common commands

• Add a blog: blogwatcher add "My Blog" https://example.com
• List blogs: blogwatcher blogs
• Scan for updates: blogwatcher scan
• List articles: blogwatcher articles
• Mark an article read: blogwatcher read 1
• Mark all articles read: blogwatcher read-all
• Remove a blog: blogwatcher remove "My Blog"

Example output

$ blogwatcher blogs
Tracked blogs (1):

  xkcd
    URL: https://xkcd.com

$ blogwatcher scan
Scanning 1 blog(s)...

  xkcd
    Source: RSS | Found: 4 | New: 4

Found 4 new article(s) total!

Notes

• Use blogwatcher <command> --help to discover flags and options.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/blogwatcher
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Diagram Maker

Create diagrams as artifacts, not prose. Choose one output mode:

• clean-svg: educational concepts, physical systems, processes, lifecycle, simple data flow.
• architecture-svg: software/cloud/infra topology, services, databases, queues, trust zones.
• excalidraw: editable hand-drawn whiteboard, flowchart, sequence, architecture sketch.

Routing

• User wants editable/collaborative: choose Excalidraw.
• User wants polished standalone browser output: choose SVG/HTML.
• Software architecture with infra components: choose architecture SVG.
• Science, product, process, concept map, physical object: choose clean SVG.
• Unsure: ask one short question only if output format matters; otherwise choose clean SVG.

Workflow

1. Extract nodes, groups, labels, and directed relationships.
2. Pick layout first: left-to-right, top-down, hub-spoke, swimlanes, layered stack, sequence.
3. Keep labels short. Prefer 5-9 main elements over dense diagrams.
4. Generate the file at the requested path, or ./diagram.html / ./diagram.excalidraw.
5. Verify syntax by opening/parsing when feasible.

SVG/HTML rules

• Single standalone .html file with inline CSS and inline SVG.
• No external fonts, JS, images, gradients, glows, decorative blobs, or remote assets.
• Use semantic colors, not rainbow sequences: neutral, input, process, storage, external, risk.
• Draw connectors before nodes so arrows sit behind boxes.
• Every connector path has fill="none" and a marker arrow when directed.
• Leave 24px text padding inside boxes; do not let text touch borders.
• Legend only when symbols/colors are not obvious.

SVG template

Use references/svg-template.md as the wrapper and replace <!-- SVG -->.

Excalidraw rules

• Save .excalidraw JSON with type, version, source, elements, and appState.
• Use bound text for shape labels. Do not use a nonstandard label property.
• Keep bound text immediately after its container in the elements array.
• Minimum labeled shape: 120x60. Minimum body text: 16px.
• Use roughness 1, fontFamily: 1, and simple fills.

For exact Excalidraw element snippets, read references/excalidraw-patterns.md.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/diagram-maker
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Frontend Slides

Create zero-dependency, animation-rich HTML presentations that run entirely in the browser.

Core Principles

1. Zero Dependencies — Single HTML files with inline CSS/JS. No npm, no build tools.
2. Show, Don't Tell — Generate visual previews, not abstract choices. People discover what they want by seeing it.
3. Distinctive Design — No generic "AI slop." Every presentation must feel custom-crafted.
4. Viewport Fitting (NON-NEGOTIABLE) — Every slide MUST fit exactly within 100vh. No scrolling within slides, ever. Content overflows? Split into multiple slides.

Design Aesthetics

You tend to converge toward generic, "on distribution" outputs. In frontend design, this creates what users call the "AI slop" aesthetic. Avoid this: make creative, distinctive frontends that surprise and delight.

Focus on:

• Typography: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics.
• Color & Theme: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes. Draw from IDE themes and cultural aesthetics for inspiration.
• Motion: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions.
• Backgrounds: Create atmosphere and depth rather than defaulting to solid colors. Layer CSS gradients, use geometric patterns, or add contextual effects that match the overall aesthetic.

Avoid generic AI-generated aesthetics:

• Overused font families (Inter, Roboto, Arial, system fonts)
• Cliched color schemes (particularly purple gradients on white backgrounds)
• Predictable layouts and component patterns
• Cookie-cutter design that lacks context-specific character

Interpret creatively and make unexpected choices that feel genuinely designed for the context. Vary between light and dark themes, different fonts, different aesthetics. You still tend to converge on common choices (Space Grotesk, for example) across generations. Avoid this: it is critical that you think outside the box!

Viewport Fitting Rules

These invariants apply to EVERY slide in EVERY presentation:

• Every .slide must have height: 100vh; height: 100dvh; overflow: hidden;
• ALL font sizes and spacing must use clamp(min, preferred, max) — never fixed px/rem
• Content containers need max-height constraints
• Images: max-height: min(50vh, 400px)
• Breakpoints required for heights: 700px, 600px, 500px
• Include prefers-reduced-motion support
• Never negate CSS functions directly (-clamp(), -min(), -max() are silently ignored) — use calc(-1 * clamp(...)) instead

When generating, read viewport-base.css and include its full contents in every presentation.

Content Density Limits Per Slide

Content exceeds limits? Split into multiple slides. Never cram, never scroll.

Phase 0: Detect Mode

Determine what the user wants:

• Mode A: New Presentation — Create from scratch. Go to Phase 1.
• Mode B: PPT Conversion — Convert a .pptx file. Go to Phase 4.
• Mode C: Enhancement — Improve an existing HTML presentation. Read it, understand it, enhance. Follow Mode C modification rules below.

Mode C: Modification Rules

When enhancing existing presentations, viewport fitting is the biggest risk:

1. Before adding content: Count existing elements, check against density limits
2. Adding images: Must have max-height: min(50vh, 400px). If slide already has max content, split into two slides
3. Adding text: Max 4-6 bullets per slide. Exceeds limits? Split into continuation slides
4. After ANY modification, verify: .slide has overflow: hidden, new elements use clamp(), images have viewport-relative max-height, content fits at 1280x720
5. Proactively reorganize: If modifications will cause overflow, automatically split content and inform the user. Don't wait to be asked

When adding images to existing slides: Move image to new slide or reduce other content first. Never add images without checking if existing content already fills the viewport.

Phase 1: Content Discovery (New Presentations)

Ask ALL questions in a single AskUserQuestion call so the user fills everything out at once:

Question 1 — Purpose (header: "Purpose"): What is this presentation for? Options: Pitch deck / Teaching-Tutorial / Conference talk / Internal presentation

Question 2 — Length (header: "Length"): Approximately how many slides? Options: Short 5-10 / Medium 10-20 / Long 20+

Question 3 — Content (header: "Content"): Do you have content ready? Options: All content ready / Rough notes / Topic only

Question 4 — Inline Editing (header: "Editing"): Do you need to edit text directly in the browser after generation? Options:

• "Yes (Recommended)" — Can edit text in-browser, auto-save to localStorage, export file
• "No" — Presentation only, keeps file smaller

Remember the user's editing choice — it determines whether edit-related code is included in Phase 3.

If user has content, ask them to share it.

Step 1.2: Image Evaluation (if images provided)

If user selected "No images" → skip to Phase 2.

If user provides an image folder:

1. Scan — List all image files (.png, .jpg, .svg, .webp, etc.)
2. View each image — Use the Read tool (Claude is multimodal)
3. Evaluate — For each: what it shows, USABLE or NOT USABLE (with reason), what concept it represents, dominant colors
4. Co-design the outline — Curated images inform slide structure alongside text. This is NOT "plan slides then add images" — design around both from the start (e.g., 3 screenshots → 3 feature slides, 1 logo → title/closing slide)
5. Confirm via AskUserQuestion (header: "Outline"): "Does this slide outline and image selection look right?" Options: Looks good / Adjust images / Adjust outline

Logo in previews: If a usable logo was identified, embed it (base64) into each style preview in Phase 2 — the user sees their brand styled three different ways.

Phase 2: Style Discovery

This is the "show, don't tell" phase. Most people can't articulate design preferences in words.

Step 2.0: Style Path

Ask how they want to choose (header: "Style"):

• "Show me options" (recommended) — Generate 3 previews based on mood
• "I know what I want" — Pick from preset list directly

If direct selection: Show preset picker and skip to Phase 3. Available presets are defined in STYLE_PRESETS.md.

Step 2.1: Mood Selection (Guided Discovery)

Ask (header: "Vibe", multiSelect: true, max 2): What feeling should the audience have? Options:

• Impressed/Confident — Professional, trustworthy
• Excited/Energized — Innovative, bold
• Calm/Focused — Clear, thoughtful
• Inspired/Moved — Emotional, memorable

Step 2.2: Generate 3 Style Previews

Based on mood, generate 3 distinct single-slide HTML previews showing typography, colors, animation, and overall aesthetic. Read STYLE_PRESETS.md for available presets and their specifications.

Save previews to .claude-design/slide-previews/ (style-a.html, style-b.html, style-c.html). Each should be self-contained, ~50-100 lines, showing one animated title slide.

Open each preview automatically for the user.

Step 2.3: User Picks

Ask (header: "Style"): Which style preview do you prefer? Options: Style A: [Name] / Style B: [Name] / Style C: [Name] / Mix elements

If "Mix elements", ask for specifics.

Phase 3: Generate Presentation

Generate the full presentation using content from Phase 1 (text, or text + curated images) and style from Phase 2.

If images were provided, the slide outline already incorporates them from Step 1.2. If not, CSS-generated visuals (gradients, shapes, patterns) provide visual interest — this is a fully supported first-class path.

Before generating, read these supporting files:

• html-template.md — HTML architecture and JS features
• viewport-base.css — Mandatory CSS (include in full)
• animation-patterns.md — Animation reference for the chosen feeling

Key requirements:

• Single self-contained HTML file, all CSS/JS inline
• Include the FULL contents of viewport-base.css in the <style> block
• Use fonts from Fontshare or Google Fonts — never system fonts
• Add detailed comments explaining each section
• Every section needs a clear /* === SECTION NAME === */ comment block

Phase 4: PPT Conversion

When converting PowerPoint files:

1. Extract content — Run python scripts/extract-pptx.py <input.pptx> <output_dir> (install python-pptx if needed: pip install python-pptx)
2. Confirm with user — Present extracted slide titles, content summaries, and image counts
3. Style selection — Proceed to Phase 2 for style discovery
4. Generate HTML — Convert to chosen style, preserving all text, images (from assets/), slide order, and speaker notes (as HTML comments)

Phase 5: Delivery

1. Clean up — Delete .claude-design/slide-previews/ if it exists
2. Open — Use open [filename].html to launch in browser
3. Summarize — Tell the user:
   • File location, style name, slide count
   • Navigation: Arrow keys, Space, scroll/swipe, click nav dots
   • How to customize: :root CSS variables for colors, font link for typography, .reveal class for animations
   • If inline editing was enabled: Hover top-left corner or press E to enter edit mode, click any text to edit, Ctrl+S to save

Phase 6: Share & Export (Optional)

After delivery, ask the user: "Would you like to share this presentation? I can deploy it to a live URL (works on any device including phones) or export it as a PDF."

Options:

• Deploy to URL — Shareable link that works on any device
• Export to PDF — Universal file for email, Slack, print
• Both
• No thanks

If the user declines, stop here. If they choose one or both, proceed below.

6A: Deploy to a Live URL (Vercel)

This deploys the presentation to Vercel — a free hosting platform. The link works on any device (phones, tablets, laptops) and stays live until the user takes it down.

If the user has never deployed before, guide them step by step:

1. Check if Vercel CLI is installed — Run npx vercel --version. If not found, install Node.js first (brew install node on macOS, or download from https://nodejs.org).

2. Check if user is logged in — Run npx vercel whoami.

   • If NOT logged in, explain: "Vercel is a free hosting service. You need an account to deploy. Let me walk you through it:"
     • Step 1: Ask user to go to https://vercel.com/signup in their browser
     • Step 2: They can sign up with GitHub, Google, email — whatever is easiest
     • Step 3: Once signed up, run vercel login and follow the prompts (it opens a browser window to authorize)
     • Step 4: Confirm login with vercel whoami
   • Wait for the user to confirm they're logged in before proceeding.

3. Deploy — Run the deploy script:

   bash scripts/deploy.sh <path-to-presentation>
   

   The script accepts either a folder (with index.html) or a single HTML file.

4. Share the URL — Tell the user:

   • The live URL (from the script output)
   • That it works on any device — they can text it, Slack it, email it
   • To take it down later: visit https://vercel.com/dashboard and delete the project
   • The Vercel free tier is generous — they won't be charged

⚠ Deployment gotchas:

• Local images/videos must travel with the HTML. The deploy script auto-detects files referenced via src="..." in the HTML and bundles them. But if the presentation references files via CSS background-image or unusual paths, those may be missed. Before deploying, verify: open the deployed URL and check that all images load. If any are broken, the safest fix is to put the HTML and all its assets into a single folder and deploy the folder instead of a standalone HTML file.
• Prefer folder deployments when the presentation has many assets. If the presentation lives in a folder with images alongside it (e.g., my-deck/index.html + my-deck/logo.png), deploy the folder directly: bash scripts/deploy.sh ./my-deck/. This is more reliable than deploying a single HTML file because the entire folder contents are uploaded as-is.
• Filenames with spaces work but can cause issues. The script handles spaces in filenames, but Vercel URLs encode spaces as %20. If possible, avoid spaces in image filenames. If the user's images have spaces, the script handles it — but if images still break, renaming files to use hyphens instead of spaces is the fix.
• Redeploying updates the same URL. Running the deploy script again on the same presentation overwrites the previous deployment. The URL stays the same — no need to share a new link.

6B: Export to PDF

This captures each slide as a screenshot and combines them into a PDF. Perfect for email attachments, embedding in documents, or printing.

Note: Animations and interactivity are not preserved — the PDF is a static snapshot. This is normal and expected; mention it to the user so they're not surprised.

1. Run the export script:

   bash scripts/export-pdf.sh <path-to-html> [output.pdf]
   

   If no output path is given, the PDF is saved next to the HTML file.

2. What happens behind the scenes (explain briefly to the user):

   • A headless browser opens the presentation at 1920×1080 (standard widescreen)
   • It screenshots each slide one by one
   • All screenshots are combined into a single PDF
   • The script needs Playwright (a browser automation tool) — it will install automatically if missing

3. If Playwright installation fails:

   • The most common issue is Chromium not downloading. Run: npx playwright install chromium
   • If that fails too, it may be a network/firewall issue. Ask the user to try on a different network.

4. Deliver the PDF — The script auto-opens it. Tell the user:

   • The file location and size
   • That it works everywhere — email, Slack, Notion, Google Docs, print
   • Animations are replaced by their final visual state (still looks great, just static)

⚠ PDF export gotchas:

• First run is slow. The script installs Playwright and downloads a Chromium browser (~150MB) into a temp directory. This happens once per run. Warn the user it may take 30-60 seconds the first time — subsequent exports within the same session are faster.
• Slides must use class="slide". The export script finds slides by querying .slide elements. If the presentation uses a different class name, the script will report "0 slides found" and fail. All presentations generated by this skill use .slide, so this only matters for externally-created HTML.
• Local images must be loadable via HTTP. The script starts a local server and loads the HTML through it (so Google Fonts and relative image paths work). If images use absolute filesystem paths (e.g., src="/Users/name/photo.png") instead of relative paths (e.g., src="photo.png"), they won't load. Generated presentations always use relative paths, but converted or user-provided decks might not — check and fix if needed.
• Local images appear in the PDF as long as they are in the same directory as (or relative to) the HTML file. The export script serves the HTML's parent directory over HTTP, so relative paths like src="photo.png" resolve correctly — including filenames with spaces. If images still don't appear, check: (1) the image files actually exist at the referenced path, (2) the paths are relative, not absolute filesystem paths like /Users/name/photo.png.
• Large presentations produce large PDFs. Each slide is captured as a full 1920×1080 PNG screenshot. An 18-slide deck can produce a ~20MB PDF. If the PDF exceeds 10MB, ask the user: "The PDF is [size]. Would you like me to compress it? It'll look slightly less sharp but the file will be much smaller." If yes, re-run the export with the --compact flag:

  bash scripts/export-pdf.sh <path-to-html> [output.pdf] --compact
  

  This renders at 1280×720 instead of 1920×1080, typically cutting file size by 50-70% with minimal visual difference.

Supporting Files

GitHub

Use gh for GitHub. Use git for local commits/branches/push/pull. Use code-reading tools for deep reviews.

Auth

gh auth status
gh auth login

Gateway HOME can differ from operator HOME. If gh auth exists elsewhere, set GH_CONFIG_DIR in the gateway service env and restart.

PRs

gh pr list --repo owner/repo --json number,title,state,author,url
gh pr view 55 --repo owner/repo --json title,body,author,files,commits,reviews,reviewDecision
gh pr checks 55 --repo owner/repo
gh pr diff 55 --repo owner/repo
gh pr create --repo owner/repo --title "feat: title" --body-file /tmp/pr.md
gh pr merge 55 --repo owner/repo --squash

URLs work directly: gh pr view https://github.com/owner/repo/pull/55.

Issues

gh issue list --repo owner/repo --state open --json number,title,labels,url
gh issue view 42 --repo owner/repo --json title,body,comments,labels,state
gh issue create --repo owner/repo --title "Bug: ..." --body-file /tmp/issue.md
gh issue comment 42 --repo owner/repo --body-file /tmp/comment.md
gh issue close 42 --repo owner/repo --comment "Fixed in ..."

CI/runs

gh run list --repo owner/repo --limit 10
gh run view <run-id> --repo owner/repo --json status,conclusion,headSha,url
gh run view <run-id> --repo owner/repo --log-failed
gh run rerun <run-id> --repo owner/repo --failed

API

gh api repos/owner/repo/pulls/55 --jq '.title, .state, .user.login'
gh api repos/owner/repo/labels --jq '.[].name'
gh api --cache 1h repos/owner/repo --jq '{stars: .stargazers_count, forks: .forks_count}'

Use --json + --jq for structured output. Use --body-file for comments/bodies containing backticks, shell snippets, env names, or user text.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/github
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

gog

Use gog for Gmail/Calendar/Drive/Contacts/Sheets/Docs. Requires OAuth setup.

Setup (once)

• gog auth credentials /path/to/client_secret.json
• gog auth add you@gmail.com --services gmail,calendar,drive,contacts,docs,sheets
• gog auth list

Common commands

• Gmail search: gog gmail search 'newer_than:7d' --max 10
• Gmail messages search (per email, ignores threading): gog gmail messages search "in:inbox from:ryanair.com" --max 20 --account you@example.com
• Gmail send (plain): gog gmail send --to a@b.com --subject "Hi" --body "Hello"
• Gmail send (multi-line): gog gmail send --to a@b.com --subject "Hi" --body-file ./message.txt
• Gmail send (stdin): gog gmail send --to a@b.com --subject "Hi" --body-file -
• Gmail send (HTML): gog gmail send --to a@b.com --subject "Hi" --body-html "<p>Hello</p>"
• Gmail draft: gog gmail drafts create --to a@b.com --subject "Hi" --body-file ./message.txt
• Gmail send draft: gog gmail drafts send <draftId>
• Gmail reply: gog gmail send --to a@b.com --subject "Re: Hi" --body "Reply" --reply-to-message-id <msgId>
• Calendar list events: gog calendar events <calendarId> --from <iso> --to <iso>
• Calendar create event: gog calendar create <calendarId> --summary "Title" --from <iso> --to <iso>
• Calendar create with color: gog calendar create <calendarId> --summary "Title" --from <iso> --to <iso> --event-color 7
• Calendar update event: gog calendar update <calendarId> <eventId> --summary "New Title" --event-color 4
• Calendar show colors: gog calendar colors
• Drive search: gog drive search "query" --max 10
• Contacts: gog contacts list --max 20
• Sheets get: gog sheets get <sheetId> "Tab!A1:D10" --json
• Sheets update: gog sheets update <sheetId> "Tab!A1:B2" --values-json '[["A","B"],["1","2"]]' --input USER_ENTERED
• Sheets append: gog sheets append <sheetId> "Tab!A:C" --values-json '[["x","y","z"]]' --insert INSERT_ROWS
• Sheets clear: gog sheets clear <sheetId> "Tab!A2:Z"
• Sheets metadata: gog sheets metadata <sheetId> --json
• Docs export: gog docs export <docId> --format txt --out /tmp/doc.txt
• Docs cat: gog docs cat <docId>

Calendar Colors

• Use gog calendar colors to see all available event colors (IDs 1-11)
• Add colors to events with --event-color <id> flag
• Event color IDs (from gog calendar colors output):
  • 1: #a4bdfc
  • 2: #7ae7bf
  • 3: #dbadff
  • 4: #ff887c
  • 5: #fbd75b
  • 6: #ffb878
  • 7: #46d6db
  • 8: #e1e1e1
  • 9: #5484ed
  • 10: #51b749
  • 11: #dc2127

Email Formatting

• Prefer plain text. Use --body-file for multi-paragraph messages (or --body-file - for stdin).

• Same --body-file pattern works for drafts and replies.

• --body does not unescape \n. If you need inline newlines, use a heredoc or $'Line 1\n\nLine 2'.

• Use --body-html only when you need rich formatting.

• HTML tags: <p> for paragraphs, <br> for line breaks, <strong> for bold, <em> for italic, <a href="url"> for links, <ul>/<li> for lists.

• Example (plain text via stdin):

  gog gmail send --to recipient@example.com \
    --subject "Meeting Follow-up" \
    --body-file - <<'EOF'
  Hi Name,
  
  Thanks for meeting today. Next steps:
  - Item one
  - Item two
  
  Best regards,
  Your Name
  EOF
  

• Example (HTML list):

  gog gmail send --to recipient@example.com \
    --subject "Meeting Follow-up" \
    --body-html "<p>Hi Name,</p><p>Thanks for meeting today. Here are the next steps:</p><ul><li>Item one</li><li>Item two</li></ul><p>Best regards,<br>Your Name</p>"
  

Notes

• Set GOG_ACCOUNT=you@gmail.com to avoid repeating --account.
• For scripting, prefer --json plus --no-input.
• Sheets values can be passed via --values-json (recommended) or as inline rows.
• Docs supports export/cat/copy. In-place edits require a Docs API client (not in gog).
• Confirm before sending mail or creating events.
• gog gmail search returns one row per thread; use gog gmail messages search when you need every individual email returned separately.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/gog
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Himalaya

Use himalaya for IMAP/SMTP email from shell.

References

• references/configuration.md: account config, auth, backend setup.
• references/message-composition.md: MML compose syntax.

Setup

himalaya --version
himalaya account configure

Config path: ~/.config/himalaya/config.toml.

Prefer password managers/keyrings for credentials; do not paste secrets into chat/logs.

Read/search

himalaya folder list
himalaya envelope list
himalaya message read <id>
himalaya envelope list from alice@example.com subject invoice

Write

himalaya message write
himalaya template write
himalaya template send < /tmp/message.txt
himalaya message reply <id>
himalaya message forward <id>

Use MML for attachments and rich messages; read references/message-composition.md first.

Organize

himalaya message copy <id> <folder>
himalaya message move <id> <folder>
himalaya message delete <id>
himalaya flag add <id> --flag seen
himalaya flag remove <id> --flag seen

Safety

• Confirm before sending, deleting, or moving many messages.
• Use --account when multiple accounts exist.
• Quote exact message IDs in summaries.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/himalaya
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Karpathy Guidelines

Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls.

Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.

1. Think Before Coding

Don't assume. Don't hide confusion. Surface tradeoffs.

Before implementing:

• State your assumptions explicitly. If uncertain, ask.
• If multiple interpretations exist, present them - don't pick silently.
• If a simpler approach exists, say so. Push back when warranted.
• If something is unclear, stop. Name what's confusing. Ask.

2. Simplicity First

Minimum code that solves the problem. Nothing speculative.

• No features beyond what was asked.
• No abstractions for single-use code.
• No "flexibility" or "configurability" that wasn't requested.
• No error handling for impossible scenarios.
• If you write 200 lines and it could be 50, rewrite it.

Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.

3. Surgical Changes

Touch only what you must. Clean up only your own mess.

When editing existing code:

• Don't "improve" adjacent code, comments, or formatting.
• Don't refactor things that aren't broken.
• Match existing style, even if you'd do it differently.
• If you notice unrelated dead code, mention it - don't delete it.

When your changes create orphans:

• Remove imports/variables/functions that YOUR changes made unused.
• Don't remove pre-existing dead code unless asked.

The test: Every changed line should trace directly to the user's request.

4. Goal-Driven Execution

Define success criteria. Loop until verified.

Transform tasks into verifiable goals:

• "Add validation" → "Write tests for invalid inputs, then make them pass"
• "Fix the bug" → "Write a test that reproduces it, then make it pass"
• "Refactor X" → "Ensure tests pass before and after"

For multi-step tasks, state a brief plan:

1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]

Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

Meeting Recorder Assistant

An intelligent meeting assistant that records, transcribes, and analyzes meetings to generate actionable insights.

Features

• Audio Recording: Record meeting audio with timestamps
• Speech-to-Text: Transcribe audio to text with speaker identification
• Meeting Minutes: Auto-generate structured meeting summaries
• Action Items: Extract tasks and assignments from discussions
• Sentiment Analysis: Analyze meeting tone and engagement

Usage

Record and Transcribe

from scripts.meeting_recorder import MeetingRecorder

# Initialize recorder
recorder = MeetingRecorder()

# Start recording
recorder.start_recording("/tmp/meeting_audio.wav")

# Stop and transcribe
transcript = recorder.stop_and_transcribe()
print(f"Transcript: {transcript['text']}")

Generate Meeting Minutes

from scripts.meeting_minutes import generate_minutes

# Generate structured minutes
minutes = generate_minutes(transcript_path="/tmp/transcript.json")
print(f"Summary: {minutes['summary']}")
print(f"Action Items: {minutes['action_items']}")

Extract Action Items

from scripts.action_extractor import extract_actions

# Extract tasks from transcript
actions = extract_actions("/tmp/transcript.txt")
for action in actions:
    print(f"- {action['task']} (Assigned: {action['assignee']})")

Supported Audio Formats

• WAV
• MP3
• M4A
• OGG

Output Formats

• JSON (structured data)
• Markdown (meeting minutes)
• TXT (transcript)

Notion

Prefer official ntn CLI. Use curl only when ntn is unavailable or a raw request is clearer.

Setup

npm install -g ntn
ntn --version
ntn login

Script/headless auth:

export NOTION_API_TOKEN=secret_or_ntn_token
export NOTION_API_VERSION=2026-03-11

ntn api sets Authorization and Notion-Version automatically. It uses CLI login by default, or NOTION_API_TOKEN when set.

Inspect

ntn doctor
ntn api ls
ntn api ls --json
ntn api v1/comments --help
ntn api v1/comments --spec -X POST
ntn api v1/comments --docs -X POST

Pages

Markdown-first helpers:

ntn pages get <page-id>
ntn pages get <page-id> --json
ntn pages create --parent page:<page-id> --content '# Title\n\nBody'
ntn pages create --parent data-source:<data-source-id> < page.md
ntn pages update <page-id> --content '# Updated'
ntn pages update <page-id> < page.md
ntn pages trash <page-id> --yes

Notes:

• pages get prints Markdown with page properties as frontmatter.
• Content input: --content, stdin, or editor in a TTY.
• Parent refs: page:<id>, database:<id>, data-source:<id>.
• For properties/templates/full Pages API, use ntn api v1/pages.

Data sources

ntn datasources resolve <database-id>
ntn datasources resolve <database-id> --json
ntn datasources query <data-source-id>
ntn datasources query <data-source-id> --limit 50 --json
ntn datasources query <data-source-id> --sort 'Date desc'
ntn datasources query <data-source-id> --filter '{"property":"Done","checkbox":{"equals":true}}'

Use resolve when you have a database ID. Query needs a data source ID.

Raw API

ntn api v1/users/me
ntn api v1/search query=roadmap page_size:=10
ntn api v1/pages 'parent[data_source_id]='"$DS_ID" 'properties[Name][title][0][text][content]=New item'
ntn api "v1/pages/$PAGE_ID" -X PATCH in_trash:=true
ntn api "v1/blocks/$PAGE_ID/children" -X PATCH \
  'children[0][type]=paragraph' \
  'children[0][paragraph][rich_text][0][text][content]=Hello'

Input syntax:

• path=value: string body field.
• path:=json: typed JSON body field.
• name==value: query parameter.
• Header:Value: request header.
• --data '<json>' or stdin JSON for larger bodies.
• Only one body source per request.

Files

ntn files create < image.png
ntn files create --filename photo.png --content-type image/png < /tmp/photo
ntn files create --external-url https://example.com/photo.png
ntn files get <upload-id>
ntn files list

Workers

ntn workers new
ntn workers deploy
ntn workers list --json
ntn workers runs list --json
ntn workers runs logs <run-id>

Workers may require Business/Enterprise plan and workspace enablement.

Curl fallback

curl -sS "https://api.notion.com/v1/users/me" \
  -H "Authorization: Bearer $NOTION_API_TOKEN" \
  -H "Notion-Version: 2026-03-11" \
  -H "Content-Type: application/json"

Version notes

• Current latest API version: 2026-03-11.
• Use in_trash, not archived.
• Append block positioning uses position, not flat after.
• transcription block renamed to meeting_notes.
• Databases can contain multiple data sources; page parents generally use data_source_id.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/notion
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Obsidian

Use the official obsidian CLI for Obsidian vault work. Vault files are plain Markdown, so direct file edits are still fine when safer/faster.

Requirements

• Obsidian 1.12.7+ installed.
• Settings -> General -> Command line interface enabled.
• obsidian registered on PATH.
• Obsidian app running; the CLI connects to the running app.

Check:

obsidian version
obsidian help

macOS registration creates /usr/local/bin/obsidian pointing at the app-bundled CLI. Linux registration copies the binary to ~/.local/bin/obsidian.

Vault model

• Notes: *.md.
• Config: .obsidian/; avoid editing unless asked.
• Canvases: *.canvas JSON.
• Attachments: vault-configured folder.
• Multiple vaults are common; pass vault="<name>" when ambiguous.

Obsidian desktop tracks vaults here:

• ~/Library/Application Support/obsidian/obsidian.json

Command pattern

obsidian <command> [name=value] [flag]
obsidian vault="Notes" search query="meeting notes" format=json

Parameter values with spaces need quotes. Add --copy to copy output where useful.

Common commands

Open/read:

obsidian open file=Recipe
obsidian open path="Inbox/Idea.md" newtab
obsidian read
obsidian read file=Recipe

Search:

obsidian search query="TODO" matches
obsidian search query="status::active" format=json
obsidian search:open query="project notes"

Create/modify:

obsidian create name="New Note"
obsidian create path="Inbox/Idea.md" content="# Idea"
obsidian append file=Note content="New line"
obsidian prepend file=Note content="After frontmatter"

Move/delete:

obsidian move file=Note to=Archive/
obsidian move path="Inbox/Old.md" to="Projects/New.md"
obsidian delete file=Note

Daily/tasks:

obsidian daily
obsidian daily:read
obsidian daily:append content="- [ ] Review inbox"
obsidian tasks all todo
obsidian task file=Note line=8 done

Properties/links:

obsidian tags all counts
obsidian property:read file=Note name=status
obsidian property:set file=Note name=status value=done
obsidian backlinks file=Note
obsidian unresolved verbose counts

Developer/debug:

obsidian plugin:reload my-plugin
obsidian dev:errors
obsidian dev:screenshot file=shot.png
obsidian eval "app.vault.getFiles().length"

Notes

• file=<name> uses Obsidian-style file resolution; path=<vault-relative.md> is exact.
• Prefer CLI move/delete/property commands for Obsidian-aware updates.
• Prefer direct Markdown edits for bulk text changes after locating the vault path.
• Do not rely on third-party obsidian-cli unless user explicitly asks for it.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/obsidian
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

PilotDeck Skills Migration

Use this skill to migrate Agent Skill folders into PilotDeck's global skill store, ~/.pilotdeck/skills.

Workflow

Use the repo npm script from the repo root:

npm run skills:migrate

npm run dev runs predev, which syncs this repo skill into $PILOT_HOME/skills (~/.pilotdeck/skills by default). The migration command itself stays available as npm run skills:migrate without requiring a global pilotdeck command on PATH.

1. Ask the user which source to migrate before running any migration command. Use ask_user_question with these options:

Which skills should I migrate into PilotDeck?
- Claude Code
- OpenClaw
- Hermes
- Custom path

For "Custom path", ask for the source directory path before continuing.

2. Run a dry run for only the selected source:

npm run skills:migrate -- --from cc
npm run skills:migrate -- --from openclaw
npm run skills:migrate -- --from hermes
npm run skills:migrate -- --source /path/to/skills

3. If the dry run finds no source path or no migratable skill directories, stop. Do not run --execute. Tell the user which source was checked and that no matching SKILL.md directories were found.

4. Review the dry-run report with the user, especially conflicts and validation errors.

5. Copy skills only after confirmation:

npm run skills:migrate -- --from cc --execute
npm run skills:migrate -- --from openclaw --execute
npm run skills:migrate -- --from hermes --execute
npm run skills:migrate -- --source /path/to/skills --execute

Common Commands

Migrate only selected sources:

npm run skills:migrate -- --from cc,openclaw --execute
npm run skills:migrate -- --from hermes --execute

Handle destination conflicts:

npm run skills:migrate -- --rename --execute
npm run skills:migrate -- --overwrite --execute

Migrate a custom source directory:

npm run skills:migrate -- --source /path/to/skills --execute

Use JSON for scripts or machine-readable reports:

npm run skills:migrate -- --json

Default Sources

The PilotDeck migrator scans immediate child directories containing SKILL.md from:

• Claude Code: ~/.claude/skills, <project>/.claude/skills
• OpenClaw: ~/.openclaw/workspace/skills, ~/.openclaw/workspace-main/skills, ~/.openclaw/workspace-assistant/skills, ~/.openclaw/skills, ~/.agents/skills
• Hermes: ~/.hermes/skills, ~/.hermes/.claude/skills, ~/.hermes/.agents/skills

Safety Rules

• Always ask which source to migrate first; do not assume all sources.
• If the selected source path is missing, or the dry run reports no migratable skills, do not execute the migration. Report that nothing was found.
• Do not delete source skills.
• Prefer --rename over --overwrite unless the user explicitly wants to replace existing PilotDeck skills.
• The repo bootstrap syncs this skill into $PILOT_HOME/skills from skills/pilotdeck-skills-migration/SKILL.md; it skips existing targets.

React / Next.js Best Practices

Use this skill when creating, reviewing, or refactoring React or Next.js applications.

Focus Areas

• Component boundaries: keep components cohesive and avoid unnecessary abstraction.
• Data fetching: avoid waterfalls; keep server/client responsibilities explicit.
• Rendering model: distinguish Server Components, Client Components, SSR, SSG, and dynamic routes.
• State: keep local state local; avoid global state unless shared behavior requires it.
• Performance: watch bundle size, memoization misuse, expensive renders, image loading, and caching.
• Hydration: avoid browser-only values during server render unless guarded.
• Accessibility: use semantic HTML before custom ARIA.
• Testing: prefer targeted tests for changed behavior.

Review Output

Return concrete findings with file paths, severity, and suggested fixes. Avoid generic advice unless tied to the current code.

PilotDeck Migration Note

• Source inspiration: Vercel Agent Skills for React/Next.js workflows.
• This is a PilotDeck-native draft, not a verbatim copy and is not Vercel-platform-specific.

Skill Creator

A skill for creating new skills and iteratively improving them.

At a high level, the process of creating a skill goes like this:

• Decide what you want the skill to do and roughly how it should do it
• Write a draft of the skill
• Create a few test prompts and run claude-with-access-to-the-skill on them
• Help the user evaluate the results both qualitatively and quantitatively
  • While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, you can either use as is or modify if you feel something needs to change about them). Then explain them to the user (or if they already existed, explain the ones that already exist)
  • Use the eval-viewer/generate_review.py script to show the user the results for them to look at, and also let them look at the quantitative metrics
• Rewrite the skill based on feedback from the user's evaluation of the results (and also if there are any glaring flaws that become apparent from the quantitative benchmarks)
• Repeat until you're satisfied
• Expand the test set and try again at larger scale

Your job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages. So for instance, maybe they're like "I want to make a skill for X". You can help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, run all the prompts, and repeat.

On the other hand, maybe they already have a draft of the skill. In this case you can go straight to the eval/iterate part of the loop.

Of course, you should always be flexible and if the user is like "I don't need to run a bunch of evaluations, just vibe with me", you can do that instead.

Then after the skill is done (but again, the order is flexible), you can also run the skill description improver, which we have a whole separate script for, to optimize the triggering of the skill.

Cool? Cool.

Communicating with the user

The skill creator is liable to be used by people across a wide range of familiarity with coding jargon. If you haven't heard (and how could you, it's only very recently that it started), there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google "how to install npm". On the other hand, the bulk of users are probably fairly computer-literate.

So please pay attention to context cues to understand how to phrase your communication! In the default case, just to give you some idea:

• "evaluation" and "benchmark" are borderline, but OK
• for "JSON" and "assertion" you want to see serious cues from the user that they know what those things are before using them without explaining them

It's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it.

Creating a skill

Capture Intent

Start by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say "turn this into a skill"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. The user may need to fill the gaps, and should confirm before proceeding to the next step.

1. What should this skill enable Claude to do?
2. When should this skill trigger? (what user phrases/contexts)
3. What's the expected output format?
4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't need them. Suggest the appropriate default based on the skill type, but let the user decide.

Interview and Research

Proactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out.

Check available MCPs - if useful for research (searching docs, finding similar skills, looking up best practices), research in parallel via subagents if available, otherwise inline. Come prepared with context to reduce burden on the user.

Write the SKILL.md

Based on the user interview, fill in these components:

• name: Skill identifier
• description: When to trigger, what it does. This is the primary triggering mechanism - include both what the skill does AND specific contexts for when to use it. All "when to use" info goes here, not in the body. Note: currently Claude has a tendency to "undertrigger" skills -- to not use them when they'd be useful. To combat this, please make the skill descriptions a little bit "pushy". So for instance, instead of "How to build a simple fast dashboard to display internal Anthropic data.", you might write "How to build a simple fast dashboard to display internal Anthropic data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'"
• compatibility: Required tools, dependencies (optional, rarely needed)
• the rest of the skill :)

Skill Writing Guide

Anatomy of a Skill

skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter (name, description required)
│   └── Markdown instructions
└── Bundled Resources (optional)
    ├── scripts/    - Executable code for deterministic/repetitive tasks
    ├── references/ - Docs loaded into context as needed
    └── assets/     - Files used in output (templates, icons, fonts)

Progressive Disclosure

Skills use a three-level loading system:

1. Metadata (name + description) - Always in context (~100 words)
2. SKILL.md body - In context whenever skill triggers (<500 lines ideal)
3. Bundled resources - As needed (unlimited, scripts can execute without loading)

These word counts are approximate and you can feel free to go longer if needed.

Key patterns:

• Keep SKILL.md under 500 lines; if you're approaching this limit, add an additional layer of hierarchy along with clear pointers about where the model using the skill should go next to follow up.
• Reference files clearly from SKILL.md with guidance on when to read them
• For large reference files (>300 lines), include a table of contents

Domain organization: When a skill supports multiple domains/frameworks, organize by variant:

cloud-deploy/
├── SKILL.md (workflow + selection)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

Claude reads only the relevant reference file.

Principle of Lack of Surprise

This goes without saying, but skills must not contain malware, exploit code, or any content that could compromise system security. A skill's contents should not surprise the user in their intent if described. Don't go along with requests to create misleading skills or skills designed to facilitate unauthorized access, data exfiltration, or other malicious activities. Things like a "roleplay as an XYZ" are OK though.

Writing Patterns

Prefer using the imperative form in instructions.

Defining output formats - You can do it like this:

## Report structure
ALWAYS use this exact template:
# [Title]
## Executive summary
## Key findings
## Recommendations

Examples pattern - It's useful to include examples. You can format them like this (but if "Input" and "Output" are in the examples you might want to deviate a little):

## Commit message format
**Example 1:**
Input: Added user authentication with JWT tokens
Output: feat(auth): implement JWT-based authentication

Writing Style

Try to explain to the model why things are important in lieu of heavy-handed musty MUSTs. Use theory of mind and try to make the skill general and not super-narrow to specific examples. Start by writing a draft and then look at it with fresh eyes and improve it.

Test Cases

After writing the skill draft, come up with 2-3 realistic test prompts — the kind of thing a real user would actually say. Share them with the user: [you don't have to use this exact language] "Here are a few test cases I'd like to try. Do these look right, or do you want to add more?" Then run them.

Save test cases to evals/evals.json. Don't write assertions yet — just the prompts. You'll draft assertions in the next step while the runs are in progress.

{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "User's task prompt",
      "expected_output": "Description of expected result",
      "files": []
    }
  ]
}

See references/schemas.md for the full schema (including the assertions field, which you'll add later).

Running and evaluating test cases

This section is one continuous sequence — don't stop partway through. Do NOT use /skill-test or any other testing skill.

Put results in <skill-name>-workspace/ as a sibling to the skill directory. Within the workspace, organize results by iteration (iteration-1/, iteration-2/, etc.) and within that, each test case gets a directory (eval-0/, eval-1/, etc.). Don't create all of this upfront — just create directories as you go.

Step 1: Spawn all runs (with-skill AND baseline) in the same turn

For each test case, spawn two subagents in the same turn — one with the skill, one without. This is important: don't spawn the with-skill runs first and then come back for baselines later. Launch everything at once so it all finishes around the same time.

With-skill run:

Execute this task:
- Skill path: <path-to-skill>
- Task: <eval prompt>
- Input files: <eval files if any, or "none">
- Save outputs to: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- Outputs to save: <what the user cares about — e.g., "the .docx file", "the final CSV">

Baseline run (same prompt, but the baseline depends on context):

• Creating a new skill: no skill at all. Same prompt, no skill path, save to without_skill/outputs/.
• Improving an existing skill: the old version. Before editing, snapshot the skill (cp -r <skill-path> <workspace>/skill-snapshot/), then point the baseline subagent at the snapshot. Save to old_skill/outputs/.

Write an eval_metadata.json for each test case (assertions can be empty for now). Give each eval a descriptive name based on what it's testing — not just "eval-0". Use this name for the directory too. If this iteration uses new or modified eval prompts, create these files for each new eval directory — don't assume they carry over from previous iterations.

{
  "eval_id": 0,
  "eval_name": "descriptive-name-here",
  "prompt": "The user's task prompt",
  "assertions": []
}

Step 2: While runs are in progress, draft assertions

Don't just wait for the runs to finish — you can use this time productively. Draft quantitative assertions for each test case and explain them to the user. If assertions already exist in evals/evals.json, review them and explain what they check.

Good assertions are objectively verifiable and have descriptive names — they should read clearly in the benchmark viewer so someone glancing at the results immediately understands what each one checks. Subjective skills (writing style, design quality) are better evaluated qualitatively — don't force assertions onto things that need human judgment.

Update the eval_metadata.json files and evals/evals.json with the assertions once drafted. Also explain to the user what they'll see in the viewer — both the qualitative outputs and the quantitative benchmark.

Step 3: As runs complete, capture timing data

When each subagent task completes, you receive a notification containing total_tokens and duration_ms. Save this data immediately to timing.json in the run directory:

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

This is the only opportunity to capture this data — it comes through the task notification and isn't persisted elsewhere. Process each notification as it arrives rather than trying to batch them.

Step 4: Grade, aggregate, and launch the viewer

Once all runs are done:

1. Grade each run — spawn a grader subagent (or grade inline) that reads agents/grader.md and evaluates each assertion against the outputs. Save results to grading.json in each run directory. The grading.json expectations array must use the fields text, passed, and evidence (not name/met/details or other variants) — the viewer depends on these exact field names. For assertions that can be checked programmatically, write and run a script rather than eyeballing it — scripts are faster, more reliable, and can be reused across iterations.

2. Aggregate into benchmark — run the aggregation script from the skill-creator directory:

   python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
   

   This produces benchmark.json and benchmark.md with pass_rate, time, and tokens for each configuration, with mean ± stddev and the delta. If generating benchmark.json manually, see references/schemas.md for the exact schema the viewer expects. Put each with_skill version before its baseline counterpart.

3. Do an analyst pass — read the benchmark data and surface patterns the aggregate stats might hide. See agents/analyzer.md (the "Analyzing Benchmark Results" section) for what to look for — things like assertions that always pass regardless of skill (non-discriminating), high-variance evals (possibly flaky), and time/token tradeoffs.

4. Launch the viewer with both qualitative outputs and quantitative data:

   nohup python <skill-creator-path>/eval-viewer/generate_review.py \
     <workspace>/iteration-N \
     --skill-name "my-skill" \
     --benchmark <workspace>/iteration-N/benchmark.json \
     > /dev/null 2>&1 &
   VIEWER_PID=$!
   

   For iteration 2+, also pass --previous-workspace <workspace>/iteration-<N-1>.

   Cowork / headless environments: If webbrowser.open() is not available or the environment has no display, use --static <output_path> to write a standalone HTML file instead of starting a server. Feedback will be downloaded as a feedback.json file when the user clicks "Submit All Reviews". After download, copy feedback.json into the workspace directory for the next iteration to pick up.

Note: please use generate_review.py to create the viewer; there's no need to write custom HTML.

5. Tell the user something like: "I've opened the results in your browser. There are two tabs — 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. When you're done, come back here and let me know."

What the user sees in the viewer

The "Outputs" tab shows one test case at a time:

• Prompt: the task that was given
• Output: the files the skill produced, rendered inline where possible
• Previous Output (iteration 2+): collapsed section showing last iteration's output
• Formal Grades (if grading was run): collapsed section showing assertion pass/fail
• Feedback: a textbox that auto-saves as they type
• Previous Feedback (iteration 2+): their comments from last time, shown below the textbox

The "Benchmark" tab shows the stats summary: pass rates, timing, and token usage for each configuration, with per-eval breakdowns and analyst observations.

Navigation is via prev/next buttons or arrow keys. When done, they click "Submit All Reviews" which saves all feedback to feedback.json.

Step 5: Read the feedback

When the user tells you they're done, read feedback.json:

{
  "reviews": [
    {"run_id": "eval-0-with_skill", "feedback": "the chart is missing axis labels", "timestamp": "..."},
    {"run_id": "eval-1-with_skill", "feedback": "", "timestamp": "..."},
    {"run_id": "eval-2-with_skill", "feedback": "perfect, love this", "timestamp": "..."}
  ],
  "status": "complete"
}

Empty feedback means the user thought it was fine. Focus your improvements on the test cases where the user had specific complaints.

Kill the viewer server when you're done with it:

kill $VIEWER_PID 2>/dev/null

Improving the skill

This is the heart of the loop. You've run the test cases, the user has reviewed the results, and now you need to make the skill better based on their feedback.

How to think about improvements

1. Generalize from the feedback. The big picture thing that's happening here is that we're trying to create skills that can be used a million times (maybe literally, maybe even more who knows) across many different prompts. Here you and the user are iterating on only a few examples over and over again because it helps move faster. The user knows these examples in and out and it's quick for them to assess new outputs. But if the skill you and the user are codeveloping works only for those examples, it's useless. Rather than put in fiddly overfitty changes, or oppressively constrictive MUSTs, if there's some stubborn issue, you might try branching out and using different metaphors, or recommending different patterns of working. It's relatively cheap to try and maybe you'll land on something great.

2. Keep the prompt lean. Remove things that aren't pulling their weight. Make sure to read the transcripts, not just the final outputs — if it looks like the skill is making the model waste a bunch of time doing things that are unproductive, you can try getting rid of the parts of the skill that are making it do that and seeing what happens.

3. Explain the why. Try hard to explain the why behind everything you're asking the model to do. Today's LLMs are smart. They have good theory of mind and when given a good harness can go beyond rote instructions and really make things happen. Even if the feedback from the user is terse or frustrated, try to actually understand the task and why the user is writing what they wrote, and what they actually wrote, and then transmit this understanding into the instructions. If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag — if possible, reframe and explain the reasoning so that the model understands why the thing you're asking for is important. That's a more humane, powerful, and effective approach.

4. Look for repeated work across test cases. Read the transcripts from the test runs and notice if the subagents all independently wrote similar helper scripts or took the same multi-step approach to something. If all 3 test cases resulted in the subagent writing a create_docx.py or a build_chart.py, that's a strong signal the skill should bundle that script. Write it once, put it in scripts/, and tell the skill to use it. This saves every future invocation from reinventing the wheel.

This task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over. I'd suggest writing a draft revision and then looking at it anew and making improvements. Really do your best to get into the head of the user and understand what they want and need.

The iteration loop

After improving the skill:

1. Apply your improvements to the skill
2. Rerun all test cases into a new iteration-<N+1>/ directory, including baseline runs. If you're creating a new skill, the baseline is always without_skill (no skill) — that stays the same across iterations. If you're improving an existing skill, use your judgment on what makes sense as the baseline: the original version the user came in with, or the previous iteration.
3. Launch the reviewer with --previous-workspace pointing at the previous iteration
4. Wait for the user to review and tell you they're done
5. Read the new feedback, improve again, repeat

Keep going until:

• The user says they're happy
• The feedback is all empty (everything looks good)
• You're not making meaningful progress

Advanced: Blind comparison

For situations where you want a more rigorous comparison between two versions of a skill (e.g., the user asks "is the new version actually better?"), there's a blind comparison system. Read agents/comparator.md and agents/analyzer.md for the details. The basic idea is: give two outputs to an independent agent without telling it which is which, and let it judge quality. Then analyze why the winner won.

This is optional, requires subagents, and most users won't need it. The human review loop is usually sufficient.

Description Optimization

The description field in SKILL.md frontmatter is the primary mechanism that determines whether Claude invokes a skill. After creating or improving a skill, offer to optimize the description for better triggering accuracy.

Step 1: Generate trigger eval queries

Create 20 eval queries — a mix of should-trigger and should-not-trigger. Save as JSON:

[
  {"query": "the user prompt", "should_trigger": true},
  {"query": "another prompt", "should_trigger": false}
]

The queries must be realistic and something a Claude Code or Claude.ai user would actually type. Not abstract requests, but requests that are concrete and specific and have a good amount of detail. For instance, file paths, personal context about the user's job or situation, column names and values, company names, URLs. A little bit of backstory. Some might be in lowercase or contain abbreviations or typos or casual speech. Use a mix of different lengths, and focus on edge cases rather than making them clear-cut (the user will get a chance to sign off on them).

Bad: "Format this data", "Extract text from PDF", "Create a chart"

Good: "ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think"

For the should-trigger queries (8-10), think about coverage. You want different phrasings of the same intent — some formal, some casual. Include cases where the user doesn't explicitly name the skill or file type but clearly needs it. Throw in some uncommon use cases and cases where this skill competes with another but should win.

For the should-not-trigger queries (8-10), the most valuable ones are the near-misses — queries that share keywords or concepts with the skill but actually need something different. Think adjacent domains, ambiguous phrasing where a naive keyword match would trigger but shouldn't, and cases where the query touches on something the skill does but in a context where another tool is more appropriate.

The key thing to avoid: don't make should-not-trigger queries obviously irrelevant. "Write a fibonacci function" as a negative test for a PDF skill is too easy — it doesn't test anything. The negative cases should be genuinely tricky.

Step 2: Review with user

Present the eval set to the user for review using the HTML template:

1. Read the template from assets/eval_review.html
2. Replace the placeholders:
   • __EVAL_DATA_PLACEHOLDER__ → the JSON array of eval items (no quotes around it — it's a JS variable assignment)
   • __SKILL_NAME_PLACEHOLDER__ → the skill's name
   • __SKILL_DESCRIPTION_PLACEHOLDER__ → the skill's current description
3. Write to a temp file (e.g., /tmp/eval_review_<skill-name>.html) and open it: open /tmp/eval_review_<skill-name>.html
4. The user can edit queries, toggle should-trigger, add/remove entries, then click "Export Eval Set"
5. The file downloads to ~/Downloads/eval_set.json — check the Downloads folder for the most recent version in case there are multiple (e.g., eval_set (1).json)

This step matters — bad eval queries lead to bad descriptions.

Step 3: Run the optimization loop

Tell the user: "This will take some time — I'll run the optimization loop in the background and check on it periodically."

Save the eval set to the workspace, then run in the background:

python -m scripts.run_loop \
  --eval-set <path-to-trigger-eval.json> \
  --skill-path <path-to-skill> \
  --model <model-id-powering-this-session> \
  --max-iterations 5 \
  --verbose

Use the model ID from your system prompt (the one powering the current session) so the triggering test matches what the user actually experiences.

While it runs, periodically tail the output to give the user updates on which iteration it's on and what the scores look like.

This handles the full optimization loop automatically. It splits the eval set into 60% train and 40% held-out test, evaluates the current description (running each query 3 times to get a reliable trigger rate), then calls Claude to propose improvements based on what failed. It re-evaluates each new description on both train and test, iterating up to 5 times. When it's done, it opens an HTML report in the browser showing the results per iteration and returns JSON with best_description — selected by test score rather than train score to avoid overfitting.

How skill triggering works

Understanding the triggering mechanism helps design better eval queries. Skills appear in Claude's available_skills list with their name + description, and Claude decides whether to consult a skill based on that description. The important thing to know is that Claude only consults skills for tasks it can't easily handle on its own — simple, one-step queries like "read this PDF" may not trigger a skill even if the description matches perfectly, because Claude can handle them directly with basic tools. Complex, multi-step, or specialized queries reliably trigger skills when the description matches.

This means your eval queries should be substantive enough that Claude would actually benefit from consulting a skill. Simple queries like "read file X" are poor test cases — they won't trigger skills regardless of description quality.

Step 4: Apply the result

Take best_description from the JSON output and update the skill's SKILL.md frontmatter. Show the user before/after and report the scores.

Package and Present (only if present_files tool is available)

Check whether you have access to the present_files tool. If you don't, skip this step. If you do, package the skill and present the .skill file to the user:

python -m scripts.package_skill <path/to/skill-folder>

After packaging, direct the user to the resulting .skill file path so they can install it.

Claude.ai-specific instructions

In Claude.ai, the core workflow is the same (draft → test → review → improve → repeat), but because Claude.ai doesn't have subagents, some mechanics change. Here's what to adapt:

Running test cases: No subagents means no parallel execution. For each test case, read the skill's SKILL.md, then follow its instructions to accomplish the test prompt yourself. Do them one at a time. This is less rigorous than independent subagents (you wrote the skill and you're also running it, so you have full context), but it's a useful sanity check — and the human review step compensates. Skip the baseline runs — just use the skill to complete the task as requested.

Reviewing results: If you can't open a browser (e.g., Claude.ai's VM has no display, or you're on a remote server), skip the browser reviewer entirely. Instead, present results directly in the conversation. For each test case, show the prompt and the output. If the output is a file the user needs to see (like a .docx or .xlsx), save it to the filesystem and tell them where it is so they can download and inspect it. Ask for feedback inline: "How does this look? Anything you'd change?"

Benchmarking: Skip the quantitative benchmarking — it relies on baseline comparisons which aren't meaningful without subagents. Focus on qualitative feedback from the user.

The iteration loop: Same as before — improve the skill, rerun the test cases, ask for feedback — just without the browser reviewer in the middle. You can still organize results into iteration directories on the filesystem if you have one.

Description optimization: This section requires the claude CLI tool (specifically claude -p) which is only available in Claude Code. Skip it if you're on Claude.ai.

Blind comparison: Requires subagents. Skip it.

Packaging: The package_skill.py script works anywhere with Python and a filesystem. On Claude.ai, you can run it and the user can download the resulting .skill file.

Updating an existing skill: The user might be asking you to update an existing skill, not create a new one. In this case:

• Preserve the original name. Note the skill's directory name and name frontmatter field -- use them unchanged. E.g., if the installed skill is research-helper, output research-helper.skill (not research-helper-v2).
• Copy to a writeable location before editing. The installed skill path may be read-only. Copy to /tmp/skill-name/, edit there, and package from the copy.
• If packaging manually, stage in /tmp/ first, then copy to the output directory -- direct writes may fail due to permissions.

Cowork-Specific Instructions

If you're in Cowork, the main things to know are:

• You have subagents, so the main workflow (spawn test cases in parallel, run baselines, grade, etc.) all works. (However, if you run into severe problems with timeouts, it's OK to run the test prompts in series rather than parallel.)
• You don't have a browser or display, so when generating the eval viewer, use --static <output_path> to write a standalone HTML file instead of starting a server. Then proffer a link that the user can click to open the HTML in their browser.
• For whatever reason, the Cowork setup seems to disincline Claude from generating the eval viewer after running the tests, so just to reiterate: whether you're in Cowork or in Claude Code, after running tests, you should always generate the eval viewer for the human to look at examples before revising the skill yourself and trying to make corrections, using generate_review.py (not writing your own boutique html code). Sorry in advance but I'm gonna go all caps here: GENERATE THE EVAL VIEWER BEFORE evaluating inputs yourself. You want to get them in front of the human ASAP!
• Feedback works differently: since there's no running server, the viewer's "Submit All Reviews" button will download feedback.json as a file. You can then read it from there (you may have to request access first).
• Packaging works — package_skill.py just needs Python and a filesystem.
• Description optimization (run_loop.py / run_eval.py) should work in Cowork just fine since it uses claude -p via subprocess, not a browser, but please save it until you've fully finished making the skill and the user agrees it's in good shape.
• Updating an existing skill: The user might be asking you to update an existing skill, not create a new one. Follow the update guidance in the claude.ai section above.

Reference files

The agents/ directory contains instructions for specialized subagents. Read them when you need to spawn the relevant subagent.

• agents/grader.md — How to evaluate assertions against outputs
• agents/comparator.md — How to do blind A/B comparison between two outputs
• agents/analyzer.md — How to analyze why one version beat another

The references/ directory has additional documentation:

• references/schemas.md — JSON structures for evals.json, grading.json, etc.

Repeating one more time the core loop here for emphasis:

• Figure out what the skill is about
• Draft or edit the skill
• Run claude-with-access-to-the-skill on test prompts
• With the user, evaluate the outputs:
  • Create benchmark.json and run eval-viewer/generate_review.py to help the user review them
  • Run quantitative evals
• Repeat until you and the user are satisfied
• Package the final skill and return it to the user.

Please add steps to your TodoList, if you have such a thing, to make sure you don't forget. If you're in Cowork, please specifically put "Create evals JSON and run eval-viewer/generate_review.py so human can review test cases" in your TodoList to make sure it happens.

Good luck!

Spike

Use when the user wants to test an idea before committing to a real build: "spike this", "quick prototype", "is this possible", "compare A/B", "before we build".

Do not use when reading docs/code can answer the question, or when the user clearly asked for production implementation.

Loop

1. Question: state the concrete feasibility question.
2. Research: read enough docs/source to choose credible approach.
3. Build: create the smallest runnable artifact that validates or invalidates the idea.
4. Stress: try one edge case or failure mode.
5. Verdict: VALIDATED, PARTIAL, or INVALIDATED.

Output shape

• Default workspace: .tmp/openclaw-spikes/<slug> unless user asks for a tracked repo-local path.
• Repo-local option: spikes/<NNN-slug>/ with README.md and minimal code.
• Prefer runnable CLI, tiny HTML, one endpoint, or focused test.
• Avoid package sprawl, Docker, env files, app frameworks, and production cleanup.

Multi-spike ideas

• Split into 2-5 independent questions.
• Run the riskiest question first.
• For A/B comparisons, keep inputs equal and measure the same dimensions.
• Ask before building all variants if the work is more than a small prototype.

Verdict format

## Verdict: VALIDATED | PARTIAL | INVALIDATED

Question: ...
Evidence: exact command/output/measurement.
What worked: ...
What failed or surprised us: ...
Recommendation: ship / adjust / avoid, with the next production step.

Rules

• An invalidated spike is useful when it rules out a path with evidence.
• Do not merge spike code into production without rewriting it normally.
• If external dependencies are evaluated, check health: recent release/commit, docs, license, install friction.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/spike
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Summarize

Fast CLI to summarize URLs, local files, and YouTube links.

When to use (trigger phrases)

Use this skill immediately when the user asks any of:

• "use summarize.sh"
• "what's this link/video about?"
• "summarize this URL/article"
• "transcribe this YouTube/video" (best-effort transcript extraction; no yt-dlp needed)

Quick start

summarize "https://example.com"
summarize "/path/to/file.pdf"
summarize "https://youtu.be/dQw4w9WgXcQ" --youtube auto

YouTube: summary vs transcript

Best-effort transcript (URLs only):

summarize "https://youtu.be/dQw4w9WgXcQ" --youtube auto --extract

If the user asked for a transcript but it's huge, return a tight summary first, then ask which section/time range to expand.

Model + keys

Set the API key for your chosen provider:

• OpenAI: OPENAI_API_KEY
• Anthropic: ANTHROPIC_API_KEY
• xAI: XAI_API_KEY
• Google: GEMINI_API_KEY (aliases: GOOGLE_GENERATIVE_AI_API_KEY, GOOGLE_API_KEY)

Default model is auto; config may choose the provider/model.

Useful flags

• --length short|medium|long|xl|xxl|<chars>
• --max-output-tokens <count>
• --extract (print extracted content, no LLM summary)
• --json (machine readable)
• --firecrawl auto|off|always (fallback extraction)
• --youtube auto (Apify fallback if APIFY_API_TOKEN set)

Config

Optional config file: ~/.summarize/config.json

{ "model": "openai/gpt-5.2" }

Optional services:

• FIRECRAWL_API_KEY for blocked sites
• APIFY_API_TOKEN for YouTube fallback

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/summarize
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

tmux

Use for existing interactive tmux sessions. For one-shot commands, use normal shell. For new non-interactive background jobs, use background execution.

Basics

tmux ls
tmux list-windows -t shared
tmux list-panes -t shared:0
tmux capture-pane -t shared:0.0 -p
tmux capture-pane -t shared:0.0 -p -S -

Target format: session:window.pane, e.g. shared:0.0.

Send input

Literal text, then Enter:

tmux send-keys -t shared:0.0 -l -- "Please continue"
tmux send-keys -t shared:0.0 Enter

Special keys:

tmux send-keys -t shared:0.0 C-c
tmux send-keys -t shared:0.0 C-d
tmux send-keys -t shared:0.0 Escape

Use -l -- for arbitrary text. Split text and Enter to avoid paste/newline surprises.

Sessions

tmux new-session -d -s worker
tmux rename-session -t old new
tmux kill-session -t worker

Prompt checks

tmux capture-pane -t worker-3 -p | tail -20
tmux capture-pane -t worker-3 -p | rg "proceed|permission|Yes|No|❯"

Approve/select only when the prompt is understood:

tmux send-keys -t worker-3 -l -- "y"
tmux send-keys -t worker-3 Enter

Helpers

• scripts/find-sessions.sh: discover sessions.
• scripts/wait-for-text.sh: wait until pane output contains text.

Notes

• capture-pane -p prints to stdout for scripts.
• -S - captures full scrollback.
• tmux sessions persist across SSH disconnects.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/tmux
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Trello Skill

Manage Trello boards, lists, and cards directly from OpenClaw.

Setup

1. Get your API key: https://trello.com/app-key
2. Generate a token (click "Token" link on that page)
3. Set environment variables:

   export TRELLO_API_KEY="your-api-key"
   export TRELLO_TOKEN="your-token"
   

Usage

All commands use curl to hit the Trello REST API.

List boards

curl -s "https://api.trello.com/1/members/me/boards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" | jq '.[] | {name, id}'

List lists in a board

curl -s "https://api.trello.com/1/boards/{boardId}/lists?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" | jq '.[] | {name, id}'

List cards in a list

curl -s "https://api.trello.com/1/lists/{listId}/cards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" | jq '.[] | {name, id, desc}'

Create a card

curl -s -X POST "https://api.trello.com/1/cards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" \
  -d "idList={listId}" \
  -d "name=Card Title" \
  -d "desc=Card description"

Move a card to another list

curl -s -X PUT "https://api.trello.com/1/cards/{cardId}?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" \
  -d "idList={newListId}"

Add a comment to a card

curl -s -X POST "https://api.trello.com/1/cards/{cardId}/actions/comments?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" \
  -d "text=Your comment here"

Archive a card

curl -s -X PUT "https://api.trello.com/1/cards/{cardId}?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" \
  -d "closed=true"

Notes

• Board/List/Card IDs can be found in the Trello URL or via the list commands
• The API key and token provide full access to your Trello account - keep them secret!
• Rate limits: 300 requests per 10 seconds per API key; 100 requests per 10 seconds per token; /1/members endpoints are limited to 100 requests per 900 seconds

Examples

# Get all boards
curl -s "https://api.trello.com/1/members/me/boards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN&fields=name,id" | jq

# Find a specific board by name
curl -s "https://api.trello.com/1/members/me/boards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" | jq '.[] | select(.name | contains("Work"))'

# Get all cards on a board
curl -s "https://api.trello.com/1/boards/{boardId}/cards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" | jq '.[] | {name, list: .idList}'

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/trello
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Weather

Use for current weather, rain/temperature checks, forecasts, and travel planning. Need a city, region, airport code, or coordinates.

Commands

curl "wttr.in/London?format=3"
curl "wttr.in/London?0"
curl "wttr.in/London"
curl "wttr.in/London?format=v2"
curl "wttr.in/London?1"
curl "wttr.in/New+York?format=3"

Useful formats:

• %l: location
• %c: condition icon
• %t: temperature
• %f: feels like
• %w: wind
• %h: humidity
• %p: precipitation

curl "wttr.in/London?format=%l:+%c+%t,+feels+%f,+rain+%p,+wind+%w"

JSON:

curl "wttr.in/London?format=j1"

Notes

• For severe alerts, aviation, marine, or official decisions, use official local weather services.
• For historical climate/weather, use an archive/API, not wttr.in.
• For hyper-local microclimates, prefer local sensors.

PilotDeck Migration Note

• Source: /var/folders/27/xyyzc_n172l3jjmnxgqmhhzh0000gn/T/tmp.AyWDWGKoS4/openclaw/skills/weather
• Review status: candidate for PilotDeck native skills pack.
• Platform-specific OpenClaw/Hermes metadata was removed or should be ignored during review.

Find Skills

This skill helps you discover and install skills from the open agent skills ecosystem.

When to Use This Skill

Use this skill when the user:

• Asks "how do I do X" where X might be a common task with an existing skill
• Says "find a skill for X" or "is there a skill for X"
• Asks "can you do X" where X is a specialized capability
• Expresses interest in extending agent capabilities
• Wants to search for tools, templates, or workflows
• Mentions they wish they had help with a specific domain (design, testing, deployment, etc.)

What is the Skills CLI?

The Skills CLI (npx skills) is the package manager for the open agent skills ecosystem. Skills are modular packages that extend agent capabilities with specialized knowledge, workflows, and tools.

Key commands:

• npx skills find [query] - Search for skills interactively or by keyword
• npx skills add <package> - Install a skill from GitHub or other sources
• npx skills check - Check for skill updates
• npx skills update - Update all installed skills

Browse skills at: https://skills.sh/

How to Help Users Find Skills

Step 1: Understand What They Need

When a user asks for help with something, identify:

1. The domain (e.g., React, testing, design, deployment)
2. The specific task (e.g., writing tests, creating animations, reviewing PRs)
3. Whether this is a common enough task that a skill likely exists

Step 2: Check the Leaderboard First

Before running a CLI search, check the skills.sh leaderboard to see if a well-known skill already exists for the domain. The leaderboard ranks skills by total installs, surfacing the most popular and battle-tested options.

For example, top skills for web development include:

• vercel-labs/agent-skills — React, Next.js, web design (100K+ installs each)
• anthropics/skills — Frontend design, document processing (100K+ installs)

Step 3: Search for Skills

If the leaderboard doesn't cover the user's need, run the find command:

npx skills find [query]

For example:

• User asks "how do I make my React app faster?" → npx skills find react performance
• User asks "can you help me with PR reviews?" → npx skills find pr review
• User asks "I need to create a changelog" → npx skills find changelog

Step 4: Verify Quality Before Recommending

Do not recommend a skill based solely on search results. Always verify:

1. Install count — Prefer skills with 1K+ installs. Be cautious with anything under 100.
2. Source reputation — Official sources (vercel-labs, anthropics, microsoft) are more trustworthy than unknown authors.
3. GitHub stars — Check the source repository. A skill from a repo with <100 stars should be treated with skepticism.

Step 5: Present Options to the User

When you find relevant skills, present them to the user with:

1. The skill name and what it does
2. The install count and source
3. The install command they can run
4. A link to learn more at skills.sh

Example response:

I found a skill that might help! The "react-best-practices" skill provides
React and Next.js performance optimization guidelines from Vercel Engineering.
(185K installs)

To install it:
npx skills add vercel-labs/agent-skills@react-best-practices

Learn more: https://skills.sh/vercel-labs/agent-skills/react-best-practices

Step 6: Offer to Install

If the user wants to proceed, you can install the skill for them:

npx skills add <owner/repo@skill> -g -y

The -g flag installs globally (user-level) and -y skips confirmation prompts.

Common Skill Categories

When searching, consider these common categories:

Tips for Effective Searches

1. Use specific keywords: "react testing" is better than just "testing"
2. Try alternative terms: If "deploy" doesn't work, try "deployment" or "ci-cd"
3. Check popular sources: Many skills come from vercel-labs/agent-skills or ComposioHQ/awesome-claude-skills

When No Skills Are Found

If no relevant skills exist:

1. Acknowledge that no existing skill was found
2. Offer to help with the task directly using your general capabilities
3. Suggest the user could create their own skill with npx skills init

Example:

I searched for skills related to "xyz" but didn't find any matches.
I can still help you with this task directly! Would you like me to proceed?

If this is something you do often, you could create your own skill:
npx skills init my-xyz-skill

Frontend Design

Use this skill when creating or reviewing frontend UI where visual quality matters.

Workflow

1. Clarify the product context, target user, and page goal.
2. Establish visual hierarchy before writing code: primary action, secondary action, supporting content.
3. Choose a deliberate visual direction instead of generic gradients and cards.
4. Use consistent spacing, type scale, color tokens, border radius, shadows, and component rhythm.
5. Design responsive states, loading states, empty states, error states, and disabled states.
6. Verify the result in a browser or preview surface when available.

Review Checklist

• The page has a clear focal point and primary action.
• Components align to a consistent grid.
• Typography has enough contrast and hierarchy.
• Color is meaningful, not decorative noise.
• The UI works at common mobile/tablet/desktop widths.
• Empty/loading/error states are intentional.

PilotDeck Migration Note

• Source inspiration: Anthropic frontend-design skill and general frontend design best practices.
• This is a PilotDeck-native draft, not a verbatim copy.

minimax-pdf

Three tasks. One skill.

Read design/design.md before any CREATE or REFORMAT work.

Route table

Rule: when in doubt between CREATE and REFORMAT, ask whether the user has an existing document to start from. If yes → REFORMAT. If no → CREATE.

Route A: CREATE

Full pipeline — content → design tokens → cover → body → merged PDF.

bash scripts/make.sh run \
  --title "Q3 Strategy Review" --type proposal \
  --author "Strategy Team" --date "October 2025" \
  --accent "#2D5F8A" \
  --content content.json --out report.pdf

Doc types: report · proposal · resume · portfolio · academic · general · minimal · stripe · diagonal · frame · editorial · magazine · darkroom · terminal · poster

Cover extras (inject into tokens via --abstract, --cover-image):

• --abstract "text" — abstract text block on the cover (magazine/darkroom)
• --cover-image "url" — hero image URL/path (magazine, darkroom, poster)

Color overrides — always choose these based on document content:

• --accent "#HEX" — override the accent color; accent_lt is auto-derived by lightening toward white
• --cover-bg "#HEX" — override the cover background color

Accent color selection guidance:

You have creative authority over the accent color. Pick it from the document's semantic context — title, industry, purpose, audience — not from generic "safe" choices. The accent appears on section rules, callout bars, table headers, and the cover: it carries the document's visual identity.

Rule: choose a color that a thoughtful designer would select for this specific document — not the type's default. Muted, desaturated tones work best; avoid vivid primaries. When in doubt, go darker and more neutral.

content.json block types:

chart / flowchart schemas:

{"type":"chart","chart_type":"bar","labels":["Q1","Q2","Q3","Q4"],
 "datasets":[{"label":"Revenue","values":[120,145,132,178]}],"caption":"Q results"}

{"type":"flowchart",
 "nodes":[{"id":"s","label":"Start","shape":"oval"},
          {"id":"p","label":"Process","shape":"rect"},
          {"id":"d","label":"Valid?","shape":"diamond"},
          {"id":"e","label":"End","shape":"oval"}],
 "edges":[{"from":"s","to":"p"},{"from":"p","to":"d"},
          {"from":"d","to":"e","label":"Yes"},{"from":"d","to":"p","label":"No"}]}

{"type":"bibliography","items":[
  {"id":"1","text":"Author (Year). Title. Publisher."}]}

Route B: FILL

Fill form fields in an existing PDF without altering layout or design.

# Step 1: inspect
python3 scripts/fill_inspect.py --input form.pdf

# Step 2: fill
python3 scripts/fill_write.py --input form.pdf --out filled.pdf \
  --values '{"FirstName": "Jane", "Agree": "true", "Country": "US"}'

Always run fill_inspect.py first to get exact field names.

Route C: REFORMAT

Parse an existing document → content.json → CREATE pipeline.

bash scripts/make.sh reformat \
  --input source.md --title "My Report" --type report --out output.pdf

Supported input formats: .md .txt .pdf .json

Environment

bash scripts/make.sh check   # verify all deps
bash scripts/make.sh fix     # auto-install missing deps
bash scripts/make.sh demo    # build a sample PDF

Web Design Guidelines

Use this skill after building or modifying web UI. It helps the agent review whether the interface is usable, readable, responsive, and polished.

Checklist

1. Layout: consistent alignment, predictable grid, no accidental crowding.
2. Typography: readable sizes, clear hierarchy, line length under control.
3. Color: sufficient contrast, semantic states, no random palette mixing.
4. Interaction: clear hover/focus/active/disabled states.
5. Responsiveness: mobile, tablet, and desktop layouts remain usable.
6. Accessibility: keyboard focus, labels, alt text, contrast, reduced motion where relevant.
7. Product states: loading, empty, error, offline, and success states exist when needed.
8. Polish: spacing, borders, shadows, icon sizes, and copy tone feel consistent.

Output

When reviewing, return: pass/fail summary, top issues, concrete fixes, and files/components likely affected.

PilotDeck Migration Note

• Source inspiration: Vercel Agent Skills web design guidance and common UI QA practice.
• This is a PilotDeck-native draft, not a verbatim copy.