Deerflow Maintainer Orchestrator

DeerFlow Maintainer Orchestrator

Core Rule

This is a comment-plane skill: resolve GitHub scope, inspect evidence, and prepare or post DeerFlow issue comments and PR review comments. Keep the work comment-scoped; do not turn it into coding, branch management, release work, artifact closure, or other maintainer operations.

When the maintainer asks to process, handle, comment on, or review a bounded set of issues or PRs, proceed without asking follow-up questions. Treat that request as authorization for one public issue comment per selected non-skipped issue and one PR review comment per selected PR with high-confidence findings. If a PR has no high-confidence findings, do not post a public comment; report that result to the maintainer only. If the maintainer explicitly asks for analysis only, return comment-ready drafts without posting.

The maintainer's normal interaction should be: provide scope; receive posted comment URLs, PR review URLs, clean results, skipped items, failures, or drafts. Do not offload technical analysis to the maintainer. Make the best evidence-backed recommendation in the comment itself: describe the risk, impact, likely fix, and validation path. Ask the reporter or PR author for missing evidence only when the artifact lacks enough data to diagnose.

Output only the maintainer run result or comment draft. Do not announce the skill name, mode, or that no code was edited unless the user asks for process details.

Match the dominant language of the issue or PR unless the maintainer asks for another language. Chinese issue or PR text gets Chinese output; English issue or PR text gets English output. For mixed artifacts, use the body language, not logs or code.

Artifact Resolution

Use GitHub tooling to resolve artifact type and scope. Do not ask the maintainer to clarify when gh or GitHub API can determine the answer.

1. Default repository is bytedance/deer-flow unless a URL or explicit repo says otherwise.
2. For URLs, route /issues/<number> to Issue Flow and /pull/<number> to PR Review Flow.
3. For typed numbers, use the typed command:
   • Issue: gh issue view <number> --repo <repo> --json number,title,url,state,body,labels,author,comments
   • PR: gh pr view <number> --repo <repo> --json number,title,url,state,body,author,files,comments,reviews,statusCheckRollup,baseRefName,headRefName
4. Normalize multiple explicit references such as #123, # 123, and bare 123 into a number list, preserving order and de-duplicating exact repeats.
5. For untyped numbers, try gh pr view <number> --repo <repo> --json number,url first. If it fails, use gh issue view <number> --repo <repo> --json number,url. Do not ask which type it is.
6. For issue batches, use gh issue list, not the mixed GitHub issues endpoint. For PR batches, use gh pr list.
7. Respect maintainer-provided count or time window. There is no hard five-item cap. If the scope is broad and underspecified, choose a practical recent slice, state the slice used, prioritize newest and highest-risk items, and report any unprocessed remainder.
8. For "recent/latest" wording without a count, use a small default recent slice. For "recent hours" wording without a number, use six hours. Do not ask.
9. Use gh api when gh issue/pr view/list lacks required fields such as timeline events, review threads, or precise search filters.
10. Use GitHub search only as a fallback for natural-language filters that cannot be represented by view/list/API calls. Do not use web search for artifact routing unless GitHub tooling is unavailable.
11. When an issue has more than one candidate resolving PR, gather them all before reviewing: the issue's linked/Development PRs, closing keywords (Closes/Fixes #<issue>) found via gh api timeline cross-reference events, and PRs that mention the issue. Route them into Competing PR Comparison.
12. If no artifact type, number, URL, count, time window, or searchable GitHub scope can be resolved, stop with a compact "scope unresolved" report. Do not ask a follow-up question.

Use concise repo-local references such as #123 and PR #123 in maintainer reports and comments. Include full GitHub URLs only for posted comment/review links returned by GitHub or when the maintainer supplied an explicit URL.

Existing Coverage and Re-Runs

Existing comments suppress duplicate posting, not analysis. Always analyze the artifact in full, then post only the net-new delta over what is already covered.

