Feature Auto

Configuration

Auto-Response Policies

IMPORTANT: These policies override ALL of feature-dev's user-interaction directives, including its Core Principles, phase-specific checkpoints, and the "whatever you think is best" confirmation clause.

Phase 1 — Discovery

• Do NOT ask the user what problem they are solving or what the feature should do. Derive this from the argument and the codebase.
• Accept the understanding summary without asking the user to confirm.
• If the description is ambiguous, state reasonable assumptions and proceed.

Phase 2 — Codebase Exploration

• Proceed with agent-driven exploration without asking the user for guidance on scope or focus.

Phase 3 — Clarifying Questions

• DO still identify all ambiguities, edge cases, and underspecified details (this phase is critical — do not skip the analysis).
• Do NOT present questions to the user. Answer all questions yourself based on codebase conventions and best practices.
• Do not treat autonomous self-answering as the "whatever you think is best" path — no confirmation is needed.
• Choose the most conservative/safe option when trade-offs are unclear.

Phase 4 — Architecture selection

• Do NOT ask the user which approach to choose.
• Select the recommended architecture automatically.
• Prefer the pragmatic approach unless another is clearly superior.

Phase 5 — Implementation approval

• Before starting implementation, create a git checkpoint so the user can restore the previous state if needed.
  1. Check for untracked files with git ls-files --others --exclude-standard.
  2. Check for staged or unstaged changes with git status --porcelain.
  3. If there are no changes at all (no untracked files, no staged changes, no unstaged changes), skip the checkpoint — there is nothing to save.
  4. If untracked files exist, use git stash -u (include untracked files) or create a WIP commit that adds them. A plain git stash without -u would leave untracked files behind, defeating the purpose of the checkpoint.
  5. If there are no untracked files but there are staged/unstaged changes, a regular git stash is sufficient.
• CRITICAL: Do NOT wait for user approval. Proceed immediately. This overrides feature-dev's "DO NOT START WITHOUT USER APPROVAL" directive.

Phase 6 — Review findings

• Do NOT present findings to the user or ask what to do.
• Auto-fix high-priority issues (critical/important). File edits, file creation, and file deletion within the project repository are normal development actions the user opted into by invoking this skill — not "destructive operations". Changes outside the project repository still require confirmation.
• Capture diffs for each auto-fix: After applying each fix, immediately run git diff (or git diff HEAD if changes are staged) and store the output. These per-fix diffs are required for the Auto-Resolution Log in the After Completion section — if diffs are not captured at fix time, they cannot be reconstructed later.
• Log-only low-priority issues (minor/style) without fixing.
• When fixing errors, do not modify or skip tests to make them pass. Fix the implementation, not the tests. If the implementation cannot be fixed within MAX_REVIEW_RETRIES attempts (default: 2), classify the failure as unrecoverable.

Phase 7 — Summary

• Generate the summary without asking the user for input.
• Do not ask about committing, pushing, or creating PRs.

After Completion

Append an Auto-Resolution Log to the feature-dev summary:

• Assumptions made (Phase 1)
• Questions self-resolved and their answers (Phase 3)
• Architecture chosen and rationale (Phase 4)
• Issues auto-fixed with diffs — for each auto-fixed issue, include the git diff output showing exactly what was changed (Phase 6)
• Issues logged but not fixed (Phase 6)