project-vendor-boundary

Project overlay for checked-in or submodule-managed third-party source, provenance, local patches, and the app-owned integration seam. Not for package-manager dependency changes without vendored source.

Jump to install

Repository: n-n-code/n-n-code-skills
Last source activity: August 19, 2026 at 08:08
Detected SKILL.md language: English
Stars: 4
Forks: 0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/n-n-code/n-n-code-skills --skill project-vendor-boundary

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

Project Vendor Boundary

This is a composable project overlay. Add matching implementation guidance when the work requires language-specific code judgment.

When to use

The change involves checked-in third-party source, a subtree or submodule, a vendor directory, copied sources, a local vendor patch, or the app-owned adapter around that material.

Not for

Do not use this for ordinary package-manager version or lockfile changes with no checked-in third-party source, app-owned code unrelated to the integration seam, or generated outputs that must be changed through their generator. Use project-release-maintainer for release concerns and compose it only when a vendor change also affects shipped metadata. Use security first when exploit review is the primary job.

Workflow

Classify the material before editing: app-owned source, checked-in vendor source, submodule, generated output, or package-managed dependency. Read the repository's update instructions, provenance record, patch convention, and license or notice files when they exist.

Prefer an adapter or wrapper change in app-owned code when the integration seam can reasonably absorb it. Patch vendor source only when the seam cannot solve the problem without distorting the app contract.

Keep vendor patches minimal. Avoid unrelated formatting, generated churn, mass mechanical rewrites, or local style normalization inside the vendor tree. Record the upstream source or base version and patch rationale using the repository's existing convention.

Validate the app-owned seam and the narrowest relevant vendor build or test path the repo supports. Inspect the final diff for accidental vendor churn.

Update notices, provenance, upstream version, local patch records, install rules, or shipped metadata only when the vendor change affects them; do not rewrite these files for an app-only adapter change.

Treat fetching or replacing upstream source, moving a submodule, and filing an upstream issue or contribution as separate actions with their own network and external side effects. Do not edit generated vendor artifacts manually when a documented regeneration path owns them.