project-vendor-boundary
Project Vendor Boundary
This is a composable overlay, not a standalone workflow. Use alongside the repo's implementation skill when work touches vendored dependencies or their integration boundary.
When to use
The change involves vendored third-party code, the boundary between app-owned and vendored code, or dependency integration (subtrees, vendor directories, copied sources).
Not for
App-owned code that does not touch vendor boundaries (use the implementation skill directly), or release/packaging concerns (use project-release-maintainer).
Rules
- prefer app-side integration changes before editing vendored code
- treat vendored code as subtree/vendor content, not normal project code
- keep notices, provenance, upstream version/source, local patch rationale, and install rules aligned with vendor changes
- prefer adapter or wrapper changes in app-owned code before patching vendored sources; patch vendor code only when the seam cannot reasonably absorb the change
- avoid unrelated churn inside vendor trees
More from n-n-code/n-n-code-skills
coding-guidance-cpp
C++ implementation and review skill. Use when writing, modifying, refactoring, or reviewing C++ code, especially modern C++17/20/23 code that needs strong ownership, type safety, and testable design. Portable across C++ repos and build systems.
18project-platform-diagnose
Overlay for environment-sensitive diagnosis — service startup, install issues, platform integration, headless/container behavior, and runtime smoke checks. Portable across repos where build, install, or runtime behavior depends on the local platform.
18documenter
Baseline overlay for substantial documentation authoring or restructuring: README, specs, ADRs, tutorials, how-to guides, reference docs, explanations, API docs, code comments, changelogs, and agent-facing docs. Use when the agent should classify doc type, ground claims in repo truth, and validate examples before finishing.
18security
Security workflow skill for repo-grounded threat modeling, exploit-focused security review, and secure-by-default implementation guidance. Use when the user explicitly asks for security work, or when security properties are the primary concern in a high-risk change. Do not trigger for ordinary code review, routine endpoint work, or general backend implementation just because a repo contains APIs, auth, or secrets.
18project-release-maintainer
Overlay for release-facing docs, install layout, workflows, licenses, and hygiene scripts. Portable across repos with a release/packaging pipeline. Use for publication-facing changes.
17project-core-dev
Overlay for day-to-day feature work and bug fixes in repo-owned code. Provides a validation checklist for build, test, format, and analysis. Use alongside the repo's principle skill.
17