@jetrabbits/agentic 0.0.1

package/areas/software/full-stack/workflows/debug-issue.md

@@ -0,0 +1,70 @@
+---
+name: debug-issue
+type: workflow
+trigger: /debug-issue
+description: Systematically diagnose and fix a bug in a full-stack Python/FastAPI + Next.js application.
+inputs:
+  - issue_description
+  - error_logs
+  - reproduction_steps
+outputs:
+  - root_cause_identified
+  - fix_implemented
+  - regression_test_added
+roles:
+  - "@backend-dev"
+  - "@qa-engineer"
+  - "@team-lead"
+execution:
+  initiator: developer
+related-rules:
+  - backend-architecture-rule.md
+  - testing-ci-guide.md
+  - logging-observability-guide.md
+uses-skills:
+  - troubleshooting
+  - observability
+quality-gates:
+  - bug reproducible before fix
+  - regression test fails before fix, passes after
+  - no mypy/ruff errors introduced
+  - root cause documented
+---
+
+## Steps
+
+### 1. Triage — `@backend-dev`
+- **Input:** issue description, error logs, environment context
+- **Actions:** classify severity (P1 data loss/outage, P2 functional break, P3 cosmetic); identify affected component from stack trace; check if reproducible in staging; check recent deploys and migrations that could have caused this
+- **Output:** triage note — severity, affected layer, reproduction status
+- **Done when:** severity assigned; reproduction path identified or deemed flaky
+
+### 2. Reproduce — `@backend-dev`
+- **Input:** triage note, reproduction steps
+- **Actions:** write a failing test that demonstrates the bug (unit or integration); if E2E: write Playwright test; run test — **must fail** before any fix; if test cannot be written, document why
+- **Output:** failing test committed to branch `fix/<issue-id>`
+- **Done when:** test reproduces issue deterministically; committed
+
+### 3. Root Cause Analysis — `@backend-dev`
+- **Input:** failing test, code
+- **Actions:** use `EXPLAIN ANALYZE` for slow/incorrect queries; check log correlation (`request_id`); trace data through layers (API → Service → Repository → DB); identify exact line/condition causing the bug
+- **Output:** root cause comment in ticket + code location identified
+- **Done when:** root cause statement: "Bug is caused by [specific condition] in [file:line]"
+
+### 4. Fix — `@backend-dev`
+- **Input:** root cause, failing test
+- **Actions:** implement minimal fix; run regression test — **must now pass**; run full test suite to check for regressions; fix must be in the correct architectural layer (don't fix a service bug in the API layer)
+- **Output:** fix committed; tests passing
+- **Done when:** regression test green; full suite green; `make lint` clean
+
+### 5. Review & Document — `@team-lead`
+- **Input:** fix + tests
+- **Actions:** review that fix addresses root cause not symptoms; verify regression test quality; update incident log if P1/P2; PR includes: root cause, fix rationale, test evidence
+- **Output:** approved PR; root cause documented
+- **Done when:** PR merged; postmortem note added for P1/P2 issues
+
+## Iteration Loop
+If fix reveals deeper root cause → return to Step 3 with updated understanding.
+
+## Exit
+Merged fix + regression test + root cause documented in ticket.

package/areas/software/full-stack/workflows/develop-feature.md

@@ -0,0 +1,85 @@
+---
+name: develop-feature
+type: workflow
+trigger: /develop-feature
+description: Implement a feature end-to-end in a full-stack Python/FastAPI project following the layered architecture.
+inputs:
+  - feature_description
+  - acceptance_criteria
+  - tech_stack
+outputs:
+  - working_feature_branch
+  - tests_passing
+  - pr_ready
+roles:
+  - "@team-lead"
+  - "@backend-dev"
+  - "@frontend-dev"
+  - "@qa-engineer"
+execution:
+  initiator: team-lead
+related-rules:
+  - backend-architecture-rule.md
+  - api-design-guide.md
+  - domain-models-guide.md
+  - database-migrations-guide.md
+  - testing-ci-guide.md
+uses-skills:
+  - backend-developer
+  - api-design-principles
+quality-gates:
+  - all tests pass (unit + integration + e2e)
+  - no mypy/ruff errors
+  - architecture layer boundaries respected (no cross-layer imports)
+  - PR description includes test evidence
+---
+
+## Steps
+
+### 1. Design — `@team-lead`
+- **Input:** feature description, acceptance criteria
+- **Actions:** clarify domain model changes; draft API contract (endpoint, request/response schema, error codes); identify DB schema changes needed; flag breaking changes
+- **Output:** `design/feature-<name>.md` — API contract + data model
+- **Done when:** API contract approved (user or tech lead sign-off)
+
+### 2. DB Model & Migration — `@backend-dev`
+- **Input:** `design/feature-<name>.md`
+- **Actions:** define/update SQLAlchemy models; generate Alembic migration (`alembic revision --autogenerate`); review migration file — check for unsafe operations (column rename, NOT NULL without default); run `alembic upgrade head`
+- **Output:** migration file in `alembic/versions/`; updated `models/`
+- **Done when:** `alembic upgrade head` succeeds; existing tests still pass
+
+### 3. Repository Layer — `@backend-dev`
+- **Input:** updated models
+- **Actions:** implement CRUD operations in `repositories/`; use `AsyncSession`; apply cursor-based pagination for list queries; write repository unit tests with transaction rollback isolation
+- **Output:** `repositories/<entity>_repo.py` + tests
+- **Done when:** repository tests pass; no business logic in repo layer
+
+### 4. Service Layer — `@backend-dev`
+- **Input:** repository layer
+- **Actions:** implement business logic in `services/`; enforce invariants; manage transactions (`async with session.begin()`); emit domain events if needed; write service unit tests with fake repository
+- **Output:** `services/<entity>_service.py` + tests
+- **Done when:** service tests pass; service imports only repository, not DB directly
+
+### 5. API Endpoint — `@backend-dev`
+- **Input:** service layer, API contract from Step 1
+- **Actions:** implement FastAPI endpoint in `api/v1/endpoints/`; validate inputs via Pydantic schemas; use FastAPI `Depends()` for auth + DB; apply correct HTTP status codes; write API integration tests
+- **Output:** endpoint file + `schemas/<entity>.py` + integration tests
+- **Done when:** endpoint matches contract from Step 1; auth + validation tested; `make lint` clean
+
+### 6. Frontend / UI — `@frontend-dev`
+- **Input:** API contract, acceptance criteria
+- **Actions:** implement UI changes (component, page, server action); connect to API; handle loading/error/empty states; add `data-testid` for E2E selectors
+- **Output:** updated `features/<name>/` directory
+- **Done when:** feature visible and functional in dev; all states handled
+
+### 7. QA & PR — `@qa-engineer` + `@team-lead`
+- **Input:** complete implementation
+- **Actions:** write/run E2E test covering acceptance criteria; run full test suite (`make test`); verify no ruff/mypy errors; create PR with: description, test evidence (output), design doc link
+- **Output:** passing CI + PR ready for review
+- **Done when:** `make test` green; `make lint` clean; PR submitted
+
+## Iteration Loop
+If review finds issues → return to relevant step (Step 2 for schema issues, Step 4 for logic issues, Step 5 for API issues).
+
+## Exit
+Merged PR with passing CI. Feature accessible in target environment.

package/areas/software/full-stack/workflows/feature-implementation-flow.md

@@ -0,0 +1,78 @@
+---
+name: feature-implementation-flow
+type: workflow
+trigger: /feature-implementation-flow
+description: Implement a single feature into an existing full-stack service with strict layered architecture.
+inputs:
+  - feature_request
+  - existing_codebase
+outputs:
+  - implemented_feature
+  - passing_tests
+roles:
+  - pm
+  - team-lead
+  - designer
+  - developer
+  - qa
+execution:
+  initiator: pm
+related-rules:
+  - backend-architecture-rule.md
+  - code-quality-guide.md
+  - testing-ci-guide.md
+uses-skills:
+  - backend-developer
+quality-gates:
+  - layered architecture rules respected (no business logic in API layer)
+  - unit and integration tests pass
+  - lint and type checks pass
+---
+
+## Steps
+
+### 1. Requirement Analysis & Models — `@pm` + `@team-lead`
+- **Input:** feature request
+- **Actions:** `@pm` captures requirements; `@team-lead` identifies impacted domain entities and determines if schema changes are needed; `@designer` provides UX/interaction specs if UI is involved
+- **Output:** confirmed feature spec with data model notes
+- **Done when:** impacted layers identified; `@developer` briefed
+
+### 2. Design & Planning — `@team-lead` + `@designer`
+- **Input:** confirmed feature spec
+- **Actions:** design layer changes (models → repository → service → API); specify Pydantic/DTO schemas for input/output; plan Alembic migration if schema changes needed; define UX states (loading / empty / error / success) if frontend involved
+- **Output:** brief implementation plan presented to `@pm` for user confirmation
+- **Done when:** user/stakeholder confirms plan; approach is approved
+
+### 3. Implementation — Inner to Outer — `@developer`
+- **Input:** approved implementation plan
+- **Actions:**
+  - **Models/Schemas:** update `src/models/` (SQLAlchemy) if schema changes; create Alembic migration; define Pydantic input/output schemas in `src/schemas/`
+  - **Repository Layer:** implement data access methods in `src/repositories/`; ensure IO-bound operations are async
+  - **Service Layer:** implement business logic in `src/services/`; inject repository dependencies; handle exceptions, convert to business errors; do not import FastAPI/Flask objects here
+  - **API Layer:** add/update endpoints in `src/api/`; validate input via schemas; call service methods only; no direct DB access
+- **Output:** feature implemented on branch; no cross-layer violations
+- **Done when:** all layers implemented; local checks pass
+
+### 4. Verification — `@developer` + `@qa`
+- **Input:** implemented feature branch
+- **Actions:**
+  - unit tests: test service logic (mock repositories); test repository logic (test DB or mocks)
+  - integration tests: test API endpoints end-to-end with test client
+  - `make lint` — zero errors; `make fmt` — no diffs; strict typing verified
+  - `@qa` runs acceptance checks against feature spec
+- **Output:** passing test suite; lint/type checks clean
+- **Done when:** all checks pass; acceptance criteria verified
+
+### 5. Review — `@team-lead`
+- **Input:** feature branch + test results
+- **Actions:** verify layer boundaries respected; check schema definitions and error handling; review test quality; provide blocking / non-blocking feedback
+- **Output:** review feedback
+- **Done when:** all blocking feedback resolved; `@team-lead` approves
+
+### 6. Fix / Retest Loop — `@developer` + `@qa`
+- **Input:** blocking feedback
+- **Actions:** fix; re-run checks; re-request review
+- **Done when:** zero blocking issues; all checks green
+
+## Exit
+`@team-lead` approval + passing checks = feature ready to merge.

package/areas/software/full-stack/workflows/testing-ci-pipeline.md

@@ -0,0 +1,65 @@
+---
+name: testing-ci-pipeline
+type: workflow
+trigger: /testing-ci-pipeline
+description: Run the full CI and testing pipeline for backend or frontend projects and produce a verified quality signal.
+inputs:
+  - project_type
+  - test_scope
+outputs:
+  - test_report
+  - pipeline_status
+roles:
+  - developer
+  - qa
+  - team-lead
+execution:
+  initiator: developer
+related-rules:
+  - testing-ci-guide.md
+  - code-quality-guide.md
+uses-skills:
+  - blackbox-test
+quality-gates:
+  - lint and format clean
+  - all tests in selected scope pass
+  - build artifact produced successfully
+---
+
+## Steps
+
+### 1. Code Quality Check — `@developer`
+- **Input:** current branch
+- **Actions:** run linters and formatters using project-standard tools (e.g. `ruff` for Python, `eslint` + `prettier` for JS/TS); fix all errors — do not suppress
+- **Output:** lint/format clean
+- **Done when:** `make lint` exits 0; `make fmt` produces no diffs
+
+### 2. Unit Tests — `@developer`
+- **Input:** lint-clean branch
+- **Actions:** run unit test suite: `make test`; confirm coverage meets project threshold (default ≥ 70%)
+- **Output:** unit tests passing; coverage report
+- **Done when:** `make test` exits 0; coverage threshold met
+
+### 3. Build / Prepare — `@developer`
+- **Input:** green unit tests
+- **Actions:** build production artifact or Docker image (`make build` or `docker build`); confirm build succeeds with no warnings treated as errors
+- **Output:** build artifact or image produced
+- **Done when:** build exits 0; artifact is usable
+
+### 4. E2E / Integration Tests — `@qa`
+- **Input:** built artifact; condition: `test_scope` is `e2e` or `all`
+- **Actions:** start services via Docker Compose; run blackbox/E2E suite: `make e2e-test`; capture logs and screenshots on failure
+- **Output:** E2E test results; pass/fail per scenario
+- **Done when:** all scenarios pass; or failures are classified (blocker vs. known flake)
+
+### 5. Results Review & Report — `@team-lead` + `@qa`
+- **Input:** all step outputs
+- **Actions:** `@qa` produces `test_report.md` — step results, coverage delta, failure details; `@team-lead` reviews and makes pipeline pass/fail decision; blocker failures must be fixed before merge
+- **Output:** `test_report.md`; pipeline status: PASS / FAIL / CONDITIONAL
+- **Done when:** report complete; status communicated to `@developer`
+
+## Failure Policy
+If any step fails: pipeline halts. Fix the violation before proceeding. Do not skip or suppress failures.
+
+## Exit
+All steps green + `test_report.md` produced = pipeline passed.

package/areas/software/general/AGENTS.md

@@ -0,0 +1,68 @@
+# Software — general guidance index
+
+This area contains the shared SDLC baseline inherited by all software specialization areas. Load this before any domain-specific guidance.
+
+## What this area covers
+
+Cross-cutting engineering practices that apply regardless of stack: Git workflow, CI/CD standards, linting, code style, SDLC methodology, role responsibilities, and project setup conventions. Every software specialization area inherits from here and adds only domain-specific overrides.
+
+## Inheritance contract
+
+All specialization areas follow this load order:
+
+```
+AGENTS.md (scope) → rules (constraints) → skills (execution patterns) → workflows (orchestration)
+```
+
+Specializations reference general guidance and keep only domain-specific overrides. Do not duplicate general rules in domain-level files.
+
+## Spec selection
+
+| Task type | Area to load |
+|:---|:---|
+| API / service development | `software/backend/` |
+| UI / component development | `software/frontend/` |
+| Full product feature (API + UI) | `software/full-stack/` |
+| Data pipelines, dbt, warehouses | `software/data-engineering/` |
+| ML training, evaluation, deployment | `software/mlops/` |
+| iOS / Android / React Native | `software/mobile/` |
+| Infrastructure, K8s, CI/CD, incidents | `software/platform/` |
+| Test strategy, coverage, QA tooling | `software/qa/` |
+| Security scans, threat modeling | `software/security/` |
+| Cross-cutting / unclear domain | `software/general/` |
+
+## Cross-cutting constraints
+
+- **Git discipline** — every change lives in a branch; no direct commits to main.
+- **Lint and format** — all files pass configured linters before any handoff.
+- **SDLC role separation** — no role consolidation when subagent execution is required.
+- **README sync** — public-facing READMEs updated whenever behavior or setup changes.
+
+## Guidance tree
+
+```text
+general/
+├── rules/
+│   ├── git-workflow-guide.md          ← branching, commit messages, PR conventions
+│   ├── github-workflow-guide.md       ← GitHub-specific CI triggers and branch protection
+│   ├── gitlab-ci-guide.md             ← GitLab CI pipeline conventions
+│   ├── makefile-guide.md              ← standard Makefile targets and conventions
+│   ├── docker-compose-guide.md        ← local multi-service development setup
+│   ├── lint-format-guide.md           ← linter config and pre-commit hooks
+│   ├── sdlc-methodology-guide.md      ← phase definitions, entry/exit criteria
+│   ├── sdlc-role-responsibilities.md  ← role matrix, handoff contracts, DoD
+│   ├── readme-sync-guide.md           ← what READMEs must contain and when to update
+│   └── code-style-guide.md            ← naming, structure, DRY, single responsibility
+├── skills/
+│   └── general-dev-tools/SKILL.md     ← cross-stack dev tooling patterns
+└── workflows/
+    ├── project-setup-workflow.md       ← /project-setup
+    ├── code-review-workflow.md         ← /code-review
+    └── development-cycle-workflow.md   ← /dev-cycle
+```
+
+## Discovery patterns
+
+- `rules/*.md`
+- `skills/*/SKILL.md`
+- `workflows/*.md`

package/areas/software/general/prompts/code-review-workflow.md

@@ -0,0 +1,87 @@
+---
+workflow: code-review-workflow
+---
+
+# Prompt: `/code-review-workflow`
+
+Use when: reviewing an open pull/merge request or a specific code change.
+
+---
+
+## Example 1 — Feature PR review
+
+**EN:**
+```
+/code-review-workflow PR #87 "Add rate limiting to public API"
+
+PR scope: adds Redis-backed sliding window rate limiter to all /api/v1/* endpoints.
+Focus areas:
+- Correctness of sliding window algorithm
+- Redis failure handling (should degrade gracefully, not block requests)
+- Test coverage for rate limit breach (429) and header presence
+- No hardcoded config values (limits must be env-configurable)
+Files changed: src/middleware/rate_limit.py, tests/test_rate_limit.py, src/config.py
+```
+
+**RU:**
+```
+/code-review-workflow PR #87 "Добавить rate limiting на публичный API"
+
+Скоуп PR: Redis-backed sliding window rate limiter для всех /api/v1/* эндпоинтов.
+Фокус:
+- Корректность алгоритма sliding window
+- Обработка сбоя Redis (должен деградировать gracefully, не блокировать запросы)
+- Покрытие тестами для 429 ответа и наличия заголовков
+- Нет hardcoded значений (лимиты настраиваются через env)
+Изменённые файлы: src/middleware/rate_limit.py, tests/test_rate_limit.py, src/config.py
+```
+
+---
+
+## Example 2 — Architecture-focused review
+
+**EN:**
+```
+/code-review-workflow PR #104 "Migrate order processing to event-driven"
+
+This is a large architectural PR. Key review concerns:
+- Does OrderService still have any direct calls to PaymentService? (should emit event only)
+- Is the dual-write period (sync + async) clearly temporary and documented?
+- Are events idempotent? If consumer replays an event, is it safe?
+- Are all new message schemas versioned?
+Diff size: ~800 lines across 12 files
+```
+
+**RU:**
+```
+/code-review-workflow PR #104 "Миграция обработки заказов на event-driven"
+
+Это большой архитектурный PR. Ключевые вопросы:
+- Нет ли прямых вызовов OrderService → PaymentService? (должен только emit event)
+- Чётко ли обозначен dual-write период как временный и задокументирован?
+- Идемпотентны ли события? Безопасен ли повторный replay у консьюмера?
+- Версионированы ли все новые message schemas?
+Размер diff: ~800 строк в 12 файлах
+```
+
+---
+
+## Example 3 — Quick / Security-focused
+
+**EN:**
+```
+/code-review-workflow PR #91 "Add admin user deletion endpoint"
+
+Security-focused review: DELETE /admin/users/{id}
+Check: auth middleware applied (admin scope required); audit log written on deletion;
+soft-delete or hard-delete with confirmation; no IDOR possible via id parameter.
+```
+
+**RU:**
+```
+/code-review-workflow PR #91 "Добавить эндпоинт удаления пользователей для администратора"
+
+Ревью с фокусом на безопасность: DELETE /admin/users/{id}
+Проверить: применён auth middleware (требуется admin scope); запись в audit log при удалении;
+soft-delete или hard-delete с подтверждением; нет возможности IDOR через параметр id.
+```

package/areas/software/general/prompts/development-cycle-workflow.md

@@ -0,0 +1,83 @@
+---
+workflow: development-cycle-workflow
+---
+
+# Prompt: `/development-cycle-workflow`
+
+Use when: starting any development task from a ticket, issue, or verbal request.
+
+---
+
+## Example 1 — Feature ticket
+
+**EN:**
+```
+/development-cycle-workflow PROJ-142 "Add pagination to GET /products"
+
+Task: the endpoint currently returns all products with no limit. Add cursor-based pagination.
+Acceptance criteria:
+- Query params: limit (default 20, max 100), cursor (opaque string)
+- Response: { items: Product[], next_cursor?: string }
+- Existing clients with no query params get first 20 results (no breaking change)
+Constraints: no new dependencies; reuse existing DB query helpers
+```
+
+**RU:**
+```
+/development-cycle-workflow PROJ-142 "Добавить пагинацию в GET /products"
+
+Задача: эндпоинт возвращает все продукты без ограничений. Добавить cursor-based пагинацию.
+Критерии приёмки:
+- Query params: limit (по умолчанию 20, макс 100), cursor (непрозрачная строка)
+- Ответ: { items: Product[], next_cursor?: string }
+- Существующие клиенты без параметров получают первые 20 результатов (без breaking change)
+Ограничения: без новых зависимостей; переиспользовать существующие DB helpers
+```
+
+---
+
+## Example 2 — Bug fix
+
+**EN:**
+```
+/development-cycle-workflow PROJ-198 "Fix: user session expires immediately after login on Safari"
+
+Bug: users on Safari 17 are logged out immediately after successful login.
+Observed: redirect to /login happens 2 seconds after landing on /dashboard
+Suspected cause: SameSite=Strict cookie attribute blocks cross-origin redirect
+Environment: only Safari 17+; Chrome and Firefox unaffected
+Expected: reproduce, fix, add regression test, document root cause
+```
+
+**RU:**
+```
+/development-cycle-workflow PROJ-198 "Фикс: сессия пользователя немедленно истекает после логина в Safari"
+
+Баг: пользователи в Safari 17 выходят из системы сразу после успешного входа.
+Наблюдение: редирект на /login происходит через 2 секунды после перехода на /dashboard
+Предполагаемая причина: атрибут SameSite=Strict блокирует cross-origin редирект
+Среда: только Safari 17+; Chrome и Firefox не затронуты
+Ожидание: воспроизвести, исправить, добавить regression test, задокументировать причину
+```
+
+---
+
+## Example 3 — Chore / Quick task
+
+**EN:**
+```
+/development-cycle-workflow PROJ-201 "Upgrade pydantic from 1.x to 2.x"
+
+Scope: migrate all Pydantic models in src/ to v2 syntax.
+Key changes: BaseModel.dict() → .model_dump(); validators use @field_validator; orm_mode → from_attributes.
+Constraints: no behavior changes; all existing tests must pass after migration.
+```
+
+**RU:**
+```
+/development-cycle-workflow PROJ-201 "Обновить pydantic с 1.x до 2.x"
+
+Скоуп: мигрировать все Pydantic модели в src/ на синтаксис v2.
+Ключевые изменения: BaseModel.dict() → .model_dump(); валидаторы через @field_validator; orm_mode → from_attributes.
+Ограничения: без изменений поведения; все существующие тесты должны пройти после миграции.
+```

package/areas/software/general/prompts/project-setup-workflow.md

@@ -0,0 +1,93 @@
+---
+workflow: project-setup-workflow
+---
+
+# Prompt: `/project-setup-workflow`
+
+Use when: bootstrapping a new project from scratch with proper tooling, CI, and conventions.
+
+---
+
+## Example 1 — Python API service
+
+**EN:**
+```
+/project-setup-workflow "Notifications Service"
+
+Language/framework: Python 3.12 + FastAPI
+Database: PostgreSQL (via SQLAlchemy async)
+Message queue: Redis (for background job queue)
+Team: 3 developers, mono-repo style, GitHub
+CI: GitHub Actions
+Conventions: conventional commits, squash merge, main branch protected
+First milestone: REST API for creating and delivering email/push notifications
+```
+
+**RU:**
+```
+/project-setup-workflow "Сервис уведомлений"
+
+Язык/фреймворк: Python 3.12 + FastAPI
+База данных: PostgreSQL (через SQLAlchemy async)
+Очередь сообщений: Redis (для очереди фоновых задач)
+Команда: 3 разработчика, mono-repo стиль, GitHub
+CI: GitHub Actions
+Соглашения: conventional commits, squash merge, защита ветки main
+Первый milestone: REST API для создания и доставки email/push уведомлений
+```
+
+---
+
+## Example 2 — TypeScript monorepo
+
+**EN:**
+```
+/project-setup-workflow "E-commerce Monorepo"
+
+Language: TypeScript (strict mode)
+Structure: Turborepo monorepo — apps/web (Next.js), apps/api (Fastify), packages/shared-types
+Database: PostgreSQL + Prisma
+CI: GitHub Actions with parallel jobs per workspace
+Code quality: ESLint + Prettier + Husky pre-commit hooks
+Testing: Vitest for unit, Playwright for E2E
+Branch strategy: feature branches → main, no develop branch
+```
+
+**RU:**
+```
+/project-setup-workflow "E-commerce Monorepo"
+
+Язык: TypeScript (strict mode)
+Структура: Turborepo monorepo — apps/web (Next.js), apps/api (Fastify), packages/shared-types
+База данных: PostgreSQL + Prisma
+CI: GitHub Actions с параллельными jobs для каждого workspace
+Качество кода: ESLint + Prettier + Husky pre-commit hooks
+Тестирование: Vitest для unit, Playwright для E2E
+Стратегия веток: feature branches → main, без develop ветки
+```
+
+---
+
+## Example 3 — Minimal / Quick start
+
+**EN:**
+```
+/project-setup-workflow "Internal Admin Tool"
+
+Stack: Python + Flask (simple, no async needed)
+No Docker required — runs locally with sqlite for now
+CI: GitLab CI, basic lint + test pipeline
+Pre-commit: trailing whitespace, end-of-file, ruff
+Just needs: Makefile, README, .gitignore, basic CI
+```
+
+**RU:**
+```
+/project-setup-workflow "Внутренний административный инструмент"
+
+Стек: Python + Flask (простой, async не нужен)
+Docker не требуется — локально с sqlite на данный момент
+CI: GitLab CI, базовый pipeline lint + test
+Pre-commit: trailing whitespace, end-of-file, ruff
+Нужно только: Makefile, README, .gitignore, базовый CI
+```

package/areas/software/general/rules/code-style-guide.md

@@ -0,0 +1,31 @@
+---
+trigger: always_on
+glob: code-style-guide
+description: language-agnostic code style principles for readable and maintainable code
+---
+
+# Code Style Rule
+
+**Rules:**
+
+- **Naming:** Use meaningful, intention-revealing names. Avoid abbreviations except well-known ones (`id`, `url`, `http`).
+- **Functions:** Single responsibility — one function does one thing. Maximum ~30 lines; extract if longer.
+- **DRY:** Do not Repeat Yourself — extract duplicated logic into shared utilities.
+- **Comments:** Code should be self-documenting. Comments explain *why*, not *what*. Remove commented-out code.
+- **Magic values:** No magic numbers or strings — use named constants or enums.
+- **Error handling:** Handle errors explicitly; never silently swallow exceptions.
+- **Immutability:** Prefer immutable data structures where possible.
+- **Depth:** Avoid deeply nested code (>3 levels); use early returns/guard clauses.
+- **File size:** No file over ~400 lines; split into modules if larger.
+- **Consistency:** Follow the existing style of the codebase for the language in use.
+- Follow language-specific style guides:
+  - Python: PEP 8
+  - JavaScript/TypeScript: Airbnb or Standard JS
+  - Go: Effective Go
+
+**Violations:**
+
+- Single-letter variable names outside of loop indexes.
+- Functions with more than one level of abstraction mixing.
+- Hardcoded configuration values in source code.
+- TODO comments left in production code for more than one sprint.