vora-ai 0.1.0

package/skills/gifgrep/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: gifgrep
+description: Search GIF providers with CLI/TUI, download results, and extract stills/sheets.
+homepage: https://gifgrep.com
+metadata:
+  {
+    "vora":
+      {
+        "emoji": "🧲",
+        "requires": { "bins": ["gifgrep"] },
+        "install":
+          [
+            {
+              "id": "brew",
+              "kind": "brew",
+              "formula": "steipete/tap/gifgrep",
+              "bins": ["gifgrep"],
+              "label": "Install gifgrep (brew)",
+            },
+            {
+              "id": "go",
+              "kind": "go",
+              "module": "github.com/steipete/gifgrep/cmd/gifgrep@latest",
+              "bins": ["gifgrep"],
+              "label": "Install gifgrep (go)",
+            },
+          ],
+      },
+  }
+---
+
+# gifgrep
+
+Use `gifgrep` to search GIF providers (Tenor/Giphy), browse in a TUI, download results, and extract stills or sheets.
+
+GIF-Grab (gifgrep workflow)
+
+- Search → preview → download → extract (still/sheet) for fast review and sharing.
+
+Quick start
+
+- `gifgrep cats --max 5`
+- `gifgrep cats --format url | head -n 5`
+- `gifgrep search --json cats | jq '.[0].url'`
+- `gifgrep tui "office handshake"`
+- `gifgrep cats --download --max 1 --format url`
+
+TUI + previews
+
+- TUI: `gifgrep tui "query"`
+- CLI still previews: `--thumbs` (Kitty/Ghostty only; still frame)
+
+Download + reveal
+
+- `--download` saves to `~/Downloads`
+- `--reveal` shows the last download in Finder
+
+Stills + sheets
+
+- `gifgrep still ./clip.gif --at 1.5s -o still.png`
+- `gifgrep sheet ./clip.gif --frames 9 --cols 3 -o sheet.png`
+- Sheets = single PNG grid of sampled frames (great for quick review, docs, PRs, chat).
+- Tune: `--frames` (count), `--cols` (grid width), `--padding` (spacing).
+
+Providers
+
+- `--source auto|tenor|giphy`
+- `GIPHY_API_KEY` required for `--source giphy`
+- `TENOR_API_KEY` optional (Tenor demo key used if unset)
+
+Output
+
+- `--json` prints an array of results (`id`, `title`, `url`, `preview_url`, `tags`, `width`, `height`)
+- `--format` for pipe-friendly fields (e.g., `url`)
+
+Environment tweaks
+
+- `GIFGREP_SOFTWARE_ANIM=1` to force software animation
+- `GIFGREP_CELL_ASPECT=0.5` to tweak preview geometry

