should `--agent` continue using `--yes`? should it use `--force`?

[yamcodes]

related to #1110

[pullfrog]

Posted a detailed analysis on issue #1111 concluding that --agent should continue implying --yes but should not imply --force. The two flags serve orthogonal purposes: --yes controls interactivity while --force bypasses safety checks. Agents can already combine them explicitly (--agent --force) when needed. Recommended follow-ups are documentation and skill guidance updates rather than a semantic change.

Task list (3/3 completed)

• Analyze current --agent, --yes, and --force semantics in the CLI
• Evaluate whether --agent should imply --force
• Post analysis comment on issue should --agent continue using --yes? should it use --force? #1111

  ^{｜ Implement plan ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using Kimi K2 ｜ 𝕏}

[pullfrog]

Analysis: Should --agent imply --force?

After reviewing the current CLI semantics, my take is no — --agent should continue implying --yes, but it should not imply --force. Here's the breakdown.

Current semantics

Flag	What it does
--yes (-y)	Skips interactive prompts and uses defaults. Passed to subprocesses (e.g. skills add --yes).
--force (-f)	Bypasses technical requirement checks (existing-project flow) and the non-empty directory guard (new-project flow). Does NOT skip prompts.
--agent (-a)	Macro for --yes --quiet --json. Enables fully automated, machine-readable output.

Why --agent should keep implying --yes

--yes is purely about interaction — it removes the need for a human (or agent) to answer prompts. This is exactly what agent mode promises. Removing this would break the "fully automated" contract.

Why --agent should NOT imply --force

1. Different concerns. --yes = "don't ask me questions." --force = "I accept the risk of bypassing safety checks." These are orthogonal. An agent may want to skip prompts while still respecting guardrails.

2. Safety boundary. --force bypasses checks that exist to prevent destructive or incorrect operations (e.g., scaffolding into a non-empty directory, or mutating a project with unmet TypeScript requirements). Making this automatic removes a valuable safety net.

3. Agents can already combine flags. arkenv init --agent --force works today. An agent that knows it needs to bypass checks can opt in explicitly.

4. Granularity. --force covers two independent behaviors (requirements bypass + non-empty directory bypass). An agent might want one but not the other. Bundling them under --agent removes that choice.

What should change instead

Rather than changing --agent's semantics, we should:

1. Update the agent skill documentation (skills/arkenv/SKILL.md) to clarify that --agent alone may fail on non-empty directories or unmet requirements, and that --agent --force should be used when the agent knows it wants to bypass those checks.

2. Improve the skill's error handling so that when arkenv init --agent returns a structured JSON error mentioning "Use --force to bypass these checks," the skill can reason about retrying with --force rather than surfacing a dead-end failure.

3. Consider updating help text to make the distinction between --yes and --force sharper — e.g., --force could be described as "Bypass safety checks" rather than "Bypass technical requirement checks and force scaffolding."

Verdict

• --agent → --yes ✅ keep as-is
• --agent → --force ❌ do not add
• Actionable follow-up: documentation and skill guidance updates

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using Kimi K2 ｜ 𝕏}

[yamcodes]

This was generated by AI during triage.

Expert recommendation

--agent should keep implying --yes and must not imply --force. I agree with the earlier analysis and would decide it now — this doesn't need to stay open.

The clean mental model: --yes answers questions the CLI would have asked; --force overrides objections the CLI would have raised. An agent should never be pre-authorized to override objections, because the objections (non-empty directory, unmet TS requirements) are precisely the situations where an autonomous tool causes damage. This is the same reason git push and git push --force are separate decisions no matter how the push is invoked.

The one genuinely valuable follow-up from the prior analysis: make the refusal machine-actionable. When arkenv init --agent fails a safety check, the JSON error should carry a stable error code (e.g. "code": "REQUIREMENTS_NOT_MET" / "NON_EMPTY_DIR") and a retryWith: ["--force"] hint, so agents can escalate deliberately rather than pattern-matching on prose. That's a small, well-bounded change suitable for ready for agent.

Suggested resolution: record the decision (--agent ⇒ --yes only), split the JSON error-code enhancement into its own issue, and close this one together with #1110.

[yamcodes]

Agree with every word. Closing for now as we have a direct answer to this question.