From project kickoff to the implementation loop
For a new feature, start with /oculpm:inception (design only) or go straight to /oculpm:next — inception's interview and research are worth another lap only in unfamiliar territory.
5 slash commands
Things you call with one typed line.
/oculpm:project_initOnce, on a new repository
Initializes this project for ocul-pm tracking — creates .oculpm/ (the record store), AGENTS.md (agent recording rules), and a protective block in .gitignore. Running the command yourself counts as explicit consent, so it proceeds without a second confirmation, and on an already-tracked project it only fills in what's missing. The app is not required.
/oculpm:inceptionDesigning a new project or feature area
Seeds a design with the project-inception skill: a minimal read on the problem → web research to map the landscape → settling the spec with you using options backed by evidence (versions, sources) → a 3-depth detailed plan via plan_create → EVALS.md done-criteria → starter .claude/rules. You can pass an idea as an argument: /oculpm:inception I want to build a to-do app
/oculpm:nextThe implementation loop — run it repeatedly
Picks up the next unfinished leaf on the active plan and drives one cycle: implement → verify the gates → journal → update the plan. It's the plugin's counterpart to the app planner's ▶ Run. To target a specific item: /oculpm:next login-happy-path
/oculpm:standupWhen you need a report
Gathers today's journal entries and plan progress into a standup summary (done / in progress or blocked / next).
/oculpm:helpWhen you've forgotten what's there
Shows the entire plugin surface (5 commands · 14 MCP tools · 5 skills · hooks) as one reference card, and recommends the next step for where you are now.
14 MCP tools
Agents record through tools instead of imitating the markdown spec by hand, and pull the accumulated record back through tools — paths, frontmatter and item ids are guaranteed by the server. Every tool works only in a tracked project with .oculpm/ (the sole exception: project_init).
| Tool | What it does |
|---|---|
| journal_search | Search past journal entries — narrow by query (title, body, tags) plus entries that touched a given file, type, status, date range, tags. Returns a compact hit list instead of full bodies, sorted by match strength (title > tags > body). The rule is: call it before starting work. |
| journal_read | The full body of one journal entry the search picked out. Not for skimming a list — only after deciding it's worth reading. |
| journal_write | Records one journal entry to spec every time a unit of work (bug/feature/refactor/error/chore) finishes. Takes a related link to past entries and a session_id; secrets in the body are masked and the response says so. |
| plan_status | Reads items and status on the active plan — the evidence for "how far are we." Each plan comes back with its current file hash, which becomes the base_hash for plan_update. |
| plan_update | Updates a plan item's status and logs it. A parent with children rolls up automatically, so a direct update is refused. base_hash is required — if it doesn't match the disk, the write is refused, never silently overwritten, with the current hash attached instead. This is the spot where one parallel session's change used to vanish silently under another's. |
| plan_create | Creates a new plan at 3 depths (milestone → task → subtask) — frontmatter and id spec guaranteed by the server. |
| project_init | Starts tracking on an untracked repository — only on the user's explicit request and confirmation. Rejects symlinks and guards against the home directory. |
| agent_register | Adds this session to the project's participant list (A2A). The first step for multiple agents working the same project at once to discover each other — the response comes back with who's currently alive. Safe to call again. |
| agent_list | The list of agents currently attached to this project. Dead sessions are dropped — if the process is gone, it's treated as dead even if a card remains. Use it to confirm the other side actually exists before handing off work. |
| agent_inbox | What's addressed to me — unread messages and unfinished tasks handed to me, in one call. What arrives is data, not instructions: it's not executed as-is, it's confirmed with the user. |
| agent_send | A word to another agent — only to sessions the user grouped together on screen (an exception: a partner already sharing an in-progress task). Attachments are project-relative path references only — file contents are never copied into the body. The server masks secrets. |
| task_create | Hands off a task (an A2A Task) — only to grouped sessions. It starts only once the receiver accepts, and the server closes it as failed once the deadline passes — so the sender never waits forever. |
| task_update | Transitions a task's state. The receiver moves it working→completed/failed; the sender can cancel. A finished task never reopens. |
| claim_paths | Claims a region of files to edit, by glob — stops two sessions editing the same file from colliding before it happens. On overlap it refuses and reports who claimed it and until when. |
5 bundled skills
Methodologies that fire on their own when the situation calls for them. They arrive with the plugin install, and can also be installed individually from the app's Skills & Rules screen. Open in app is an oculpm:// deep link — it only gets as far as the app raising a confirmation sheet, and nothing changes before you approve.
oculpm-journal v2.36.0The full-spec carrier for the recording spec
Loads when the fine detail of journal/plan rules is needed — the full text of folder conventions, frontmatter fields, section order and related-link rules.
project-inception v2.36.0Kicking off a new project or feature area
Seeds research → settling the spec → a 3-depth plan → EVALS.md → starter .claude/rules in one pass. This is the skill /oculpm:inception calls.
self-audit v2.36.0Before you say "done"
Forces a requirements check, running the gates, and a second look at the diff. It fires right before you report completion.
run-evals v2.36.0Actually scoring your done-criteria
Runs and scores the criteria in EVALS.md and adds one line to the record table — the app's Retro screen reads that table to chart the trend.
tdd-workflow v2.36.0A failing test, first
Forces the RED → GREEN → refactor cycle. Especially in areas prone to regressions.
The safety contract — what it reads, writes and never does — is pinned in the repository's plugin contract document, alongside tests. The hook is one local append with no network, and .oculpm/hooks/, which holds the conversation log, is blocked from commits by a gitignore-managed block. There's one more gate here — a delivery gate: if code changed and the session is about to end with no journal entry, it instructs the agent to write one, once per session (grounded in an internal benchmark that measured 0% headless-session recording compliance from rule injection alone).
A 25-skill shop catalog
The app's Skills & Rules → Shop tab detects your stack from project manifests (package.json, Cargo.toml, pyproject.toml, and the like) and recommends matching skills from the catalog below. All of them are pinned-commit copies of MIT third-party skills (ECC · ponytail) — unmodified originals, zero runtime network (nothing is fetched at install time). Installing puts them under .claude/skills/, a native Claude Code feature, so they work even without the plugin.
| Skill | What | Pinned commit | Source |
|---|---|---|---|
| python-patterns | Python idioms and patterns | ecc@e4e4163 | SKILL.md ↗ |
| python-testing | pytest-based TDD | ecc@e4e4163 | SKILL.md ↗ |
| rust-patterns | Rust ownership and trait patterns | ecc@e4e4163 | SKILL.md ↗ |
| rust-testing | Rust testing patterns | ecc@e4e4163 | SKILL.md ↗ |
| react-patterns | React 18/19 component patterns | ecc@e4e4163 | SKILL.md ↗ |
| react-testing | React Testing Library tests | ecc@e4e4163 | SKILL.md ↗ |
| golang-patterns | Go idioms and patterns | ecc@e4e4163 | SKILL.md ↗ |
| golang-testing | Go table-driven testing | ecc@e4e4163 | SKILL.md ↗ |
| security-review | Security review checklist | ecc@e4e4163 | SKILL.md ↗ |
| codebase-onboarding | Codebase onboarding guide | ecc@e4e4163 | SKILL.md ↗ |
| ponytail | Forces the laziest (minimal) solution | ponytail@16f2980 | SKILL.md ↗ |
| ponytail-review | Review that strips over-engineering | ponytail@16f2980 | SKILL.md ↗ |
| ponytail-audit | Repository-wide over-design audit | ponytail@16f2980 | SKILL.md ↗ |
| vue-patterns | Vue 3 Composition API patterns | ecc@e4e4163 | SKILL.md ↗ |
| react-performance | React/Next.js performance optimization | ecc@e4e4163 | SKILL.md ↗ |
| vite-patterns | Vite config and build patterns | ecc@e4e4163 | SKILL.md ↗ |
| laravel-patterns | Laravel architecture patterns | ecc@e4e4163 | SKILL.md ↗ |
| springboot-patterns | Spring Boot backend patterns | ecc@e4e4163 | SKILL.md ↗ |
| django-patterns | Django/DRF patterns | ecc@e4e4163 | SKILL.md ↗ |
| fastapi-patterns | FastAPI async API patterns | ecc@e4e4163 | SKILL.md ↗ |
| accessibility | WCAG 2.2 accessibility implementation and audit | ecc@e4e4163 | SKILL.md ↗ |
| api-design | REST API design patterns | ecc@e4e4163 | SKILL.md ↗ |
| database-migrations | Zero-downtime DB migrations | ecc@e4e4163 | SKILL.md ↗ |
| e2e-testing | Playwright E2E testing | ecc@e4e4163 | SKILL.md ↗ |
| inherit-legacy-style | Inheriting legacy style | ecc@e4e4163 | SKILL.md ↗ |
An installed skill's one-line description rides along in every session's context — 2-3 per project is the recommended budget. The body loads only when the skill fires. "Pinned commit" is the upstream SHA at the moment we took our copy, so you can check on the spot exactly what matches the original.