oh-my-pi: tailor your agent with extensions and skills

In short: As of September 5, 2026, choose oh-my-pi if you want an integrated coding agent, or Pi if you prefer assembling a minimal core. Use a skill to formalize a recurring method and an extension only to add an executable capability. My recommendation: start with a skill, then add an extension only after identifying a missing action and auditing its code.

The model reasons and produces text. The harness determines what it sees, what it can execute, and, if you enable this capability, what it can retrieve from one session to the next.

Should you choose Pi or oh-my-pi?

Pi, a deliberately minimal foundation

Pi presents itself as a minimal, extensible coding agent for the terminal. Its core provides four tools by default: read, write, edit, and bash. You then choose the models, providers, and customizations that suit the way you work, particularly through extensions, skills, and packages.

This minimalism is not a gap to fill. It is a design decision. Pi deliberately leaves features such as MCP, subagents, and plan mode to extensions or external tools. You start with a small foundation, then compose your environment around your actual needs instead of accepting a predefined bundle.

oh-my-pi, the more integrated fork

oh-my-pi, or omp, is a fork of Pi with a more integrated approach, often described as “batteries included.” It is neither a plugin installed on Pi nor a layer running on top of it: Pi and omp are two different harness options.

omp notably brings together primitives for LSP and DAP, subagents, persistent sessions, optional memory, and unified resource reading. This integration saves you from assembling every capability yourself, but it does not guarantee automatic results. Subagents still require supervision, and memory, which is disabled by default, remains heuristic.

The right mental model is simple: the model interacts with your chosen harness—Pi or omp—which acts on the project through its tools. Pi favors a minimal core; omp integrates more primitives. Your preference depends on how much assembly you want to do and how much control you want to retain.

What can an extension do?

Hooks, tools, and commands

An extension is a TypeScript or JavaScript module that adds or changes executable behavior. It can listen to events in the agent lifecycle, then register tools, commands, shortcuts, flags, or interface elements. It therefore affects actions, not merely how instructions are phrased.

Take a simple rule: no destructive command should run without confirmation. A hook can inspect an action before execution and block it when it violates this rule. A workflow-specific command such as /release-check can run the checks required for a release. The expected result is observable: the dangerous action is stopped, or the checklist is executed. It does not rely on a vague promise of productivity.

A custom tool is an action the model can call directly. An extension provides a broader, event-driven framework that can itself register tools. This distinction helps you choose the smallest technical surface you need.

Power that requires auditing

This power calls for one essential precaution: omp extensions are not sandboxed. They run in the same process with your user account’s permissions. An unknown extension can therefore access anything your session can reach.

Before installing one, review its source code and check the paths it loads, the commands it runs, and the data it sends. Grant the minimum permissions, start by limiting its scope to a test repository, and keep human confirmation for deletion, publication, or any sensitive operation. A useful extension should make actions easier to control, not silently expand the risks.

What is a skill for?

A procedure loaded on demand

A skill packages know-how, a procedure, and references around a SKILL.md file. Its lightweight metadata can be exposed to the agent before the full content is loaded. This progressive disclosure avoids injecting a lengthy procedure into every exchange.

Always define name and description clearly, even if some providers accept more permissive variants. The description should help the agent understand when to use the method. You can then invoke the skill explicitly with /skill:<name>; the skill:// scheme lets the agent read its package on demand.

---
name: release-dedimarco
description: Prepare and verify a bilingual Dedimarco publication.
---

## Procedure

1. Check the French and English versions.
2. Verify the sources, image, and publication criteria.

From one-off prompt to reusable know-how

Level	Duration and scope	Typical content	Example	Main limitation
Prompt	Current task or turn	Immediate objective and context	“Analyze this Astro error”	Often repeated and easily lost
Skill	Recurring sessions and projects	Procedure, constraints, references	Bilingual publishing checklist	Must be kept up-to-date
Extension	Executable capability	Hook, tool, command, integration	Block an action or call an API	Privileged code to audit and maintain

The prompt makes the request, the skill explains how to work, and the extension provides the means to act. omp can also discover skills from several harnesses, notably in .claude/skills/ and .opencode/skills/ layouts. This compatibility can reduce the initial rewriting work, but you still need to verify conventions and behavior in your environment.

How should you combine skills and extensions without piling them up?

The running example: publishing a Dedimarco article

Imagine a release-dedimarco skill. It describes the Astro 7 checklist, alignment between the French and English versions, source verification, image constraints, and quality criteria. It does not publish anything: it gives the agent a stable, verifiable operating procedure.

An extension complements this method with a /release-check command. It can target the relevant files, run the planned checks, and request confirmation before publication. The prompt for the current task remains specific: “prepare the article on this topic and apply the skill.” Each layer therefore keeps a distinct role.

