All authors
Claude Skills by kish21
github.com/kish217 skills0 installs14 views
- Design SystemPhase 2 (Development) of product-playbook — design the product's UI BEFORE building screens. Turns "I don't know what it should look like" into agreed design principles + a confirmed sample page + a concrete, archetype-correct DESIGN.md (shadcn-compatible tokens) that every later build step reuses. Use after /structure when the product has a user-facing UI, or run /design-system "design the UI", "what should it look like", "make a design system", "my UI looks AI-generated / fonts too small". ...Votes: 0GitHub stars: 3
- Frontend AuditPhase 2/3 of product-playbook — the UI enforcement gate. Mechanically checks built UI (and its DESIGN.md) against the /design-system universal laws, with a REAL WCAG contrast engine (OKLCH/hex → ratio) so contrast is computed, never asserted. Use after building or changing UI, before shipping, or in CI — run /frontend-audit "check my UI", "is this accessible", "audit the frontend", "did I break the design system". Reports a pass/warn/error scorecard and exits non-zero on errors. Pairs with /d...Votes: 0GitHub stars: 3
- ArchitectPhase 2 (Development), step 1 of product-playbook. Decide the tech stack + tools + key architecture decisions, benchmarked to current-year options and chosen against the project's own constraints. Use at the start of building, or run /architect "what stack", "tech decisions", "how should we build this". Writes the Architecture section of PRODUCT.md. Run /structure next.Votes: 0GitHub stars: 3
- BuildPhase 2 (Development), step 5 of product-playbook — the per-feature build loop: ONE feature at a time, a definition-of-done that INCLUDES security, reuse before writing, verify the LIVE path, review the diff, write the feature doc. Use to implement features, or run /build "build feature X", "implement", "add the feature". Appends to PRODUCT.md#Build log + writes docs/features/<feature>.md. Composes /run and /code-review. Run /dev-check when all core-scope features are done.Votes: 0GitHub stars: 3
- FoundationPhase 2 (Development), step 3 of product-playbook. Build the walking skeleton that actually RUNS — dependencies, config loader, structured logging, base infra wiring (DB/LLM/queue), dev tooling (lint/format + the commit-hook runner #Architecture chose), secret-scan, and a CI that mirrors the prod bootstrap. Use after /structure, or run /foundation "set up the skeleton", "get it running", "wire up CI". Writes the Foundation section of PRODUCT.md. Run /contracts next.Votes: 0GitHub stars: 3
- StructurePhase 2 (Development), step 2 of product-playbook — the FIRST thing you build. Choose the project's SHAPE (domain modules by default, or layers) and explain what each folder is for and why, plus the root scaffolding every project needs — agent instructions, ignore rules, .env.example, secret-scan, commit hooks, a task runner — using the TOOLS #Architecture chose, and a prompts/ YAML folder for AI. Use when starting to code, or run /structure "set up the project", "folder structure", "where do...Votes: 0GitHub stars: 3
- TicketsPhase 2 (Development), step 4b of product-playbook — bridges /contracts and /build. Bare /tickets turns every milestone in PRODUCT.md#Plan into EPICS of small, independently mergeable tickets — grouped into MODULE LANES (one per STRUCTURE.md module, ordered inside, parallel across) with an Owner, sliced VERTICALLY (thin end-to-end increments) or HORIZONTALLY (one ticket per layer), proposed and confirmed by you — each with exact file paths, typed in/out and a security DoD, filed as parent iss...Votes: 0GitHub stars: 3