Prepare Code Contributions That a Human Reviews and Submits

## Follow the Repository's Rules and Wait for Maintainer Approval Treat the repository's contribution guide, artificial-intelligence policy, and directory-specific agent instructions as the governing sources for the files being changed. ### Resolve Applicable Rules - Read the root contribution and safety policies before editing. - When entering a specialized directory, also apply its local instructions for runtime behavior, public interfaces, integrations, documentation, or tests. - If instructions conflict, stop and surface the conflict instead of choosing whichever rule makes implementation easier. - Use optional agent skills only when the client supports them and they do not override repository policy. ### Approval Gates - Do not submit issues, pull requests, or draft pull requests through browser automation, command-line hosting tools, or service APIs. - Draft submission text for a human to review and send, using the repository's templates so it is ready to paste. - Do not push branches or prepare public-submission materials until the relevant issue is triaged and assigned to the human contributor. - Do not implement a non-trivial feature, public-interface change, refactor, or behavior change without recorded maintainer direction. Stop at a proposal when direction is missing. ## Keep Secrets Out of Commits and Live Services Out of Tests Protect credentials, evidence quality, repository history, and test isolation throughout the task. ### Non-Negotiable Rules - Never commit secrets, credentials, private provider data, or sensitive environment values. - Never fabricate test results, approvals, citations, review status, or compatibility claims. - Unit tests must not contact live model, provider, or external application services. - Use deterministic substitutes and an environment that removes live-service credentials from test processes. - Do not add generated media, large generated assets, or synthetic datasets without clear provenance and maintainer agreement. - Do not add license headers manually when repository automation owns license insertion. - Do not add comments unless requested; preserve existing comments, docstrings, and license headers unless the change makes them inaccurate. ### Protected Files Do not manually edit changelogs, generated files, lockfiles, validation snapshots, or other tool-owned artifacts unless the task explicitly requires the repository's regeneration workflow. Put release-note context in a proposal or submission draft when changelogs are generated. ## Change Dependencies Only When Needed and Use the Pinned Tools Use the project's canonical locked environment and task commands rather than improvising alternate execution paths. ### Dependency Changes - Do not add or update dependencies unless the task requires it. - For temporary investigation, use an isolated environment that does not modify committed dependency state. - When a dependency change is necessary, place it in the narrowest suitable dependency group or optional feature set. - Add clear compatibility bounds and avoid moving optional integrations into the default installation path. - Keep dependency and lockfile changes separate from unrelated edits. ### Tooling - Use the repository's pinned runtime and tool versions for installation, tests, documentation, formatting, and static analysis. - Distinguish authoritative validation commands from diagnostic commands. A standalone linter or type checker may aid diagnosis but does not replace the repository's required pre-commit or validation path. - Treat scripts that perform broad staging, commits, or repository-wide checks as high-impact tools; run them only when explicitly required and preferably in a clean worktree. ## Pick the Tests That Match the Type of Change Select the minimum sufficient validation from the actual change type, then broaden only when shared behavior or compatibility risk justifies it. ### Validation Matrix - Documentation or repository metadata: run checks on changed files; build documentation when rendering, links, examples, or documentation configuration may be affected. - Runtime bug fix: add or run a focused regression test, then run required checks on changed files. - Public interface, configuration, or language behavior: run focused tests and update related documentation or examples; add broader package tests when compatibility risk is meaningful. - Server, streaming, tracing, action, or generation path: test the changed path and its fallback or unsupported path. - Packaging, dependency, or lockfile change: run the relevant installation or packaging checks and keep the dependency diff isolated. ### Scope and Isolation - Know what the canonical full-suite command includes; do not assume it covers only the most obvious test directory. - Prefer the test entry point that removes live-provider credentials and supplies deterministic substitutes. - Diagnose isolation-related flakiness by comparing the normal parallel run with a deterministic serial run under the same environment safeguards. - Treat slow or serial markers as advisory unless the test runner actually enforces them. - Do not use a convenient alternate test command if it can retain live credentials or bypass required test paths. ### Handoff Evidence For a change intended for review, run authoritative pre-commit checks before handoff so formatting, license, and type-checking results are stable. Report any required check that was skipped and why. ## Check for Duplicate Work and Answer Every Review Comment Keep public contribution activity traceable to approved work and avoid duplicating effort. ### Before Implementation - Confirm the issue is triaged, assigned, and supported by an agreed approach for non-trivial work. - Before preparing review-shaped work, use read-only searches to check the issue discussion, open changes referencing the issue, and open changes in the same area. - If an open change already covers the work, do not prepare a duplicate. If the approach differs materially, explain the difference in a draft for the issue discussion. - For exploratory work, draft an issue comment describing the branch and relevant files instead of opening a public change request. ### Submission and Review - Follow the repository's title and commit conventions. - Do not add artificial-intelligence markers to titles or commit messages, and do not add tools or agents as commit co-authors. - Address or reply to every open review comment before requesting maintainer review. - Do not resolve another reviewer's thread on their behalf or apply readiness labels to your own change unless policy explicitly allows it. - Treat automated and human review findings as claims to verify against the real code path, not as automatically correct instructions. ## Update the Docs When User-Visible Behavior Changes Keep documentation synchronized with user-visible behavior and avoid presenting narrow examples as universal support. ### Documentation Duties - Update relevant documentation when changing public interfaces, configuration syntax, examples, installation requirements, or other user-visible behavior. - For optional integrations, state that they are optional, identify required packages or feature groups, list expected credential types without exposing values, and explain the integration route. - For model or provider examples, state the model type, routing mode, supported modes, and known limitations. - Verify that identifiers presented as current are generally available through an authoritative source. - Do not change shipped default parameters merely as part of a documentation update. ### Refactors and Generated Content - For an approved refactor, add or update characterization tests before changing subtle behavior. - When existing tests do not cover the refactored path, retain the equivalence check used to prove behavior remains unchanged. - Do not hand-edit generated documentation or generated artifacts; use the project workflow only when the task authorizes regeneration. - Do not run documentation builders known to stage files or trigger broad checks unless explicitly requested and isolated from unrelated changes. ## Review Against the Merge Base and Report Only What Was Verified Review the completed change against the correct baseline and verify every claim before declaring it ready. ### Review Sequence 1. Compare the branch against the repository's configured merge base. 2. Inspect both the implementation and the tests that exercise it. 3. Run authoritative formatting, linting, license, and type checks before structured review so line locations remain stable. 4. Perform a structured code review and add a security pass for authentication, input handling, deserialization, or external-call changes. 5. Verify each finding against the actual execution path. 6. Correct confirmed findings, rerun affected validation, and repeat review until no confirmed issue remains. ### Completion Standard Report the files changed, validation performed, results observed, skipped checks, unresolved risks, and any human action still required. Do not claim review readiness, approval, compatibility, or successful validation without direct evidence.