ry-start

name	ry-start
description	Полный lifecycle задачи: init→research→plan→implement→quality gates→post-task sync; ревью только по явному запросу. Используй для: /rldyour-flow:ry-start, реализуй, доработай, исправь качественно, сделай задачу, реализуй фичу. EN triggers: full SDLC, implement task, build feature, complete lifecycle; explicit review only.
argument-hint	<task description>

ry-start

Purpose

Implement a task to a high-quality, scalable, synchronized state. Speed is secondary to correctness, consistency, maintainability, and clean git history.

Workflow

1. If context is missing, run a scoped ry-init automatically.
2. Understand the prompt. For ambiguity, ask concise Russian questions with options.
3. Research current code through Serena memories and semantic tools.
4. Research current docs, patterns, and alternatives through rldyour-explore.
5. Read ${CLAUDE_PLUGIN_ROOT}/references/context-sufficiency-gate.md and pass the gate before editing code.
6. Write a detailed plan. Verify each plan item against code using Serena before editing.
7. Create or use a feature branch/worktree. Use stacked PRs only when the task naturally splits into independent logical PRs.
8. Implement strictly by plan, adapting only after code evidence. Make frequent atomic Conventional Commits.
9. Provide progress checkpoints after meaningful milestones or every 2-3 completed plan groups.
10. Fix all issues in touched scope plus affected integration path. If wider technical debt is found, ask whether to expand scope.
11. Run quality gates using project scripts, rldyour-lsps, and detected stack checks.
12. Trigger browser validation for UI/browser-visible work unless auth blocks it; if auth blocks, report the limitation and use available evidence.
13. Apply security implementation guidance for security-sensitive changes; run security review only when the owner explicitly asks for review/audit/security review.
14. Run reviewer subagents only when the owner explicitly asks for review, audit, security review, rules review, or ry-review; otherwise skip the expensive review phase.
15. Run flow-post-task-sync before final response.

Deploy Intent Routing

If the user request includes deploy, production, server rollout, sync-and-deploy, or a named deployment target, do not finish after implementation. After code validation and Serena/docs sync, route into ry-deploy with the same scope and target. If the deploy contract is incomplete, ask for the missing server, branch, environment, health-check, rollback, or credential decision before deploying. Never invent server access or deployment targets.

Automatic Helper Routing

The user normally invokes only rldyour-flow commands and writes prompts in Russian. ry-start must route helper skills automatically instead of waiting for explicit helper skill names:

• Repository/code scope: use serena-code-workflow, lsp-routing, quality-first-engineering, and implementation-discipline for изучи код, посмотри проект, реализуй, доработай, исправь, рефакторинг, ревью, архитектура, файлы, директории, symbols, or implementation scope.
• Internet or best-practice research: for technical prompts such as исследуй интернет, изучи в интернете, посмотри документацию, best practices, migration, API behavior, framework/library setup, or MCP/tool sources, use tech-research first with Context7, DeepWiki, and Grep by Vercel. Add web-research when the prompt asks for internet/current/latest/source-backed information or when sources beyond the three MCPs are needed.
• Browser-visible work: use browser-tool-routing and browser-validation for проверь в браузере, визуально, UI, адаптив, скриншот, pixel-perfect, user flow, or business-logic checks. Use browser-debug for console, network, runtime, layout, hydration, Lighthouse, performance, and browser-only failures.
• Design/frontend UI work: use ry-design, figma-to-code, design-system-implementation, fsd-frontend-architecture, and design-validation when the task mentions Figma, дизайн, UI, верстка, дизайн-система, shadcn/ui, ReactBits, FSD, tokens, or pixel-perfect design.
• Security-sensitive work: use owasp-top-10-implementation during auth/authz/API/input/file/dependency/config/secrets/payment/admin/external-integration work. Use ry-sec-review and flow-security-review only for explicit security-review requests.
• Explicit review requests: when the prompt asks for review, audit, ry-review, ry-sec-review, ry-rules-review, reviewer subagents, or rules/security review, route the matching reviewer tracks. A normal ry-start implementation request is not review permission.
• Verification and finish: use verification-quality-gates, serena-memory-sync, and flow-post-task-sync before final delivery when the task produced durable code, config, docs, plugin, memory, hook, or workflow changes.

