Agent skill · operations · aiskillstore
req-change-workflow
Standardize requirement/feature changes in an existing codebase (especially Chrome extensions) by turning "改需求/需求变更/调整交互/改功能/重构流程" into a repeatable loop: clarify acceptance criteria, confirm current behavior from code, assess impact/risk, design the new logic, implement with small diffs, run a fixed regression checklist, and update docs/decision log. Use when the user feels the change process is chaotic, when edits tend to sprawl across files, or when changes touch manifest/service worker/OAuth/storage/UI and need reliable verification + rollback planning.
Why this skill is useful
Provides a structured workflow for managing requirement changes in Chrome extensions, ensuring clarity and reducing chaos in the process.
What it needs
About 3k tokens when loaded. Last updated 2026-08-07. 405 stars on the source repository.
What this skill does
Req Change Workflow Overview Use a lightweight, repeatable workflow to modify an existing requirement without scope creep or “边改边炸”. Produce clear artifacts at each gate so the user can approve before the implementation starts. Workflow (gated loop) Follow the steps in order. Do not implement code changes until the user approves Step 4. Step 0: Set the plan (optional but recommended) Use updateplan to create 5–7 short steps: clarify → baseline → impact → design → implement → validate → document. Keep exactly one step inprogress at a time and advance as you finish. Step 1: Clarify the change (lock scope first) Ask the user for the minimal inputs, then rewrite them into a clear “change brief”: Target (1 sentence): what outcome changes. Out of scope (1 sentence): explicitly what must NOT change. Acceptance criteria (3–6 bullets): observable behaviors that can be verified. “Must keep” constraints: compatibility, performance, security, no new dependencies, no network, etc. Rollback expectation: can we revert by reverting a diff, or does it require data migration/backfill? Use the template in references/change-brief-template.md. Step 2: Confirm current behavior from code (baseline) Do not trust memory or assumptions. Locate the real entrypoints + current data flow and summarize it in 5–10 lines: UI entrypoints (e.g., sidepanel/, options/) and where user actions are wired. Background orchestration (e.g., serviceworker.js). Core modules (e.g., src/core/...) and storage (src/core/local/...). Config/permissions changes (e.g., manifest.json). Use scripts/impactscan.sh to quickly find likely files, then read only the necessary ones. Output artifact: “Current behavior summary” + a short file list (with why each file matters). Step 3: Impact + risk assessment (change budget) Before proposing a new design, list: Files/modules that must change and why. Risks: auth/session, storage migration, concurrency, caching, permission scopes, UX regressions. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aiskillstore/req-change-workflow