.github/skills/packmind-create-command/SKILL.md
Guide for creating reusable commands via the Packmind CLI. This skill should be used when users want to create a new command that captures multi-step workflows, recipes, or task automation for distribution to CoPilot.
npx skillsauth add PackmindHub/packmind packmind-create-commandInstall 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.
This skill provides a complete walkthrough for creating reusable commands via the Packmind CLI.
Commands are structured, multi-step workflows that capture repeatable tasks, recipes, and automation patterns. They help teams standardize common development workflows and enable CoPilot to execute complex tasks consistently.
Every command is drafted as a markdown file with this structure:
# Command Name
## Summary
What the command does, why it's useful, and when it's relevant.
## When to Use
- Scenario 1 when this command applies
- Scenario 2 when this command applies
## Context Validation Checkpoints
- Question 1 to validate before proceeding?
- Question 2 to ensure context is clear?
## Steps
### Step Name
What this step does and how to implement it.
\`\`\`typescript
// Optional code example
\`\`\`
### Another Step
Description without code.
The # Title heading is the display name shown in indexes and dashboards. The slug is auto-generated from it — never write the slug yourself.
Format: Use Title Case with spaces — natural language, not a slug.
Examples:
"Create API Endpoint", "Setup Database Migration", "Configure CI Pipeline""api-endpoint" (slug format — use Title Case with spaces)"setup migration" (not Title Case)"create-api-endpoint" (slug format)The CLI validates the command after conversion. Ensure the markdown file meets these requirements:
# Title: Non-empty Title Case string starting with an action verb, descriptive and specific (2–5 words, e.g., "Create API Endpoint")## Summary: Non-empty string describing intent, value, and relevance## When to Use: At least one bullet item (non-empty strings)## Context Validation Checkpoints: At least one bullet item (non-empty strings)## Steps: At least one step subsection### Step Name: Non-empty string (step title)Before creating a command, verify that packmind-cli is available:
Check if packmind-cli is installed:
packmind-cli --version
If not available, install it:
npm install -g @packmind/cli
Then login to Packmind:
packmind-cli login
Skip this step only when the command's workflow and steps are already clearly defined.
To create an effective command, clearly understand:
What workflow does this command automate?
When should this command be triggered?
Example clarifying questions:
Transform the understanding from Step 1 into a complete markdown draft with steps and validation checkpoints.
.packmind/commands/_drafts/ (create the folder if missing) using filename <slug>.md (lowercase with hyphens)# <Command Title> (Title Case, action-verb prefix, 2–5 words)## Summary — what the command does, why it's useful, and when it's relevant## When to Use — bullet list of specific scenarios## Context Validation Checkpoints — bullet list of validation questions## Steps — each step as a ### <step title> subsection following the Step Writing Guidelines belowThis draft file is the only file created during drafting — no separate files are needed.
Good descriptions:
Bad descriptions:
Questions that verify requirements before execution:
Good checkpoints:
Bad checkpoints:
Define specific, actionable scenarios:
Good scenarios:
Bad scenarios:
Before running the CLI command, you MUST get explicit user approval:
Show the user the complete command content in a formatted preview:
Provide the file path to the markdown file (.packmind/commands/_drafts/<slug>.md) so users can open and edit it directly if needed.
Ask: "Here is the command that will be created on Packmind. The draft file is at `<path>` if you want to review or edit it. Do you approve?"
Wait for explicit user confirmation before proceeding to Step 4.
If the user requests changes, go back to earlier steps to make adjustments.
Re-read the markdown file from disk to capture any user edits.
Compare with the original content you created in Step 2.
If changes were detected:
If no changes: Proceed directly to submission.
Convert the markdown to JSON using these conversion rules:
# heading → name## Summary content → summary## When to Use bullet items → whenToUse[]## Context Validation Checkpoints bullet items → contextValidationCheckpoints[]### ... under ## Steps → step name, paragraph text → description, code block → codeSnippet (wrapped in markdown code fences with language identifier)Pipe the JSON directly to the CLI via stdin using a heredoc (no intermediate file needed):
packmind-cli commands create --origin-skill packmind-create-command <<'EOF'
{"name":"...","summary":"...","whenToUse":[...],"contextValidationCheckpoints":[...],"steps":[...]}
EOF
Expected output on success:
packmind-cli Command "Your Command Name" created successfully (ID: <uuid>)
View it in the webapp: <url>
"Not logged in" error:
packmind-cli login
"Failed to resolve global space" error:
Validation errors:
## Steps section has at least one ### step subsectionAfter the command is successfully created, delete the draft markdown file in .packmind/commands/_drafts/.
Only clean up on success - if the CLI command fails, keep the files so the user can retry.
After successful creation, check if the command fits an existing package:
packmind-cli install --list to get available packages<package-slug> package."<package-slug>packmind-cli packages add --to <package-slug> --command <command-slug>packmind-cli install to sync the changes?"packmind-cli installHere's a complete example creating a command for setting up a new API endpoint:
File: .packmind/commands/_drafts/create-api-endpoint.md
# Create API Endpoint
## Summary
Set up a new REST API endpoint with controller, service, and tests following the hexagonal architecture pattern.
## When to Use
- When adding a new REST endpoint to the API
- When implementing a new backend feature that exposes HTTP endpoints
## Context Validation Checkpoints
- Is the HTTP method and path defined (e.g., POST /users)?
- Is the request/response payload structure specified?
- Is the associated use case or business logic identified?
## Steps
### Create Controller
Create the controller file in the \`infra/http/controllers/\` directory with the endpoint handler and input validation.
\`\`\`typescript
@Controller('users')
export class UsersController {
@Post()
async create(@Body() dto: CreateUserDTO) {
return this.useCase.execute(dto);
}
}
\`\`\`
### Create Use Case
Create the use case in the \`application/useCases/\` directory implementing the business logic.
### Create Tests
Create unit tests for the controller and use case in their respective \`.spec.ts\` files following the Arrange-Act-Assert pattern.
### Register in Module
Add the controller and use case to the appropriate NestJS module's \`controllers\` and \`providers\` arrays.
Creating the command (piped via stdin):
packmind-cli commands create --origin-skill packmind-create-command <<'EOF'
{"name":"Create API Endpoint","summary":"Set up a new REST API endpoint...","whenToUse":[...],"contextValidationCheckpoints":[...],"steps":[...]}
EOF
| Section | Required | Description |
|---|---|---|
| # Title | Yes | Title Case, action-verb prefix, 2–5 words |
| ## Summary | Yes | What, why, and when (one sentence) |
| ## When to Use | Yes | Bullet list, at least one scenario |
| ## Context Validation Checkpoints | Yes | Bullet list, at least one checkpoint |
| ## Steps | Yes | Contains step subsections |
| ### Step Name | Yes (≥1) | Step title |
| Step body (paragraph) | Yes | Implementation details |
| Step body (code block) | No | Markdown code block with language |
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