Surface feedback when requests skip, no-op, or are not understood #153

Context

Dogfood on aixgo-dev/sync (2026-09-19): humans leave review feedback or @aixgo-code … comments expecting the agent to act or to explain why it did not. Today many paths end in silence from the human’s point of view.

Concrete Sync examples

1. pull_request_review / changes-requested — caller job address is often skipped (e.g. sync run 35442613141) even when the reviewer is MEMBER. No comment on the PR explains that address never ran. Workaround that works: a separate @aixgo-code address … issue comment.

2. Natural-language @aixgo-code on a PR — e.g. on sync#19:
   @aixgo-code if we are pinning the version of Golang, ensure we are using the latest version of golang 1.27.1…
   The bot replied that it did not recognise a command (help-style reply) and did not treat the text as address/implement intent. The follow-up Actions run triggered by the bot’s own comment then shows as skipped (sync run 35443859600) with no human-visible “ignored because author is a Bot” note in the PR timeline beyond the Actions UI.

3. Actions UI — a full workflow conclusion of skipped with empty job steps gives adopters no durable signal on the issue/PR that their request was received but gated out.

Net: feedback is easy to miss, looks like “nothing happened,” and legitimate improvement requests (Go pin, review nits) are not acted on unless the human already knows the narrow command vocabulary.

Goal

Every human-triggered request path (ax:go label, @aixgo-code … comment, pull_request_review address) must leave visible, durable feedback on the issue or PR when the harness:

• runs and completes (success / blocked / needs input), or
• skips / no-ops / does not understand the request.

Prefer a short bot comment (or check-run annotation linked from a comment) over relying on the Actions “skipped” badge alone.

Out of scope

• Changing the core implement/address loop quality when it does run
• Replacing the command vocabulary entirely (improving routing is in scope; removing go / address / help is not required)

Proposed directions (implementer may refine)

1. Caller / reusable workflow

   • When a triggering event fires but the caller if skips the job that would have handled it (e.g. review submitted but address gated), post (or ensure the app posts) a one-line comment: “Received your review; address job did not run because …” with the concrete reason (author_association, missing secrets, bot author, etc.).
   • Fix or relax the address author_association gate if it falsely skips MEMBER/OWNER reviews (see Sync dogfood).

2. Comment command parsing

   • After @aixgo-code, if the rest is not an exact subcommand, either:
     • Route ambiguous PR comments to address (with the full body as feedback), and/or
     • Reply with an explicit no-op that quotes what was ignored and the exact phrases that would work (address, go, help), without requiring the human to open Actions.
   • Do not leave “I did not recognise a command” as the only outcome when the comment clearly asks for a code change.

3. Bot re-entry

   • Bot comments must not look like failed human requests in Actions. Skip quietly or mark the run with a clear ignore bot comment summary so adopters do not chase skipped runs that are expected.

4. Blocked / engine errors

   • Keep posting blocked comments (already done for engine errors); extend the same visibility standard to skip/no-op paths.

Acceptance criteria

• A CHANGES_REQUESTED (or submitted) review from a repo member that fails the address if still results in a PR comment stating that address did not run and why (or the if is fixed so address runs).
• An @aixgo-code … comment that is not a known subcommand either acts with a reasonable default on PRs (address using the comment body) or replies with a clear no-op + how to retry — never silence.
• Expected skips (bot-authored comments, wrong event for a job) do not strand humans staring at a red/skipped Actions entry with no PR/issue explanation when the trigger was a human request.
• Docs (README / setup / FAQ): one short section “What you should see after you ask” for label, comment, and review triggers.
• Unit/integration coverage for command parsing / skip-reason messaging where logic lives in Go; workflow behaviour covered by a documented manual dogfood checklist if YAML-only.
• make check green.

Evidence / repro

How to hand to Aixgo Code

Apply ax:go when ready (may need a human-written design note in the issue if command-routing policy should be locked first).