impacted-scope-enforcement
Skill4 starsChanged 10 months agoMITView on GitHub
Use when user deploys changes, commits code, runs builds/tests, or requests selective validation. Ensures only impacted components are tested/deployed when appropriate, scoping quality gates to modified code.
In this repository67 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agents-onboardingSkill
- agent-workitem-automationSkill
- architecture-testingSkill
- aspire-integration-testingSkill
- automated-standards-enforcementSkill
- best-practice-introductionSkill
- branching-strategy-and-conventionsSkill
- broken-windowSkill
- change-risk-rollbackSkill
- ci-cd-conformanceSkill
- component-boundary-ownershipSkill
- contract-consistency-validationSkill
- csharp-best-practicesSkill
- deployment-provenanceSkill
- documentation-as-codeSkill
- documentation-scaffoldSkill
- dotnet-bespoke-code-minimisationSkill
- dotnet-best-practicesSkill
- dotnet-domain-primitivesSkill
- dotnet-efcore-practicesSkill
- dotnet-healthchecksSkill
- dotnet-logging-serilogSkill
- dotnet-mapping-standardSkill
- dotnet-open-source-first-governanceSkill
- dotnet-source-generation-firstSkill
- dotnet-specification-patternSkill
- dotnet-testing-assertionsSkill
- environment-traceabilitySkill
- finishing-a-development-branch-iddSkill
- greenfield-baselineSkill
- incremental-change-impactSkill
- incremental-deploymentSkill
- innersource-governance-bootstrapSkill
- issue-driven-deliverySkill
- library-extraction-stabilisationSkill
- local-dev-experienceSkill
- markdown-authorSkill
- modern-csharp-coding-standardsSkill
- monorepo-orchestration-setupSkill
- observability-logging-baselineSkill
- pair-programmingSkill
- persona-switchingSkill
- process-skill-routerSkill
- quality-gate-enforcementSkill
- release-tagging-planSkill
- repo-best-practices-bootstrapSkill
- repository-foundation-bootstrapSkill
- requirements-gatheringSkill
- runtime-tooling-validationSkill
- safe-brownfield-refactorSkill
- scoped-colocationSkill
- security-processesSkill
- selective-build-testSkill
- semantic-version-impactSkill
- session-awareSkill
- skills-first-workflowSkill
- static-analysis-securitySkill
- structured-review-workflowSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 33
Apply coverage delta: - Check coverage of modified lines only (not absolute coverage)
- Distinctive: line 35
Preserve critical gates: - Always run architecture tests, security scans
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Impacted Scope Enforcement
Overview
Scope quality gates and deployments to impacted components only. Full-system validation wastes CI resources and delays feedback when only a subset of code changed. Identify impact, scope gates, execute selectively.
REQUIRED BACKGROUND: superpowers:verification-before-completion
When to Use
Triggered for:
- User deploys changes or requests deployment
- User commits code triggering quality gates
- User runs local or CI builds/tests
- User asks about selective or incremental validation
- Repository uses immutable releases and SemVer
Core Workflow
- Identify impact - Determine which components changed (use git diff, affected tooling)
- Scope quality gates - Limit lint, format, tests to impacted files/components
- Apply coverage delta - Check coverage of modified lines only (not absolute coverage)
- Selective execution - Build/test/deploy only affected components + dependencies
- Preserve critical gates - Always run architecture tests, security scans
Quick Reference
| Scenario | Scoping Strategy |
| Single file change | Lint/test affected file + direct consumers |
| Service change (mono) | Build/test that service + consumer tests |
| Shared library change | Build/test all dependent services |
| Documentation only | Skip deployment, validate markdown only |
| Deploy single service | Deploy that service, keep others unchanged |
Coverage Delta
Use modified line coverage, not absolute coverage:
Coverage Delta = (covered modified lines / total modified lines) x 100
Target: 80% of modified lines coveredAbsolute coverage punishes unrelated code. Delta focuses quality on changes.
Service-Specific Versioning
For immutable releases:
- Tag services individually:
backend-v2.6.0,frontend-v1.8.2 - Deploy only changed services
- Rollback to previous immutable version per service
Red Flags - STOP
- "Run full suite to be safe"
- "Deploy everything together"
- "Apply absolute coverage to entire codebase"
- "Use single version tag for all components"
- "Might miss something with selective approach"
All mean: Apply skill to scope validation/deployment to impacted components.
See references/scoping-strategies.md for tooling examples and detailed patterns.
See references/rationalizations.md for excuse table and pressure responses.
Build Tool Commands
Nx (TypeScript/JavaScript)
# Find affected projects
npx nx affected:apps --base=main --head=HEAD
# Run tests only for affected projects
npx nx affected:test --base=main --head=HEAD
# Build only affected projects
npx nx affected:build --base=main --head=HEAD
# Show dependency graph of affected
npx nx affected:graph --base=main --head=HEADBazel
# Query affected targets
bazel query "rdeps(//..., set($(git diff --name-only main...HEAD)))"
# Test only affected targets
bazel test $(bazel query "rdeps(//..., set($(git diff --name-only main...HEAD)))" --output=label)
# Build only affected
bazel build $(bazel query "kind(.*_binary, rdeps(//..., set($(git diff --name-only main...HEAD))))")Gradle
# Using gradle-affected plugin
./gradlew affectedUnitTests -Paffected.base=main
# Manual approach with changed modules
CHANGED=$(git diff --name-only main...HEAD | grep -E "^[^/]+/" | cut -d'/' -f1 | sort -u)
for module in $CHANGED; do
./gradlew :$module:test
doneTurborepo (TypeScript/JavaScript)
# Run tests for affected packages
npx turbo run test --filter='...[origin/main]'
# Build affected packages
npx turbo run build --filter='...[origin/main]'Delta Coverage Workflow
Step 1: Generate baseline coverage
# Checkout main, run tests with coverage
git checkout main
npm test -- --coverage --coverageReporters=json
cp coverage/coverage-final.json coverage-baseline.json
git checkout -Step 2: Identify modified lines
# Get line numbers of changes
git diff main...HEAD --unified=0 | grep -E "^@@" > changed-lines.txtStep 3: Calculate delta coverage
// delta-coverage.js
const baseline = require("./coverage-baseline.json");
const current = require("./coverage/coverage-final.json");
const changedFiles = execSync("git diff --name-only main...HEAD")
.toString()
.split("\n");
let coveredLines = 0,
totalLines = 0;
for (const file of changedFiles.filter(
(f) => f.endsWith(".ts") || f.endsWith(".js"),
)) {
const fileCoverage = current[file];
if (!fileCoverage) continue;
const changedLineNumbers = getChangedLines(file); // from git diff
for (const line of changedLineNumbers) {
totalLines++;
if (fileCoverage.s[line] > 0) coveredLines++;
}
}
const deltaCoverage = (coveredLines / totalLines) * 100;
console.log(`Delta coverage: ${deltaCoverage.toFixed(1)}%`);
if (deltaCoverage < 80) process.exit(1);CI Integration (GitHub Actions)
- name: Delta coverage check
run: |
git fetch origin main
CHANGED_FILES=$(git diff --name-only origin/main...HEAD | grep -E '\.(ts|js)$' || true)
if [ -z "$CHANGED_FILES" ]; then
echo "No code changes, skipping delta coverage"
exit 0
fi
npm test -- --coverage --collectCoverageFrom="$CHANGED_FILES"
node scripts/delta-coverage.jsRequired Agent Steps
- Announce skill and why it applies
- Identify affected components (git diff, affected tooling)
- For commits: Scope git hook quality gates to impacted files/components
- For commits: Apply coverage delta to modified lines only
- For builds: Define selective build execution (impacted + dependencies)
- For builds: Define selective test execution (unit, integration, contracts)
- For deployments: Ensure only impacted components deployed
- For deployments: Define service-specific version tags and traceability
- Preserve full-suite critical gates (architecture, security)
- Provide evidence checklist for completion
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

