qwen3-mcp-oz-v2

Got it — here’s a tighter, failure-resistant prompt that improves the model’s structure of thought (explicit tool plan, retries, zero “thinking aloud”), plus a reusable report template. I’ve **replaced** your file with a better version and added a template you can reuse.

````md
# path: qwen3-mcp-osmosis.md
# MCP Osmosis Prompt (concise, no chain-of-thought leakage)

## Objective
Given a user topic (e.g., a library like `@crxjs/vite-plugin`), **gather authoritative context using any of**: `gitmcp`, `mcp-deepwiki`, `contex7`. Then produce a concise, source-backed report.

## Ground Rules
- **Do not output internal reasoning.** Only output the final report + appendix per the schema below.
- **Don’t stall on questions.** If something is ambiguous, make one reasonable assumption and proceed; state the assumption in the report.
- **Respect the tool budget.** Each tool gets up to **2 attempts** per sub-goal before you switch tools.
- **Prefer primary sources first.** Official repos, docs, and spec pages outrank blogs.
- **Cite every non-trivial claim** with a source in the Appendix (tool + identifier).

## Tool Playbook (ordered)
1) **contex7 first (ID resolution)**
   - Try to resolve a library ID from the exact user token.
   - If not found, try: stripped scope name, common aliases, and nearest-match suggestions.
   - If an ID is found, fetch library docs/metadata/snippets.

2) **gitmcp next (code/doc ground truth)**
   - If you know the owner/repo: fetch `README`, `docs/*`, `CHANGELOG*`, `examples/*`.
   - If not: run a repo discovery (search by package name, keywords) and pick the highest-signal repo (stars, recency, docs presence).

3) **mcp-deepwiki for conceptual/background**
   - Pull short, high-yield summaries to explain core ideas, constraints, and ecosystem fit.
   - Use only to augment (never replace) primary findings.

## Minimal Retry Policy
- On tool error or empty result:
  - Adjust the query once (e.g., remove scope `@`, try alt names).
  - If still empty, switch tools per the playbook order instead of looping.

## Data You Must Extract (when available)
- Name, maintainer/org, homepage/repo.
- Purpose and key features (3–7 bullets).
- Supported environments (frameworks, browsers, Node/Vite versions, MV2/MV3, etc.).
- Install & minimal usage snippet.
- Gotchas/limitations and common failure modes.
- Alternatives and quick “when to choose X vs Y”.
- Version/maintenance status and last update date.

## Output Schema (exact)
Produce **only** this structure:

### Report
**Topic:** <resolved topic/name>  
**Assumption (if any):** <1–2 lines or “None”>

#### What it is (TL;DR)
- <bullets>

#### When to use it
- <bullets>

#### Setup & minimal example
```bash
# install
<command(s)>
````

```ts
// vite.config.*
<minimal config demonstrating core usage>
```

#### Key capabilities

* <bullets>

#### Limitations & pitfalls

* <bullets>

#### Alternatives (and when to prefer them)

* <A vs B vs C in one short table or bullets>

#### Version & maintenance

* Current version: <semver if known>
* Last meaningful update: <date or “unknown”>
* Maintenance signal: <active / sporadic / archived> (why)

---

### Appendix: Sources & Tool Log

* contex7: <queries/IDs used, matches chosen>
* gitmcp: <repo paths fetched>
* deepwiki: <topics/URLs summarized>
* Notes: <brief notes on retries/fallbacks>

## Example Invocation (for this prompt)

* **Input:** “Use any of gitmcp / mcp-deepwiki / contex7 to gather context on `@crxjs/vite-plugin`, then make a report.”
* **Behavior:**

  1. contex7.resolve(`@crxjs/vite-plugin`) → if miss, try `crxjs vite plugin`, `vite-plugin-chrome-extension`, `vite-plugin-web-extension`.
  2. gitmcp: discover repo if not known; fetch README + docs.
  3. deepwiki: summarize Chrome Extension + Vite MV3 background.
  4. Generate report per schema (no chain-of-thought).

## Style

* Be brief, source-backed, and actionable.
* Prefer bullets, one minimal code path, and a compact alternatives section.

````

```md
# path: mcp-report-template.md
### Report
**Topic:** {{resolved_name}}  
**Assumption (if any):** {{assumption_or_None}}

#### What it is (TL;DR)
- {{bullet}}
- {{bullet}}
- {{bullet}}

#### When to use it
- {{bullet}}
- {{bullet}}

#### Setup & minimal example
```bash
# install
{{install_command}}
````

```ts
// vite.config.*
{{minimal_config}}
```

#### Key capabilities

* {{bullet}}
* {{bullet}}
* {{bullet}}

#### Limitations & pitfalls

* {{bullet}}
* {{bullet}}

#### Alternatives (and when to prefer them)

* {{alt A}} — {{when}}
* {{alt B}} — {{when}}
* {{alt C}} — {{when}}

#### Version & maintenance

* Current version: {{semver_or_unknown}}
* Last meaningful update: {{date_or_unknown}}
* Maintenance signal: {{active/sporadic/archived}} — {{1-line justification}}

---

### Appendix: Sources & Tool Log

* contex7: {{calls + chosen IDs}}
* gitmcp: {{repo paths fetched}}
* deepwiki: {{topics/URLs summarized}}
* Notes: {{retries/fallbacks}}

```

### Why this improves interactions
- **No chain-of-thought leakage:** the prompt forbids printing “thought” blocks; users only see the clean report + audit trail.
- **Deterministic tool order + fallback:** avoids indecisive loops shown in your log by hardcoding a playbook and retry limits.
- **Primary-first evidence:** pushes repo/docs before secondary summaries, reducing hallucinations.
- **Uniform output:** a locked schema makes results skimmable and comparable across runs.
- **One assumption policy:** keeps momentum without interrogating the user mid-run.
```