This example is an illustration constructed from the documented APIs, not an official package. Its value lies in the separation of responsibilities: the extension provides the tool, the skill provides the operating procedure, and the prompt sets the immediate objective.

Choose the lightest layer

If you only need something once, start with a precise prompt. If the same method applies to several deliverables, turn it into a skill. Write an extension only when you genuinely lack an executable capability: blocking an action, calling an integration, or exposing a workflow-specific command.

Every component adds maintenance and expands the risk surface. Piling up rules, tools, and hooks does not automatically make the agent better. The right architecture is one where you can still explain, review, and remove every element.

Which customizations are useful for a developer?

Write and publish in two languages

Bilingual publishing is well suited to an explicit method. The skill defines the order of work, identical shared metadata, consistent sections, and source verification. The extension can run authorized checks and report discrepancies. You can then measure concrete results: both files exist, their structures match, and the publication criteria are followed. The model contributes to the writing, but quality is still judged against these observable criteria.

Diagnose a bug methodically

A diagnostic skill prevents the agent from jumping straight to the first plausible fix. It enforces a loop: reproduce the defect, minimize it, formulate hypotheses, instrument, fix the source, and then provide proof. The executable capabilities depend on the surface involved: a terminal for a command-line program, a browser for a web interface, and DAP for inspecting a process’s state. The tool supports the investigation; the procedure keeps it rigorous.

Apply a repository’s conventions

A project skill can record the architecture, validation rules, expected style, and reference paths. The agent no longer has to rediscover these decisions for every task. Specialized tools then let it act without bypassing those rules. Here again, keep method and capability separate: knowing that a change must remain local is not the same as having a tool to make it.

Retrieve useful decisions

omp sessions are persistent, tree-structured, and append-only. They can preserve continuity across a piece of work. Optional memory can also surface previous observations, but it remains heuristic and must never override the current code or your instructions. Store only necessary information and consider its sensitivity. A retrieved past decision is evidence to compare with the repository, not a final truth.

How should you start small and stay in control?

First choose a recurring task with a verifiable outcome: preparing a release, diagnosing an incident, or publishing bilingual content. Write a minimal skill with an explicit name, a useful description, a few steps, and acceptance criteria. Use it within a limited scope, then refine only what proves necessary.

Add an extension only if the method requires an action the harness cannot yet perform or govern. Audit its code, reduce its permissions, and retain human validation for important changes. If a rule, reference, or tool no longer provides value, remove it. An abandoned customization that remains active quickly becomes both debt and risk.

Finally, distinguish three dimensions. Technical capability determines what the agent can do. Method specifies when and how it should do it. Model quality affects reasoning and writing. None of these automatically compensates for weaknesses in the other two. Your context, acceptance criteria, and supervision remain decisive.

Is OpenCode Go an affordable way to try it?

A fixed-budget option

OpenCode Go costs $10 per month as of September 5, 2026. Its published base limits correspond to $12 of usage value over five hours, $30 per week, and $60 per month. They vary by model and may change: treat them as published limits, not a guarantee of how much usage you will receive.

Compare this plan with other access options based on your tasks, models, and usage frequency rather than the displayed price alone.

Why start with GLM-5.3-Flash?

GLM-5.3-Flash is available in the OpenCode Go catalog. Its published rates are $0.15 per million input tokens, $0.50 for output, and $0.03 for cache reads.

It is therefore an affordable starting point to evaluate on a real task, not a guarantee of success or the best choice for every project. Give it a bounded objective, then observe quality, speed, and usage before keeping this model or choosing another one.

You can try OpenCode Go through this referral link. The subscription costs $10 per month as of September 5, 2026. After the first eligible subscription, the referred subscriber and the referrer each receive $5 in Go credit to apply from the console. Self-referrals, previously referred accounts, and accounts that have already received Go benefits are not eligible.

Conclusion

Pi chooses a minimal core for you to compose; omp chooses a more comprehensive integration. In both cases, customization remains clearer when each layer keeps its role: the prompt makes the request, the skill formalizes the method, and the extension executes or governs an action.

I recommend starting with a useful workflow that has a measurable result. Prove its value on a bounded task, retain human validation, then expand the environment gradually. A well-tailored agent is not the one that accumulates the most features, but the one whose rules, capabilities, and limits you understand and control.

Sources

Sources consulted on September 5, 2026:

• Pi Coding Agent — overview, installation, and customization
• oh-my-pi — overview and installation
• oh-my-pi — extensions
• oh-my-pi — skills
• oh-my-pi — session storage
• oh-my-pi — optional memory
• OpenCode Go — pricing, models, and usage limits
• OpenCode — referral program rules