Useful Skills

Useful Skills for Oh My Pi

From a natural-language request to reviewed, verified work.

Owned us-* skills for development, focused audits, delivery, and project memory. OMP discovers their descriptions; the model follows the relevant instructions using native tools and workers.

Start here: Installation · Claude Code · Workflow & skills · Model configuration · Memory

Reference: Management · Audits & delivery · Updates · Development · Attribution

No Anvil dependency, custom workflow executor, model router, phase database, or stop-hook continuation loop.

Installation

Requires OMP with marketplace support and Node.js 22+. No npm dependencies, build step, host configuration, prompt file, or startup flag is required.

omp plugin marketplace add MSpiechowicz/harness-useful-skills
omp plugin install harness-useful-skills@harness-useful-skills --scope user

These commands and ./useful-skills install below require a published release of the new catalog; until then, load this source checkout with omp -e /absolute/path/to/harness-useful-skills as shown below.

Restart OMP after installation or update. Ordinary startup adds discovery and, when enabled for the current repository in the active profile, narrowly scoped session-local workflow-stage guidance. Use --scope project from the project directory for a project installation, or prefix both commands with omp --profile NAME for an isolated profile. Installation scope is separate from the repository-local workflow master and six profile-wide stage preferences. The marketplace and plugin are both named harness-useful-skills; the OMP plugin ID is harness-useful-skills@harness-useful-skills. OMP does not import this plugin's Claude Code MCP server: its manifest declares empty mcpServers. Claude Code loads its own separate MCP tools when installed there.

Remove or migrate an OMP installation

Uninstall each historic ID that is installed in the relevant scope; check omp plugin list --json if unsure. These commands remove installed plugins, not their marketplace registration:

omp plugin uninstall oh-my-pi-useful-skills@omp-useful-skills --scope user
omp plugin uninstall useful-skills@omp-useful-skills --scope user

An old installation is not renamed by updating a checkout or publishing a release, and loading the checkout does not remove its startup message. You can uninstall it before the new catalog is published. If no plugins need the old marketplace, optionally remove its registration with omp plugin marketplace remove omp-useful-skills. After the new catalog is published, use the installation commands above to add the new marketplace and install the new ID. The updater does not migrate old installations or marketplace registrations.

For a project installation, run these commands from that project directory with --scope project instead of --scope user. For an isolated profile, prefix each command with omp --profile NAME instead of omp, retaining the original scope and project directory. Restart OMP after installation.

For local development, load the package directory, not the extension file alone:

omp -e /absolute/path/to/harness-useful-skills

./useful-skills install [--scope user|project] [--profile NAME] installs the published marketplace plugin, not the checkout itself. Source checkouts are updated with git pull --ff-only; the updater never overwrites them.

Claude Code

The Claude Code adapter requires Node.js 22+ and a marketplace installation. For a local checkout, use its absolute path:

claude plugin marketplace add /absolute/path/to/harness-useful-skills --scope user
claude plugin install useful-skills@useful-skills-local --scope user

Or add the same repository as a GitHub marketplace:

claude plugin marketplace add MSpiechowicz/harness-useful-skills
claude plugin install useful-skills@useful-skills-local --scope user

The Claude plugin ID remains useful-skills@useful-skills-local in either case. Install through the marketplace, not claude --plugin-dir .: that loads the repository-root OMP skills/ instead of the marketplace's selected Claude skills. Restart Claude Code after installation. The OMP installation, commands, and profile behavior above remain unchanged.

