Autonomous Reply

Autonomous Reply

Turn "reply to this, here's the context" into a channel-ready response with zero templating instructions: detect the channel from the pointer's shape, read the whole thread, ground the draft in the supplied context, and deliver it through the channel-correct route — in the user's voice, never the agent's.

Why this shape: replying to messages is a daily recurring task whose content varies but whose rules never do — which tool reads which channel, which tone fits, and above all which delivery route is safe. Encoding the rules once means every invocation needs only two things: a pointer to the message and pointers to the context.

Arguments

Pointers passed at invocation: $ARGUMENTS

The first pointer that resolves to a message/thread is the thing being answered; every other argument is a context source. Interpret each by shape — never ask the user to classify them:

Ambiguous pointers (a bare name that could be several repos, a key in an unknown tracker) are asked about, never guessed. With no arguments at all, infer the message and context from the conversation so far — the user often pastes a link or message right before invoking.

Channel matrix — tone and delivery are decided here, once

The delivery rules are not preferences — they are the reason this skill exists as a skill. Never "helpfully" send anything on the user's behalf, even if asked to hurry: the escape hatch is the user pasting/sending faster, not the agent taking over the account.

Phase 1 — Parse pointers and preflight access

Resolve every pointer per the shape table, then confirm the needed connectors actually work before drafting anything. Connector health varies per session: OAuth tokens wedge, servers need re-auth. If a read path is down, degrade gracefully — ask the user to paste the message or document content — rather than stalling or drafting blind. (Tracker MCPs that stop authenticating can often be bypassed by refreshing the OAuth token manually and calling the REST API directly with the same token.)

Phase 2 — Read the full thread, not just the message

Always pull the entire thread or comment history before drafting: who is on it, what was already answered, what tone and register the thread uses, which questions are addressed to the user specifically versus to others. For a Jira issue: description, acceptance criteria, all comments, linked issues, and the parent epic. A reply that repeats what someone already said, answers a question aimed at someone else, or contradicts an earlier message in the same thread is worse than no reply. Note who the audience is — a thread with directors or external parties on it changes how much detail and hedging is appropriate.

Phase 3 — Digest the context sources

Read each supplied source and extract only what bears on the thread's ask. The grounding rule is absolute: every factual claim in the draft must trace to a context source, to the thread itself, or be explicitly framed as the user's professional judgment. Gaps do not get filled with plausible-sounding filler — they become questions back to the sender or a stated "to be confirmed". Name systems, hosts, and components precisely as the sources name them; do not substitute generic labels that the recipient will have to disambiguate.

Phase 4 — Classify what the sender actually asks

The ask's type drives the draft's shape:

• Answer a question — lead with the answer in the first sentence; evidence and caveats after. Never make the recipient dig for the verdict.
• Assess / review (a Jira story, a document, a proposal) — free-form, shaped by what the item actually needs; no fixed rubric. Angles worth considering where relevant: scope clarity, whether acceptance criteria are verifiable, dependencies, risks and non-functional concerns, effort sanity, open questions. Raise only the ones that matter for this item.
• Acknowledge / confirm — short and decisive; confirm exactly what was asked, state the basis in one line, stop.
• Action request — commit with a concrete next step and timeframe, or push back with reasons. Never a vague "I'll look into it".

If the message is really a decision question in disguise ("should we go with X or Y?"), say so and hand off to the architecture-decision-review skill instead of answering shallowly.

Phase 5 — Draft in the user's voice, iterate in chat

Write in first person as the user, in the channel tone from the matrix. Show the draft in chat and apply corrections before any delivery step. Recurring correction patterns to pre-empt: don't over-explain to expert audiences; scope claims to what was actually measured or verified; for client-facing threads, guide only the interface between the parties — never the recipient's internals — and prefer "recommended" over "must". Nothing in the draft may identify the agent: no attribution, no meta-commentary about how the reply was produced.

Phase 6 — Deliver through the channel rule

• Gmail: create the draft reply on the thread (correct recipients, reply-all only when the thread expects it) and report the draft's location/id. Do not send.
• Slack / Google Chat / Jira: output the final text as a clearly marked paste-ready block — the last thing in the response, easy to copy whole. The user posts it.

The only programmatic writes this skill performs are creating an email draft and, when explicitly requested, creating or linking a tracker issue (next section). Everything else leaves the agent's hands as text.

Tracker issue creation — the one non-reply task this skill accepts

Sometimes the "reply" the thread needs is a new tracker issue: a meeting agreed to track a topic separately, or a thread asks for a follow-up ticket. When the user explicitly asks to create a tracker issue (and optionally link it to an existing one), do it through the tracker MCP — the issue is created under the user's own authenticated account, so the attribution concern that forbids connector posts on chat channels does not apply.

Rules for that route:

• Explicit request only. Never create an issue as a side effect of drafting a reply, and never post the paste-ready comment yourself — comments stay paste-ready.
• Read the hierarchy first (jira_get_issue on the referenced issue, its parent and epic) and decide the new issue's type and placement from what the sources say. A topic the thread wanted kept separate becomes a standalone story linked with "Relates", not a sub-task under the same parent.
• Ground the description the same way as a reply: background, goal, scope and out-of-scope, dependencies, acceptance criteria, next steps — every line traceable to the thread or a context source. Name the people and the decision date as the notes do.
• Sensible defaults, stated afterwards: same project as the referenced issue, assigned to the user, project-default priority. Report every default in the recap so the user can adjust in the tracker.
• Create, then link (jira_create_issue → jira_create_issue_link); report the new key.
• Still finish the reply. If the notes assign the user a "share the ticket number" step, end with the paste-ready comment for the originating thread as usual.

Learning loop

When a run hits friction this skill didn't anticipate — a pointer shape it misread, a connector quirk, a tone correction that keeps recurring — append a dated note to FIELD-NOTES.md in this skill's directory at the moment it happens, not in an end-of-run recall pass. A clean run records nothing. If the run produced notes, offer the user a skill retro at the end; codify into SKILL.md only patterns the user approves, and clear codified entries from the notes file. Notes must stay free of internal identifiers and content — this repo is public.