.github/skills/update-playbook/SKILL.md
This skill should be used when the user wants to evaluate and update the Packmind playbook (standards, commands, skills) based on the current conversation context. Triggers on requests like "update the playbook", "sync standards", "check if we need new standards", or after significant coding sessions where patterns emerged.
npx skillsauth add PackmindHub/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.
Evaluate the current conversation context against existing Packmind artifacts (standards, commands, skills) to identify what needs creating, updating, or deprecating. Produce a structured change report, then apply approved changes.
Before dispatching any subagents, summarize the current conversation context. Extract:
This summary is reused as input for all subsequent subagent prompts.
Find which existing artifacts are relevant to the session. Read each references/triage-*.md file and construct one prompt per subagent:
## Conversation Context
<the context summary from Phase 1>
## Triage Task
<full contents of the corresponding references/triage-*.md file>
Launch all three as Task(general-purpose) subagents in a single message:
| Subagent | Reference File | Output |
|----------|---------------|--------|
| Standards Triage | references/triage-standards.md | List of relevant standard slugs + new standard ideas |
| Commands Triage | references/triage-commands.md | List of relevant command slugs + new command ideas |
| Skills Triage | references/triage-skills.md | List of relevant skill names + new skill ideas |
Each subagent returns a short list — no deep analysis, just relevance filtering.
Using the triage results, read each references/analyse-*.md file and construct one prompt per subagent. Include only the artifacts flagged as relevant by triage:
## Conversation Context
<the context summary from Phase 1>
## Relevant Artifacts
<the filtered list from the corresponding triage subagent>
## Analysis Task
<full contents of the corresponding references/analyse-*.md file>
Launch all three as Task(general-purpose) subagents in a single message:
| Subagent | Reference File | Output |
|----------|---------------|--------|
| Standards Analyst | references/analyse-standards.md | Detailed change report |
| Commands Analyst | references/analyse-commands.md | Detailed change report |
| Skills Analyst | references/analyse-skills.md | Detailed change report |
Skip a subagent entirely if its triage returned no relevant artifacts and no new artifact ideas.
After all analysis subagents complete, consolidate their reports into a single change report presented to the user. Number every change sequentially so the user can selectively approve (e.g., "apply 1, 3, 5" or "all but 4"):
## Playbook Change Report
### Skill Updates (keep current)
1. [skill] <name>: <what changed and why>
### New Skills
2. [skill] <name>: <reason>
### Standard Updates
3. [standard] <name>: <what changed and why>
### New Standards (lintable rules only)
4. [standard] <name>: <reason>
### Command Updates (strong evidence only)
5. [command] <name>: <what changed and why>
### Deprecations
6. [standard|skill] <name>: <reason>
### No Changes Needed
- [standards|commands|skills]: <brief explanation if an artifact type needs no changes>
Ordering reflects priority: skill accuracy first, then standards, then commands. New commands are never proposed (command creation is user-driven).
Present this report and ask the user which changes to apply. Accept any of:
Map the user's selection back to the specific artifact changes before proceeding to Phase 5.
For each approved change from the Phase 4 report, edit the local installed files directly:
.packmind/standards/<slug>.md.packmind/commands/<slug>.md.claude/skills/<skill-name>/ (SKILL.md, references/, etc.)Edit only one instance of each artifact — packmind-cli diff compares the local copy against the server version.
For new artifacts, delegate to the corresponding creation skill (packmind-create-standard, packmind-create-command, packmind-create-skill).
Run packmind-cli diff and present the output to the user. Verify the diff matches the intended changes — no unrelated modifications should be included.
If unrelated changes appear in the diff (e.g., from a previous session), inform the user and proceed only with the intended changes.
Run packmind-cli diff --submit -m "<concise summary of all changes>" to submit the changes as proposals for human review on Packmind.
Ask the user whether they have validated the submitted changes on Packmind and wish to propagate them locally. If yes, run:
packmind-cli install --recursive
| File | Phase | Contents |
|------|-------|----------|
| references/triage-standards.md | 2 | Shallow relevance scan for standards |
| references/triage-commands.md | 2 | Shallow relevance scan for commands |
| references/triage-skills.md | 2 | Shallow relevance scan for skills |
| references/analyse-standards.md | 3 | Deep analysis of pre-filtered standards |
| references/analyse-commands.md | 3 | Deep analysis of pre-filtered commands |
| references/analyse-skills.md | 3 | Deep analysis of pre-filtered skills |
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