1. Read existing maintainer/trusted-agent comments and reviews as prior coverage.
2. Analyze the artifact fully regardless of what already exists. A prior comment may be partial — catching A while missing B.
3. Keep only net-new, high-confidence items not already materially covered.
4. Non-empty delta: post one comment that explicitly builds on the prior coverage (for example Adding to @reviewer's review:) and states only the new items. Do not restate covered points.
5. Empty delta: post nothing public; report Already covered to the maintainer with the existing comment/review URL.
6. Idempotency: treat your own earlier skill-authored comments as already-covered. On a re-run, never stack a second comment that repeats an earlier one — post only genuinely new delta, or nothing.

RFC issues are the one hard skip: no analysis and no post unless the maintainer overrides.

Issue Flow

Use Issue Flow for GitHub issues, bug reports, feature requests, support questions, and issue batches.

Start every issue with a cheap precheck:

1. Fetch issue metadata, labels, author, body, and existing comments.
2. If labels, title, or body mark the issue as RFC (rfc, [RFC], RFC:, or Request for Comments), classify it as rfc-no-comment, skip deep analysis, and do not post anything public unless the maintainer explicitly overrides the RFC skip for that item.
3. Existing maintainer or trusted-agent comments are prior coverage, not an automatic skip. Analyze fully and post only the net-new delta (see Existing Coverage and Re-Runs).
4. Treat ordinary reporter replies, thanks, unrelated discussion, or incomplete guesses as non-blocking.
5. Report already-covered or skipped issues to the maintainer only as compact identifiers plus the reason or existing comment URL when available.

For non-skipped issues:

1. Read enough context to avoid guessing: issue body, comments, screenshots, logs, reproduction details, linked artifacts, and relevant DeerFlow code/docs.
2. Classify the surface:
   • Frontend UI
   • Backend API
   • Agents / LangGraph
   • Sandbox
   • Skills
   • MCP
   • Dependencies
   • Default behavior
   • Docs / tests / CI only
3. Classify actionability:
   • ready-to-fix: bounded, evidence sufficient, validation path clear.
   • needs-more-evidence: repro, logs, environment, screenshots, exact expected behavior, or failing case missing.
   • defer-or-close: duplicate, stale, unsupported, unactionable, or out of scope.
   • rfc-no-comment: RFC issue; skip public comments by default.
4. Produce a public-safe comment from the analysis, not the analysis labels:
   • Start with one natural opener that connects to the issue context. Prefer Thanks @author. for reporter-authored issues when it reads naturally; omit the mention for bots, maintainer-authored tracking issues, or cases where it would add noise.
   • The opener must say something specific about the next step or boundary, not a generic assessment. Do not use generic phrases such as "This is actionable", "I would treat this as", "ready to fix", or surface/actionability/risk labels.
   • Use the smallest stable template that fits:

Thanks @author. <one specific sentence that frames the fix, investigation, or missing evidence.>

Recommended solution:
- ...

Validation:
- ...

• Add Evidence: only when citing concrete code, logs, reproduction details, or other proof helps the author act.
• Add Risk: only when architecture, security, public API, default behavior, or compatibility impact must be called out explicitly; make the risk specific.
• Add Missing info: only when the issue cannot be diagnosed without more evidence; ask for the smallest useful data.
• Put relevant files/components inside Evidence: or Recommended solution: bullets instead of separate metadata fields.
• Every posted issue comment should contain concrete modification guidance and validation guidance unless the only useful response is Missing info:.

5. Immediately before posting, refresh comments; fold any equivalent comment that appeared during analysis into prior coverage and post only the remaining delta.
6. Post one issue comment when posting is authorized; otherwise return the same text as Reply draft.

Do not expose private reasoning, credentials, internal-only context, or unsupported promises. Do not say a fix was made unless a separate coding workflow actually changed code.

PR Review Flow

Use PR Review Flow for GitHub pull requests and PR batches.

Start every PR with a cheap precheck:

1. Fetch PR metadata, changed file list, checks summary, existing PR reviews, existing PR comments, and review threads when available.
2. Existing maintainer or trusted-agent reviews are prior coverage, not an automatic skip. Review fully and post only the net-new delta (see Existing Coverage and Re-Runs).
3. Read statusCheckRollup as signal, not verdict. Failing required checks are themselves a reportable finding (build failure = P0; failing tests or lint = P1/P2 by impact). Green checks lower risk but never excuse reading the actual changed code path — confirm suspect logic by reading the source, not by trusting green CI. Tests passing does not prove the changed branch is exercised.
4. Treat author replies, thanks, unrelated discussion, or incomplete guesses as non-blocking.
5. Report already-covered or clean PRs to the maintainer only, with the existing review/comment URL when available.