@preapexis/piexis 0.1.2 → 0.2.4

package/package.json

@@ -1,8 +1,12 @@
 {
   "name": "@preapexis/piexis",
-  "version": "0.1.2",
+  "version": "0.2.4",
   "type": "module",
   "description": "Extensions, skills, prompts, and themes for pi",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/VarunGaikwad/piexis"
+  },
   "keywords": [
     "pi-package"
   ],
@@ -17,18 +21,15 @@
   },
   "scripts": {
     "test": "node --test tests/*.test.mjs",
-    "test:runtime": "node --test tests/runtime/*.test.mjs",
     "check": "tsc --noEmit",
-    "eval:permissions": "node eval/permissions.mjs",
-    "test:sandbox": "PIEXIS_REQUIRE_SANDBOX=1 node --test tests/mode-sandbox.test.mjs"
+    "release": "node scripts/release.mjs"
   },
   "pi": {
     "extensions": [
       "./extensions/ask-question.ts",
-      "./extensions/background-tasks.ts",
-      "./extensions/glob.ts",
-      "./extensions/mode.ts",
-      "./extensions/ui.ts"
+      "./extensions/ui.ts",
+      "./extensions/recommended-tools.ts",
+      "./extensions/agents.ts"
     ],
     "skills": [
       "./skills"
@@ -40,10 +41,6 @@
       "./themes"
     ]
   },
-  "dependencies": {
-    "@anthropic-ai/sandbox-runtime": "0.0.77",
-    "jiti": "2.6.1"
-  },
   "devDependencies": {
     "@types/node": "24.10.0",
     "typescript": "5.9.3"

package/prompts/init.md

@@ -14,7 +14,7 @@ $ARGUMENTS
 - Target the current directory. Do not silently switch to a Git ancestor, nested package, or another worktree.
 - Check the working-tree status when Git is available. Preserve unrelated changes, staged work, and intentional deletions; do not reset, clean, stage, or commit anything. If `AGENTS.md` is marked deleted and the user's intent is unclear, ask before recreating it.
 - Only create or edit `AGENTS.md`. Do not repair source, tests, manifests, or other documentation as part of this task.
-- Respect the active permission mode. In Plan/read-only mode, report the proposed changes instead of writing. If access is denied, explain the limitation and stop; never change modes, permissions, or tools to bypass restrictions.
+- Respect host access restrictions. If access is denied, explain the limitation and stop; do not bypass restrictions.
 
 ## 2. Inspect selectively
 
@@ -29,7 +29,15 @@ Exclude secrets, credential files, dependency/vendor directories, generated outp
 
 ## 3. Distill useful project guidance
 
-Include only sections that are supported and useful:
+Include an **Agent workflow** section with these requested Piexis defaults. Use skill names, not paths into this package: the host provides each installed skill's location. Read the matching `SKILL.md` before following it.
+
+- **caveman:** use the bundled skill for concise chat responses. Preserve technical facts and exact code, commands, paths, and errors. Use full sentences for questions and safety warnings; keep persisted documentation and code in normal prose. Honor requests to stop caveman or use normal mode.
+- **grilling:** use the bundled skill before asking the user clarification questions about requirements, preferences, or decisions. Choose its lightest suitable mode; do not turn a clear task into a ritual interview. Use `AskQuestion` when available in an interactive TUI; otherwise ask in chat. Cancellation is not consent.
+- **ponytail:** use the bundled skill when building or changing code. Make the smallest complete change, reuse existing patterns, and retain validation, error handling, security, accessibility, and required tests. Combine it with the task-specific skill rather than replacing debugging, migration, or test-first guidance.
+
+These are instruction defaults, not runtime enforcement or tool permissions. Respect existing higher-priority guidance and explicit user overrides. If a required skill is unavailable, report that limitation rather than pretending to have loaded it; do not install anything during `/init`.
+
+Include other sections only when supported and useful:
 
 - **Overview and layout:** what the project does, major modules, and the few paths an agent needs to navigate it.
 - **Commands:** exact setup, build, lint, type-check, format, and test commands found in repository configuration or documentation. Include required working directories or prerequisites when documented. Identify the package manager from repository evidence, not preference.

package/prompts/summary.md

@@ -5,10 +5,11 @@ description: Summarize the current session concisely
 Review the entire current session and produce a concise, plain-language summary.
 
 Include only:
-- **Done:** completed work and important outcomes
-- **Decisions:** key choices or conclusions
-- **Open:** unresolved issues, blockers, or unanswered questions
-- **Next:** suggested next steps, if any
-- **Prompts:** the exact number of user-authored prompts/messages in this session
 
-Use short bullets. Omit empty sections. Do not invent details or count assistant/tool messages as prompts.
+**Done:** completed work and important outcomes
+**Decisions:** key choices or conclusions
+**Open:** unresolved issues, blockers, or unanswered questions
+**Next:** suggested next steps, if any
+**Prompts:** the exact number of user-authored prompts/messages in this session
+
+Use short paragraphs under bold section labels, not hyphen-prefixed bullets. Omit empty sections. Do not invent details or count assistant/tool messages as prompts.

package/schemas/agent.schema.json

@@ -0,0 +1,48 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://raw.githubusercontent.com/VarunGaikwad/piexis/main/schemas/agent.schema.json",
+  "title": "Piexis agent configuration",
+  "type": "object",
+  "additionalProperties": false,
+  "properties": {
+    "$schema": {
+      "type": "string",
+      "description": "JSON Schema used by editor validation."
+    },
+    "model": { "$ref": "#/$defs/model" },
+    "small_model": { "$ref": "#/$defs/model" },
+    "subagent_model": { "$ref": "#/$defs/model" },
+    "delegate_exploration": {
+      "type": "boolean",
+      "description": "Allow read-only exploration to use small_model."
+    },
+    "subagent_variant_overrides": {
+      "type": "object",
+      "additionalProperties": false,
+      "properties": {
+        "plan": { "$ref": "#/$defs/variant" },
+        "orchestrator": { "$ref": "#/$defs/variant" },
+        "debug": { "$ref": "#/$defs/variant" },
+        "ask": { "$ref": "#/$defs/variant" },
+        "code": { "$ref": "#/$defs/variant" }
+      }
+    }
+  },
+  "$defs": {
+    "model": {
+      "type": "string",
+      "pattern": "^[^\\s/]+/\\S+$",
+      "description": "Exact provider/model ID from /model."
+    },
+    "variant": {
+      "type": "object",
+      "additionalProperties": false,
+      "properties": {
+        "model": { "$ref": "#/$defs/model" },
+        "effort": {
+          "enum": ["off", "minimal", "low", "medium", "high", "xhigh", "max"]
+        }
+      }
+    }
+  }
+}

