pending-questions

Pending Questions -- Responder Answering Skill

When to Use

Use this skill when the user is acting as a responder and wants to:

• check for pending breakpoints
• monitor for newly routed breakpoints
• draft and submit an answer with project-specific context

Step 1: Resolve the Responder Identity

Prefer an explicit responder ID from the user. If they do not provide one:

1. inspect .a5c/responder/ or run list_responders
2. match the user to an existing responder profile when possible
3. ask for the responder ID before answering anything

Cache the resolved responderId and display name for the rest of the session.

Step 2: Poll for Pending Breakpoints

Tool: poll_breakpoints

{
  "responderId": "security-responder",
  "waitSeconds": 0
}

For continuous monitoring, raise waitSeconds and repeat the poll after each cycle:

{
  "responderId": "security-responder",
  "waitSeconds": 30
}

Summarize the pending breakpoints, then ask which one to answer if there is more than one.

Step 3: Claim the Breakpoint

Claim the breakpoint before drafting so other responders can see it is being worked:

Tool: claim_breakpoint

{
  "breakpointId": "bp_123",
  "responderId": "security-responder"
}

If the claim fails, tell the user and let them choose a different breakpoint or continue without claiming when the backend does not support it.

Step 4: Enrich Context

Before drafting an answer:

• read any referenced files from the workspace
• inspect related code paths and recent changes when they matter
• summarize the constraints, risks, and likely trade-offs

The goal is to give the responder a short, grounded brief before they approve the draft.

Step 5: Draft the Answer

Prepare a draft that:

1. leads with the recommendation
2. explains the reasoning with repo-specific context
3. calls out caveats or follow-up checks
4. proposes an honest confidence score
5. includes relevant file or doc references

Ask the responder whether to submit, revise, change confidence, or skip.

Step 6: Submit the Answer

Tool: answer_breakpoint

{
  "breakpointId": "bp_123",
  "responderId": "security-responder",
  "responderName": "Sam Rivera",
  "text": "Require SameSite cookies and a CSRF token on the form POST.",
  "confidence": 85,
  "references": [
    "packages/adapters/tasks/docs/expert-guide.md",
    "docs/security/csrf.md"
  ]
}

If the workflow uses signed answers, include:

• sign: true
• keyFingerprint

Step 7: Confirm Recorded State

After submission, confirm what the backend recorded:

Tool: check_breakpoint_status

{
  "breakpointId": "bp_123"
}

Offer to return to polling for the next breakpoint.

Continuous Mode

When the user asks you to keep watching:

1. poll with poll_breakpoints
2. surface new breakpoints as they appear
3. help draft and submit answers
4. return to polling until the user stops

For terminal-first workflows, tasks-adapter responder-loop --responder <responderId> --once is the package CLI equivalent of a single poll cycle.