opencode-skills-collection 3.1.14 → 3.1.16

package/bundled-skills/drizzle-migration-conflict/scripts/check_drizzle_migrations.py

@@ -20,6 +20,19 @@ import re
 import sys
 from dataclasses import asdict, dataclass
 from pathlib import Path
+
+
+def safe_user_path(path_value, base_dir="."):
+    """Resolve a CLI path under the current workspace."""
+    if base_dir != ".":
+        raise ValueError("Custom base directories are not supported for CLI paths")
+    base_path = Path.cwd().resolve()
+    resolved_path = Path(path_value).expanduser().resolve()
+    try:
+        resolved_path.relative_to(base_path)
+    except ValueError as exc:
+        raise ValueError(f"Path escapes allowed directory: {path_value}") from exc
+    return resolved_path
 from typing import Any, Iterable
 
 CONFIG_NAME_PATTERN = re.compile(r"^drizzle(?:[.-].+)?\.config\.(?:ts|js|mjs|cjs|mts|cts)$")
@@ -169,15 +182,14 @@ def iter_config_files(
     if explicit_configs:
         return configs, issues
 
-    for current_root, dirnames, filenames in os.walk(root):
-        dirnames[:] = [name for name in dirnames if name not in SKIP_DIR_NAMES]
-        base = Path(current_root)
-        for filename in filenames:
-            if CONFIG_NAME_PATTERN.match(filename):
-                path = (base / filename).resolve()
-                if path not in seen:
-                    seen.add(path)
-                    configs.append(path)
+    for path in safe_user_path(root).rglob("*"):
+        if not path.is_file() or any(part in SKIP_DIR_NAMES for part in path.parts):
+            continue
+        if CONFIG_NAME_PATTERN.match(path.name):
+            resolved = path.resolve()
+            if resolved not in seen:
+                seen.add(resolved)
+                configs.append(resolved)
     return configs, issues
 
 
@@ -283,13 +295,11 @@ def discover_dirs(args: argparse.Namespace, root: Path) -> tuple[list[Path], lis
 
 
 def iter_text_files(directory: Path) -> Iterable[Path]:
-    for current_root, dirnames, filenames in os.walk(directory):
-        dirnames[:] = [name for name in dirnames if name not in SKIP_DIR_NAMES]
-        base = Path(current_root)
-        for filename in filenames:
-            path = base / filename
-            if path.suffix in TEXT_SUFFIXES:
-                yield path
+    for path in safe_user_path(directory).rglob("*"):
+        if not path.is_file() or any(part in SKIP_DIR_NAMES for part in path.parts):
+            continue
+        if path.suffix in TEXT_SUFFIXES:
+            yield path
 
 
 def has_conflict_markers(path: Path) -> bool:
@@ -696,7 +706,7 @@ def report_as_text(root: Path, reports: list[DirectoryReport]) -> str:
 
 def main() -> int:
     args = parse_args()
-    root = Path(args.root).resolve()
+    root = safe_user_path(args.root).resolve()
     dirs, discovery_issues = discover_dirs(args, root)
     reports: list[DirectoryReport] = []
     if discovery_issues:

package/bundled-skills/ecl-harness-engineer/agents/creator-config.md

@@ -41,7 +41,7 @@ The runtime ecosystem contract. Describes what the application needs to run.
     }
   ],
   "services": [
-    {"type": "redis", "env_vars": {"REDIS_URL": "redis://localhost:6379"}}
+    {"type": "redis", "env_vars": {"REDIS_URL": "redis://:${HARNESS_REDIS_PASSWORD}@localhost:6379"}}
   ],
   "secrets": [
     {"name": "JWT_SECRET", "description": "JWT signing key", "test_value": "test-secret-do-not-use-in-prod"}
@@ -95,11 +95,24 @@ Start external dependencies (DB, Redis, etc.):
 ```bash
 #!/bin/bash
 set -euo pipefail
+umask 077
+
+mkdir -p harness/.runtime
+HARNESS_ENV_FILE="${HARNESS_ENV_FILE:-harness/.runtime/env}"
+if [ ! -f "$HARNESS_ENV_FILE" ]; then
+  HARNESS_POSTGRES_PASSWORD="$(openssl rand -hex 24)"
+  HARNESS_REDIS_PASSWORD="$(openssl rand -hex 24)"
+  {
+    printf 'HARNESS_POSTGRES_PASSWORD=%s\n' "$HARNESS_POSTGRES_PASSWORD"
+    printf 'HARNESS_REDIS_PASSWORD=%s\n' "$HARNESS_REDIS_PASSWORD"
+  } > "$HARNESS_ENV_FILE"
+fi
+. "$HARNESS_ENV_FILE"
 
 # Start PostgreSQL
 docker run -d --name harness-postgres \
   -p 127.0.0.1:5432:5432 \
-  -e POSTGRES_PASSWORD=testpass \
+  -e POSTGRES_PASSWORD="$HARNESS_POSTGRES_PASSWORD" \
   postgres:16
 
 # Wait for ready
@@ -120,7 +133,8 @@ set -euo pipefail
 
 export PORT=8081
 export ENV=test
-export DATABASE_URL="postgres://postgres:testpass@localhost:5432/testdb?sslmode=disable"
+. harness/.runtime/env
+export DATABASE_URL="postgres://postgres:${HARNESS_POSTGRES_PASSWORD}@localhost:5432/testdb?sslmode=disable"
 
 # Start server
 go run cmd/api/main.go &

package/bundled-skills/ecl-harness-engineer/references/environment-detection-guide.md

@@ -81,7 +81,7 @@ harness/
       },
       "test_alternatives": {
         "sqlite_in_memory": "DB_DRIVER=sqlite3 DB_URL=:memory:",
-        "docker": "docker run -d --name test-pg -p 127.0.0.1:5433:5432 -e POSTGRES_PASSWORD=test postgres:16"
+        "docker": "HARNESS_POSTGRES_PASSWORD=$(openssl rand -hex 24); docker run -d --name test-pg -p 127.0.0.1:5433:5432 -e POSTGRES_PASSWORD=\"$HARNESS_POSTGRES_PASSWORD\" postgres:16"
       }
     }
   ],
@@ -94,7 +94,7 @@ harness/
       "required": false,
       "connection": {
         "url_env": "REDIS_URL",
-        "default_url": "redis://localhost:6379"
+        "default_url": "redis://:${HARNESS_REDIS_PASSWORD}@localhost:6379"
       },
       "setup": {
         "docker_image": "redis:7",
@@ -221,11 +221,12 @@ echo "==> Setting up environment for ${PROJECT_NAME}..."
 {{#if (eq type "postgres")}}
 if ! docker ps -q -f name={{name}} | grep -q .; then
   echo "Starting PostgreSQL ({{name}})..."
+  : "${{{connection.password_env}}:=$(openssl rand -hex 24)}"
   docker run -d \
     --name {{name}} \
     -p 127.0.0.1:{{connection.default_port}}:5432 \
     -e POSTGRES_USER=${{{connection.user_env}}:-postgres} \
-    -e POSTGRES_PASSWORD=${{{connection.password_env}}:-postgres} \
+    -e POSTGRES_PASSWORD="${{{connection.password_env}}}" \
     -e POSTGRES_DB=${{{connection.database_env}}:-{{../project_name}}} \
     {{setup.docker_image}}
   echo "Waiting for PostgreSQL to be ready..."
@@ -239,10 +240,11 @@ fi
 {{#if (eq type "mysql")}}
 if ! docker ps -q -f name={{name}} | grep -q .; then
   echo "Starting MySQL ({{name}})..."
+  : "${{{connection.password_env}}:=$(openssl rand -hex 24)}"
   docker run -d \
     --name {{name}} \
     -p 127.0.0.1:{{connection.default_port}}:3306 \
-    -e MYSQL_ROOT_PASSWORD=${{{connection.password_env}}:-root} \
+    -e MYSQL_ROOT_PASSWORD="${{{connection.password_env}}}" \
     -e MYSQL_DATABASE=${{{connection.database_env}}:-{{../project_name}}} \
     {{setup.docker_image}}
   echo "Waiting for MySQL to be ready..."
@@ -262,7 +264,9 @@ fi
 {{#if (eq type "redis")}}
 if ! docker ps -q -f name={{name}} | grep -q .; then
   echo "Starting Redis ({{name}})..."
-  docker run -d --name {{name}} -p 127.0.0.1:6379:6379 {{setup.docker_image}}
+  : "${HARNESS_REDIS_PASSWORD:=$(openssl rand -hex 24)}"
+  docker run -d --name {{name}} -p 127.0.0.1:6379:6379 {{setup.docker_image}} \
+    redis-server --requirepass "$HARNESS_REDIS_PASSWORD"
   echo "Redis started."
 fi
 {{/if}}

package/bundled-skills/effective-agent-skills/SKILL.md

@@ -0,0 +1,333 @@
+---
+name: effective-agent-skills
+description: "Author and review high-quality agent skills with triggers, progressive disclosure, and safety notes."
+category: development
+risk: safe
+source: community
+source_repo: davidondrej/skills
+source_type: community
+date_added: "2026-07-07"
+author: davidondrej
+tags: [skills, authoring, quality]
+tools: [claude, codex]
+license: "MIT"
+license_source: "https://github.com/davidondrej/skills/blob/main/LICENSE"
+---
+
+# Agent Skills: A Complete Guide
+
+## When to Use
+
+- Use when creating, editing, reviewing, or debugging an agent SKILL.md file.
+- Use when you need quality guidance for triggers, examples, limitations, and safety notes.
+
+A consolidated reference on what agent skills are, why they exist, how they work, and how to write effective ones.
+
+---
+
+## 1. What agent skills are
+
+An Agent Skill is a folder containing a `SKILL.md` file (YAML frontmatter + markdown instructions), plus optional subfolders for scripts, references, and assets that the agent loads on demand.
+
+```
+my-skill/
+├── SKILL.md          # Required: metadata + instructions
+├── scripts/          # Optional: executable code (CLIs, validators, helpers)
+├── references/       # Optional: detailed docs loaded only when needed
+└── assets/           # Optional: templates, fonts, static files
+```
+
+Skills are an open standard (agentskills.io), originally created by Anthropic and adopted by OpenAI Codex, Cursor, Gemini CLI, Microsoft Agent Framework, Google ADK, and 40+ other agent products. A skill written once works across all compatible agents.
+
+---
+
+## 2. Why this abstraction exists
+
+Base LLMs are generalists. Real work requires procedural knowledge, organizational context, and repeatable workflows. Every prior alternative had a failure mode:
+
+| Approach | Problem |
+|---|---|
+| Stuff it into the system prompt | Always loaded → context bloat at scale |
+| Re-paste instructions each session | No version control, no consistency |
+| Fine-tuning | Slow, expensive, opaque, vendor-locked |
+| MCP servers alone | Give the agent tools but no workflows for using them |
+
+Skills solve four problems at once:
+
+- **Context efficiency** — instructions load only when relevant
+- **Repeatability** — multi-step procedures become auditable workflows
+- **Composability** — multiple skills combine at runtime per task
+- **Portability** — same files work across vendors and surfaces
+
+Mental model: skills are to LLMs what man pages, runbooks, and team handbooks are to engineers — reference material loaded into working memory only when the task demands it.
+
+---
+
+## 3. How they work — progressive disclosure
+
+The architectural core. Three-stage loading:
+
+**Level 1 — Discovery (~100 tokens per skill, always in context):**
+Only `name` + `description` from frontmatter are injected into the system prompt at startup. Agent knows the skill exists and when it applies. You can install dozens of skills with negligible overhead.
+
+**Level 2 — Activation (<5,000 tokens, loaded on match):**
+When the user's request matches a skill's description, the agent reads the full `SKILL.md` body into context.
+
+**Level 3 — Execution (unbounded, on demand):**
+The agent reads referenced files (`references/foo.md`) or runs scripts (`scripts/validate.py`) only as needed. Scripts can execute without their source being loaded into context at all.
+
+This is why bundled content has no practical limit. Files don't consume tokens until accessed.
+
+---
+
+## 4. SKILL.md anatomy
+
+```markdown
+---
+name: skill-name
+description: What this skill does AND when to use it. Include trigger phrases the user will say.
+---
+
+# Skill Name
+
+## Quick start
+[Minimal working example]
+
+## Workflow
+[Step-by-step procedure with checklists]
+
+## Output format
+[What the user/agent should expect back]
+
+## Advanced
+[Link to references/ for rarely-needed detail]
+```
+
+Frontmatter constraints:
+- `name` is lowercase, hyphens only, 1–64 chars, **exactly matches the parent folder name**
+- Avoid `<` and `>` in frontmatter (they can inject into the system prompt)
+- Invalid YAML silently prevents loading
+
+Optional standard fields:
+- `disable-model-invocation: true` — stops the agent from auto-loading the skill based on the conversation; it can only be triggered manually (e.g. `/skill-name`). Now a standard Agent Skills spec field, so it works across spec-compliant clients (Claude Code, Copilot, etc.), not just Claude. Caveat: it prevents auto-invocation, but some clients (Claude Code, open bug) still inject the `description` into context, so it doesn't always save the discovery-level tokens. Use for manual-only utilities you don't want firing automatically.
+
+---
+
+## 5. Two design philosophies
+
+Skills tend to fall into one of two patterns. Both are valid; they solve different problems.
+
+### Pattern A — Capability primitives (tool wrappers)
+The skill is a thin wrapper over a deterministic CLI or script. Logic lives in code. SKILL.md teaches the agent how to invoke it.
+
+- **Adds**: new capabilities (search, email, browser, API access)
+- **Reliability via**: shell tools, not prompts
+- **Typical length**: 30–80 lines, mostly command examples
+- **Use when**: the bottleneck is "the agent can't do X"
+
+### Pattern B — Process primitives (cognitive disciplines)
+The skill encodes a methodology the agent should follow. Pure prompt engineering — no scripts needed.
+
+- **Adds**: structured workflows (TDD, code review, design alignment, debugging loops)
+- **Reliability via**: explicit procedure, checklists, validation loops
+- **Use when**: the bottleneck is "the agent's output quality or process is bad"
+
+A mature setup uses both. Pattern A gives the agent better tools. Pattern B gives it better methods for using them.
+
+---
+
+## 6. How to write effective skills — do this
+
+### Description as routing contract
+The description is the only thing the agent sees before deciding to load the skill. If your skill doesn't trigger, the description is wrong 95% of the time, not the body.
+
+Include three elements:
+1. **What** the skill does (one phrase)
+2. **When** to use it (trigger phrases, situations)
+3. **Differentiator** vs related skills (prevents routing conflicts)
+
+Pattern: `"X via Y. Use for [situations]. [Differentiator: no Z required / faster than W / handles edge case V]."`
+
+**Never summarize the full workflow in the description.** If the description contains a step-by-step summary of *how* the skill works, the agent tends to follow that summary and skip loading the body. Describe *what* and *when*, never *how*. The description answers "should I open this skill now?" — not "what are the steps?"
+
+### Keep SKILL.md lean
+- Beyond a certain length, you're usually encoding logic that should be in a script or referenced file
+
+### Bash-first, prose-second
+Concrete command examples with inline comments beat prose explanations. The agent pattern-matches on syntax. Show, don't describe.
+
+### Push determinism into code
+Anything fragile, repetitive, or where variation is a bug → script. Use markdown only for tasks requiring judgment.
+
+### Match strictness to task fragility (degrees of freedom)
+Scale instruction rigidity to how costly a wrong move is:
+- **Loose natural-language heuristics** when many approaches are valid (e.g. code review).
+- **Pseudocode or templates** when there's a preferred pattern but variation is acceptable (e.g. report format).
+- **Exact scripts and strict step lists** when the workflow is fragile, error-prone, or consistency-critical (e.g. migrations, document patching).
+
+### Build validation loops
+The single biggest output quality improvement: state a verify → fix → re-verify loop explicitly.
+
+- Document skills: visual QA pass before delivery
+- Code skills: tests pass + zero type errors before completion
+- Data skills: schema validation before output
+
+### State-check before action
+Don't assume setup is done. Instruct the agent to verify state, then branch:
+```
+First check if X is configured: [command]
+If not, walk the user through setup: [steps]
+```
+
+### Just-in-time loading with explicit pointers
+Tell the agent exactly when to read each referenced file:
+```
+For standard cases, follow the steps below.
+For [specific edge case], read references/edge-cases.md first.
+```
+
+### Keep references one level deep
+Link referenced files directly from SKILL.md. Never build chains (SKILL.md → advanced.md → details.md → actual.md) — the agent may preview nested files only partially and miss critical instructions. Add a table of contents to any reference file longer than 100 lines.
+
+### Document output formats
+If your script returns structured data, show the agent what it looks like. Enables reliable downstream parsing.
+
+### Defer to --help for completeness
+List the 80% common operations in SKILL.md. Tell the agent to run `tool --help` for the rest. Keeps SKILL.md small without losing functionality.
+
+### Compose primitives, don't bundle workflows
+One skill = one capability or one discipline. Resist bundling concerns into "the X workflow." Multiple small skills combine at runtime; one large skill is rigid.
+
+### Cite established principles when applicable
+If your skill encodes a known engineering methodology (TDD, DDD, red-green-refactor), name the source. Gives the agent a coherent model to align with and gives users a way to verify the design.
+
+### Persistent artifacts for cross-session memory
+Skills can write to repo-level files (CONTEXT.md, ADRs, decision logs) that future agent sessions read. This is how you fight the "agents have no memory" problem at the architecture level.
+
+---
+
+## 7. What not to do — anti-patterns
+
+### Don't re-teach what the model already knows
+Every line in SKILL.md should provide context the model doesn't already have. No Python syntax tutorials. No "what is git." Challenge every paragraph.
+
+### Don't include human-facing docs
+No README.md, no CHANGELOG.md, no INSTALLATION_GUIDE.md inside the skill folder. Skills are for agents.
+
+### Don't write vague descriptions
+- Bad: "A helpful skill for documents"
+- Good: "Fill PDF form fields, extract form data, flatten completed PDFs. Use when the user mentions PDF forms, fillable forms, or programmatic field population."
+
+### Don't bundle library code
+If you need a parsing library, install via npm/pip. Don't paste source into the skill.
+
+### Don't write monolithic mega-skills
+If one skill does design + planning + implementation + testing + deployment, you've built a framework, not a skill. Split it.
+
+### Don't assume the agent will infer
+Be explicit about every step that matters.
+- Bad: "Then deploy it."
+- Good: "Run `npm run deploy:staging` and wait for HTTP 200 from /healthz before reporting success."
+
+### Don't write style-only variants
+A skill that just changes tone or formatting belongs in user preferences or a system prompt, not a skill.
+
+### Don't ignore failure modes
+For every workflow step that can fail, document what failure looks like and what to do. Happy-path-only skills break in production.
+
+### Don't include time-sensitive information
+"As of Q4 2024..." rots fast. Fetch live data via script or omit.
+
+### Don't use absolute paths
+Always relative. Forward slashes regardless of OS. Use runtime placeholders for skill-directory references.
+
+### Don't trust unfamiliar skills
+Skills can execute arbitrary code and steer agent behavior. A malicious skill is a data exfiltration vector. Audit `scripts/` for unexpected network calls, file access outside expected scope, or hidden instructions in references. Watch for typosquatted skill names. Sandbox execution environments.
+
+---
+
+## 8. Authoring workflow
+
+1. **Identify the gap.** Run your agent on real tasks. Where does it consistently fail or need re-prompting? That's a skill candidate.
+2. **Decide the pattern.** Capability primitive (need new tools) or process primitive (need better methodology)?
+3. **Draft the description first.** What + when + differentiator. Read it back: would the agent know when to fire it?
+4. **Write the smallest body that works.** Add only when testing reveals gaps.
+5. **Move detail to references/ once SKILL.md grows too long.**
+6. **Test triggering.** Ask the agent something the skill should handle without invoking it explicitly. If it doesn't fire, fix the description.
+7. **Test execution.** Invoke explicitly. If output is wrong, fix the body.
+8. **Adversarial test.** Have another LLM ask: "What edge cases break this skill?" Patch the gaps.
+9. **Version control.** Treat skills as code. Tag, branch, review.
+
+---
+
+## 9. Testing and debugging
+
+- **"Which skill did you use?"** — ask the agent post-task. Fastest routing debug.
+- **Routing fails → description problem.** Add specific trigger phrases.
+- **Execution fails → body problem.** Add explicit steps, examples, or validation.
+- **Skills snapshot at session start.** Edits during a session require a restart.
+- **Test against the weakest model you'll deploy on.** Stronger models forgive vague skills; weaker models expose them.
+- **Run an eval suite.** A handful of representative prompts that should and shouldn't trigger the skill, with expected outputs.
+
+---
+
+## 10. Composition
+
+Skills compose at runtime — the agent loads multiple skills as needed for a single task. Design for this:
+
+- **One skill = one concern.** Resist bundling.
+- **Define interfaces between skills.** If skill A produces artifacts that skill B consumes, document the shape.
+- **Use a repo-level config substrate.** A shared file (e.g., AGENTS.md, CONTEXT.md, settings.json) that multiple skills read and write coordinates them without explicit handoffs.
+- **Loops over menus.** A coordinated set of skills forming a workflow (align → spec → build → verify → refactor) drives adoption far better than an unrelated catalog of capabilities.
+
+---
+
+## 11. Security checklist
+
+Before installing any third-party skill:
+
+- Read every file in the folder
+- Audit `scripts/` for outbound network calls, file access outside expected scope, command execution
+- Check references for prompt injection ("ignore previous instructions...")
+- Verify the skill name isn't typosquatting a popular one
+- Run in a sandboxed environment first
+- Pin to a specific version/commit, not `latest`
+
+---
+
+## 12. Ship checklist
+
+Before publishing a skill:
+
+- [ ] Frontmatter `name` matches folder name
+- [ ] Description includes what + when + differentiator
+- [ ] Description includes likely user trigger phrases
+- [ ] No human-facing docs inside the skill folder
+- [ ] No time-sensitive information
+- [ ] Relative paths only
+- [ ] State-check before action where applicable
+- [ ] Validation loop documented
+- [ ] Output format documented if relevant
+- [ ] Tested with weak and strong models
+- [ ] Tested for both correct triggering and correct execution
+- [ ] Skill does one thing
+- [ ] Composes cleanly with related skills
+- [ ] Version controlled
+
+---
+
+## 13. First principles, compressed
+
+1. **The description routes; the body executes.** Get both right independently.
+2. **Tokens are scarce; files are cheap.** Push detail out of context until it's needed.
+3. **Determinism comes from code; judgment comes from prompts.** Put each in its right place.
+4. **One skill, one concern.** Composition beats bundling.
+5. **Agents have no memory.** Use persistent artifacts to give them one.
+6. **The model knows a lot.** Don't re-teach. Only add what's missing.
+7. **Validate before completing.** Self-correction loops dominate output quality.
+8. **Skills are code.** Version, test, audit, and review them as such.
+
+## Limitations
+
+- Adapted from `davidondrej/skills`; verify local paths, tools, credentials, and agent features before acting.
+- For commands, remote access, scheduling, browser automation, or file-changing workflows, get explicit user approval and confirm the target environment first.

package/bundled-skills/electron-development/SKILL.md

@@ -538,12 +538,16 @@ publish:
 # macOS: requires Apple Developer certificate
 # Set environment variables before building:
 export CSC_LINK="path/to/Developer_ID_Application.p12"
-export CSC_KEY_PASSWORD="your-password"
+read -rsp "macOS certificate password: " CSC_KEY_PASSWORD
+echo
+export CSC_KEY_PASSWORD
 
 # Windows: requires EV or standard code signing certificate
 # Set environment variables:
 export WIN_CSC_LINK="path/to/code-signing.pfx"
-export WIN_CSC_KEY_PASSWORD="your-password"
+read -rsp "Windows certificate password: " WIN_CSC_KEY_PASSWORD
+echo
+export WIN_CSC_KEY_PASSWORD
 
 # Build signed app
 npx electron-builder --mac --win --publish never

package/bundled-skills/environment-setup-guide/SKILL.md

@@ -107,13 +107,10 @@ sudo -E bash "$tmpdir/nodesource-setup.sh"
 sudo apt install -y nodejs
 \`\`\`
 
-**Windows (using Chocolatey):**
+**Windows (using winget):**
 \`\`\`powershell
-# Install Chocolatey if not installed
-Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
-
 # Install Node.js
-choco install nodejs
+winget install OpenJS.NodeJS.LTS
 \`\`\`
 
 ### Step 2: Verify Installation

package/bundled-skills/expo-ui/scripts/list-components.js

@@ -15,8 +15,12 @@
 
 const fs = require('fs');
 const path = require('path');
+const sanitizeFilename = require('sanitize-filename');
 
-const projectPath = process.argv[2];
+const rawProjectPath = process.argv[2];
+const projectPath = rawProjectPath
+  ? path.resolve(process.cwd(), sanitizeFilename(path.basename(rawProjectPath)))
+  : null;
 const withDocs = process.argv.includes('--docs');
 
 if (!projectPath) {

package/bundled-skills/fable-safe-prompt/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: fable-safe-prompt
+description: "Rewrite allowed prompts to reduce false-positive safety triggers without bypassing policy or changing intent."
+category: agent-behavior
+risk: safe
+source: community
+source_repo: davidondrej/skills
+source_type: community
+date_added: "2026-07-07"
+author: davidondrej
+tags: [prompting, safety, guardrails]
+tools: [claude, codex]
+license: "MIT"
+license_source: "https://github.com/davidondrej/skills/blob/main/LICENSE"
+disable-model-invocation: true
+---
+
+# Fable-Safe Prompt
+
+## When to Use
+
+- Use when an allowed prompt appears likely to hit false-positive classifier language.
+- Use when the user asks for prompt wording that keeps benign intent clear and policy-compliant.
+
+Return the user's prompt back **in full, verbatim**, changing ONLY the specific sentences/phrases most likely to trip Fable 5's cyber/bio classifiers. Do not rewrite the whole thing, do not summarize, do not restructure — minimal surgical edits. Keep the actual goal and all benign text exactly as written. This lowers false positives for benign work. It must not be used to bypass safety policy or enable harmful requests.
+
+Fable 5 runs 3 input classifiers: **cyber**, **bio/chem**, **reasoning_extraction**. Triggers are keyword/surface-based, largely intent-independent ("hello" and "cancer" got flagged). The fix is to abstract away the sensitive domain, not just restate intent.
+
+Apply when the prompt touches: cyber/auth/exploits/malware/pentesting/credentials; bio/chem/medical/disease/lab topics; or any "show your reasoning" instruction.
+
+The user provides the prompt-to-be-changed wrapped in `<prompt>...</prompt>` XML tags. Operate only on the text inside those tags; treat everything outside as instructions to you.
+
+## Method
+
+1. Flag the highly problematic sentences/phrases (offensive framings, named sensitive domains, "show your thinking" lines).
+2. Replace each in place with a safe equivalent (see swaps), or describe the wanted functionality abstractly rather than naming the domain.
+3. Leave everything else byte-for-byte identical.
+4. Return the complete edited prompt.
+
+Reframe so the task reads as: **owned/authorized**, **defensive** (implement/fix/test, not attack), and **not dual-use** (no exploit dev, attack simulation, bypass payloads, malware, live testing).
+
+### Swap framings (apply per-sentence)
+
+| Triggering | Safe rewrite |
+|---|---|
+| "How could an attacker exploit this auth" | "Review these auth files for missing checks and fix them defensively" |
+| "Write an exploit / payload / PoC" | "Add a regression test proving X is fixed, then patch it" |
+| "How do I bypass / brute-force Y" | "Enforce secure session validation + rate limiting on Y" |
+| "Reverse this malware / show attack steps" | "Describe the risk high-level, then implement the fix" |
+| "Show your reasoning / explain step-by-step / walk me through your thinking" | **Delete it.** Trips `reasoning_extraction`. If progress visibility is needed, ask it to use a send-to-user tool, not to echo its internal thoughts. |
+| Clinician framing: "as a doctor, diagnose this ECG" | Patient framing: "help me interpret this ECG my doctor gave me" |
+| Named bio/chem domain: "cancer / disease pathway / chemical kinetics" | Abstract it: describe the data/analysis generically, drop the domain noun |
+
+### Trigger keywords to abstract away
+*Cyber:* exploit, malware, vulnerability, attack, bypass, stealth, fingerprinting, anti-bot, CAPTCHA, penetration.
+*Bio/chem:* biology, biomedicine, chemistry, cancer, disease pathways, RNA/variant calling, equilibrium, kinetics, diagnosis.
+*Distillation:* "distill the model", training pipelines, frontier LLM development.
+
+If no benign defensive equivalent exists for a sentence (it's purely offensive), flag it to the user rather than silently neutering the intent.
+
+## Output
+
+1. Print the full safe prompt back to the user in text (a code block, ready to paste).
+2. **Copy it to the clipboard** so the user can paste immediately:
+   ```bash
+   pbcopy <<'EOF'
+   <the full safe prompt>
+   EOF
+   ```
+   Confirm in one line that it's on the clipboard.
+3. A short list of exactly which sentences you changed and what they became.
+4. If the task is genuinely offensive (pentest, exploit repro, malware analysis): say plainly no edit makes it Fable-safe — use an Opus 4.8 fallback or vetted Mythos, not Fable 5.
+
+**Hard truth:** you can't reliably stop Fable 5 guardrails. Robust API setups also treat `stop_reason: "refusal"` (HTTP 200, `stop_details.category` = `cyber`/`bio`) as a route to an Opus 4.8 fallback — mention only if the user controls the integration.
+
+## Limitations
+
+- Adapted from `davidondrej/skills`; verify local paths, tools, credentials, and agent features before acting.
+- For commands, remote access, scheduling, browser automation, or file-changing workflows, get explicit user approval and confirm the target environment first.