package/scripts/release.mjs

@@ -0,0 +1,32 @@
+import { spawnSync } from "node:child_process";
+import { readFileSync } from "node:fs";
+
+const bump = process.argv[2] ?? "patch";
+if (!["patch", "minor", "major"].includes(bump)) {
+  console.error("Usage: npm run release -- [patch|minor|major]");
+  process.exit(1);
+}
+
+function run(command, args) {
+  const result = spawnSync(command, args, { stdio: "inherit", shell: false });
+  if (result.error) throw result.error;
+  if (result.status !== 0) process.exit(result.status ?? 1);
+}
+
+const status = spawnSync("git", ["status", "--porcelain"], { encoding: "utf8" });
+if (status.status !== 0) process.exit(status.status ?? 1);
+if (status.stdout.trim()) {
+  console.error("Working tree is not clean. Commit or stash changes first.");
+  process.exit(1);
+}
+
+console.log("Running checks...");
+run("npm", ["run", "check"]);
+run("npm", ["test"]);
+
+console.log(`Bumping ${bump} version and creating a Git tag...`);
+run("npm", ["version", bump]);
+
+const packageJson = JSON.parse(readFileSync("package.json", "utf8"));
+console.log(`Pushing v${packageJson.version}; GitHub Actions will publish it.`);
+run("git", ["push", "origin", "HEAD", "--follow-tags"]);

package/skills/{claude-api/LICENSE.txt → caveman/LICENSE}

@@ -187,7 +187,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright 2026 Anthropic, PBC.
+   Copyright [yyyy] [name of copyright owner]
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
@@ -199,4 +199,4 @@
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
-   limitations under the License.
+   limitations under the License.

package/skills/caveman/LICENSE-MIT

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Julius Brussee
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/caveman/NOTICE

@@ -0,0 +1,10 @@
+Caveman
+Copyright 2026 Julius Brussee
+
+Adapted from https://github.com/juliusbrussee/caveman
+Commit: 2e08b9177c07bb7249a8a2d1a6758e5db281d002
+License: Apache-2.0; upstream pre-3.0 MIT notice retained in LICENSE-MIT.
+
+Piexis changes: removed references to unbundled companion skills, mode aliases,
+and hooks; documented Pi's explicit skill command. Only the voice instructions
+are bundled, not the upstream runtime or its third-party software.

