stay-in-lane

Validate proposed code changes against user requests before editing.

60|2|Updated Jan 21, 2026
One-click install
npx skills add https://github.com/ElliotJLT/Claude-Skill-Potions --skill stay-in-lane
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: stay-in-lane
Source: https://github.com/ElliotJLT/Claude-Skill-Potions/tree/main/skills/stay-in-lane
Command: npx skills add https://github.com/ElliotJLT/Claude-Skill-Potions --skill stay-in-lane

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

The Stay In Lane skill prevents scope creep by verifying that proposed changes match the user's original request before editing code, reducing misfires and unnecessary refinements.

Core Features & Use Cases

  • Scope verification before every modification to ensure changes align with user intent.
  • Decision-matrix guidance that classifies changes as Proceed, Stop, or Adjacent with steps.
  • Clear guidelines for handling adjacent work and avoiding scope creep during reviews and refactors.
  • Suitable for use during development sessions, code reviews, and pair programming to maintain focus.

Quick Start

Use Stay In Lane before any code modification to confirm the scope of the requested change. Provide the user’s request and the proposed change, then evaluate:

  • If Match is Yes → proceed with the change.
  • If Match is No → halt and prompt for clarification.
  • If Match is Adjacent → perform the requested change first, then note the adjacent improvement for later.

Frequently Asked Questions about stay-in-lane

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

FAQPage Schema
How do I prevent scope creep when making code changes?

Scope creep prevention starts by validating proposed changes against your original request before editing. Use a decision matrix to classify each change as Proceed, Stop, or Adjacent, ensuring modifications stay aligned with intent and reducing unnecessary refinements.

What's the best way to handle adjacent work during code reviews?

When adjacent improvements emerge during reviews, complete the requested change first, then document adjacent work separately for later. This keeps focus on the primary task while capturing secondary improvements without derailing the current scope.

How do I verify code changes match the original request?

Before any modification, apply a scope-match checklist: compare the proposed change directly against the user's request using the decision matrix. If Match is Yes, proceed; if No, halt and request clarification; if Adjacent, complete the request first.

Can I use scope control during pair programming and development sessions?

Yes. Stay In Lane applies across development sessions, code reviews, and pair programming. Use the before-change checklist and adjacent-work guidelines in each context to maintain focus and prevent scope creep consistently.

What happens when a proposed change doesn't match the original request?

Stop the modification and prompt for clarification. Mismatched changes indicate scope creep risk. Use the decision matrix to determine whether the change is truly out of scope or qualifies as adjacent work that should be deferred.

Why does scope verification matter in refactors?

Refactors can drift into unrelated improvements, multiplying risk and review cycles. Scope verification ensures refactoring stays focused on the stated goal—structural change, performance, or clarity—without bundling unrelated enhancements.