apply-change

Orchestrates applying OpenSpec changes via builder subagents and adaptive reviewer fan-out.

Updated Nov 7, 2023
One-click install
npx skills add https://github.com/lstellway/nixfiles --skill apply-change-lstellway
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: apply-change
Source: https://github.com/lstellway/nixfiles/tree/main/modules/home-manager/claude/skills/apply-change
Command: npx skills add https://github.com/lstellway/nixfiles --skill apply-change-lstellway

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Applying a planned change to a codebase involves coordinating implementation, review, and commit decisions; doing this manually risks missed tasks, unreviewed diffs, and premature commits. ## Core Features & Use Cases - Pre-flight validation: Verifies the OpenSpec change exists, has no unresolved decisions, and that prerequisite changes have landed before any code is written. - Delegated build with adaptive review: A builder subagent executes tasks.md (single pass or parallel worktree slices), then reviewers are selected based on what the diff actually touches, with findings synthesized into blocking, non-blocking, and drift categories. - Use Case: After planning a change with plan-change, run this skill to have a builder implement the tasks, get domain-matched reviewers to inspect the diff, iterate up to three build cycles on blocking findings, and commit only after your explicit confirmation. ## Quick Start Apply the OpenSpec change named add-auth-flow by running the apply-change skill with that change name as the argument.

Frequently Asked Questions about apply-change

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

FAQPage Schema
How do I apply an OpenSpec change to my codebase?

Pass the kebab-case change name as the argument. The skill verifies the change is ready, delegates implementation of tasks.md to a builder subagent, fans out reviewers matched to the diff, and commits only after your confirmation.

How are reviewers selected for a code change review?

Reviewers are chosen adaptively by inspecting the git diff and matching changed surfaces (code domains, file types, API changes) to agent descriptions in ~/.claude/agents and .claude/agents. There is no fixed count; trivial diffs may get zero reviewers.

What happens if the change has unresolved decisions or missing files?

The skill stops before building. If proposal.md or tasks.md is missing, or markers like TBD and TODO(decide) are found, it directs you to resolve them or re-run plan-change first rather than repairing planning artifacts during apply.

Does the skill commit changes automatically?

No. It never commits without explicit user confirmation, never pushes, and never amends prior commits. If pre-commit hooks fail, the failure is treated as blocking and routed back into the review loop.

When should I use parallel worktree slices instead of a single build pass?

Use parallel slices only when tasks.md has clearly independent task groups touching disjoint file sets and the change is large enough to justify orchestration overhead. When in doubt, the skill defaults to a single-pass build.

What happens when review findings keep blocking the change?

Build-review iterations are capped at three cycles. After that, the skill stops and surfaces unresolved issues to you, since repeated blocking findings usually indicate the spec needs re-planning rather than more implementation attempts.