@captain_z/zsk-skills 0.1.0 → 1.0.0

package/README.md

@@ -62,202 +62,211 @@ zsk skill 是 LLM **按需自动触发**的资产：
 | `frontend-with-design-handoff` | 31 | frontend-project + Figma 交付 2 |
 | `custom` | 交互 | 通过 `zsk add` 任意多选 |
 
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 46 skills -->
+
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 46 skills -->
+
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 46 skills -->
+
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 46 skills -->
+
 ## Skill 清单（按领域）
 
 > 内容由 `tools/catalog.ts` 从各 SKILL.md frontmatter 生成。重生成：`pnpm catalog`。
 
-### `sdlc/` — SDLC · 7 阶段 + 3 变更工作流 + task 框架（17）
+### `sdlc/` — SDLC · 7 阶段 + 3 变更工作流 + task 框架 (17)
 
 - **`zsk:proposal`** *[stage 1 · stage · core]*
-  Use when starting a new change (feature / bugfix / refactor) and you need to frame the why, success criteria, out-of-scope boundary, alternatives considered, and risks before any spec work. Always the first stage of the 7-stage SDLC.
+  New-change framing (feature / bugfix / refactor) before spec work — why, success criteria, out-of-scope boundary, alternatives considered, and risks. Always the first stage of the 7-stage SDLC.
   触发：`new feature proposal` · `bug report` · `refactor trigger` · `SMART goals`
 
 - **`zsk:spec`** *[stage 2 · stage · core]*
-  Use when the proposal is approved and you need to write the behavioral contract — User Stories (INVEST), FR / NFR / AC numbering, BDD scenarios, edge cases, term glossary. Stage 2 of the 7-stage SDLC.
-  触发：`writing spec` · `user stories` · `acceptance criteria` · `FR NFR numbering`
+  Behavioral contract writing after proposal approval — scope, numbered functional and non-functional requirements, scenarios, acceptance criteria, edge cases, and impact boundaries. Stage 2 of the 7-stage SDLC.
+  触发：`writing spec` · `behavior contract` · `acceptance criteria` · `numbered requirements`
 
 - **`zsk:design`** *[stage 3 · stage · core]*
-  Use when the spec is frozen and you need to translate FR/NFR into concrete implementation plans — ADR decisions, architecture diagrams (C4 + sequence), file responsibilities, FR→code mapping, error handling, rollback, observability. Stage 3 of the 7-stage SDLC.
-  触发：`technical design` · `ADR architecture decision` · `C4 diagram` · `FR mapping`
+  Solution design after spec freeze — current-state scan, architectural decisions, implementation mapping, delivery slices, risks, rollback, and observability. Stage 3 of the 7-stage SDLC.
+  触发：`technical design` · `solution design` · `architecture decision` · `current state scan`
 
 - **`zsk:coding`** *[stage 4 · stage · core]*
-  Use when the design is frozen and you need to execute — write code and tests, follow branch/commit conventions, enforce TDD for bugfix/refactor, respect dependency hygiene, pass local quality gates before review. Stage 4 of the 7-stage SDLC.
-  触发：`implementing design` · `TDD red green refactor` · `conventional commits` · `gitlab flow`
+  Implementation execution after design freeze — smallest viable change, task-by-task delivery, test-first where risk is high, continuous evidence capture, and local quality gates before review. Stage 4 of the 7-stage SDLC.
+  触发：`implementing design` · `task by task delivery` · `local quality gates` · `smallest viable change`
 
 - **`zsk:reviewing`** *[stage 5 · stage · core]*
-  Use when submitting or receiving a PR for code review — self-checklist, reviewer checklist, Conventional Comments prefixes, technical-rigor-over-performative-agreement when receiving feedback, dispute escalation path. Stage 5 of the 7-stage SDLC. This is the code-view (does the diff look right); the contract-view is zsk:verify.
+  PR code review — self-checklist, reviewer checklist, Conventional Comments prefixes, technical-rigor-over-performative-agreement when receiving feedback, dispute escalation path. Stage 5 of the 7-stage SDLC. This is the code-view (does the diff look right); the contract-view is zsk:verify.
   触发：`code review` · `PR review` · `conventional comments` · `receiving feedback`
 
 - **`zsk:verify`** *[stage 6 · stage · core]*
-  Use when about to merge to main — the hard "evidence before assertion" gate. Requires DoD fully green, FR coverage matrix complete, AC checklist ticked with links, validation records with reproducible evidence. Stage 6 of the 7-stage SDLC. This is the contract-view; the code-view is zsk:reviewing.
-  触发：`acceptance verification` · `definition of done` · `FR coverage matrix` · `evidence before assertion`
+  Acceptance verification before merge — independent contract check, FR/NFR coverage, AC evidence, gate records, and verdict with reproducible proof. Stage 6 of the 7-stage SDLC.
+  触发：`acceptance verification` · `evidence before assertion` · `FR coverage matrix` · `AC evidence`
 
 - **`zsk:archive`** *[stage 7 · stage · core]*
-  Use when closing an iteration — move historical snapshots to docs/{module}/archive/, write postmortem (P0/P1 mandatory), update changelog (SemVer + Keep a Changelog), flush ADRs, update SYSTEM-SPEC if cross-module constraints emerged, feed back to standards/system docs. Stage 7 of the 7-stage SDLC.
+  Iteration closing / archive — move historical snapshots to docs/{module}/archive/, write postmortem (P0/P1 mandatory), update changelog (SemVer + Keep a Changelog), flush ADRs, update SYSTEM-SPEC if cross-module constraints emerged, feed back to standards/system docs. Stage 7 of the 7-stage SDLC.
   触发：`archive iteration` · `postmortem` · `changelog` · `ADR flush`
 
 - **`zsk:bugfix-tasks`** *[core]*
