一键导入
sdd-test
Generate and run check artifacts for a spec. Self-sufficient: MCP preflight, 2-agent generation, автоматически по всем Requirements, auto state transition.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Generate and run check artifacts for a spec. Self-sufficient: MCP preflight, 2-agent generation, автоматически по всем Requirements, auto state transition.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Реализовать задачи из tasks.md текущего change'а с встроенной L1/L2/L3 верификацией. Читает test-plan.md как контекст. Обновляет .sdd-state.yaml на каждом подшаге. Обновляет openspec/specs/index.yaml для новых capabilities (только при verify-ok).
Update dev: namespace to latest version from awesome-claude. Checks dependencies and updates them if needed.
Create a well-structured git commit following project conventions. Analyzes staged and unstaged changes, drafts a detailed commit message with What/Why/Details sections, and commits. Auto-detects task ID format from git history.
Bug fixer: traces root cause via /tracing (analysis only), then fixes via /tdd (test-first implementation). Combines incident analysis with TDD-driven repair. Use when: something is broken, a feature doesn't work, or a bug needs fixing.
Initialize a DDD monorepo with backend (FastAPI, SQLAlchemy, multi-BC architecture) and frontend (React 19, Vite, TypeScript) packages. Scaffolds full project structure: root orchestration (Makefile, docker-compose), backend with one bounded context (domain entity, repository, use case, infra repo, routes, schemas), frontend with API client, router, UI kit seed, and test infrastructure for both (pytest 6-type strategy, vitest, architecture tests). Ready to `make check` after generation.
TDD workflow: writes tests FIRST, runs them (red), writes implementation (green), refactors. Works as a senior QA automation engineer with 20 years of experience. Covers all test layers: unit, state, security, cases, integration, e2e, contract. Always follows critical path first, then corner cases. Use when implementing features, fixing bugs, or adding test coverage via TDD.
| name | sdd:test |
| description | Generate and run check artifacts for a spec. Self-sufficient: MCP preflight, 2-agent generation, автоматически по всем Requirements, auto state transition. |
| workflow_step | 5 |
Попытайся вызвать sdd_db_init (MCP tool).
Если инструмент недоступен:
Прочитай .mcp.json. Если sdd-scripts отсутствует → остановись:
✗ sdd-scripts не зарегистрирован в .mcp.json. Добавьте запись вручную и перезапустите.
Если sdd-scripts присутствует → запусти через Bash tool:
python3 "${CLAUDE_SKILL_DIR}/../scripts/enable_mcp.py"
added → остановись:
Конфигурация обновлена: sdd-scripts добавлен в enabledMcpjsonServers.
Перезапустите сессию Claude Code и повторите /sdd:test.
already-enabled → остановись:
MCP-сервер настроен, но не загружен. Перезапустите сессию Claude Code.
error: → остановись с текстом ошибки.Если инструмент доступен → перейди к шагу 0.5.
Спроси через AskUserQuestion:
Режим прогона:
- full — заново генерировать check-скрипты и запустить всё
- rerun — запустить существующие скрипты без регенерации
- show — показать текущее состояние БД без запуска
Определи <spec> из $ARGUMENTS или из контекста разговора.
Вызови sdd_db_run_start → получи run_id. Все дальнейшие sdd_db_step_* используют этот run_id.
sdd_db_step_start run_id 1
Прочитай <spec>/spec.md. Извлеки все Requirements и Scenarios.
Если spec.md содержит test_type: в Purpose-секции → sdd_db_set_spec_meta <spec> test_type <value>.
Зарегистрируй каждый Requirement через sdd_db_add <spec> <req_id> <run_id> → получи check_id.
Если у Requirement есть явный scope: → sdd_db_set_req_meta <spec> <req_id> scope <value>.
sdd_db_step_done run_id 1
sdd_db_step_start run_id 2
Для каждого Requirement прочитай check_id через sdd_db_read. Собери:
test_type спеки (из spec_meta)scope каждого Requirement (из checks)sdd_db_step_done run_id 2
sdd_db_step_start run_id 3
Если mode=full: спроси подтверждение через AskUserQuestion:
Удалить существующие check-скрипты и данные БД для
<spec>?
При согласии: sdd_db_delete_spec <spec>, удали файлы <spec>/scripts/check_*.py.
sdd_db_step_done run_id 3
sdd_db_step_start run_id 4
Вызови sdd_db_list_criteria → получи JSON список критериев.
Они передаются Агенту 1 на шаге 6.
sdd_db_step_done run_id 4
sdd_db_step_start run_id 5
Для каждого check: если script_path задан и файл существует → запусти через Bash tool.
Запиши результат через sdd_db_write_manual <check_id> passed|failed.
sdd_db_step_done run_id 5
sdd_db_step_start run_id 6
Для каждого Requirement параллельно:
Создай тест-кейс <spec>/cases/<req_slug>.md по шаблону из cases/test.md.
Запиши путь: sdd_db_write_script_path <check_id> <path>.
Агент 1 (анализ):
Входы:
spec.mdtest_type, scope)Задача: системный анализ (процесс → контекст → цель → failure mode), MVP без деталей.
Если test_type=imperative — включить precondition/operation/postcondition.
Если test_type=declarative — включить assertions по каждому полю/правилу.
Формат вывода — жёсткий YAML:
goal: <что этот requirement охраняет>
failure_mode: <что сломается если нарушен>
scenarios:
- id: <scenario-id>
description: <дословно из spec.md>
checks:
- what: <что проверить>
justification: <цитата из текста Requirement>
boundary: <граничный случай с обоснованием, если применимо>
После завершения: sdd_db_write_analysis_notes <check_id> <yaml> (ставит analysis_status=done).
Агент 2 (генерация):
Входы:
analysis_notes из БД (основной источник — sdd_db_read <check_id>)spec.md только для разрешения неоднозначностейПравило: реализовать ровно то, что в analysis_notes. Не добавлять проверки из spec.md.
Если противоречие analysis_notes vs spec.md → флагировать в stdout, не генерировать (сигнал перезапустить Агента 1).
Контракт скрипта (D22):
PASS или FAIL: <reason>Сохрани скрипт: <spec>/scripts/check_<req_slug>.py.
Запиши путь: sdd_db_write_script_path <check_id> <path>.
Ставит generation_status=done.
sdd_db_step_done run_id 6
После каждого Агента 2: sdd_db_list_gaps <check_id>.
Если непусто → вернись к Агенту 2 с запросом дописать проверки.
Максимум 2 итерации.
sdd_db_step_start run_id 7
Вызови sdd_db_start_semantic_eval <run_id> agent до запуска субагентов.
Без этого вызова sdd_db_step_done run_id 7 завершится ошибкой.
Для каждого Requirement запусти субагент-оценщик:
Входы субагента:
Задача субагента (Верификация — шаг 7):
Проверь что тест действительно проверяет то, что написано в требовании.
Оцени каждый критерий: passed/failed.
Запиши через sdd_db_add_criterion_result <check_id> <criterion_id> <passed> <notes>.
История накапливается — повторный вызов добавляет строку, не перезаписывает.
sdd_db_step_done run_id 7
sdd_db_step_start run_id 7.5
Если скилл вызван в контексте change'а (известен change_id):
Прочитай агрегат через sdd_db_report <spec>.
manual_result = passed → sdd_state_transition <change_id> verify-okmanual_result = failed → sdd_state_transition <change_id> verify-failedТолько Skill Flow выполняет этот transition. Generation и Evaluation — запрещено.
sdd_db_step_done run_id 7.5
sdd_db_step_start run_id 8
Вызови sdd_db_report <spec> → выведи таблицу:
| Requirement | Script | Manual | Semantic | Criteria |
|-------------|--------|--------|----------|----------|
| req-name | ✓ | passed | passed | 7/7 |
Итоговая строка: N/M passed.
Orphans из report → отдельная секция если непусто.
sdd_db_step_done run_id 8