@bonesofspring/ai-rules 0.2.1 → 0.2.2

package/presets/claude/ios-swift/rules/ui-and-accessibility/viewmodels.md

@@ -0,0 +1,43 @@
+---
+description: ViewModels, состояние экрана и domain flow
+paths:
+  - "**/{Presentation,Domain}/**/*ViewModel*.swift"
+---
+
+# Общие принципы
+
+- ViewModel — **единственная точка** orchestration для экрана: load, submit, validation, navigation intents.
+- Хранить и отдавать во View **domain models** и UI-specific state (loading, error message, selected tab).
+- `@MainActor` на ViewModel; тяжёлую работу — в use case / repository (`async`), не блокировать main thread.
+- Unidirectional flow: View → intent → ViewModel → use case → state update → View.
+
+# State
+
+- Явный enum или struct для UI state где уместно:
+  - `idle`, `loading`, `loaded(Data)`, `failed(Error)` — или аналог из репо.
+- Избегать множества несинхронизированных `@Published` флагов, если один enum покрывает сценарий.
+- `@Observable` / `ObservableObject` — как в проекте; не смешивать стили в одной фиче без причины.
+
+# Use cases и repositories
+
+- ViewModel зависит от **протоколов** (`LoadOrdersUseCase`, `OrderRepository`), не от `*RepositoryImpl`.
+- Один use case — одна бизнес-операция; не раздувать ViewModel сотнями строк — выносить use cases в Domain.
+- Кэширование и offline — в repository/Data, не во ViewModel.
+
+# Side effects
+
+- Analytics, haptics, deep links — через injected services или middleware-паттерн, не hardcode синглтонов.
+- `Task` в ViewModel: отмена при `deinit` / `onDisappear` где нужно (`task(id:)`, хранение `Task?` с cancel).
+
+# Тестируемость
+
+- Инициализатор ViewModel принимает протоколы (DI); без скрытых singleton для сети/БД.
+- Бизнес-ветки покрывать unit-тестами с mock use cases.
+
+# Требование к агенту
+
+При создании ViewModel:
+- Не вызывать `URLSession` / API client напрямую.
+- Не парсить JSON и не объявлять DTO во ViewModel.
+- Именование: `FeatureViewModel`, методы — глаголы (`loadOrders()`, `submitOrder()`).
+- Следовать стилю существующих ViewModels в той же фиче.

package/presets/claude/next/CLAUDE.md

@@ -1,39 +1,11 @@
 # Next.js stack — project instructions
 
-Краткая точка входа для Claude Code. Подробные правила — модульные файлы под `rules/` (подпапки по темам).
+Краткая точка входа для Claude Code. Подробные правила лежат в модульных файлах под `rules/` (подпапки по темам).
 
-See @rules/README.md for the full catalog and loading strategy.
+See @rules/README.md for how this preset splits instructions.
 
 ## Conventions
 
-- **Одна тема на файл**; для больших областей — подпапки в `rules/<topic>/`.
-- **Session-start rules** — только базовые инварианты (`next-app-core`, lint, package manager, code-quality).
-- **Domain-specific rules** — YAML frontmatter `paths:` (подгружаются при работе с matching-файлами).
-- Slash-команды — в `commands/`; сценарии — в `skills/`; subagents — в `agents/`.
-
-## Quick start
-
-| Задача | Куда смотреть |
-|--------|----------------|
-| Любая новая work-задача | `commands/task.md` + `rules/tooling-and-review/agent-team-orchestrator.md` |
-| Новая фича end-to-end | skill `feature-delivery` + `rules/architecture/feature-delivery-workflow.md` |
-| Эталонные фичи | `rules/architecture/reference-features.md` (заполнить TBD в репо) |
-| Стек и слои | `rules/stack/next-app-core.md` |
-| App Router | `rules/stack/next-app-router.md` |
-| A11y при кодинге UI | `rules/ui-and-accessibility/react-a11y-coding.md` |
-| После правок кода | `rules/tooling-and-review/post-change-lint.md` |
-| Валидация перед review | agent `build-verifier` |
-| Code review MR | skill `code-review` + `rules/tooling-and-review/code-review-mr.md` |
-| Техническое ретро | `commands/technical-retro.md` + skill `technical-retro` |
-
-## Install
-
-```bash
-npx @bonesofspring/ai-rules init claude --preset next
-```
-
-Копирует `CLAUDE.md`, `rules/**`, `commands/**`, `agents/**`, `hooks/**`, `team/**`, `hooks.json`, `BUGBOT.md` и др. в `.claude/` целевого репозитория.
-
-## Pipeline routing
-
-Intent detection, profiles (`full` / `standard` / `light`), and default steps — **only** in `agents/task-router.md`. Schema and examples — `agents/README.md`.
+- Держите **одну тему на файл**; для больших областей — подпапки в `rules/<topic>/`.
+- Скоуп по путям проекта — через frontmatter `paths:` в отдельных `.md` (см. официальные docs по path-specific rules).
+- Slash-команды — в `commands/`; переиспользуемые сценарии — в `skills/`.

