PackmindHub/test-factory-patterns
.claude/skills/test-factory-patterns/SKILL.md
This skill provides guidance for writing test factories in the Packmind codebase. It should be used when creating or updating factory functions in `**/test/*Factory.ts` files to ensure realistic test data with variety.
$ install --global
skillsauthnpx skillsauth add PackmindHub/packmind test-factory-patternsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 16, 2026, 1:40 AM30.3s1 file scanned
SKILL.md
- name:
- test-factory-patterns
- description:
- This skill provides guidance for writing test factories in the Packmind codebase. It should be used when creating or updating factory functions in `**/test/*Factory.ts` files to ensure realistic test data with variety.
Test Factory Patterns
Overview
Test factories create realistic test data with variety. Good factories generate multiple plausible instances and randomly select one, while allowing partial overrides. Poor factories return identical static data every time.
The Pattern
Good Factory Structure
A well-designed factory:
- Defines an array of multiple realistic instances with meaningful, varied content
- Uses
randomIn()to select one instance randomly - Spreads partial overrides to allow customization
import { Factory, randomIn } from '@packmind/test-utils';
import { Entity, createEntityId } from '@packmind/types';
import { v4 as uuidv4 } from 'uuid';
export const entityFactory: Factory<Entity> = (entity?: Partial<Entity>) => {
const entities: Entity[] = [
{
id: createEntityId(uuidv4()),
name: 'Meaningful Name One',
slug: 'meaningful-name-one',
content: `Realistic content that represents actual usage...`,
// ... other fields with realistic values
},
{
id: createEntityId(uuidv4()),
name: 'Different Meaningful Name',
slug: 'different-meaningful-name',
content: `Different realistic content...`,
// ... other fields with different realistic values
},
// Add 3-5 varied instances
];
return {
...randomIn(entities),
...entity,
};
};
Bad Factory Structure (Avoid)
Avoid factories that return identical static data:
// BAD: Always returns the same data
export const entityFactory: Factory<Entity> = (entity?: Partial<Entity>) => {
return {
id: createEntityId(uuidv4()),
name: 'Test Entity', // Static, meaningless
content: 'test content', // Not realistic
...entity,
};
};
Guidelines
Content Quality
- Use realistic, domain-appropriate content (not "test", "foo", "bar")
- Include variety that reflects actual usage patterns
- Make names and slugs consistent with each other
Instance Count
- Include 3-5 varied instances in the array
- Each instance should represent a plausible real-world case
Required Imports
import { Factory, randomIn } from '@packmind/test-utils';
ID Generation
- Always generate fresh UUIDs for IDs using
createXxxId(uuidv4()) - Never hardcode static UUIDs
Override Support
- Always spread partial overrides last:
...entity - This allows tests to customize specific fields while keeping realistic defaults
Related Skills
PackmindHub/michel-ui-demo-recorder
tools
VerifiedTrustedCommunity
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.
288SKILL.mdUpdated Jun 4, 2026
PackmindHub/michel-run-local-dev-stack
tools
VerifiedTrustedCommunity
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.
288SKILL.mdUpdated Jun 4, 2026
PackmindHub/michel-create-pr-with-screenshots
tools
VerifiedTrustedCommunity
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".
288SKILL.mdUpdated Jun 4, 2026
PackmindHub/scripts/michel/michel-create-packmind-dataset
tools
VerifiedTrustedCommunity
--- 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
288SKILL.mdUpdated Jun 4, 2026