loop-mode

name	loop-mode
description	Executes tasks in continuous loop mode with strict test coverage and no legacy compatibility. Use when the user says "进入loop 模式, 目标: XXXX" or asks for nonstop implementation until done.

Loop Mode

Run in continuous execution mode for a single concrete goal with minimal interruption.

Trigger

Apply this skill when the user provides:

• 进入loop 模式, 目标: XXXX
• or equivalent intent such as "keep going without stopping until done"

If goal text is missing, ask exactly one concise follow-up question to obtain it.

Core Contract

1. Implementation first:

   • Do not stop at high-level planning unless explicitly requested.
   • Move directly into code changes after a short analysis.

2. Continuous loop:

   • Analyze -> implement -> test -> fix -> retest -> summarize.
   • Continue until acceptance criteria are met or a hard blocker is encountered.

3. Minimal interruption:

   • Do not ask for step-by-step confirmation.
   • Escalate only when truly blocked.

Test and Quality Requirements (Strict)

For every functional change:

• Add/update tests for main flow, edge cases, failure paths, and key branches.
• Run relevant tests/build checks after changes.
• Do not claim completion unless all related tests pass.
• Never skip execution-based verification.

If tests fail:

• Investigate root cause.
• Fix implementation or tests to match intended new behavior.
• Rerun until passing.

Compatibility Policy (Strict)

The product has no legacy-user burden. Therefore:

• Do not keep old-design compatibility paths.
• Do not add fallback/adapter/dual-path migration logic.
• If new design conflicts with old behavior, keep only the new design path.
• Rewrite outdated tests to assert the new design, not legacy semantics.

Retry and Escalation

Before escalating:

• Attempt up to 3 materially different fixes for the same class of failure.
• Record for each attempt:
  • failure reason
  • change made
  • result

Escalate only after repeated failure, with up to 3 concrete options.

Execution Guardrails

• Maintain clean architecture boundaries and single ownership of each responsibility.
• Avoid defensive fallback clutter; fix timing/order in the main path instead.
• Do not auto-commit unless the user explicitly requests commit.
• Do not perform destructive git operations.

Completion Output

At completion (or blocker), provide:

• Objective
• Changes
• Verification (commands and outcomes)
• Status
• Next