opencode-skills-collection 3.1.14 → 3.1.16

package/bundled-skills/workorai/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: workorai
+description: "WorkorAI talent-marketplace skill: candidates search jobs and manage applications; employers run the job lifecycle and get ranked candidate matches with white-box fit explanations."
+category: productivity
+risk: critical
+source: community
+source_repo: work0r-ai/agent-kit
+source_type: community
+date_added: "2026-07-03"
+author: work0r-ai
+tags: [job-search, hiring, recruiting, talent-marketplace, mcp]
+tools: [claude, cursor, gemini]
+license: "MIT"
+license_source: "https://github.com/work0r-ai/agent-kit/blob/main/skills/workorai/LICENSE.txt"
+---
+
+# WorkorAI
+
+## Overview
+
+WorkorAI is a talent marketplace exposed to agents through an MCP server
+(streamable HTTP at https://workorai.com/mcp, listed on the official MCP
+Registry as `io.github.work0r-ai/workorai`). This skill routes requests by
+intent across the dual-role tool surface: 9 `candidate.*` tools (job search,
+job detail, applications, apply, invitations, saved jobs) and the
+`employer.*` tools (job lifecycle, candidate discovery, invitations,
+applicant review). Employer candidate discovery returns tiered rankings
+(best/good/weak) with a white-box match explanation per candidate — fit
+score, skills proven in interview, gaps, and a quotable rationale — instead
+of a black-box score.
+
+## When to Use This Skill
+
+- Use when a user asks to find a job, search vacancies, apply to a position,
+  or track their applications ("find me a job", "ищу работу").
+- Use when an employer wants to post, publish, update, close, or archive a
+  job on WorkorAI.
+- Use when an employer asks to find, rank, compare, or evaluate candidates,
+  or asks why a candidate matches a role.
+- Use when a user needs to set up or troubleshoot the WorkorAI MCP
+  connection and API key onboarding.
+
+## How It Works
+
+### Step 1: Connect the MCP server
+
+Add the WorkorAI MCP server to your agent's MCP configuration. For Claude
+Code:
+
+```bash
+claude mcp add --transport http workorai https://workorai.com/mcp
+```
+
+If the user has no API key yet, call the `request_access` tool and follow
+the onboarding it returns.
+
+### Step 2: Route by role and intent
+
+Detect whether the request is a candidate flow or an employer flow, then use
+the matching tool group:
+
+- Candidate: `candidate.search_jobs`, `candidate.get_job`,
+  `candidate.apply_to_job`, `candidate.get_applications`,
+  `candidate.accept_invitation` / `candidate.decline_invitation`,
+  `candidate.withdraw_application`, `candidate.set_saved_job`,
+  `candidate.get_saved_jobs`.
+- Employer: `employer.create_job` → `employer.publish_job` →
+  `employer.close_job` / `employer.archive_job` for the lifecycle;
+  `employer.search_candidates_for_job` or
+  `employer.search_candidates_by_query` for discovery;
+  `employer.invite_candidate`, `employer.list_applicants`,
+  `employer.get_applicant_detail`, `employer.set_review_status` for
+  pipeline work.
+
+### Step 3: Explain matches with white-box data
+
+When presenting employer search results, keep the tier structure
+(best/good/weak) and surface each candidate's `matchExplanation`: fit score,
+interview-proven skills, gaps, and rationale. For deeper comparison, fetch
+per-candidate interview evidence with `employer.get_candidate_evidence` and
+`employer.get_applicant_transcript`.
+
+## Examples
+
+### Example 1: Candidate job search
+
+```
+User: "Find me remote TypeScript jobs and apply to the best one."
+Agent: candidate.search_jobs(query="TypeScript", remote=true)
+       → present ranked results → candidate.get_job(id)
+       → confirm with the user → candidate.apply_to_job(id)
+```
+
+### Example 2: Employer candidate discovery
+
+```
+User: "Who are the best candidates for my Senior Backend role?"
+Agent: employer.search_candidates_for_job(jobId)
+       → report Best tier with each candidate's fit score, proven
+         skills, and gaps → employer.invite_candidate on approval
+```
+
+## Best Practices
+
+- ✅ Confirm with the user before applying, inviting, or changing job
+  status — these are visible, stateful marketplace actions.
+- ✅ Quote the white-box match explanation when recommending a candidate,
+  so the employer sees why, not just a score.
+- ✅ Use `request_access` for key onboarding instead of asking users to
+  paste credentials into chat.
+- ❌ Don't fabricate fit scores or ranks — only report what the tools
+  return.
+- ❌ Don't apply to jobs or send invitations in bulk without explicit
+  user approval.
+
+## Limitations
+
+- Requires a WorkorAI account and API key; tools fail without a valid key.
+- This skill does not replace environment-specific validation, testing, or
+  expert review.
+- Stop and ask for clarification if required inputs, permissions, or safety
+  boundaries are missing.
+
+## Security & Safety Notes
+
+- All operations go through the remote WorkorAI MCP server over HTTPS; the
+  skill itself runs no shell commands.
+- Mutating tools (apply, withdraw, invite, publish, close, delete) should
+  be preceded by an explicit user confirmation.
+- Treat API keys as secrets: store them in MCP client configuration, never
+  in chat transcripts or committed files.
+
+## Additional Resources
+
+- [Source repository](https://github.com/work0r-ai/agent-kit) — full skill
+  with reference files and agents (npm: `@workorai/agent-kit`)
+- [WorkorAI MCP endpoint](https://workorai.com/mcp)

package/bundled-skills/wp-site-health-auditor/SKILL.md

@@ -0,0 +1,341 @@
+---
+name: wp-site-health-auditor
+description: "Turns a WordPress Site Health report into a risk-tiered, backup-first fix plan with exact WP-CLI/PHP snippets. Use for site health, recommended improvements, or critical issue reports."
+category: development
+risk: critical
+source: self
+source_type: self
+date_added: "2026-07-03"
+author: whoisabhishekadhikari
+tags: [wordpress, site-health, wp-cli, seo, performance, security, hardening]
+tools: [claude, cursor, codex, gemini]
+---
+
+# WP Site Health Auditor
+
+## When to Use This Skill
+
+- The user pastes a WordPress Site Health report (`Tools > Site Health`), as text or screenshot
+- The user pastes raw Site Health debug info (`Tools > Site Health > Info`) and asks what's wrong
+- The user mentions "site health", "recommended improvements," or "critical issues" for a WordPress site
+- The user asks to clean up, harden, or speed up a WP install based on that screen
+
+Turns a WordPress Site Health report (Critical issues / Recommended improvements / Passed tests) into a
+prioritized, risk-tiered fix plan — then executes the safe fixes and hands off the rest with exact
+commands or code.
+
+## ⚠️ Safety — read before touching any file
+
+This skill edits `wp-config.php`, `.htaccess`, and `php.ini`-equivalent settings, and deletes plugins and
+themes. All three are one bad edit away from a white-screen-of-death or a broken upload path. **Never skip
+this section, even for a one-line change, even if the user is in a hurry.**
+
+**Before any edit or deletion, in this order:**
+1. **Back up the specific file(s) you're about to touch outside the web root**, not just "have a backup somewhere":
+   ```
+   umask 077
+   backup_dir="../wp-site-health-backups/$(date +%Y%m%d-%H%M%S)"
+   mkdir -p "$backup_dir"
+   cp -p wp-config.php "$backup_dir/wp-config.php"
+   cp -p .htaccess "$backup_dir/.htaccess"
+   ```
+   If shell access isn't available, tell the user to download the current file via SFTP/host file
+   manager first, and don't proceed until they confirm they have it.
+2. **Confirm a full site/database backup exists** before deleting any plugin or theme, or running
+   `wp search-replace`. If the user doesn't have one and has a backup plugin active (UpdraftPlus, etc.),
+   trigger a backup first: `wp updraftplus backup` or the plugin's own WP-CLI command, or tell them to
+   click "Backup Now" and wait for confirmation before continuing.
+3. **Never run `wp search-replace` without `--dry-run` first**, and always show the dry-run output to the
+   user before running it for real. This command rewrites the database in place — a wrong pattern can
+   corrupt serialized data across every table it touches.
+4. **After any PHP file edit, lint it before reloading the site**:
+   ```
+   php -l wp-config.php
+   ```
+   For `.htaccess` changes, run `apachectl configtest` if available, or check the site immediately.
+   A syntax error in `wp-config.php` takes the entire site down immediately. Do not skip the lint check to
+   save a step.
+5. **Change one thing at a time, then verify the site still loads** (homepage + wp-admin) before making
+   the next change. Don't batch multiple Tier 2 file edits into one pass — if something breaks, you want to
+   know which change did it.
+6. **Give the user the exact rollback command** alongside every edit:
+   ```
+   cp ../wp-site-health-backups/<timestamp>/wp-config.php wp-config.php
+   ```
+   State this even if nothing goes wrong — it costs one line and saves a panicked user later.
+
+If the user says "just do it, skip the backup" — still create the backup silently as part of the edit
+sequence and tell them you did. Refuse to skip step 1 or step 4 entirely; those two are non-negotiable
+regardless of urgency, since the failure mode (corrupted `wp-config.php`, dead site) is worse than the ten
+seconds a backup costs.
+
+## Overview
+
+The Site Health screen is diagnostic, not prescriptive. It tells the site owner *that* something is wrong
+(e.g. "you should use a persistent object cache") but not *how* to fix it, and it mixes items that are
+one-click-safe (deactivate a plugin) with items that require host-level changes (php.ini, object cache
+backend) or are purely informational (SQL server version — no action needed). This skill sorts that out —
+safely.
+
+## Phase 1 — Parse the report
+
+Input is usually one of:
+- Pasted plain text copied from `Tools > Site Health` (Status tab)
+- Pasted plain text from `Tools > Site Health > Info` (the debug data export)
+- A screenshot of the Status tab
+- WP-CLI output (`wp site-health check` is not a core command; note that up front, don't invent one — see Phase 4)
+
+Extract three buckets exactly as WordPress labels them:
+1. **Critical issues** (red) — always fix first, always confirm before touching.
+2. **Recommended improvements** (yellow) — the bulk of real work; triage by risk tier below.
+3. **Passed tests** (green) — skip. Do not "fix" or re-verify passed tests unless the user asks. Do not
+   invent problems with green items — a common failure mode is treating "SQL server is up to date" as
+   something to act on. It isn't.
+
+If the report is a screenshot, transcribe item titles + category tags (Security/Performance/SEO/Privacy)
+verbatim before triaging — don't paraphrase the WordPress-generated title, it's used for the fix lookup in
+Phase 3.
+
+If no report was pasted and the user just says "audit my site health," ask them to paste the Status tab
+text (fastest) rather than guessing — Site Health results are host- and config-specific and guessing wastes
+a turn.
+
+## Phase 2 — Risk-tiered triage
+
+Classify every non-passed item into one of three tiers before touching anything. Present this triage table
+to the user first for anything above Tier 1 count of 3+ items — don't silently start deactivating plugins.
+
+**Tier 1 — Safe, reversible, auto-fixable in wp-admin or via WP-CLI**
+No data loss risk, no downtime, fully reversible. Still back up per the Safety section before deleting
+anything. Fix directly once the user confirms the item list.
+- Remove inactive plugins/themes (they aren't running, deactivation already happened — this is just
+  deletion of dead code)
+- Turn off `WP_DEBUG` display in production (`WP_DEBUG_DISPLAY`, not `WP_DEBUG` itself if the user still
+  wants logging)
+- Enable search engine indexing / fix robots visibility toggle
+- Update the site tagline off "Just another WordPress site"
+
+**Tier 2 — Requires host/server-level access — Claude drafts the change, user or host applies it**
+Cannot be fixed purely from wp-admin; needs php.ini, .htaccess, wp-config.php, or hosting panel access.
+Draft the exact snippet, explain where it goes, remind the user of the backup + lint steps above, and flag
+that a server restart or host support ticket may be needed.
+- Permalink structure change (migration — existing URLs break without redirects; require a redirect plan and CDN/cache flush before applying)
+- `post_max_size` < `upload_max_filesize` mismatch
+- Persistent object cache not available (Redis/Memcached)
+- Page cache not detected
+- PHP version/module changes
+- HTTPS/SSL configuration
+- Loopback/REST API failures caused by firewall or security plugin blocking
+
+**Tier 3 — Informational / host-dependent, no fix exists or none needed**
+Report as informational only. Do not attempt a fix, do not suggest one unless directly asked.
+- SQL server version notices when already current
+- "Autoloaded options are acceptable" type passed-adjacent info
+- Anything already green in Passed tests
+
+## Phase 3 — Fix recipes by item
+
+Match the WordPress-generated item title (case-insensitive substring match is fine) to a recipe below.
+Every recipe below assumes the Safety section has already been followed for that file. If an item doesn't
+match anything here, say so explicitly rather than fabricating a fix — Site Health's item set changes
+across WP core versions and this list isn't exhaustive (see `references/catalog.md` for the fuller list
+including rarer items).
+
+### You should remove inactive plugins / themes — Tier 1
+```
+# confirm full site backup exists first (Safety step 2)
+wp plugin list --status=inactive --field=name
+wp plugin delete <plugin-slug>
+
+wp theme list --status=inactive --field=name
+wp theme delete <theme-slug>
+```
+Never delete the currently active theme's parent if the active theme is a child theme. Never delete
+Twenty Twenty-Five (or the current default core theme) if it's the only fallback theme — WordPress needs
+at least one broken-theme fallback; recommend keeping one bundled default even if inactive.
+Confirm the exact plugin/theme names with the user before deleting — inactive isn't the same as unused;
+some plugins are intentionally kept inactive as a staged rollback.
+
+### post_max_size smaller than upload_max_filesize — Tier 2
+This breaks large file uploads (post data gets truncated before the file size limit is even reached).
+Fix by raising `post_max_size` to be >= `upload_max_filesize`, typically with headroom for form overhead.
+
+Where to set it (pick whichever the host supports, in this order of preference):
+1. Host control panel PHP settings (cPanel "Select PHP Version" > Options, Plesk, etc.) — no code needed,
+   safest option, skip the file-backup steps entirely.
+2. `php.ini` (if the user has server access) — back up first (`cp php.ini php.ini.bak-<timestamp>`):
+   ```ini
+   upload_max_filesize = 64M
+   post_max_size = 128M
+   ```
+3. `.htaccess` (Apache + mod_php only, not on PHP-FPM/nginx) — back up first:
+   ```apache
+   php_value upload_max_filesize 64M
+   php_value post_max_size 128M
+   ```
+   A malformed `.htaccess` directive can 500 the entire site. Run `apachectl configtest` if available
+   before reloading, or check the live site immediately after saving.
+4. `.user.ini` (CGI/FastCGI hosts; not mod_php) — back up first, create or edit `.user.ini`
+   in the WordPress root:
+   ```ini
+   upload_max_filesize = 64M
+   post_max_size = 128M
+   ```
+   ⚠️ **Do not use `ini_set()` in `wp-config.php` for these directives** — `upload_max_filesize`
+   and `post_max_size` are `PHP_INI_PERDIR`, which means they can only be set before the
+   request starts (php.ini, .htaccess, .user.ini). `ini_set()` calls silently fail for both,
+   leaving the problem unfixed.
+
+Always set `post_max_size` strictly greater than `upload_max_filesize`. Confirm the current values first
+(`wp cli info` doesn't show these — check `phpinfo()` or the host panel) rather than assuming defaults.
+
+### You should use a persistent object cache — Tier 2
+Requires a caching backend (Redis or Memcached) installed at the server level — this is not something a
+plugin alone can create out of nothing.
+1. Confirm with the user's host whether Redis or Memcached is available (many managed WP hosts include one).
+2. If available, install a drop-in client plugin: Redis Object Cache or WP Redis (Redis), or Memcached
+   Object Cache (Memcached). `wp plugin install redis-cache --activate` then `wp redis enable`. This writes
+   an `object-cache.php` drop-in to `wp-content/` — confirm no existing `object-cache.php` is being
+   overwritten (check first with `ls wp-content/object-cache.php`); if one exists, back it up before enabling.
+3. If not available, this is a hosting-tier limitation — report it as such rather than trying to fake a
+   fix; don't recommend switching hosts unprompted, just flag it as the blocker.
+
+### Page cache is not detected — Tier 2
+1. Check if the host provides server-level page caching (many managed WP hosts do, and it may already be
+   active but not reporting the headers Site Health looks for — worth confirming with the host before
+   installing a redundant plugin).
+2. If not, install one page-cache plugin (not a full plugin stack) — WP Super Cache, W3 Total Cache, or
+   the host-recommended one. `wp plugin install wp-super-cache --activate` then enable caching from its
+   settings screen (no reliable WP-CLI toggle across cache plugins — flag manual step to user).
+3. Avoid stacking two caching plugins; if one is already active but not detected, check the plugin's own
+   status page before adding another. Some cache plugins also write rules into `.htaccess` — back it up
+   first per the Safety section before activating.
+
+### Your site is not set to output debug information — usually already passing; if failing — Tier 1
+Back up `wp-config.php` first, lint after editing:
+```php
+// wp-config.php
+define( 'WP_DEBUG', false );         // set to true only while actively debugging
+define( 'WP_DEBUG_DISPLAY', false ); // never show errors to visitors
+define( 'WP_DEBUG_LOG', true );      // logs to wp-content/debug.log instead
+```
+
+### REST API / loopback requests / background updates failing — Tier 2
+Usually a security plugin, firewall, or `.htaccess` rule blocking internal requests. Steps:
+1. Temporarily deactivate security/firewall plugins one at a time, re-check Site Health after each.
+2. Check hosting-level firewall (Cloudflare, Sucuri, host WAF) isn't blocking the site from calling itself.
+3. Verify `wp-config.php` doesn't have `define('DISALLOW_FILE_MODS', true)` set incorrectly for background
+   updates specifically, if that's the failing item. Back up before removing/editing that line.
+
+### HTTPS not fully active — Tier 2
+```
+wp option get siteurl
+wp option get home
+```
+Both must be `https://`. Also check for mixed-content (http:// hardcoded in content/theme). Confirm a full
+database backup exists, then dry-run before applying for real:
+```
+wp search-replace 'http://olddomain.com' 'https://olddomain.com' --dry-run
+```
+Only remove `--dry-run` after the user has reviewed the dry-run output and confirmed the replacement count
+and matched rows look correct.
+
+## Phase 4 — What NOT to invent
+
+- There is no `wp site-health` WP-CLI command in WordPress core as of this writing — don't fabricate one.
+  Fixes are applied via the specific commands above, not a single audit-and-fix CLI call.
+- Don't claim a fix is complete without the user (or a re-run of Site Health) confirming it — server-level
+  changes (Tier 2) especially can silently fail to apply depending on host restrictions.
+- Don't guess PHP/server values (current `upload_max_filesize`, cache backend availability, etc.) — ask or
+  have the user check `phpinfo()` / host panel rather than assuming common defaults are in place.
+- Don't skip or shortcut the Safety section for any reason, including "it's a small change" — file
+  corruption risk doesn't scale with edit size; a single dropped semicolon in `wp-config.php` is as fatal
+  as a large edit.
+
+## Phase 5 — Output format
+
+Give the user:
+1. **Triage table**: item | category | tier | one-line fix summary
+2. **Tier 1 fixes**: execute directly (with confirmation + backup for deletions), show before/after
+3. **Tier 2 fixes**: exact snippet + exactly where it goes + backup command + lint/verify command + rollback
+   command + note that a host restart or support ticket may be required; don't mark these "done" until the
+   user confirms the site still loads
+4. **Tier 3 / unrecognized items**: one line each, informational only
+5. Recommend re-running Site Health after Tier 1/2 changes to confirm the yellow items clear.
+
+Keep the whole response scannable — this is a punch list, not an essay. Use the table + short recipe
+blocks above, not prose paragraphs, unless the user asks for more explanation on a specific item.
+
+## Examples
+
+### Example: Site Health reports "You should use a persistent object cache"
+
+1. Triage → Tier 2 (requires Redis/Memcached at server level)
+2. Ask the user to check with their host whether Redis is available
+3. If yes, run:
+   ```
+   wp plugin install redis-cache --activate
+   wp redis enable
+   ```
+4. Verify: `ls wp-content/object-cache.php` exists
+5. Re-run Site Health to confirm the item clears
+
+### Example: Site Health reports "Your site is not set to output debug information"
+
+1. Triage → Tier 1 (safe, reversible via wp-config.php)
+2. Back up `wp-config.php`:
+   ```
+   umask 077
+   backup_dir="../wp-site-health-backups/$(date +%Y%m%d-%H%M%S)"
+   mkdir -p "$backup_dir"
+   cp -p wp-config.php "$backup_dir/wp-config.php"
+   ```
+3. Edit and lint:
+   ```php
+   define( 'WP_DEBUG', false );
+   define( 'WP_DEBUG_DISPLAY', false );
+   ```
+4. Verify `php -l wp-config.php` passes
+5. Confirm the site homepage + wp-admin still load
+
+## Best Practices
+
+- ✅ Back up the specific file before every edit — `cp` takes seconds, restoring a dead site takes hours
+- ✅ Change one thing at a time and verify the site loads between each change
+- ✅ Always run `php -l` after editing `wp-config.php` before reloading the site
+- ✅ Run `wp search-replace` with `--dry-run` first and show the output to the user
+- ❌ Never batch multiple Tier-2 file edits into one pass — you won't know which change broke the site
+- ❌ Never skip the backup step, even for a one-line comment change
+
+## Reference
+
+`references/catalog.md` — extended list of less-common Site Health items (SEO category items like llms.txt
+generation, Privacy items, rarer Security items) with the same tier classification, for reports that
+include items not covered above.
+
+## Common Pitfalls
+
+- **Treating every yellow item as actionable** — Some recommended improvements (e.g. persistent object cache) are host-level and may not be fixable. Always triage by tier before acting.
+- **Changing permalinks without a redirect plan** — Flipping to "Post name" on an indexed site breaks every existing URL. Always plan 301 redirects first.
+- **Using `ini_set()` for upload limits** — `upload_max_filesize` and `post_max_size` are `PHP_INI_PERDIR`; `ini_set()` silently fails. Use `php.ini`, `.htaccess`, or `.user.ini` instead.
+- **Skipping the dry-run on `wp search-replace`** — A wrong pattern can corrupt serialized data. Never run it without `--dry-run` first.
+- **Installing two caching plugins** — Stacking page cache plugins causes conflicts and obscure bugs. If one is already active but not detected, debug it rather than adding another.
+
+## Limitations
+
+- Cannot execute anything itself against a live site — every WP-CLI/PHP snippet is drafted for the user or
+  their host to run; this skill has no shell access to the user's actual server.
+- Cannot verify current PHP/server values (upload limits, cache backend availability, HTTPS status) —
+  relies on what the user reports back after checking `phpinfo()` or their host panel.
+- Does not cover multisite-specific Site Health variations or WooCommerce-specific health checks; both add
+  extra items this skill's recipe list doesn't include.
+- The item catalog (main file + `references/catalog.md`) reflects WordPress core's Site Health checks as of
+  mid-2026 — item titles/wording can change across core versions, so an unmatched item should be reported
+  as unmatched, not force-fit to the closest recipe.
+- Does not replace a full security audit or compromise scan — Site Health flags configuration hygiene
+  issues, not signs that a site has already been broken into.
+
+## Related Skills
+
+- `@security-hardening` — For deeper WordPress security audits beyond Site Health's surface checks
+- `@wp-performance` — For targeted performance optimization after Site Health flags are resolved

package/bundled-skills/wp-site-health-auditor/references/catalog.md

@@ -0,0 +1,135 @@
+# WP Site Health item catalog
+
+Extended list of less-common WordPress Site Health items, organized by
+category. Items in the main `SKILL.md` recipe list are NOT duplicated here.
+
+## Security
+
+### Passwords need updating — Tier 1
+Users with weak or reused passwords. Inform the admin, list affected users:
+```
+wp user list --field=user_login | while read u; do echo "$u: $(wp user meta get "$u" session_tokens | wc -c)"; done
+```
+No automated fix — the admin must ask each user to update via
+`wp user reset-password <user>` or Users > Profile.
+
+### The site is not using a persistent connection (not an object cache) — Tier 3
+Persistent database connections (`mysqli.persist`). Purely informational;
+most shared hosts disable this and there is no performance downside for
+standard WP installs. No action needed.
+
+### File permissions should be reviewed — Tier 2
+`wp-config.php` and `/wp-content/` directory permissions. Do not recursively
+chmod the whole web root, because it may contain host-managed files or private
+backup material. Draft the expected permissions for the WordPress-owned paths:
+```bash
+chmod 600 wp-config.php
+find wp-content -type d -exec chmod 755 {} +
+find wp-content -type f -exec chmod 644 {} +
+chmod 400 .htaccess # if Apache; nginx ignores it
+```
+The user must verify with their host that the filesystem supports these
+permissions (some managed WP hosts lock permissions).
+
+## Performance
+
+### Indexed autoloaded options found — Tier 2
+Autoloaded options larger than 1 MB. List the worst offenders:
+```
+SELECT option_name, LENGTH(option_value) AS size
+FROM wp_options
+WHERE autoload = 'yes'
+ORDER BY size DESC
+LIMIT 20;
+```
+If a plugin is the source, report the plugin name. Cleaning involves:
+- `wp option delete <key>` (only if the option is safe to delete — confirm
+  with the plugin author first).
+- Disabling autoload: `wp option update <key> <value> --autoload=no`.
+
+### Can not process scheduled maintenance jobs (wp_cron) — Tier 2
+`DISABLE_WP_CRON` is set but no system cron is running. Fix by either:
+1. Setting up a real system cron job (recommended):
+   ```
+   * * * * * wget -q -O - https://example.com/wp-cron.php
+   ```
+2. Removing `define('DISABLE_WP_CRON', true);` from `wp-config.php`
+
+### Background updates failed — Tier 2
+Automatic background updates for core/plugins/themes. Check:
+```
+wp core check-update
+wp plugin list --update=available
+```
+If `DISALLOW_FILE_MODS` is true, background updates are blocked. Only
+override if the user explicitly wants auto-updates:
+```php
+define('DISALLOW_FILE_MODS', false); // wp-config.php
+```
+
+## SEO
+
+### llms.txt generation not configured — Tier 1
+The site is missing an `llms.txt` file at the domain root. Install and
+activate an SEO plugin that supports it, or create a manual file via
+wp-admin > SEO > Settings. Not a ranking factor, but recommended for
+AI crawler discoverability.
+
+### No XML sitemap detected — Tier 1
+Install an SEO plugin with sitemap support (Yoast, Rank Math, etc.) or
+a dedicated sitemap plugin. Enable sitemap generation from the plugin
+settings screen (no WP-CLI toggle reliably available across plugins).
+
+### Social preview images missing — Tier 2
+Open Graph / Twitter Card meta tags not set. Requires theme integration
+or an SEO plugin. Draft the OG meta tags if the theme uses `wp_head()`:
+```php
+add_action('wp_head', function () {
+    if (has_post_thumbnail()) {
+        echo '<meta property="og:image" content="' . esc_url(get_the_post_thumbnail_url()) . '" />';
+    }
+});
+```
+
+## Privacy
+
+### Privacy policy page not set — Tier 1
+The site has no privacy policy page. Create one:
+```
+wp post create --post_type=page --post_title="Privacy Policy" --post_status=draft
+```
+Then set it under Settings > Privacy or via:
+```
+wp option update wp_page_for_privacy_policy <page-id>
+```
+
+### Privacy policy page is outdated — Tier 2
+The privacy policy page was created before the site's current privacy
+guidance generation date. Re-run the guidance generator in
+Tools > Export Personal Data and update the page content. No WP-CLI
+command for this — manual step.
+
+## Diagnostics / hard-to-classify
+
+### Requirement mis-match with Xdebug extension — Tier 3
+Xdebug is loaded but is not required for production. If the user didn't
+intentionally install it, suggest removal via host panel or php.ini:
+```
+; php.ini
+; zend_extension=xdebug.so  (comment out or remove)
+```
+
+### ZipArchive / gzinflate / BCMath / Imagick missing — Tier 2
+Missing PHP extensions that some plugins or WordPress itself need.
+List missing extensions and suggest installation via host panel or:
+```
+sudo apt install php-zip php-gd php-bcmath php-imagick
+```
+(Command varies by OS — draft the correct one for the user's environment.)
+
+## Items deliberately excluded from this catalog
+
+- **SQL Server version** — WP core already reports this as Passed or
+  Informational; no user action exists.
+- **Active theme up to date** — Already green in Site Health; no action.
+- **Plugin updates available** — Handled by `wp plugin update --all`.

package/bundled-skills/writing-skills/render-graphs.js

@@ -16,10 +16,21 @@
 const fs = require('fs');
 const path = require('path');
 const { execSync } = require('child_process');
+const sanitizeFilename = require('sanitize-filename');
+
+function sanitizePathSegments(pathValue) {
+  return String(pathValue ?? '').split(/[\\/]+/).filter(Boolean).map((segment) => {
+    const sanitized = sanitizeFilename(segment);
+    if (sanitized !== segment || !sanitized) {
+      throw new Error(`Unsafe path segment: ${segment}`);
+    }
+    return sanitized;
+  });
+}
 
 function safeJoin(base, ...parts) {
   const root = path.resolve(base);
-  const target = path.resolve(root, ...parts);
+  const target = path.resolve(root, ...parts.flatMap(sanitizePathSegments));
   const rel = path.relative(root, target);
   if (rel.startsWith('..') || path.isAbsolute(rel)) {
     throw new Error(`Path escapes skill directory: ${parts.join('/')}`);
@@ -123,7 +134,7 @@ function main() {
     process.exit(1);
   }
 
-  const skillDir = path.resolve(skillDirArg);
+  const skillDir = safeJoin(process.cwd(), skillDirArg);
   const skillFile = safeJoin(skillDir, 'SKILL.md');
   const skillName = path.basename(skillDir).replace(/-/g, '_');
 

package/bundled-skills/x-twitter-scraper/SKILL.md

@@ -84,7 +84,9 @@ Use TweetClaw when the agent should search tweets, post tweets, post replies, se
 3. Set it as an environment variable or pass it directly
 
 ```bash
-export XQUIK_API_KEY="xq_YOUR_KEY_HERE"
+read -rsp "X API key: " XQUIK_API_KEY
+echo
+export XQUIK_API_KEY
 ```
 
 ## Capabilities