Profile My skills Saved Collections Edit profile Submit a skill

← all publishers

pacho-h

@pacho-h source repo

5 published skills

  1. ▌
    Using Ssep · pacho-h
    Use at the start of every conversation that touches a non-trivial code or design task. Establishes the ssep skill-matching matrix (4 specialized skills — reviewing-spec-and-policy, reviewing-design-fidelity, improving-feature-completeness, running-integration-tests) and requires the matrix to be evaluated BEFORE any other action, including clarifying questions, file reads, or implementation. Triggers on any of these signals — Figma URL shared, PRD/RFC/spec text shared, "review", "구현", "검토", "implement", "ship", "production-ready", "polish", "verify", "e2e", "staging" — even when each individual word looks routine, because ssep's most common failure mode is "the task looks small, just do it" rationalization that skips the spec/design/completeness/integration checks the matrix would have flagged. Distinct from superpowers:using-superpowers which sets up generic skill discipline; this one specifically enforces ssep's four-skill matrix so domain-specific reviews are not silently skipped.
    0
    installs
  2. ▌
    Reviewing Design Fidelity · pacho-h bundle
    Reviews implemented UI against design source-of-truth (Figma frames, mockup images, design tokens) for visual fidelity — spacing, typography, color, responsive behavior, interaction states, accessibility. Use when comparing built pages to design specs, when a Figma URL is shared alongside a live URL/screenshot, or for "디자인 검수", "퍼블리싱 검토", "compare with figma", "픽셀 비교", "design QA", "피그마대로 되어있나", "figma vs 현재 화면", "구현이 디자인과 맞는지". Also triggers when a Figma URL is shared with reference to existing implementation. Triggers even when the change appears trivial — single label swap, one CSS rule, one-line JSX edit — because apparent simplicity is the most common skip rationalization, and the skill itself decides scope (full audit vs quick check) faster than the caller can. Captures both sides (Figma + Playwright snapshot), runs structured visual diff, reports gaps by user-visible impact. Distinct from reviewing-spec-and-policy (audits docs) and code review (audits code structure).
    0
    installs
  3. ▌
    Reviewing Spec And Policy · pacho-h bundle
    Reviews product specs, requirements docs, RFCs, PRDs, and policy documents from text, markdown, or Figma. Use for completeness, consistency, edge-case coverage, ambiguity, policy conflicts, or compliance gaps. Triggers on "이 기획서 검토해줘", "스펙 리뷰", "정책 검토", "review this PRD", "is this complete?", "이 기획대로 구현하면 빠진게 뭐가 있을까", "스펙 갭", "요구사항 누락", or whenever a Figma URL is shared in a planning context. Triggers even when the requirement reads as a single concise sentence (e.g. "X should default to inactive and be activatable from detail"); concise requirements hide unstated questions about default values for existing data, role/permission interactions, and state-transition edges that a structured audit surfaces in minutes. Reads sources, runs a multi-dimensional review, returns a prioritized gap report. Distinct from brainstorming (generates new designs) and reviewing-design-fidelity (compares impl vs design); this audits an existing artifact.
    0
    installs
  4. ▌
    Running Integration Tests · pacho-h bundle
    Authors and runs tests across the test pyramid — unit, FE↔BE integration, and end-to-end browser scenarios — using Playwright MCP and runners (jest, vitest, mocha). Use when verifying multi-layer behavior or for "e2e 테스트", "integration 테스트", "통합 테스트", "playwright로 검증", "브라우저에서 직접 확인", "백엔드-프론트 연동", "API 통합 테스트", "staging 검증", "배포 후 검증", "smoke test", or when a feature crosses boundaries (API + UI + DB). Also triggers when verifying a deployed feature or when a PR test plan has unchecked browser/API items. Triggers even when only one boundary is crossed and a manual Playwright click was performed; manual verification proves the path works once but does not produce a codified regression, and integration-tier surprises cluster at exactly the boundary that "looked fine" during manual checks. Decides which test level fits, sets up infra, writes tests, runs them, reports failures with diagnostic context. Distinct from superpowers:test-driven-development (unit-level TDD); handles integration and e2e tiers.
    0
    installs
  5. ▌
    Improving Feature Completeness · pacho-h bundle
    Audits a working feature for the gap between "happy path passes" and "production-ready" — edge cases, error handling, loading/empty/error states, a11y, responsive, i18n, observability, ops hooks. Use when a feature works but needs polish, for "완성도 높여줘", "production ready로", "edge case 검토", "polish this feature", "is this ready to ship?", "엣지 케이스 다 챙겼나", "PR 전 점검", "빠진 상태 없나", or before shipping any non-trivial feature. Also triggers proactively right before PR creation on a non-trivial branch. Triggers even when the diff is small or the happy path was verified manually; gaps emerge from state interactions (empty/loading/error/disabled, role and locale variants), not line count, and "I already clicked through it in Playwright" does not substitute for the audit. Distinct from brainstorming (designs), test-driven-development (implements), and requesting-code-review (evaluates structure); raises the bar of a working impl via production-readiness audit.
    0
    installs