Create a Packmind dataset
Build a working dataset inside a local Packmind instance — an organization with standards, commands, and skills — so a change can be tested against realistic data. Written for an autonomous agent verifying its own work on the Packmind app.
The one rule that governs what you build
Let the task pick the artifacts. This skill is not a fixed recipe that always creates the same three standards. A "dataset" is whatever the thing you are testing needs to be exercised. Before seeding anything, ask: what must exist for my change to be observable?
- Testing a standards-list filter or the Standards page → seed a few standards (samples are fastest).
- Testing the Skills page, skill versioning, or
playbook add/submit→ seed at least one skill via the CLI (the only path that creates skills). - Testing a command palette,
/sluginvocation, or the Commands page → author one or two commands. - Reproducing a bug that only appears with N artifacts, or a specific name/slug → create exactly those.
- Just need "the app isn't empty" for a demo → a few sample standards + one command + one skill is a well-rounded minimum.
Seed the minimum that makes the change observable. Over-seeding slows the run and muddies what you are actually testing. When unsure what an artifact is or how a flow behaves, look it up in the product docs over MCP (see below) rather than guessing.
Product docs are available over MCP
The packmind-user-docs MCP server (configured in .mcp.json, served from https://docs.packmind.com/mcp) exposes Packmind's end-user documentation. Query it whenever you are unsure how a feature works from the user's side — what a standard/command/skill is, what the creation flows offer, what a setting does, how packages/distribution work. This is the authoritative source for product behavior; prefer it to assumptions. The docs describe the UI and concepts; the CLI mechanics below are the seeding path.
Workflow
1. Bring the stack up — defer to michel-run-local-dev-stack
That skill is the single source of truth for the lifecycle. The essentials:
export PACKMIND_EDITION="$(bash scripts/michel/resolve-edition.sh)" # oss | proprietary, from the git remote
docker compose --profile dev up -d
PM_WEB="$(docker compose port frontend 4200 | sed 's#.*:##')" # host port: 4200 oss / 4201 proprietary
until curl -sf "localhost:$PM_WEB" >/dev/null; do sleep 2; done # frontend ready
curl -s -o /dev/null -w "%{http_code}\n" "localhost:$PM_WEB/api/v0" # API via Vite proxy -> 200
Host-port trap: the NestJS API is on container port 3000, which is not published to the host. Never poll localhost:3000. Reach the API through the frontend's Vite proxy at http://localhost:$PM_WEB/api/v0 — and that same base URL (http://localhost:$PM_WEB) is what the CLI must point at. The host frontend port is edition-dependent (4200 OSS / 4201 proprietary) — resolve PM_WEB as above, never hardcode 4200.
If the frontend exits on its own or sticks on "Loading Packmind…", that is a known cosmetic flake — restart just frontend or reload the page. See michel-run-local-dev-stack ("Frontend troubleshooting"); don't debug the app.
Clean slate: the Postgres volume persists across down, so a prior run leaves its org and artifacts behind. If the test needs a guaranteed-empty start:
docker compose --profile dev down -v
docker compose --profile dev up -d # PACKMIND_EDITION already exported above
2. Create the organization (UI, via Playwright MCP)
A fresh instance has no account; the first org is created through sign-up. Drive the browser with the Playwright MCP:
- Open
http://localhost:$PM_WEB(4200 OSS / 4201 proprietary — see the host-port trap above) → lands on/sign-in. - Sign up →
/sign-up/create-account. - Work email (e.g.
michel@packmind-demo.com) → Continue with email. - Password — must be 8+ chars with at least 2 non-alphanumeric characters (e.g.
Packmind!Demo#2026). The signup API rejects anything weaker with a raw error, not a hint, so a weak password reads as a silent failure. Confirm → Create Account. (Same policy applies to scripted signup viaPOST /api/v0/auth/signup— seemichel-run-local-dev-stack→ "Creating the first account".) - Name the org (e.g.
Packmind Demo) → Continue. Slug is derived (packmind-demo). - Pick an onboarding reason (I'm just exploring) → Continue; dismiss the welcome dialog.
You land at /org/<org-slug>/space/global. The default space is Global.
3. Seed standards (only if the task needs them)
Playbook → Standards. Fastest path for realistic data is Browse samples: tick the languages/frameworks the task needs (e.g. TypeScript, React, Nest.js — click the sample card, the checkbox is overlaid by its label) → Create. Each becomes a versioned standard (typescript-best-practices, etc.), listed immediately.
Other paths when you need specific rules: Create manually (/standards/create) for authored content, Browse use cases to populate from GitHub/Slack/Jira, Generate from your code to infer from a codebase. Pick by what you are testing.
4. Seed commands (only if the task needs them)
Playbook → Commands → Create manually (/commands/create).
- Name (e.g.
Create React Component) → slug auto-derived (create-react-component), invoked as/slug. - Content: Markdown prompt. Describe the task precisely; reference your standards when relevant.
- Create.
The page also offers Browse use cases, Create from your code, and example buttons (Conventional commit, Generate Playwright test).
5. Seed skills — CLI only
Skills are not created with a UI form (the Skills page's Import action just documents the CLI flow). A skill is a directory containing a SKILL.md with name/description frontmatter, uploaded via the CLI. Connect the CLI first (§6), then:
# Stage one skill folder (must contain SKILL.md), targeting a space
node ./dist/apps/cli/main.cjs playbook add <skill-directory> --space global
# Publish. -m skips the interactive editor; --no-review applies it directly
node ./dist/apps/cli/main.cjs playbook submit -m "Add skill (test dataset)" --no-review
Output: 1 skill created. Refresh Playbook → Skills to see it, versioned and attributed.
playbook addscans.claude/skills/**forSKILL.md; point it at a single folder to stage just that one.playbook statusshows what is tracked.- Omit
--no-reviewto create a proposal instead — use this when the task is to test the review workflow.
6. Connect the CLI to the local instance
Build from source and run as node ./dist/apps/cli/main.cjs — do not use a global packmind-cli, which may target production.
npm run packmind-cli:build # -> dist/apps/cli/main.cjs
node ./dist/apps/cli/main.cjs login --host "http://localhost:$PM_WEB" # MUST pass --host (4200 oss / 4201 prop); defaults to prod
Login starts a callback server (http://127.0.0.1:19284) and prints a /cli-login?... URL. Open it in a browser session already logged in to the local org (the §2 account); it hands the code back and the CLI stores an API key at ~/.packmind/credentials.json.
- Headless / no browser reach: the
/cli-loginpage also shows a one-time code and alogin --host … --code <uuid>command. Pass--codeto skip the browser round-trip.
Verify, then the CLI reads/writes the local dataset:
node ./dist/apps/cli/main.cjs whoami # Host/Organization/User
node ./dist/apps/cli/main.cjs standards list # the standards you created
node ./dist/apps/cli/main.cjs spaces list # -> @global
7. Tear the stack down when finished
If you are an autonomous agent that started the stack, you must take it down before finishing so no container blocks later runs (per michel-run-local-dev-stack):
docker compose --profile dev down # keeps the dataset
docker compose --profile dev down -v # also wipes it
Quick reference
# Stack
export PACKMIND_EDITION="$(bash scripts/michel/resolve-edition.sh)" # oss | proprietary
docker compose --profile dev up -d
PM_WEB="$(docker compose port frontend 4200 | sed 's#.*:##')" # host port: 4200 oss / 4201 proprietary
until curl -sf "localhost:$PM_WEB" >/dev/null; do sleep 2; done
curl -s -o /dev/null -w "%{http_code}\n" "localhost:$PM_WEB/api/v0" # -> 200
# CLI: build + connect to local
npm run packmind-cli:build
node ./dist/apps/cli/main.cjs login --host "http://localhost:$PM_WEB"
node ./dist/apps/cli/main.cjs whoami
# Seed a skill (org + standards + commands done in the UI per §2–4)
node ./dist/apps/cli/main.cjs playbook add <skill-dir> --space global
node ./dist/apps/cli/main.cjs playbook submit -m "seed" --no-review
# Teardown (mandatory for autonomous runs)
docker compose --profile dev down