Using ssep

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-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:

1. 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.
2. 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.
3. 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.
4. 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.