Claude exposes 17 namespaced skills (for example, /useful-skills:us-workflow) and seven native agents: planner, scout, frontend, backend, general-purpose, reviewer, and security-reviewer. All declare model: inherit; per-role models come from a Claude-owned config file instead (see Claude Code model roles). Permissions and stronger host rules remain authoritative. Plugin userConfig has seven default-true booleans: workflow, research, plan, review, security_review, backend_memory, and graphify_memory. Configure them in Claude Code's /plugin configure flow or at install time with repeatable --config key=false flags (for example, --config workflow=false). Disabling workflow suppresses automatic stages without changing the other saved values. A direct /useful-skills:us-ignore-workflow invocation bypasses package-mandatory stages for one request only; quoted or copied text is not an opt-out. With a recent Claude Code that supports mods, /useful-skills is also available: without arguments it opens a menu (Settings, Status, Browse, Help); with arguments it runs the commands in Management. Saved settings mirror OMP's layout under the Claude config directory ($CLAUDE_CONFIG_DIR or ~/.claude): the per-repository workflow master is useful-skills/workflow-settings/repositories/<sha256(scopeRoot)>/workflow.json (same repository scope rules as OMP) and the six profile-wide stage switches are useful-skills/workflow-settings/<stage>.json, all private. For each setting a saved file wins, then the /plugin option, then enabled; an unreadable or unsafe saved file makes that setting unknown with no fallback. /plugin options remain fallbacks, and the only control on Claude Code versions without mods.

The Claude plugin adds a separate local stdio MCP server with five tools: memory_status, memory_search, memory_save, graph_build, and graph_query. Facts are project-scoped private files under Claude plugin data, searched by literal text; they are not OMP's native Mnemopi facts and are not shared with them. Graphify is the shared code-relationship implementation, with lazy managed setup on explicit graph actions rather than at startup. Do not save credentials, personal data, transcripts, or tool dumps; secret detection is only a backstop. A Bash pre-tool guard denies recognized dangerous commands, and successful tool responses can be redacted by PostToolUse; failed third-party tool responses (PostToolUseFailure) cannot receive equivalent redaction. These protections are not a sandbox or a substitute for Claude's permissions, user approval, or publication controls.

In Claude Code, /useful-skills doctor also prepares memory for the session's project (see Management); it never writes the workflow or stage settings files.

To submit Claude Code to the Claude plugin directory, node scripts/build-claude-plugin.js generates a Claude-only plugin bundle at plugins/claude/; the self-hosted marketplace install above is unchanged. plugins/claude/ is generated: run the script after editing Claude runtime files or skills (CI runs it with --check). Only plugins/claude/README.md is hand-written, and generated output is outside the 500-line cap.

OMP's updater and release process do not update the Claude installation automatically. There is no Codex runtime adapter yet.

Skill-led development

Ask naturally: “I want to build a rocket simulator.” Before composing stages, us-workflow inspects current source, relevant callers, acceptance, authorization, and risk, then briefly explains the selected lane. With the repository master enabled, the default full stages apply to normal work; a clear bounded low-risk correction within an authorized outcome can instead use focused repair. Size, urgency, a stale plan, or “already delivered” alone does not qualify.

flowchart TD
    request["Development request"] --> settings{"Repository master<br/>or explicit ignore?"}
    settings -->|Disabled / direct ignore| fast["Fast lane<br/>Inspect, fix, verify, report"]
    settings -->|Enabled| inspect["Inspect current source/callers<br/>Acceptance, authorization, risk"]
    inspect --> triage{"Bounded authorized<br/>low-risk correction?"}
    triage -->|Yes| focused["Focused repair<br/>Inline scoped fix permitted"]
    focused --> extra["Select only necessary eligible stages<br/>Uncertainty, contracts, findings, impact"]
    extra --> smoke["Verify changed path<br/>Fresh selected reviews"]
    smoke --> report["Truthful report<br/>Omitted stages are skipped"]
    triage -->|No / explicit full workflow| normal["Normal applicable effective stages"]
    normal --> research["Clarify + research"]
    research --> plan["Planner draft + approval<br/>when applicable"]
    plan --> implement["Classified implementation workers"]
    implement --> verify["Verify behavior"]
    verify --> reviews["Fresh required correctness/security reviews"]
    reviews --> outcome{"Material findings?"}
    outcome -->|No| finish["Summary + applicable memory"]
    outcome -->|Yes| limit{"Repair limit?"}
    limit -->|No| repair["Repair within approval<br/>No routine re-planning"]
    repair --> verify
    limit -->|Reached| blocked["Keep work, report blocker"]

