Using ssep
The four ssep skills are designed to fire at specific workflow phases. Skipping them is the dominant failure mode observed in real sessions, not lack of trigger keywords. This skill exists to make the skip impossible to rationalize away.
The matrix — evaluate at every task entry
Before any other action, classify the current task against this matrix. The matching skill MUST be invoked at the matching moment. Do not start implementation, do not start clarifying, do not read source files until the matrix has been evaluated.
| Phase / Signal |
Required ssep skill |
Why this fires |
| Figma URL + planning context (no implementation yet) |
reviewing-spec-and-policy |
Concise requirements hide unstated edges. Audit before code. |
| PRD / RFC / spec doc shared |
reviewing-spec-and-policy |
Same — gap detection before implementation. |
| Figma URL + existing implementation OR Figma URL + live URL/screenshot |
reviewing-design-fidelity |
Drift is invisible alone; structured side-by-side catches it. |
| Feature implemented, happy path passes, PR pending |
improving-feature-completeness |
"Works on the happy path" is 50% done. State/i18n/a11y/observability audit. |
| Just before merge, just after deploy, "staging 확인", "e2e", "통합 테스트" |
running-integration-tests |
Manual click ≠ codified regression. Cross-boundary surprises cluster here. |
| Multi-phase task (e.g., "implement this design and verify on staging") |
Chain all relevant skills in order: spec → impl → fidelity → completeness → integration |
Each phase has its own audit; skipping intermediate phases hides drift downstream. |
The chain
Figma URL shared
└─ reviewing-spec-and-policy (BEFORE implementation)
└─ (implementation — use superpowers skills as needed)
└─ reviewing-design-fidelity (AFTER implementation, BEFORE merge)
└─ improving-feature-completeness (BEFORE PR creation)
└─ running-integration-tests (AFTER staging deploy)
A skill that completes its run MUST announce the next skill in the chain when the next phase is reachable, so the chain does not break at handoffs.
Red flags — these thoughts mean STOP
Each of these is a documented skip rationalization from real sessions. When you catch yourself thinking one of these, invoke the matched ssep skill instead of acting on the rationalization.
| Thought |
Reality |
Required action |
| "It's a single-line CSS swap, fidelity check is overkill" |
Fidelity check decides scope. A single-line swap can have cascade in state variants. |
Invoke reviewing-design-fidelity — it picks quick check vs full audit. |
| "The requirement is one sentence, no spec to audit" |
Concise sentences hide edges (default for existing rows, role differences, state transitions). |
Invoke reviewing-spec-and-policy. |
| "Happy path passed in Playwright, ship it" |
State coverage (empty/loading/error/disabled) and i18n/a11y are not checked by happy-path e2e. |
Invoke improving-feature-completeness. |
| "I already clicked through it manually" |
Manual ≠ regression test. The next change breaks it silently. |
Invoke running-integration-tests. |
| "I'll just do this one thing first" |
The matrix takes 30 seconds. The skipped audit costs a re-work cycle. |
Evaluate matrix first. |
| "Figma was fetched, the agent has the context" |
Fetching ≠ comparing. Source-of-truth comparison is the skill's job. |
Invoke reviewing-design-fidelity. |
When NOT to use ssep
- Pure refactor with no UI or spec surface →
superpowers:requesting-code-review suffices.
- TDD / debugging / planning →
superpowers covers these; ssep is the orthogonal specialized review surface.
- Subagent dispatched with a specific narrow task → respect the subagent contract and skip the matrix.
Composition with superpowers
ssep does not replace superpowers. The two compose:
superpowers:brainstorming → design generation. ssep:reviewing-spec-and-policy → audit what was designed.superpowers:test-driven-development → unit-level TDD. ssep:running-integration-tests → integration/e2e tier.superpowers:requesting-code-review → code structure review. ssep:improving-feature-completeness → production-readiness review.superpowers:using-superpowers → generic skill discipline. ssep:using-ssep → this matrix.
If both apply, invoke both — they answer different questions.
Real-session retrospective: what skipping looks like
A real session where all four skills should have fired but were each skipped under "task looks small" reasoning:
- Figma URL shared with implementation request →
reviewing-spec-and-policy was skipped. Spec gap (column ordering between PRD v5 and Figma) was discovered only mid-implementation.
- Implementation completed, screenshots taken →
reviewing-design-fidelity was skipped (figma fetch was relied on for "context" but not structured side-by-side comparison). Visual gaps (table-look vs plain grid, section grouping, section titles) surfaced after merge when the user pointed them out. Re-work PR was needed.
- PR ready →
improving-feature-completeness was skipped. Edge cases (raw enum number leaked to UI label when both list screen and i18n key map already existed) were not surfaced until visual verification.
- staging deploy verified manually with Playwright →
running-integration-tests was skipped — Playwright was used ad-hoc but no codified test was added; the manual session became the only artifact.
Net cost of all four skips: re-work PRs, multiple staging deploys, and the user discovering issues that the matrix would have caught in minutes.
The matrix exists because the model is biased toward "looks fast, just do it." This skill makes that bias visible at the decision point.
1---2name: using-ssep3description: 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.4---56# Using ssep78<SUBAGENT-STOP>9If you were dispatched as a subagent to execute a specific task, skip this skill.10</SUBAGENT-STOP>1112<EXTREMELY-IMPORTANT>13If there is even a 1% chance one of the four ssep skills applies to the work in front of you, evaluate the matrix BEFORE doing anything else — including reading files, asking clarifying questions, or invoking superpowers skills.1415The four ssep skills are designed to fire at specific workflow phases. Skipping them is the dominant failure mode observed in real sessions, not lack of trigger keywords. This skill exists to make the skip impossible to rationalize away.16</EXTREMELY-IMPORTANT>1718## The matrix — evaluate at every task entry1920Before any other action, classify the current task against this matrix. The matching skill MUST be invoked at the matching moment. Do not start implementation, do not start clarifying, do not read source files until the matrix has been evaluated.2122| Phase / Signal | Required ssep skill | Why this fires |23|---|---|---|24| **Figma URL + planning context** (no implementation yet) | `reviewing-spec-and-policy` | Concise requirements hide unstated edges. Audit before code. |25| **PRD / RFC / spec doc shared** | `reviewing-spec-and-policy` | Same — gap detection before implementation. |26| **Figma URL + existing implementation OR Figma URL + live URL/screenshot** | `reviewing-design-fidelity` | Drift is invisible alone; structured side-by-side catches it. |27| **Feature implemented, happy path passes, PR pending** | `improving-feature-completeness` | "Works on the happy path" is 50% done. State/i18n/a11y/observability audit. |28| **Just before merge, just after deploy, "staging 확인", "e2e", "통합 테스트"** | `running-integration-tests` | Manual click ≠ codified regression. Cross-boundary surprises cluster here. |29| **Multi-phase task** (e.g., "implement this design and verify on staging") | **Chain all relevant skills** in order: spec → impl → fidelity → completeness → integration | Each phase has its own audit; skipping intermediate phases hides drift downstream. |3031## The chain3233```34Figma URL shared35 └─ reviewing-spec-and-policy (BEFORE implementation)36 └─ (implementation — use superpowers skills as needed)37 └─ reviewing-design-fidelity (AFTER implementation, BEFORE merge)38 └─ improving-feature-completeness (BEFORE PR creation)39 └─ running-integration-tests (AFTER staging deploy)40```4142A skill that completes its run MUST announce the next skill in the chain when the next phase is reachable, so the chain does not break at handoffs.4344## Red flags — these thoughts mean STOP4546Each of these is a documented skip rationalization from real sessions. When you catch yourself thinking one of these, invoke the matched ssep skill instead of acting on the rationalization.4748| Thought | Reality | Required action |49|---|---|---|50| "It's a single-line CSS swap, fidelity check is overkill" | Fidelity check decides scope. A single-line swap can have cascade in state variants. | Invoke `reviewing-design-fidelity` — it picks quick check vs full audit. |51| "The requirement is one sentence, no spec to audit" | Concise sentences hide edges (default for existing rows, role differences, state transitions). | Invoke `reviewing-spec-and-policy`. |52| "Happy path passed in Playwright, ship it" | State coverage (empty/loading/error/disabled) and i18n/a11y are not checked by happy-path e2e. | Invoke `improving-feature-completeness`. |53| "I already clicked through it manually" | Manual ≠ regression test. The next change breaks it silently. | Invoke `running-integration-tests`. |54| "I'll just do this one thing first" | The matrix takes 30 seconds. The skipped audit costs a re-work cycle. | Evaluate matrix first. |55| "Figma was fetched, the agent has the context" | Fetching ≠ comparing. Source-of-truth comparison is the skill's job. | Invoke `reviewing-design-fidelity`. |5657## When NOT to use ssep5859- Pure refactor with no UI or spec surface → `superpowers:requesting-code-review` suffices.60- TDD / debugging / planning → `superpowers` covers these; ssep is the orthogonal specialized review surface.61- Subagent dispatched with a specific narrow task → respect the subagent contract and skip the matrix.6263## Composition with superpowers6465ssep does not replace `superpowers`. The two compose:6667- `superpowers:brainstorming` → design generation. `ssep:reviewing-spec-and-policy` → audit what was designed.68- `superpowers:test-driven-development` → unit-level TDD. `ssep:running-integration-tests` → integration/e2e tier.69- `superpowers:requesting-code-review` → code structure review. `ssep:improving-feature-completeness` → production-readiness review.70- `superpowers:using-superpowers` → generic skill discipline. `ssep:using-ssep` → this matrix.7172If both apply, invoke both — they answer different questions.7374## Real-session retrospective: what skipping looks like7576A real session where all four skills should have fired but were each skipped under "task looks small" reasoning:77781. **Figma URL shared with implementation request** → `reviewing-spec-and-policy` was skipped. Spec gap (column ordering between PRD v5 and Figma) was discovered only mid-implementation.792. **Implementation completed, screenshots taken** → `reviewing-design-fidelity` was skipped (figma fetch was relied on for "context" but not structured side-by-side comparison). Visual gaps (table-look vs plain grid, section grouping, section titles) surfaced **after merge** when the user pointed them out. Re-work PR was needed.803. **PR ready** → `improving-feature-completeness` was skipped. Edge cases (raw enum number leaked to UI label when both list screen and i18n key map already existed) were not surfaced until visual verification.814. **staging deploy verified manually with Playwright** → `running-integration-tests` was skipped — Playwright was used ad-hoc but no codified test was added; the manual session became the only artifact.8283Net cost of all four skips: re-work PRs, multiple staging deploys, and the user discovering issues that the matrix would have caught in minutes.8485The matrix exists because the model is biased toward "looks fast, just do it." This skill makes that bias visible at the decision point.
pacho-h