{ "schemaVersion": "1.0", "item": { "slug": "apollo-issue-review", "name": "Apollo Issue Review", "source": "tencent", "type": "skill", "category": "AI 智能", "sourceUrl": "https://clawhub.ai/nobodyiam/apollo-issue-review", "canonicalUrl": "https://clawhub.ai/nobodyiam/apollo-issue-review", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/apollo-issue-review", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=apollo-issue-review", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md", "agents/openai.yaml", "references/reply-templates.md", "references/diagnostic-playbook.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-23T16:43:11.935Z", "expiresAt": "2026-04-30T16:43:11.935Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentDisposition": "attachment; filename=\"4claw-imageboard-1.0.1.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/apollo-issue-review" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/apollo-issue-review", "agentPageUrl": "https://openagent3.xyz/skills/apollo-issue-review/agent", "manifestUrl": "https://openagent3.xyz/skills/apollo-issue-review/agent.json", "briefUrl": "https://openagent3.xyz/skills/apollo-issue-review/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "Apollo Issue Review", "body": "Follow this workflow to review an Apollo issue and produce a concise maintainer response." }, { "title": "Core Principles", "body": "Classify first: behavior/regression issue vs consultative/support question.\nFor behavior/regression issues: reproduce first, theorize second.\nFor consultative/support questions (for example \"is there an official script/doc\"): do evidence check first and answer directly; do not force \"reproduced/not reproduced\" wording.\nSolve the user ask, do not debate whether the user is right or wrong.\nIf behavior is already reproduced and conclusion is stable, do not ask for extra info.\nDo not default to \"version regression\" analysis unless the user explicitly asks for version comparison or it changes the recommendation.\nMatch the issue language: English issue -> English reply, Chinese issue -> Chinese reply (unless the user explicitly asks for bilingual output).\nUse canonical Apollo module names from repository reality (AGENTS/module layout/root pom.xml), and correct misnamed terms succinctly when needed.\nIf an existing comment already answers the same ask (including bot replies), avoid duplicate long replies; prefer a short addendum that only contributes corrections or missing deltas.\nNever wrap GitHub @mention handles in backticks/code spans; use plain @handle so notifications are actually triggered.\nIf a community user volunteers to implement (\"认领\"/\"first contribution\"), acknowledge and encourage first, then evaluate the proposal with explicit feasibility boundaries and concrete refinement suggestions.\nFor OpenAPI-related asks, explicitly separate Portal web APIs (e.g., /users) and OpenAPI endpoints (e.g., /openapi/v1/*); only claim \"OpenAPI supports X\" when token-based OpenAPI path is verified.\nBefore concluding \"capability not available\", cross-check code + docs/scripts + module/dependency hints from pom.xml to avoid false negatives caused by path assumptions." }, { "title": "Input Contract", "body": "Collect or derive these fields before review:\n\nrepo: /\nissue_number: numeric ID\nissue_context: title/body/comments\npublish_mode: draft-only (default) or post-after-confirm\noutput_mode: human (default) or pipeline\n\nOptional but recommended:\n\nknown_labels: existing labels on the issue\ndesired_outcome: whether user wants only triage or triage + implementation handoff\n\nIf issue_number or issue_context is missing, ask one short clarification before continuing." }, { "title": "Workflow", "body": "Collect issue facts and user ask\n\nRead issue body and comments before concluding.\nExtract: primary ask, symptom, expected behavior, actual behavior, and whether user asks one path or an either-or path.\nKeep user asks explicit (for example \"better parsing API OR raw text API\": answer both).\nDetect whether the thread includes a contribution-claim ask (for example \"can I take this issue?\") and treat it as a guidance+boundary response, not only a capability yes/no response.\nDetect main language from issue title/body/recent comments and set reply language before drafting.\nDecide issue type up front:\n\nbehavior/regression (needs reproducibility check)\nconsultative/support (needs evidence check)\n\n\nNormalize names to canonical module/service terms used by Apollo repo (e.g., apollo-portal, not invented service names).\nIf GitHub API access is unstable, use:\n\ncurl -L -s https://api.github.com/repos///issues/\ncurl -L -s https://api.github.com/repos///issues//comments\n\nRun the right validation path (mandatory)\n\nFor behavior/regression issues:\n\nBuild a minimal, local, runnable reproduction for the reported behavior.\nPrefer repo-native unit tests or a tiny temporary script over speculation.\nRecord exact observed output and types, not just interpretation.\n\n\nFor consultative/support questions:\n\nVerify by repository evidence scan (docs/scripts/code paths), not by speculative reproduction framing.\nFor API availability asks, verify in three places before concluding:\n\nactual controller paths, 2) docs/openapi scripts, 3) module/dependency pointers in pom.xml.\n\n\nRecord exact files/paths searched and what exists vs does not exist.\n\n\nExample checks:\n\nrg -n \"\" -S\ngo test ./... -run \n# or a minimal go run script under /tmp for one-off validation\n# consultative evidence scan example:\nrg --files | rg -i \"\"\nrg -n \"\" docs scripts apollo-* -S\n\nBranch by validation result\n\nBehavior/regression path:\n\nIf reproducible:\n\nState clearly that behavior is confirmed.\nIdentify whether this is supported behavior, usage mismatch, or current feature gap.\nThen answer user asks directly (existing API/workaround/unsupported).\n\n\nIf not reproducible:\n\nAsk for minimal missing evidence only:\n\ninput sample\nexact read/access code\nexpected vs actual output\n\n\nKeep this short and concrete.\n\n\n\n\nConsultative/support path:\n\nIf capability/script/doc exists: provide exact path/link and usage entry point.\nIf it does not exist: state \"currently not available\" directly and give one practical alternative.\nIf an existing comment already covered the same conclusion: post only a concise delta/correction instead of repeating the full answer.\n\nDraft maintainer reply (focus on action)\n\nStart with a one-paragraph summary in the thread language:\n\nbehavior/regression issue: reproduction summary (复现结论 / Reproduction Result)\nconsultative/support issue: direct conclusion summary (结论 / Conclusion)\n\n\nThen include:\n\n当前能力与边界: what is supported today and what is not.\n可行方案: exact API/command/workaround user can run now.\n后续路径: either invite PR with concrete files/tests, or state maintainers may plan it later without overpromising timeline.\n\n\nIf the thread includes a contribution-claim proposal, structure the main body as:\n\nappreciation and encouragement, 2) feasibility judgment, 3) concrete implementation refinements (what to reuse vs what not to reuse directly).\n\n\nIf user ask is either-or, answer both explicitly.\nIf already confirmed feature gap, do not request more logs/steps by default.\nKeep wording factual and concise.\nUse canonical module names in final wording; if the issue uses a non-canonical name, correct it briefly without derailing the answer.\nIf there is already a correct prior comment, prefer \"reference + minimal supplement\" format.\nIf you mention users/bots, keep mentions as plain text (e.g., @dosubot), not code-formatted mention strings.\nUse localized section labels and wording by issue language (for example: Reproduction Result / Current Support Boundary / Practical Path / Next Step in English threads).\n\nAsk for publish confirmation (mandatory gate)\n\nDefault behavior: generate draft only; do not post automatically.\nPresent the exact comment body first, then ask for confirmation in the same thread.\nUse a direct question in the same language as the thread, e.g.:\n\nChinese: 是否直接发布到 issue #？回复“发布”或“先不发”。\nEnglish: Post this to issue # now? Reply \"post\" or \"hold\".\n\n\nTreat no response or ambiguous response as not approved.\n\nPost the response only after explicit confirmation\n\nAllowed confirmation examples: 发布 / 帮我发 / 直接回复上去.\nIf user intent is unclear, ask one short clarification question before any post command.\nPreferred:\n\ngh api repos///issues//comments -f body=''\n\nFallback when gh transport is unstable:\n\nTOKEN=$(gh auth token)\ncurl --http1.1 -sS -X POST \\\n -H \"Authorization: token $TOKEN\" \\\n -H \"Accept: application/vnd.github+json\" \\\n -d '{\"body\":\"\"}' \\\n https://api.github.com/repos///issues//comments\n\nAfter posting, return the comment URL as evidence." }, { "title": "Output Contract", "body": "Default (output_mode=human) output should be human-friendly:\n\nIssue Summary\n\nissue type + confidence\nvalidation result (reproduced / not reproduced / evidence result)\n\nTriage Suggestion\n\nlabels to add\nmissing information (if any)\nwhether it is ready for implementation handoff\n\nDraft Maintainer Reply\n\nFirst sentence must match issue type:\n\nbehavior/regression: reproducibility status (已复现/暂未复现 or Reproduced/Not yet reproduced)\nconsultative/support: direct availability conclusion\n\n\nInclude at least one concrete API/code path/file reference.\nIf unsupported today: include support boundary + practical workaround + next path.\nIf reproducible and conclusion is stable: do not request extra data.\nIf not reproducible: request only minimal reproducible inputs.\nIf prior comment already solved the ask: provide concise delta only.\nDo not present unverified root cause as fact.\nKeep language matched to issue language unless user asks otherwise.\n\nPublish Gate\n\nIf no explicit publish confirmation exists, end with:\n\nChinese: 是否直接发布到 issue #？回复“发布”或“先不发”。\nEnglish: Post this to issue # now? Reply \"post\" or \"hold\".\n\nIf output_mode=pipeline, append one machine-readable block after the human output:\n\nhandoff:\n issue_classification:\n type: \"功能咨询|问题排查|技术讨论|Bug 反馈|Feature request\"\n validation_path: \"behavior-regression|consultative-support\"\n confidence: \"high|medium|low\"\n triage_decision:\n labels_to_add: []\n missing_info_fields: []\n ready_for_issue_to_pr: false\n ready_reason: \"\"\n implementation_handoff:\n goal: \"\"\n acceptance_criteria: []\n suggested_modules: []\n risk_hints: []" }, { "title": "Load References When Needed", "body": "Use references/diagnostic-playbook.md for scenario-specific diagnostics and command snippets.\nUse references/reply-templates.md for reusable Chinese maintainer reply skeletons." } ], "body": "Apollo Issue Review\n\nFollow this workflow to review an Apollo issue and produce a concise maintainer response.\n\nCore Principles\nClassify first: behavior/regression issue vs consultative/support question.\nFor behavior/regression issues: reproduce first, theorize second.\nFor consultative/support questions (for example \"is there an official script/doc\"): do evidence check first and answer directly; do not force \"reproduced/not reproduced\" wording.\nSolve the user ask, do not debate whether the user is right or wrong.\nIf behavior is already reproduced and conclusion is stable, do not ask for extra info.\nDo not default to \"version regression\" analysis unless the user explicitly asks for version comparison or it changes the recommendation.\nMatch the issue language: English issue -> English reply, Chinese issue -> Chinese reply (unless the user explicitly asks for bilingual output).\nUse canonical Apollo module names from repository reality (AGENTS/module layout/root pom.xml), and correct misnamed terms succinctly when needed.\nIf an existing comment already answers the same ask (including bot replies), avoid duplicate long replies; prefer a short addendum that only contributes corrections or missing deltas.\nNever wrap GitHub @mention handles in backticks/code spans; use plain @handle so notifications are actually triggered.\nIf a community user volunteers to implement (\"认领\"/\"first contribution\"), acknowledge and encourage first, then evaluate the proposal with explicit feasibility boundaries and concrete refinement suggestions.\nFor OpenAPI-related asks, explicitly separate Portal web APIs (e.g., /users) and OpenAPI endpoints (e.g., /openapi/v1/*); only claim \"OpenAPI supports X\" when token-based OpenAPI path is verified.\nBefore concluding \"capability not available\", cross-check code + docs/scripts + module/dependency hints from pom.xml to avoid false negatives caused by path assumptions.\nInput Contract\n\nCollect or derive these fields before review:\n\nrepo: /\nissue_number: numeric ID\nissue_context: title/body/comments\npublish_mode: draft-only (default) or post-after-confirm\noutput_mode: human (default) or pipeline\n\nOptional but recommended:\n\nknown_labels: existing labels on the issue\ndesired_outcome: whether user wants only triage or triage + implementation handoff\n\nIf issue_number or issue_context is missing, ask one short clarification before continuing.\n\nWorkflow\nCollect issue facts and user ask\nRead issue body and comments before concluding.\nExtract: primary ask, symptom, expected behavior, actual behavior, and whether user asks one path or an either-or path.\nKeep user asks explicit (for example \"better parsing API OR raw text API\": answer both).\nDetect whether the thread includes a contribution-claim ask (for example \"can I take this issue?\") and treat it as a guidance+boundary response, not only a capability yes/no response.\nDetect main language from issue title/body/recent comments and set reply language before drafting.\nDecide issue type up front:\nbehavior/regression (needs reproducibility check)\nconsultative/support (needs evidence check)\nNormalize names to canonical module/service terms used by Apollo repo (e.g., apollo-portal, not invented service names).\nIf GitHub API access is unstable, use:\ncurl -L -s https://api.github.com/repos///issues/\ncurl -L -s https://api.github.com/repos///issues//comments\n\nRun the right validation path (mandatory)\nFor behavior/regression issues:\nBuild a minimal, local, runnable reproduction for the reported behavior.\nPrefer repo-native unit tests or a tiny temporary script over speculation.\nRecord exact observed output and types, not just interpretation.\nFor consultative/support questions:\nVerify by repository evidence scan (docs/scripts/code paths), not by speculative reproduction framing.\nFor API availability asks, verify in three places before concluding:\nactual controller paths, 2) docs/openapi scripts, 3) module/dependency pointers in pom.xml.\nRecord exact files/paths searched and what exists vs does not exist.\nExample checks:\nrg -n \"\" -S\ngo test ./... -run \n# or a minimal go run script under /tmp for one-off validation\n# consultative evidence scan example:\nrg --files | rg -i \"\"\nrg -n \"\" docs scripts apollo-* -S\n\nBranch by validation result\nBehavior/regression path:\nIf reproducible:\nState clearly that behavior is confirmed.\nIdentify whether this is supported behavior, usage mismatch, or current feature gap.\nThen answer user asks directly (existing API/workaround/unsupported).\nIf not reproducible:\nAsk for minimal missing evidence only:\ninput sample\nexact read/access code\nexpected vs actual output\nKeep this short and concrete.\nConsultative/support path:\nIf capability/script/doc exists: provide exact path/link and usage entry point.\nIf it does not exist: state \"currently not available\" directly and give one practical alternative.\nIf an existing comment already covered the same conclusion: post only a concise delta/correction instead of repeating the full answer.\nDraft maintainer reply (focus on action)\nStart with a one-paragraph summary in the thread language:\nbehavior/regression issue: reproduction summary (复现结论 / Reproduction Result)\nconsultative/support issue: direct conclusion summary (结论 / Conclusion)\nThen include:\n当前能力与边界: what is supported today and what is not.\n可行方案: exact API/command/workaround user can run now.\n后续路径: either invite PR with concrete files/tests, or state maintainers may plan it later without overpromising timeline.\nIf the thread includes a contribution-claim proposal, structure the main body as:\nappreciation and encouragement, 2) feasibility judgment, 3) concrete implementation refinements (what to reuse vs what not to reuse directly).\nIf user ask is either-or, answer both explicitly.\nIf already confirmed feature gap, do not request more logs/steps by default.\nKeep wording factual and concise.\nUse canonical module names in final wording; if the issue uses a non-canonical name, correct it briefly without derailing the answer.\nIf there is already a correct prior comment, prefer \"reference + minimal supplement\" format.\nIf you mention users/bots, keep mentions as plain text (e.g., @dosubot), not code-formatted mention strings.\nUse localized section labels and wording by issue language (for example: Reproduction Result / Current Support Boundary / Practical Path / Next Step in English threads).\nAsk for publish confirmation (mandatory gate)\nDefault behavior: generate draft only; do not post automatically.\nPresent the exact comment body first, then ask for confirmation in the same thread.\nUse a direct question in the same language as the thread, e.g.:\nChinese: 是否直接发布到 issue #？回复“发布”或“先不发”。\nEnglish: Post this to issue # now? Reply \"post\" or \"hold\".\nTreat no response or ambiguous response as not approved.\nPost the response only after explicit confirmation\nAllowed confirmation examples: 发布 / 帮我发 / 直接回复上去.\nIf user intent is unclear, ask one short clarification question before any post command.\nPreferred:\ngh api repos///issues//comments -f body=''\n\nFallback when gh transport is unstable:\nTOKEN=$(gh auth token)\ncurl --http1.1 -sS -X POST \\\n -H \"Authorization: token $TOKEN\" \\\n -H \"Accept: application/vnd.github+json\" \\\n -d '{\"body\":\"\"}' \\\n https://api.github.com/repos///issues//comments\n\nAfter posting, return the comment URL as evidence.\nOutput Contract\n\nDefault (output_mode=human) output should be human-friendly:\n\nIssue Summary\nissue type + confidence\nvalidation result (reproduced / not reproduced / evidence result)\nTriage Suggestion\nlabels to add\nmissing information (if any)\nwhether it is ready for implementation handoff\nDraft Maintainer Reply\nFirst sentence must match issue type:\nbehavior/regression: reproducibility status (已复现/暂未复现 or Reproduced/Not yet reproduced)\nconsultative/support: direct availability conclusion\nInclude at least one concrete API/code path/file reference.\nIf unsupported today: include support boundary + practical workaround + next path.\nIf reproducible and conclusion is stable: do not request extra data.\nIf not reproducible: request only minimal reproducible inputs.\nIf prior comment already solved the ask: provide concise delta only.\nDo not present unverified root cause as fact.\nKeep language matched to issue language unless user asks otherwise.\nPublish Gate\nIf no explicit publish confirmation exists, end with:\nChinese: 是否直接发布到 issue #？回复“发布”或“先不发”。\nEnglish: Post this to issue # now? Reply \"post\" or \"hold\".\n\nIf output_mode=pipeline, append one machine-readable block after the human output:\n\nhandoff:\n issue_classification:\n type: \"功能咨询|问题排查|技术讨论|Bug 反馈|Feature request\"\n validation_path: \"behavior-regression|consultative-support\"\n confidence: \"high|medium|low\"\n triage_decision:\n labels_to_add: []\n missing_info_fields: []\n ready_for_issue_to_pr: false\n ready_reason: \"\"\n implementation_handoff:\n goal: \"\"\n acceptance_criteria: []\n suggested_modules: []\n risk_hints: []\n\nLoad References When Needed\nUse references/diagnostic-playbook.md for scenario-specific diagnostics and command snippets.\nUse references/reply-templates.md for reusable Chinese maintainer reply skeletons." }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/nobodyiam/apollo-issue-review", "publisherUrl": "https://clawhub.ai/nobodyiam/apollo-issue-review", "owner": "nobodyiam", "version": "1.0.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/apollo-issue-review", "downloadUrl": "https://openagent3.xyz/downloads/apollo-issue-review", "agentUrl": "https://openagent3.xyz/skills/apollo-issue-review/agent", "manifestUrl": "https://openagent3.xyz/skills/apollo-issue-review/agent.json", "briefUrl": "https://openagent3.xyz/skills/apollo-issue-review/agent.md" } }