deckhouse · nervgh · May 28, 2026
diff --git a/.agents/skills/review-multi/SKILL.md b/.agents/skills/review-multi/SKILL.md
@@ -0,0 +1,63 @@
+---
+name: review-multi
+description: Multi-role code review for the Deckhouse Delivery Kit. Orchestrates technical, product, and risk analysis roles into a single consolidated report. Use when asked to do a full review of a pull request, branch, or code changes.
+---
+
+# Multi-Role Code Review
+
+Orchestrate a multi-role code review of changes in the Deckhouse Delivery Kit project. Three reviewer roles — technical, product, and risk — each evaluate the changes from their perspective. Follow the workflow below, loading the specialist skills (review-tech, review-product, review-risk) for the detailed methodology of each role.
+
+## Workflow
+
+### Phase 1: Preparation
+
+1. Ask the user for DoD (Definition of Done) — numbered acceptance criteria that all reviewers will use to evaluate the changes.
+2. Obtain `git diff main...HEAD` to see the changes introduced in the current branch.
+3. Analyze the diff: identify modified files, type of change (feature/fix/refactor/docs), patterns, and areas of concern.
+4. Perform deep analysis of the affected code: read the changed files and their consumers, search for symbol usages, understand the context of changed packages.
+
+### Phase 2: Technical Reviewer Role
+
+Activate the **Technical Reviewer** role using the **review-tech** skill. Evaluate code quality, architecture, and adherence to best practices. Provide the skill with the git diff, codebase analysis, and DoD criteria.
+
+### Phase 3: Product Reviewer Role
+
+Activate the **Product Reviewer** role using the **review-product** skill. Evaluate DoD alignment, user impact, completeness, and product consistency. Provide the skill with the git diff, codebase analysis, and DoD criteria.
+
+### Phase 4: Risk Analyst Role
+
+Activate the **Risk Analyst** role using the **review-risk** skill. Identify technical, security, UX, and operational risks. Provide the skill with the git diff, codebase analysis, DoD criteria, and the findings from both the Technical Reviewer and Product Reviewer.
+
+### Phase 5: Final Report
+
+1. Determine the current git branch name.
+2. Combine all findings into a single risk analysis table. Use the risk analyst's table as the base and enrich it with context from the technical and product reviews — add new risks, merge related ones, and ensure all concerns from all phases are captured. Every row must have a specific location.
+3. Assemble the final report with this structure, then save to `reviews/<branch-name>/REVIEW.md`:
+
+```markdown
+## Expert Opinions
+- Technical Reviewer: [2-3 sentence key finding in the user's language]
+- Product Reviewer: [2-3 sentence key finding in the user's language]
+- Risk Analyst: [2-3 sentence key finding in the user's language]
+
+## Risk Analysis Table
+| Risk | Type | Probability | Location | Circumstances | Consequences |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| ... | Technical/UX/Security/Operational | Low/Medium/High | file:line or component | (User Language) | (User Language) |
+```
+
+## Gotchas
+
+- **werf** uses [werf/nelm](https://github.com/werf/nelm) as its deployment engine — evaluate against nelm-specific patterns, not generic Helm.
+- **Content-based tagging** is used for container images. Tag logic affects cache invalidation and registry cleanup.
+- **Registry cleanup** is a unique werf feature. Changes to cleanup logic can cause data loss. Users rely on dry-run modes.
+- The `Taskfile.dist.yaml` uses **remote taskfiles**. All build/test commands run through `task`, never raw Go tools.
+- werf is a **CLI tool** — command-line UX, error messages, and help text are part of the product.
+- nelm is an **engine, not a standalone tool** — changes to nelm behavior affect all werf deployments.
+- The **risk analysis table** is the final summary. Do NOT add prose after it.
+
+## Language Rules
+
+- Communicate with the user in their language (e.g., Russian if they write in Russian).
+- Report headers MUST be in English.
+- The Circumstances and Consequences columns in the risk table MUST be in the user's language.
diff --git a/.agents/skills/review-product/SKILL.md b/.agents/skills/review-product/SKILL.md
@@ -0,0 +1,46 @@
+---
+name: review-product
+description: Product review for Deckhouse Delivery Kit changes. Assesses DoD alignment, user impact, completeness, and consistency with werf/nelm product behavior. Use alongside technical review for a full picture.
+---
+
+# Product Review
+
+Assess whether code changes fulfill product requirements from a user and product perspective. Focus on what matters for werf and nelm users.
+
+## Gotchas
+
+- **werf is a CLI tool** — command-line UX, error messages, and help text are part of the product. Evaluate flag names, defaults, and output formatting.
+- **nelm is an engine, not a standalone tool** — changes to nelm behavior affect all werf deployments. Breaking changes in nelm ripple through the entire user base.
+- **Registry cleanup is destructive** — changes to cleanup logic must be clearly communicated. Users rely on dry-run modes.
+- **Content-based tagging** — users depend on predictable tag behavior for rollback and caching.
+
+## Review focus
+
+1. DoD alignment: are all criteria met?
+2. User impact: CLI UX, error messages, breaking changes?
+3. Completeness: edge cases handled (dry-run, force, conflicting flags)?
+4. Consistency: matches existing werf conventions?
+5. Documentation: changelog, help text, or docs needed?
+
+## Output format
+
+### Product Review Summary
+
+[2-3 sentence expert opinion in the user's language]
+
+### DoD Criteria Assessment
+
+| Criteria | Met? | Evidence |
+| :--- | :--- | :--- |
+| [Criterion] | ✅/⚠️/❌ | specific evidence from diff |
+
+### Product Impact
+
+- **Positive**: what works well
+- **Concerns**: user confusion or friction
+- **Gaps**: missing functionality or edge cases
+
+## Constraints
+
+- Content in the user's language. Headers in English.
+- Do NOT evaluate code quality — that is the tech reviewer's role.
diff --git a/.agents/skills/review-risk/SKILL.md b/.agents/skills/review-risk/SKILL.md
@@ -0,0 +1,44 @@
+---
+name: review-risk
+description: Risk analysis for Deckhouse Delivery Kit changes. Identifies technical, security, UX, and operational risks based on technical and product review outputs. Produces a risk analysis table.
+---
+
+# Risk Analysis
+
+Identify and assess risks based on the technical review, product review, and the actual diff. The output is a single table. No prose summary.
+
+## Methodology
+
+1. Identify risks from: engineering principles, tech review findings, product review findings, and the diff.
+2. Assess probability: **Low** / **Medium** / **High**.
+3. Pin exact location: file:line or component name.
+4. Describe circumstances (when the risk manifests) in the user's language.
+5. Describe consequences (system/user/process impact) in the user's language.
+
+## Risk types
+
+- **Technical**: architecture, performance, maintainability, testability
+- **Security**: vulnerabilities, privilege escalation, data exposure
+- **UX/Product**: user confusion, incomplete features, breaking changes
+- **Operational**: deployment issues, monitoring gaps, failure modes
+
+## Gotchas
+
+- Registry cleanup risks are **Operational** type — data loss is the consequence.
+- Breaking changes in nelm are **UX/Product** type — they affect all deployments.
+- Missing observability is **Technical** type — hard to debug in production.
+- Table is the FINAL output. No summary after it.
+
+## Output format
+
+### Risk Analysis Table
+
+| Risk | Type | Probability | Location | Circumstances | Consequences |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| ... | Technical/UX/Security/Operational | Low/Medium/High | file:line or component | (User Language) | (User Language) |
+
+## Constraints
+
+- Headers in English. Circumstances/Consequences in user's language.
+- Every risk must have a specific location.
+- NO textual summary after the table.
diff --git a/.agents/skills/review-tech/SKILL.md b/.agents/skills/review-tech/SKILL.md
@@ -0,0 +1,66 @@
+---
+name: review-tech
+description: Technical code review for changes in the Deckhouse Delivery Kit. Evaluates Go, werf, Docker, Container Registry, and nelm code against SOLID/DRY/KISS principles and project conventions. Use when asked to review pull requests, branches, or code changes.
+---
+
+# Technical Review
+
+Review code changes for quality, architecture, and best practices. Focus on what the agent would not know without project context: the specific technology stack (Go, werf, Docker, nelm) and how principles apply to this codebase.
+
+## Gotchas
+
+- This project is built on top of **werf**, which uses [werf/nelm](https://github.com/werf/nelm) as its deployment engine. Do NOT evaluate against generic Helm best practices — evaluate against nelm-specific patterns.
+- The project uses **content-based tagging** for container images. Tag logic matters for cache invalidation and registry cleanup.
+- **Registry cleanup** is a unique werf feature. Changes to cleanup logic can cause data loss if wrong.
+- The `Taskfile.dist.yaml` uses **remote taskfiles**. All build/test commands run through `task`, never raw Go tools.
+
+## Methodology
+
+Evaluate changes against these principles, referencing specific file:line in the diff:
+
+| Principle | What to check |
+| :--- | :--- |
+| SOLID | SRP per type, OCP for extensibility, ISP for interface size. |
+| DRY | Duplicated logic, config, or error handling. |
+| KISS/YAGNI | Unnecessary abstraction, generics, or interfaces for hypothetical needs. |
+| Security | Least privilege, input validation, secret handling, container security. |
+| Observability | Logs/metrics for critical paths, especially deploy and registry operations. |
+| Testability | Can the change be tested without mocks or integration setup? |
+
+## Input
+
+The coordinator provides: git diff, codebase analysis, DoD criteria.
+
+## Output format
+
+### Technical Review Summary
+
+[2-3 sentence expert opinion in the user's language]
+
+### Adherence to Best Practices
+
+| Practice | Status | Comments |
+| :--- | :--- | :--- |
+| SOLID | ✅/⚠️/❌ | file:line — one-liner |
+| DRY | ✅/⚠️/❌ | ... |
+| KISS/YAGNI | ✅/⚠️/❌ | ... |
+| Security | ✅/⚠️/❌ | ... |
+| Observability | ✅/⚠️/❌ | ... |
+| Testability | ✅/⚠️/❌ | ... |
+
+### DoD Criteria Assessment
+
+| Criteria | Met? | Comments |
+| :--- | :--- | :--- |
+| [Criterion] | ✅/⚠️/❌ | file:line reference |
+
+### Issues Found
+
+- **Critical**: blocking, with file:line
+- **Major**: significant concern
+- **Minor**: suggestion
+
+## Constraints
+
+- Issue descriptions in the user's language. Headers in English.
+- Reference specific lines. No obvious comments.