Pstack Omp logo

Pstack Omp

Community
dsebban
pstack-omp

OMP adapter for poteto-mode. Maps canonical pstack roles and lifecycle protocols to current OMP task agents, batching, isolation, agent:// follow-ups, and durable result resources.

Overview

Publisherdsebban
Repositoryskills
Skill namepstack-omp
Stars
72
Forks
6
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by dsebban on GitHub. Read the source before you install it.

Installation

Install the Pstack Omp AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/dsebban/skills/tree/main/skills/pstack-omp
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/dsebban/skills.git /tmp/skills
mkdir -p .claude/skills
cp -r /tmp/skills/skills/pstack-omp .claude/skills/pstack-omp
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Pstack Omp in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Pstack Omp on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Pstack Omp is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

pstack on OMP

poteto-mode is the sole router. It selects the playbook, canonical role, step order, and lifecycle protocol. This adapter translates those choices to OMP only. It never selects a playbook, repeats the playbook index, or changes a playbook gate.

While this skill is active, its role map is the specific pstack execution contract. Generic OMP instructions remain valid outside pstack work.

Canonical role map

Use these exact OMP agent names.

Canonical roleOMP agent
explorerscout
watcherscout
plannertask
designertask
reviewerreviewer
researcherlibrarian
synthesizerreviewer
implementerpoteto-agent
ownerpoteto-agent
mechanicalsonic

Role responsibilities live in skill://poteto-mode. This table only names the agent.

The canonical OMP roster is closed:

text
scout
reviewer
security-reviewer
librarian
task
sonic
poteto-agent
comment-sicko
seance

A canonically routed task item's agent value must be one of those bundled names. Canonical role labels and model aliases are not agent names. task is the default worker, so omit agent for it.

poteto-agent runs implementer and owner work in poteto's style. comment-sicko audits comments for imported skills that name it directly.

Planning and design

The imported warning about a built-in planning subagent describes a source-host mechanism that bypassed the skill contract. This OMP version has no bundled plan agent and no designer agent. Canonical planner and designer work uses task. The brief carries the specialization, such as technical planning or visual and interaction design, and no source-host subagent fields.

Security review

Use security-reviewer for an independent security lane. Keep it read-only and separate from ordinary code review when both are required. A later reviewer session may synthesize frozen reports; it does not replace the primary security review.

Task contract

The root performs every task call. A child never calls task, starts another child, or asks the user directly. Put Do not call task or start subagents under FORBIDDEN in every child brief. task.maxRecursionDepth permits nesting, so the brief is what keeps the tree flat, not the host.

Children start without the parent conversation. Every prompt must stand alone. They receive the configured workspace, context files, skills, and approved plan resources supplied by OMP.

Call shape

One task call is a batch. context is shared immutable background rendered into every child's system prompt; tasks[] carries the participants. A single dispatch is a one-item batch, not a different schema.

json
{
  "context": "Repository root, base SHA, frozen artifacts, constraints, and verification context shared by every item.",
  "tasks": [
    {
      "name": "ParserOverflowFix",
      "solutionSpace": "one fix: bounds check in parse_header, call site given",
      "task": "GOAL\n...\n\nROLE\n...\n\nSCOPE\n...\n\nCONTEXT\n...\n\nACCEPTANCE\n...\n\nVERIFY\n...\n\nTIMEBOX\n...\n\nFORBIDDEN\n...\n\nREPORT\n...\n\nSTANDING\n..."
    }
  ]
}

Required per item: task and solutionSpace. solutionSpace states how open-ended the child's problem is, not how much work it is: whether the fix is given, or which causes and designs remain open. It never mentions sibling items or coordination.

name is CamelCase, at most 32 characters, unique within the call. It becomes the child's agent:// identifier, so choose a name the root can still recognize an hour later.

Optional fields exist only when their setting is on. Check before writing one:

  • isolated requires task.isolation.enabled and no plan mode. Use it for a writer that needs a dedicated worktree, then verify the patch, branch, or applied change OMP reports. A long-lived owner that must accept follow-ups in the same workspace stays non-isolated.
  • effort (lo, med, hi) requires task.enableEffort. When it is off, reasoning depth comes from the agent's configured model role, not from the call.
  • outputSchema and schemaMode require task.structured.
  • tools exposes eval-defined tools to the child.

