Using ssep
<SUBAGENT-STOP> If you were dispatched as a subagent to execute a specific task, skip this skill. </SUBAGENT-STOP> <EXTREMELY-IMPORTANT> If 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.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. </EXTREMELY-IMPORTANT>
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-reviewsuffices. - TDD / debugging / planning →
superpowerscovers 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-policywas skipped. Spec gap (column ordering between PRD v5 and Figma) was discovered only mid-implementation. - Implementation completed, screenshots taken →
reviewing-design-fidelitywas 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-completenesswas 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-testswas 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.