Treat issues found in review, testing, or runtime as traceable tickets. The input is one or more findings; the output is an item-by-item handling record, fixes verified by regression, and clear reasons and follow-up paths for items that cannot be fixed.
Scope of Application
Applies to structured findings, failing tests, or locatable defects in ordinary engineering repositories. If the task is constrained by an organization's proprietary status, approval, or archiving rules, first load the corresponding binding layer; this skill assumes no specific directory, project, or toolchain.
Even a single obvious minor change should keep a minimal record: reproduction evidence, fix, relevant regression, and receipt.
Customer-Readable Description
What This Skill Can Do
| Customer Wants | Execute the Closed Loop | Customer Can See |
|---|---|---|
| Fix item by item according to review comments | Summary, decision, fix, and item-by-item verification | Status and evidence for each finding |
| Confirm whether it can be closed | Independently recheck fixes and regression results | Conclusion of pass, needs modification, or blocked |
| Defer some issues | Provide traceable follow-up locations and reasons | Clear deferral boundaries |
How Customers Use It
Provide findings, the target workspace, relevant tests or reproduction information, and the permitted scope of modification. If something may involve deletion, overwriting, remote state, release, or scope expansion, obtain explicit authorization first; if information is insufficient, first organize an input checklist and do not begin modification.
Dependencies and Installation
Installation:
claude plugin marketplace add soia-team/soia-open-skills
claude plugin install soia-dev@soia
When only this one skill is needed, the npx route can be used. Note that the skill will land in the shared source of truth ~/.agents/skills; if a plugin is also installed, the same skill will appear in two indexes and each will drift, so it is recommended to choose one of the two:
npx skills add soia-team/soia-open-dev-skills -g -a '*' -s soia-dev-fix-loop -y
This skill requires no other dedicated installation or private configuration. Its hard dependencies are accessible findings, the target workspace, and a verification entry point commensurate with the risk; follow the target repository's existing contribution instructions and check conventions.
WorkBuddy The loading unit of is role-based experts rather than plugins,npx skills add -a '*' cannot cover it, so it needs to be installed separately, see docs/install/workbuddy.md。
Private Information and Intermediate Data
- Findings, failure logs, and reproduction materials may contain source code, account, or customer data; keep only the minimal excerpts needed for decisions, and desensitize them before putting them into receipts or committable fixtures.
- Fix and test artifacts remain in the target workspace; this skill does not establish its own persistent state, cache, or complete copy of findings. Defer items that need long-term tracking should be written into the issue, task system, or file explicitly specified by the customer.
- Temporary reproduction data should be placed in the target repository's existing test directory or the operating system's temporary directory; after the task ends, clean up only the temporary content created by this skill and confirmed safe to delete.
- Credentials should use only the Provider's official login state or the system credential store, and must not be written into ordinary configuration, commands, logs, tests, or commits.
- Completion receipts should record the decision, minimal evidence, and verification result by finding ID, and should not echo the full prompt, response body, or irrelevant logs.
Logs and Completion Receipts
Record the number of inputs, item-by-item decisions, verification status, and blocking reasons. The final receipt must cover the conclusion for each finding, the checks actually run, unhandled items, and residual risks; credentials or local private information must not be output.
Five-step remediation loop
1. Reproduce and normalize input
Read all findings, extracting unique identifiers, severity, location, problem description, and source. Merge duplicates; when the same issue has different severities, use the higher level while preserving the sources. For each key issue, run a minimal reproduction, or record why it cannot currently be reproduced.
| Finding | 严重性 | 来源 | 位置 | 复现证据 |
|---|---|---|---|---|
| F-01 | high | review-a | <file:line> | <命令或步骤> |
2. Item-by-item decision before remediation
Each finding must have a status selected before implementation:
| Decision | Meaning | Required basis |
|---|---|---|
| fix | Fix in this round | Target behavior and verification plan |
| reject | Finding does not hold | Testable counter-evidence |
| defer | Defer remediation | Traceable follow-up location, owner, or trigger condition |
Issues must not be silently omitted; "look at it later" must not be used in place of defer. For high-risk decisions or fixes that would expand scope, first explain the impact to the user and obtain the necessary authorization.
3. Implement the minimal fix
Modify only the parts needed to make the finding satisfy the target behavior. It is forbidden to fake a fix with TODOs, comments, suppressing exceptions, weakening assertions, or deleting tests. Each fix should have corresponding evidence in the diff; if multiple fixes depend on each other, explicitly state the dependencies.
After the change, search for similar patterns and decide whether to include them in this round; if excluded, record the scope rationale to avoid mistakenly calling unchecked similar issues resolved.
4. Regression and independent review
For each fix item, run at least one direct verification and run regression checks proportionate to the change surface. For each reject item, review its counter-evidence; for each defer item, review that the follow-up chain truly exists and is sufficiently specific.
In addition to tests, attack the conclusion through independent paths, such as checking the diff, constructing counterexample inputs, checking callers, or having someone not involved in the implementation review it. If a regression, empty diff, TODO fake fix, invalid rejection reason, or broken follow-up chain appears, loop back to step 2 or step 3.
5. Close out and receipt
Only when all items have fix、reject or defer evidence can it be closed out. Use one of the following conclusions:
| Conclusion | Condition |
|---|---|
| approved | Fix passes, rejection reason holds, deferral chain is valid |
| changes requested | There are unverified fixes, omissions, or decisions that do not hold |
| blocked | Missing necessary permissions, environment, input, or follow-up ownership |
修复回执：<approved / changes requested / blocked>。
处理清单：<每条 finding 的决策与结果>
验证：<复现、直接检查、回归和独立复核>
未处理项：<defer 或 blocked 的原因和承接路径>
风险：<仍未覆盖的情形；无则写“无”>
Anti-omission and fake-fix gate
- Every finding in the input list has an explicit decision;
- Every fix has diff evidence of code or configuration behavior;
- Direct verification and regression checks are actually run, and failures are not hidden;
- Rejections and deferrals both have reviewable bases;
- Unrelated files or unrelated refactoring are not mixed into the fix commit.
Security boundary
Retain user confirmation for deletion, overwriting, remote writes, releases, and expanding the remediation scope. Do not put local absolute paths, accounts, credentials, or private project context in records or examples.