القائمة
Parallel-agent project/feature kickoff — 4 agents design contracts, scaffold tests, review security, validate structure BEFORE any code is written. Prevents 80% of audit findings at the root.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | dev-start |
| description | Parallel-agent project/feature kickoff — 4 agents design contracts, scaffold tests, review security, validate structure BEFORE any code is written. Prevents 80% of audit findings at the root. |
/dev-start [feature description].80% проблем из аудитов = код написан без подготовки. Нет контрактов, нет тестов, нет security review. dev-start запускает 4 агента ПАРАЛЛЕЛЬНО до первой строки кода.
/dev-start [описание фичи] → полный kickoff (4 агента)/dev-start lite [описание] → быстрый (2 агента: contract + tests)Каждый агент ОБЯЗАН:
ds-contractПроект: [path], стек: [стек].
Фича: [описание].
Задача: спроектировать API контракт ДО реализации.
1. Определи ВСЕ types/interfaces которые нужны для фичи
2. Определи API boundaries — какие модули взаимодействуют
3. Проверь существующие типы — НЕ дублируй (SSOT):
- Grep по проекту: есть ли похожие типы?
- Если есть — переиспользуй, НЕ создавай новые
4. Определи data flow: откуда данные → куда → в каком формате
5. Для каждого join/merge — определи ключ (НЕ индекс массива!)
Output:
- Список types/interfaces с полями
- Data flow diagram (текстом)
- Список переиспользуемых типов (с путями)
- Предупреждения о потенциальных N+1 / data integrity issues
CODE_QUOTE существующих типов обязательна.
ds-testsПроект: [path], стек: [стек].
Фича: [описание].
Задача: написать скелет тестов ДО реализации (TDD).
1. Определи critical paths фичи
2. Для каждого path — напиши test case:
- Happy path
- Edge cases (null, empty, boundary values)
- Error cases (network fail, invalid input, timeout)
- Auth cases (unauthorized, wrong role)
3. Определи test framework проекта (jest/vitest/pytest/go test)
4. Создай файлы тестов с описательными `it()`/`test()` — тела пустые (TODO)
Output:
- Список test files с путями
- Содержимое каждого test file (skeleton)
- Какие mocks/fixtures нужны
НЕ пиши реализацию — только тесты.
ds-securityПроект: [path], стек: [стек].
Фича: [описание].
Задача: security review ДО написания кода.
1. Классифицируй фичу по risk level:
- HIGH: auth, payments, user data, crypto, file upload
- MEDIUM: API endpoints, forms, search, notifications
- LOW: UI-only, docs, formatting
2. Для HIGH/MEDIUM — чек-лист требований:
- [ ] Input validation — какие поля, какие constraints?
- [ ] Auth/authz — кто может вызывать? какие роли?
- [ ] Rate limiting — нужен? какой лимит?
- [ ] Data exposure — что НЕ должно попасть в response?
- [ ] Secrets — нужны ли новые ключи/токены? Где хранить?
- [ ] Crypto — если JWT/подписи: verify ОБЯЗАТЕЛЕН (НЕ decode)
- [ ] Pagination — max limit обязателен
3. Проверь существующие auth/security паттерны в проекте:
- Как другие endpoints делают auth?
- Есть ли middleware? Используется ли?
- Есть ли rate limiting? Работает ли? (grep по коду)
Output:
- Risk level фичи
- Security requirements checklist (заполненный)
- Паттерны из проекта которые НАДО переиспользовать
- Антипаттерны из проекта которые НЕ НАДО повторять
- CODE_QUOTE существующих security паттернов
ds-structureПроект: [path], стек: [стек].
Фича: [описание].
Задача: спланировать файловую структуру.
1. Определи какие файлы нужно создать / изменить
2. Для каждого файла — оценка LOC:
- Если >150 LOC predicted → split на 2+ файла СРАЗУ
- Если функция >25 LOC predicted → split на подфункции СРАЗУ
3. Проверь Constructor Pattern:
- 1 файл = 1 класс = 1 ответственность
- Types отдельно от реализации
- Нет ли существующих файлов >200 LOC которые фича усугубит
4. Проверь зависимости:
- Нужны ли новые пакеты?
- Есть ли уже установленные пакеты для этой задачи?
- Нет ли dead dependencies которые можно переиспользовать?
Output:
- File plan: [path] — [responsibility] — [estimated LOC]
- Files to modify: [path] — [current LOC] → [estimated LOC after]
- Constructor Pattern warnings
- Dependency recommendations
=== DEVELOPMENT BRIEF ===
Feature: [название]
Risk: HIGH/MEDIUM/LOW
## Contracts
[types/interfaces from ds-contract]
## Test Plan
[test files from ds-tests]
## Security Requirements
[checklist from ds-security]
## File Plan
[structure from ds-structure]
## Warnings
[potential issues caught before coding]
## Ready to code: YES/NO
[если NO — что нужно решить сначала]
Deep research on any topic using parallel agents, web search, and cross-referencing. Use when user asks to research, investigate, or deeply analyze a topic, technology, library, or concept. Triggers on keywords like "research", "investigate", "deep dive", "find out everything about". Supports `--angle` presets for common specializations (competitors, design-refs).
Gateway router for web animation work. Picks between /scroll-animation, /motion-design, or /ai-animation via one AskUserQuestion call, then hands off. Does NOT implement animation — the downstream skills remain the source of truth for their respective domains.
Use when running multi-skill pipelines — new-feature, marketing-launch, design-to-code, web-creation, full-audit, rag-setup workflows
Meta-orchestrator — converts a free-text task description into the right artefact(s) (agent, skill, hook, rule, or block) by composing existing KeiSeiKit primitives. Pure-click decision chain except the single intake field. Enriches `_blocks/` over time via Phase 6 block-augmentation — the kit gets smarter with every invocation.
Deprecated alias for /research with the design-refs angle preset. Routes to /research focused on design patterns, visual archetype references, and award-winning site teardowns.
Continuous parallel quality gate during development — 3 backend agents (security/perf/structure) check every significant code change in real-time. Run after writing code, before committing.