Ecosystem Research

Ecosystem Research

Scope

Research target received from orchestrator:

$ARGUMENTS

Confirm the library/protocol/feature and the specific behavior or compatibility concern before proceeding. If either is absent or ambiguous, state the gap and stop.

Step 1 — GitHub Issues and Discussions

Search the primary repository's issue tracker and discussion board for real-world reports.

Search terms to apply (adapt to the library name and feature):

• "doesn't work with", "not supported", "not compatible"
• "workaround for", "gotcha", "unexpected behavior"
• "error" + feature name
• Changelog entries referencing the feature (look for fix:, breaking: prefixes)

For each finding: record the issue or discussion URL, a one-sentence summary of the report, and whether it was resolved.

Step 2 — Client / Host Compatibility

Identify which clients, hosts, or consumers support this feature.

Look for:

• Explicit support statements in official docs (cite URL + access date)
• Issue reports naming specific clients as broken, partial, or missing
• Test matrices or compatibility tables in the repository

Record per-client status as one of: supported, partial, unsupported, unknown. Every status requires an evidence source — do not infer.

Step 3 — Community Patterns

Identify what approaches the community has converged on.

Look for:

• Repeated workarounds appearing across multiple issues or threads
• Alternative implementations recommended by maintainers or frequent contributors
• Patterns that replaced a broken original approach (check changelogs for deprecation notices)

Cite each pattern with at least one source URL. Do not describe a pattern as "common" without at least two independent sources.

Step 4 — Real-World Gotchas

Identify what surprised users — content that is NOT in official docs but IS in issue threads, discussions, blog posts, or changelogs.

Signals to look for:

• Maintainer corrections to user assumptions in issue comments
• Changelog entries for unexpected behavioral changes (not just new features)
• Documentation PRs that added a warning section — the warning was added because someone was burned

Every gotcha requires a source. Gotchas derived from training data are not acceptable — they must come from a retrievable URL.

Step 5 — Alternatives

Identify community-preferred alternatives to broken or missing features.

Look for:

• Issues closed as "use X instead"
• Discussion threads converging on a replacement approach
• README sections recommending alternatives

For each alternative: state what problem it solves, why the original approach was insufficient, and cite the source.

Output Format

Return a structured report in exactly this format:

## Ecosystem Research — {technology/feature} — {date}

### Community Usage Patterns
[patterns with source URLs — one bullet per pattern, each with at least one URL]

### Client / Host Compatibility
[per-client status: supported / partial / unsupported / unknown — with evidence source for each entry]

### Real-World Gotchas (sourced)
[each item with source — issue URL, discussion link, blog post URL, or changelog entry]

### Alternatives
[community-preferred alternatives to broken or missing features — with evidence]

### Gaps
[explicit list of what was searched for but not found — include search terms used and locations searched]

Every section must appear even if empty. For empty sections, write "None found after searching [locations]."

Constraints

• Every claim requires a source: issue URL, discussion URL, docs URL with access date, or changelog entry. Claims without sources are findings gaps, not findings.
• Do NOT rely on training data for version-specific facts, bug reports, or compatibility claims. Training data reflects a past snapshot; issue trackers are current.
• Do NOT write to any backlog item. Return all content to the caller.
• Do NOT broaden scope to domain discovery. If the caller asks about a specific library, research that library — do not survey alternatives unless Step 5 applies.
• Rate limit transparency: if a search endpoint returns fewer results than expected, or blocks entirely, note it in the Gaps section and report what was searched before the limit was reached.