Document engine.command field for custom executable paths

[Copilot]

Plan: Document the engine.command field

The engine.command field already exists and works (implemented, tested, and in schema), but it's not documented in the user-facing documentation. This PR adds documentation for this feature.

Checklist:

• Verify the feature exists and works (confirmed via code review and tests)
• Add documentation to /docs/src/content/docs/reference/engines.md
• Add example usage showing how to override the default command
• Verify documentation builds without errors (formatting passed)
• Run final validation (tests passed, manual compilation verified)
• Apply unbloat-docs to make documentation more concise

Changes Made:

1. ✅ Added new "Custom Engine Command" section in engines.md
2. ✅ Added the command field to the extended configuration example
3. ✅ Included practical examples (absolute path, relative path, environment variables)
4. ✅ Documented use cases and behavior when custom command is specified
5. ✅ Follows existing documentation style and structure
6. ✅ Reduced documentation from ~42 lines to ~10 lines (76% reduction) while preserving all essential information

Summary:

The engine.command field was already fully implemented and tested in the codebase, but was undocumented. This PR adds concise user-facing documentation to help users understand how to use custom engine executables in their workflows.

Original prompt

Add optimal engine.command field that allows to replace the default command name of an agentic engines

engine:
id: copilot
command: other

generates "other"

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[pelikhan]

@copilot use unbloat-docs instructions to make it shorter

[Copilot]

Pull request overview

Documents the existing engine.command configuration field so users can run a custom engine executable/command instead of the default installation flow.

Changes:

• Adds a “Custom Engine Command” section explaining engine.command and common use cases.
• Updates the extended configuration example to include the command field.
• Provides examples for absolute/relative paths, env-var expansion, and PATH-based commands.

Comments suppressed due to low confidence (2)

docs/src/content/docs/reference/engines.md:149

• “Relative path” is described as relative to the “workflow directory”, but the engine command runs with working directory set to ${GITHUB_WORKSPACE} (repo root) both in normal steps and in AWF (--container-workdir). Suggest updating this to “relative to the repository root / ${GITHUB_WORKSPACE}” to match runtime behavior.

- **Relative path**: Path relative to the workflow directory (e.g., `./bin/claude-cli`)
- **Command with environment variable**: Use environment variable expansion (e.g., `$HOME/.local/bin/codex`)

docs/src/content/docs/reference/engines.md:176

• Since engine.command causes the engine’s entire GetInstallationSteps to be skipped (including secret-validation, Node/npm setup, and AWF install when sandbox/firewall is enabled), it’d help to add an explicit note here that users must provision those dependencies themselves (or disable sandbox / provide sandbox.agent.command for AWF) when using command.

When a custom `command` is specified, the workflow assumes the engine is already installed and available at the specified path. Installation steps will be skipped.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

@copilot use unbloat-docs instructions to make it shorter

Done! Reduced the documentation from ~42 lines to ~10 lines (76% reduction) while preserving all essential information. Commit: 2171d64

Changes:

• Consolidated bullet points into concise prose
• Removed redundant examples (kept one comprehensive example)
• Removed separate "Use cases" section (now implied in intro)
• More direct, action-oriented language