Ask Expert

Breakpoints Adapter Skill

When to Use

Use ask_breakpoint when you need an answer from a human responder and the codebase, existing docs, and your own analysis are not enough.

Good fits:

• architecture trade-offs
• security reviews
• domain-specific implementation questions
• approval or intervention checkpoints

Do not route breakpoints you can already answer confidently from the available context.

Before Asking

1. Check who is available with list_responders.
2. Gather the code paths, constraints, and prior attempts you want the responder to see.
3. Decide whether you need a named responder with targetResponders or general routing by domain and tags.

Tool Contract

Tool: ask_breakpoint

{
  "question": "Should we keep the GitHub Issues backend for this workflow, or move this project to the server backend?",
  "context": "The repo already has routing.json entries for github-issues. We now need token-backed polling for multiple responders.",
  "fileReferences": [
    "packages/adapters/tasks/src/backends/index.ts",
    "packages/adapters/tasks/src/mcp/backend-resolver.ts"
  ],
  "tags": ["backends", "routing", "operations"],
  "domain": "platform",
  "targetResponders": ["platform-responder"],
  "routingStrategy": "single",
  "timeout": 600000
}

Current ask_breakpoint parameters:

• question
• context
• markdown
• codeSnippets
• fileReferences
• tags
• domain
• urgency
• interactionKind
• targetResponders
• routingStrategy
• timeout
• breakpointId
• backend
• breakpointsDir
• proven

Routing Guidance

• Use routingStrategy: "single" when one named responder should answer.
• Use routingStrategy: "first-response-wins" for the fastest qualified answer.
• Use routingStrategy: "collect-all" when you want multiple viewpoints.
• Use routingStrategy: "quorum" when you need a majority outcome.

After the Answer

• ask_breakpoint waits for the answer path to resolve, timeout, or cancellation.
• Use check_breakpoint_status with the returned breakpointId when you need to inspect the stored breakpoint record after the initial exchange.
• If the response must be signed, set proven: true on ask_breakpoint and optionally call verify_breakpoint_answer afterward for an explicit verification record.