molyanov-ai-dev: Skill for Claude Code

Code Writing

Understand the Change

1. Extract the requested behavior and what done means from the request or user-spec. Resolve ambiguity from repository evidence; ask only when a substantive choice changes the result or scope.
2. Read repository instructions, affected code, its usages, and only the project documentation needed to change it safely. A localized edit needs local context; cross-cutting work needs its contracts, architecture, and relevant patterns.
3. For non-trivial work, read every source file that will change, find affected contracts and reusable code, and establish the smallest useful baseline check. Inspect generated, lock, snapshot, or other mechanical artifacts through their generator, relevant diff, and deterministic validation rather than an unhelpful full read.
4. Before editing non-trivial work not covered by an approved user-spec or user-approved plan, briefly explain in simple user-facing language how the result will work end to end and why this is the simplest sufficient approach, then wait for approval.
5. Treat a new idea, risk, edge case, or opportunity discovered during implementation or review as a proposal, not authorization. A rare or unagreed scenario is a user decision even when its correction looks local. Correct autonomously only an authorized local defect in agreed normal behavior; ask before adding behavior, state, entities, contracts, dependencies, architecture, or material complexity.

Implement and Verify

1. Implement only the requested behavior. Reuse existing capabilities before adding abstractions or dependencies. Do not add speculative validation, fallbacks, configuration, optimization, or future flexibility without a current requirement or realistic project condition.
2. Validate untrusted input at its boundary, keep secrets out of source, preserve useful error information, and handle failures where the program can recover or add context.
3. Let straightforward code explain itself. Comment only when code cannot communicate the reason for a business rule, safety invariant, external constraint, compatibility workaround, deliberate tradeoff, or required ordering.
4. Apply test-master only to deterministic executable behavior or another explicit deterministic contract. For LLM-produced results, presentation-only layout, or freely editable copy, use agent, manual, or visual verification instead. If there is no test subject, do not create artificial assertions.
5. Run the smallest supported lint, format, type, build, render, and user-requested checks that cover the change. Use a project-wide command only when it is the available entrypoint or the change is cross-cutting. Separate unrelated baseline failures from regressions.