pm-brain: a curl pipe into tar, 404 of 406 checks, and no CI

The install pipes curl into tar and tracks a branch name

Stage one installs a skill and nothing else. On macOS, Linux, WSL or Git Bash it is one pipeline:

mkdir -p ~/.claude/skills && \
  curl -L https://github.com/phuryn/pm-brain/archive/refs/heads/main.tar.gz | \
  tar xz --strip-components=3 -C ~/.claude/skills pm-brain-main/.claude/skills/pm-brain/

Three things are fixed in that line. The source is `refs/heads/main`, so the install follows whatever is on the default branch at the moment you run it. There is no tag and no checksum, so there is no way to tell afterwards which revision landed. And the strip depth is hardcoded to three, because the archive unpacks to `pm-brain-main/` and the path has to be walked down to the single skill folder. The PowerShell variant does the same job with `irm`, `Expand-Archive`, `Copy-Item -Recurse -Force` and a `Remove-Item` of the temporary files. Both paths are explicit that only `.claude/skills/pm-brain/` is copied, and that `example-brain/`, `tests/` and `docs/` stay on GitHub to be browsed.

Two checks fail and the suite is described as the floor

The research preview notice is the most useful paragraph in the README because it quantifies the state of the thing. It says the architecture has months of dogfooding behind it on a sister content brain, that the product as installed by real product managers in real organizations is days old, and that the eval suite, with 404 of 406 checks passing, is the floor. So the suite does not fully pass, and the two failures are not presented as bugs awaiting a fix but as the current baseline. There is a results file linked from the badges at `tests/RESULTS.md`. The repository layout is four entries plus agent files: `.claude/`, `example-brain/`, `tests/` and `docs/`, with the skill itself at `.claude/skills/pm-brain/`, an example instance pre-scaffolded for browsing, the eval suite described as synthetic scenarios plus a harness, and documentation covering architecture, how it works, testing and prior art.

The dogfooding ran on a content brain, not a product one

The months of usage behind the design are attributed to a sister content brain, which is a different domain from the product management case the tool targets. The distinction matters because the file layout encodes product concepts: hypotheses written as testable statements, decisions recorded with the evidence trail and what would reopen them, and one file per stakeholder carrying their asks and concerns. A content brain has none of those, so the structure that gets used hardest in daily operation is the part with the least prior use. What the walkthrough offers instead is a narrative rather than a record: a document titled A week with PM Brain, Lena's first five days, described as a short story of one product manager using it on a real team, and recommended as the starting point for newcomers. There is also a sister repository for skills, `github.com/phuryn/pm-skills`, linked from the badges.

Provenance is a four-level hierarchy stored as readable text

The fourth step of the loop is the one that distinguishes this from a notes app. Every load-bearing claim wears a marker drawn from four sources: a documented interview, a verbal stakeholder comment, your hunch, or general industry knowledge. The tags carry an implicit ranking, documented outweighs verbal and verbal outweighs intuition, and the ranking is deliberately not hidden in code. The point is that you can see when the brain is leaning on intuition and override it when your judgement says otherwise, which means the weighting is an argument you read rather than a constant you trust. The full tag list lives in a glossary under `docs/`, and a worked end-to-end example sits in a how-it-works document. The propagation step that runs just before it explains why this matters: one artifact often touches four to six files across the durable layer.

Bootstrapping writes six directories into your working folder

Stage two is per product. You change into a folder, start `claude`, and run `/pm-brain`. The skill then decides what it is looking at: an empty folder gets a fresh start and is called greenfield, while a folder holding existing product artifacts such as Notion exports, a Jira CSV or meeting notes gets read and absorbed and is called migration. Either way a five-batch interview captures company, role and current priorities, the scaffold drops in, and the brain commits locally and never pushes. After that the working directory carries six folders. `knowledge/` holds your stable picture of strategy, product, users, market and org. `hypotheses/` holds things you are tracking evidence for. `decisions/` holds calls with their evidence trail and what would reopen them. `stakeholders/` holds one file per person. `ingestion/` holds the synthesis of everything read, and `source/` holds untouched originals so the audit trail stays intact.

Migration is current state only and backfilling is discouraged

One callout is unusually directive about what not to do. Migration is for your current state, and old artifacts should not be backfilled retroactively. The note names the failure directly: do not try to manually ingest 200 old interview transcripts and six months of Slack threads, because forcing them in now wastes a weekend and clogs the durable layer. The stated alternative is that a stale artifact will come up through current work and you will ingest it then. That is a real design position rather than a limitation worked around, and it follows from the propagation model, since one artifact touching four to six files makes bulk ingestion a combinatorial problem rather than a slow one. The README also states plainly what the tool is not: not a notes app, not a chatbot with memory because the memory lives in your repo rather than in Claude, and not a vector database because every file is plain markdown you can grep.

The suite runs locally because there is no .github directory

The root listing has `.claude/`, `.gitignore`, `AGENTS.md`, `CLAUDE.md`, `LICENSE`, `README.md`, `docs/`, `example-brain/` and `tests/`. There is no `.github/` directory, so nothing in this repository runs the eval suite on a schedule or on a pull request. A project whose central claim is a pass rate of 404 out of 406 has no automation holding that number in place, and the reported figure comes from a file, `tests/RESULTS.md`, that a human wrote at a moment in time. Two agent instruction files sit at the root, `AGENTS.md` and `CLAUDE.md`, which is the pair a repository uses to be readable by more than one agent runtime. The recorded primary language for the repository is Python, which reflects the eval harness in `tests/` rather than the product, since the deliverable a user installs is a skill folder.

The Friday sweep is a command you run, not a job that runs

Six commands make up the interface, and one of them carries the maintenance burden. `/ingest` takes a thing, a file, a paste or a quick note in chat, works out whether it is an interview, a meeting, a market signal or ad-hoc, and routes it. `/prep` produces a one-page brief before a meeting with their open asks, last unresolved concern and suggested questions. `/ideate` is described as synthesis rather than brainstorm: it loads strategy, insights and hypotheses and surfaces three to seven directions, each tagged with the evidence behind it. `/risk` runs a five-area scan and drafts hypothesis stubs for any area with no coverage. `/plan` produces a six-block draft plan covering what we know, assumption against evidence, who to interview, hypotheses to open, experiments to run and decision points. And `/review` is the weekly sweep: six checks across the brain, fixing small things directly and drafting the larger ones for your call.

Editorial conclusion

pm-brain suits a product manager who already works inside Claude Code, keeps one product rather than a portfolio, and wants its decisions and hypotheses in files they can grep, diff and read in a pull request. It does not suit anyone who wants a recall system with embeddings, or anyone who needs a stable versioned artefact to depend on, because the install tracks a branch with no checksum. Check four things first. Check where the install puts things, since the curl path extracts a single skill folder into your global Claude skills directory while the repository's example brain, tests and docs stay on GitHub. Check that you understand the two failing checks, since 404 of 406 is presented as a floor rather than a bug list. Check the provenance tags in your own files, because the hierarchy is plain text by design and you are meant to override it when your judgement disagrees. And check whether you will actually do the weekly review, since the sweep is a command you have to run rather than something that runs. There are no GitHub releases, the licence is MIT, and the default branch was last pushed on 2026-05-20.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. phuryn/pm-brain on GitHub
4. Project website
5. README