plugins/lt-showroom/skills/creating-showcases/SKILL.md
Creates, updates, and manages showcases on the lenne.tech Showroom platform (showroom.lenne.tech). Implements a 5-phase workflow: (1) project analysis, (2) screenshot capture with Docker/app startup and demo data, (3) SHOWCASE.md creation as single source of truth in the project repository, (4) showcase creation via API using SHOWCASE.md + customer feedback + web research, (5) interactive presentation with modern content blocks. Fetches customer feedback from https://lenne.tech/kundenerfolge. Uses MCP tools (showroom-api) or REST API for CRUD operations. Activates when creating, editing, managing showcases, portfolio entries, or the Showroom platform. NOT for platform development on the showroom codebase itself (use generating-nest-servers or developing-lt-frontend).
npx skillsauth add lennetech/claude-code creating-showcasesInstall 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 implements a 5-phase workflow built around SHOWCASE.md as the single source of truth. Every showcase starts from a versioned Markdown file in the project repository and is then published to showroom.lenne.tech.
version must match package.json version — A drift between the two is silently ignored by the API, but it confuses future audits and breaks automated "is the showcase current?" checks. Always sync the version field when running an update.curl calls, the session cookie written to .cookies is tied to this Claude session. On the next session's first request you'll get a 401 without a clear error. Re-authenticate before each new workflow.docker compose down with a trap/finally-equivalent, not just a success-path call.order values must be ascending with no gaps — Holes in the sequence (e.g. order 1, 3, 5) cause rendering glitches on the showroom frontend. When deleting a block, re-normalize the remaining orders; when adding, pick the next consecutive integer./lt-showroom:showroom:analyze, /lt-showroom:showroom:screenshot, /lt-showroom:showroom:create, /lt-showroom:showroom:updateanalyzing-projects — Provides the evidence-based analysis report that populates SHOWCASE.mdgenerating-nest-servers / developing-lt-frontend — For platform developmentAll showcase operations go through the showroom-api MCP server. Screenshot capture uses the chrome-devtools MCP server.
The default MCP endpoint is https://api.showroom.lenne.tech/mcp (production). When working inside the showroom project repository, the project-level .mcp.json overrides this to http://localhost:3000/mcp for local development.
If MCP is unavailable (e.g. OAuth not configured), use the REST API directly via curl with session cookies:
# Login
curl -s -c /tmp/showroom-cookies.txt -X POST http://localhost:3000/iam/sign-in/email \
-H 'Content-Type: application/json' -d '{"email":"...","password":"..."}'
# Create showcase
curl -s -b /tmp/showroom-cookies.txt -X POST http://localhost:3000/showcases \
-H 'Content-Type: application/json' -d '{"title":"...","description":"...","contentBlocks":[...]}'
# Update showcase (add content blocks)
curl -s -b /tmp/showroom-cookies.txt -X PATCH http://localhost:3000/showcases/{id} \
-H 'Content-Type: application/json' -d '{"contentBlocks":[...]}'
# Publish
curl -s -b /tmp/showroom-cookies.txt -X POST http://localhost:3000/showcases/{id}/publish
${CLAUDE_SKILL_DIR}/reference/showcase-model.md — Showcase data model and status lifecycle${CLAUDE_SKILL_DIR}/reference/content-blocks.md — All content block types with schemas${CLAUDE_SKILL_DIR}/reference/screenshot-workflow.md — Docker-based startup, demo data, feature screenshots${CLAUDE_SKILL_DIR}/reference/best-practices.md — Content guidelines and block structure${CLAUDE_SKILL_DIR}/reference/showcase-markdown.md — SHOWCASE.md format specificationSHOWCASE.md is the single source of truth. Everything flows from this file.
Phase 1: Analyze → structured report with features + pages + startup info
Phase 2: Screenshots → start app, create demo data, capture per feature
Phase 3: SHOWCASE.md → versioned Markdown in project repository
Phase 4: Publish → SHOWCASE.md + feedback + research → showcase via API
Phase 5: Present → modern blocks with glassmorphism, scroll-reveal, 3D-tilt
Run the project-analyzer agent (or use analyzing-projects skill inline) for a full 8-dimension report. The report MUST include:
startupInfo block (how to start the app, database requirements, seed command)pagesInventory list (all routes with auth level and associated feature)Every claim must have a file:line evidence reference.
Check for Docker Compose first — it is the preferred startup method:
# Option A: Docker Compose (preferred)
[ -f "docker-compose.yml" ] || [ -f "compose.yaml" ] && docker compose up -d
# Option B: Standalone MongoDB if needed but not in compose
docker run -d --name showcase-mongo -p 27018:27017 mongo:7
# Option C: npm/pnpm dev server
pnpm run dev # or npm run dev
Always use run_in_background: true for server processes. Poll for readiness before proceeding.
package.json: seed, db:seed, demo, fixturespnpm run seedFor each feature in the analysis report:
docs/showcase/screenshots/ in the project directoryFilename convention: {feature-slug}-desktop.png, {feature-slug}-mobile.png
# Ensure the screenshot directory exists
mkdir -p docs/showcase/screenshots
After all screenshots are captured:
pkill -f "nuxt dev" / pkill -f "next dev" / pkill -f "nest start"docker compose down or docker stop showcase-mongolsof -ti :<port>Full details in ${CLAUDE_SKILL_DIR}/reference/screenshot-workflow.md.
Write SHOWCASE.md in the project root (or docs/showcase/SHOWCASE.md for monorepos).
The file format is defined in ${CLAUDE_SKILL_DIR}/reference/showcase-markdown.md.
Key requirements:
version in frontmatter MUST match package.json versionanalyzed_at is the ISO date of the analysisdocs/showcase/screenshots/Parse the SHOWCASE.md frontmatter and sections as the primary content source.
https://lenne.tech/kundenerfolge:
Block 1: tech-stack — Technology badges from SHOWCASE.md tech stack section
Block 2: text "Überblick" — 3-5 paragraphs from SHOWCASE.md overview section
Block 3: feature-grid — 6-8 features from SHOWCASE.md features section
Block 4: text "Architektur" — From SHOWCASE.md architecture section
Block 5: screenshot-gallery — Screenshots from docs/showcase/screenshots/
Block 6: text "Highlights" — From SHOWCASE.md technical highlights section
Block 7: timeline — Project milestones (if derivable from git or SHOWCASE.md)
Block 8: testimonial — Customer feedback from lenne.tech/kundenerfolge
Block 9: team — Team members (if known)
Block 10: text "Ergebnis" — From SHOWCASE.md results section
Block 11: cta — "Termin vereinbaren" + meeting URL
# Auth
curl -s -c /tmp/showroom-cookies.txt -X POST http://localhost:3000/iam/sign-in/email \
-H 'Content-Type: application/json' -d '{"email":"...","password":"..."}'
# Create with all content blocks
curl -s -b /tmp/showroom-cookies.txt -X POST http://localhost:3000/showcases \
-H 'Content-Type: application/json' -d '{ "title": "...", "description": "...", "contentBlocks": [...] }'
# Publish
curl -s -b /tmp/showroom-cookies.txt -X POST http://localhost:3000/showcases/{id}/publish
Use modern content blocks that align with lt-website-reloaded styling:
Visual design principles:
feature-grid cards use glass-style background with blurfeature-grid itemsContent block choices:
feature-grid for capabilities (not a plain list)screenshot-gallery with viewport switcher (desktop/tablet/mobile tabs)testimonial for social prooftech-stack with category grouping (Frontend, Backend, Database, Infrastructure)timeline for project history or phasesText quality standards (same as best-practices.md):
<h3>, <p>, <ul>/<li>, <strong>{
"contentBlocks": [
{
"type": "tech-stack",
"title": "Technologien",
"order": 0,
"visible": true,
"showInToc": true,
"content": {
"technologies": [
{"name": "NestJS", "category": "backend"},
{"name": "Nuxt", "category": "frontend"}
]
}
},
{
"type": "text",
"title": "Projektübersicht",
"order": 1,
"visible": true,
"showInToc": true,
"content": {
"html": "<h3>Was ist das Projekt?</h3><p>Detailed description...</p><h3>Das Problem</h3><p>...</p><h3>Die Lösung</h3><p>...</p>"
}
},
{
"type": "feature-grid",
"title": "Features",
"order": 2,
"visible": true,
"showInToc": true,
"content": {
"features": [
{"title": "Feature Name", "description": "What it does and why it matters", "icon": "lucide:icon-name"}
]
}
},
{
"type": "testimonial",
"title": "Kundenfeedback",
"order": 7,
"visible": true,
"showInToc": false,
"content": {
"quote": "The customer quote...",
"author": "Person Name",
"company": "Company Name"
}
}
]
}
docs/showcase/screenshots/development
Single source of truth for the lenne.tech fullstack production-readiness checklist. Defines the eight pillars (configuration & secrets, observability & logging, health & lifecycle, security hardening, data durability, resilience under load, deployment hygiene, runbook & rollback) with concrete file/line evidence requirements per pillar, severity classification (Critical / Major / Minor), and a canonical machine-parseable report block. Activates whenever an agent or command needs to gate a release on production-readiness — currently used by /lt-dev:production-ready, lt-dev:production-readiness-orchestrator, and the devops-reviewer (read-only). NOT for OWASP-style code-level security review (use security-reviewer). NOT for npm dependency audits (use maintaining-npm-packages).
development
Single source of truth for executing GitLab CI/CD pipelines locally with the same image, env vars, and service containers as the real runner — so pipeline failures are caught before push. Defines pipeline discovery (.gitlab-ci.yml + includes), per-job execution via gitlab-runner exec, service-container orchestration (Mongo, Redis, MailHog), env injection without secrets, cache/artifact handling, and a job-by-job verdict report. Also describes the GitHub Actions equivalent via act for projects that mirror to GitHub. Activates whenever an agent or command needs to validate that the CI pipeline will pass — currently used by /lt-dev:production-ready and lt-dev:production-readiness-orchestrator. NOT for running the local check script (use running-check-script). NOT for writing or refactoring CI configs (use the devops agent).
development
Single source of truth for designing, running, and interpreting k6 load tests against lenne.tech fullstack APIs. Defines installation paths (brew, docker, npm), the three canonical scenarios (smoke / load / soak), endpoint discovery from the generated SDK, realistic Better-Auth login flows, threshold defaults for ~10 concurrent users (p95 < 500ms, error rate < 1%, http_req_failed < 1%), result interpretation, and the optimisation ladder when the system fails (DB indices, query rewrites, caching, connection pool sizing, rate-limit relaxation, payload trimming). Activates whenever an agent or command needs to validate that the API is stable for ~10 concurrent users performing many actions in short time, or to detect performance regressions via k6. Currently used by /lt-dev:production-ready, lt-dev:production-readiness-orchestrator, and lt-dev:performance-reviewer. NOT for Lighthouse frontend performance (use a11y-reviewer). NOT for unit performance assertions (use the test runner directly).
tools
Migrates lenne.tech projects from the legacy jest+eslint+prettier toolchain to the current vitest+oxlint+oxfmt baseline used by nest-server-starter and nuxt-base-starter. Covers swc decoratorMetadata config, the @Prop union-type fix for SWC, supertest default-import correction, ESM/CJS interop, the Nitro PORT-vs-NITRO_PORT bug, ANSI escape stripping in workspace runners (lerna/nx), free-port logic for check-server-start.sh, the offers-pattern config.env.ts (NSC__-only + fail-fast + auto-derived appUrl), and the multi-phase check-envs.sh smoke test. Activates whenever someone is migrating an existing project to the new toolchain, debugging "Cannot determine a type for the X field" Mongoose errors, ERR_SOCKET_BAD_PORT crashes from check-server-start, or wants to align an existing project with the current starter conventions.