impl

Impl

Decompose submission units on your own according to the requirements, do a minimal implementation one by one, then call atomic-commit to submit.

-w Use an isolated worktree,-a use a sub-Agent or workflow orchestration; the two are independent and composable. When the user explicitly requests a worktree or sub-Agent / workflow, execute according to -w、-a respectively. When using -w or -a , read ISOLATION.md。

Process

1. Load project context

Execute according to the project knowledge protocol. Review all sceneIds and ruleNames returned by scope, and load the scenarios or atomic RULEs relevant to this round of implementation. Reuse knowledge already in the session only when it covers this round of implementation; if insufficient, load more. If knowledge is unavailable, continue and state so truthfully, and do not claim to have complied.

2. Decompose submission units

A submission unit is bounded by business meaning that can be independently explained: after completion, a user, role, or system gains a complete capability, or an observable business result is produced. Identify these results from the task card, PRD, API list, or the current conversation; put the code, tests, configuration, migrations, and documentation required to jointly achieve the same result in the same unit, and do not split by file, technical layer, number of interfaces, or type of change.

Split only when different and individually complete business results are formed. Each submission unit must also satisfy atomic-commit the delivery completeness and direct rollback criteria.

3. Implement and submit

Execute submission unit by submission unit:

1. Review the existing code and map the requirements to the actual structure. After mapping, load any relevant scenarios or atomic RULEs not yet covered.
2. When changes involve module responsibilities, interface surface area, seams, adapters, test surface, or depth, read codebase-design, and determine the necessary design based on the requirements, real code, and project rules; when there are feasible options with significantly different impacts, call ask-me to confirm with the user.
3. Make the minimal changes within scope, prioritizing reuse of existing capabilities. Do not add fallback or defensive designs beyond the requirements and rules.
4. Before submitting, verify each loaded RULE: for this unit's changes, determine whether it is compliant or not applicable, and if violated, fix it until compliant. Verification is completed within the implementation process; after passing, call atomic-commit, and complete one local commit with the current submission unit as the delivery unit.

Stop and report when code facts prove the approach infeasible, or when scope needs to be expanded or an already-closed approach needs to be changed.