Command Execution

Command execution procedures

This skill provides procedural how-to for the invariants defined in the command-execution rule module. The rule module states what must hold; this skill states how to comply.

Federated identity flow handoff

When an automation-launched browser context is blocked or degraded during a federated identity flow (Google, Apple, Microsoft, GitHub):

1. Stop the automation at the moment the IdP redirect URL is reached. Do not attempt to fill the IdP form from automation.
2. Hand off the IdP step to a real browser session via Chrome DevTools Protocol attach, or by asking the user to complete the sign-in step interactively.
3. Wait for the post-IdP redirect back to the application's callback URL.
4. Resume automation from the post-callback state.

The agent MUST NOT attempt to bypass provider anti-automation, embedded-browser restrictions, or "this browser is not secure" gates. Such bypasses are explicitly forbidden by the command-execution rule module.

Agent-browser session retry

When the default agent-browser session bind fails on Windows:

1. Choose an explicit, task-scoped session name (e.g., task-<short-id>).
2. Retry the bind with the new name.
3. If multiple binds fail in sequence, capture the error and surface it; do not loop indefinitely.
4. Track every session name your task opens so you can close them on completion.

Privilege elevation fallback

The rule module requires sudo first; this is the fallback ladder when sudo is unavailable:

1. Try sudo <command> directly.
2. If sudo is not on PATH, check for gsudo (a PowerShell-friendly elevation tool) and use it if available.
3. As a last resort, instruct the user to re-run the command in an elevated terminal session.
4. NEVER spawn a separate elevated shell window such as Start-Process -Verb RunAs from inside an automation flow — the parent loses stdout/stderr capture and exit code propagation.

Destructive PowerShell file deletion safety

When the rule module requires verifying the final absolute target path before a destructive operation:

1. Resolve the target with [System.IO.Path]::GetFullPath($candidate) or Resolve-Path -LiteralPath $candidate.
2. Assert the resolved path is inside the expected directory tree before deleting.
3. Normalize file attributes (attrib -r -h -s) on read-only, hidden, or system files before attempting deletion.
4. Prefer [System.IO.File]::Delete() / [System.IO.Directory]::Delete($path, $true) over the rm alias, which dispatches through provider hooks that may silently fail on locked files.
5. After deletion, re-stat the path and verify it is gone.

Avoiding interactive git prompts

The rule module forbids interactive git prompts. Apply one of these in every git invocation that might open an editor:

• Pass --no-edit to merge, revert, cherry-pick, etc.
• Set GIT_EDITOR=true for the invocation.
• For commit messages, always pass -m "<msg>" or use a here-doc.

Diagnosing third-party tool failures

When the rule module requires checking the latest stable release:

1. Determine the currently installed version (<tool> --version or package manager query).
2. Look up the latest stable release on the tool's official release feed.
3. Upgrade to the latest stable in an isolated install if feasible.
4. Re-run the failing command on the latest stable.
5. If the failure persists, document the version, exact command, and reproduction steps as a verified limitation.
6. Implement the smallest deterministic workaround that does not bypass safety checks.