jackyliang
14 verified skills118 total stars
test-driven-development
Use when building any feature (small or large), fixing bugs, or refactoring — always write failing tests first against real infrastructure
development10
best-practices
Use for any code change — bug fix, small feature, refactor, or improvement. Ensures TDD, clarifying questions, codebase investigation, DRY, proper branching/worktrees, UI skills, and doc updates. PDD invokes this automatically for large features.
development10
give-me-five
Generate 5 meaningfully distinct UI/UX variants of the same screen in parallel (one subagent each), reachable via ?style=1...5, so the user can compare and pick. Calling again on a chosen style refines within that direction.
data-ai10
Ultra-short replies — answer a quick question, draft a short text/social post, or draft a short email. No preamble, no offers to elaborate, drafts under 480 characters (280 for X), never em-dashes.
testing10
user-research
Run PM-grade discovery before building any user-facing feature — problem statement, jobs-to-be-done, core flow, decision matrix. Output is a short brief with open decisions surfaced as explicit questions. Invoked by plan-driven-development and give-me-five.
development10
drift-audit
Reconcile shipped code with the plan in both directions — additive drift (unplanned work that landed) and subtractive drift (dead files, stale TODOs, completed deferred items). Run as part of PDD's post-completion audit, before /simplify.
development10
plan-driven-development
Use when starting any feature (small or large), resuming work after context loss, or unsure if a feature plan already exists. For smaller features, use lightweight mode (no plan file, but all PDD rules still apply).
development10
plan-drift-audit
Run before the post-completion audit (PDD M9) on any feature that used `powerups:plan-driven-development`. Reconciles the shipped artifact with the plan in BOTH directions — additive drift (what landed that wasn't planned) and subtractive drift (what's still in the code or plan but shouldn't be — dead files from replaced features, completed deferred items, stale TODOs, orphaned redirect stubs). Almost every shipped feature drifts on both axes; without this step the plan file lies and the repo accumulates stragglers.
development8
change-log
Use after completing a feature or bug fix to log the change in CHANGELOG.md using plain, business-user-friendly language
documentation8
database-branching
Use when building any feature that involves database changes (new table, new column, alter column, etc.) — fork the database like a git branch. Only applies to projects using Ghost DB.
development7
update-docs
Invoke after completing a feature to sync all documentation — local docs, sibling repos, skill plugins, and downstream project docs. Scans everything by default.
tools7
self-documenting-apis
Use when building or refactoring FastAPI endpoints. Ensures endpoints have proper docstrings, response models, and request models so auto-generated docs (Swagger/ReDoc) are the single source of truth — no separate API reference file to maintain.
development7
simple-design-principles
Use when writing any user-facing text (UI labels, toasts, errors, empty states) or choosing UI components. Ensures plain language, consistent component usage, and human-first design.
testing7
bug-fix
Use when fixing a bug — enforces reproduce-first-then-fix discipline with a strict step-by-step protocol. Prevents wrong-approach loops by gating each step on success criteria.
testing4