# Evaluate System Changes

Judges RFCs, refactors and migrations from first principles before any code changes.

- Repository: https://github.com/bytedance/deer-flow (84840 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add bytedance/deer-flow --skill engineer-system-change -g -a claude-code -y`
Codex: `npx skills add bytedance/deer-flow --skill engineer-system-change -g -a codex -y`
Cursor: `npx skills add bytedance/deer-flow --skill engineer-system-change -g -a cursor -y`
Gemini CLI: `npx skills add bytedance/deer-flow --skill engineer-system-change -g -a gemini-cli -y`

## Description

Evaluate and carry out non-trivial software-system changes from first principles. Use when assessing RFCs, issues, designs, features, refactors, migrations, dependency changes, or proposed fields, events, APIs, modules, and services whose need, consumers, system fit, validation, or rollback require scrutiny. Read the actual system, identify the concrete problem and named semantic consumers, choose the smallest sufficient solution, reject pseudo-requirements and speculative abstractions, and require evidence proportional to risk. Do not use for mechanical edits, source-code explanation, or a dedicated review of an already-complete diff.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Engineer System Change

Treat every proposed change as a hypothesis about a real system, not as an implementation checklist. Establish whether the change should exist before designing or building it, then keep the solution and the process proportional to the risk.

## Preserve the Task Boundary

- If asked only to assess, review, or plan, make no project or external-state changes.
- If explicitly asked to implement, including after an assessment, pass the decision gates before editing and verify the result afterward.
- Treat implementation permission as separate from permission to commit, push, deploy, publish, or update issues and pull requests.
- If repository truth matters, inspect the current target revision and relevant discussion. Do not rely on a stale checkout, an RFC alone, or remembered architecture.
- Separate verified facts, inferences, and unknowns. Do not turn missing evidence into a confident conclusion.

## Apply the Decision Gates

### 1. Ground the Problem

- Trace the current user workflow, failure, or code path before proposing a solution.
- State the undesirable observable behavior and the invariant or outcome that should replace it.
- Identify who is affected and which concrete decision or action changes.
- Check whether the existing system, configuration, documentation, or operating procedure already solves the problem.
- Enumerate adjacent product paths and workarounds, not only the proposed target surface. Explain precisely which accepted outcome each alternative fails; do not claim “the only option” from one missing UI control or code path.
- Treat an absent field, interface, abstraction, or standard as an observation, not proof of a requirement.

Return `STOP` only when evidence affirmatively shows that no change is needed or the affected workflow already achieves the outcome. Return `NEEDS_EVIDENCE` when an unverified fact prevents the decision.

### 2. Name Semantic Consumers

The rest: https://github.com/bytedance/deer-flow/blob/HEAD/.agent/skills/engineer-system-change/SKILL.md