Never put a model field in a task item. OMP has none.

Keep briefs short and route bulk through local://<name>.md, which parent and children share. Do not paste a large payload inline.

Batched panel

Use one batch call for independent participants:

json
{
  "context": "Shared immutable repository, base SHA, artifacts, constraints, and verification context.",
  "tasks": [
    {
      "name": "CandidateA",
      "solutionSpace": "architecture open; candidate A explores the event-sourced shape",
      "task": "Standalone brief for architecture candidate A."
    },
    {
      "name": "CandidateB",
      "solutionSpace": "architecture open; candidate B explores the state-machine shape",
      "task": "Standalone brief for architecture candidate B."
    }
  ]
}

Each name is unique. context contains common immutable material. Each item still names its exact role, slice, acceptance criteria, verification, forbidden work, and report contract.

Start every participant in one batch before consuming any verdict. Separate writers with isolated workspaces or disjoint output paths. Freeze candidate artifacts before starting reviewers. Freeze reviewer reports before starting a separate synthesizer session.

task.maxConcurrency caps simultaneous children at 32 by default; a larger batch queues rather than failing.

Background completion and follow-ups

Spawns run as background jobs and their results auto-deliver. Record the returned job and agent identifiers. The delivered preview may be truncated.

  • Read the full result from agent://<id>. Nested children are agent://<parent>.<child>.
  • Read the session transcript from history://<id> when the report is incomplete, ambiguous, or suspicious.
  • read proc:// lists live jobs and read proc://<id> inspects one without consuming its delivery.
  • write agent://<id> sends one in-scope correction, answer, authorization, or next coupled phase. It revives a parked session. agent://all broadcasts and is write-only.
  • write proc://<id>/kill cancels stale, superseded, or scope-breaching work.
  • Call wait only when the root is blocked with nothing else to do. Never poll.
  • Never steer a reviewer toward a preferred conclusion.
  • Ignore duplicate terminal deliveries and reject stale artifact generations.

A task result is evidence, not completion. The root inspects the artifact and runs verification.

Brief shape

A dispatch is forbidden until its brief contains:

GOAL
One-sentence outcome executable by a stranger.

ROLE
The canonical role, mapped OMP agent, authority, and expected stance.

SCOPE
Writable and non-writable paths, exact slice or race arm, worktree and branch where applicable, and every output path. State the one-writer assignment.

CONTEXT
Repository root, relevant source paths, base SHA, frozen artifacts, active skill and playbook paths, settled assumptions, and known gotchas.

ACCEPTANCE
Checkable observable outcomes, one per line.

VERIFY
Exact commands, fixtures, runtime probes, comparison baselines, environment requirements, and known false-positive or false-negative risks.

TIMEBOX
A rough cap. At the cap, return partial evidence and stop instead of broadening scope.

FORBIDDEN
At minimum: no child task calls; no subagent spawning; no out-of-scope fixes; no unrequested migrations; no shared-path edits outside ownership; no merge; no direct user questions; no completion claim without executed verification.

REPORT
Require PASS | ISSUES | BLOCKED, semantic session name, branch and exact SHAs where applicable, verdict and evidence, changed files or artifacts, actual verification commands and results, deviations, unresolved risks, and parent actions.

STANDING
Copy the active playbook's standing policy text verbatim when it supplies one.

Canonical protocols

Bounded session

  1. Author one standalone brief.
  2. Start one task with the mapped agent.
  3. Record its semantic name, agent ID, job ID, role, scope, isolation mode, base SHA, and expected artifact.
  4. Consume the async result when delivered.
  5. Read agent://<id>; inspect history://<id> when needed.
  6. Send one write agent://<id> correction only within the same unit.
  7. Inspect the artifact and independently run the promised verification.
  8. Accept the unit only after the parent verifies the reported output.

A role or unit change requires a fresh task.

