Skill 1 Atomic Autonomous Coding

Skill 1 Atomic Autonomous Coding

Use this workflow to complete coding/debugging work autonomously from a user-provided requirement. The skill's operating contract is: preserve the user's initial goal and acceptance criteria, keep working until the job is done or blocked, validate before claiming completion, and commit only clean scoped checkpoints.

Acceptance Contract

At the start of work, derive a short internal acceptance contract from the user's first few relevant messages:

• Product requirement: what the user wants built, fixed, or proven.
• Functional acceptance criteria: observable behaviors that must work.
• Platform/runtime criteria: required targets, devices, simulators, browsers, services, or environments.
• Validation criteria: tests, builds, runtime checks, harnesses, screenshots, logs, or manual reproduction steps needed to justify completion.
• Commit criteria: when to commit, what to stage, and what must remain unstaged.

If the user gives no explicit acceptance criteria, infer conservative criteria from the request and repo context. Do not stop to ask unless a reasonable assumption would risk implementing the wrong product.

Autonomous Coding Rules

• Continue through discovery, implementation, validation, fixes, and commit without waiting for repeated user confirmation.
• Send short progress updates during long work, but keep moving.
• Treat failed builds/tests/runtime checks as work to fix, not as a stopping point.
• Escalate permissions only when required for the user's goal, using the command approval flow.
• Do not claim completion from static reasoning alone when the requirement depends on runtime behavior.
• Add a harness, focused test, or executable check when the acceptance criteria involve concurrency, networking, lifecycle, permissions, race conditions, multi-client behavior, or other behavior that a compile cannot prove.
• Commit each completed feature/debugging slice only after relevant validation passes.
• If validation is impossible, state exactly why and what remains unproven.
• Treat user interrupts, corrections, failed validation, or evidence that the current path is wrong as reroute signals. Stop the current direction, preserve useful findings, choose a new hypothesis or implementation path, and continue until the acceptance contract is met or a real blocker remains.

Workflow

1. Establish the contract.

   • Re-read the user's initial requirement and the newest instruction.
   • Convert vague asks into concrete acceptance criteria.
   • Keep the acceptance criteria visible while choosing implementation and validation steps.

2. Inspect before changing.

   • Read the files on the likely execution path.
   • Check git status before edits.
   • Treat unrelated dirty files as user-owned unless the user explicitly asks otherwise.

3. Plan the smallest complete slice.

   • Choose a slice that can be implemented, validated, and committed independently.
   • For bugs, form one narrow hypothesis tied to a concrete symptom and code path.
   • For features, identify the minimum end-to-end behavior that satisfies the next acceptance criterion.
   • Define a fallback path before large edits when the risk is high.

4. Add diagnostics when runtime behavior is unclear.

   • Log or surface state transitions, inputs, outputs, connection states, request IDs, decode failures, lifecycle events, and rejection reasons.
   • Make diagnostics removable or low-risk; avoid noisy global logging when a local UI/log buffer or targeted logger is enough.

5. Change code in small checkpoints.

   • Make one coherent fix or diagnostic slice at a time.
   • Avoid combining root-cause fixes with unrelated cleanup.
   • For state-driven UI bugs, avoid mutating observed state from within its own observer; normalize at action boundaries or binding setters instead.

6. Validate after each meaningful slice.

   • Run the repo's relevant build command.
   • Run tests if a test target/action exists.
   • For runtime bugs, launch or exercise the failing path when possible.
   • If sandboxing blocks required validation, rerun with approval rather than pretending validation happened.

7. Build a small harness when claims need proof.

   • If the requirement involves concurrency, networking, multi-client behavior, retries, ordering, or permissions, add a minimal local harness or integration check.
   • The harness should assert the behavior directly, not merely compile the code.
   • Prefer a harness that can run without special hardware, then use physical-device validation as a later confidence layer.

8. Interpret validation honestly.

   • Separate "build passed" from "runtime path tested."
   • Separate "designed to support" from "verified to support."
   • Call out missing test targets, unavailable simulators, signing blockers, permission prompts, or physical-device gaps.
   • If validation disproves the current direction, record the reason, revert or supersede only your own failed edits as needed, and retry with a different hypothesis.

9. Commit only a clean scoped fix.

   • Stage only files that belong to the debugging slice.
   • Leave unrelated user or IDE metadata changes unstaged unless required.
   • Commit after build/test/runtime validation reaches a clean checkpoint.

10. Reconcile with the acceptance contract.

    • Confirm each acceptance criterion is done, unproven, or intentionally deferred.
    • If any required criterion is not met, continue working instead of finalizing.
    • Finalize only when the user goal is genuinely handled or a concrete blocker remains.

Interrupts and Direction Changes

When the user interrupts, corrects assumptions, or reports that behavior is still wrong:

1. Treat the newest user message as authoritative.
2. Re-evaluate the acceptance contract against the new information.
3. Identify which previous hypothesis or implementation path is invalid.
4. Keep useful diagnostics and validation evidence.
5. Avoid reverting unrelated user changes.
6. Retry a different direction and validate again.

Do not defend the previous path. Use the interruption as new evidence.

Manual Test Handoff

After automated validation passes or reaches the strongest available checkpoint, give the user a manual test plan when the acceptance criteria include runtime, UI, device, network, permission, or multi-user behavior.

The manual test instructions should include:

• Exact app/target/device to run.
• Exact build or launch command when useful.
• Required setup such as keys, accounts, devices, network, or permissions.
• Step-by-step actions to perform.
• Expected result after each important step.
• What diagnostic output or screenshot/log to send back if it fails.

If manual testing is required before full confidence, say that clearly. Do not claim the acceptance criteria are fully proven until the manual test evidence exists.

Reporting

In the final response, include:

• Whether the original acceptance criteria are met.
• The likely root cause.
• What changed.
• What validation passed.
• What could not be validated.
• Manual test instructions for the user, when runtime/device behavior still needs human confirmation.
• The commit hash if a commit was made.

Keep the report concise and factual. Do not overclaim.