package/skills/github/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: github
+description: "GitHub operations via `gh` CLI: issues, PRs, CI runs, code review, API queries. Use when: (1) checking PR status or CI, (2) creating/commenting on issues, (3) listing/filtering PRs or issues, (4) viewing run logs. NOT for: complex web UI interactions requiring manual browser flows (use browser tooling when available), bulk operations across many repos (script with gh api), or when gh auth is not configured."
+metadata:
+  {
+    "vora":
+      {
+        "emoji": "🐙",
+        "requires": { "bins": ["gh"] },
+        "install":
+          [
+            {
+              "id": "brew",
+              "kind": "brew",
+              "formula": "gh",
+              "bins": ["gh"],
+              "label": "Install GitHub CLI (brew)",
+            },
+            {
+              "id": "apt",
+              "kind": "apt",
+              "package": "gh",
+              "bins": ["gh"],
+              "label": "Install GitHub CLI (apt)",
+            },
+          ],
+      },
+  }
+---
+
+# GitHub Skill
+
+Use the `gh` CLI to interact with GitHub repositories, issues, PRs, and CI.
+
+## When to Use
+
+✅ **USE this skill when:**
+
+- Checking PR status, reviews, or merge readiness
+- Viewing CI/workflow run status and logs
+- Creating, closing, or commenting on issues
+- Creating or merging pull requests
+- Querying GitHub API for repository data
+- Listing repos, releases, or collaborators
+
+## When NOT to Use
+
+❌ **DON'T use this skill when:**
+
+- Local git operations (commit, push, pull, branch) → use `git` directly
+- Non-GitHub repos (GitLab, Bitbucket, self-hosted) → different CLIs
+- Cloning repositories → use `git clone`
+- Reviewing actual code changes → use `coding-agent` skill
+- Complex multi-file diffs → use `coding-agent` or read files directly
+
+## Setup
+
+```bash
+# Authenticate (one-time)
+gh auth login
+
+# Verify
+gh auth status
+```
+
+## Common Commands
+
+### Pull Requests
+
+```bash
+# List PRs
+gh pr list --repo owner/repo
+
+# Check CI status
+gh pr checks 55 --repo owner/repo
+
+# View PR details
+gh pr view 55 --repo owner/repo
+
+# Create PR
+gh pr create --title "feat: add feature" --body "Description"
+
+# Merge PR
+gh pr merge 55 --squash --repo owner/repo
+```
+
+### Issues
+
+```bash
+# List issues
+gh issue list --repo owner/repo --state open
+
+# Create issue
+gh issue create --title "Bug: something broken" --body "Details..."
+
+# Close issue
+gh issue close 42 --repo owner/repo
+```
+
+### CI/Workflow Runs
+
+```bash
+# List recent runs
+gh run list --repo owner/repo --limit 10
+
+# View specific run
+gh run view <run-id> --repo owner/repo
+
+# View failed step logs only
+gh run view <run-id> --repo owner/repo --log-failed
+
+# Re-run failed jobs
+gh run rerun <run-id> --failed --repo owner/repo
+```
+
+### API Queries
+
+```bash
+# Get PR with specific fields
+gh api repos/owner/repo/pulls/55 --jq '.title, .state, .user.login'
+
+# List all labels
+gh api repos/owner/repo/labels --jq '.[].name'
+
+# Get repo stats
+gh api repos/owner/repo --jq '{stars: .stargazers_count, forks: .forks_count}'
+```
+
+## JSON Output
+
+Most commands support `--json` for structured output with `--jq` filtering:
+
+```bash
+gh issue list --repo owner/repo --json number,title --jq '.[] | "\(.number): \(.title)"'
+gh pr list --json number,title,state,mergeable --jq '.[] | select(.mergeable == "MERGEABLE")'
+```
+
+## Templates
+
+### PR Review Summary
+
+```bash
+# Get PR overview for review
+PR=55 REPO=owner/repo
+echo "## PR #$PR Summary"
+gh pr view $PR --repo $REPO --json title,body,author,additions,deletions,changedFiles \
+  --jq '"**\(.title)** by @\(.author.login)\n\n\(.body)\n\n📊 +\(.additions) -\(.deletions) across \(.changedFiles) files"'
+gh pr checks $PR --repo $REPO
+```
+
+### Issue Triage
+
+```bash
+# Quick issue triage view
+gh issue list --repo owner/repo --state open --json number,title,labels,createdAt \
+  --jq '.[] | "[\(.number)] \(.title) - \([.labels[].name] | join(", ")) (\(.createdAt[:10]))"'
+```
+
+## Notes
+
+- Always specify `--repo owner/repo` when not in a git directory
+- Use URLs directly: `gh pr view https://github.com/owner/repo/pull/55`
+- Rate limits apply; use `gh api --cache 1h` for repeated queries

package/skills/gog/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: gog
+description: Google Workspace CLI for Gmail, Calendar, Drive, Contacts, Sheets, and Docs.
+homepage: https://gogcli.sh
+metadata:
+  {
+    "vora":
+      {
+        "emoji": "🎮",
+        "requires": { "bins": ["gog"] },
+        "install":
+          [
+            {
+              "id": "brew",
+              "kind": "brew",
+              "formula": "steipete/tap/gogcli",
+              "bins": ["gog"],
+              "label": "Install gog (brew)",
+            },
+          ],
+      },
+  }
+---
+
+# 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):
+
+  ```bash
+  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):
+  ```bash
+  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.