Panel

  1. Partition independent slices or race arms with one task item per participant.
  2. Start every participant in one batch before consuming any result.
  3. Track participants by semantic name and identifiers, never arrival order.
  4. Let results auto-deliver; wait only when nothing else can proceed, and cancel an abandoned arm explicitly with write proc://<id>/kill.
  5. Ignore duplicate terminal delivery.
  6. Freeze implementation artifacts, branches, head SHAs, reports, and hashes.
  7. Start every independent reviewer in a new batch only after the candidates are frozen.
  8. Freeze verdicts before starting a separate reviewer when synthesis is needed.
  9. Treat synthesis as advice. The root selects and verifies.

Do not mix implementers, reviewers, or synthesizers in one session. Do not let reviewers race a moving head.

Long-lived owner

  1. Start one non-isolated poteto-agent session with the complete owner brief.
  2. Record its agent ID and reuse it. Do not start a sibling owner for the same unit.
  3. The owner works only in its assigned branch and paths and never starts children.
  4. Send a write agent://<id> follow-up only for the next coupled phase, an in-scope correction, an answer resolved from evidence, or explicit authorization.
  5. Require a terminal report at each verification boundary.
  6. Independently verify the boundary before authorizing the next phase.
  7. Stand down on ownership violation, stale generation, or terminal scope breach.

One-shot watcher

  1. Start one background scout task.
  2. Put the exact branch, head SHA, generation, watched predicate, stop predicate, and timebox in the brief.
  3. Require one meaningful event and a terminal report.
  4. Discard a report whose generation no longer matches.
  5. Start a fresh watcher for each new generation.
  6. Stand down when the stop predicate is met or the work is superseded.

A watcher observes. It does not fix, merge, authorize, or silently follow a changed head.

Interactions and decisions

Children resolve uncertainty from source, standing policy, frozen evidence, or the brief. Otherwise they use the safest reversible interpretation and report the assumption, or return BLOCKED with the exact missing decision and evidence gathered.

The root resolves a child question and sends the answer with write agent://<id> to the existing agent. Ask the user only for genuine product preference, unavailable authority, or an irreversible action not covered by standing orders.

Ownership and verification

  • One writer per branch, worktree, mutable state, and output path.
  • Separate sessions own implementation, review, judgment, and synthesis.
  • A task stays inside its assigned unit and role.
  • Isolate concurrent writers unless their outputs are structurally disjoint.
  • A worker's report never verifies its own work.
  • Record branch, base SHA, and exact head SHA or artifact generation.
  • Prefer behavioral proof over type-check-only evidence.
  • A new commit, restack, conflict resolution, or applied patch creates a new generation that voids the prior verdict.
  • Judges and synthesizers advise. The root owns selection, user interaction, external writes, merges, deletion, and final truth.
  • Claim model independence only from returned resolved-model and fallback metadata.

Model routing

OMP resolves a task agent through its current settings, including modelRoles, task.agentModelOverrides, the agent definition, and normal fallback. Agent selection and model selection are separate decisions.

Do not put a model field in a task item. Do not use a model alias as the agent value. Configure routing with /skill:setup-pstack, which writes both records into the active profile's config.yml after validating every selector against the detected catalog.

/skill:setup-pstack --show prints the live agent-to-role mapping. These are settings, not task payload fields. When a playbook requires model independence, read the resolved model each child reports; if two panel agents resolve to the same model, say so rather than claiming a second opinion.

Writing

Apply unslop (skill://unslop) to every reply, brief, report, review, task dispatch, commit message, and agent-facing edit.

Frequently asked questions

What does the Pstack Omp AI skill do?

OMP adapter for poteto-mode. Maps canonical pstack roles and lifecycle protocols to current OMP task agents, batching, isolation, agent:// follow-ups, and durable result resources.

Why use Pstack Omp on TypingMind?

Because you install it once and use it with any model. Pstack Omp is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Pstack Omp in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/dsebban/skills/tree/main/skills/pstack-omp. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Pstack Omp?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Pstack Omp?

As many as you like. As long as a model supports skills, you can use Pstack Omp with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Pstack Omp AI skill free?

Yes. It is published on GitHub by dsebban under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