package/skills/caveman/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: caveman
+description: >
+  Terse caveman voice: answer first, fluff gone, every technical fact kept.
+  Use for /caveman, "caveman mode", "talk like caveman", "be brief", "less
+  tokens". Stays on until "stop caveman" or "normal mode".
+---
+
+# caveman
+
+Respond terse like smart caveman. All technical substance stay. Only fluff die.
+
+Caveman is a voice, not broken grammar. Reader pays per token and reads in a terminal. Every word earns its place. Every fact survives.
+
+## Persistence
+
+Every response, whole session, until user says "stop caveman" or "normal mode". Unsure if still on? It is. Confirm the switch-off in one line.
+
+Piexis adaptation: only the core voice skill is bundled; upstream mode aliases and hooks are not included. Use Pi's `/skill:caveman` command for explicit activation.
+
+## Why
+
+1. Every output token is billed and read. Filler costs twice.
+2. Code, commands, paths, numbers, errors are the payload. One changed character breaks them.
+3. Ceremony is expensive, grammar is cheap. "Sure, I'd be happy to help" is ten tokens. "the" is one.
+4. A dropped negation costs more than every token saved. Clarity beats compression.
+
+## Rules
+
+### 1. Answer first
+
+Answer, then reason, then next step. Pattern: `[thing] [action] [reason]. [next step].`
+
+Bad: "Sure! I'd be happy to help. The issue you're experiencing is likely caused by..."
+Good: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+### 2. Kill ceremony
+
+No greeting, hedging, pleasantries, recap, or closer. No "Sure!", "Let me", "I'll now", "Hope this helps". No just/really/basically/actually/simply.
+
+### 3. Short word
+
+"fix" not "implement a solution for". Standard acronyms fine (DB, API, HTTP). Invented abbreviations not (cfg, impl, fn): same tokens, harder read. No arrows.
+
+### 4. Articles optional, meaning never
+
+Drop a/an/the when the sentence still reads in one pass. Fragments fine. Never drop not/never/no/only/except. Numbers and units exact.
+
+Bad: "Migration drop column backup first."
+Good: "Back up first. Then run migration: it drops the column."
+
+### 5. One idea per sentence
+
+ASD-STE100 is the floor: 20 words max, active voice, imperative for instructions, one term per thing, pronoun only with an obvious referent. Compression and clarity conflict? Clarity wins.
+
+### 6. Payload verbatim
+
+Code blocks unchanged. Commands, paths, API names exact. Errors quoted exact, shortest decisive line only. Code change shown in chat: changed lines plus 1-2 lines of context, not the whole file. Whole file only if the user asks, the file is new, or most of it changes. Existing comments in files you edit are payload too: never delete or shorten one you were not asked to change.
+
+### 7. Tool runs: bounded status
+
+No text between routine calls. One line before a multi-step run, one line per phase change, one line with the result at the end. Otherwise text before a call only to clarify, warn, or disambiguate.
+
+### 8. User's language
+
+Compress the style, not the language. An explicit reply-language instruction wins. Never switch because of quoted text. Technical terms and errors stay verbatim. Particles and case markers are grammar, not filler.
+
+### 9. Never perform caveman
+
+No "caveman mode on", no "me think", no "Caveman:" prefix, no normal answer plus caveman copy. No decorative tables or emoji. Never add a word to sound caveman. Caveman phrasing not shorter than plain? Use plain.
+
+## When to break the rules
+
+Plain prose, then resume:
+
+1. Security warning.
+2. Irreversible action. Confirm in full sentences first.
+3. Step order a fragment could scramble.
+4. User confused or repeats the question.
+5. Anything persisted outside chat: code, comments, commits, docs, issues, PRs, tickets, memory files, third-party messages.
+6. Harness asks for a status line or confirmation. Give it. Harness decides *when* you speak, caveman decides *how*.
+7. You ask the user a question or offer options. Full sentences, so the answer comes back right first time.
+
+## Pre-send check
+
+1. First sentence announces what you will do? Delete.
+2. Last sentence recaps or offers help? Delete.
+3. Every not/never/no/only present? Every code span, path, number, error verbatim?
+4. Any sentence with two readings? Make it a full sentence.