-  Use when implementing a bugfix — the TDD-enforced task template. Step 1 Red (write failing reproduction test), Step 2 Green (minimal fix, no opportunistic refactor), Step 3 Regression (adjacent scenarios), Step 4 Evidence (before/after reproduction). Requires Superpowers' 3 confidence questions before starting.
+  Bugfix task template with TDD enforcement — Step 1 Red (write failing reproduction test), Step 2 Green (minimal fix, no opportunistic refactor), Step 3 Regression (adjacent scenarios), Step 4 Evidence (before/after reproduction). Requires Superpowers' 3 confidence questions before starting.
   触发：`bugfix task template` · `TDD bug fix` · `red green regression` · `bug confidence questions`
 
 - **`zsk:dor-dod`** *[core]*
-  Use when transitioning between SDLC stages to gate starting a task (DoR) and closing a task (DoD). Generic DoR/DoD for all change types; frontend-specific rows (UE matrix / ue-mcp / 三语 i18n / 视觉回归 / axe) are in frontend:dor-dod-frontend.
+  DoR/DoD gates between SDLC stages — generic DoR/DoD for all change types; frontend-specific rows (UE matrix / ue-mcp / 三语 i18n / 视觉回归 / axe) are in frontend:dor-dod-frontend.
   触发：`definition of ready` · `definition of done` · `DoR DoD` · `task gate`
 
 - **`zsk:refactor-tasks`** *[core]*
-  Use when implementing a refactor — the characterization + small-step atomic task template. Step 1 capture behavior baseline, Step 2 apply one Fowler technique per atomic commit (revert on red), Step 3 Parallel Change for large refactors (Expand → Migrate → Contract), Step 4 prepare behavior-unchanged evidence.
+  Refactor task template (characterization + small-step atomic) — Step 1 capture behavior baseline, Step 2 apply one Fowler technique per atomic commit (revert on red), Step 3 Parallel Change for large refactors (Expand → Migrate → Contract), Step 4 prepare behavior-unchanged evidence.
   触发：`refactor task template` · `characterization baseline` · `Fowler techniques` · `Parallel Change tasks`
 
 - **`zsk:task`** *[core]*
-  Use when you need the cross-stage task execution mindset — what a task is, how it threads spec → verify, which template to pick by change type, cross-stage hard principles. Not for writing a specific task; use zsk:task-structure for that.
+  Cross-stage task execution mindset — what a task is, how it threads spec → verify, which template to pick by change type, cross-stage hard principles. Not for writing a specific task; use zsk:task-structure for that.
   触发：`task framework` · `task execution overview` · `cross-stage tasks` · `which task template`
 
 - **`zsk:task-evidence`** *[core]*
-  Use when handing a task to verify — fill the FR coverage matrix (every FR/NFR from spec has coverage task + acceptance evidence), AC checklist with reproducible links, validation records per gate (lint/type-check/test/security/etc.). Enforces "evidence before assertion" — links must be clickable and reproducible.
+  Task verification evidence discipline — FR coverage matrix (every FR/NFR from spec has coverage task + acceptance evidence), AC checklist with reproducible links, validation records per gate (lint/type-check/test/security/etc.). Enforces "evidence before assertion" — links must be clickable and reproducible.
   触发：`FR coverage matrix` · `AC verification` · `validation record` · `evidence links`
 
 - **`zsk:task-structure`** *[core]*
-  Use when writing a tasks.md — set task granularity (0.5-2 person-days), two-level structure (parent/child, no deeper), estimation unit (T-shirt or Fibonacci), required fields per task (status/owner/covers-FR/deliverable/verification), FR coverage numbering rules.
+  tasks.md authoring discipline — task granularity (0.5-2 person-days), two-level structure (parent/child, no deeper), estimation unit (T-shirt or Fibonacci), required fields per task (status/owner/covers-FR/deliverable/verification), FR coverage numbering rules.
   触发：`task granularity` · `task estimation` · `T-shirt sizing` · `story points`
 
 - **`zsk:task-tracking`** *[core]*
-  Use when executing tasks and tracking dependencies (Mermaid graph), blockers (dated log with severity H/M/L and escalation rules), milestones (stage exits with committed dates), and task state transitions (TODO → DOING → DONE, with BLOCKED requiring log entry). Includes **§6 每任务交互契约**：LLM 执行单任务后必须 "更新状态 → 填证据 → 短汇报 → 等人类确认"，不自动连跑。
+  Task execution tracking — dependencies (Mermaid graph), blockers (dated log with severity H/M/L and escalation rules), milestones (stage exits with committed dates), and task state transitions (TODO → DOING → DONE, with BLOCKED requiring log entry).
   触发：`task dependency graph` · `blocker log` · `milestones` · `task state flow`
 
 - **`zsk:bugfix`** *[workflow · core]*
-  Use when fixing an existing defect end-to-end — triage → reproduce → RCA (5 Whys with confidence questions) → TDD fix (red first) → regression coverage → postmortem (P0/P1 mandatory). Enforces Superpowers' bug confidence questioning discipline.
+  Bugfix end-to-end orchestration — triage → reproduce → RCA (5 Whys with confidence questions) → TDD fix (red first) → regression coverage → postmortem (P0/P1 mandatory). Enforces Superpowers' bug confidence questioning discipline.
   触发：`bug fix workflow` · `fix defect` · `RCA` · `5 whys`
 
 - **`zsk:feature`** *[workflow · core]*
-  Use when building a new feature end-to-end — orchestrates the 7 SDLC stages for the feature change type. Walks you through brainstorming → writing-plans → plan-eng-review → executing-plans+TDD → requesting/receiving-code-review → verification-before-completion → finishing-a-development-branch.
+  Feature end-to-end orchestration across 7 SDLC stages — brainstorming → writing-plans → plan-eng-review → executing-plans+TDD → requesting/receiving-code-review → verification-before-completion → finishing-a-development-branch.
   触发：`new feature workflow` · `feature end to end` · `start feature` · `feature stages`
 
 - **`zsk:refactor`** *[workflow · core]*
-  Use when refactoring code without changing observable behavior — Fowler catalog, characterization tests as baseline, small atomic commits, Parallel Change / Strangler Fig for large refactors. Enforces "behavior preserved" as a hard contract (any behavior change means it's not a refactor).
+  Behavior-preserving refactor discipline — Fowler catalog, characterization tests as baseline, small atomic commits, Parallel Change / Strangler Fig for large refactors. Enforces "behavior preserved" as a hard contract (any behavior change means it is not a refactor).
   触发：`refactor workflow` · `Fowler refactoring` · `characterization test` · `Parallel Change`
 
-### `frontend/` — Frontend · React + Web 层实现规范（16）
+### `frontend/` — Frontend · React + Web 层实现规范 (16)
 
 - **`zsk:spec-frontend`** *[stage 2 · stage · optional]*
-  Use when writing spec.md for a frontend component / page — adds Component Public Contract (Props / Events / TS types), UE state matrix with a11y attributes, UE/MCP reference, and the 6-category Frontend NFR (performance / a11y / security / i18n / compat / observability). Extends the generic zsk:spec framework.
+  Frontend component/page spec.md authoring — adds Component Public Contract (Props / Events / TS types), UE state matrix with a11y attributes, UE/MCP reference, and the 6-category Frontend NFR (performance / a11y / security / i18n / compat / observability). Extends the generic zsk:spec framework.
   触发：`frontend spec` · `Component Public Contract` · `Props Event Contract` · `UE state matrix`
 
 - **`zsk:design-frontend`** *[stage 3 · stage · optional]*
-  Use when writing design.md for a frontend module — adds Props/state/event implementation mapping, UE-state-to-structure mapping, Figma-to-implementation mapping, performance budget (Core Web Vitals), ErrorBoundary placement. Extends the generic zsk:design framework.
+  Frontend module design.md authoring — adds Props/state/event implementation mapping, UE-state-to-structure mapping, Figma-to-implementation mapping, performance budget (Core Web Vitals), ErrorBoundary placement. Extends the generic zsk:design framework.
   触发：`frontend design` · `Props implementation mapping` · `UE state to structure` · `Figma to implementation`
 
 - **`zsk:review-frontend`** *[stage 5 · stage · optional]*
-  Use when reviewing frontend code in a PR — frontend-specific self-checklist and reviewer checklist covering TypeScript red lines (no any / @ts-ignore), React hooks rules, dangerouslySetInnerHTML, large-list performance hazards, visual regression, i18n three-language sync, jsx-a11y. Extends zsk:reviewing generic checklist.
+  Frontend PR code review — frontend-specific self-checklist and reviewer checklist covering TypeScript red lines (no any / @ts-ignore), React hooks rules, dangerouslySetInnerHTML, large-list performance hazards, visual regression, i18n three-language sync, jsx-a11y. Extends zsk:reviewing generic checklist.
   触发：`frontend code review` · `React review checklist` · `TypeScript red lines` · `hooks review`
 
 - **`zsk:dor-dod-frontend`** *[optional]*
-  Use when transitioning between SDLC stages for frontend modules — frontend-specific DoR/DoD rows on top of the generic checklist. Covers UE state matrix completeness, ue-mcp.md registration, visual regression, three-language i18n sync, a11y (keyboard/aria/focus), frontend NFR (CWV) evidence.
+  Frontend-specific DoR/DoD for SDLC stage transitions — frontend-specific rows on top of the generic checklist. Covers UE state matrix completeness, ue-mcp.md registration, visual regression, three-language i18n sync, a11y (keyboard/aria/focus), frontend NFR (CWV) evidence.
   触发：`frontend DoR DoD` · `frontend definition of ready done` · `UE matrix gate` · `visual regression gate`
 
 - **`zsk:feature-tasks-frontend`** *[optional]*
-  Use when building a new frontend component/page feature — the 7-category mandatory task template (事实源对齐 / Props 契约 / UE-MCP 刷新 / UE 状态 / 测试 / 视觉回归 / 质量门禁). Enforces TDD-first, contract-driven, evidence-before-assertion.
+  Frontend component/page feature task template — 7-category mandatory (事实源对齐 / Props 契约 / UE-MCP 刷新 / UE 状态 / 测试 / 视觉回归 / 质量门禁). Enforces TDD-first, contract-driven, evidence-before-assertion.
   触发：`frontend feature tasks` · `component tasks template` · `7 category tasks` · `Props UE state visual regression`
 
 - **`zsk:nfr-web`** *[optional]*
-  Use when establishing concrete Web-side thresholds for the 7-category NFR framework — Core Web Vitals (LCP/INP/CLS/TTFB/TTI targets), WCAG 2.1 AA itemized rules, Web security NFR items, i18n language list + baseline + entry + RTL, browser/OS/device compatibility matrix, responsive breakpoints, observability (web-vitals + error reporting), reliability (ErrorBoundary + timeout + retry). Inherits system/nfr-baseline; modules declare deviations only.
+  Web-side NFR thresholds for the 7-category framework — Core Web Vitals (LCP/INP/CLS/TTFB/TTI targets), WCAG 2.1 AA itemized rules, Web security NFR items, i18n language list + baseline + entry + RTL, browser/OS/device compatibility matrix, responsive breakpoints, observability (web-vitals + error reporting), reliability (ErrorBoundary + timeout + retry). Inherits system/nfr-baseline; modules declare deviations only.
   触发：`Web NFR` · `CWV thresholds` · `WCAG AA rules` · `browser matrix`
 
 - **`zsk:a11y-web`** *[standard · optional]*
-  Use when implementing accessibility in React/JSX — label association (htmlFor/wrap), aria props usage, Modal focus trap (inert + initialFocus + restoreFocus), dialog role, live regions for async, skip link, axe-core + jsx-a11y toolchain, keyboard event handlers, prefers-reduced-motion. Implementation layer; principles (WCAG, POUR, contrast) live in quality/a11y-principles.
+  React/JSX accessibility implementation — label association (htmlFor/wrap), aria props usage, Modal focus trap (inert + initialFocus + restoreFocus), dialog role, live regions for async, skip link, axe-core + jsx-a11y toolchain, keyboard event handlers, prefers-reduced-motion. Implementation layer; principles (WCAG, POUR, contrast) live in quality/a11y-principles.
   触发：`jsx a11y` · `focus trap` · `Modal accessibility` · `axe-core`
 
 - **`zsk:api-contract-ts`** *[standard · optional]*
-  Use when integrating a TypeScript frontend with a backend API — never hand-write API types, always consume from the shared types package or generated codegen. Covers source-of-truth pattern (backend-owned types), codegen workflows (OpenAPI / GraphQL / tRPC / Protobuf), breaking-change handling, version discipline, runtime validation (Zod at boundary), and service-layer shape. Pairs with typescript.md red lines.
+  TypeScript frontend × backend API contract — never hand-write API types, always consume from the shared types package or generated codegen. Covers source-of-truth pattern (backend-owned types), codegen workflows (OpenAPI / GraphQL / tRPC / Protobuf), breaking-change handling, version discipline, runtime validation (Zod at boundary), and service-layer shape. Pairs with typescript.md red lines.
   触发：`API type sync` · `do not hand-write API types` · `OpenAPI codegen` · `GraphQL codegen`
 
-- **`zsk:css-bem`** *[standard · optional]*
-  Use when writing CSS / Less / Sass / CSS Modules / Tailwind in a frontend module — CSS scheme detection (Less/Sass/CSS Modules/Tailwind/native), BEM naming (Block__Element--Modifier), nesting discipline (≤3 layers), token usage rules (no hardcoded color/spacing), scope isolation, responsive breakpoints, and !important prohibition.
-  触发：`CSS scheme detection` · `BEM naming` · `Less nesting` · `design token`
-
 - **`zsk:i18n`** *[standard · optional]*
-  Use when implementing i18n in a frontend module — unified entry (i18n.t with mandatory fallback), key namespace structure (namespace.module.leaf_key), three-language sync rule (commit-atomic), ICU MessageFormat for plural/select, Intl.* for date/number/currency, RTL declaration, React Trans component for JSX interpolation. Replaces standards/i18n for frontend scope.
+  Frontend module i18n implementation — unified entry (i18n.t with mandatory fallback), key namespace structure (namespace.module.leaf_key), three-language sync rule (commit-atomic), ICU MessageFormat for plural/select, Intl.* for date/number/currency, RTL declaration, React Trans component for JSX interpolation. Replaces standards/i18n for frontend scope.
   触发：`i18n implementation` · `key namespace` · `fallback baseline` · `ICU plural`
 
 - **`zsk:performance-web`** *[standard · optional]*
-  Use when optimizing a React / Web frontend for Core Web Vitals — CWV thresholds (LCP/INP/CLS/TTFB/TTI), React memoization discipline (when to memo vs not), virtualization for lists ≥ 200, lazy loading via React.lazy + Suspense + IntersectionObserver, bundle splitting + tree-shaking, image srcset + loading="lazy", debounce/throttle, re-render diagnosis with React DevTools Profiler. Implementation layer; budget framework in system/nfr-baseline + frontend/nfr-web.
+  React / Web frontend performance for Core Web Vitals — CWV thresholds (LCP/INP/CLS/TTFB/TTI), React memoization discipline (when to memo vs not), virtualization for lists ≥ 200, lazy loading via React.lazy + Suspense + IntersectionObserver, bundle splitting + tree-shaking, image srcset + loading="lazy", debounce/throttle, re-render diagnosis with React DevTools Profiler. Implementation layer; budget framework in system/nfr-baseline + frontend/nfr-web.
   触发：`Core Web Vitals` · `LCP INP CLS` · `React memo` · `virtual scrolling`
 
 - **`zsk:react-components`** *[standard · optional]*
-  Use when designing React component APIs — layering (UI/logic separation via hooks), composition vs configuration (compound components over flat-prop explosion), granularity (5-question checklist), controlled vs uncontrolled boundary, Props API design. React-specific implementation of generic component discipline.
+  React component API design — layering (UI/logic separation via hooks), composition vs configuration (compound components over flat-prop explosion), granularity (5-question checklist), controlled vs uncontrolled boundary, Props API design. React-specific implementation of generic component discipline.
   触发：`React component design` · `compound components` · `component granularity` · `controlled uncontrolled`
 
 - **`zsk:react-naming`** *[standard · optional]*
-  Use when naming React components, files, folders, variables, booleans, event handlers, event props, hooks, TS types/interfaces, constants, and i18n keys — the complete naming convention table for a React + TypeScript codebase. Principles transfer to Vue/Svelte with syntax adjustments.
+  React + TypeScript naming conventions — components, files, folders, variables, booleans, event handlers, event props, hooks, TS types/interfaces, constants, and i18n keys. Principles transfer to Vue/Svelte with syntax adjustments.
   触发：`React naming` · `component file naming` · `event handler naming` · `boolean naming`
 
 - **`zsk:security-web`** *[standard · optional]*
-  Use when addressing Web frontend security — XSS (React default escape + dangerouslySetInnerHTML red line + DOMPurify exception), URL protocol whitelist, Storage red lines (no sensitive data in Local/SessionStorage), CSRF token integration, console log scrubbing for production, CSP meta/header consumption, SRI for third-party scripts, clickjacking (frame-ancestors awareness), postMessage origin checks. Frontend UI is the convenience defense; backend is final.
+  Web frontend security — XSS (React default escape + dangerouslySetInnerHTML red line + DOMPurify exception), URL protocol whitelist, Storage red lines (no sensitive data in Local/SessionStorage), CSRF token integration, console log scrubbing for production, CSP meta/header consumption, SRI for third-party scripts, clickjacking (frame-ancestors awareness), postMessage origin checks. Frontend UI is the convenience defense; backend is final.
   触发：`dangerouslySetInnerHTML` · `XSS React` · `DOMPurify` · `LocalStorage sensitive`
 
+- **`zsk:styling-system`** *[standard · optional]*
+  Frontend styling system discipline — scheme detection, naming conventions, nesting depth (≤3 layers), token usage rules (no hardcoded color/spacing), scope isolation, responsive breakpoints, and !important prohibition across Less / Sass / CSS Modules / Tailwind / CSS-in-JS.
+  触发：`CSS scheme detection` · `BEM naming` · `Less nesting` · `design token`
+
 - **`zsk:testing-web`** *[standard · optional]*
-  Use when setting up or writing frontend tests for a React codebase — the full toolchain (Jest/Vitest + React Testing Library + renderHook + user-event + MSW + Playwright + Chromatic + jest-axe), test structure (AAA/GWT), mock strategy (MSW for HTTP, manual for modules), coverage thresholds (new code / global), and the component test template. Implementation layer; cross-stack principles live in quality/testing-pyramid.
+  Frontend tests for React codebases — full toolchain (Jest/Vitest + React Testing Library + renderHook + user-event + MSW + Playwright + Chromatic + jest-axe), test structure (AAA/GWT), mock strategy (MSW for HTTP, manual for modules), coverage thresholds (new code / global), and the component test template. Implementation layer; cross-stack principles live in quality/testing-pyramid.
   触发：`Jest Vitest` · `React Testing Library` · `MSW mock service worker` · `Playwright`
 
 - **`zsk:typescript`** *[standard · optional]*
-  Use when writing TypeScript in a frontend codebase — red lines (no any / as any / @ts-ignore / empty interface / Object type), must-do (explicit types for public boundaries, union literals, strict + noUncheckedIndexedAccess), API types from backend (not hand-written), type vs interface, generics discipline, unknown over any. Complements quality/code-hygiene for cross-language hygiene.
+  TypeScript in frontend codebases — red lines (no any / as any / @ts-ignore / empty interface / Object type), must-do (explicit types for public boundaries, union literals, strict + noUncheckedIndexedAccess), API types from backend (not hand-written), type vs interface, generics discipline, unknown over any. Complements quality/code-hygiene for cross-language hygiene.
   触发：`TypeScript red lines` · `no any` · `strict mode` · `noUncheckedIndexedAccess`
 
-### `quality/` — Quality · 跨栈质量原则（5）
+### `quality/` — Quality · 跨栈质量原则 (5)
 
 - **`zsk:a11y-principles`** *[standard · optional]*
-  Use when thinking about accessibility at the concept level — WCAG 2.1 AA baseline, POUR principles, keyboard operation matrix, focus management, aria semantics, contrast ratios, don't-rely-on-color, reduced motion. For Web/JSX implementation (axe-core, jsx-a11y, focus traps in Modal, etc.) see frontend/a11y-web.md.
+  Accessibility principles at the concept level — WCAG 2.1 AA baseline, POUR principles, keyboard operation matrix, focus management, aria semantics, contrast ratios, don't-rely-on-color, reduced motion. For Web/JSX implementation (axe-core, jsx-a11y, focus traps in Modal, etc.) see frontend/a11y-web.md.
   触发：`accessibility principles` · `WCAG AA` · `POUR` · `keyboard matrix`
 
 - **`zsk:code-hygiene`** *[standard · optional]*
-  Use when writing code in any language — comment policy (WHY not WHAT), import ordering principle, formatter discipline, generic forbidden patterns (TODO comments, commented-out code, signature-like comments). Stack-specific rules (TypeScript red lines, React naming) are in frontend/*.
+  Code hygiene for any language — comment policy (WHY not WHAT), import ordering principle, formatter discipline, generic forbidden patterns (TODO comments, commented-out code, signature-like comments). Stack-specific rules (TypeScript red lines, React naming) are in frontend/*.
   触发：`code hygiene` · `comment policy` · `import order` · `WHY not WHAT`
 
 - **`zsk:release`** *[standard · optional]*
-  Use when shipping a version — SemVer numbering, Keep a Changelog, Conventional Changelog auto-generation, environment promotion (dev→test→pre→prod), feature flag lifecycle, rollback strategy, hotfix process, canary monitoring. Works across language stacks; tool names are stack-specific examples.
+  Version release discipline — SemVer numbering, Keep a Changelog, Conventional Changelog auto-generation, environment promotion (dev→test→pre→prod), feature flag lifecycle, rollback strategy, hotfix process, canary monitoring. Works across language stacks; tool names are stack-specific examples.
   触发：`SemVer` · `changelog` · `conventional changelog` · `hotfix`
 
 - **`zsk:security-owasp`** *[standard · optional]*
-  Use when addressing cross-stack security concerns — OWASP Top 10 overview, CVE response SLAs, dependency license whitelist, supply chain hygiene, common lint red lines (eval/dynamic execution), and the "frontend UI is not the final defense" principle. Web-specific XSS/CSRF/Storage red lines are in frontend/security-web.md.
+  Cross-stack security discipline — OWASP Top 10 overview, CVE response SLAs, dependency license whitelist, supply chain hygiene, common lint red lines (eval/dynamic execution), and the "frontend UI is not the final defense" principle. Web-specific XSS/CSRF/Storage red lines are in frontend/security-web.md.
   触发：`OWASP Top 10` · `CVE response` · `license whitelist` · `supply chain security`
 
 - **`zsk:testing-pyramid`** *[standard · optional]*
-  Use when designing test strategy or writing tests in any language — the test pyramid ratio (unit 70 / integration 20 / e2e 10), AAA/GWT structure, coverage targets, and the three hard principles (evidence before assertion, Red-Green-Refactor, bug confidence questioning). Stack-specific tooling (Jest/RTL/MSW/Playwright) is in frontend/testing-web.md.
+  Cross-language test strategy & discipline — test pyramid ratio (unit 70 / integration 20 / e2e 10), AAA/GWT structure, coverage targets, and the three hard principles (evidence before assertion, Red-Green-Refactor, bug confidence questioning). Stack-specific tooling (Jest/RTL/MSW/Playwright) is in frontend/testing-web.md.
   触发：`test pyramid` · `TDD discipline` · `test coverage target` · `AAA GWT structure`
 
-### `design-handoff/` — Design Handoff · 设计交付方法论（2）
+### `design-handoff/` — Design Handoff · 设计交付方法论 (2)
 
 - **`zsk:figma-to-code`** *[optional]*
-  Use when reading a Figma design node via MCP and producing production-grade code — the 7-step workflow (locate → extract structure → extract annotations → naming conversion → layout decoding → states → tokens), plus the 4-dimension "100% fidelity" verification (visual / interaction / semantic / responsive). CSS/BEM specifics live in zsk:css-bem.
+  Figma design node → production code via MCP — 7-step workflow (locate → extract structure → extract annotations → naming conversion → layout decoding → states → tokens), plus the 4-dimension "100% fidelity" verification (visual / interaction / semantic / responsive). Styling specifics live in zsk:styling-system.
   触发：`figma to code` · `100 percent fidelity` · `node naming conversion` · `design annotations`
 
 - **`zsk:ue-mcp`** *[optional]*
-  Use when the module has Figma/design input and you need to capture Design Source (URL/node-id), MCP readout status, module-specific UE deviations from system baselines, and implementation mapping. Produces docs/{module}/ue-mcp.md + structured description.md snapshot in design-assets. Only records deviations, not duplicated baseline rules.
+  Design Source capture & MCP readout for modules with Figma/design input — Design Source (URL/node-id), MCP readout status, module-specific UE deviations from system baselines, and implementation mapping. Produces docs/{module}/ue-mcp.md + structured description.md snapshot in design-assets. Only records deviations, not duplicated baseline rules.
   触发：`UE MCP context` · `figma snapshot` · `design source reference` · `module UE deviation`
 
-### `system/` — System · 工程宪法级资源（5）
+### `system/` — System · 工程宪法级资源 (5)
 
 - **`zsk:adr`** *[optional]*
-  Use when recording a cross-module, long-lived architectural decision that has alternatives worth weighing — with context, decision, rationale, alternatives considered, and consequences. Produces docs/system/adrs/ADR-NNNN-{slug}.md. Not for single-module implementation choices.
+  Cross-module long-lived architectural decision record — context, decision, rationale, alternatives considered, and consequences. Produces docs/system/adrs/ADR-NNNN-{slug}.md. Not for single-module implementation choices.
   触发：`architecture decision record` · `ADR template` · `MADR` · `cross-module decision`
 
 - **`zsk:architecture`** *[optional]*
-  Use when documenting the project's overall system architecture — C4 context diagram, tech stack baseline, module boundaries, routing, auth flow, data flow (request/state/contract), deployment topology, related ADRs. Frontend micro-frontend topology is an optional add-on section.
+  Project system architecture documentation — C4 context diagram, tech stack baseline, module boundaries, routing, auth flow, data flow (request/state/contract), deployment topology, related ADRs. Frontend micro-frontend topology is an optional add-on section.
   触发：`system architecture` · `C4 model` · `tech stack baseline` · `module boundaries`
 
 - **`zsk:glossary`** *[optional]*
-  Use when bootstrapping or maintaining the project's Ubiquitous Language — the single source for business terms, domain entities, state names, technical terms, and acronyms. Eliminates same-concept-different-names confusion across modules and backend contracts.
+  Project Ubiquitous Language maintenance — single source for business terms, domain entities, state names, technical terms, and acronyms. Eliminates same-concept-different-names confusion across modules and backend contracts.
   触发：`glossary` · `ubiquitous language` · `DDD terms` · `business term`
 
 - **`zsk:nfr-baseline`** *[optional]*
-  Use when establishing or inheriting the project's non-functional requirements baseline — the 7-category framework (performance / a11y / security / i18n / compatibility / observability / reliability) and the deviation-declaration discipline. Web-specific values (CWV thresholds, WCAG AA, browser matrix, 三语) live in frontend/nfr-web.md.
+  Project NFR baseline (inherited or established) — 7-category framework (performance / a11y / security / i18n / compatibility / observability / reliability) and the deviation-declaration discipline. Web-specific values (CWV thresholds, WCAG AA, browser matrix, 三语) live in frontend/nfr-web.md.
   触发：`NFR baseline` · `non functional requirements` · `quality attributes` · `ISO 25010`
 
 - **`zsk:project-constraints-template`** *[optional]*
-  Use when bootstrapping a new project to capture import origins, forbidden libraries/patterns, required wrappers, naming conventions, quality gates, branch/release conventions in one SYSTEM-SPEC chapter. The project-side constitutional constraint table, complementary to project-config.yaml (mechanical values).
+  Project constraints template for new-project bootstrap — captures import origins, forbidden libraries/patterns, required wrappers, naming conventions, quality gates, branch/release conventions in one SYSTEM-SPEC chapter. The project-side constitutional constraint table, complementary to project-config.yaml (mechanical values).
   触发：`project constraints` · `SYSTEM-SPEC` · `import origins` · `forbidden packages`
 
-### `meta/` — Meta · 元信息（1）
+### `meta/` — Meta · 元信息 (1)
 
 - **`zsk:philosophy`** *[meta · optional]*
-  Use when you need to understand the design rationale of the zsk skill set (LLM Wiki × Superpowers × GSD × project-adaptation synthesis), or when explaining why zsk is organized the way it is to a new contributor.
+  Design rationale of the zsk skill set — LLM Wiki × Superpowers × GSD × project-adaptation synthesis. For contributors needing to understand why zsk is organized the way it is.
   触发：`zsk philosophy` · `why is zsk organized this way` · `design rationale` · `LLM wiki vs superpowers`
+

package/bundles.yaml

@@ -45,7 +45,7 @@ bundles:
       - zsk:react-components
       - zsk:react-naming
       - zsk:typescript
-      - zsk:css-bem
+      - zsk:styling-system
       - zsk:i18n
       - zsk:a11y-web
       - zsk:performance-web
@@ -82,7 +82,7 @@ bundles:
       - zsk:react-components
       - zsk:react-naming
       - zsk:typescript
-      - zsk:css-bem
+      - zsk:styling-system
       - zsk:i18n
       - zsk:a11y-web
       - zsk:performance-web

package/design-handoff/figma-to-code/SKILL.md

@@ -3,14 +3,14 @@ name: zsk:figma-to-code
 description: Figma design node → production code via MCP — 7-step workflow
   (locate → extract structure → extract annotations → naming conversion → layout
   decoding → states → tokens), plus the 4-dimension "100% fidelity" verification
-  (visual / interaction / semantic / responsive). CSS/BEM specifics live in
-  zsk:css-bem.
+  (visual / interaction / semantic / responsive). Styling specifics live in
+  zsk:styling-system.
 category: resource
 domain: design-handoff
 tier: optional
 related:
   - ../ue-mcp/SKILL.md
-  - ../../frontend/css-bem/SKILL.md
+  - ../../frontend/styling-system/SKILL.md
   - ../../frontend/a11y-web/SKILL.md
   - ../../frontend/react-components/SKILL.md
 triggers:
@@ -26,7 +26,7 @@ triggers:
 
 > **目标**：以最少的主观猜测、最高的还原度，从 Figma 设计稿产出生产级代码
 > **适用**：有视觉 / 交互设计输入的模块
-> **CSS 实现细节**：BEM / Less 嵌套 / token 引用见 [`frontend/css-bem`](../../frontend/css-bem/SKILL.md)（本文件只讲方法论）
+> **样式实现细节**：命名、Less 嵌套、token 与断点纪律见 [`frontend/styling-system`](../../frontend/styling-system/SKILL.md)（本文件只讲方法论）
 
 ## 核心挑战
 
@@ -112,7 +112,7 @@ Figma 原名往往不规范，必须转换为 **语义化 + 可搜索 + 与代
 #### 命名转换原则
 
 1. **语义化，不视觉化**（✅ `.feature-tree__node` / ❌ `.blue-box`）
-2. **BEM 约定**（Block / Element / Modifier — 默认推荐，详见 [`frontend/css-bem`](../../frontend/css-bem/SKILL.md)）
+2. **样式命名约定**（BEM 为默认推荐，详见 [`frontend/styling-system`](../../frontend/styling-system/SKILL.md)）
 3. **与组件命名对齐**（组件 `FeatureTree` → Block class `.feature-tree`）
 4. **稳定且可搜索**（Figma 改名不影响代码；跨文件 grep 能定位）
 5. **识别语义的依据**：位置 / 结构、Variants / States、内容、命名暗示
@@ -233,7 +233,7 @@ Figma Variants → 组件状态：
 - [ ] `{{config.paths.design_assets}}/{module}/{snapshot}/description.md`
 - [ ] `screenshot-*.png`（每状态一张）
 - [ ] `docs/{module}/ue-mcp.md`（引用 description.md）
-- [ ] 组件代码 + 样式（遵循 [`frontend/css-bem`](../../frontend/css-bem/SKILL.md)）
+- [ ] 组件代码 + 样式（遵循 [`frontend/styling-system`](../../frontend/styling-system/SKILL.md)）
 - [ ] i18n 三语文案（若适用，含批注中文案）
 - [ ] 单元测试（覆盖状态矩阵每一项）
 - [ ] **批注落实追踪**
@@ -259,7 +259,7 @@ Figma Variants → 组件状态：
 - [ ] 状态矩阵含 diff + 截图 + a11y 属性
 - [ ] **设计批注表完整**（含类别 / 责任 / 已落实列）
 - [ ] **批注已全部落实或关联 tasks.md**
-- [ ] BEM 命名一致（见 `frontend/css-bem`）
+- [ ] 样式命名一致（见 `frontend/styling-system`）
 - [ ] 布局用 flex / grid，绝对定位有理由
 - [ ] 四维度 100% 还原清单全绿
 - [ ] description.md 与代码交叉一致

package/frontend/nfr-web/SKILL.md

@@ -161,7 +161,7 @@ triggers:
 
 **浏览器矩阵**（默认基线）：Chrome / Edge / Safari / Firefox 桌面端最近 2 个大版本；iOS Safari / Android Chrome 最近 2 个大版本；**IE 11 不支持**。在 `package.json` 配 `browserslist` 对齐（`last 2 <browser> versions` + `not dead`）。
 
-**响应式断点**（引自 token，详见 [`css-bem`](../css-bem/SKILL.md) 第 7 节）：
+**响应式断点**（引自 token，详见 [`styling-system`](../styling-system/SKILL.md) 第 7 节）：
 
 | 断点 | ≤ px | 说明 |
 | --- | ---: | --- |

package/frontend/review-frontend/SKILL.md

@@ -112,7 +112,7 @@ triggers:
 
 ### 代码风格（前端）
 - [ ] 命名符合 [`frontend/react-naming`](../react-naming/SKILL.md)
-- [ ] CSS 遵循 [`frontend/css-bem`](../css-bem/SKILL.md)（BEM / 无 `!important` / 无深度嵌套）
+- [ ] 样式遵循 [`frontend/styling-system`](../styling-system/SKILL.md)（命名稳定 / 无 `!important` / 无深度嵌套）
 - [ ] 无过度注释 WHAT（见 [`quality/code-hygiene`](../../quality/code-hygiene/SKILL.md)）
 - [ ] 没有未被调用的新抽象（YAGNI）
 

package/frontend/{css-bem → styling-system}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: zsk:css-bem
-description: Frontend CSS / Less / Sass / CSS Modules / Tailwind discipline —
-  scheme detection, BEM naming (Block__Element--Modifier), nesting depth (≤3
-  layers), token usage rules (no hardcoded color/spacing), scope isolation,
-  responsive breakpoints, and !important prohibition.
+name: zsk:styling-system
+description: Frontend styling system discipline — scheme detection, naming
+  conventions, nesting depth (≤3 layers), token usage rules (no hardcoded
+  color/spacing), scope isolation, responsive breakpoints, and !important
+  prohibition across Less / Sass / CSS Modules / Tailwind / CSS-in-JS.
 category: standard
 domain: frontend
 tier: optional
@@ -20,7 +20,7 @@ triggers:
   - responsive breakpoints
 ---
 
-# CSS / BEM · 样式纪律
+# Styling System · 样式体系纪律
 
 > **范围**：CSS / Less / Sass / CSS Modules / Tailwind / CSS-in-JS 场景下的样式纪律
 > **前置**：**写样式前必须先检测项目 CSS 方案**，严格跟随，不混用
@@ -50,9 +50,9 @@ triggers:
 - ❌ CSS Modules 项目里手写全局 class（除非显式 `:global()`）
 - ❌ 同文件混用 CSS-in-JS 与外部样式表
 
-## 2. BEM 命名（Block · Element · Modifier）
+## 2. 命名与结构纪律（默认示例：BEM）
 
-### 结构
+### 默认结构
 
 ```
 .block                { ... }   // 块
@@ -67,6 +67,12 @@ triggers:
 - 不嵌套 Element（`block__el1__el2` 是错误 — 改为 `block__el2` 或重新设计 block）
 - Modifier 表达状态 / 变体（`--primary`、`--is-active`、`--size-large`）
 
+### 说明
+
+- **BEM 不是唯一合法方案**，但在 Less / Sass / 全局样式表场景下仍然是默认推荐
+- 如果项目已明确采用 CSS Modules、Tailwind、CSS-in-JS 或 Vanilla Extract，就遵循宿主方案的命名与组织方式，不强行套一层 BEM
+- 本 skill 关心的是**命名稳定、作用域清晰、层级可控**，不是要求所有项目都写成同一种 class 语法
+
 ### 示例
 
 ```html

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@captain_z/zsk-skills",
-  "version": "0.1.0",
+  "version": "1.0.0",
   "description": "ZNorth Standard Kit — skill content package (SDLC + frontend + quality + design-handoff + system + meta)",
   "license": "MIT",
   "files": [