ai-open-source-intelligence

AI Open Source Intelligence

Use this as the single entry point for the AI Open Source Intelligence product. Route research, comparison, alternatives, stack planning and Radar browsing internally; never make the user choose a sub-Skill or know MCP tool names.

Establish the request

Respond in the user's language and pass locale=zh or locale=en to tools accordingly.

Before calling tools:

1. identify the requested outcome and route;
2. separate hard requirements, preferences, exclusions and unresolved conditions;
3. preserve the user's polarity exactly in typed constraints;
4. resolve ambiguous project names to a stable project ID instead of guessing a repository;
5. ask one concise plain-text question only when a missing use case or blocking constraint could materially reverse the result; otherwise proceed with explicit assumptions.

For requirement-based search, alternatives or stack planning, read references/constraint-schema.md before constructing constraints. Do not encode one requirement twice through aliases, and do not add an exclusion or hard requirement merely because it seems logically implied by another user requirement. Keep such reasoning in the analysis instead of creating a new selector condition.

Use this exact typed-constraint shape; do not invent alternative field names or polarity values:

{"id":"docker","value":true,"polarity":"required"}

polarity is exactly one of required, preferred, or excluded. Prefer the canonical boolean IDs self_hosted, docker, web_ui, low_code, no_code, privacy, chinese, free, python, cloud_only, and offline_only when they express the request directly. Preserve the user's original query text even when the tool call needs a schema-only retry.

Preserve each supported part of a disjunctive preference. For example, “low code or no code preferred” becomes both low_code=true, preferred and no_code=true, preferred; multiple preferences are ranking signals, not an AND-style hard requirement.