Context Sufficiency

Do not implement from a shallow prompt. Before editing, the model must know the relevant architecture, files, symbols, DB/schema/API/config contracts, tests, integration paths, current project patterns, and current external API/framework guidance needed for the task.

If the model cannot answer the gate questions in ${CLAUDE_PLUGIN_ROOT}/references/context-sufficiency-gate.md, it must gather more evidence through Serena, LSP, rldyour-explore, browser/security/design workflows, or ask the user with options. This is a quality guard, not a hard blocker: the correct response is to enrich context until implementation is safe.

Reviewer Opt-In

Invoking ry-start alone is not permission to use parallel reviewer subagents. Reviewer agents (flow-architecture-review, flow-quality-review, flow-consistency-review, flow-integration-review, flow-verification-review, flow-security-review) are orchestrated only by explicit review intents such as ry-review, ry-sec-review, ry-rules-review, "сделай ревью", "security review", or "аудит". Reviewer prompts must be self-contained and read-only.

Review Phase Output Transport

When explicit review was requested, reviewer subagents follow the file-first output contract in ${CLAUDE_PLUGIN_ROOT}/references/reviewer-protocol.md (section "Output Transport"). The orchestrator (this skill body, executed by the main session model) is responsible for the run-level coordination:

1. Generate one run_id per review wave in the form <UTC-ISO-compact>-<git-short-sha>. Example: 2026-05-16T1433Z-91cc276 (minute-precision timestamp prevents collisions when two waves run in the same hour). Use the same run_id for all reviewers in the wave so their reports land in the same directory.
2. Compute report_dir = .serena/reviews/<run_id>/ (relative to repo root). .serena/reviews/ is gitignored by repo policy and treated as runtime artefact (.serena/cache/, .serena/diagnostics/ follow the same pattern). Create it once with mkdir -p before dispatching reviewers, or let the first reviewer create it - both are safe because mkdir -p is idempotent.
3. Inject run_id and report_dir into every reviewer prompt, alongside scope, diff, constraints, expected reviewer-protocol citation, and read-only reminder. Without these fields each reviewer derives safe defaults, but explicit values keep the wave consistent.
4. After all reviewers complete, read each compact summary from the agent result. Aggregate Counts: across tracks. Identify the critical/high findings that need synthesis.
5. Must read each per-reviewer report file via Read for every critical and high finding before deciding disposition; flow-security-review carries Category (OWASP/ASVS), Attack path, and Verification fields that exist only in the report file. Medium and low findings may be read on demand when consolidation requires deeper evidence; reports without any findings can be skipped.
6. Resolve contradictions between reviewer tracks against code evidence (Serena find_symbol, find_referencing_symbols).
7. Write a consolidated <report_dir>/_summary.md with cross-track findings, plan disposition (must-fix / should-fix / defer / false-positive), and the chosen fix order. Required whenever any track reported one or more findings. This file is the durable wave artefact - useful for the user to inspect and for flow-post-task-sync to reference.
8. Report back to the user in Russian. List the report-file paths so the user can inspect full findings on disk. Quote no more than the top critical/high entries inline; everything else stays in the files.

Rationale: Claude Code 2.0.77+ has a confirmed task.output regression (Anthropic issues #16789, #20531, #23463, all closed as "not planned") that can deliver up to 200-500 KB of JSONL transcript per subagent to the parent session, with combined subagent results capable of overflowing the parent context and crashing the session. Capping each reviewer at a 4 KB summary while preserving full evidence on disk structurally prevents that failure mode.

Non-Negotiables

• No hacks, temporary workarounds, or untracked debt in touched scope.
• No fake green checks. If a check cannot run, say why.
• No silent destructive git actions. Branch/worktree cleanup requires verified merged state.
• No secrets in commits, logs, docs, memories, or prompts.

Anti-patterns

• Implement без passing context-sufficiency gate.
• Run reviewer fan-out without an explicit user review request.
• Skip browser validation для UI changes без явного auth-blocker reasoning.
• Force-push продуктовых веток.
• Commit без Conventional Commits format.
• Final delivery без flow-post-task-sync.