package/skills/goplaces/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: goplaces
+description: Query Google Places API (New) via the goplaces CLI for text search, place details, resolve, and reviews. Use for human-friendly place lookup or JSON output for scripts.
+homepage: https://github.com/steipete/goplaces
+metadata:
+  {
+    "vora":
+      {
+        "emoji": "📍",
+        "requires": { "bins": ["goplaces"], "env": ["GOOGLE_PLACES_API_KEY"] },
+        "primaryEnv": "GOOGLE_PLACES_API_KEY",
+        "install":
+          [
+            {
+              "id": "brew",
+              "kind": "brew",
+              "formula": "steipete/tap/goplaces",
+              "bins": ["goplaces"],
+              "label": "Install goplaces (brew)",
+            },
+          ],
+      },
+  }
+---
+
+# goplaces
+
+Modern Google Places API (New) CLI. Human output by default, `--json` for scripts.
+
+Install
+
+- Homebrew: `brew install steipete/tap/goplaces`
+
+Config
+
+- `GOOGLE_PLACES_API_KEY` required.
+- Optional: `GOOGLE_PLACES_BASE_URL` for testing/proxying.
+
+Common commands
+
+- Search: `goplaces search "coffee" --open-now --min-rating 4 --limit 5`
+- Bias: `goplaces search "pizza" --lat 40.8 --lng -73.9 --radius-m 3000`
+- Pagination: `goplaces search "pizza" --page-token "NEXT_PAGE_TOKEN"`
+- Resolve: `goplaces resolve "Soho, London" --limit 5`
+- Details: `goplaces details <place_id> --reviews`
+- JSON: `goplaces search "sushi" --json`
+
+Notes
+
+- `--no-color` or `NO_COLOR` disables ANSI color.
+- Price levels: 0..4 (free → very expensive).
+- Type filter sends only the first `--type` value (API accepts one).

