Compare commits
5
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Frank
|
6664f9090a | ||
 dank
|
7de07ee35c | ||
|
Frank
|
fcc7226c3b | ||
|
dank
|
a8011c3d4d | ||
|
Frank
|
08f90c6df3 |
@@ -96,6 +96,17 @@ Never assume the user reports correct information. He is human, and humans make
|
||||
- Always practice Test Driven Development practices; do UNIT TESTS exist for the functionality about to be edited? Is there a LINTER? Is there a FORMATTER? Verify that they exist, and that they are configured as a pre-commit hook. If they do not exist, they MUST be written PRIOR to the code being written. Invoke `/skill:tdd` for preferred testing style. If tests do exist, ensure that they still match the planned changes. If you believe a PRE-EXISTING test must be changed prior to commencing work, ASK THE USER ABOUT IT.
|
||||
- Always ensure tests run on code changes after every commit, and all project tests run before every push using git hooks, EXCEPT in the event that the individual test in question takes an excessive amount of time. Always ask the user before disabling an individual due to running time or performance concerns.
|
||||
|
||||
|
||||
### 6. Keep the Todo List LIVE, Not Retrospective
|
||||
|
||||
The todo list is the user's cockpit view of your work. A list that only flips at the end is a history dump, not tracking - the user sees nothing while you work.
|
||||
|
||||
- Multi-step work: `todo init` BEFORE the first substantive step - the list must exist while the work is unseen, not after.
|
||||
- Batch the todo transition with the step it describes: `done` + `start` ride along in the same message as the first tool calls of the next step. NEVER defer flips until the whole bill of tasks is finished.
|
||||
- A task is `done` the moment its work is verified - not when the surrounding phase ends.
|
||||
- Blocked on external input (user answer, subagent, service)? `block` it with a reason so the stall is visible; `unblock` the instant it is actionable.
|
||||
- NEVER make a todo call the only call in a message - that is ceremony, not progress; pair every flip with real work.
|
||||
|
||||
## FORBIDDEN ACTS AND MISTAKES TO NOT REPEAT (DO NOT DO THESE):
|
||||
- Editing node_modules or similar import module directories. This is third party code that will be overwritten next time `npm update` or a similar command is run.
|
||||
- `git push` - unless directed, except if it's our local gitea instance on Dankclaw.
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/ask-matt
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/chief-of-staff
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/claude-handoff
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/code-review
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/codebase-design
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/diagnosing-bugs
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/domain-modeling
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/find-skills
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/git-guardrails-claude-code
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/grill-me
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/grill-with-docs
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/grilling
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: grilling
|
||||
description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
|
||||
---
|
||||
|
||||
> **Authored override.** Extracted 2026-10-18 from `mattpocock/skills` (identical to upstream at extraction) into the command-center repo so Frank can customize it. Removed from the `skills` CLI global store (`~/.agents/.skill-lock.json` pruned) so `skills update -g` never resurrects a duplicate. Edits to this file are repo prose: branch → PR → Frank OK.
|
||||
|
||||
Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
|
||||
|
||||
Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled: the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
|
||||
|
||||
Format a round like so:
|
||||
|
||||
```
|
||||
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
|
||||
|
||||
➡️ <your recommended answer>
|
||||
|
||||
---
|
||||
|
||||
❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
|
||||
|
||||
➡️ <your recommended answer>
|
||||
```
|
||||
|
||||
Word each question so "yes" accepts your recommended answer.
|
||||
|
||||
Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
|
||||
|
||||
Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The _decisions_ are the user's: put each to them and wait.
|
||||
|
||||
The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/handoff
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/implement
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/implement-spec
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/improve-codebase-architecture
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/loop-me
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/migrate-to-shoehorn
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/pr
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/prototype
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/research
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/retro
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/scaffold-exercises
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/setup-matt-pocock-skills
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/setup-pre-commit
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/setup-ts-deep-modules
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/tdd
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/teach
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/to-questionnaire
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/to-spec
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/to-tickets
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/triage
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/wait-what
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/wayfinder
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/wizard
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/writing-beats
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/writing-for-agents
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/writing-fragments
|
||||
@@ -1 +0,0 @@
|
||||
/home/blank/.agents/skills/writing-shape
|
||||
@@ -1,44 +1,63 @@
|
||||
---
|
||||
type: reference
|
||||
title: omp Skill Store Wiring
|
||||
description: How omp's agent/skills directory is symlinked into the skills CLI global store, and where lockfile provenance lives.
|
||||
description: Division of skill tiers on Dank workstations — skills CLI global store, omp agents provider, and the authored repo tier.
|
||||
tags:
|
||||
- skills
|
||||
- symlinks
|
||||
- provisioning
|
||||
- dotfiles
|
||||
timestamp: 2026-10-18
|
||||
verified: 2026-10-18
|
||||
---
|
||||
|
||||
# omp Skill Store Wiring
|
||||
|
||||
omp is NOT a registered agent in the `skills` CLI (79-agent registry checked in
|
||||
`dist/cli.mjs` 2026-10-18; see [Agent Support](/tools/vercel-labs-skills/agent-support.md)),
|
||||
so `skills add` never writes to `~/.omp/agent/skills/` on its own. The wiring is
|
||||
manual, retrofitted 2026-10-18:
|
||||
Three tiers, one owner each:
|
||||
|
||||
- **Canonical store:** `~/.agents/skills/<name>/` — real files, written by
|
||||
`npx skills add <owner>/<repo> --all -g` (universal agent, global scope).
|
||||
- **Provenance:** `~/.agents/.skill-lock.json` (store lockfile, version 3): per
|
||||
skill `source` (e.g. `mattpocock/skills`, `vercel-labs/skills`), `skillPath`,
|
||||
`skillFolderHash`, timestamps. 39 entries as of 2026-10-18: 38 from
|
||||
`mattpocock/skills`, `find-skills` from `vercel-labs/skills`.
|
||||
- **omp tier:** every entry in `agent/skills/` (this repo) is a **symlink** to
|
||||
`~/.agents/skills/<name>` — 39 links. `manage_skill` writes real dirs into the
|
||||
separate tier `agent/managed-skills/`; that tier is untouched by this scheme.
|
||||
| Tier | Path | Owner | Content |
|
||||
|---|---|---|---|
|
||||
| Canonical store | `~/.agents/skills/` | `skills` CLI | upstream skills, 38 as of 2026-10-18 (all `mattpocock/skills`) |
|
||||
| Provenance | `~/.agents/.skill-lock.json` | `skills` CLI | v3 lockfile: `source`, `skillPath`, `skillFolderHash` per skill |
|
||||
| Authored | `agent/skills/` (this repo) | Frank, via PR | hand-customized overrides; today only `grilling` |
|
||||
|
||||
## Consequences
|
||||
## How omp loads them
|
||||
|
||||
- `skills update -g` refreshes every skill for omp through the links; the repo
|
||||
records only the link set (which skills are enabled), never content.
|
||||
- A fresh workstation needs two steps: `npx skills add mattpocock/skills --all -g`
|
||||
(+ `find-skills` from `vercel-labs/skills`), then re-create the symlinks;
|
||||
`git pull` alone yields dangling links until the store exists.
|
||||
- `skills ls` from a repo whose layout contains `agent/skills` mislabels those
|
||||
links as Eve project skills (path collision with Eve's `agent/skills` dir);
|
||||
harmless attribution noise.
|
||||
omp is NOT a registered agent in the `skills` CLI (79-agent registry checked
|
||||
2026-10-18; see [Agent Support](/tools/vercel-labs-skills/agent-support.md)) —
|
||||
`skills add` never writes anywhere under `~/.omp`. Instead omp's own `agents`
|
||||
provider reads the store **directly**: `skills.enableAgentsUser` (default true)
|
||||
loads `~/.agents/skills/*/SKILL.md`. No per-skill symlinks in the repo — the
|
||||
repo does not mirror the store; it only holds authored overrides.
|
||||
|
||||
Precedence (omp `omp://skills.md`): authored `agent/skills/` (native, priority
|
||||
100) beats the agents provider; identical copies collapse by realpath, differing
|
||||
same-named copies survive namespaced (`agents/<name>`) with a startup warning.
|
||||
Therefore: **when authoring an override, remove the skill from the store**
|
||||
(`npx skills remove <name> -g`) so the lockfile stays truthful and no
|
||||
namespaced twin haunts the listing. `grilling` was extracted this way 2026-10-18.
|
||||
|
||||
## Updating upstream skills
|
||||
|
||||
```bash
|
||||
npx -y skills update -g # refreshes everything the lockfile tracks
|
||||
npx skills check # drift report vs GitHub tree SHAs
|
||||
```
|
||||
|
||||
Fresh workstation (omp side is two commands — store restore + authored tier
|
||||
arrives with the repo clone):
|
||||
|
||||
```bash
|
||||
npx -y skills add mattpocock/skills --all -g
|
||||
npx -y skills add vercel-labs/skills --skill find-skills --agent universal -g
|
||||
npx -y skills remove grilling -g # authored copy ships in the repo
|
||||
```
|
||||
|
||||
## Managed tier
|
||||
|
||||
`agent/managed-skills/` (auto-learn, priority 5) is separate and untouched by
|
||||
all of the above; authored skills always win name collisions against it.
|
||||
|
||||
## Related
|
||||
|
||||
* [Lock File](/tools/vercel-labs-skills/lock-file.md) — lockfile format and update checking
|
||||
* [Installation Scope](/tools/vercel-labs-skills/installation-scope.md) — symlink vs `--copy` methods
|
||||
* [Lock File](/tools/vercel-labs-skills/lock-file.md) — hash-based update checking
|
||||
* [Agent Support](/tools/vercel-labs-skills/agent-support.md) — full CLI agent registry
|
||||
|
||||
Reference in New Issue
Block a user