molyanov-ai-dev: Skill for Codex

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. Discuss the approach before editing only when evidence exposes a substantive fork, risk, or scope decision. Otherwise choose the smallest safe implementation that follows project or framework conventions.
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. When the change can alter observable behavior, apply test-master to select and run the protecting tests. If it has no test subject, state that instead of creating 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.