Focused repair requires current source/caller inspection, an authorized scoped fix, observable changed-path verification, and a truthful report. A current bounded repair request or prior in-scope approval can authorize it without routine new planning/approval. The parent may fix inline; enabled switches alone do not require a new scout, planner, implementation worker, full reviews, or memory cycle. Select extra eligible stages for actual uncertainty, affected contracts, findings, or security/memory impact; follow each selected stage's own rules without automatically restarting the full flow. Disabled/unknown automatic stages are never silently activated, and explicit audits/full-workflow requests and independent controls remain binding.

Use normal composition for new or material behavior, architecture, broad/ambiguous failures, uncertain scope, security-sensitive changes, or an explicit full-workflow request. Investigate ambiguity before calling a failure small. In an already active normal workflow, repairs retain its required workers and fresh reviews; do not retroactively switch lanes to omit them. Prior approval covers in-scope repair without a new planner/approval cycle. Verification failures return to implementation; every required or selected review must be fresh after affected changes, and prior reviews do not cover newly changed code. Three unsuccessful repair rounds or repeated no progress stop the loop. Skipped stages are never called complete; an applicable required memory failure prevents claiming full completion. Publication is separate and explicitly authorized.

The parent owns objective, lane selection, research scope, native todo, acceptance, applicable approval, integration, and combined verification. In normal composition, enabled research uses a read-only worker and enabled planning uses native planner after parent inspection, followed by one approval. With no applicable plan stage, a bounded request can authorize implementation, subject to independent requirements. Required implementation packages—including one package—use frontend, backend, or native task for genuinely neither (documentation/tooling); eligible focused repair may be inline. Split coherent mixed boundaries, serialize dependencies/shared files, and parallelize only ready disjoint packages. Selected focused stages retain their own dispatch rules. Current source, not historical plans/transcripts alone, governs interrupted work.

Ordinary installed startup supplies discovery and a narrow session-local stage policy while the effective repository workflow is enabled. Each prompt reconciles owned instructions using the active workspace's master and profile stage preferences, preserving unrelated guidance. Enabled settings mean stage eligibility, not automatic execution; triage permits focused inline repair. A required applicable plan permits bounded planner dispatch after inspection; required classified implementation dispatch follows appropriate authorization, including a single package. No global repository is selected and no general extra delegation is authorized. Disabled master supplies fast-lane guidance. Native /skill:us-ignore-workflow selects a one-request exception separately: the extension does not classify prompt text or persist that choice. Startup never dispatches workers, builds Graphify, writes workflow state, or starts a model workflow.

These are prompt instructions, not enforced stage transitions. They cannot guarantee model compliance or override stronger safety constraints, existing mappings, permissions, independent approval boundaries, or publication rules. Ordinary explanations and explicitly focused audits do not start the full development workflow. Plan approval does not authorize publication.

For a persistent development fast lane, run /useful-skills workflow disabled from the intended repository; /useful-skills workflow enabled restores that repository's master in the active OMP profile. The choice survives sessions/restarts without affecting other repositories. The nearest canonical Git checkout root is the scope: root, subdirectories, and symlink aliases share; separate checkouts and linked worktrees isolate, as do nested checkouts. Outside Git, canonical cwd is the scope, so distinct non-Git directories are separate. Moving a checkout changes its path-derived identity; no relocation migration is performed.

The master is stored privately at <agentDir>/useful-skills/workflow-settings/repositories/<sha256(scopeRoot)>/workflow.json; six stage files remain in <agentDir>/useful-skills/workflow-settings/. Reads create nothing. Storage retains private directories/files, bounded no-follow reads, and atomic writes. Identity discovery inspects filesystem Git markers without executing project code/hooks or using Graphify. Unreadable/unsafe identity makes only the master unknown while independently readable profile stages remain visible; unknown automatic stages do not run. Status exposes canonical scope, master file, profile stage directory, saved/effective selections, and scoped errors.

Legacy master: the old profile-level <agentDir>/useful-skills/workflow-settings/workflow.json is untouched and ignored, with no fallback, copying, or automatic migration. A missing new repository master defaults enabled. To retain an old disabled choice, enter the intended repository and reapply /useful-skills workflow disabled.