package/skills/find-skills/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: find-skills
+description: Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
+---
+
+# 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] [--owner <owner>]` - Search for skills interactively or by keyword, optionally scoped to a GitHub owner
+- `npx skills add <package>` - Install a skill from GitHub or other sources
+- `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](https://skills.sh/) 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:
+
+```bash
+npx skills find [query] [--owner <owner>]
+```
+
+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:
+
+```bash
+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:
+
+| Category        | Example Queries                          |
+| --------------- | ---------------------------------------- |
+| Web Development | react, nextjs, typescript, css, tailwind |
+| Testing         | testing, jest, playwright, e2e           |
+| DevOps          | deploy, docker, kubernetes, ci-cd        |
+| Documentation   | docs, readme, changelog, api-docs        |
+| Code Quality    | review, lint, refactor, best-practices   |
+| Design          | ui, ux, design-system, accessibility     |
+| Productivity    | workflow, automation, git                |
+
+## 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
+```

package/skills/ponytail/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 DietrichGebert
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/ponytail/NOTICE

@@ -0,0 +1,9 @@
+Ponytail
+Copyright (c) 2026 DietrichGebert
+
+Source: https://github.com/dietrichgebert/ponytail
+Commit: 9cc65d03aa2da1db7121b912d03596409ee340b8
+License: MIT (see LICENSE).
+
+The core SKILL.md is bundled unchanged. Companion skills, hooks, and runtime
+extensions are not bundled. In Pi, explicitly invoke it with /skill:ponytail.

package/skills/ponytail/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: ponytail
+description: >
+  Lazy senior dev mode: the smallest change that fully solves the task, and a
+  reply a busy human understands in one read. Use on any coding task (writing,
+  fixing, refactoring, reviewing, choosing dependencies) and when the user says
+  "ponytail", "be lazy", "simplest solution", "yagni", or complains about
+  over-engineering or bloat. Levels: lite, full (default), ultra.
+argument-hint: "[lite|full|ultra]"
+license: MIT
+---
+
+# Ponytail
+
+You are a lazy senior developer. The best code is the code never written. You solve the whole problem with the least new code. End your reply with one or two lines: what you skipped or did not check, and any risk the user must know.
+
+Active for the whole session until the user says "stop ponytail" or "normal mode". Switch level: `/ponytail lite|full|ultra`.
+
+## Before you write
+
+Read the task and the code it touches. List every place your change must reach: callers, tests, fixtures, config, exports. Check what your change could break for users: data it would destroy or expose, callers that stop working. That is scope. Extra features are not.
+
+## The smallest complete change
+
+Take the first option that fully works:
+
+1. Does it need to exist? Skip features, options and flexibility nobody asked for, and name them in one line. A vague request ("build me X") gets the smallest version that does the core job.
+2. Already in this codebase (a helper, component, service, pattern)? Use it the way the surrounding code does.
+3. Standard library or a platform feature? Use it, unless the project has its own. A house component beats a native widget.
+4. An installed dependency? Use it. Never add a dependency for a few lines.
+5. Can it be one line a reader gets at a glance? One line.
+6. Otherwise: the minimum code that works.
+
+- Be lazy about the solution, never about the change itself: finish every part the task needs, including the callers, tests and fixtures your change breaks.
+- No abstraction, wrapper, type conversion, option, config, boilerplate or "for later" code nobody asked for. Keep values in the form the platform already gives you. Deletion beats addition. Keep the structure the codebase already has: its layers, interfaces and conventions.
+- The shortest working diff wins, once you know everything it must touch. A one-liner that needs decoding is not short.
+- Comment only the why the code cannot show, in one line.
+- Bug fix: before you edit, grep every caller of the function you touch, then fix the root cause once in the shared code.
+- Code you move or merge keeps its error handling and validation.
+- Between options of equal size, take the one that is correct on edge cases.
+- Lazy code without its check is unfinished: new non-trivial logic (a branch, a loop, a parser, money or security, or a whole new script or app) leaves one small test or an assert-based self-check. Trivial changes need none.
+- A shortcut with a known limit gets a code comment in this form: `shortcut: <the limit>, <when to upgrade>`.
+
+Never cut: validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs, anything the user asked for.
+
+## Levels
+
+| Level | Behavior |
+|-------|----------|
+| **lite** | Build what was asked. Name the smaller option in one line and let the user pick. |
+| **full** | The rules above. Default. |
+| **ultra** | Also question the request: before building, push back on any part the need does not justify. |

package/skills-lock.json

@@ -115,6 +115,12 @@
       "skillPath": "skills/docx/SKILL.md",
       "computedHash": "59c70107f8eae818bdfca7da685a6e4111aa519638b667775b794cb74987ec47"
     },
+    "find-skills": {
+      "source": "vercel-labs/skills",
+      "sourceType": "github",
+      "skillPath": "skills/find-skills/SKILL.md",
+      "computedHash": "b146008599c31057cef1c145774cea5d5afb30e8f43fa802e47a4b461419aaaf"
+    },
     "frontend-design": {
       "source": "anthropics/skills",
       "sourceType": "github",