local-change-guard

Enforce file budgets and governance checks for direct in-tree edits.

1|Updated Jan 13, 2026
One-click install
npx skills add https://github.com/jongensutrecht/demo-ai-stack --skill local-change-guard
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: local-change-guard
Source: https://github.com/jongensutrecht/demo-ai-stack/tree/main/lars%20skills/local-change-guard
Command: npx skills add https://github.com/jongensutrecht/demo-ai-stack --skill local-change-guard

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill lets you make focused feature changes directly in the current working tree without a separate worktree or planning ceremony, while still enforcing strict repo governance and file-size limits.

Core Features & Use Cases

  • Direct in-tree edits for small to medium feature work.
  • Mandatory pre-edit budgeting for touched files, including line counts and function/method counts.
  • Governance-aware workflow for CTO rules, universal repo checks, and early escalation when scope grows.
  • Best for local bug fixes, incremental feature tweaks, and guarded refactors that must stay within shape limits.

Quick Start

Ask the assistant to implement the requested change directly in the current working tree while enforcing file budgets, CTO guardrails, and post-change verification.

Frequently Asked Questions about local-change-guard

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

FAQPage Schema
How do I enforce repo governance rules when making direct edits to a working tree?

To enforce repo governance during direct edits, you need a workflow that applies CTO guardrails, mandatory pre-edit file budgeting, and post-change verification before considering any local feature work complete.

What is pre-edit file budgeting for local repository changes?

Pre-edit file budgeting is a governance mechanism requiring you to define limits on touched files, including specific line counts and function or method counts, before any direct in-tree feature edits can begin.

Can I make incremental feature changes directly in-tree without a separate worktree?

Yes, you can make incremental feature changes directly in the current working tree without a separate worktree, provided you adhere to strict repository shape limits and complete post-change verification.

What's the best way to guard small refactors to ensure they stay within repository shape limits?

The best way to guard small refactors is to use a governance-aware workflow that enforces strict file-size limits, mandates pre-edit budgeting, and triggers early escalation if the scope grows beyond defined boundaries.

When should I not use direct in-tree edits for bug fixes?

You should not use direct in-tree edits for bug fixes when the changes require a separate planning workflow, exceed strict file-size limits, or involve scope growth that bypasses mandatory CTO governance checks.