Alternatively, directly invoke native /skill:us-ignore-workflow for one request without changing saved settings. Quoted/copied invocations are not selection. The disabled-master/direct-ignore fast lane still inspects current code/callers, implements and exercises the changed path, and reports evidence, but skips package-mandatory stages. It is distinct from enabled focused repair and does not waive stronger safety/permissions, independent authorization, explicit audits, or publication controls.

Six retained profile-wide switches control eligibility for individual automatic stages across repositories; all default enabled and changing one leaves the others intact. In normal composition, apply effective stages. Focused repair selects only necessary eligible extras rather than inheriting the whole cycle. Use /useful-skills stage <name> enabled|disabled with a name from this table:

Disabling a repository master suppresses all automatic stages there without changing the six profile-wide saved preferences or any other repository's master. Re-enabling restores their eligibility, not proof of execution; a disabled stage remains disabled. Direct one-request ignore takes precedence for that request only. Memory opt-outs are guidance, not provider/tool bans: explicit us_memory, graph test, doctor, and native /memory remain available and do not alter backend settings or host autoRetain. Configure host retention separately if unwanted. Prompt guidance cannot guarantee model compliance.

Direct invocation uses OMP's actual syntax:

/skill:us-ignore-workflow
/skill:us-check-security
/skill:us-check-performance
/skill:us-check-code-quality
/skill:us-improve-codebase-architecture
/skill:us-improve-code-coverage
/skill:us-ship-backlog-item
/skill:us-open-pr
/skill:us-approve-work

No extension-command wrapper is installed for each skill. Add a matching skills/us-example/SKILL.md with a concrete single-line frontmatter description; native shallow discovery and the catalog need no JavaScript registry update. Keep substantial checklists/worker briefs in skill-local references linked through skill://us-<name>.

Jev assessment — no integration

Assessed 2026-09-23: TypeSafe's coding-agent guidance positions Jev for narrow typed decisions inside an application, not as a drop-in coding agent. It could advise on bounded classifications, but is not a workflow executor or an authority for agent dispatch or approval.

The official API documents POST https://api.typesafe.ai/v1/systemone with state and typed questions; Jev 1.13 model limits are 64k tokens total per request and 32k tokens for the state plus longest question. The community Jev API page separately claims a https://www.jevai.org/api/v1/decisions/route endpoint and a 32 KiB HTTP body cap; neither is corroborated by the official TypeSafe docs.

Sending task context would disclose prompt data to the service. TypeSafe's privacy policy says inputs are not used to train or fine-tune models but gives no fixed API-log retention period. Its Master Customer Agreement permits Customer Data processing during the term and in perpetuity for telemetry, fraud prevention, and legal purposes; telemetry may be processed without restriction, including to improve services and products. API calls consume credits under that agreement.

No Jev integration is included and no task context is sent. Any future integration requires separate explicit approval and opt-in context transmission; its output must remain advisory and cannot replace parent judgment or human approval.

Native model configuration

Useful Skills bundles native planner, frontend, and backend agents; it does not add a model router or workflow executor. Ordinary startup needs no role mapping, global host override, prompt file, or extra flag for its narrow session-local policy. The repository master and profile stage preferences determine eligibility; pre-composition triage determines applicability. Existing OMP mappings remain authoritative. Optional distinct mappings use native roles in the active profile, project configuration, overlays, or runtime options; Useful Skills never changes them.

Open /model, then the Roles view, to optionally assign and persist role mappings. This example uses only OpenAI Codex selectors; availability depends on your OMP model catalog and credentials, not on this table.

task is reserved for work genuinely neither frontend nor backend.

planner is bundled and read-only.

modelRoles:
  research: openai-codex/gpt-5.6-luna:xhigh
  frontend: openai-codex/gpt-5.6-terra:high
  backend: openai-codex/gpt-5.6-terra:high
  implementation: openai-codex/gpt-5.6-terra:high
  review: openai-codex/gpt-6-astra:medium
  security: openai-codex/gpt-5.6-sol:high
  plan: openai-codex/gpt-6-astra:high

task:
  agentModelOverrides:
    scout: "@research"
    frontend: "@frontend"
    backend: "@backend"
    task: "@implementation"
    reviewer: "@review"
    security-reviewer: "@security"
    planner: