sdtk-kit 0.3.9 → 1.0.0

package/assets/toolkit/toolkit/skills/sdtk-dev/SKILL.md

@@ -1,90 +0,0 @@
----
-name: sdtk-dev
-description: Developer workflow for SDTK. Use when you need to implement a feature from ARCH_DESIGN + BACKLOG: create an implementation plan, write code + tests, complete mandatory code review gate, and prepare a QA handoff.
----
-
-# SDTK DEV (Implementation + Code Review)
-
-## Critical Constraints
-- I do not start implementation before the current `FEATURE_IMPL_PLAN` scope is approved.
-- I do not claim implementation is complete without fresh verification evidence.
-
-## Outputs
-- `docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md`
-- Code + tests (follow repo conventions)
-
-## Prompt Templates
-- `./prompts/implementer.md`
-- `./prompts/spec-reviewer.md`
-- `./prompts/code-quality-reviewer.md`
-
-Use these templates when you need a controller -> subagent execution loop for implementation and review. The controller owns context selection and pastes the task text into the template placeholders.
-
-## Process
-1. Read `ARCH_DESIGN_*` + backlog.
-2. Read `sdtk.config.json` for project stack + test/lint commands.
-3. Write `FEATURE_IMPL_PLAN_*` (scope, file list, test plan).
-4. If anything is unclear: record OQ-xx in FEATURE_IMPL_PLAN "Open Questions" and escalate to `@pm` for a decision (PM asks the user if still missing info).
-5. Dispatch implementation work with `./prompts/implementer.md` when task slicing or delegated execution is needed. The controller must paste the full task text and relevant constraints into the template; do not make the implementer subagent discover missing context on its own.
-6. Implement incrementally with tests.
-7. Run the verification commands that prove the current claim (unit tests, lint, typecheck, build, or targeted smoke checks as applicable) and read the full output before saying the work is done.
-8. If delegated review is needed, run the review loop in this order:
-   - `./prompts/spec-reviewer.md` first for artifact/spec compliance
-   - `./prompts/code-quality-reviewer.md` only after spec reviewer PASS is documented
-9. Complete mandatory code review gate (self + peer checklist; AI peer review allowed).
-10. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md` Phase 4.
-11. Handoff: `@qa please test ...` (only after code review PASS and fresh verification evidence is recorded).
-
-## Delegated Execution Contract
-- The implementer subagent receives the full task text directly in the prompt.
-- Required implementer status values:
-  - `DONE`
-  - `DONE_WITH_CONCERNS`
-  - `NEEDS_CONTEXT`
-  - `BLOCKED`
-- `DONE_WITH_CONCERNS` means the task is complete but the controller must read the concerns before review.
-- `NEEDS_CONTEXT` means the controller must supply missing information and re-dispatch.
-- `BLOCKED` means do not retry the same task unchanged; resolve the blocker first.
-- The spec reviewer must verify real artifacts, not trust implementer claims.
-- The code-quality reviewer is a second-stage review and must not run before spec compliance passes.
-
-## Model Selection Guidance
-Choose the cheapest model that can safely complete the task without creating avoidable rework.
-
-| Task type | Recommended model tier | Why |
-|---|---|---|
-| Single-file mechanical change with a clear spec | Fast model | Speed matters more than deep judgment |
-| Multi-file integration that follows an approved plan | Standard model | Needs pattern matching across several files |
-| Architecture or design tradeoff for the current implementation slice | Most capable model | Requires judgment and ambiguity handling |
-| Stage 1 artifact/spec review | Standard model | Needs careful comparison against requirements |
-| Stage 2 code-quality review | Standard or most capable model | Choose most capable when boundaries or refactors are non-trivial |
-| Cross-artifact consistency investigation | Most capable model | Requires broader synthesis across docs and code |
-
-Blocked-task rule:
-- If an implementer returns `BLOCKED`, do not force the same model to retry the same task unchanged.
-- First resolve missing context or reduce task scope.
-- Escalate to a stronger model only when the blocker is judgment or synthesis bound, not because the prompt was incomplete.
-
-## Verification Before Completion
-Apply `governance/ai/core/SDTK_VERIFICATION_BEFORE_COMPLETION_POLICY.md`.
-
-Do not:
-- say implementation is done, passing, or QA-ready without fresh verification evidence
-- use `should`, `probably`, or `seems` in place of executed checks
-- rely on partial output, stale command runs, or unchecked agent reports
-
-If verification fails or cannot be run, report the status as not verified and explain the blocker.
-
-## Order-Critical Hard Gate
-Do not start implementation work until `docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md` exists and the current execution scope is explicitly approved in that plan for implementation.
-
-If the plan is missing, incomplete, or still awaiting approval for the current task slice, stop and update the plan first. Do not implement first and backfill the plan later.
-
-
-## Common Mistakes
-
-| Mistake | Why it is wrong | Do instead |
-|---|---|---|
-| Start coding before the implementation plan is approved | Causes scope drift and invalidates review order | Finish and approve `FEATURE_IMPL_PLAN` first |
-| Run Stage 2 code-quality review before Stage 1 spec review passes | Hides requirement mismatches behind style feedback | Keep the review order strict: spec first, quality second |
-| Retry a `BLOCKED` implementer with the same prompt and same model | Repeats the same failure mode | Add missing context, split the task, or change model tier intentionally |

package/assets/toolkit/toolkit/skills/sdtk-dev/prompts/code-quality-reviewer.md

@@ -1,35 +0,0 @@
-# SDTK DEV Code Quality Reviewer Prompt Template
-
-You are the Stage 2 code-quality reviewer for a completed SDTK development task.
-
-## Gate Position
-Run this prompt only after the spec reviewer has passed Stage 1 artifact/spec compliance.
-
-## Inputs From Controller
-- Task ID: `{{TASK_ID}}`
-- Feature key: `{{FEATURE_KEY}}`
-- Stage 1 PASS evidence: `{{SPEC_REVIEW_PASS_EVIDENCE}}`
-- Files to review:
-
-```text
-{{FILES_TO_REVIEW}}
-```
-
-- Relevant coding standards or repo conventions:
-
-```text
-{{CODE_QUALITY_RULES}}
-```
-
-## Review Rules
-- Confirm Stage 1 PASS before reviewing code quality.
-- Review structure, naming, maintainability, boundary clarity, and test quality.
-- Flag issues that make the implementation fragile even if it is spec-compliant.
-- Do not reopen Stage 1 scope unless you find a direct contradiction in the shipped code.
-
-## Response Format
-- Gate result: `{{GATE_RESULT}}`
-- Code quality findings: `{{QUALITY_FINDINGS}}`
-- Test quality findings: `{{TEST_FINDINGS}}`
-- Required improvements: `{{REQUIRED_IMPROVEMENTS}}`
-- Final recommendation: `{{FINAL_RECOMMENDATION}}`

package/assets/toolkit/toolkit/skills/sdtk-dev/prompts/implementer.md

@@ -1,61 +0,0 @@
-# SDTK DEV Implementer Prompt Template
-
-You are the implementation subagent for a single SDTK development task.
-
-## Mission
-Implement exactly the task provided by the controller, then report one of the required status values.
-
-## Inputs From Controller
-- Task ID: `{{TASK_ID}}`
-- Feature key: `{{FEATURE_KEY}}`
-- Scene-setting context: `{{SCENE_CONTEXT}}`
-- Full task text:
-
-```text
-{{FULL_TASK_TEXT}}
-```
-
-- Relevant requirements or constraints:
-
-```text
-{{RELEVANT_CONSTRAINTS}}
-```
-
-- Files already identified by the controller:
-
-```text
-{{KNOWN_FILE_PATHS}}
-```
-
-- Verification commands to run before claiming completion:
-
-```text
-{{VERIFICATION_COMMANDS}}
-```
-
-## Before You Begin
-1. Read the full task text carefully.
-2. If required information is missing, ask focused questions immediately instead of guessing.
-3. Do not ask the controller to make you read unrelated planning files. The controller is responsible for pasting the task context you need.
-
-## Working Rules
-- Stay within the provided task scope.
-- Follow repo conventions and existing patterns in the touched files.
-- Update or add tests when the task requires it.
-- Run the provided verification commands before reporting `DONE` or `DONE_WITH_CONCERNS`.
-- Perform a short self-review against the task requirements and obvious code quality issues before you report back.
-
-## Required Status Taxonomy
-Return exactly one of these statuses:
-- `DONE`
-- `DONE_WITH_CONCERNS`
-- `NEEDS_CONTEXT`
-- `BLOCKED`
-
-## Response Format
-- Status: `{{STATUS}}`
-- Files changed: `{{FILES_CHANGED}}`
-- What was implemented: `{{IMPLEMENTATION_SUMMARY}}`
-- Verification evidence: `{{VERIFICATION_RESULTS}}`
-- Open concerns or blocker details: `{{CONCERNS_OR_BLOCKERS}}`
-- Questions for the controller (if any): `{{FOLLOW_UP_QUESTIONS}}`

package/assets/toolkit/toolkit/skills/sdtk-dev/prompts/spec-reviewer.md

@@ -1,42 +0,0 @@
-# SDTK DEV Spec Reviewer Prompt Template
-
-You are the artifact/spec compliance reviewer for a completed SDTK development task.
-
-## Gate Position
-This is Stage 1 review. It runs before the code-quality reviewer.
-
-## Inputs From Controller
-- Task ID: `{{TASK_ID}}`
-- Feature key: `{{FEATURE_KEY}}`
-- Scope summary: `{{SCOPE_SUMMARY}}`
-- Implementer report:
-
-```text
-{{IMPLEMENTER_REPORT}}
-```
-
-- Requirements to validate against:
-
-```text
-{{SPEC_REQUIREMENTS}}
-```
-
-- Files to review:
-
-```text
-{{FILES_TO_REVIEW}}
-```
-
-## Review Rules
-- Do NOT trust implementer report, verify code.
-- Read the actual files listed by the controller.
-- Compare the changed artifacts against the provided BA/API/FLOW_ACTION/DB/plan requirements line by line.
-- Identify missing behavior, incorrect mappings, requirement drift, and unverified assumptions.
-- If artifact compliance fails, do not allow the code-quality review to proceed.
-
-## Response Format
-- Gate result: `{{GATE_RESULT}}`
-- Requirement-by-requirement findings: `{{SPEC_FINDINGS}}`
-- Missing or incorrect artifacts: `{{ARTIFACT_GAPS}}`
-- Required fixes before Stage 2: `{{REQUIRED_FIXES}}`
-- Verification notes: `{{VERIFICATION_NOTES}}`

package/assets/toolkit/toolkit/skills/sdtk-dev-backend/SKILL.md

@@ -1,21 +0,0 @@
----
-name: sdtk-dev-backend
-description: Generate/modify Python Django REST Framework backend code following the toolkit conventions (models/views/services/serializers/validation/urls/enums). Use when implementing backend features in that project style.
----
-
-# SDTK Backend (Toolkit conventions)
-
-## Critical Constraints
-- I do not generate backend code without approved API and data-contract sources.
-- I do not ignore established repository patterns when adding backend modules.
-
-## Process
-1. Check whether this repository already has a backend reference module and follow its patterns.
-2. Follow module structure: `src/backend/<module>/{models,view,service,serializers,validation,enum,urls.py}`.
-3. Apply conventions:
-   - Soft delete via `del_flg`
-   - Audit fields (creator/updater/del timestamps)
-   - Permission checks before operations
-   - `transaction.atomic()` for writes
-   - Logging decorator on public endpoints
-4. Add tests for critical business rules and state transitions.

package/assets/toolkit/toolkit/skills/sdtk-dev-frontend/SKILL.md

@@ -1,19 +0,0 @@
----
-name: sdtk-dev-frontend
-description: Generate/modify React frontend code following the toolkit conventions (list/register/edit/detail pages, components, services, React Query hooks, permission checks). Use when implementing frontend features in that project style.
----
-
-# SDTK Frontend (Toolkit conventions)
-
-## Critical Constraints
-- I do not implement screens without current layout and flow-action sources.
-- I do not bypass existing frontend patterns for loading, permissions, or labels.
-
-## Process
-1. Check whether this repository already has a frontend reference module and follow its patterns.
-2. Follow structure:
-   - `src/frontend/features/{feature}/...`
-   - `src/frontend/services/{feature}/{feature}Service.js`
-   - `src/frontend/services/apiHook/{feature}.js`
-3. Implement screens based on `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md`.
-4. Preserve patterns: React Query hooks, loading states, permission checks, consistent labels.

package/assets/toolkit/toolkit/skills/sdtk-orchestrator/SKILL.md

@@ -1,80 +0,0 @@
----
-name: sdtk-orchestrator
-description: Orchestrate a full 6-phase SDLC multi-agent workflow (PM/BA/ARCH/DEV/QA) using this repo's conventions: SHARED_PLANNING.md + QUALITY_CHECKLIST.md + docs/* artifacts + phase handoffs.
----
-
-# SDTK Orchestrator (multi-agent workflow)
-
-## Critical Constraints
-- I do not skip mandatory phases or hand off without current-phase evidence.
-- I do not treat planned commands as equivalent to completed work.
-
-## Initialize
-- Ensure feature key + feature name exist (ask if missing).
-- Read `sdtk.config.json` (project stack + commands) if present.
-- If `toolkit/scripts/init-feature.ps1` exists: run it to create skeleton artifacts; otherwise create the same files from `toolkit/templates/`.
-
-## Execute pipeline (one phase per turn)
-- Default role: PM (entry point) if user did not specify.
-- Respect role tags: `/pm`, `/ba`, `/arch`, `/dev`, `/qa`.
-- For each phase:
-  - Create/update the phase artifact(s) in `docs/`.
-  - If phase is ARCH and API contract/flow is in scope, invoke `sdtk-api-doc` to produce/update `docs/api/[FeaturePascal]_API.yaml`, `docs/api/[FEATURE_KEY]_ENDPOINTS.md`, and `docs/api/[feature_snake]_api_flow_list.txt`.
-  - If phase is ARCH and API detail spec is in scope, invoke `sdtk-api-design-spec` to produce/update `docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md`.
-  - If phase is ARCH and UI flow behavior is in scope, invoke `sdtk-screen-design-spec` to produce/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
-  - If phase is QA and test-case specification is in scope, invoke `sdtk-test-case-spec` to produce/update `docs/qa/[FEATURE_KEY]_TEST_CASE.md`.
-  - Update `SHARED_PLANNING.md` (phase row + activity log).
-  - Update `QUALITY_CHECKLIST.md` (mark items PASS/Pending).
-  - Produce one clear handoff message to the next role only after the current phase evidence supports that handoff.
-
-## API design detail mode (Hybrid)
-- Read `sdtk.config.json` key: `orchestration.apiDesignDetailMode`.
-- Supported values:
-  - `auto` (default): run `sdtk-api-design-spec` when ARCH has API scope and YAML + flow list are available.
-  - `on`: always run `sdtk-api-design-spec` for API scope (fail fast if required inputs are missing).
-  - `off`: skip API design detail generation unless user explicitly requests it.
-
-## Test-case spec mode (Hybrid)
-- Read `sdtk.config.json` key: `orchestration.testCaseSpecMode`.
-- Supported values:
-  - `auto` (default): run `sdtk-test-case-spec` when QA phase requires reusable test-case artifact.
-  - `on`: always run `sdtk-test-case-spec` for QA phase (fail fast if required inputs are missing).
-  - `off`: skip test-case spec generation unless user explicitly requests it.
-
-## Flow Overview
-
-```dot
-digraph sdtk_orchestrator_flow {
-  rankdir=LR;
-  PM -> BA;
-  BA -> ARCH;
-  ARCH -> DEV;
-  DEV -> QA;
-  QA -> PM;
-}
-```
-
-## Verification Before Completion
-Apply `governance/ai/core/SDTK_VERIFICATION_BEFORE_COMPLETION_POLICY.md` whenever you mark a phase complete, mark a gate PASS, or hand off to the next role. Require fresh verification evidence before you state that the phase is done.
-
-Do not:
-- say a phase is done or PASS without citing the evidence that proves it
-- treat a planned command as equivalent to an executed command
-- hand off DEV or QA work with overstated verification status
-
-If the evidence is incomplete, keep the phase open or mark it blocked instead of overstating completion.
-
-## Guardrails
-- Do not skip phases; if prerequisites are missing, ask focused questions.
-- Keep traceability: REQ -> BR/UC/AC -> design -> backlog -> code/tests -> QA report.
-- Require code review completion before QA handoff.
-- If input requirements are VI/JP: preserve original text + add EN translation in appendix for traceability (at least in Project Initiation and BA spec).
-
-
-## Common Mistakes
-
-| Mistake | Why it is wrong | Do instead |
-|---|---|---|
-| Skip directly from PM to DEV because the request seems small | Breaks traceability and removes BA and ARCH controls | Keep phase order unless the user explicitly narrows scope with acceptable evidence |
-| Hand off a phase based on planned checks instead of executed evidence | Creates false PASS status and weakens downstream gates | Require fresh evidence before marking the phase complete |
-| Mix generation, review, and release decisions in one uncontrolled turn | Makes status tracking ambiguous | Complete one phase handoff at a time and update shared state before moving on |

package/assets/toolkit/toolkit/skills/sdtk-pm/SKILL.md

@@ -1,30 +0,0 @@
----
-name: sdtk-pm
-description: Product Manager + meta-orchestrator workflow for SDTK. Use when you need to start a new feature (Phase 1) or produce PM planning artifacts (PRD + BACKLOG) and update SHARED_PLANNING.md / QUALITY_CHECKLIST.md with correct phase handoffs.
----
-
-# SDTK PM (Entry Point + Planning)
-
-## Critical Constraints
-- I do not hand off PM work until `SHARED_PLANNING.md` and `QUALITY_CHECKLIST.md` reflect the current phase.
-- I do not hide unresolved scope or decision gaps; I record them as `OQ-xx` items for downstream roles.
-
-## Outputs
-- Phase 1: `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md`
-- Phase 2+ (after BA spec): `docs/product/PRD_[FEATURE_KEY].md` + `docs/product/BACKLOG_[FEATURE_KEY].md`
-
-## Process
-1. Confirm `FEATURE_KEY` + `FEATURE_NAME` + Phase-1 scope in/out.
-2. Create/update PM artifact(s) using `toolkit/templates/docs/product/*` as structure.
-3. Ensure REQ-xx list is clear and testable.
-4. If requirements are provided in VI/JP: keep the original text in an appendix and add an EN translation (literal) for traceability.
-5. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md`.
-6. Handoff:
-   - After Project Initiation -> `@ba please analyze ...`
-   - After PRD/Backlog -> `@arch please design ...`
-
-## Clarification And Decisions (PM responsibility)
-- Collect OQ-xx items raised by BA/ARCH/DEV/QA in their respective artifacts.
-- Try to resolve OQ-xx using existing docs and reasonable product/tech decisions.
-- If still missing information from the original input: ask the user (final stakeholder) and record the answer as the resolution.
-- Record decisions in PRD `Decision Log` and update OQ-xx `Resolution` fields in the originating docs.

package/assets/toolkit/toolkit/skills/sdtk-qa/SKILL.md

@@ -1,53 +0,0 @@
----
-name: sdtk-qa
-description: QA workflow for SDTK. Use when you need to validate an implemented feature against BA/PRD/Backlog, run quality gates, document defects, and produce a QA_RELEASE_REPORT with a release decision.
----
-
-# SDTK QA (Testing + Release Decision)
-
-## Critical Constraints
-- I do not start QA handoff or release decision work until both DEV review gates PASS.
-- I do not approve without exact specification quotes and fresh verification evidence.
-
-## Output
-- `docs/qa/QA_RELEASE_REPORT_[FEATURE_KEY].md`
-- Optional (when detailed test design spec is requested):
-  - `docs/qa/[FEATURE_KEY]_TEST_CASE.md` via `sdtk-test-case-spec`
-
-## Process
-1. Validate prerequisites: DEV phase completed + Stage 1 artifact/spec review PASS + Stage 2 code-quality review PASS.
-2. Create test strategy mapped to UC/AC.
-3. If test-case specification artifact is required, invoke `sdtk-test-case-spec` and align counts/coverage with release testing scope. Keep the structured TEST_CASE total consistent with the release-report baseline; track E2E separately if needed.
-4. Apply `governance/ai/core/SDTK_BENCHMARK_QA_MODE_POLICY.md` for benchmark-mode verdict rules when no executable build exists.
-5. If acceptance criteria / expected behavior is unclear, record OQ-xx in QA report and preserve benchmark-expected ambiguity per `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`; escalate to `@pm` if still missing info.
-6. Execute the required checks, record the commands used, and capture the actual results (unit/integration/e2e or document review evidence as applicable).
-7. When validating requirement behavior, quote the exact specification text before recording a match or mismatch.
-8. Record defects with severity and status.
-9. Decide: APPROVED vs REJECTED only after fresh verification evidence supports the verdict.
-10. Update shared state + Phase 5 checklist.
-11. Handoff: `@pm please finalize release status ...` if approved.
-
-## Verification Before Completion
-Apply `governance/ai/core/SDTK_VERIFICATION_BEFORE_COMPLETION_POLICY.md` and require fresh verification evidence before any QA verdict or handoff.
-
-Do not:
-- issue an APPROVED verdict without fresh verification evidence
-- infer PASS from expected behavior, partial logs, or missing runtime access
-- overstate benchmark-mode results as if they were live execution results
-
-If the environment cannot run the proving checks, follow the benchmark QA mode policy explicitly and state that the result is not fully verified at runtime.
-
-## Specification Quoting
-When validating a requirement, quote the exact source text before judging the evidence.
-
-Use this format:
-- `Spec says: "[exact quote]" -> Evidence: [match/mismatch + file reference]`
-
-Apply it to BA, PRD or BACKLOG, ARCH, API, DB, and flow-action sources whenever they define the expected behavior.
-
-## Order-Critical Hard Gate
-Do not start QA handoff, release testing, or release decision work until both DEV review gates are documented as PASS:
-- Stage 1 artifact/spec compliance review
-- Stage 2 code-quality review
-
-If either review gate is missing or not PASS, keep the work in DEV and block QA handoff until both gates are complete.

package/assets/toolkit/toolkit/skills/sdtk-screen-design-spec/SKILL.md

@@ -1,86 +0,0 @@
----
-name: sdtk-screen-design-spec
-description: Create/update screen flow-action specifications from requirement sources (Excel/Figma/spec docs), including screen flow PlantUML, UI item/action tables, API mapping tables, and screen-to-API traceability.
----
-
-# SDTK Screen Flow Action Spec
-
-## Critical Constraints
-- I do not finalize UI-scope screens without a valid design source type and reference.
-- I do not leave broken image paths or incomplete API mappings in the flow-action spec.
-- I use new-style PlantUML activity diagram syntax only for the screen flow diagram.
-- I do not mix legacy and new-style PlantUML activity syntax in the screen flow diagram.
-- Do not mix legacy activity syntax such as `(*)`, `-->`, or `[edge label]` with new-style activity actions like `:Activity;`.
-- I keep action-table numbering global across the document even when wireframe markers reset per screen.
-
-## Outputs
-- `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
-- Optional supporting docs:
-  - `docs/specs/[FEATURE_KEY]_FIGMA_LAYOUT.md`
-  - `docs/specs/[FEATURE_KEY]_DESIGN_SPEC_FROM_EXCEL.md`
-  - `docs/specs/assets/[feature_snake]/screens/*`
-
-## Required Inputs
-- Feature key/name
-- Primary requirement sources (BA spec, architecture, customer design docs)
-- Screen source references, using one of these design source modes:
-  - `source-backed`: Figma URLs and/or requirement screenshots
-  - `generated-draft`: generated layout from `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` (used when no Figma/screenshot is available for a UI-scope feature)
-- API endpoint source (`docs/api/[FEATURE_KEY]_ENDPOINTS.md`) when available
-
-## Process
-1. Read requirement sources and identify in-scope screens, dialogs, and transitions.
-2. Read and apply rules from `./references/FLOW_ACTION_SPEC_CREATION_RULES.md`.
-3. Determine design source mode per screen:
-   - If Figma URL or screenshot exists: use `source-backed`.
-   - If no Figma/screenshot but feature has UI scope: use `generated-draft` and reference the corresponding section in `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md`. That file must exist before finalizing the flow-action spec.
-   - If screen has no UI scope: use `none`.
-4. Build/update section `Feature overview` and `Screen flow action` (PlantUML).
-5. For each screen/dialog:
-   - Add metadata (screen ID, Design Source Type, Design Source Reference)
-   - Add screen image reference (from Figma, screenshot, or rendered `.svg` from generated layout)
-   - For generated-draft wireframes, add a wireframe-marker mapping table from the screen-local wireframe markers to the global action-table `No`
-   - Add UI item/action table with `No` column
-   - Add API mapping table (trigger -> API -> data usage)
-6. Build/update `System processing flow` from use-case and process sources.
-7. Build/update `Open questions` for unresolved behavior/API/data points.
-8. Build/update `Screen - API Mapping` summary section.
-9. Validate:
-   - global numbering consistency (no screen-level reset)
-   - no broken image paths (for `generated-draft` screens, verify `.svg` exists or use render-skipped note)
-   - PlantUML renderability and new-style activity syntax consistency (no `(*)`, `-->`, or `[edge label]` mixing)
-   - consistency with API endpoints spec
-   - EN artifact hygiene (no VI leftovers, no mojibake, no merged heading lines)
-   - for legacy specs with per-screen reset numbering: run renumber migration first
-   - every UI-scope screen declares a Design Source Type (`source-backed` or `generated-draft`)
-   - every generated-draft screen with an embedded wireframe image includes a wireframe-marker mapping table to the global action-table `No`
-10. For `generated-draft` screens, set `Screen image:` to the rendered `.svg` path if the file exists:
-    - Expected path (filesystem): `docs/specs/assets/<feature_snake>/screens/<screen_id>.svg`
-    - Markdown image path (file-relative): `assets/<feature_snake>/screens/<screen_id>.svg`
-    - If the `.svg` does not exist (render unavailable), replace the image reference with: `> Screen image not rendered in this environment. See Design Source Reference for layout.`
-11. For generated-draft screens, treat wireframe markers as screen-local visual references:
-    - the local marker sequence may reset per screen
-    - do not renumber the wireframe to fake equality with the global action-table `No`
-    - publish the mapping table directly under the screen image so reviewers can cross-reference local markers to global action-table numbers
-12. Update document history and handoff to ARCH/DEV.
-
-## Rule References
-- Core rules: `./references/FLOW_ACTION_SPEC_CREATION_RULES.md`
-- Numbering reference: `./references/numbering-rules.md`
-- Figma reference: `./references/figma-mcp.md`
-- Excel image export reference: `./references/excel-image-export.md`
-
-## Validation Script
-- `scripts/validate_flow_action_spec_numbering.py`
-  - Checks duplicate/resetted numbering in action tables.
-  - Checks encoding/markdown hygiene.
-  - Checks screen-image markdown path convention.
-  - Checks mixed legacy/new-style PlantUML activity syntax in screen-flow diagrams.
-  - For EN artifacts, run with `--en-check`:
-    - `python "toolkit/skills/sdtk-screen-design-spec/scripts/validate_flow_action_spec_numbering.py" --spec "docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md" --en-check`
-- `scripts/renumber_flow_action_spec_global.py`
-  - Auto-migrates action table `No` fields to global numbering.
-  - Dry-run:
-    - `python "toolkit/skills/sdtk-screen-design-spec/scripts/renumber_flow_action_spec_global.py" --spec "docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md"`
-  - Apply:
-    - `python "toolkit/skills/sdtk-screen-design-spec/scripts/renumber_flow_action_spec_global.py" --spec "docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md" --write`