pmos-toolkit

PMOS Toolkit

A Claude Code and Codex plugin for product builders. Turn fuzzy ideas into shipped features, run user research, draft PRDs and design docs, critique UIs, and track personal work — without leaving your terminal.

What makes it different: every workflow has built-in adversarial and user-perspective checks, so the output survives contact with reality:

• /grill interviews you on shaky assumptions before you commit to a direction.
• /msf-req and /msf-wf simulate user friction against requirements and wireframes.
• /simulate-spec pressure-tests a technical design before any code is written.
• /creativity surfaces non-obvious alternatives you'd otherwise miss.
• /ideate runs premortem + inversion + assumption-mapping on a half-formed idea.

Skills are namespaced /pmos-toolkit:<name> — for brevity the rest of this README drops the prefix.

What do you want to do?

How it works

Five cross-cutting capabilities the whole toolkit is built on:

• HTML-primary artifacts with Markdown sidecar. Pipeline skills emit HTML by default (better for review and stakeholder sharing) with a Markdown sidecar for diffing. Controlled by output_format in .pmos/settings.yaml — set once per repo.
• Resumable worktree pipelines. /feature-sdlc runs each feature in its own git worktree with state persisted to .pmos/feature-sdlc/state.yaml. Crash, close the session, switch machines — cd back in and resume from the last checkpoint. /feature-sdlc list shows everything in flight across all feat/* worktrees.
• Auto-tiering by scope. Every pipeline skill detects whether you're doing a bug fix, an enhancement, or a feature, and adjusts depth automatically (Tier 1 = lightweight, Tier 3 = full ceremony). You don't pick the tier; the skill does.
• Adversarial self-evaluation loops. /wireframes, /prototype, /diagram, /survey-design, /artifact, /readme all dispatch a reviewer subagent against the draft, apply approved fixes, and loop up to two iterations before showing you anything. Built-in, not opt-in.
• Persistent workstream context. ~/.pmos/workstreams/ stores product / area / feature scope across repos and sessions. Pipeline skills read it as a context preamble so you stop re-explaining what you're building. Set via /product-context.

• Per-developer run defaults. /complete-dev remembers your last release answers (.pmos/complete-dev.lastrun.yaml) and short-circuits the confirm prompts on subsequent runs. Destructive prompts still fire.
• Parallel subagent execution. /execute --subagent-driven runs independent tasks in parallel waves with two-stage review (spec compliance
  • code quality). /readme's simulated-reader dispatches three reader personas concurrently. /wireframes and /prototype parallelise per-device generation.
• User-extensible templates. /artifact reads custom templates from ~/.pmos/artifacts/; /polish reads custom checks from ~/.pmos/polish/custom-checks.yaml. Bring your own writing-style preset or rubric.
• Per-skill learnings capture. Every skill appends session lessons to ~/.pmos/learnings.md under ## /<skill-name>, then reads them on next invocation. The toolkit gets smarter about your workflow over time.
• Cross-platform, non-interactive ready. The same skill bodies run under Claude Code and Codex CLI. A canonical --non-interactive mode auto-picks recommended answers and defers ambiguous or destructive choices to an open-questions log, so the pipeline runs unattended in headless CI agents.

The build-a-feature pipeline

For the end-to-end "idea → shipped" flow, the skills compose like this:

/ideate? → /requirements → [/wireframes → /prototype] → /spec → /plan → /execute → /verify → /complete-dev
                              optional (UI work)

Adversarial passes are available at every stage:
  /grill          — interview on shaky assumptions
  /msf-req        — user-friction analysis on requirements
  /msf-wf         — user-friction analysis on wireframes
  /creativity     — non-obvious alternatives
  /simulate-spec  — pressure-test the design before code

/feature-sdlc runs this whole chain for you, auto-tiering each stage by scope (bug fix vs. enhancement vs. feature) and persisting resumable state in a worktree.

Every other skill is standalone — invoke at any point.

Install

# Claude Code
/plugin marketplace add maneesh-dhabria/pmos-toolkit
/plugin install pmos-toolkit

Smoke test: run /pmos-toolkit:mytasks or /pmos-toolkit:backlog — both work on a fresh install with no prior artifacts.

Codex (recommended)

Tell Codex:

Fetch and follow instructions from https://raw.githubusercontent.com/maneesh-dhabria/pmos-toolkit/refs/heads/main/.codex/INSTALL.md

Then restart Codex.

git clone https://github.com/maneesh-dhabria/pmos-toolkit.git ~/.codex/pmos-toolkit
mkdir -p ~/.agents/skills
ln -s ~/.codex/pmos-toolkit/plugins/pmos-toolkit/skills ~/.agents/skills/pmos-toolkit

Local development

git clone https://github.com/maneesh-dhabria/pmos-toolkit.git
claude --plugin-dir /path/to/pmos-toolkit

Changes take effect after restarting the session or running /reload-plugins. Plugin caching is keyed by version in plugin.json — bump the version on any skill content change. Both .claude-plugin/plugin.json and .codex-plugin/plugin.json versions must match (enforced by .githooks/pre-push).

Skills live under plugins/pmos-toolkit/skills/<skill-name>/SKILL.md — that path is the only one the loader reads.

To add or revise a skill, use /skill-sdlc <description> (or /skill-sdlc --from-feedback <text|path> to apply retro feedback).

Updating

Claude Code updates automatically via the marketplace. For Codex:

cd ~/.codex/pmos-toolkit && git pull

Requirements

• Claude Code or Codex CLI

Contributing

This is a solo-maintained project. To keep the surface area honest:

• Feedback is welcome — open a GitHub issue, or run /pmos-toolkit:retro at the end of a session and paste the output. /retro produces severity-tagged, per-skill feedback that's the easiest signal for me to act on.
• Bug reports are welcome — issues with a reproducer get priority.
• Unsolicited PRs are not accepted. If you'd like to propose a skill change, run /pmos-toolkit:skill-sdlc --from-feedback <description> on your end, share the proposed diff in an issue, and we'll discuss before any code lands.
• Forks are fine. MIT means you can take the toolkit in any direction you want under your own name.

License

MIT — use it however you want, please keep the copyright notice.