Evaluate System Changes
Judges RFCs, refactors and migrations from first principles before any code changes.
Install
npx skills add bytedance/deer-flow --skill engineer-system-change -g -a claude-code -y- Repository
- bytedance/deer-flow84.8k
- Category
- Engineering
- Updated
- 3d ago
- License
- MIT
- Context cost
- Mediumabout 2,285 tokens
- Runs scripts
- No, instructions only
What it does
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.
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.
