no-mistakes ask-user vs auto-fix Finding Categorization: When to Block vs Auto-Resolve

In the no-mistakes pipeline, auto-fix findings are safe, mechanical issues resolved automatically without human input, while ask-user findings challenge user intent or product behavior and force the pipeline to pause until explicitly approved.

The no-mistakes repository classifies every detected issue—whether from review, test, lint, or CI steps—as a Finding with an associated action string. This categorization determines whether the pipeline can proceed automatically or must stop for human review. Understanding the distinction between ask-user and auto-fix is essential for configuring safe automation boundaries.

Where Action Constants Are Defined

The three possible finding actions are declared as string constants in internal/types/findings.go at lines 10-13:

const (
    ActionNoOp    = "no-op"
    ActionAutoFix = "auto-fix"
    ActionAskUser = "ask-user"
)

User-facing descriptions of these actions reside in internal/skill/skill.go (lines 46-53), where the CLI documentation explains that auto-fix represents mechanical and low-risk changes, while ask-user indicates the finding challenges the user's deliberate intent.

Understanding the auto-fix Category

auto-fix findings identify problems that the pipeline can correct automatically without risking user intent or product-level behavior. These fixes are deterministic, safe, and low-risk.

Common examples include:

• Trivial style violations
• Missing imports
• Formatting inconsistencies
• Dead code removal that does not affect API surface

Because auto-fix findings do not alter functional behavior or intentional design choices, the executor can apply resolutions immediately when running with --action fix or --action approve flags.

Understanding the ask-user Category

ask-user findings flag issues that touch the user's deliberate intent, product behavior, or functional requirements. These findings must be reviewed by a human or an explicitly authorized agent before any change is applied.

Examples of ask-user findings include:

• Hard-coded values that should be configurable
• Deletions of code that appear intentional
• Changes that could affect the public API
• Modifications to security-critical configurations

When the pipeline encounters even a single ask-user finding, it creates a gate that pauses execution and requires a response via no-mistakes axi respond before proceeding.

Pipeline Execution and Gate Logic

The executor uses the helper function HasAskUserFindings defined in internal/types/findings.go (lines 203-210) to determine whether a step can proceed unattended:

func HasAskUserFindings(findings Findings) bool {
    for _, item := range findings.Items {
        if item.Action == ActionAskUser {
            return true
        }
    }
    return false
}

The pipeline behavior follows this logic:

1. Automatic resolution occurs when all findings are auto-fix or no-op. The step resolves without human intervention.
2. Gating occurs when HasAskUserFindings returns true. The pipeline pauses, awaiting human response through the CLI.
3. --yes mode bypasses the gate by pre-approving all ask-user findings, treating them identically to auto-fix for unattended automation scenarios.

Practical Code Examples

Creating Findings with Different Actions

In internal/types/findings.go, the Finding struct uses the action constants to categorize issues. Here is how step implementations construct these findings:

import "github.com/kunchenguid/no-mistakes/internal/types"

func exampleFindings() types.Findings {
    return types.Findings{
        Items: []types.Finding{
            {
                ID:          "auto-1",
                Severity:    "warning",
                Description: "unused import – can be removed automatically",
                Action:      types.ActionAutoFix,
            },
            {
                ID:          "user-1",
                Severity:    "error",
                File:        "config.go",
                Line:        42,
                Description: "hard-coded API endpoint – should be configurable",
                Action:      types.ActionAskUser,
            },
        },
    }
}

Checking Findings in the Executor

Step implementations in internal/pipeline/steps/* use the findings helpers to determine execution flow:

func handleFindings(f types.Findings) {
    if types.HasAskUserFindings(f) {
        // Pause the run – the user must answer.
        fmt.Println("🔒 Gate: ask-user findings present")
        // Sends FINDINGS back to the CLI for `axi respond`
    } else if types.HasActionableFindings(f) {
        // Safe to auto-fix everything.
        fmt.Println("✅ Auto-fixing findings")
        // Invoke the auto-fix step
    } else {
        fmt.Println("🟢 No actionable findings")
    }
}

Responding to ask-user Findings from the CLI

When the pipeline gates on an ask-user finding, inspect the status and respond accordingly:

# Check current gate status

no-mistakes axi status

# → gate: ... findings: [{id:"user-1",action:"ask-user",...}]

# Approve the finding as-is

no-mistakes axi respond --action approve

# Or request a fix with specific instructions

no-mistakes axi respond \
    --action fix \
    --findings user-1 \
    --instructions "Make the endpoint configurable via ENV"

Summary

• auto-fix in no-mistakes represents mechanical, low-risk issues that the pipeline can resolve automatically without human review.
• ask-user protects intentional design choices by flagging findings that affect user intent, product behavior, or API compatibility.
• The HasAskUserFindings function in internal/types/findings.go determines whether a pipeline step must gate and await human response.
• --yes mode bypasses ask-user gates for fully automated environments where explicit pre-approval has been granted.
• Categories are defined as constants in internal/types/findings.go and documented in internal/skill/skill.go.

Frequently Asked Questions

What happens if a step contains both auto-fix and ask-user findings?

If any finding in a step has the ask-user action, the entire step gates regardless of other auto-fix findings present. The pipeline pauses and requires human response via no-mistakes axi respond before proceeding.

Can I override ask-user blocking behavior in automation?

Yes. Running the pipeline with the --yes flag pre-approves all ask-user findings, allowing the executor to treat them identically to auto-fix findings. This is useful for unattended CI/CD environments where explicit human confirmation is not feasible.

How do I configure which findings categories block the pipeline?

Projects can tune gate behavior through configuration settings such as auto_fix.review: 0, which ensures that ask-user findings always block the pipeline even if other parts of the step could be auto-resolved. The pipeline logic respects these settings in the step implementations located in internal/pipeline/steps/*.

Where are the action constants defined in the source code?

The ActionAutoFix and ActionAskUser constants are defined in internal/types/findings.go at lines 10-13. Helper functions like HasAskUserFindings (lines 203-210) and user-facing documentation in internal/skill/skill.go (lines 46-53) provide the complete implementation and description of these categorizations.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}