vdev

name

vdev

description

Apply the user's pragmatic coding discipline and personal Git conventions. Read this Skill before writing, editing, refactoring, fixing, reviewing, generating, or designing code, scripts, tests, configuration, schemas, migrations, or automation, and before choosing dependencies or abstractions. Also use whenever Codex inspects or changes a Git repository, manages branches or commits, pushes to GitHub, rewrites remote history, deletes refs, creates a pull request, handles a dirty worktree, or the user says “记录在案” / “record this” and wants an agreed plan or decision persisted in project documentation. Prevent excessive defensive programming, redundant checking, and unnecessary encapsulation or abstraction while preserving justified complexity, real boundary checks, security, and data-integrity protections.

Vdev

Before any code-writing action, read this Skill and apply the coding gate below. For repository and GitHub remote operations, also use the local Git CLI and the user's existing SSH authentication as the default path.

Proportionate coding gate

Understand the system, then use complexity in proportion to the task:

1. Read the task, repository instructions, relevant files, existing conventions, and the real end-to-end flow before editing. Never propose or change code based on an unread referenced file or an assumed implementation.
2. Implement the requested behavior completely. Do not optimize for the fewest lines or smallest diff when a clearer, more maintainable solution legitimately needs more structure.
3. For a bug, trace the symptom to its root cause and inspect callers and sibling paths. Prefer one fix at the shared cause over repeated symptom guards, but do not broaden into unrelated cleanup.
4. Before adding a guard, validation, fallback, retry, exception translation, compatibility shim, or duplicate check, identify the realistic failure, explicit requirement, real contract, or trust boundary that requires it. If none exists, trust the established invariant and do not add the defense.
5. Validate at actual system boundaries such as user input, external APIs, untrusted files, authentication and authorization, persistence, destructive operations, and unreliable hardware or I/O. Do not repeatedly revalidate data already guaranteed by internal callers, types, frameworks, or an earlier boundary check.
6. Before adding a wrapper, helper, interface, factory, service layer, configuration option, dependency, or new file, identify its present structural value. Keep one-off logic local and avoid indirection created only for hypothetical reuse, configurability, scale, or backwards compatibility.
7. Reuse repository code and patterns, the standard library, native platform features, and already-installed dependencies when they fit. Do not force reuse when it makes the current design less clear or preserves a bad abstraction.
8. Keep changes focused on the requested behavior. Do not add adjacent features, broad refactors, cleanup, or speculative improvements, but include all directly necessary supporting changes.
9. Test in proportion to behavior and risk. Cover meaningful branches and regression paths, especially money, security, migrations, and data integrity; avoid duplicate assertions, exhaustive impossible-state tests, or new test machinery without a concrete need.
10. Preserve explicit contracts: public APIs, persisted data, deployed migrations, external consumers, repository-mandated interfaces, security, accessibility, and protections against data loss. Avoiding overengineering never overrides these constraints or anything the user explicitly requested.

The target is justified complexity: every defense, check, layer, and abstraction should earn its place through current behavior or a real contract. Necessary complexity is welcome; speculative complexity is not.

Non-negotiable defaults

1. Use git for status, diff, staging, commits, branches, fetch, push, force updates, tags, and remote ref deletion.
2. Use SSH for GitHub remotes. Prefer an existing SSH remote; otherwise target [e-mail]:<owner>/<repo>.git without rewriting repository configuration unless requested.
3. Use only the current worktree. Never create another worktree or run git worktree add.
4. Do not create a pull request unless the user explicitly asks for one. A request to push does not imply a PR.
5. Treat every AGENTS.md as local-only unless the user explicitly overrides this rule. Keep it ignored and never stage, commit, or push it.
6. Never list any agent, AI system, or automated assistant as an author or co-author. Do not add agent attribution to commit authorship, Co-authored-by trailers, PR authorship, release metadata, or published acknowledgements.
7. Unless the user explicitly specifies another identity, every commit must use Vinnish-A <[e-mail]> as both author and committer. Before committing, verify user.name and user.email; replace stale repository-local overrides instead of silently inheriting them.
8. Treat the user's personal development repositories as direct-to-main projects: do not create feature branches, draft PRs, branch-protection workflows, or review gates unless the user explicitly asks for them. Only push when the user explicitly declares that the changes should be pushed, uploaded, or published to a remote. When that authorization exists, push the intended changes directly to main unless the user names another ref.
9. Use a GitHub connector only when the user explicitly requests it or the operation is not expressible through Git and no suitable authenticated local CLI path exists.

Working-tree workflow