package/skills/healthcheck/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: healthcheck
+description: Host security hardening and risk-tolerance configuration for Vora deployments. Use when a user asks for security audits, firewall/SSH/update hardening, risk posture, exposure review, Vora cron scheduling for periodic checks, or version status checks on a machine running Vora (laptop, workstation, Pi, VPS).
+---
+
+# Vora Host Hardening
+
+## Overview
+
+Assess and harden the host running Vora, then align it to a user-defined risk tolerance without breaking access. Use Vora security tooling as a first-class signal, but treat OS hardening as a separate, explicit set of steps.
+
+## Core rules
+
+- Recommend running this skill with a state-of-the-art model (e.g., Opus 4.5, GPT 5.2+). The agent should self-check the current model and suggest switching if below that level; do not block execution.
+- Require explicit approval before any state-changing action.
+- Do not modify remote access settings without confirming how the user connects.
+- Prefer reversible, staged changes with a rollback plan.
+- Never claim Vora changes the host firewall, SSH, or OS updates; it does not.
+- If role/identity is unknown, provide recommendations only.
+- Formatting: every set of user choices must be numbered so the user can reply with a single digit.
+- System-level backups are recommended; try to verify status.
+
+## Workflow (follow in order)
+
+### 0) Model self-check (non-blocking)
+
+Before starting, check the current model. If it is below state-of-the-art (e.g., Opus 4.5, GPT 5.2+), recommend switching. Do not block execution.
+
+### 1) Establish context (read-only)
+
+Try to infer 1–5 from the environment before asking. Prefer simple, non-technical questions if you need confirmation.
+
+Determine (in order):
+
+1. OS and version (Linux/macOS/Windows), container vs host.
+2. Privilege level (root/admin vs user).
+3. Access path (local console, SSH, RDP, tailnet).
+4. Network exposure (public IP, reverse proxy, tunnel).
+5. Vora gateway status and bind address.
+6. Backup system and status (e.g., Time Machine, system images, snapshots).
+7. Deployment context (local mac app, headless gateway host, remote gateway, container/CI).
+8. Disk encryption status (FileVault/LUKS/BitLocker).
+9. OS automatic security updates status.
+   Note: these are not blocking items, but are highly recommended, especially if Vora can access sensitive data.
+10. Usage mode for a personal assistant with full access (local workstation vs headless/remote vs other).
+
+First ask once for permission to run read-only checks. If granted, run them by default and only ask questions for items you cannot infer or verify. Do not ask for information already visible in runtime or command output. Keep the permission ask as a single sentence, and list follow-up info needed as an unordered list (not numbered) unless you are presenting selectable choices.
+
+If you must ask, use non-technical prompts:
+
+- “Are you using a Mac, Windows PC, or Linux?”
+- “Are you logged in directly on the machine, or connecting from another computer?”
+- “Is this machine reachable from the public internet, or only on your home/network?”
+- “Do you have backups enabled (e.g., Time Machine), and are they current?”
+- “Is disk encryption turned on (FileVault/BitLocker/LUKS)?”
+- “Are automatic security updates enabled?”
+- “How do you use this machine?”
+  Examples:
+  - Personal machine shared with the assistant
+  - Dedicated local machine for the assistant
+  - Dedicated remote machine/server accessed remotely (always on)
+  - Something else?
+
+Only ask for the risk profile after system context is known.
+
+If the user grants read-only permission, run the OS-appropriate checks by default. If not, offer them (numbered). Examples:
+
+1. OS: `uname -a`, `sw_vers`, `cat /etc/os-release`.
+2. Listening ports:
+   - Linux: `ss -ltnup` (or `ss -ltnp` if `-u` unsupported).
+   - macOS: `lsof -nP -iTCP -sTCP:LISTEN`.
+3. Firewall status:
+   - Linux: `ufw status`, `firewall-cmd --state`, `nft list ruleset` (pick what is installed).
+   - macOS: `/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate` and `pfctl -s info`.
+4. Backups (macOS): `tmutil status` (if Time Machine is used).
+
+### 2) Run Vora security audits (read-only)
+
+As part of the default read-only checks, run `vora security audit --deep`. Only offer alternatives if the user requests them:
+
+1. `vora security audit` (faster, non-probing)
+2. `vora security audit --json` (structured output)
+
+Offer to apply Vora safe defaults (numbered):
+
+1. `vora security audit --fix`
+
+Be explicit that `--fix` only tightens Vora defaults and file permissions. It does not change host firewall, SSH, or OS update policies.
+
+If browser control is enabled, recommend that 2FA be enabled on all important accounts, with hardware keys preferred and SMS not sufficient.
+
+### 3) Check Vora version/update status (read-only)
+
+As part of the default read-only checks, run `vora update status`.
+
+Report the current channel and whether an update is available.
+
+### 4) Determine risk tolerance (after system context)
+
+Ask the user to pick or confirm a risk posture and any required open services/ports (numbered choices below).
+Do not pigeonhole into fixed profiles; if the user prefers, capture requirements instead of choosing a profile.
+Offer suggested profiles as optional defaults (numbered). Note that most users pick Home/Workstation Balanced:
+
+1. Home/Workstation Balanced (most common): firewall on with reasonable defaults, remote access restricted to LAN or tailnet.
+2. VPS Hardened: deny-by-default inbound firewall, minimal open ports, key-only SSH, no root login, automatic security updates.
+3. Developer Convenience: more local services allowed, explicit exposure warnings, still audited.
+4. Custom: user-defined constraints (services, exposure, update cadence, access methods).
+
+### 5) Produce a remediation plan
+
+Provide a plan that includes:
+
+- Target profile
+- Current posture summary
+- Gaps vs target
+- Step-by-step remediation with exact commands
+- Access-preservation strategy and rollback
+- Risks and potential lockout scenarios
+- Least-privilege notes (e.g., avoid admin usage, tighten ownership/permissions where safe)
+- Credential hygiene notes (location of Vora creds, prefer disk encryption)
+
+Always show the plan before any changes.
+
+### 6) Offer execution options
+
+Offer one of these choices (numbered so users can reply with a single digit):
+
+1. Do it for me (guided, step-by-step approvals)
+2. Show plan only
+3. Fix only critical issues
+4. Export commands for later
+
+### 7) Execute with confirmations
+
+For each step:
+
+- Show the exact command
+- Explain impact and rollback
+- Confirm access will remain available
+- Stop on unexpected output and ask for guidance
+
+### 8) Verify and report
+
+Re-check:
+
+- Firewall status
+- Listening ports
+- Remote access still works
+- Vora security audit (re-run)
+
+Deliver a final posture report and note any deferred items.
+
+## Required confirmations (always)
+
+Require explicit approval for:
+
+- Firewall rule changes
+- Opening/closing ports
+- SSH/RDP configuration changes
+- Installing/removing packages
+- Enabling/disabling services
+- User/group modifications
+- Scheduling tasks or startup persistence
+- Update policy changes
+- Access to sensitive files or credentials
+
+If unsure, ask.
+
+## Periodic checks
+
+After Vora install or first hardening pass, run at least one baseline audit and version check:
+
+- `vora security audit`
+- `vora security audit --deep`
+- `vora update status`
+
+Ongoing monitoring is recommended. Use the Vora cron tool/CLI to schedule periodic audits (Gateway scheduler). Do not create scheduled tasks without explicit approval. Store outputs in a user-approved location and avoid secrets in logs.
+When scheduling headless cron runs, include a note in the output that instructs the user to call `healthcheck` so issues can be fixed.
+
+### Required prompt to schedule (always)
+
+After any audit or hardening pass, explicitly offer scheduling and require a direct response. Use a short prompt like (numbered):
+
+1. “Do you want me to schedule periodic audits (e.g., daily/weekly) via `vora cron add`?”
+
+If the user says yes, ask for:
+
+- cadence (daily/weekly), preferred time window, and output location
+- whether to also schedule `vora update status`
+
+Use a stable cron job name so updates are deterministic. Prefer exact names:
+
+- `healthcheck:security-audit`
+- `healthcheck:update-status`
+
+Before creating, `vora cron list` and match on exact `name`. If found, `vora cron edit <id> ...`.
+If not found, `vora cron add --name <name> ...`.
+
+Also offer a periodic version check so the user can decide when to update (numbered):
+
+1. `vora update status` (preferred for source checkouts and channels)
+2. `npm view vora version` (published npm version)
+
+## Vora command accuracy
+
+Use only supported commands and flags:
+
+- `vora security audit [--deep] [--fix] [--json]`
+- `vora status` / `vora status --deep`
+- `vora health --json`
+- `vora update status`
+- `vora cron add|list|runs|run`
+
+Do not invent CLI flags or imply Vora enforces host firewall/SSH policies.
+
+## Logging and audit trail
+
+Record:
+
+- Gateway identity and role
+- Plan ID and timestamp
+- Approved steps and exact commands
+- Exit codes and files modified (best effort)
+
+Redact secrets. Never log tokens or full credential contents.
+
+## Memory writes (conditional)
+
+Only write to memory files when the user explicitly opts in and the session is a private/local workspace
+(per `docs/reference/templates/AGENTS.md`). Otherwise provide a redacted, paste-ready summary the user can
+decide to save elsewhere.
+
+Follow the durable-memory prompt format used by Vora compaction:
+
+- Write lasting notes to `memory/YYYY-MM-DD.md`.
+
+After each audit/hardening run, if opted-in, append a short, dated summary to `memory/YYYY-MM-DD.md`
+(what was checked, key findings, actions taken, any scheduled cron jobs, key decisions,
+and all commands executed). Append-only: never overwrite existing entries.
+Redact sensitive host details (usernames, hostnames, IPs, serials, service names, tokens).
+If there are durable preferences or decisions (risk posture, allowed ports, update policy),
+also update `MEMORY.md` (long-term memory is optional and only used in private sessions).
+
+If the session cannot write to the workspace, ask for permission or provide exact entries
+the user can paste into the memory files.