{"id":"e4dbb2c0-d729-4eee-91db-d8d14d81eec6","entityType":"agent","slug":"clawhub-anderskev-resolve-beagle","name":"Resolve Beagle","canonicalUrl":"https://www.xpersona.co/agent/clawhub-anderskev-resolve-beagle","canonicalPath":"/agent/clawhub-anderskev-resolve-beagle","generatedAt":"2026-10-11T15:14:22.147Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T12:32:37.954Z","emptyReason":null},"description":"Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or imp... Skill: Resolve Beagle Owner: anderskev Summary: Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or imp... Tags: latest:1.0.3 Version history: v1.0.3 | 2026-06-25T05:40:25.417Z | auto resolve-beagle 1.0.3 - Removed file: skill-card.md - Expanded latent gap detection in SKILL.md to include unconsumed external surfaces","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17b1fzefm8nj8j1sdkzrze7gn83pfrg:resolve-beagle","sourceUrl":"https://clawhub.ai/anderskev/resolve-beagle","homepage":"https://clawhub.ai/anderskev/skills/resolve-beagle","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/anderskev/resolve-beagle","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/anderskev/skills/resolve-beagle","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or imp..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T12:32:37.954Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T12:32:37.954Z","emptyReason":null},"stars":null,"forks":null,"downloads":1064,"packageName":null,"latestVersion":"1.0.3","tractionLabel":"1.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T12:32:37.888Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T12:32:37.954Z","lastCrawledAt":"2026-10-11T12:32:37.888Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T12:32:37.888Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.3","createdAt":"2026-06-25T05:40:25.417Z","changelog":"resolve-beagle 1.0.3 - Removed file: `skill-card.md` - Expanded latent gap detection in SKILL.md to include unconsumed external surfaces and unresolved composition with upstream/downstream mechanisms - Clarified and detailed the definitions and identification of latent gaps in the workflow - No functional code changes; update strictly to documentation and process description","fileCount":4,"zipByteSize":8972},{"version":"1.0.2","createdAt":"2026-06-01T02:21:57.676Z","changelog":"resolve-beagle 1.0.2 - Clarified instructions on research task types and tool usage in the workflow section. - Updated language and table examples for codebase and API research to improve specificity. - Refined guidance on subagent dispatch, especially regarding agent support for subagents. - Removed outdated documentation file: skill-card.md.","fileCount":4,"zipByteSize":8697},{"version":"1.0.1","createdAt":"2026-04-22T04:10:15.412Z","changelog":"**Added objective process gates to enforce workflow discipline before each step.** - Introduced a new \"Gates\" section defining explicit, checklisted pass conditions for each workflow stage (spec location, gap list publication, research artifact, proposal queue, reconciliation, commit prompt), ensuring no step can be skipped by assertion alone. - Clarified that research tasks for unresolved gaps must produce structured artifacts before user proposals. - Made it mandatory to publish the combined gap list and get user approval/adjustment before any research. - Strengthened requirements for spec reconciliation and running a self-review pass before edit commits. - No functional changes to scrape/gap extraction logic, research methods, or proposal flows.","fileCount":4,"zipByteSize":8749},{"version":"1.0.0","createdAt":"2026-04-18T15:03:25.965Z","changelog":"resolve-beagle 1.0.0 - Initial release providing automated gap-closing for specs generated by brainstorm-beagle. - Identifies and classifies both explicit open questions and latent gaps (e.g., placeholders, vague requirements, contradictions) in spec documents. - Presents a consolidated gap list for user review and customization before research begins. - Dispatches parallel research tasks via subagents when available; otherwise operates sequentially. - Proposes structured answers (with recommendations, alternatives, and supporting evidence) for user approval, one gap at a time. - Updates the spec in place, ensuring all resolved items are properly integrated with full rationale and self-review. - Does not write code, design implementation, or create plans—focuses solely on producing a complete, implementation-ready spec.","fileCount":3,"zipByteSize":6959}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17b1fzefm8nj8j1sdkzrze7gn83pfrg:resolve-beagle","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-anderskev-resolve-beagle/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-anderskev-resolve-beagle/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-anderskev-resolve-beagle/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-anderskev-resolve-beagle/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-anderskev-resolve-beagle/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-anderskev-resolve-beagle/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T15:14:22.144Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-anderskev-resolve-beagle/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-anderskev-resolve-beagle/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-anderskev-resolve-beagle/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-anderskev-resolve-beagle/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T12:32:37.954Z","emptyReason":null},"readme":"Skill: Resolve Beagle\n\nOwner: anderskev\n\nSummary: Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or imp...\n\nTags: latest:1.0.3\n\nVersion history:\n\nv1.0.3 | 2026-06-25T05:40:25.417Z | auto\n\nresolve-beagle 1.0.3\n\n- Removed file: `skill-card.md`\n- Expanded latent gap detection in SKILL.md to include unconsumed external surfaces and unresolved composition with upstream/downstream mechanisms\n- Clarified and detailed the definitions and identification of latent gaps in the workflow\n- No functional code changes; update strictly to documentation and process description\n\nv1.0.2 | 2026-06-01T02:21:57.676Z | auto\n\nresolve-beagle 1.0.2\n\n- Clarified instructions on research task types and tool usage in the workflow section.\n- Updated language and table examples for codebase and API research to improve specificity.\n- Refined guidance on subagent dispatch, especially regarding agent support for subagents.\n- Removed outdated documentation file: skill-card.md.\n\nv1.0.1 | 2026-04-22T04:10:15.412Z | auto\n\n**Added objective process gates to enforce workflow discipline before each step.**\n\n- Introduced a new \"Gates\" section defining explicit, checklisted pass conditions for each workflow stage (spec location, gap list publication, research artifact, proposal queue, reconciliation, commit prompt), ensuring no step can be skipped by assertion alone.\n- Clarified that research tasks for unresolved gaps must produce structured artifacts before user proposals.\n- Made it mandatory to publish the combined gap list and get user approval/adjustment before any research.\n- Strengthened requirements for spec reconciliation and running a self-review pass before edit commits.\n- No functional changes to scrape/gap extraction logic, research methods, or proposal flows.\n\nv1.0.0 | 2026-04-18T15:03:25.965Z | auto\n\nresolve-beagle 1.0.0\n\n- Initial release providing automated gap-closing for specs generated by brainstorm-beagle.\n- Identifies and classifies both explicit open questions and latent gaps (e.g., placeholders, vague requirements, contradictions) in spec documents.\n- Presents a consolidated gap list for user review and customization before research begins.\n- Dispatches parallel research tasks via subagents when available; otherwise operates sequentially.\n- Proposes structured answers (with recommendations, alternatives, and supporting evidence) for user approval, one gap at a time.\n- Updates the spec in place, ensuring all resolved items are properly integrated with full rationale and self-review.\n- Does not write code, design implementation, or create plans—focuses solely on producing a complete, implementation-ready spec.\n\nArchive index:\n\nArchive v1.0.3: 4 files, 8972 bytes\n\nFiles: references/subagent-prompts.md (6124b), skill-card.md (2131b), SKILL.md (12577b), _meta.json (133b)\n\nFile v1.0.3:SKILL.md\n\n---\nname: resolve-beagle\ndescription: \"Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or implementation can begin. Triggers on: \\\"resolve the open questions\\\", \\\"close the gaps in this spec\\\", \\\"research the open items\\\", \\\"finalize my spec\\\", \\\"make this spec implementation-ready\\\", \\\"answer the TBDs\\\". Also triggers whenever the user points at a brainstorm-beagle spec and asks for research, proposals, or answers to unresolved items. Orchestrates parallel research subagents when available (falls back to inline sequential research otherwise), proposes answers one at a time for user approval, then rewrites the spec in place so it arrives at planning with no known gaps. Does NOT write code, design implementation, or create plans — it only produces a complete spec.\"\n---\n\n# Resolve: Close Spec Gaps\n\nTake a spec produced by `brainstorm-beagle` and close its remaining gaps — both the explicit Open Questions and the latent ones the self-review missed — by researching, proposing answers, and rewriting the spec in place.\n\nThe terminal state is a spec with no known open questions and no placeholder requirements. Planning can start immediately after.\n\n<hard_gate>\nThis skill does not write code, scaffold projects, design architecture, or create implementation plans. It only edits the spec document. \"Answering an open question\" means proposing a WHAT/WHY answer with rationale — never a HOW. If a question turns out to require implementation design, defer it with a note and move on.\n</hard_gate>\n\n## Gates (pass before next step)\n\nObjective pass conditions so steps are not skippable by assertion alone:\n\n1. **Spec located** — The target file path is known and `Read` succeeds (or the user supplied a valid path after you listed 3–5 recent `docs/specs/` candidates).\n2. **Gap list published** — One message lists every explicit Open Question bullet **and** each latent gap you will treat as in-scope. **Do not dispatch research** until the user adjusts the list (add/remove/defer) **or** explicitly tells you to proceed with that list.\n3. **Research artifact per gap** — Before you present a proposal for gap *G*, you have a structured note for *G*: recommended answer, 1–2 rejected alternatives with reasons, and evidence (file:line, URL, or in-spec citation). No proposal without that artifact.\n4. **One proposal queue** — Do not open the next gap’s proposal until the current gap has a clear outcome (accepted, revised wording applied, rejected with what happens next, or deferred with reason).\n5. **Rewrite reconciled** — After editing, you read the full spec once and resolve cross-section contradictions; then run the self-review checklist from `../brainstorm-beagle/references/spec-reviewer.md` with failures fixed in-session unless the user opts for a follow-up pass.\n6. **Commit** — No `git commit` unless the user answered yes to the commit prompt in § Committing.\n\n## Workflow\n\n1. **Locate the spec** — explicit path from the user, or the most recent file in `docs/specs/`\n2. **Extract gaps** — parse Open Questions *and* audit for latent issues (placeholders, vague requirements, missing rationale, contradictions)\n3. **Show the gap list** — present everything you plan to close in one summary so the user can add or remove items before research starts\n4. **Dispatch research** — one task per gap, in parallel via subagents when available; otherwise sequentially inline\n5. **Propose answers** — one proposal at a time, with recommendation + alternatives + evidence\n6. **Rewrite the spec in place** — migrate resolved items to the right sections; nothing silently dropped\n7. **Self-review** — same checklist `brainstorm-beagle` uses (see `../brainstorm-beagle/references/spec-reviewer.md`)\n8. **Ask about committing** — prompt the user whether to commit the edit; don't commit unprompted\n\n```\nLocate spec → Extract gaps → Show list ──→ User adds/removes\n                                          → Dispatch research (parallel if possible)\n                                          → Propose answers (one at a time)\n                                                → User decision → next\n                                          → Rewrite spec in place\n                                          → Self-review (fix inline)\n                                          → Ask about committing\n```\n\n## Locating the spec\n\nIf the user gave a path, use it.\n\nOtherwise, list the 3–5 most recently modified files in `docs/specs/` and ask: \"Work on `<most recent>`, or another one?\" Don't scan the whole directory tree — specs are top-level per `brainstorm-beagle`'s convention.\n\nIf no spec directory exists, ask the user for the path.\n\n## Extracting gaps\n\nTwo categories count as gaps:\n\n**Explicit gaps** — every bullet under the spec's `Open Questions` heading is one research task.\n\n**Latent gaps** — issues that slipped past the brainstorm's self-review. Scan the spec for:\n\n| Problem | What it looks like |\n|---------|-------------------|\n| Placeholder | TBD, TODO, \"to be determined\", ellipsis used as content |\n| Vague requirement | \"fast\", \"simple\", \"good\", \"user-friendly\", \"intuitive\" — nothing to verify against |\n| Missing rationale | Constraint or Out-of-Scope item with no \"why\" |\n| Contradiction | Requirement conflicts with another requirement, with a constraint, or with Out of Scope |\n| Untestable success | No observable way to verify the requirement was met |\n| Implementation leakage | A requirement prescribes HOW instead of describing WHAT |\n| Unconsumed surface | A must-have introduces new externally-facing surface (API surface, command, endpoint, exported contract) that nothing else in the spec consumes |\n| Unresolved composition | An existing mechanism sits upstream/downstream in the same data pipeline and transforms (truncate, filter, buffer, reorder, dedupe) the data the feature depends on, but its composition with the feature is left unexamined |\n\nThe reason to treat latent gaps as first-class: a spec that says \"fast\" or \"good UX\" hasn't been answered just because nothing was explicitly flagged. Planning will trip over those same words. Close them here.\n\nBefore dispatching research, show the combined list to the user in one message — \"here's what I'm planning to close\" — and let them add, remove, or defer items. Don't ask permission one-by-one; that's the proposal step.\n\n## Dispatching research\n\nEach gap gets exactly one research task. Classify each task first — the type determines which tools the research needs:\n\n| Task type | Looks like | Tools |\n|-----------|-----------|-------|\n| Codebase pattern | \"How does the existing `--start-at` pattern work?\" \"Where is `SKILL_MAP` defined?\" | search the codebase (grep/glob/read) |\n| External / API | \"What does the agent's SDK expose for sub-agent spawning?\" \"Does Codex have hooks?\" | web search and page fetch (if web access is available) |\n| Design tradeoff | \"What should the merged report format be?\" \"How should deduplication work?\" | Reasoning + analogous reference points already in the spec |\n| Scope / policy | \"Should config/docs files route to a stack or fallback?\" | Reasoning tied to the spec's own Core Value and Constraints |\n\n### With subagents (preferred)\n\n**If the agent supports subagents**, dispatch each research task as an independent subagent — **all in the same turn**, so they run in parallel. Each subagent gets its own context window, which matters: gaps often come with large supporting context (the spec, the codebase) that you don't want crammed into a single conversation.\n\nSee `references/subagent-prompts.md` for the prompt templates (one per task type).\n\nThe research return must be structured: recommended answer, 1–2 alternatives with why rejected, and concrete evidence (file:line citations, URLs, or references to existing spec sections). Cap each return at ~300 words — you want decisions, not transcripts.\n\n### Without subagents\n\nIf no subagent tool is available, do the research yourself, one question at a time. Work in cheapest-first order: codebase questions, then external, then tradeoffs, then scope/policy. Produce the same structured proposal for each. This is slower but never leaves gaps unresolved.\n\n## Proposing answers\n\nPresent proposals **one at a time**. For each:\n\n- **The gap** — restated in one line\n- **Recommended answer** — your best call, with WHY\n- **Alternatives** — 1–2 credible options and why they were rejected\n- **Evidence** — file:line citations, URLs, or references to decisions already in the spec\n\nThe user can accept, revise, or reject. Follow the thread if they want to discuss; move on once decided.\n\n**Order matters.** Resolve in this rough sequence:\n\n1. Codebase-reality gaps first (they may inform design tradeoffs)\n2. Policy/scope gaps second (they shape everything downstream)\n3. Format/presentation gaps last (they depend on the above)\n\nWhen a gap can't be resolved without input only the user has (budgets, stakeholder preferences, unstated constraints), don't guess — ask directly. It's cheaper than proposing the wrong answer and unwinding it.\n\n## Rewriting the spec\n\nAs decisions land, migrate them to where they belong:\n\n| Gap type | Destination after resolution |\n|----------|-----------------------------|\n| Architectural or policy decision | New entry under **Key Decisions** (with alternatives considered) |\n| Concrete behavior | New entry under **Requirements** (assigned must/should/out-of-scope) |\n| Hard limit | New entry under **Constraints** (with rationale) |\n| External reference discovered during research | New entry under **Reference Points** |\n| Vague requirement replaced | Rewrite the existing requirement inline; do not duplicate |\n| Intentionally deferred | Stays in **Open Questions** with a `deferred: <reason>` suffix |\n\nTwo rules that matter:\n\n- **Never silently drop an Open Question.** Either resolve it, migrate it with rationale, or explicitly defer it with a reason. Dropping a question without a trail is how specs regress between sessions.\n- **Rewrite the whole spec, not just the touched sections.** Changes ripple: a new Key Decision may contradict an old Requirement, a resolved Open Question may invalidate a Constraint. Read the spec end-to-end after edits and reconcile.\n\n## Self-review\n\nRun the checks from `../brainstorm-beagle/references/spec-reviewer.md`:\n\n- No placeholders\n- No contradictions\n- No implementation leakage\n- All requirements testable\n- Constraints and Out-of-Scope items have rationale\n- No new externally-facing surface (API surface, command, endpoint, exported contract) without a named consumer — name it or move it to Future Considerations\n- Any existing upstream/downstream pipeline mechanism that transforms the feature's data is recorded as a Key Decision tagged `needs-spike-before-planning`, not left unexamined\n\nFix anything that surfaces inline before handing back to the user. If new gaps appear during the rewrite (they sometimes do), add them to a \"new gaps surfaced\" list and ask the user whether to resolve them now or leave for a later pass.\n\n## Committing\n\nAfter the rewrite, summarize and ask:\n\n> \"Spec updated. Resolved N explicit questions and M latent gaps. Want me to commit this as `docs: resolve open questions in <topic> spec`?\"\n\nIf yes, commit. If no, leave the working tree for the user. Do not commit unprompted — the user may want to review the diff first or bundle it with other changes.\n\n## Key Principles\n\n- **Close the loop.** The goal is a spec with nothing unanswered that blocks planning. Half-resolved is worse than clearly deferred.\n- **One research task per gap.** Don't blur tasks together — it makes the proposal step harder to review and weakens the evidence trail.\n- **Evidence over opinion.** Every proposal cites something — a file, a URL, or an existing spec decision. \"I think\" is not enough.\n- **Still WHAT, not HOW.** Answers land as decisions in the spec, not as implementation designs. If an answer requires implementation thinking, defer it.\n- **Defer honestly.** A question too expensive to answer now stays an Open Question with a one-line reason. Better to admit a known gap than paper over it.\n- **Parallelize when you can.** Subagents run in isolation — fan out aggressively. Sequential research is the fallback, not the default.\n- **Don't interrupt unnecessarily.** Show the gap list once, then only stop the user for decisions that need human judgment.\n\nFile v1.0.3:_meta.json\n\n{\n  \"ownerId\": \"kn79190nfmdb20hk6xjhzt2zv583844x\",\n  \"slug\": \"resolve-beagle\",\n  \"version\": \"1.0.3\",\n  \"publishedAt\": 1782366025417\n}\n\nFile v1.0.3:references/subagent-prompts.md\n\n# Subagent Prompt Templates\n\nUse these when dispatching research tasks to subagents. One task per subagent. Launch all subagents in a single turn so they run in parallel.\n\nEvery template ends with the same **return format** — a structured proposal the orchestrator can drop directly into the spec. Don't let subagents return free-form prose; decisions are the deliverable, not transcripts.\n\n## Return format (shared across all templates)\n\nEvery subagent must return exactly this structure, ~300 words max:\n\n```\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY>\n\n## Alternatives considered\n- <alternative 1> — rejected because <reason>\n- <alternative 2> — rejected because <reason>\n\n## Evidence\n- <file:line citation, URL, or reference to an existing spec section>\n- <additional citations as needed>\n\n## Open sub-questions (if any)\n- <anything the subagent couldn't resolve and needs the user or orchestrator to decide>\n```\n\nIf the subagent cannot produce a recommendation with evidence, it should say so explicitly in \"Open sub-questions\" rather than guess.\n\n---\n\n## Template: Codebase pattern\n\nUse when the question is about how the existing codebase works — an API, a pattern, a file layout, a convention that the spec references.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: read the relevant code and return a structured proposal answering the question. Use Grep, Glob, and Read. Do not modify any files.\n\nScope hints:\n- <file/dir hints from the spec, if any>\n- <reference points mentioned in the spec>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what you found>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, citing code>\n- <alt 2> — rejected because <reason, citing code>\n\n## Evidence\n- <file:line> — <one-line description of what's there>\n- <file:line> — <one-line description>\n\n## Open sub-questions\n- <anything that needs user input or is blocked>\n\nCap the return at ~300 words. Cite file paths and line numbers. Decisions, not transcripts.\n```\n\n## Template: External / API\n\nUse when the question is about an external system — a framework's capabilities, an SDK's API, a tool's behavior.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: use web search and page fetch (if web access is available) to find authoritative answers — official docs, source repositories, maintainer statements. Avoid blog posts and secondhand summaries.\n\nFocus area: <framework / SDK / tool name>\nWhy it matters: <one-line context pulled from the spec's Problem Statement or Key Decisions>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what the official source says>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, citing source>\n- <alt 2> — rejected because <reason, citing source>\n\n## Evidence\n- <URL> — <one-line description of what it says>\n- <URL> — <one-line description>\n\n## Open sub-questions\n- <anything version-specific, ambiguous, or that needs user confirmation>\n\nCap the return at ~300 words. Prefer primary sources. Decisions, not transcripts.\n```\n\n## Template: Design tradeoff\n\nUse when the question is a product/design judgment call with no single \"right answer\" in the codebase or external docs — format decisions, deduplication heuristics, UX structure.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: reason about the tradeoff and produce a concrete recommendation grounded in the spec's own Core Value, Problem Statement, and Key Decisions. Reference the spec heavily — the right answer usually already lives implicit in the rest of the document.\n\nDo NOT propose implementation details. The answer goes into the spec as a WHAT/WHY decision, not a HOW.\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — explicitly citing which spec section supports the choice>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, ideally citing a spec section it would undermine>\n- <alt 2> — rejected because <reason>\n\n## Evidence\n- Spec section \"<section name>\" — <what it says that informs this>\n- <additional analogies or reference points if relevant>\n\n## Open sub-questions\n- <anything that needs the user's judgment (preferences, budgets, unstated constraints)>\n\nCap the return at ~300 words. Ground the call in the spec. Decisions, not transcripts.\n```\n\n## Template: Scope / policy\n\nUse when the question is about inclusion/exclusion — what routes where, what's covered, what's explicitly out.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: recommend the scope/policy answer that best preserves the spec's Core Value and is consistent with its existing Out-of-Scope rationale. Read the spec end-to-end before deciding — scope answers regress fast if you only look at the local question.\n\nDo NOT propose implementation details. The answer goes into the spec as a WHAT/WHY decision.\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — showing it aligns with Core Value and existing Out-of-Scope reasoning>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, ideally showing it conflicts with a stated constraint>\n- <alt 2> — rejected because <reason>\n\n## Evidence\n- Spec section \"Core Value\" — <relevant phrase>\n- Spec section \"Out of Scope\" — <relevant rationale>\n- <other spec sections as needed>\n\n## Open sub-questions\n- <anything that needs user input on future intent>\n\nCap the return at ~300 words. Consistency with the spec matters more than novelty. Decisions, not transcripts.\n```\n\nFile v1.0.3:skill-card.md\n\n## Description:\n\nResolve Beagle helps agents close open questions and latent gaps in a brainstorm-beagle spec by researching issues, proposing evidence-backed answers for user approval, and rewriting the spec in place.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[anderskev](https://clawhub.ai/user/anderskev)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, product owners, and spec authors use this skill to turn a brainstorm-beagle spec with open questions, placeholders, or ambiguous requirements into an implementation-ready spec before planning starts.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can read project files, use external web research, and rewrite the target spec in place.\n\nMitigation: Use it on specs the agent is allowed to inspect and edit, and review the proposed gap list before allowing research to proceed.\n\nRisk: Accepted proposals could introduce incorrect or misleading requirements into a planning document.\n\nMitigation: Review each evidence-backed proposal before acceptance and re-read the rewritten spec before planning begins.\n\nRisk: The workflow may create a commit if the user approves it.\n\nMitigation: Require explicit user approval before any commit and inspect the resulting diff when repository history matters.\n\n## Reference(s):\n\n- [Subagent Prompt Templates](references/subagent-prompts.md)\n- [Resolve Beagle ClawHub Listing](https://clawhub.ai/anderskev/skills/resolve-beagle)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Guidance, Files]\n\n**Output Format:** [Markdown spec edits with structured proposal text]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Requires user confirmation before research proceeds and before any commit.]\n\n## Skill Version(s):\n\n1.0.3 (source: server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.2: 4 files, 8697 bytes\n\nFiles: references/subagent-prompts.md (6124b), skill-card.md (2117b), SKILL.md (11821b), _meta.json (133b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: resolve-beagle\ndescription: \"Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or implementation can begin. Triggers on: \\\"resolve the open questions\\\", \\\"close the gaps in this spec\\\", \\\"research the open items\\\", \\\"finalize my spec\\\", \\\"make this spec implementation-ready\\\", \\\"answer the TBDs\\\". Also triggers whenever the user points at a brainstorm-beagle spec and asks for research, proposals, or answers to unresolved items. Orchestrates parallel research subagents when available (falls back to inline sequential research otherwise), proposes answers one at a time for user approval, then rewrites the spec in place so it arrives at planning with no known gaps. Does NOT write code, design implementation, or create plans — it only produces a complete spec.\"\n---\n\n# Resolve: Close Spec Gaps\n\nTake a spec produced by `brainstorm-beagle` and close its remaining gaps — both the explicit Open Questions and the latent ones the self-review missed — by researching, proposing answers, and rewriting the spec in place.\n\nThe terminal state is a spec with no known open questions and no placeholder requirements. Planning can start immediately after.\n\n<hard_gate>\nThis skill does not write code, scaffold projects, design architecture, or create implementation plans. It only edits the spec document. \"Answering an open question\" means proposing a WHAT/WHY answer with rationale — never a HOW. If a question turns out to require implementation design, defer it with a note and move on.\n</hard_gate>\n\n## Gates (pass before next step)\n\nObjective pass conditions so steps are not skippable by assertion alone:\n\n1. **Spec located** — The target file path is known and `Read` succeeds (or the user supplied a valid path after you listed 3–5 recent `docs/specs/` candidates).\n2. **Gap list published** — One message lists every explicit Open Question bullet **and** each latent gap you will treat as in-scope. **Do not dispatch research** until the user adjusts the list (add/remove/defer) **or** explicitly tells you to proceed with that list.\n3. **Research artifact per gap** — Before you present a proposal for gap *G*, you have a structured note for *G*: recommended answer, 1–2 rejected alternatives with reasons, and evidence (file:line, URL, or in-spec citation). No proposal without that artifact.\n4. **One proposal queue** — Do not open the next gap’s proposal until the current gap has a clear outcome (accepted, revised wording applied, rejected with what happens next, or deferred with reason).\n5. **Rewrite reconciled** — After editing, you read the full spec once and resolve cross-section contradictions; then run the self-review checklist from `../brainstorm-beagle/references/spec-reviewer.md` with failures fixed in-session unless the user opts for a follow-up pass.\n6. **Commit** — No `git commit` unless the user answered yes to the commit prompt in § Committing.\n\n## Workflow\n\n1. **Locate the spec** — explicit path from the user, or the most recent file in `docs/specs/`\n2. **Extract gaps** — parse Open Questions *and* audit for latent issues (placeholders, vague requirements, missing rationale, contradictions)\n3. **Show the gap list** — present everything you plan to close in one summary so the user can add or remove items before research starts\n4. **Dispatch research** — one task per gap, in parallel via subagents when available; otherwise sequentially inline\n5. **Propose answers** — one proposal at a time, with recommendation + alternatives + evidence\n6. **Rewrite the spec in place** — migrate resolved items to the right sections; nothing silently dropped\n7. **Self-review** — same checklist `brainstorm-beagle` uses (see `../brainstorm-beagle/references/spec-reviewer.md`)\n8. **Ask about committing** — prompt the user whether to commit the edit; don't commit unprompted\n\n```\nLocate spec → Extract gaps → Show list ──→ User adds/removes\n                                          → Dispatch research (parallel if possible)\n                                          → Propose answers (one at a time)\n                                                → User decision → next\n                                          → Rewrite spec in place\n                                          → Self-review (fix inline)\n                                          → Ask about committing\n```\n\n## Locating the spec\n\nIf the user gave a path, use it.\n\nOtherwise, list the 3–5 most recently modified files in `docs/specs/` and ask: \"Work on `<most recent>`, or another one?\" Don't scan the whole directory tree — specs are top-level per `brainstorm-beagle`'s convention.\n\nIf no spec directory exists, ask the user for the path.\n\n## Extracting gaps\n\nTwo categories count as gaps:\n\n**Explicit gaps** — every bullet under the spec's `Open Questions` heading is one research task.\n\n**Latent gaps** — issues that slipped past the brainstorm's self-review. Scan the spec for:\n\n| Problem | What it looks like |\n|---------|-------------------|\n| Placeholder | TBD, TODO, \"to be determined\", ellipsis used as content |\n| Vague requirement | \"fast\", \"simple\", \"good\", \"user-friendly\", \"intuitive\" — nothing to verify against |\n| Missing rationale | Constraint or Out-of-Scope item with no \"why\" |\n| Contradiction | Requirement conflicts with another requirement, with a constraint, or with Out of Scope |\n| Untestable success | No observable way to verify the requirement was met |\n| Implementation leakage | A requirement prescribes HOW instead of describing WHAT |\n\nThe reason to treat latent gaps as first-class: a spec that says \"fast\" or \"good UX\" hasn't been answered just because nothing was explicitly flagged. Planning will trip over those same words. Close them here.\n\nBefore dispatching research, show the combined list to the user in one message — \"here's what I'm planning to close\" — and let them add, remove, or defer items. Don't ask permission one-by-one; that's the proposal step.\n\n## Dispatching research\n\nEach gap gets exactly one research task. Classify each task first — the type determines which tools the research needs:\n\n| Task type | Looks like | Tools |\n|-----------|-----------|-------|\n| Codebase pattern | \"How does the existing `--start-at` pattern work?\" \"Where is `SKILL_MAP` defined?\" | search the codebase (grep/glob/read) |\n| External / API | \"What does the agent's SDK expose for sub-agent spawning?\" \"Does Codex have hooks?\" | web search and page fetch (if web access is available) |\n| Design tradeoff | \"What should the merged report format be?\" \"How should deduplication work?\" | Reasoning + analogous reference points already in the spec |\n| Scope / policy | \"Should config/docs files route to a stack or fallback?\" | Reasoning tied to the spec's own Core Value and Constraints |\n\n### With subagents (preferred)\n\n**If the agent supports subagents**, dispatch each research task as an independent subagent — **all in the same turn**, so they run in parallel. Each subagent gets its own context window, which matters: gaps often come with large supporting context (the spec, the codebase) that you don't want crammed into a single conversation.\n\nSee `references/subagent-prompts.md` for the prompt templates (one per task type).\n\nThe research return must be structured: recommended answer, 1–2 alternatives with why rejected, and concrete evidence (file:line citations, URLs, or references to existing spec sections). Cap each return at ~300 words — you want decisions, not transcripts.\n\n### Without subagents\n\nIf no subagent tool is available, do the research yourself, one question at a time. Work in cheapest-first order: codebase questions, then external, then tradeoffs, then scope/policy. Produce the same structured proposal for each. This is slower but never leaves gaps unresolved.\n\n## Proposing answers\n\nPresent proposals **one at a time**. For each:\n\n- **The gap** — restated in one line\n- **Recommended answer** — your best call, with WHY\n- **Alternatives** — 1–2 credible options and why they were rejected\n- **Evidence** — file:line citations, URLs, or references to decisions already in the spec\n\nThe user can accept, revise, or reject. Follow the thread if they want to discuss; move on once decided.\n\n**Order matters.** Resolve in this rough sequence:\n\n1. Codebase-reality gaps first (they may inform design tradeoffs)\n2. Policy/scope gaps second (they shape everything downstream)\n3. Format/presentation gaps last (they depend on the above)\n\nWhen a gap can't be resolved without input only the user has (budgets, stakeholder preferences, unstated constraints), don't guess — ask directly. It's cheaper than proposing the wrong answer and unwinding it.\n\n## Rewriting the spec\n\nAs decisions land, migrate them to where they belong:\n\n| Gap type | Destination after resolution |\n|----------|-----------------------------|\n| Architectural or policy decision | New entry under **Key Decisions** (with alternatives considered) |\n| Concrete behavior | New entry under **Requirements** (assigned must/should/out-of-scope) |\n| Hard limit | New entry under **Constraints** (with rationale) |\n| External reference discovered during research | New entry under **Reference Points** |\n| Vague requirement replaced | Rewrite the existing requirement inline; do not duplicate |\n| Intentionally deferred | Stays in **Open Questions** with a `deferred: <reason>` suffix |\n\nTwo rules that matter:\n\n- **Never silently drop an Open Question.** Either resolve it, migrate it with rationale, or explicitly defer it with a reason. Dropping a question without a trail is how specs regress between sessions.\n- **Rewrite the whole spec, not just the touched sections.** Changes ripple: a new Key Decision may contradict an old Requirement, a resolved Open Question may invalidate a Constraint. Read the spec end-to-end after edits and reconcile.\n\n## Self-review\n\nRun the checks from `../brainstorm-beagle/references/spec-reviewer.md`:\n\n- No placeholders\n- No contradictions\n- No implementation leakage\n- All requirements testable\n- Constraints and Out-of-Scope items have rationale\n\nFix anything that surfaces inline before handing back to the user. If new gaps appear during the rewrite (they sometimes do), add them to a \"new gaps surfaced\" list and ask the user whether to resolve them now or leave for a later pass.\n\n## Committing\n\nAfter the rewrite, summarize and ask:\n\n> \"Spec updated. Resolved N explicit questions and M latent gaps. Want me to commit this as `docs: resolve open questions in <topic> spec`?\"\n\nIf yes, commit. If no, leave the working tree for the user. Do not commit unprompted — the user may want to review the diff first or bundle it with other changes.\n\n## Key Principles\n\n- **Close the loop.** The goal is a spec with nothing unanswered that blocks planning. Half-resolved is worse than clearly deferred.\n- **One research task per gap.** Don't blur tasks together — it makes the proposal step harder to review and weakens the evidence trail.\n- **Evidence over opinion.** Every proposal cites something — a file, a URL, or an existing spec decision. \"I think\" is not enough.\n- **Still WHAT, not HOW.** Answers land as decisions in the spec, not as implementation designs. If an answer requires implementation thinking, defer it.\n- **Defer honestly.** A question too expensive to answer now stays an Open Question with a one-line reason. Better to admit a known gap than paper over it.\n- **Parallelize when you can.** Subagents run in isolation — fan out aggressively. Sequential research is the fallback, not the default.\n- **Don't interrupt unnecessarily.** Show the gap list once, then only stop the user for decisions that need human judgment.\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn79190nfmdb20hk6xjhzt2zv583844x\",\n  \"slug\": \"resolve-beagle\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1780280517676\n}\n\nFile v1.0.2:references/subagent-prompts.md\n\n# Subagent Prompt Templates\n\nUse these when dispatching research tasks to subagents. One task per subagent. Launch all subagents in a single turn so they run in parallel.\n\nEvery template ends with the same **return format** — a structured proposal the orchestrator can drop directly into the spec. Don't let subagents return free-form prose; decisions are the deliverable, not transcripts.\n\n## Return format (shared across all templates)\n\nEvery subagent must return exactly this structure, ~300 words max:\n\n```\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY>\n\n## Alternatives considered\n- <alternative 1> — rejected because <reason>\n- <alternative 2> — rejected because <reason>\n\n## Evidence\n- <file:line citation, URL, or reference to an existing spec section>\n- <additional citations as needed>\n\n## Open sub-questions (if any)\n- <anything the subagent couldn't resolve and needs the user or orchestrator to decide>\n```\n\nIf the subagent cannot produce a recommendation with evidence, it should say so explicitly in \"Open sub-questions\" rather than guess.\n\n---\n\n## Template: Codebase pattern\n\nUse when the question is about how the existing codebase works — an API, a pattern, a file layout, a convention that the spec references.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: read the relevant code and return a structured proposal answering the question. Use Grep, Glob, and Read. Do not modify any files.\n\nScope hints:\n- <file/dir hints from the spec, if any>\n- <reference points mentioned in the spec>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what you found>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, citing code>\n- <alt 2> — rejected because <reason, citing code>\n\n## Evidence\n- <file:line> — <one-line description of what's there>\n- <file:line> — <one-line description>\n\n## Open sub-questions\n- <anything that needs user input or is blocked>\n\nCap the return at ~300 words. Cite file paths and line numbers. Decisions, not transcripts.\n```\n\n## Template: External / API\n\nUse when the question is about an external system — a framework's capabilities, an SDK's API, a tool's behavior.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: use web search and page fetch (if web access is available) to find authoritative answers — official docs, source repositories, maintainer statements. Avoid blog posts and secondhand summaries.\n\nFocus area: <framework / SDK / tool name>\nWhy it matters: <one-line context pulled from the spec's Problem Statement or Key Decisions>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what the official source says>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, citing source>\n- <alt 2> — rejected because <reason, citing source>\n\n## Evidence\n- <URL> — <one-line description of what it says>\n- <URL> — <one-line description>\n\n## Open sub-questions\n- <anything version-specific, ambiguous, or that needs user confirmation>\n\nCap the return at ~300 words. Prefer primary sources. Decisions, not transcripts.\n```\n\n## Template: Design tradeoff\n\nUse when the question is a product/design judgment call with no single \"right answer\" in the codebase or external docs — format decisions, deduplication heuristics, UX structure.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: reason about the tradeoff and produce a concrete recommendation grounded in the spec's own Core Value, Problem Statement, and Key Decisions. Reference the spec heavily — the right answer usually already lives implicit in the rest of the document.\n\nDo NOT propose implementation details. The answer goes into the spec as a WHAT/WHY decision, not a HOW.\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — explicitly citing which spec section supports the choice>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, ideally citing a spec section it would undermine>\n- <alt 2> — rejected because <reason>\n\n## Evidence\n- Spec section \"<section name>\" — <what it says that informs this>\n- <additional analogies or reference points if relevant>\n\n## Open sub-questions\n- <anything that needs the user's judgment (preferences, budgets, unstated constraints)>\n\nCap the return at ~300 words. Ground the call in the spec. Decisions, not transcripts.\n```\n\n## Template: Scope / policy\n\nUse when the question is about inclusion/exclusion — what routes where, what's covered, what's explicitly out.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: recommend the scope/policy answer that best preserves the spec's Core Value and is consistent with its existing Out-of-Scope rationale. Read the spec end-to-end before deciding — scope answers regress fast if you only look at the local question.\n\nDo NOT propose implementation details. The answer goes into the spec as a WHAT/WHY decision.\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — showing it aligns with Core Value and existing Out-of-Scope reasoning>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, ideally showing it conflicts with a stated constraint>\n- <alt 2> — rejected because <reason>\n\n## Evidence\n- Spec section \"Core Value\" — <relevant phrase>\n- Spec section \"Out of Scope\" — <relevant rationale>\n- <other spec sections as needed>\n\n## Open sub-questions\n- <anything that needs user input on future intent>\n\nCap the return at ~300 words. Consistency with the spec matters more than novelty. Decisions, not transcripts.\n```\n\nFile v1.0.2:skill-card.md\n\n## Description: <br>\nResolve Beagle helps an agent close explicit and latent gaps in a brainstormed spec by researching open items, proposing answers for approval, and rewriting the spec so planning can begin. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[anderskev](https://clawhub.ai/user/anderskev) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and specification authors use this skill after brainstorming to resolve open questions, clarify latent gaps, and produce an implementation-ready spec without moving into design or coding. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill can guide agents through ClawHub and Convex operational workflows and may involve sensitive staff actions. <br>\nMitigation: Confirm targets before live staff actions, use appropriate authorization, and avoid broad full-access autoreview modes unless they are needed. <br>\nRisk: Research proposals may add incorrect or misleading decisions to a specification. <br>\nMitigation: Require evidence for each proposal, present one proposal at a time for user approval, and run the self-review checklist before finishing. <br>\n\n\n## Reference(s): <br>\n- [Subagent Prompt Templates](references/subagent-prompts.md) <br>\n- [ClawHub Skill Page](https://clawhub.ai/anderskev/resolve-beagle) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown prose with structured proposals and in-place spec edits] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include recommended answers, rejected alternatives, evidence citations, updated spec content, and commit prompts.] <br>\n\n## Skill Version(s): <br>\n1.0.2 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.1: 4 files, 8749 bytes\n\nFiles: references/subagent-prompts.md (6118b), skill-card.md (2234b), SKILL.md (11816b), _meta.json (133b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: resolve-beagle\ndescription: \"Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or implementation can begin. Triggers on: \\\"resolve the open questions\\\", \\\"close the gaps in this spec\\\", \\\"research the open items\\\", \\\"finalize my spec\\\", \\\"make this spec implementation-ready\\\", \\\"answer the TBDs\\\". Also triggers whenever the user points at a brainstorm-beagle spec and asks for research, proposals, or answers to unresolved items. Orchestrates parallel research subagents when available (falls back to inline sequential research otherwise), proposes answers one at a time for user approval, then rewrites the spec in place so it arrives at planning with no known gaps. Does NOT write code, design implementation, or create plans — it only produces a complete spec.\"\n---\n\n# Resolve: Close Spec Gaps\n\nTake a spec produced by `brainstorm-beagle` and close its remaining gaps — both the explicit Open Questions and the latent ones the self-review missed — by researching, proposing answers, and rewriting the spec in place.\n\nThe terminal state is a spec with no known open questions and no placeholder requirements. Planning can start immediately after.\n\n<hard_gate>\nThis skill does not write code, scaffold projects, design architecture, or create implementation plans. It only edits the spec document. \"Answering an open question\" means proposing a WHAT/WHY answer with rationale — never a HOW. If a question turns out to require implementation design, defer it with a note and move on.\n</hard_gate>\n\n## Gates (pass before next step)\n\nObjective pass conditions so steps are not skippable by assertion alone:\n\n1. **Spec located** — The target file path is known and `Read` succeeds (or the user supplied a valid path after you listed 3–5 recent `docs/specs/` candidates).\n2. **Gap list published** — One message lists every explicit Open Question bullet **and** each latent gap you will treat as in-scope. **Do not dispatch research** until the user adjusts the list (add/remove/defer) **or** explicitly tells you to proceed with that list.\n3. **Research artifact per gap** — Before you present a proposal for gap *G*, you have a structured note for *G*: recommended answer, 1–2 rejected alternatives with reasons, and evidence (file:line, URL, or in-spec citation). No proposal without that artifact.\n4. **One proposal queue** — Do not open the next gap’s proposal until the current gap has a clear outcome (accepted, revised wording applied, rejected with what happens next, or deferred with reason).\n5. **Rewrite reconciled** — After editing, you read the full spec once and resolve cross-section contradictions; then run the self-review checklist from `../brainstorm-beagle/references/spec-reviewer.md` with failures fixed in-session unless the user opts for a follow-up pass.\n6. **Commit** — No `git commit` unless the user answered yes to the commit prompt in § Committing.\n\n## Workflow\n\n1. **Locate the spec** — explicit path from the user, or the most recent file in `docs/specs/`\n2. **Extract gaps** — parse Open Questions *and* audit for latent issues (placeholders, vague requirements, missing rationale, contradictions)\n3. **Show the gap list** — present everything you plan to close in one summary so the user can add or remove items before research starts\n4. **Dispatch research** — one task per gap, in parallel via subagents when available; otherwise sequentially inline\n5. **Propose answers** — one proposal at a time, with recommendation + alternatives + evidence\n6. **Rewrite the spec in place** — migrate resolved items to the right sections; nothing silently dropped\n7. **Self-review** — same checklist `brainstorm-beagle` uses (see `../brainstorm-beagle/references/spec-reviewer.md`)\n8. **Ask about committing** — prompt the user whether to commit the edit; don't commit unprompted\n\n```\nLocate spec → Extract gaps → Show list ──→ User adds/removes\n                                          → Dispatch research (parallel if possible)\n                                          → Propose answers (one at a time)\n                                                → User decision → next\n                                          → Rewrite spec in place\n                                          → Self-review (fix inline)\n                                          → Ask about committing\n```\n\n## Locating the spec\n\nIf the user gave a path, use it.\n\nOtherwise, list the 3–5 most recently modified files in `docs/specs/` and ask: \"Work on `<most recent>`, or another one?\" Don't scan the whole directory tree — specs are top-level per `brainstorm-beagle`'s convention.\n\nIf no spec directory exists, ask the user for the path.\n\n## Extracting gaps\n\nTwo categories count as gaps:\n\n**Explicit gaps** — every bullet under the spec's `Open Questions` heading is one research task.\n\n**Latent gaps** — issues that slipped past the brainstorm's self-review. Scan the spec for:\n\n| Problem | What it looks like |\n|---------|-------------------|\n| Placeholder | TBD, TODO, \"to be determined\", ellipsis used as content |\n| Vague requirement | \"fast\", \"simple\", \"good\", \"user-friendly\", \"intuitive\" — nothing to verify against |\n| Missing rationale | Constraint or Out-of-Scope item with no \"why\" |\n| Contradiction | Requirement conflicts with another requirement, with a constraint, or with Out of Scope |\n| Untestable success | No observable way to verify the requirement was met |\n| Implementation leakage | A requirement prescribes HOW instead of describing WHAT |\n\nThe reason to treat latent gaps as first-class: a spec that says \"fast\" or \"good UX\" hasn't been answered just because nothing was explicitly flagged. Planning will trip over those same words. Close them here.\n\nBefore dispatching research, show the combined list to the user in one message — \"here's what I'm planning to close\" — and let them add, remove, or defer items. Don't ask permission one-by-one; that's the proposal step.\n\n## Dispatching research\n\nEach gap gets exactly one research task. Classify each task first — the type determines which tools the research needs:\n\n| Task type | Looks like | Tools |\n|-----------|-----------|-------|\n| Codebase pattern | \"How does the existing `--start-at` pattern work?\" \"Where is `SKILL_MAP` defined?\" | Grep, Glob, Read |\n| External / API | \"What does the Claude SDK expose for sub-agent spawning?\" \"Does Codex have hooks?\" | WebSearch, WebFetch, Context7 (if available) |\n| Design tradeoff | \"What should the merged report format be?\" \"How should deduplication work?\" | Reasoning + analogous reference points already in the spec |\n| Scope / policy | \"Should config/docs files route to a stack or fallback?\" | Reasoning tied to the spec's own Core Value and Constraints |\n\n### With subagents (preferred)\n\nWhen the Task tool (or equivalent subagent tool) is available, dispatch each research task as an independent subagent — **all in the same turn**, so they run in parallel. Each subagent gets its own context window, which matters: gaps often come with large supporting context (the spec, the codebase) that you don't want crammed into a single conversation.\n\nSee `references/subagent-prompts.md` for the prompt templates (one per task type).\n\nThe research return must be structured: recommended answer, 1–2 alternatives with why rejected, and concrete evidence (file:line citations, URLs, or references to existing spec sections). Cap each return at ~300 words — you want decisions, not transcripts.\n\n### Without subagents\n\nIf no subagent tool is available, do the research yourself, one question at a time. Work in cheapest-first order: codebase questions, then external, then tradeoffs, then scope/policy. Produce the same structured proposal for each. This is slower but never leaves gaps unresolved.\n\n## Proposing answers\n\nPresent proposals **one at a time**. For each:\n\n- **The gap** — restated in one line\n- **Recommended answer** — your best call, with WHY\n- **Alternatives** — 1–2 credible options and why they were rejected\n- **Evidence** — file:line citations, URLs, or references to decisions already in the spec\n\nThe user can accept, revise, or reject. Follow the thread if they want to discuss; move on once decided.\n\n**Order matters.** Resolve in this rough sequence:\n\n1. Codebase-reality gaps first (they may inform design tradeoffs)\n2. Policy/scope gaps second (they shape everything downstream)\n3. Format/presentation gaps last (they depend on the above)\n\nWhen a gap can't be resolved without input only the user has (budgets, stakeholder preferences, unstated constraints), don't guess — ask directly. It's cheaper than proposing the wrong answer and unwinding it.\n\n## Rewriting the spec\n\nAs decisions land, migrate them to where they belong:\n\n| Gap type | Destination after resolution |\n|----------|-----------------------------|\n| Architectural or policy decision | New entry under **Key Decisions** (with alternatives considered) |\n| Concrete behavior | New entry under **Requirements** (assigned must/should/out-of-scope) |\n| Hard limit | New entry under **Constraints** (with rationale) |\n| External reference discovered during research | New entry under **Reference Points** |\n| Vague requirement replaced | Rewrite the existing requirement inline; do not duplicate |\n| Intentionally deferred | Stays in **Open Questions** with a `deferred: <reason>` suffix |\n\nTwo rules that matter:\n\n- **Never silently drop an Open Question.** Either resolve it, migrate it with rationale, or explicitly defer it with a reason. Dropping a question without a trail is how specs regress between sessions.\n- **Rewrite the whole spec, not just the touched sections.** Changes ripple: a new Key Decision may contradict an old Requirement, a resolved Open Question may invalidate a Constraint. Read the spec end-to-end after edits and reconcile.\n\n## Self-review\n\nRun the checks from `../brainstorm-beagle/references/spec-reviewer.md`:\n\n- No placeholders\n- No contradictions\n- No implementation leakage\n- All requirements testable\n- Constraints and Out-of-Scope items have rationale\n\nFix anything that surfaces inline before handing back to the user. If new gaps appear during the rewrite (they sometimes do), add them to a \"new gaps surfaced\" list and ask the user whether to resolve them now or leave for a later pass.\n\n## Committing\n\nAfter the rewrite, summarize and ask:\n\n> \"Spec updated. Resolved N explicit questions and M latent gaps. Want me to commit this as `docs: resolve open questions in <topic> spec`?\"\n\nIf yes, commit. If no, leave the working tree for the user. Do not commit unprompted — the user may want to review the diff first or bundle it with other changes.\n\n## Key Principles\n\n- **Close the loop.** The goal is a spec with nothing unanswered that blocks planning. Half-resolved is worse than clearly deferred.\n- **One research task per gap.** Don't blur tasks together — it makes the proposal step harder to review and weakens the evidence trail.\n- **Evidence over opinion.** Every proposal cites something — a file, a URL, or an existing spec decision. \"I think\" is not enough.\n- **Still WHAT, not HOW.** Answers land as decisions in the spec, not as implementation designs. If an answer requires implementation thinking, defer it.\n- **Defer honestly.** A question too expensive to answer now stays an Open Question with a one-line reason. Better to admit a known gap than paper over it.\n- **Parallelize when you can.** Subagents run in isolation — fan out aggressively. Sequential research is the fallback, not the default.\n- **Don't interrupt unnecessarily.** Show the gap list once, then only stop the user for decisions that need human judgment.\n\nFile v1.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn79190nfmdb20hk6xjhzt2zv583844x\",\n  \"slug\": \"resolve-beagle\",\n  \"version\": \"1.0.1\",\n  \"publishedAt\": 1776831015412\n}\n\nFile v1.0.1:references/subagent-prompts.md\n\n# Subagent Prompt Templates\n\nUse these when dispatching research tasks to subagents. One task per subagent. Launch all subagents in a single turn so they run in parallel.\n\nEvery template ends with the same **return format** — a structured proposal the orchestrator can drop directly into the spec. Don't let subagents return free-form prose; decisions are the deliverable, not transcripts.\n\n## Return format (shared across all templates)\n\nEvery subagent must return exactly this structure, ~300 words max:\n\n```\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY>\n\n## Alternatives considered\n- <alternative 1> — rejected because <reason>\n- <alternative 2> — rejected because <reason>\n\n## Evidence\n- <file:line citation, URL, or reference to an existing spec section>\n- <additional citations as needed>\n\n## Open sub-questions (if any)\n- <anything the subagent couldn't resolve and needs the user or orchestrator to decide>\n```\n\nIf the subagent cannot produce a recommendation with evidence, it should say so explicitly in \"Open sub-questions\" rather than guess.\n\n---\n\n## Template: Codebase pattern\n\nUse when the question is about how the existing codebase works — an API, a pattern, a file layout, a convention that the spec references.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: read the relevant code and return a structured proposal answering the question. Use Grep, Glob, and Read. Do not modify any files.\n\nScope hints:\n- <file/dir hints from the spec, if any>\n- <reference points mentioned in the spec>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what you found>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, citing code>\n- <alt 2> — rejected because <reason, citing code>\n\n## Evidence\n- <file:line> — <one-line description of what's there>\n- <file:line> — <one-line description>\n\n## Open sub-questions\n- <anything that needs user input or is blocked>\n\nCap the return at ~300 words. Cite file paths and line numbers. Decisions, not transcripts.\n```\n\n## Template: External / API\n\nUse when the question is about an external system — a framework's capabilities, an SDK's API, a tool's behavior.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: use WebSearch, WebFetch, and Context7 (if available) to find authoritative answers — official docs, source repositories, maintainer statements. Avoid blog posts and secondhand summaries.\n\nFocus area: <framework / SDK / tool name>\nWhy it matters: <one-line context pulled from the spec's Problem Statement or Key Decisions>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what the official source says>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, citing source>\n- <alt 2> — rejected because <reason, citing source>\n\n## Evidence\n- <URL> — <one-line description of what it says>\n- <URL> — <one-line description>\n\n## Open sub-questions\n- <anything version-specific, ambiguous, or that needs user confirmation>\n\nCap the return at ~300 words. Prefer primary sources. Decisions, not transcripts.\n```\n\n## Template: Design tradeoff\n\nUse when the question is a product/design judgment call with no single \"right answer\" in the codebase or external docs — format decisions, deduplication heuristics, UX structure.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: reason about the tradeoff and produce a concrete recommendation grounded in the spec's own Core Value, Problem Statement, and Key Decisions. Reference the spec heavily — the right answer usually already lives implicit in the rest of the document.\n\nDo NOT propose implementation details. The answer goes into the spec as a WHAT/WHY decision, not a HOW.\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — explicitly citing which spec section supports the choice>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, ideally citing a spec section it would undermine>\n- <alt 2> — rejected because <reason>\n\n## Evidence\n- Spec section \"<section name>\" — <what it says that informs this>\n- <additional analogies or reference points if relevant>\n\n## Open sub-questions\n- <anything that needs the user's judgment (preferences, budgets, unstated constraints)>\n\nCap the return at ~300 words. Ground the call in the spec. Decisions, not transcripts.\n```\n\n## Template: Scope / policy\n\nUse when the question is about inclusion/exclusion — what routes where, what's covered, what's explicitly out.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: recommend the scope/policy answer that best preserves the spec's Core Value and is consistent with its existing Out-of-Scope rationale. Read the spec end-to-end before deciding — scope answers regress fast if you only look at the local question.\n\nDo NOT propose implementation details. The answer goes into the spec as a WHAT/WHY decision.\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — showing it aligns with Core Value and existing Out-of-Scope reasoning>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, ideally showing it conflicts with a stated constraint>\n- <alt 2> — rejected because <reason>\n\n## Evidence\n- Spec section \"Core Value\" — <relevant phrase>\n- Spec section \"Out of Scope\" — <relevant rationale>\n- <other spec sections as needed>\n\n## Open sub-questions\n- <anything that needs user input on future intent>\n\nCap the return at ~300 words. Consistency with the spec matters more than novelty. Decisions, not transcripts.\n```\n\nFile v1.0.1:skill-card.md\n\n## Description: <br>\nResolve Beagle helps agents close explicit and latent gaps in brainstorm-beagle specs by researching open questions, proposing answers for approval, and rewriting the spec so it is ready for planning. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[anderskev](https://clawhub.ai/user/anderskev) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and product engineers use this skill after brainstorm-beagle to turn a draft spec with unresolved questions into an implementation-ready spec. It identifies explicit and latent gaps, coordinates focused research, gathers user-approved decisions, and updates the spec document. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The security review verdict is suspicious because related ClawHub maintainer workflows may have broad local authority or send diffs to external model CLIs. <br>\nMitigation: Install only if that operating model is acceptable; prefer constrained review modes such as --no-yolo or AUTOREVIEW_YOLO=0 when using adjacent autoreview workflows. <br>\nRisk: Incorrect proposals can alter requirements when the skill rewrites a specification file. <br>\nMitigation: Review the gap list, each proposal, and the final spec diff before planning from or committing the updated specification. <br>\n\n\n## Reference(s): <br>\n- [Resolve Beagle on ClawHub](https://clawhub.ai/anderskev/resolve-beagle) <br>\n- [Subagent Prompt Templates](references/subagent-prompts.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Markdown, Guidance, Files] <br>\n**Output Format:** [Markdown proposals and in-place spec document edits] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May coordinate one research task per gap and asks for user approval before rewriting.] <br>\n\n## Skill Version(s): <br>\n1.0.1 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.0: 3 files, 6959 bytes\n\nFiles: references/subagent-prompts.md (6118b), SKILL.md (10418b), _meta.json (133b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: resolve-beagle\ndescription: \"Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or implementation can begin. Triggers on: \\\"resolve the open questions\\\", \\\"close the gaps in this spec\\\", \\\"research the open items\\\", \\\"finalize my spec\\\", \\\"make this spec implementation-ready\\\", \\\"answer the TBDs\\\". Also triggers whenever the user points at a brainstorm-beagle spec and asks for research, proposals, or answers to unresolved items. Orchestrates parallel research subagents when available (falls back to inline sequential research otherwise), proposes answers one at a time for user approval, then rewrites the spec in place so it arrives at planning with no known gaps. Does NOT write code, design implementation, or create plans — it only produces a complete spec.\"\n---\n\n# Resolve: Close Spec Gaps\n\nTake a spec produced by `brainstorm-beagle` and close its remaining gaps — both the explicit Open Questions and the latent ones the self-review missed — by researching, proposing answers, and rewriting the spec in place.\n\nThe terminal state is a spec with no known open questions and no placeholder requirements. Planning can start immediately after.\n\n<hard_gate>\nThis skill does not write code, scaffold projects, design architecture, or create implementation plans. It only edits the spec document. \"Answering an open question\" means proposing a WHAT/WHY answer with rationale — never a HOW. If a question turns out to require implementation design, defer it with a note and move on.\n</hard_gate>\n\n## Workflow\n\n1. **Locate the spec** — explicit path from the user, or the most recent file in `docs/specs/`\n2. **Extract gaps** — parse Open Questions *and* audit for latent issues (placeholders, vague requirements, missing rationale, contradictions)\n3. **Show the gap list** — present everything you plan to close in one summary so the user can add or remove items before research starts\n4. **Dispatch research** — one task per gap, in parallel via subagents when available; otherwise sequentially inline\n5. **Propose answers** — one proposal at a time, with recommendation + alternatives + evidence\n6. **Rewrite the spec in place** — migrate resolved items to the right sections; nothing silently dropped\n7. **Self-review** — same checklist `brainstorm-beagle` uses (see `../brainstorm-beagle/references/spec-reviewer.md`)\n8. **Ask about committing** — prompt the user whether to commit the edit; don't commit unprompted\n\n```\nLocate spec → Extract gaps → Show list ──→ User adds/removes\n                                          → Dispatch research (parallel if possible)\n                                          → Propose answers (one at a time)\n                                                → User decision → next\n                                          → Rewrite spec in place\n                                          → Self-review (fix inline)\n                                          → Ask about committing\n```\n\n## Locating the spec\n\nIf the user gave a path, use it.\n\nOtherwise, list the 3–5 most recently modified files in `docs/specs/` and ask: \"Work on `<most recent>`, or another one?\" Don't scan the whole directory tree — specs are top-level per `brainstorm-beagle`'s convention.\n\nIf no spec directory exists, ask the user for the path.\n\n## Extracting gaps\n\nTwo categories count as gaps:\n\n**Explicit gaps** — every bullet under the spec's `Open Questions` heading is one research task.\n\n**Latent gaps** — issues that slipped past the brainstorm's self-review. Scan the spec for:\n\n| Problem | What it looks like |\n|---------|-------------------|\n| Placeholder | TBD, TODO, \"to be determined\", ellipsis used as content |\n| Vague requirement | \"fast\", \"simple\", \"good\", \"user-friendly\", \"intuitive\" — nothing to verify against |\n| Missing rationale | Constraint or Out-of-Scope item with no \"why\" |\n| Contradiction | Requirement conflicts with another requirement, with a constraint, or with Out of Scope |\n| Untestable success | No observable way to verify the requirement was met |\n| Implementation leakage | A requirement prescribes HOW instead of describing WHAT |\n\nThe reason to treat latent gaps as first-class: a spec that says \"fast\" or \"good UX\" hasn't been answered just because nothing was explicitly flagged. Planning will trip over those same words. Close them here.\n\nBefore dispatching research, show the combined list to the user in one message — \"here's what I'm planning to close\" — and let them add, remove, or defer items. Don't ask permission one-by-one; that's the proposal step.\n\n## Dispatching research\n\nEach gap gets exactly one research task. Classify each task first — the type determines which tools the research needs:\n\n| Task type | Looks like | Tools |\n|-----------|-----------|-------|\n| Codebase pattern | \"How does the existing `--start-at` pattern work?\" \"Where is `SKILL_MAP` defined?\" | Grep, Glob, Read |\n| External / API | \"What does the Claude SDK expose for sub-agent spawning?\" \"Does Codex have hooks?\" | WebSearch, WebFetch, Context7 (if available) |\n| Design tradeoff | \"What should the merged report format be?\" \"How should deduplication work?\" | Reasoning + analogous reference points already in the spec |\n| Scope / policy | \"Should config/docs files route to a stack or fallback?\" | Reasoning tied to the spec's own Core Value and Constraints |\n\n### With subagents (preferred)\n\nWhen the Task tool (or equivalent subagent tool) is available, dispatch each research task as an independent subagent — **all in the same turn**, so they run in parallel. Each subagent gets its own context window, which matters: gaps often come with large supporting context (the spec, the codebase) that you don't want crammed into a single conversation.\n\nSee `references/subagent-prompts.md` for the prompt templates (one per task type).\n\nThe research return must be structured: recommended answer, 1–2 alternatives with why rejected, and concrete evidence (file:line citations, URLs, or references to existing spec sections). Cap each return at ~300 words — you want decisions, not transcripts.\n\n### Without subagents\n\nIf no subagent tool is available, do the research yourself, one question at a time. Work in cheapest-first order: codebase questions, then external, then tradeoffs, then scope/policy. Produce the same structured proposal for each. This is slower but never leaves gaps unresolved.\n\n## Proposing answers\n\nPresent proposals **one at a time**. For each:\n\n- **The gap** — restated in one line\n- **Recommended answer** — your best call, with WHY\n- **Alternatives** — 1–2 credible options and why they were rejected\n- **Evidence** — file:line citations, URLs, or references to decisions already in the spec\n\nThe user can accept, revise, or reject. Follow the thread if they want to discuss; move on once decided.\n\n**Order matters.** Resolve in this rough sequence:\n\n1. Codebase-reality gaps first (they may inform design tradeoffs)\n2. Policy/scope gaps second (they shape everything downstream)\n3. Format/presentation gaps last (they depend on the above)\n\nWhen a gap can't be resolved without input only the user has (budgets, stakeholder preferences, unstated constraints), don't guess — ask directly. It's cheaper than proposing the wrong answer and unwinding it.\n\n## Rewriting the spec\n\nAs decisions land, migrate them to where they belong:\n\n| Gap type | Destination after resolution |\n|----------|-----------------------------|\n| Architectural or policy decision | New entry under **Key Decisions** (with alternatives considered) |\n| Concrete behavior | New entry under **Requirements** (assigned must/should/out-of-scope) |\n| Hard limit | New entry under **Constraints** (with rationale) |\n| External reference discovered during research | New entry under **Reference Points** |\n| Vague requirement replaced | Rewrite the existing requirement inline; do not duplicate |\n| Intentionally deferred | Stays in **Open Questions** with a `deferred: <reason>` suffix |\n\nTwo rules that matter:\n\n- **Never silently drop an Open Question.** Either resolve it, migrate it with rationale, or explicitly defer it with a reason. Dropping a question without a trail is how specs regress between sessions.\n- **Rewrite the whole spec, not just the touched sections.** Changes ripple: a new Key Decision may contradict an old Requirement, a resolved Open Question may invalidate a Constraint. Read the spec end-to-end after edits and reconcile.\n\n## Self-review\n\nRun the checks from `../brainstorm-beagle/references/spec-reviewer.md`:\n\n- No placeholders\n- No contradictions\n- No implementation leakage\n- All requirements testable\n- Constraints and Out-of-Scope items have rationale\n\nFix anything that surfaces inline before handing back to the user. If new gaps appear during the rewrite (they sometimes do), add them to a \"new gaps surfaced\" list and ask the user whether to resolve them now or leave for a later pass.\n\n## Committing\n\nAfter the rewrite, summarize and ask:\n\n> \"Spec updated. Resolved N explicit questions and M latent gaps. Want me to commit this as `docs: resolve open questions in <topic> spec`?\"\n\nIf yes, commit. If no, leave the working tree for the user. Do not commit unprompted — the user may want to review the diff first or bundle it with other changes.\n\n## Key Principles\n\n- **Close the loop.** The goal is a spec with nothing unanswered that blocks planning. Half-resolved is worse than clearly deferred.\n- **One research task per gap.** Don't blur tasks together — it makes the proposal step harder to review and weakens the evidence trail.\n- **Evidence over opinion.** Every proposal cites something — a file, a URL, or an existing spec decision. \"I think\" is not enough.\n- **Still WHAT, not HOW.** Answers land as decisions in the spec, not as implementation designs. If an answer requires implementation thinking, defer it.\n- **Defer honestly.** A question too expensive to answer now stays an Open Question with a one-line reason. Better to admit a known gap than paper over it.\n- **Parallelize when you can.** Subagents run in isolation — fan out aggressively. Sequential research is the fallback, not the default.\n- **Don't interrupt unnecessarily.** Show the gap list once, then only stop the user for decisions that need human judgment.\n\nFile v1.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn79190nfmdb20hk6xjhzt2zv583844x\",\n  \"slug\": \"resolve-beagle\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1776524605965\n}\n\nFile v1.0.0:references/subagent-prompts.md\n\n# Subagent Prompt Templates\n\nUse these when dispatching research tasks to subagents. One task per subagent. Launch all subagents in a single turn so they run in parallel.\n\nEvery template ends with the same **return format** — a structured proposal the orchestrator can drop directly into the spec. Don't let subagents return free-form prose; decisions are the deliverable, not transcripts.\n\n## Return format (shared across all templates)\n\nEvery subagent must return exactly this structure, ~300 words max:\n\n```\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY>\n\n## Alternatives considered\n- <alternative 1> — rejected because <reason>\n- <alternative 2> — rejected because <reason>\n\n## Evidence\n- <file:line citation, URL, or reference to an existing spec section>\n- <additional citations as needed>\n\n## Open sub-questions (if any)\n- <anything the subagent couldn't resolve and needs the user or orchestrator to decide>\n```\n\nIf the subagent cannot produce a recommendation with evidence, it should say so explicitly in \"Open sub-questions\" rather than guess.\n\n---\n\n## Template: Codebase pattern\n\nUse when the question is about how the existing codebase works — an API, a pattern, a file layout, a convention that the spec references.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: read the relevant code and return a structured proposal answering the question. Use Grep, Glob, and Read. Do not modify any files.\n\nScope hints:\n- <file/dir hints from the spec, if any>\n- <reference points mentioned in the spec>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what you found>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, citing code>\n- <alt 2> — rejected because <reason, citing code>\n\n## Evidence\n- <file:line> — <one-line description of what's there>\n- <file:line> — <one-line description>\n\n## Open sub-questions\n- <anything that needs user input or is blocked>\n\nCap the return at ~300 words. Cite file paths and line numbers. Decisions, not transcripts.\n```\n\n## Template: External / API\n\nUse when the question is about an external system — a framework's capabilities, an SDK's API, a tool's behavior.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: use WebSearch, WebFetch, and Context7 (if available) to find authoritative answers — official docs, source repositories, maintainer statements. Avoid blog posts and secondhand summaries.\n\nFocus area: <framework / SDK / tool name>\nWhy it matters: <one-line context pulled from the spec's Problem Statement or Key Decisions>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what the official source says>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, citing source>\n- <alt 2> — rejected because <reason, citing source>\n\n## Evidence\n- <URL> — <one-line description of what it says>\n- <URL> — <one-line description>\n\n## Open sub-questions\n- <anything version-specific, ambiguous, or that needs user confirmation>\n\nCap the return at ~300 words. Prefer primary sources. Decisions, not transcripts.\n```\n\n## Template: Design tradeoff\n\nUse when the question is a product/design judgment call with no single \"right answer\" in the codebase or external docs — format decisions, deduplication heuristics, UX structure.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: reason about the tradeoff and produce a concrete recommendation grounded in the spec's own Core Value, Problem Statement, and Key Decisions. Reference the spec heavily — the right answer usually already lives implicit in the rest of the document.\n\nDo NOT propose implementation details. The answer goes into the spec as a WHAT/WHY decision, not a HOW.\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — explicitly citing which spec section supports the choice>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, ideally citing a spec section it would undermine>\n- <alt 2> — rejected because <reason>\n\n## Evidence\n- Spec section \"<section name>\" — <what it says that informs this>\n- <additional analogies or reference points if relevant>\n\n## Open sub-questions\n- <anything that needs the user's judgment (preferences, budgets, unstated constraints)>\n\nCap the return at ~300 words. Ground the call in the spec. Decisions, not transcripts.\n```\n\n## Template: Scope / policy\n\nUse when the question is about inclusion/exclusion — what routes where, what's covered, what's explicitly out.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: recommend the scope/policy answer that best preserves the spec's Core Value and is consistent with its existing Out-of-Scope rationale. Read the spec end-to-end before deciding — scope answers regress fast if you only look at the local question.\n\nDo NOT propose implementation details. The answer goes into the spec as a WHAT/WHY decision.\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — showing it aligns with Core Value and existing Out-of-Scope reasoning>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, ideally showing it conflicts with a stated constraint>\n- <alt 2> — rejected because <reason>\n\n## Evidence\n- Spec section \"Core Value\" — <relevant phrase>\n- Spec section \"Out of Scope\" — <relevant rationale>\n- <other spec sections as needed>\n\n## Open sub-questions\n- <anything that needs user input on future intent>\n\nCap the return at ~300 words. Consistency with the spec matters more than novelty. Decisions, not transcripts.\n```","readmeExcerpt":"Skill: Resolve Beagle Owner: anderskev Summary: Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or imp... Tags: latest:1.0.3 Version history: v1.0.3 | 2026-06-25T05:40:25.417Z | auto resolve-beagle 1.0.3 - Removed file: skill-card.md - Expanded latent gap detection in SKILL.md to include unconsumed external surfaces","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"Locate spec → Extract gaps → Show list ──→ User adds/removes\n                                          → Dispatch research (parallel if possible)\n                                          → Propose answers (one at a time)\n                                                → User decision → next\n                                          → Rewrite spec in place\n                                          → Self-review (fix inline)\n                                          → Ask about committing"},{"language":"text","snippet":"## Recommended answer\n<one-sentence answer, then a short paragraph on WHY>\n\n## Alternatives considered\n- <alternative 1> — rejected because <reason>\n- <alternative 2> — rejected because <reason>\n\n## Evidence\n- <file:line citation, URL, or reference to an existing spec section>\n- <additional citations as needed>\n\n## Open sub-questions (if any)\n- <anything the subagent couldn't resolve and needs the user or orchestrator to decide>"},{"language":"text","snippet":"You are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: read the relevant code and return a structured proposal answering the question. Use Grep, Glob, and Read. Do not modify any files.\n\nScope hints:\n- <file/dir hints from the spec, if any>\n- <reference points mentioned in the spec>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what you found>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, citing code>\n- <alt 2> — rejected because <reason, citing code>\n\n## Evidence\n- <file:line> — <one-line description of what's there>\n- <file:line> — <one-line description>\n\n## Open sub-questions\n- <anything that needs user input or is blocked>\n\nCap the return at ~300 words. Cite file paths and line numbers. Decisions, not transcripts."},{"language":"text","snippet":"You are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: use web search and page fetch (if web access is available) to find authoritative answers — official docs, source repositories, maintainer statements. Avoid blog posts and secondhand summaries.\n\nFocus area: <framework / SDK / tool name>\nWhy it matters: <one-line context pulled from the spec's Problem Statement or Key Decisions>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what the official source says>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, citing source>\n- <alt 2> — rejected because <reason, citing source>\n\n## Evidence\n- <URL> — <one-line description of what it says>\n- <URL> — <one-line description>\n\n## Open sub-questions\n- <anything version-specific, ambiguous, or that needs user confirmation>\n\nCap the return at ~300 words. Prefer primary sources. Decisions, not transcripts."},{"language":"text","snippet":"You are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: reason about the tradeoff and produce a concrete recommendation grounded in the spec's own Core Value, Problem Statement, and Key Decisions. Reference the spec heavily — the right answer usually already lives implicit in the rest of the document.\n\nDo NOT propose implementation details. The answer goes into the spec as a WHAT/WHY decision, not a HOW.\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — explicitly citing which spec section supports the choice>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, ideally citing a spec section it would undermine>\n- <alt 2> — rejected because <reason>\n\n## Evidence\n- Spec section \"<section name>\" — <what it says that informs this>\n- <additional analogies or reference points if relevant>\n\n## Open sub-questions\n- <anything that needs the user's judgment (preferences, budgets, unstated constraints)>\n\nCap the return at ~300 words. Ground the call in the spec. Decisions, not transcripts."},{"language":"text","snippet":"You are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: recommend the scope/policy answer that best preserves the spec's Core Value and is consistent with its existing Out-of-Scope rationale. Read the spec end-to-end before deciding — scope answers regress fast if you only look at the local question.\n\nDo NOT propose implementation details. The answer goes into the spec as a WHAT/WHY decision.\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — showing it aligns with Core Value and existing Out-of-Scope reasoning>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, ideally showing it conflicts with a stated constraint>\n- <alt 2> — rejected because <reason>\n\n## Evidence\n- Spec section \"Core Value\" — <relevant phrase>\n- Spec section \"Out of Scope\" — <relevant rationale>\n- <other spec sections as needed>\n\n## Open sub-questions\n- <anything that needs user input on future intent>\n\nCap the return at ~300 words. Consistency with the spec matters more than novelty. Decisions, not transcripts."}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: resolve-beagle\ndescription: \"Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or implementation can begin. Triggers on: \\\"resolve the open questions\\\", \\\"close the gaps in this spec\\\", \\\"research the open items\\\", \\\"finalize my spec\\\", \\\"make this spec implementation-ready\\\", \\\"answer the TBDs\\\". Also triggers whenever the user points at a brainstorm-beagle spec and asks for research, proposals, or answers to unresolved items. Orchestrates parallel research subagents when available (falls back to inline sequential research otherwise), proposes answers one at a time for user approval, then rewrites the spec in place so it arrives at planning with no known gaps. Does NOT write code, design implementation, or create plans — it only produces a complete spec.\"\n---\n\n# Resolve: Close Spec Gaps\n\nTake a spec produced by `brainstorm-beagle` and close its remaining gaps — both the explicit Open Questions and the latent ones the self-review missed — by researching, proposing answers, and rewriting the spec in place.\n\nThe terminal state is a spec with no known open questions and no placeholder requirements. Planning can start immediately after.\n\n<hard_gate>\nThis skill does not write code, scaffold projects, design architecture, or create implementation plans. It only edits the spec document. \"Answering an open question\" means proposing a WHAT/WHY answer with rationale — never a HOW. If a question turns out to require implementation design, defer it with a note and move on.\n</hard_gate>\n\n## Gates (pass before next step)\n\nObjective pass conditions so steps are not skippable by assertion alone:\n\n1. **Spec located** — The target file path is known and `Read` succeeds (or the user supplied a valid path after you listed 3–5 recent `docs/specs/` candidates).\n2. **Gap list published** — One message lists every explicit Open Question bullet **and** each latent gap you will treat as in-scope. **Do not dispatch research** until the user adjusts the list (add/remove/defer) **or** explicitly tells you to proceed with that list.\n3. **Research artifact per gap** — Before you present a proposal for gap *G*, you have a structured note for *G*: recommended answer, 1–2 rejected alternatives with reasons, and evidence (file:line, URL, or in-spec citation). No proposal without that artifact.\n4. **One proposal queue** — Do not open the next gap’s proposal until the current gap has a clear outcome (accepted, revised wording applied, rejected with what happens next, or deferred with reason).\n5. **Rewrite reconciled** — After editing, you read the full spec once and resolve cross-section contradictions; then run the self-review checklist from `../brainstorm-beagle/references/spec-reviewer.md` with failures fixed in-session unless the user opts for a follow-up pass.\n6. **Commit** — No `git commit` unless the user answered yes to the commit prompt in § Committing.\n\n## Workflo"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn79190nfmdb20hk6xjhzt2zv583844x\",\n  \"slug\": \"resolve-beagle\",\n  \"version\": \"1.0.3\",\n  \"publishedAt\": 1782366025417\n}"},{"path":"references/subagent-prompts.md","content":"# Subagent Prompt Templates\n\nUse these when dispatching research tasks to subagents. One task per subagent. Launch all subagents in a single turn so they run in parallel.\n\nEvery template ends with the same **return format** — a structured proposal the orchestrator can drop directly into the spec. Don't let subagents return free-form prose; decisions are the deliverable, not transcripts.\n\n## Return format (shared across all templates)\n\nEvery subagent must return exactly this structure, ~300 words max:\n\n```\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY>\n\n## Alternatives considered\n- <alternative 1> — rejected because <reason>\n- <alternative 2> — rejected because <reason>\n\n## Evidence\n- <file:line citation, URL, or reference to an existing spec section>\n- <additional citations as needed>\n\n## Open sub-questions (if any)\n- <anything the subagent couldn't resolve and needs the user or orchestrator to decide>\n```\n\nIf the subagent cannot produce a recommendation with evidence, it should say so explicitly in \"Open sub-questions\" rather than guess.\n\n---\n\n## Template: Codebase pattern\n\nUse when the question is about how the existing codebase works — an API, a pattern, a file layout, a convention that the spec references.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: read the relevant code and return a structured proposal answering the question. Use Grep, Glob, and Read. Do not modify any files.\n\nScope hints:\n- <file/dir hints from the spec, if any>\n- <reference points mentioned in the spec>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what you found>\n\n## Alternatives considered\n- <alt 1> — rejected because <reason, citing code>\n- <alt 2> — rejected because <reason, citing code>\n\n## Evidence\n- <file:line> — <one-line description of what's there>\n- <file:line> — <one-line description>\n\n## Open sub-questions\n- <anything that needs user input or is blocked>\n\nCap the return at ~300 words. Cite file paths and line numbers. Decisions, not transcripts.\n```\n\n## Template: External / API\n\nUse when the question is about an external system — a framework's capabilities, an SDK's API, a tool's behavior.\n\n```\nYou are researching one question for an in-progress project spec.\n\nSpec path: <absolute path>\nQuestion: <the exact open question, verbatim>\n\nYour job: use web search and page fetch (if web access is available) to find authoritative answers — official docs, source repositories, maintainer statements. Avoid blog posts and secondhand summaries.\n\nFocus area: <framework / SDK / tool name>\nWhy it matters: <one-line context pulled from the spec's Problem Statement or Key Decisions>\n\nReturn in this exact format:\n\n## Recommended answer\n<one-sentence answer, then a short paragraph on WHY — grounded in what the official source says>\n\n## Alternatives considered\n- <alt 1> "},{"path":"skill-card.md","content":"## Description:\n\nResolve Beagle helps agents close open questions and latent gaps in a brainstorm-beagle spec by researching issues, proposing evidence-backed answers for user approval, and rewriting the spec in place.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[anderskev](https://clawhub.ai/user/anderskev)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, product owners, and spec authors use this skill to turn a brainstorm-beagle spec with open questions, placeholders, or ambiguous requirements into an implementation-ready spec before planning starts.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can read project files, use external web research, and rewrite the target spec in place.\n\nMitigation: Use it on specs the agent is allowed to inspect and edit, and review the proposed gap list before allowing research to proceed.\n\nRisk: Accepted proposals could introduce incorrect or misleading requirements into a planning document.\n\nMitigation: Review each evidence-backed proposal before acceptance and re-read the rewritten spec before planning begins.\n\nRisk: The workflow may create a commit if the user approves it.\n\nMitigation: Require explicit user approval before any commit and inspect the resulting diff when repository history matters.\n\n## Reference(s):\n\n- [Subagent Prompt Templates](references/subagent-prompts.md)\n- [Resolve Beagle ClawHub Listing](https://clawhub.ai/anderskev/skills/resolve-beagle)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Guidance, Files]\n\n**Output Format:** [Markdown spec edits with structured proposal text]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Requires user confirmation before research proceeds and before any commit.]\n\n## Skill Version(s):\n\n1.0.3 (source: server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or imp... Skill: Resolve Beagle Owner: anderskev Summary: Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or imp... Tags: latest:1.0.3 Version history: v1.0.3 | 2026-06-25T05:40:25.417Z | auto resolve-beagle 1.0.3 - Removed file: skill-card.md - Expanded latent gap detection in SKILL.md to include unconsumed external surfaces","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1651,"uniquenessScore":46,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T12:32:37.954Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T12:32:37.954Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T15:14:22.147Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}