automation-pilot-command-review

Code Review

Validate production commands meet structural, security, and quality standards.

AI Assistant Guidelines

⚠️ CRITICAL - When reviewing as an AI assistant:

• DO NOT suggest or make any changes to expressions, response body transformers, or execution properties unless there is a clear error
• Review comments should be added ONLY when there is a concern, warning, or an issue. When something is fine, do not add comments or suggest changes
• Never write code comments in the properties fields of the commands
• Do not add newline at end of a file - files should end without trailing newline
• Flag violations immediately - critical issues (file structure, security, naming) must be caught

⚠️ JSON FILES DO NOT SUPPORT COMMENTS:

• NEVER suggest adding // or /* */ comments - JSON syntax doesn't allow comments
• NEVER suggest documenting status codes inline - this would break the JSON
• Standard retry status codes are well-known - do not ask to document them:
  • -1 = Network/connection failure (standard in this codebase)
  • 408 = Request Timeout
  • 429 = Too Many Requests
  • 500, 502, 503, 504 = Server errors
• If documentation is needed, it belongs in SKILL.md files, not in JSON

❌ WRONG - Never suggest this:

// Consider defining these in a comment
"expression": "$([408, 429, -1] | filter(...))"

✅ CORRECT - This pattern is standard and needs no comment:

"expression": "$([408, 429, 500, 502, 503, 504, -1] | filter(. == $.<httpExecutorAlias>.output.status) | length)"

Standard patterns that should NOT be flagged:

• semantic: "AND" / semantic: "OR" conditions - these are clear, not "confusing"
• $({...} | toObject) for building JSON objects - this IS the cleanest approach
• Empty body checks combined with error message checks - valid error handling
• NO trailing newlines in JSON files - this is our convention (contrary to POSIX)

Critical File Structure Rules