feature-qa-looplisted

# Feature QA Loop Run a tight human-in-the-loop QA cycle for one feature. Keep the user focused on a single action while maintaining the deeper test plan, evidence trail, and engineering loop yourself. ## Start the session Ask for the feature only if the user has not named it. Resolve the target environment and current deployed version from context or read-only inspection. Inspect relevant product docs, code, fixtures, and existing QA instructions before choosing the first action. Establish the mutation policy from the user's explicit wording: - `analysis-only`: investigate and record; do not edit code, commit, push, deploy, or change production data. - `fix blockers`: implement and verify confirmed blockers. Commit or push only when the user explicitly authorizes those actions for this session. Skill invocation alone never grants write or production authority. Do not make the user review the whole test plan. Maintain it privately and reveal one step at a time. ## One-step contract Every manual-testing turn must contain exactly one action for the user. State: 1. The single action to perform. 2. The exact visible result expected. Keep it brief and easy to scan. Do not include later steps, optional branches, multiple actions hidden in one bullet, or a full checklist. Wait for the user's result before advancing. Read-only checks the assistant can perform—repository inspection, logs, database reads, deployment status, or screenshot analysis—do not count as extra user s