.claude/skills/packmind-update-playbook/SKILL.md
Use when updating, adding, fixing, changing, or deprecating Packmind playbook artifacts (standards, commands, skills). Triggers on explicit phrases like "update packmind standard", "add a packmind skill", "fix packmind command", "change packmind playbook", "deprecate a standard". Also triggers — even without an explicit request — whenever the conversation reveals an opportunity: a new coding convention was just agreed on, a recurring pattern emerged, a workflow changed, a rule was found outdated, or the user says things like "we always do X", "let us remember to Y", "that is the pattern we use". If there is any chance the conversation established a convention or exposed a gap, invoke this skill proactively. This skill defines a mandatory workflow: do NOT edit artifact files directly — follow all phases regardless of change size.
npx skillsauth add PackmindHub/packmind packmind-update-playbookInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Run "packmind-cli --version" to get the current cli installation.
Find the highest version at or below the cli version in this list:
Evaluate the user's intent against existing Packmind artifacts (standards, commands, skills) to identify what needs creating or updating. Produce a structured change report, then apply approved changes using the playbook CLI workflow.
⚠️ MANDATORY WORKFLOW — This skill defines a strict sequence: Understanding Your Request → Summarizing Changes → Analyzing Playbook → Change Report → Applying Changes. Do NOT skip steps or edit artifact files directly. Even for a single-line change, follow every step. The workflow ensures changes are reviewed, approved, submitted, and propagated correctly.
STOP. This phase runs FIRST, before anything else. No file reads, no CLI commands, no subagents until this gate passes.
Analyze the user's input and conversation context to determine intent:
The skill was invoked standalone with no context. Ask:
"What Packmind artifact do you want to modify? For example: a standard (coding rule/convention), a command (multi-step workflow), or a skill (specialized capability). Please describe what you'd like to change."
BLOCK — do not proceed until the user responds.
The user explicitly asked to update, add, fix, or change a Packmind artifact. Extract an intent summary:
Proceed to Summarizing Changes with this validated intent.
The conversation reveals a playbook update opportunity — e.g., a convention was established, a pattern emerged, a workflow was changed, or a known artifact is now stale — but the user did not explicitly ask for a playbook update. Summarize the opportunity and ask:
"I noticed an opportunity to update the Packmind playbook: <brief description>. Would you like me to run the update workflow?"
BLOCK — do not proceed until the user confirms.
If the conversation contains no references to modifying Packmind artifacts and no detectable update opportunity, tell the user:
"I didn't detect any intent or opportunity to modify the Packmind playbook. What artifact would you like to update — a standard, command, or skill? Please describe the change."
BLOCK — do not proceed until the user responds.
Only proceed after Understanding Your Request validates intent (explicit request or confirmed opportunity).
Summarize the validated intent before launching any subagents. Extract:
This intent summary is passed as input to all subagents.
CLI health check: Before launching subagents, run
packmind-cli --version. If it fails, stop immediately and tell the user: "The Packmind CLI is not available or not working. Please check your installation before proceeding." Do not continue.
No subagent support? If the
Tasktool is unavailable, perform all three domain analyses sequentially in the current session — run eachsteps/analyze-*.mdanalysis one after another before proceeding to Change Report.
Launch all three as Task(general-purpose) subagents simultaneously — do not wait for one before starting the others. Each subagent handles its own listing, filtering, and deep analysis in one pass.
Construct each prompt as:
## Validated Intent
<the intent summary from Summarizing Changes>
## Analysis Task
<full contents of the corresponding steps/analyze-*.md file>
| Subagent | Step File | Output |
|----------|-----------|--------|
| Standards | steps/analyze-standards.md | Standards change report |
| Commands | steps/analyze-commands.md | Commands change report |
| Skills | steps/analyze-skills.md | Skills change report |
For each domain, decide whether to launch or skip based on the validated intent's target artifact type:
After all subagents complete, consolidate their reports. Before numbering, deduplicate: if multiple subagents propose modifying the same artifact, merge those into one entry combining both rationales — do not list the same artifact twice. Number every change sequentially so the user can selectively approve:
## Playbook Change Report
<!-- Only include sections that have changes. Omit empty sections entirely. -->
<!-- Ordering reflects priority: skill accuracy first, then standards, then commands. -->
<!-- New commands have a high bar — see domain-commands.md for criteria. -->
### Skill Updates
1. [skill] <name>: <what changed and why>
### New Skills
2. [skill] <name>: <reason>
### Standard Updates
3. [standard] <name>: <what changed and why>
### New Standards
4. [standard] <name>: <reason>
### New Commands
5. [command] <name>: <reason>
### Command Updates
6. [command] <name>: <what changed and why>
Only include sections that have actual changes — omit empty sections entirely. Order by priority: skills first, then standards, then commands.
Present this report and ask the user for approval:
Follow the procedure in packmind-versions/<$PACKMIND_CLI_VERSION>/apply-changes.md.
Pass it the list of approved changes (with their numbers and details) from the Change Report above.
tools
Record polished UI demo videos and screenshots of a running web app using Playwright MCP — for client deliverables, release notes, feature walkthroughs, or bug repros. Produces an HD WebM video with chapter markers, a mandatory animated cursor overlay, and a mandatory subtitle bar that narrates each step (positioned deliberately so it never masks the UI being demonstrated), plus full-page screenshots at each step. Use this whenever the user asks to "record a demo", "create a screencast", "make a UI walkthrough video", "document this feature with video", "show the client how X works", "capture screenshots of the app", or anything similar — even when the user only says "make a video" or "take screenshots" in the context of a running frontend. Also use it when the user wants to demonstrate a workflow, generate marketing-quality footage of an app, or produce repeatable visual documentation.
tools
The canonical recipe for starting, checking, and stopping the Packmind local dev stack with Docker Compose — the single source of truth other skills and the Michel agent defer to. Covers bringing the full stack (PostgreSQL, Redis, NestJS API, React/Vite frontend on :4200, MCP server, nginx) up in the background, the init services (dependency install + TypeORM migrations) you must wait on, the critical host-port trap that the API on container port 3000 is NOT exposed to the host and must be reached via the frontend Vite proxy at localhost:4200/api/v0, confirming the API and frontend are actually serving before you depend on them, the persistent-volume gotcha that leaves stale Postgres schema and node_modules behind between runs, building the CLI, and tearing everything down so no container is left blocking the run. Use this whenever you need Packmind running locally — to verify a change, record a UI or CLI demo, hit the API, seed data, or reproduce a bug — and whenever you are about to start or stop `docker compose`. If you are an autonomous agent (e.g. Michel) that started the stack, you MUST use the teardown half before finishing. Prefer this over running `nx serve` on the host for anything that needs the real, containerized stack.
tools
Best practices for creating GitHub pull requests that include inline images — CLI terminal screenshots (from cli-demo-recorder), UI screenshots/videos (from ui-demo-recorder), or any other visual artifact. Use this skill whenever opening or updating a PR that has visual artifacts to embed, or when images aren't rendering in a PR description. Also use it when asked "how do I add screenshots to a PR", "why isn't my image showing", or "embed a demo in the PR".
tools
--- name: michel-create-packmind-dataset description: Seed a local Packmind instance with a realistic dataset — one organization populated with standards, commands, and skills — so an autonomous agent can exercise its own changes against lifelike data instead of an empty app. Use this whenever you need populated Packmind data to verify a change end-to-end: reproducing a bug that only shows with existing artifacts, recording a UI/CLI demo that needs content on screen, smoke-testing a new endpoint