out-of-scope

File out-of-scope findings as GitHub issues at the moment they are discovered.

1|Updated Apr 21, 2026
One-click install
npx skills add https://github.com/devbasex/ai-plugins --skill out-of-scope-devbasex
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: out-of-scope
Source: https://github.com/devbasex/ai-plugins/tree/main/plugins/ndf/skills/out-of-scope
Command: npx skills add https://github.com/devbasex/ai-plugins --skill out-of-scope-devbasex

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? During implementation, refactoring, or code review, developers often find defects or improvements that fall outside the current change's scope. Without a defined procedure, these findings get lost, silently ignored, or improperly absorbed into the current change. This Skill captures each finding as a GitHub issue at the moment of discovery, with a clear record of why it was judged out of scope. ## Core Features & Use Cases - Three-way decision framework: Classify each finding as file-an-issue, pull-into-scope, or do-not-file, defaulting to filing when uncertain, and always recording the reasoning. - Duplicate check and structured filing: Search open issues once before creating one, then file with a fixed five-section body (what was found, where, why out of scope, impact, origin) after user confirmation of target repo, body, and labels. - Cross-repository targeting: Resolve whether the issue belongs in the NDF distribution repository or the development repository via a three-stage resolution (environment variable, marketplace clone inspection, then asking the user), detailed in references/issue-target.md. - Traceability: Record the filed issue number back at the origin (PR body, plan file, or review reply) so retrospectives can search all issues spawned from a change. - Use Case: While running a TDD cycle, you notice a bug in an unrelated module. The Skill checks for duplicates, files a structured issue in the correct repository, and links the issue number back into your PR description. ## Quick Start Ask the AI to file this out-of-scope finding as a GitHub issue using the out-of-scope procedure, noting where it was found and why it falls outside the current change.

Frequently Asked Questions about out-of-scope

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I handle a bug found outside my current change scope?▼

Classify the finding with a three-way decision: file it as a GitHub issue, pull it into scope if it shares the same cause and shape, or record why no filing is needed. When uncertain, file the issue since closing later is cheaper than rediscovering it.

How do I avoid creating duplicate GitHub issues for known problems?▼

Run a single search with gh issue list --state open using two or three keywords describing the problem before filing. If a match exists, add a comment noting you observed the same issue during your work instead of creating a new issue.

Which repository should receive an issue when working across two repos?▼

The issue's nature decides: process and Skill procedure problems go to the distribution repository, while code, data, and configuration problems go to the development repository. Issues spanning both are filed in both, distribution repo first, with cross-referenced numbers.

What should an out-of-scope issue report contain?▼

The body requires five sections: what was found with reproducible detail, where it was found, why it falls outside the change's acceptance criteria, what happens if left unfixed, and the origin written as PR #number or issue #number.

When should a review comment be resolved as out of scope?▼

Resolve a review comment as out of scope only after filing an issue and writing the issue number in your reply. Resolving without the number makes the decision indistinguishable from ignoring the feedback.