Establish a traceable execution closed loop for any engineering task. The input is a clear objective and an accessible workspace; the output is the minimal change, reproducible verification evidence, and an honest completion receipt.
Scope of application
Applies to verifiable tasks such as code, configuration, documentation, migration preparation, and repository maintenance. It does not replace the local rules of the target repository; after entering the repository, first read the applicable contribution instructions and testing conventions.
If the task requires a specific organization's process state, dedicated directories, or approval records, first load that organization's binding-layer skill; this skill only provides a portable execution method.
Customer-readable description
What this skill can do
| Customer wants | Execution closed loop | Customer can see |
|---|---|---|
| Implement or modify an engineering work item | Define boundaries, then make the minimal reliable change | Change mapping and verification results |
| Complete a risky maintenance work item | Identify high-risk surfaces and review them via an independent path | Verified facts, unverified items, and risks |
| Hand off a completed task | Summarize inputs, artifacts, checks, and residual risks | A copyable completion receipt |
Definition of done
"Done" simultaneously satisfies: the requested observable result has been achieved; the relevant verification has actually run; key conclusions have independent evidence; the working tree contains only the changes for this task. When any of these cannot be satisfied, clearly report the blocker or uncovered scope, and do not write intent as completion.
How customers use it
Provide the objective, the target workspace, the expected observable result, and any known testing or reproduction method. When deletion, overwriting, sending, publishing, remote writes, or irreversible data changes are involved, state the scope of authorization; if this information is missing, stop at the preview or diagnostic stage first.
Dependencies and installation
Installation:
claude plugin marketplace add soia-team/soia-open-skills
claude plugin install soia-dev@soia
When you only want this one skill, you can use the npx route. 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 as 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-task-execute -y
This skill does not require other installers or private configuration. Its hard dependencies are an accessible target workspace and at least one reproducible verification method; if the repository already has contribution instructions, test entry points, or local rules, read them first and take them as authoritative.
WorkBuddy is loaded as role-based experts rather than as a plugin,npx skills add -a '*' cannot cover it, and it needs to be installed separately, see docs/install/workbuddy.md。
Private information and intermediate data
- Only read the workspace files, test outputs, and configuration fields needed to complete the current task; customer data, credentials, and production logs are handled only minimally and are not copied into examples, patches, or receipts.
- Formal changes and deliverables remain in the target workspace or a user-specified path. This skill does not create its own persistent state, cache, prompt archive, or response body logs.
- Temporary reproduction data and tool intermediate files follow the target project's conventions; when there are no conventions, use the operating system's temporary directory and, after confirming it is safe, clean up the content created by this skill.
- Provider credentials must use the official login state or the system credential store; ordinary
config.ymlOnly non-secret preferences and path pointers are allowed. - The receipt records changed paths, commands, exit statuses, and necessary summaries; it does not echo secrets, unrelated source code, or complete customer input.
Logs and completion receipt
The process reports only stages, scope changes, verification results, and blocking reasons that affect judgment. The final receipt must list actual changes, commands actually run, independent review, and residual risks, and must not print credentials or local private information.
Execution flow
1. Define task boundaries
Before starting, write down four items: goals, non-goals, acceptance criteria, and verification plan. Split the input into work items that can be independently falsified, and specify evidence for each item, such as test names, command output, generated artifacts, or manual reproduction steps.
Distinguish "diagnosis" from "change": when the user only asks for localization, deliver the diagnosis first unless the user also authorizes a fix. When encountering deletion, overwriting, sending, publishing, or remote state changes, reconfirm the goal and authorization scope.
2. Inspect the site and implement
First inspect the working tree, baseline, and relevant conventions; existing unrelated changes must not be staged or mixed into this task. Keep the implementation scope minimal: every line changed should map to the goal, necessary verification, or obsolete old behavior.
For uncertain specifications, prefer a narrow, reversible interpretation and record assumptions; ambiguities that affect security, data integrity, public interfaces, or irreversible actions must be asked about first.
3. Verify results
Choose checks based on risk, not just the most convenient command to run:
| Risk surface | At least one type of evidence |
|---|---|
| Logic or data boundaries | Unit tests, fixtures, or boundary inputs |
| Flows and error paths | Integration tests or end-to-end reproduction |
| Interfaces, configuration, or build | Type checking, lint, build, or consumer paths |
| User-visible interface | Real operating steps, screenshots, or automated UI checks |
When fixing a problem, first reproduce it or establish the narrowest failing check; after the fix, run the relevant regression. If tests fail, cannot run, or cover only the happy path, state so truthfully and do not substitute "looks correct" for evidence.
4. Independent review
Do not verify only your own implementation intent. Review the most fragile assumptions through at least one other path: for example, inspect the diff beyond tests, reproduce with different inputs, check downstream call sites, or manually verify generated results.
Then search for the same pattern: whether the same defect appears in adjacent modules or the same calling convention. Write the search scope and reasons for inclusion or exclusion into the receipt. If unrelated problems are found, only report them and do not casually expand the changes.
5. Deliver the receipt
Before completion, check the staging area and working tree to confirm that no unrelated files enter the delivery. Write the receipt according to strength of fact: give sources for what was observed; give basis for inferences; explain the verification path for unknowns.
完成：<可观察结果>。
边界：<目标、非目标和关键假设>
文件变化：<每项变化如何对应目标>
验证：<实际运行的命令、结果和独立复核>
残余风险：<未覆盖情况；无则写“无”>
Anti-Fake-Fix Gate
Before calling it complete, confirm item by item:
- The diff of changes exists, and each item corresponds to the request;
- Verification proportionate to the risk was actually run;
- No TODO, comment, swallowed error, or empty commit was used to disguise a behavioral fix;
- The same pattern has been searched for and the handling conclusion recorded;
- Unrelated uncommitted files were not included in the delivery.
Security boundaries
Do not hardcode local paths, accounts, credentials, internal project details, or private context. Preserve explicit confirmation boundaries for remote writes, deletions, overwrites, sends, and publications. Report only checks and results that were actually executed.