1. Inspect git status --short --branch, the current branch, remotes, upstream state, and the relevant diff before changing the index.
2. Preserve unrelated tracked and untracked user changes. Stage explicit paths; never use git add -A in a mixed worktree.
3. For personal development repositories, work directly on main and do not create convenience branches. Only use another branch when the user explicitly requests it.
4. Do not treat local lint, tests, or other static checks as a default pre-upload gate. Run them before uploading only when the user explicitly asks or repository instructions explicitly require them; otherwise keep the upload workflow unblocked and report checks only if they were run.
5. Write commit messages in English as concise, relevant puns or light jokes that still accurately describe the full intended diff. If the user requests exact, formal, conventional, or non-humorous wording, follow that instead. Never sacrifice clarity or add attribution merely to make the joke work.
6. Do not push during ordinary implementation, commit, or test work. Treat local commits and user testing as separate from remote publication. Usually wait for the user to test the result and explicitly request the push; completion of the implementation, a request to commit, or a request to run tests is not push authorization.
7. After explicit push authorization, push through SSH to main for personal development repositories unless the user explicitly names another ref.
8. Verify the remote refs and commit after the push, then report the exact branch, SHA, checks, and any preserved local changes.

Changelog closeout for project changes

At the end of every project implementation or build task that changes functionality or user- or developer-visible behavior, update the project's canonical CHANGELOG.md as part of the same task. Do this after the implementation is settled and before staging, committing, pushing, or reporting completion.

This requirement does not apply to general questions or one-off tasks outside a project, writing-only or documentation-only work, repository inspection, diagnosis with no implementation, Git-only operations, or changes with no functional or externally observable effect. Pure refactors, formatting, mechanical maintenance, routine dependency or version bumps, and tests that only cover existing behavior do not need an entry. If one task mixes excluded work with a functional change, document only the functional change.

1. Locate the repository's existing canonical changelog, commonly CHANGELOG.md or docs/CHANGELOG.md, and follow its current heading hierarchy, tone, bullet style, ordering, version notation, and date format. Do not create a second changelog. For a new project or a repository with no changelog, create a root CHANGELOG.md with an Unreleased section unless repository instructions establish another location or convention.
2. Base the entry on the completed diff and actual behavior, not intent or guesswork. Include new features, meaningful behavior changes, and bug fixes that affect reliability, compatibility, supported workflows, or developer experience. Exclude internal implementation detail, formatting noise, and unrelated pre-existing changes.
3. Add the current task to the existing Unreleased section when the project uses one. Otherwise follow the repository's established convention; if no release version has been assigned, add an Unreleased entry rather than inventing a version, tag, or release date. Do not backfill older releases unless the user asks.
4. Keep wording brief, concrete, and consistent with project terminology. Use flat bullets for one to three clear points; add categories such as Features, Improvements, or Bug Fixes only when several distinct items make them useful. Avoid marketing language and do not copy commit or release text verbatim when it is noisy.
5. Verify that the changelog describes only behavior present in the final diff, preserves the local Markdown structure, and is included in the intended task diff. If the implementation was reverted or ultimately produced no qualifying functional change, do not add an entry and remove any provisional one created for it.

Record-on-file requests

When the user says “记录在案”, “record this”, or an equivalent phrase about an agreed plan or decision:

1. Persist the current agreed content in the relevant repository instead of only acknowledging it in chat. Prefer updating an existing authoritative design/decision document; otherwise create a clearly named file under docs/ (or the repository's established documentation directory).
2. Record the decision status, motivation, accepted and rejected directions, affected components, known risks or historical debt, implementation sequence, and measurable validation criteria when those details exist. Preserve distinctions between confirmed decisions, proposals, and work already completed.
3. Keep credentials, tokens, private endpoints, personal data, and other secrets out of tracked documentation. Put production-only topology in local AGENTS.md only when needed, and keep that file untracked under this Skill's existing rule.
4. Treat “记录在案” as authorization to write or update documentation only. It does not authorize implementation, staging, committing, pushing, deployment, branch creation, issue creation, or a pull request unless the user explicitly requests those actions too.
5. Preserve unrelated worktree changes, then report the exact document paths written and whether they are tracked, ignored, or untracked.

Destructive operations

• Require explicit user authorization before force-pushing, deleting remote refs, rewriting history, or replacing the default branch.
• Prefer --force-with-lease for ordinary rewrites. Use an orphan root commit and an explicit forced ref update only when the user asks to treat a repository as empty or discard history.
• Never use git reset --hard, destructive checkout, or file removal to clean unrelated user changes.
• Never print credentials, private keys, tokens, or credential-bearing remote URLs.

Omni manager boundary

When operating on the Omni manager repository, publish only omni-cli, manager-owned documentation, release metadata, tests, and automation. Keep omnischolar, omnisketch, omniplotter, omnievolve, omninetwork, Vaults, and local AGENTS.md out of every remote ref.