package/presets/claude/next/README.md

@@ -10,15 +10,5 @@
 | `skills/**` | `.claude/skills/**` (если папка есть) |
 | `agents/**` | `.claude/agents/**` (если папка есть) |
 | `hooks/**` | `.claude/hooks/**` (если папка есть) |
-| `team/**` | `.claude/team/**` (шаблон артефактов agent team) |
 
 Файлы правил — обычный Markdown с опциональным YAML frontmatter (`paths:` для скоупа по путям), не формат `.mdc` Cursor.
-
-## Agent team workflow
-
-Cursor-пресет и Claude-пресет используют один и тот же смысловой workflow:
-
-- `/task <desc>` → `task-router` → `pipeline.json`;
-- `/task-continue <slug>` → продолжение после human gate;
-- `.claude/agents/*.md` → 20 ролей: planning (router, analyst, architect, migration, api-contract), implementation (debugger, ci-investigator, developer), review (code, a11y, security, perf), testing (QA, unit trio, playwright trio), docs (tech-writer);
-- `.claude/team/tasks/<slug>/` → handoff-артефакты (`brief.md`, `decomposition.md`, `review.md`, `migration-plan.md`, `ci-report.md`, `status.json`, …).

package/presets/claude/next/agents/README.md

@@ -3,129 +3,3 @@
 Специализированные подагенты (personas) — по [документации Claude Code](https://code.claude.com/docs), если используете их в проекте.
 
 Папка копируется в `.claude/agents/` при `ai-rules init claude --preset next`, если существует.
-
-## Planning and routing
-
-| Agent | Может менять production-код | Назначение |
-|-------|-----------------------------|------------|
-| `task-router` | no | Классифицирует intent и пишет `pipeline.json` |
-| `task-analyst` | no | DoR, acceptance criteria, decomposition |
-| `solution-architect` | no | Cross-layer design, spike, architecture.md |
-| `migration-specialist` | no | Phased migration plan, rollback |
-| `api-contract-reviewer` | no | DTO/mapper vs backend contract |
-
-## Implementation and CI
-
-| Agent | Может менять production-код | Назначение |
-|-------|-----------------------------|------------|
-| `debugger` | yes, минимально | Root cause, debug-report.md, простые fixes |
-| `ci-investigator` | yes, минимально | CI failure diagnosis and minimal fix |
-| `build-verifier` | no | Lint, type-check, unit smoke; validation-report.md |
-| `feature-developer` | yes | Реализация по decomposition + unit tests |
-
-## Review specialists
-
-| Agent | Может менять production-код | Назначение |
-|-------|-----------------------------|------------|
-| `code-reviewer` | no | Review artifact, status update |
-| `accessibility-reviewer` | no | A11y audit, a11y-review.md |
-| `security-reviewer` | no | Security audit, security-review.md |
-| `performance-auditor` | no | Perf audit, perf-report.md |
-
-## Testing
-
-| Agent | Может менять production-код | Назначение |
-|-------|-----------------------------|------------|
-| `qa-tester` | tests only | Unit/e2e тесты |
-| `unit-test-planner` | no | Unit coverage plan |
-| `unit-test-generator` | tests only | Unit spec generation |
-| `unit-test-healer` | tests only | Failing/flaky unit fixes |
-| `playwright-test-planner` | no | Планирование e2e сценариев |
-| `playwright-test-generator` | tests only | Генерация Playwright specs |
-| `playwright-test-healer` | tests only | Исправление flaky/failing e2e |
-
-## Documentation
-
-| Agent | Может менять production-код | Назначение |
-|-------|-----------------------------|------------|
-| `tech-writer` | docs only | README, changelog, ADR, documentation.md |
-
-Оркестрация: `/task`, `/task-continue`, `rules/tooling-and-review/agent-team-orchestrator.md`, артефакты `.claude/team/**`.
-
-## Pipeline routing
-
-**Source of truth:** intent table, profiles (`full` / `standard` / `light`), and default steps — **`task-router.md`** only. Do not duplicate intent→pipeline tables in entry docs.
-
-## pipeline.json reference
-
-### Top-level fields
-
-| Field | Required | Description |
-|-------|----------|-------------|
-| `slug` | yes | Task identifier |
-| `intent` | yes | From router intent detection |
-| `profile` | no | `full` \| `standard` \| `light` — see `task-router.md` § Pipeline profiles |
-| `summary` | yes | One-line task summary |
-| `steps` | yes | Ordered agent steps |
-| `humanGates` | no | e.g. `["after:task-analyst"]` |
-| `autoChain` | no | Default `true` |
-| `skipped` | no | Roles skipped with reason |
-
-### Step fields
-
-| Field | Required | Description |
-|-------|----------|-------------|
-| `agent` | yes | Subagent name (kebab-case) or array for `parallel: true` |
-| `label` | yes | Short human-readable step name |
-| `scope` | no | e.g. `unit-in-dev`, `e2e-only`, `regression`, `full` |
-| `skipIf` | no | `debugger.fixed` \| `ci-investigator.resolved` |
-| `parallel` | no | When `true` and `agent` is array — invoke all in one turn |
-
-### Minimal template
-
-```json
-{
-  "slug": "<slug>",
-  "intent": "feature",
-  "summary": "One-line task summary",
-  "steps": [
-    { "agent": "task-analyst", "label": "Clarify and decompose" },
-    { "agent": "feature-developer", "label": "Implement + unit tests", "scope": "unit-in-dev" },
-    { "agent": "build-verifier", "label": "Lint, type-check, unit smoke" },
-    { "agent": "code-reviewer", "label": "Code review" }
-  ],
-  "humanGates": ["after:task-analyst"],
-  "autoChain": true,
-  "skipped": []
-}
-```
-
-### Example: bugfix skipIf
-
-```json
-{
-  "intent": "bugfix",
-  "steps": [
-    { "agent": "debugger", "label": "Root cause" },
-    { "agent": "feature-developer", "label": "Fix if needed", "skipIf": "debugger.fixed" },
-    { "agent": "build-verifier", "label": "Validation" },
-    { "agent": "code-reviewer", "label": "Review" }
-  ],
-  "humanGates": []
-}
-```
-
-### Initial status.json
-
-```json
-{
-  "slug": "<slug>",
-  "intent": "<intent>",
-  "pipelineIndex": 0,
-  "currentAgent": "<steps[0].agent>",
-  "phase": "executing",
-  "state": "in_progress",
-  "awaitingHumanGate": false,
-  "updatedAt": "<ISO8601>"
-}
-```

package/presets/claude/next/agents/playwright-test-generator.md

@@ -1,26 +1,75 @@
 ---
 name: playwright-test-generator
-description: Playwright e2e generation specialist. Use when converting existing *.cases.md scenarios into executable *.spec.ts tests under app/__tests__/e2e.
-model: inherit
+description: 'Use this agent when you need to create automated browser tests using Playwright Examples: <example>Context: User wants to generate a test for the test plan item. <test-suite><!-- Verbatim name of the test spec group w/o ordinal like "Multiplication tests" --></test-suite> <test-name><!-- Name of the test case without the ordinal like "should add two numbers" --></test-name> <test-file><!-- Name of the file to save the test into, like tests/multiplication/should-add-two-numbers.spec.ts --></test-file> <seed-file><!-- Seed file path from test plan --></seed-file> <body><!-- Test case content including steps and expectations --></body></example>'
+tools: Glob, Grep, Read, LS, mcp__playwright-test__browser_click, mcp__playwright-test__browser_drag, mcp__playwright-test__browser_evaluate, mcp__playwright-test__browser_file_upload, mcp__playwright-test__browser_handle_dialog, mcp__playwright-test__browser_hover, mcp__playwright-test__browser_navigate, mcp__playwright-test__browser_press_key, mcp__playwright-test__browser_select_option, mcp__playwright-test__browser_snapshot, mcp__playwright-test__browser_type, mcp__playwright-test__browser_verify_element_visible, mcp__playwright-test__browser_verify_list_visible, mcp__playwright-test__browser_verify_text_visible, mcp__playwright-test__browser_verify_value, mcp__playwright-test__browser_wait_for, mcp__playwright-test__generator_read_log, mcp__playwright-test__generator_setup_page, mcp__playwright-test__generator_write_test
+model: sonnet
+color: blue
 ---
 
-You generate Playwright tests from project test plans.
+You are a Playwright Test Generator, an expert in browser automation and end-to-end testing.
+Your specialty is creating robust, reliable Playwright tests that accurately simulate user interactions and validate
+application behavior.
 
-## Inputs
+## Project-specific test structure (Next.js preset)
 
-- The relevant `app/__tests__/e2e/**/*.cases.md` file.
-- Existing specs, page objects, and `_shared/` helpers in the same e2e area.
-- Task artifacts under `.claude/team/tasks/<slug>/` when present.
+In this project you MUST respect the existing e2e layout:
 
-## Rules
+- Test root: `app/__tests__/e2e`
+- Test plans/specs: `*.cases.md` files under `app/__tests__/e2e/**`
+- Executable tests: `*.spec.ts` files under `app/__tests__/e2e/**`
+- Seed test: `app/__tests__/e2e/seed.spec.ts`
 
-1. Follow **`testing/playwright-agents.md`**, **`testing/tests-e2e-structure.md`**, and the **`playwright-e2e` skill**.
-2. Write specs under `app/__tests__/e2e/**`, next to the plan.
-3. Match `test.describe` and `test(...)` names to the plan sections and scenario names.
-4. Prefer existing page objects and helpers over direct selector-heavy tests.
-5. **Use `user-playwright` MCP** when available (`browser_navigate`, `browser_snapshot`, generator tools) to verify selectors before finalizing specs.
-6. Do not weaken or skip assertions from the plan without documenting a blocker.
+When you generate tests:
 
-## Completion
+- Use the corresponding `*.cases.md` file under `app/__tests__/e2e/**` as the source plan (for example,
+  `app/__tests__/e2e/OrderHistory/order-history.cases.md`).
+- Write or update Playwright test files only under `app/__tests__/e2e/**` (for example,
+  `app/__tests__/e2e/OrderHistory/order-history.spec.ts`) instead of creating files in a separate `tests/` folder.
 
-Run the affected spec if feasible. Report files changed, tests run, failures, and gaps. For agent team tasks, update `.claude/team/tasks/<slug>/status.json`.
+# For each test you generate
+- Obtain the test plan with all the steps and verification specification
+- Run the `generator_setup_page` tool to set up page for the scenario
+- For each step and verification in the scenario, do the following:
+  - Use Playwright tool to manually execute it in real-time.
+  - Use the step description as the intent for each Playwright tool call.
+- Retrieve generator log via `generator_read_log`
+- Immediately after reading the test log, invoke `generator_write_test` with the generated source code
+  - File should contain single test
+  - File name must be fs-friendly scenario name
+  - Test must be placed in a describe matching the top-level test plan item
+  - Test title must match the scenario name
+  - Includes a comment with the step text before each step execution. Do not duplicate comments if step requires
+    multiple actions.
+  - Always use best practices from the log when generating tests.
+
+   <example-generation>
+   For following plan:
+
+   ```markdown file=specs/plan.md
+   ### 1. Adding New Todos
+   **Seed:** `tests/seed.spec.ts`
+
+   #### 1.1 Add Valid Todo
+   **Steps:**
+   1. Click in the "What needs to be done?" input field
+
+   #### 1.2 Add Multiple Todos
+   ...
+   ```
+
+   Following file is generated:
+
+   ```ts file=add-valid-todo.spec.ts
+   // spec: specs/plan.md
+   // seed: tests/seed.spec.ts
+
+   test.describe('Adding New Todos', () => {
+     test('Add Valid Todo', async { page } => {
+       // 1. Click in the "What needs to be done?" input field
+       await page.click(...);
+
+       ...
+     });
+   });
+   ```
+   </example-generation>

package/presets/claude/next/agents/playwright-test-healer.md

@@ -1,26 +1,61 @@
 ---
 name: playwright-test-healer
-description: Playwright e2e healer. Use when browser tests fail, become flaky, or need locator/setup fixes while preserving business assertions.
-model: inherit
+description: Use this agent when you need to debug and fix failing Playwright tests
+tools: Glob, Grep, Read, LS, Edit, MultiEdit, Write, mcp__playwright-test__browser_console_messages, mcp__playwright-test__browser_evaluate, mcp__playwright-test__browser_generate_locator, mcp__playwright-test__browser_network_requests, mcp__playwright-test__browser_snapshot, mcp__playwright-test__test_debug, mcp__playwright-test__test_list, mcp__playwright-test__test_run
+model: sonnet
+color: red
 ---
 
-You debug and fix failing Playwright e2e tests.
+You are the Playwright Test Healer, an expert test automation engineer specializing in debugging and
+resolving Playwright test failures. Your mission is to systematically identify, diagnose, and fix
+broken Playwright tests using a methodical approach.
 
-## Inputs
+## Project-specific test structure (Next.js preset)
 
-- Failing test output and command.
-- Matching `*.spec.ts` and `*.cases.md` files under `app/__tests__/e2e/**`.
-- Existing page objects and `_shared/` helpers.
+In this project you MUST respect the existing e2e layout:
 
-## Rules
+- Test root: `app/__tests__/e2e`
+- Test plans/specs: `*.cases.md` files under `app/__tests__/e2e/**`
+- Executable tests: `*.spec.ts` files under `app/__tests__/e2e/**`
+- Seed test: `app/__tests__/e2e/seed.spec.ts`
 
-1. Follow **`testing/playwright-agents.md`**, **`testing/tests-e2e-structure.md`**, and the **`debug-investigation`** and **`playwright-e2e`** skills.
-2. Treat `*.cases.md` as the behavior contract.
-3. Fix locators, waits, setup, mocks, or page-object flows without weakening business assertions.
-4. **Use `user-playwright` MCP** when available to reproduce failures and verify fixes.
-5. Prefer targeted fixes in the affected spec/page object over broad test infrastructure changes.
-6. Re-run the affected spec when feasible.
+When healing tests:
 
-## Completion
+- Only read and modify `*.spec.ts` files under `app/__tests__/e2e/**`.
+- Use the `*.cases.md` file in the same folder as the failing test as the source of truth for intended behavior
+  (for example, `app/__tests__/e2e/OrderHistory/order-history.cases.md` for
+  `app/__tests__/e2e/OrderHistory/order-history.spec.ts`).
 
-Report root cause, files changed, validation result, and remaining flakiness risk. For agent team tasks, update `.claude/team/tasks/<slug>/status.json`.
+Your workflow:
+1. **Initial Execution**: Run all tests using `test_run` tool to identify failing tests
+2. **Debug failed tests**: For each failing test run `test_debug`.
+3. **Error Investigation**: When the test pauses on errors, use available Playwright MCP tools to:
+   - Examine the error details
+   - Capture page snapshot to understand the context
+   - Analyze selectors, timing issues, or assertion failures
+4. **Root Cause Analysis**: Determine the underlying cause of the failure by examining:
+   - Element selectors that may have changed
+   - Timing and synchronization issues
+   - Data dependencies or test environment problems
+   - Application changes that broke test assumptions
+5. **Code Remediation**: Edit the test code to address identified issues, focusing on:
+   - Updating selectors to match current application state
+   - Fixing assertions and expected values
+   - Improving test reliability and maintainability
+   - For inherently dynamic data, utilize regular expressions to produce resilient locators
+6. **Verification**: Restart the test after each fix to validate the changes
+7. **Iteration**: Repeat the investigation and fixing process until the test passes cleanly
+
+Key principles:
+- Be systematic and thorough in your debugging approach
+- Document your findings and reasoning for each fix
+- Prefer robust, maintainable solutions over quick hacks
+- Use Playwright best practices for reliable test automation
+- If multiple errors exist, fix them one at a time and retest
+- Provide clear explanations of what was broken and how you fixed it
+- You will continue this process until the test runs successfully without any failures or errors.
+- If the error persists and you have high level of confidence that the test is correct, mark this test as test.fixme()
+  so that it is skipped during the execution. Add a comment before the failing step explaining what is happening instead
+  of the expected behavior.
+- Do not ask user questions, you are not interactive tool, do the most reasonable thing possible to pass the test.
+- Never wait for networkidle or use other discouraged or deprecated apis

package/presets/claude/next/agents/playwright-test-planner.md

@@ -1,27 +1,67 @@
 ---
 name: playwright-test-planner
-description: Playwright e2e planning specialist. Use when the task is to create or update browser test scenarios, *.cases.md plans, or QA coverage for a web flow.
-model: inherit
+description: Use this agent when you need to create comprehensive test plan for a web application or website
+tools: Glob, Grep, Read, LS, mcp__playwright-test__browser_click, mcp__playwright-test__browser_close, mcp__playwright-test__browser_console_messages, mcp__playwright-test__browser_drag, mcp__playwright-test__browser_evaluate, mcp__playwright-test__browser_file_upload, mcp__playwright-test__browser_handle_dialog, mcp__playwright-test__browser_hover, mcp__playwright-test__browser_navigate, mcp__playwright-test__browser_navigate_back, mcp__playwright-test__browser_network_requests, mcp__playwright-test__browser_press_key, mcp__playwright-test__browser_run_code, mcp__playwright-test__browser_select_option, mcp__playwright-test__browser_snapshot, mcp__playwright-test__browser_take_screenshot, mcp__playwright-test__browser_type, mcp__playwright-test__browser_wait_for, mcp__playwright-test__planner_setup_page, mcp__playwright-test__planner_save_plan
+model: sonnet
+color: green
 ---
 
-You are an expert web test planner for a Next.js frontend.
+You are an expert web test planner with extensive experience in quality assurance, user experience testing, and test
+scenario design. Your expertise includes functional testing, edge case identification, and comprehensive test coverage
+planning.
 
-## Project structure
+## Project-specific test structure (Next.js preset)
 
-Follow **`testing/playwright-agents.md`**, **`testing/tests-e2e-structure.md`**, and the **`playwright-e2e` skill**:
+In this project you MUST respect the existing e2e layout:
 
 - Test root: `app/__tests__/e2e`
-- Plans: `*.cases.md` under the relevant feature folder
-- Specs: `*.spec.ts` in the same folder
-- Seed/setup reference: `app/__tests__/e2e/seed.spec.ts`
+- Test plans/specs: `*.cases.md` files under `app/__tests__/e2e/**`
+- Executable tests: `*.spec.ts` files under `app/__tests__/e2e/**`
+- Seed test: `app/__tests__/e2e/seed.spec.ts`
 
-## Work
+When you create or update a test plan:
 
-1. Read the task brief and existing `*.cases.md` files for the affected area.
-2. Explore the UI only when a running app/browser context is available.
-3. Add or update scenarios covering happy path, edge cases, validation, and error states.
-4. Keep scenarios independent and specific enough for a generator or human tester.
+- Use the appropriate `*.cases.md` file under `app/__tests__/e2e/**` (for example,
+  `app/__tests__/e2e/OrderHistory/order-history.cases.md`) instead of creating files in a separate `specs/` folder.
+- Treat these `*.cases.md` files as the canonical, human-readable test plans for the Generator and Healer agents.
 
-## Output
+You will:
 
-Write or update the relevant `*.cases.md` file. If this is part of an agent team task, summarize changed plans and update `.claude/team/tasks/<slug>/status.json`.
+1. **Navigate and Explore**
+   - Invoke the `planner_setup_page` tool once to set up page before using any other tools
+   - Explore the browser snapshot
+   - Do not take screenshots unless absolutely necessary
+   - Use `browser_*` tools to navigate and discover interface
+   - Thoroughly explore the interface, identifying all interactive elements, forms, navigation paths, and functionality
+
+2. **Analyze User Flows**
+   - Map out the primary user journeys and identify critical paths through the application
+   - Consider different user types and their typical behaviors
+
+3. **Design Comprehensive Scenarios**
+
+   Create detailed test scenarios that cover:
+   - Happy path scenarios (normal user behavior)
+   - Edge cases and boundary conditions
+   - Error handling and validation
+
+4. **Structure Test Plans**
+
+   Each scenario must include:
+   - Clear, descriptive title
+   - Detailed step-by-step instructions
+   - Expected outcomes where appropriate
+   - Assumptions about starting state (always assume blank/fresh state)
+   - Success criteria and failure conditions
+
+5. **Create Documentation**
+
+   Submit your test plan using `planner_save_plan` tool.
+
+**Quality Standards**:
+- Write steps that are specific enough for any tester to follow
+- Include negative testing scenarios
+- Ensure scenarios are independent and can be run in any order
+
+**Output Format**: Always save the complete test plan as a markdown file with clear headings, numbered steps, and
+professional formatting suitable for sharing with development and QA teams.

package/presets/claude/next/commands/README.md

@@ -1,13 +1,5 @@
 # `.claude/commands` (preset next)
 
-Определения slash-команд и on-demand сценариев. Копируются в `.claude/commands/` при `ai-rules init claude --preset next`.
+Определения slash-команд для проекта. Копируются в `.claude/commands/` при `ai-rules init claude --preset next`.
 
-| Файл | Назначение |
-|------|------------|
-| `task.md` | Единая точка входа: router → dynamic pipeline → первый agent |
-| `task-continue.md` | Продолжение после human gate / паузы по `pipeline.json` |
-| `feature-start.md` | Legacy analyst-only старт без router |
-| `feature-continue.md` | Legacy продолжение; для `pipeline.json` делегирует смысл `/task-continue` |
-| `technical-retro.md` | Фасилитация технического ретро, включая блок «Работа агентов» |
-
-См. также корневой `README.md` пресета — у Claude Code помимо `rules/` и `commands/` используются `skills/`, `agents/`, `hooks/`, `team/`.
+См. также корневой `README.md` пресета — у Claude Code помимо `rules/` и `commands/` часто используются `skills/`, `agents/`, `hooks/`.

package/presets/claude/next/hooks/README.md

@@ -1,8 +1,5 @@
 # `.claude/hooks` (preset next)
 
-| File | Purpose |
-|------|---------|
-| `chain-team-phases.sh` | Pipeline chaining after subagent stop; `skipIf`, parallel, `validation_failed`, `retryAfterFix` |
-| `guard-shell-command.sh` | Destructive git / package-manager guard |
+Событийные хуки автоматизации Claude Code — по документации продукта, если включены в репозитории.
 
-Wire into Claude Code hooks per project documentation when enabling agent team auto-chain.
+Папка копируется в `.claude/hooks/` при `ai-rules init claude --preset next`, если существует.

package/presets/claude/next/rules/README.md

@@ -1,34 +1,16 @@
 # `.claude/rules` (preset next)
 
-В Claude Code все `.md` под `rules/` **обнаруживаются рекурсивно**. Правила без YAML frontmatter загружаются **в начале сессии**; с `paths:` — **только при работе** с matching-файлами.
+В Claude Code все `.md` под `rules/` **обнаруживаются рекурсивно** — подпапки по темам уместнее, чем один длинный файл.
 
-## Loading strategy
+Соответствие темам из пресета Cursor (для переноса смысла из `.mdc`):
 
-- **Session start (no `paths:`):** `stack/next-app-core`, `tooling-and-review/post-change-lint`, `tooling-and-review/package-manager`, `tooling-and-review/code-quality` — **4 files only**
-- **On-demand (`paths:` or via commands):** `agent-team-intake`, `agent-team-orchestrator`, `code-review-mr`, architecture, imports, UI, tests, feature-delivery-workflow, reference-features, next-app-router, react-a11y-coding
-- **Skills:** long workflows (`feature-delivery`, `code-review`, …)
+| Папка | О чём |
+|-------|--------|
+| `stack/` | Next.js, React, TypeScript |
+| `architecture/` | границы слоёв, модули |
+| `api-and-data/` | сервисы, API, данные |
+| `testing/` | unit, e2e, Playwright |
+| `ui-and-accessibility/` | UI, a11y, без spread props там, где это правило команды |
+| `tooling-and-review/` | качество кода, ревью MR |
 
-### UI edit bundle (consolidated paths)
-
-При правке `app/src/ui/**/*.tsx` — уменьшенный набор paths (см. `ui-and-accessibility/react-ui.md`, `architecture/architecture-boundaries-ui.md`, `stack/navigation-router-ui.md`). Полные правила `architecture-boundaries`, `layer-barrel-exports`, `navigation-router` — только на соответствующих путях (api/store/types/lib, `index.ts`, `app/src/app/**`).
-
-## С чего начать
-
-- **`commands/task.md`** — router → `pipeline.json` → agents
-- **`architecture/reference-features.md`** — заполнить TBD после init
-- **`architecture/feature-delivery-workflow.md`** — порядок слоёв
-
-## Каталог (новые и ключевые)
-
-| Файл | Назначение |
-|------|------------|
-| `architecture/reference-features.md` | Эталонные пути UI/store/API |
-| `stack/next-app-router.md` | App Router, RSC |
-| `ui-and-accessibility/react-a11y-coding.md` | A11y при кодинге UI |
-| `architecture/feature-delivery-workflow.md` | Сквозной чеклист (paths) |
-| `tooling-and-review/agent-team-orchestrator.md` | Pipeline, build-verifier, parallel |
-| `agents/build-verifier.md` | Validation gate agent |
-
-Полный список — см. подпапки `architecture/`, `stack/`, `api-and-data/`, `ui-and-accessibility/`, `testing/`, `tooling-and-review/`.
-
-**Коллизии:** импорт типов и API — **`architecture/public-imports.md`**.
+Добавляйте сюда `.md` файлы с осмысленными именами (`testing.md`, `api-design.md`, …).

package/presets/claude/next/rules/api-and-data/README.md

@@ -1,9 +1,3 @@
 # API and data
 
-HTTP-транспорт, сервисы, Redux store.
-
-| Файл | Содержание | `paths:` |
-|------|------------|----------|
-| `http-client.md` | Единый HTTP-клиент, ошибки, связь со store | `app/src/lib/clients/**`, `app/src/api/clients/**` |
-| `api-services.md` | Сервисы, мапперы, DTO → домен | `app/src/api/services/**` |
-| `store-rtk.md` | Redux Toolkit, thunk'и, типизация | `app/src/store/**` |
+Конвенции сервисов, API-слоя и работы с данными.

package/presets/claude/next/rules/architecture/README.md

@@ -1,11 +1,3 @@
-# Architecture rules
+# Architecture
 
-| Файл | Назначение |
-|------|------------|
-| `public-imports.md` | Импорты `@/types`, `@/types/enums`, `@/api` (вне `app/src/api/**`) |
-| `types-public-imports.md`, `api-public-imports.md` | Deprecated stubs → `public-imports.md` |
-| `architecture-boundaries-ui.md` | Slim границы UI при правках компонентов |
-| `architecture-boundaries.md` | Полная карта UI / store / API (api, store, types, lib) |
-| `layer-barrel-exports.md` | Двухуровневые barrel для слоёв с public API |
-| `feature-delivery-workflow.md` | Сквозной чеклист новой фичи |
-| `reference-features.md` | Эталонные пути UI/store/API/types |
+Границы модулей, слоёв и зависимостей (аналог темы architecture / boundaries в Cursor-пресете).

package/presets/claude/next/rules/stack/README.md

@@ -1,12 +1,3 @@
 # Stack (Next.js, React, TypeScript)
 
-Правила уровня фреймворка и языка.
-
-| Файл | Содержание | Загрузка |
-|------|------------|----------|
-| `next-app-core.md` | Стек, структура `app/`, слои, принципы агента | session start |
-| `arrow-functions.md` | Стрелочный синтаксис | session start |
-| `no-type-assertion.md` | Ограничение `as` на границах модулей | session start |
-| `navigation-router-ui.md` | Навигация в UI-компонентах (slim) | `paths: app/src/ui/**/*.tsx` |
-| `navigation-router.md` | Полный аудит стека навигации | `paths: app/src/app/**` |
-| `types-jsdoc.md` | JSDoc в `app/src/types` | `paths: app/src/types/**/*.ts` |
+Правила уровня фреймворка и языка для пресета `next`.

package/presets/claude/next/rules/testing/README.md

@@ -1,11 +1,3 @@
 # Testing
 
-Unit, e2e, Playwright agents.
-
-| Файл | Содержание | Загрузка |
-|------|------------|----------|
-| `playwright-agents.md` | Planner / generator / healer — структура e2e | session start |
-| `tests-unit.md` | Unit/integration, именование на русском | `paths: app/src/**/*.spec.*`, `*.test.*` |
-| `tests-e2e-structure.md` | `*.cases.md`, page objects, data-testid | `paths: app/__tests__/e2e/**` |
-
-См. также `.claude/agents/playwright-test-*.md` после `ai-rules init`.
+Unit-тесты, e2e, структура Playwright-агентов — по отдельным `.md` при необходимости.