skill

omp-skills

Personal skills library for the Oh My Pi coding agent, mostly adapted from Superpowers

fgladisch/omp-skillscommunitylistedunreviewed

Set up

Skills are installed by placing their folder where your agent loads skills.

Download ZIP from GitHub Open the repository

The download comes from github.com/fgladisch/omp-skills itself, not from our server, so what you get is exactly what its author published.

Install instructions come from the README

Skills do not use an MCP config. Follow the steps in the README below.

README

synced Oct 25, 2026

omp-skills

A personal skills and command library for Oh My Pi. The content targets OMP's built-in tool surface and execution workflows.

Installation

OMP discovers user skills one directory below ~/.omp/agent/skills/ and command files in ~/.omp/agent/commands/. Clone the repository, then symlink each entry:

git clone https://github.com/fgladisch/omp-skills.git ~/.omp/omp-skills
mkdir -p ~/.omp/agent/skills ~/.omp/agent/commands
for skill in "$HOME"/.omp/omp-skills/skills/*; do
  ln -sfn "$skill" "$HOME/.omp/agent/skills/$(basename "$skill")"
done
for command in "$HOME"/.omp/omp-skills/commands/*.md; do
  ln -sfn "$command" "$HOME/.omp/agent/commands/$(basename "$command")"
done

For local development, replace "$HOME"/.omp/omp-skills with the path to this checkout. If upgrading from code-review, remove its old symlink from ~/.omp/agent/skills/ and rerun the installation loops to discover local-code-review and the restored pr-create command. Restart OMP after adding or removing skills or commands so discovery runs again.

Commands

Command	Purpose
`local-review-cycle`	Review local changes in Hunk and apply fixes until LGTM
`pr-create`	Create a PR and address review feedback until LGTM

Skills

Skill	When to use
`analyze-youtube-video`	When the user shares a YouTube URL or asks what a video says; fetches only its transcript with yt-dlp for analysis
`commit`	When the user asks to commit changes; follows repository conventions with gitmoji as the fallback
`finalizing-changes`	When a coherent set of changes is ready to validate and then commit, merge, publish as a PR, or retain
`local-code-review`	When reviewing local code changes in a working tree, branch, commit, or defined file set; findings land as Hunk notes
`systematic-debugging`	When a bug, failing test, build failure, performance regression, or unexpected behavior needs diagnosis
`test-driven-development`	Before the first production-code edit for any behavior change or bug fix
`verification-before-completion`	Before claiming work is complete, fixed, passing, reviewed, ready, committed, or integrated

Skill dependency graph

flowchart TB
  SD["systematic-debugging"]
  TDD["test-driven-development"]
  CR["local-code-review"]
  V["verification-before-completion"]
  C["commit"]
  F["finalizing-changes"]

  SD -. "when a regression cycle is feasible" .-> TDD
  TDD -. "when change risk warrants review" .-> CR
  CR --> V
  TDD --> V
  SD --> V
  F -. "when the outcome requires a commit" .-> C
  C --> V
  F --> V

Arrows mean the source skill explicitly applies the target skill, and dashed edges are conditional. TDD requests independent review only when compatibility, security, data-integrity, or operational risk warrants the additional pass.

OpenSpec (optional)

OpenSpec is the recommended way to plan changes with these skills; it replaces OMP plan mode. Each change gets a proposal, delta specs with WHEN/THEN scenarios, a design, and a task list before code is written. The skills work without it. When the current work implements an active OpenSpec change, they also use its artifacts:

Skill	With an active OpenSpec change
`test-driven-development`	Turns each delta-spec scenario into a failing test before the task that implements it
`verification-before-completion`	Treats checked `tasks.md` items as claims that need evidence; runs `openspec validate`
`local-code-review`	Gives reviewers the proposal and delta specs as the intended behavior
`finalizing-changes`	Writes the pull request What and Why from the proposal; leaves archiving until after merge

Initialize each repository with the core profile:

openspec init --tools oh-my-pi --profile core

A change runs through these steps:

/opsx-explore to investigate when the idea is still open.
/opsx-propose <idea> to create the change; review and edit its artifacts.
Create the topic branch, then /opsx-apply to implement the tasks.
/local-review-cycle or local-code-review to review the result.
finalizing-changes or /pr-create to publish it.
After the merge, /opsx-archive on the base branch to merge the delta specs into openspec/specs/, then commit the result.

OMP tooling

ask provides structured decisions; no extension-provided selection tool is required.
read, glob, grep, lsp, edit, and write handle repository inspection and changes before shell fallbacks.
debug and browser verify runtime and UI behavior directly.
task, hub, and todo provide parallel agents, process supervision, and phase tracking.
Hunk is required for local-code-review and local-review-cycle: findings, decisions, and fixes are recorded as note threads in a live hunk diff session, and verification-before-completion checks those threads before completion claims.
Skills and their supporting files are addressable through skill://<name>.
Project instructions live in AGENTS.md; OMP loads them as repository context.

License

MIT — see LICENSE.