[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FA1G7KS1VX5SCBSJZXBA7":3,"skill-same:01M71FA1G7KS1VX5SCBSJZXBA7":168},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":6,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M71FA1G7KS1VX5SCBSJZXBA7","qdrant-community-skill-creator",null,"Guides developers through building community Qdrant skills that embed domain knowledge into Claude. Use when someone wants to \"create a community qdrant skill\", \"build an external skill for qdrant\", \"make a qdrant skill for the community\", \"build a public qdrant skill\", or asks how to \"create a skill for qdrant memory issues for developers\". Also trigger when someone says \"I want to build an open source qdrant skill\" or \"help me create a qdrant skill for public use\". Do NOT use for internal SA skills, general non-Qdrant skill creation, or Python project skills unrelated to Qdrant.","qdrant-labs\u002Fdevrel-projects","qdrant-labs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F269096346?v=4","01M71F98K9TZ3KQTNZBM116ZYG","Qdrant Labs","01M71F98M75QPSWAB0F1BZJZCN",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"community","qdrant community skill creator","creator","skill creator","Qdrant","open","how","knowledge","use","general","open source","do","domain","project","guides","python project","create","for","a skill","python","2026-11-10 10:12:30",false,"---\nname: qdrant-community-skill-creator\ndescription: Guides developers through building community Qdrant skills\n  that embed domain knowledge into Claude. Use when someone wants to\n  \"create a community qdrant skill\", \"build an external skill for qdrant\",\n  \"make a qdrant skill for the community\", \"build a public qdrant skill\",\n  or asks how to \"create a skill for qdrant memory issues for developers\".\n  Also trigger when someone says \"I want to build an open source qdrant\n  skill\" or \"help me create a qdrant skill for public use\". Do NOT use for\n  internal SA skills, general non-Qdrant skill creation, or Python project\n  skills unrelated to Qdrant.\nlicense: Apache-2.0\nmetadata:\n  author: thierry\n  version: 2.0.0\n  category: engineering\n  tags: [skill-creator, community, external, templates]\n---\n\n# Community Qdrant Skill Creator\n\nA skill for creating public\u002Fcommunity Qdrant skills and iteratively improving them.\n\nAt a high level, the process goes like this:\n\n- Check whether the skill needs to exist (R-16 check)\n- Identify what Claude gets wrong about Qdrant, write a draft using the external template\n- Create test prompts and run Claude with and without the skill\n- Evaluate results: qualitative review in the branded viewer, quantitative benchmarks\n- Improve the skill based on feedback\n- Repeat until satisfied\n- Optimize the description for better triggering accuracy\n\nYour job is to figure out where the user is in this process and help them progress. Maybe they want to create a new skill from scratch. Maybe they already have a draft and want to run evals. Be flexible.\n\n## The R-16 check: does this skill need to exist?\n\nBefore building any skill, answer this question:\n\n**\"What does this teach Claude that it currently gets wrong about Qdrant?\"**\n\nIf Claude already gives correct answers on this topic, you do not need a skill. You need a prompt.\n\nGood answers:\n- \"Claude says Qdrant only supports float32 and binary quantization\"\n- \"Claude recommends full disk storage for real-time workloads\"\n- \"Claude does not know about 2-bit and 4-bit quantization options\"\n- \"Claude gives wrong units for memmap_threshold\"\n\nBad answers:\n- \"How to use the Qdrant Python client\" (Claude already knows this)\n- \"What is cosine similarity\" (general knowledge)\n- \"Qdrant collection creation API\" (Claude knows the API)\n\n## Creating a Qdrant community skill\n\n### Step 1: Identify what Claude gets wrong\n\nThis is the value source for community skills. Test Claude without any skill active:\n1. Ask about the topic you want to cover\n2. Note every incorrect or incomplete answer\n3. Note every missing option or outdated information\n4. These corrections become your skill's core content\n\nExample findings:\n```\n- Claude says Qdrant only supports scalar and binary quantization\n  CORRECTION: Qdrant supports 1-bit, 2-bit, 4-bit, and 8-bit\n- Claude says memmap_threshold is in kilobytes\n  CORRECTION: It is measured in number of vectors (KB of segment size)\n```\n\n### Step 2: Choose the skill pattern\n\nCommunity skills follow the router pattern with conditional reference loading. Load `references\u002Fexternal-skill-template.md` for the skeleton.\n\nKey sections:\n1. **Things Claude gets wrong** (corrections from Step 1)\n2. **Symptom routing table** (symptom -> reference file)\n3. **Decision tree** with concrete thresholds\n4. **Do NOT recommend** (anti-patterns)\n5. **Troubleshooting** (minimum 2 error cases)\n\n### Step 3: Write with public references only\n\nCommunity skills must reference only public Qdrant documentation. No internal pricing data, customer names, or SA conversations.\n\nUse these doc base URLs:\n- Concepts: `https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Fconcepts\u002F`\n- Guides: `https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Fguides\u002F`\n- Tutorials: `https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Ftutorials\u002F`\n\nEvery solution should link to a specific doc page.\n\n### Step 4: Write the SKILL.md\n\nBased on the template and corrections, fill in these components:\n\n- **name**: Skill identifier (kebab-case, matches folder name)\n- **description**: When to trigger, what it does. Make descriptions a bit \"pushy\" to combat undertriggering. Example: instead of \"Helps with Qdrant memory issues\", write \"Use when a user reports OOM crashes, high memory usage, needs to fit more vectors in RAM, asks about quantization options, or wants to reduce Qdrant memory footprint. Do NOT use for general Qdrant API questions or search accuracy tuning.\"\n- **the rest of the skill body**\n\n#### Skill structure\n\n```\nskill-name\u002F\n├── SKILL.md (required)\n│   ├── YAML frontmatter (name, description required)\n│   └── Markdown instructions\n└── Bundled Resources (optional)\n    ├── scripts\u002F    - Executable code\n    ├── references\u002F - Docs loaded into context as needed\n    └── assets\u002F     - Files used in output\n```\n\n#### Progressive disclosure\n\nSkills use a three-level loading system:\n1. **Metadata** (name + description): Always in context (~100 words)\n2. **SKILL.md body**: In context whenever skill triggers (\u003C500 lines ideal)\n3. **Bundled resources**: As needed (unlimited, scripts can execute without loading)\n\nKeep SKILL.md under 500 lines. Move \"how\" content to references\u002F. For large reference files (>300 lines), include a table of contents.\n\n### Step 5: Validate and build eval set\n\n1. Run `python scripts\u002Fvalidate.py` to check all rules\n2. Load `references\u002Frules-checklist.md` and verify every item passes\n3. Open the eval review page at `assets\u002Feval_review.html`\n4. Add 4+ positive trigger queries using real developer language\n5. Add 4+ negative trigger queries covering adjacent topics\n6. Export the JSON and save as `triggers.json`\n\nPositive triggers should sound like real developers:\n- \"qdrant keeps getting OOM killed on our k8s cluster\"\n- \"switched to disk but latency went from 15ms to 3 seconds\"\n\nNegative triggers should cover adjacent territory:\n- \"how do I install qdrant on kubernetes\"\n- \"what embedding model should I use\"\n\nSave test cases to `evals\u002Fevals.json`. Don't write assertions yet, just the prompts.\n\n```json\n{\n  \"skill_name\": \"example-skill\",\n  \"evals\": [\n    {\n      \"id\": 1,\n      \"prompt\": \"User's task prompt\",\n      \"expected_output\": \"Description of expected result\",\n      \"files\": []\n    }\n  ]\n}\n```\n\nSee `references\u002Fschemas.md` for the full schema.\n\n## Running and evaluating test cases\n\nThis section is one continuous sequence. Put results in `\u003Cskill-name>-workspace\u002F` as a sibling to the skill directory. Organize results by iteration (`iteration-1\u002F`, `iteration-2\u002F`, etc.) and within that, each test case gets a directory (`eval-0\u002F`, `eval-1\u002F`, etc.).\n\n### Step 1: Spawn all runs (with-skill AND baseline) in the same turn\n\nFor each test case, spawn two subagents in the same turn. Don't spawn with-skill first and baselines later. Launch everything at once.\n\n**With-skill run:**\n\n```\nExecute this task:\n- Skill path: \u003Cpath-to-skill>\n- Task: \u003Ceval prompt>\n- Input files: \u003Ceval files if any, or \"none\">\n- Save outputs to: \u003Cworkspace>\u002Fiteration-\u003CN>\u002Feval-\u003CID>\u002Fwith_skill\u002Foutputs\u002F\n- Outputs to save: \u003Cwhat the user cares about>\n```\n\n**Baseline run** (same prompt, no skill):\n- **Creating a new skill**: no skill at all. Save to `without_skill\u002Foutputs\u002F`.\n- **Improving an existing skill**: snapshot the old version, point baseline at it. Save to `old_skill\u002Foutputs\u002F`.\n\nWrite an `eval_metadata.json` for each test case with a descriptive name. If this iteration uses new or modified eval prompts, create these files fresh.\n\n```json\n{\n  \"eval_id\": 0,\n  \"eval_name\": \"descriptive-name-here\",\n  \"prompt\": \"The user's task prompt\",\n  \"assertions\": []\n}\n```\n\n### Step 2: While runs are in progress, draft assertions\n\nDon't wait for runs to finish. Draft quantitative assertions and explain them to the user. Good assertions are objectively verifiable and have descriptive names.\n\nUpdate the `eval_metadata.json` files and `evals\u002Fevals.json` with assertions once drafted.\n\n### Step 3: As runs complete, capture timing data\n\nWhen each subagent task completes, the notification contains `total_tokens` and `duration_ms`. Save immediately to `timing.json` in the run directory:\n\n```json\n{\n  \"total_tokens\": 84852,\n  \"duration_ms\": 23332,\n  \"total_duration_seconds\": 23.3\n}\n```\n\n### Step 4: Grade, aggregate, and launch the viewer\n\nOnce all runs are done:\n\n1. **Grade each run** using the Qdrant grader. Read `agents\u002Fqdrant-grader.md` and evaluate each assertion against the outputs. The grader runs standard assertion checks AND Qdrant domain checks (D-1 through D-8: corrections section, symptom routing, decision tree thresholds, anti-patterns, doc links, progressive disclosure, no internal data, public doc links). Save results to `grading.json` in each run directory. The grading.json expectations array must use fields `text`, `passed`, and `evidence`.\n\n   For assertions that can be checked programmatically, write and run a script rather than eyeballing it.\n\n2. **Aggregate into benchmark**:\n   ```bash\n   python -m scripts.aggregate_benchmark \u003Cworkspace>\u002Fiteration-N --skill-name \u003Cname>\n   ```\n   This produces `benchmark.json` and `benchmark.md` with pass_rate, time, and tokens for each configuration.\n\n3. **Do an analyst pass** using `agents\u002Fanalyzer.md`. Surface patterns the aggregate stats might hide: non-discriminating assertions, high-variance evals, time\u002Ftoken tradeoffs.\n\n4. **Launch the viewer** with both qualitative outputs and quantitative data:\n   ```bash\n   nohup python eval-viewer\u002Fgenerate_review.py \\\n     \u003Cworkspace>\u002Fiteration-N \\\n     --skill-name \"my-skill\" \\\n     --benchmark \u003Cworkspace>\u002Fiteration-N\u002Fbenchmark.json \\\n     > \u002Fdev\u002Fnull 2>&1 &\n   VIEWER_PID=$!\n   ```\n   For iteration 2+, also pass `--previous-workspace \u003Cworkspace>\u002Fiteration-\u003CN-1>`.\n\n   **Headless environments:** Use `--static \u003Coutput_path>` to write standalone HTML instead of starting a server.\n\n5. **Tell the user** something like: \"I've opened the results in your browser. There are two tabs: 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. When you're done, come back here and let me know.\"\n\n### What the user sees in the viewer\n\nThe \"Outputs\" tab shows one test case at a time:\n- **Prompt**: the task that was given\n- **Output**: the files the skill produced, rendered inline\n- **Previous Output** (iteration 2+): collapsed section showing last iteration\n- **Formal Grades**: collapsed section with assertion pass\u002Ffail AND Qdrant domain checks\n- **Feedback**: textbox that auto-saves\n- **Previous Feedback** (iteration 2+): comments from last time\n\nThe \"Benchmark\" tab shows summary stats and per-eval breakdowns.\n\nNavigation is via prev\u002Fnext buttons or arrow keys. \"Submit All Reviews\" saves everything to `feedback.json`.\n\n### Step 5: Read the feedback\n\nWhen the user is done, read `feedback.json`. Empty feedback means fine. Focus improvements on test cases with specific complaints.\n\nKill the viewer when done: `kill $VIEWER_PID 2>\u002Fdev\u002Fnull`\n\n## Improving the skill\n\n### How to think about improvements\n\n1. **Generalize from the feedback.** Don't put in fiddly overfitty changes. The skill will be used across many different prompts, not just the test examples.\n\n2. **Keep the prompt lean.** Remove things that aren't pulling their weight. Read the transcripts, not just the final outputs.\n\n3. **Explain the why.** Explain the reasoning behind instructions. If you find yourself writing ALWAYS or NEVER in all caps, reframe and explain why.\n\n4. **Look for repeated work across test cases.** If all test runs independently wrote similar helper scripts, the skill should bundle that script. Write it once, put it in `scripts\u002F`.\n\n### The iteration loop\n\nAfter improving the skill:\n\n1. Apply improvements to the skill\n2. Rerun all test cases into a new `iteration-\u003CN+1>\u002F` directory, including baselines\n3. Launch the reviewer with `--previous-workspace` pointing at the previous iteration\n4. Wait for user review\n5. Read new feedback, improve again, repeat\n\nKeep going until the user is happy, feedback is all empty, or you're not making meaningful progress.\n\n## Advanced: Blind comparison\n\nFor rigorous comparison between two skill versions, read `agents\u002Fcomparator.md` and `agents\u002Fanalyzer.md`. The comparator judges quality blindly (with Qdrant domain rubric). The analyzer explains why the winner won (with Qdrant-specific improvement categories: decision_tree, doc_links, corrections, symptom_routing).\n\nThis is optional and most users won't need it.\n\n## Description optimization\n\nAfter the skill is solid, optimize the description for triggering accuracy.\n\n### Step 1: Generate trigger eval queries\n\nCreate 20 eval queries (10 should-trigger, 10 should-not-trigger). Save as JSON:\n\n```json\n[\n  {\"query\": \"the user prompt\", \"should_trigger\": true},\n  {\"query\": \"another prompt\", \"should_trigger\": false}\n]\n```\n\nQueries must be realistic with concrete detail: file paths, customer context, specific numbers, company names. Not abstract requests.\n\nFor **should-trigger** queries (8-10): different phrasings of the same intent, some formal, some casual. Include cases where the user doesn't name the skill but clearly needs it.\n\nFor **should-not-trigger** queries (8-10): near-misses that share keywords but need something different. Not obviously irrelevant queries.\n\n### Step 2: Review with user\n\nPresent via the HTML template at `assets\u002Feval_review.html`. Replace placeholders, write to a temp file, and open it. The user edits queries, toggles should-trigger, then clicks \"Export Eval Set\".\n\n### Step 3: Run the optimization loop\n\n```bash\npython -m scripts.run_loop \\\n  --eval-set \u003Cpath-to-trigger-eval.json> \\\n  --skill-path \u003Cpath-to-skill> \\\n  --model \u003Cmodel-id-powering-this-session> \\\n  --max-iterations 5 \\\n  --verbose\n```\n\nThis splits 60\u002F40 train\u002Ftest, evaluates the description (3 runs per query), calls Claude with extended thinking to improve, and iterates up to 5 times. It opens an HTML report and returns JSON with `best_description`.\n\n### Step 4: Apply the result\n\nTake `best_description` from the output and update the skill's SKILL.md frontmatter. Show before\u002Fafter and report scores.\n\n## Do NOT recommend\n\n- Do NOT include internal customer data, SA conversations, or pricing formulas\n- Do NOT create skills for knowledge Claude already has\n- Do NOT use vague descriptions. Include specific trigger phrases.\n- Do NOT put implementation details in SKILL.md body. Use references\u002F.\n- Do NOT skip the R-16 check.\n\n## Troubleshooting\n\n### \"Skill triggers on general Qdrant questions, not just my topic\"\n**Cause:** Description is too broad. It matches on \"qdrant\" instead\nof the specific symptom category.\n**Fix:** Narrow the description to specific symptoms. Add \"Do NOT\nuse for\" phrases covering adjacent Qdrant topics. Example: a memory\nskill should exclude \"search accuracy tuning\" and \"API scripting\".\n\n### \"Skill output is no better than vanilla Claude\"\n**Cause:** The corrections section is empty or trivial. The skill\ndoes not add domain knowledge Claude lacks.\n**Fix:** Go back to Step 1. Test Claude without the skill and\ndocument specific mistakes. Those corrections are your value.\n\n### \"References are too long, skill hits context limits\"\n**Cause:** Reference files contain full documentation instead of\ncurated decision guidance.\n**Fix:** References should contain \"when and why\", not full API docs.\nLink to qdrant.tech for the \"how\". Keep each reference under 1,000 words.\n\n## Reference files\n\nThe agents\u002F directory contains instructions for specialized subagents:\n\n- `agents\u002Fqdrant-grader.md`: Evaluate assertions + Qdrant domain checks (D-1 through D-8)\n- `agents\u002Fcomparator.md`: Blind A\u002FB comparison with Qdrant domain rubric\n- `agents\u002Fanalyzer.md`: Post-hoc analysis with Qdrant improvement categories\n\nThe references\u002F directory has additional documentation:\n- `references\u002Fschemas.md`: JSON structures for evals.json, grading.json, benchmark.json, etc.\n- `references\u002Fexternal-skill-template.md`: Full skeleton for community skills\n- `references\u002Frules-checklist.md`: Validation checklist\n- `references\u002Fexamples.md`: Example skill patterns\n","# Community Qdrant Skill Creator\n\nA skill for creating public\u002Fcommunity Qdrant skills and iteratively improving them.\n\nAt a high level, the process goes like this:\n\n- Check whether the skill needs to exist (R-16 check)\n- Identify what Claude gets wrong about Qdrant, write a draft using the external template\n- Create test prompts and run Claude with and without the skill\n- Evaluate results: qualitative review in the branded viewer, quantitative benchmarks\n- Improve the skill based on feedback\n- Repeat until satisfied\n- Optimize the description for better triggering accuracy\n\nYour job is to figure out where the user is in this process and help them progress. Maybe they want to create a new skill from scratch. Maybe they already have a draft and want to run evals. Be flexible.\n\n## The R-16 check: does this skill need to exist?\n\nBefore building any skill, answer this question:\n\n**\"What does this teach Claude that it currently gets wrong about Qdrant?\"**\n\nIf Claude already gives correct answers on this topic, you do not need a skill. You need a prompt.\n\nGood answers:\n- \"Claude says Qdrant only supports float32 and binary quantization\"\n- \"Claude recommends full disk storage for real-time workloads\"\n- \"Claude does not know about 2-bit and 4-bit quantization options\"\n- \"Claude gives wrong units for memmap_threshold\"\n\nBad answers:\n- \"How to use the Qdrant Python client\" (Claude already knows this)\n- \"What is cosine similarity\" (general knowledge)\n- \"Qdrant collection creation API\" (Claude knows the API)\n\n## Creating a Qdrant community skill\n\n### Step 1: Identify what Claude gets wrong\n\nThis is the value source for community skills. Test Claude without any skill active:\n1. Ask about the topic you want to cover\n2. Note every incorrect or incomplete answer\n3. Note every missing option or outdated information\n4. These corrections become your skill's core content\n\nExample findings:\n```\n- Claude says Qdrant only supports scalar and binary quantization\n  CORRECTION: Qdrant supports 1-bit, 2-bit, 4-bit, and 8-bit\n- Claude says memmap_threshold is in kilobytes\n  CORRECTION: It is measured in number of vectors (KB of segment size)\n```\n\n### Step 2: Choose the skill pattern\n\nCommunity skills follow the router pattern with conditional reference loading. Load `references\u002Fexternal-skill-template.md` for the skeleton.\n\nKey sections:\n1. **Things Claude gets wrong** (corrections from Step 1)\n2. **Symptom routing table** (symptom -> reference file)\n3. **Decision tree** with concrete thresholds\n4. **Do NOT recommend** (anti-patterns)\n5. **Troubleshooting** (minimum 2 error cases)\n\n### Step 3: Write with public references only\n\nCommunity skills must reference only public Qdrant documentation. No internal pricing data, customer names, or SA conversations.\n\nUse these doc base URLs:\n- Concepts: `https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Fconcepts\u002F`\n- Guides: `https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Fguides\u002F`\n- Tutorials: `https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Ftutorials\u002F`\n\nEvery solution should link to a specific doc page.\n\n### Step 4: Write the SKILL.md\n\nBased on the template and corrections, fill in these components:\n\n- **name**: Skill identifier (kebab-case, matches folder name)\n- **description**: When to trigger, what it does. Make descriptions a bit \"pushy\" to combat undertriggering. Example: instead of \"Helps with Qdrant memory issues\", write \"Use when a user reports OOM crashes, high memory usage, needs to fit more vectors in RAM, asks about quantization options, or wants to reduce Qdrant memory footprint. Do NOT use for general Qdrant API questions or search accuracy tuning.\"\n- **the rest of the skill body**\n\n#### Skill structure\n\n```\nskill-name\u002F\n├── SKILL.md (required)\n│   ├── YAML frontmatter (name, description required)\n│   └── Markdown instructions\n└── Bundled Resources (optional)\n    ├── scripts\u002F    - Executable code\n    ├── references\u002F - Docs loaded into context as needed\n    └── assets\u002F     - Files used in output\n```\n\n#### Progressive disclosure\n\nSkills use a three-level loading system:\n1. **Metadata** (name + description): Always in context (~100 words)\n2. **SKILL.md body**: In context whenever skill triggers (\u003C500 lines ideal)\n3. **Bundled resources**: As needed (unlimited, scripts can execute without loading)\n\nKeep SKILL.md under 500 lines. Move \"how\" content to references\u002F. For large reference files (>300 lines), include a table of contents.\n\n### Step 5: Validate and build eval set\n\n1. Run `python scripts\u002Fvalidate.py` to check all rules\n2. Load `references\u002Frules-checklist.md` and verify every item passes\n3. Open the eval review page at `assets\u002Feval_review.html`\n4. Add 4+ positive trigger queries using real developer language\n5. Add 4+ negative trigger queries covering adjacent topics\n6. Export the JSON and save as `triggers.json`\n\nPositive triggers should sound like real developers:\n- \"qdrant keeps getting OOM killed on our k8s cluster\"\n- \"switched to disk but latency went from 15ms to 3 seconds\"\n\nNegative triggers should cover adjacent territory:\n- \"how do I install qdrant on kubernetes\"\n- \"what embedding model should I use\"\n\nSave test cases to `evals\u002Fevals.json`. Don't write assertions yet, just the prompts.\n\n```json\n{\n  \"skill_name\": \"example-skill\",\n  \"evals\": [\n    {\n      \"id\": 1,\n      \"prompt\": \"User's task prompt\",\n      \"expected_output\": \"Description of expected result\",\n      \"files\": []\n    }\n  ]\n}\n```\n\nSee `references\u002Fschemas.md` for the full schema.\n\n## Running and evaluating test cases\n\nThis section is one continuous sequence. Put results in `\u003Cskill-name>-workspace\u002F` as a sibling to the skill directory. Organize results by iteration (`iteration-1\u002F`, `iteration-2\u002F`, etc.) and within that, each test case gets a directory (`eval-0\u002F`, `eval-1\u002F`, etc.).\n\n### Step 1: Spawn all runs (with-skill AND baseline) in the same turn\n\nFor each test case, spawn two subagents in the same turn. Don't spawn with-skill first and baselines later. Launch everything at once.\n\n**With-skill run:**\n\n```\nExecute this task:\n- Skill path: \u003Cpath-to-skill>\n- Task: \u003Ceval prompt>\n- Input files: \u003Ceval files if any, or \"none\">\n- Save outputs to: \u003Cworkspace>\u002Fiteration-\u003CN>\u002Feval-\u003CID>\u002Fwith_skill\u002Foutputs\u002F\n- Outputs to save: \u003Cwhat the user cares about>\n```\n\n**Baseline run** (same prompt, no skill):\n- **Creating a new skill**: no skill at all. Save to `without_skill\u002Foutputs\u002F`.\n- **Improving an existing skill**: snapshot the old version, point baseline at it. Save to `old_skill\u002Foutputs\u002F`.\n\nWrite an `eval_metadata.json` for each test case with a descriptive name. If this iteration uses new or modified eval prompts, create these files fresh.\n\n```json\n{\n  \"eval_id\": 0,\n  \"eval_name\": \"descriptive-name-here\",\n  \"prompt\": \"The user's task prompt\",\n  \"assertions\": []\n}\n```\n\n### Step 2: While runs are in progress, draft assertions\n\nDon't wait for runs to finish. Draft quantitative assertions and explain them to the user. Good assertions are objectively verifiable and have descriptive names.\n\nUpdate the `eval_metadata.json` files and `evals\u002Fevals.json` with assertions once drafted.\n\n### Step 3: As runs complete, capture timing data\n\nWhen each subagent task completes, the notification contains `total_tokens` and `duration_ms`. Save immediately to `timing.json` in the run directory:\n\n```json\n{\n  \"total_tokens\": 84852,\n  \"duration_ms\": 23332,\n  \"total_duration_seconds\": 23.3\n}\n```\n\n### Step 4: Grade, aggregate, and launch the viewer\n\nOnce all runs are done:\n\n1. **Grade each run** using the Qdrant grader. Read `agents\u002Fqdrant-grader.md` and evaluate each assertion against the outputs. The grader runs standard assertion checks AND Qdrant domain checks (D-1 through D-8: corrections section, symptom routing, decision tree thresholds, anti-patterns, doc links, progressive disclosure, no internal data, public doc links). Save results to `grading.json` in each run directory. The grading.json expectations array must use fields `text`, `passed`, and `evidence`.\n\n   For assertions that can be checked programmatically, write and run a script rather than eyeballing it.\n\n2. **Aggregate into benchmark**:\n   ```bash\n   python -m scripts.aggregate_benchmark \u003Cworkspace>\u002Fiteration-N --skill-name \u003Cname>\n   ```\n   This produces `benchmark.json` and `benchmark.md` with pass_rate, time, and tokens for each configuration.\n\n3. **Do an analyst pass** using `agents\u002Fanalyzer.md`. Surface patterns the aggregate stats might hide: non-discriminating assertions, high-variance evals, time\u002Ftoken tradeoffs.\n\n4. **Launch the viewer** with both qualitative outputs and quantitative data:\n   ```bash\n   nohup python eval-viewer\u002Fgenerate_review.py \\\n     \u003Cworkspace>\u002Fiteration-N \\\n     --skill-name \"my-skill\" \\\n     --benchmark \u003Cworkspace>\u002Fiteration-N\u002Fbenchmark.json \\\n     > \u002Fdev\u002Fnull 2>&1 &\n   VIEWER_PID=$!\n   ```\n   For iteration 2+, also pass `--previous-workspace \u003Cworkspace>\u002Fiteration-\u003CN-1>`.\n\n   **Headless environments:** Use `--static \u003Coutput_path>` to write standalone HTML instead of starting a server.\n\n5. **Tell the user** something like: \"I've opened the results in your browser. There are two tabs: 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. When you're done, come back here and let me know.\"\n\n### What the user sees in the viewer\n\nThe \"Outputs\" tab shows one test case at a time:\n- **Prompt**: the task that was given\n- **Output**: the files the skill produced, rendered inline\n- **Previous Output** (iteration 2+): collapsed section showing last iteration\n- **Formal Grades**: collapsed section with assertion pass\u002Ffail AND Qdrant domain checks\n- **Feedback**: textbox that auto-saves\n- **Previous Feedback** (iteration 2+): comments from last time\n\nThe \"Benchmark\" tab shows summary stats and per-eval breakdowns.\n\nNavigation is via prev\u002Fnext buttons or arrow keys. \"Submit All Reviews\" saves everything to `feedback.json`.\n\n### Step 5: Read the feedback\n\nWhen the user is done, read `feedback.json`. Empty feedback means fine. Focus improvements on test cases with specific complaints.\n\nKill the viewer when done: `kill $VIEWER_PID 2>\u002Fdev\u002Fnull`\n\n## Improving the skill\n\n### How to think about improvements\n\n1. **Generalize from the feedback.** Don't put in fiddly overfitty changes. The skill will be used across many different prompts, not just the test examples.\n\n2. **Keep the prompt lean.** Remove things that aren't pulling their weight. Read the transcripts, not just the final outputs.\n\n3. **Explain the why.** Explain the reasoning behind instructions. If you find yourself writing ALWAYS or NEVER in all caps, reframe and explain why.\n\n4. **Look for repeated work across test cases.** If all test runs independently wrote similar helper scripts, the skill should bundle that script. Write it once, put it in `scripts\u002F`.\n\n### The iteration loop\n\nAfter improving the skill:\n\n1. Apply improvements to the skill\n2. Rerun all test cases into a new `iteration-\u003CN+1>\u002F` directory, including baselines\n3. Launch the reviewer with `--previous-workspace` pointing at the previous iteration\n4. Wait for user review\n5. Read new feedback, improve again, repeat\n\nKeep going until the user is happy, feedback is all empty, or you're not making meaningful progress.\n\n## Advanced: Blind comparison\n\nFor rigorous comparison between two skill versions, read `agents\u002Fcomparator.md` and `agents\u002Fanalyzer.md`. The comparator judges quality blindly (with Qdrant domain rubric). The analyzer explains why the winner won (with Qdrant-specific improvement categories: decision_tree, doc_links, corrections, symptom_routing).\n\nThis is optional and most users won't need it.\n\n## Description optimization\n\nAfter the skill is solid, optimize the description for triggering accuracy.\n\n### Step 1: Generate trigger eval queries\n\nCreate 20 eval queries (10 should-trigger, 10 should-not-trigger). Save as JSON:\n\n```json\n[\n  {\"query\": \"the user prompt\", \"should_trigger\": true},\n  {\"query\": \"another prompt\", \"should_trigger\": false}\n]\n```\n\nQueries must be realistic with concrete detail: file paths, customer context, specific numbers, company names. Not abstract requests.\n\nFor **should-trigger** queries (8-10): different phrasings of the same intent, some formal, some casual. Include cases where the user doesn't name the skill but clearly needs it.\n\nFor **should-not-trigger** queries (8-10): near-misses that share keywords but need something different. Not obviously irrelevant queries.\n\n### Step 2: Review with user\n\nPresent via the HTML template at `assets\u002Feval_review.html`. Replace placeholders, write to a temp file, and open it. The user edits queries, toggles should-trigger, then clicks \"Export Eval Set\".\n\n### Step 3: Run the optimization loop\n\n```bash\npython -m scripts.run_loop \\\n  --eval-set \u003Cpath-to-trigger-eval.json> \\\n  --skill-path \u003Cpath-to-skill> \\\n  --model \u003Cmodel-id-powering-this-session> \\\n  --max-iterations 5 \\\n  --verbose\n```\n\nThis splits 60\u002F40 train\u002Ftest, evaluates the description (3 runs per query), calls Claude with extended thinking to improve, and iterates up to 5 times. It opens an HTML report and returns JSON with `best_description`.\n\n### Step 4: Apply the result\n\nTake `best_description` from the output and update the skill's SKILL.md frontmatter. Show before\u002Fafter and report scores.\n\n## Do NOT recommend\n\n- Do NOT include internal customer data, SA conversations, or pricing formulas\n- Do NOT create skills for knowledge Claude already has\n- Do NOT use vague descriptions. Include specific trigger phrases.\n- Do NOT put implementation details in SKILL.md body. Use references\u002F.\n- Do NOT skip the R-16 check.\n\n## Troubleshooting\n\n### \"Skill triggers on general Qdrant questions, not just my topic\"\n**Cause:** Description is too broad. It matches on \"qdrant\" instead\nof the specific symptom category.\n**Fix:** Narrow the description to specific symptoms. Add \"Do NOT\nuse for\" phrases covering adjacent Qdrant topics. Example: a memory\nskill should exclude \"search accuracy tuning\" and \"API scripting\".\n\n### \"Skill output is no better than vanilla Claude\"\n**Cause:** The corrections section is empty or trivial. The skill\ndoes not add domain knowledge Claude lacks.\n**Fix:** Go back to Step 1. Test Claude without the skill and\ndocument specific mistakes. Those corrections are your value.\n\n### \"References are too long, skill hits context limits\"\n**Cause:** Reference files contain full documentation instead of\ncurated decision guidance.\n**Fix:** References should contain \"when and why\", not full API docs.\nLink to qdrant.tech for the \"how\". Keep each reference under 1,000 words.\n\n## Reference files\n\nThe agents\u002F directory contains instructions for specialized subagents:\n\n- `agents\u002Fqdrant-grader.md`: Evaluate assertions + Qdrant domain checks (D-1 through D-8)\n- `agents\u002Fcomparator.md`: Blind A\u002FB comparison with Qdrant domain rubric\n- `agents\u002Fanalyzer.md`: Post-hoc analysis with Qdrant improvement categories\n\nThe references\u002F directory has additional documentation:\n- `references\u002Fschemas.md`: JSON structures for evals.json, grading.json, benchmark.json, etc.\n- `references\u002Fexternal-skill-template.md`: Full skeleton for community skills\n- `references\u002Frules-checklist.md`: Validation checklist\n- `references\u002Fexamples.md`: Example skill patterns\n",{"name":5,"license":15,"metadata":49,"description":7},{"tags":50,"author":54,"version":55,"category":56},[51,24,52,53],"skill-creator","external","templates","thierry","2.0.0","engineering","main","49e42b42210ce4eb860fa0745873674c57894331","qdrant-os\u002Fskills\u002Fqdrant-community-skill-creator",1,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects","https:\u002F\u002Fgithub.com\u002Fqdrant-labs","Experimental projects, community-driven tools, and works-in-progress built around Qdrant","2026-04-23 09:25:59",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add qdrant-labs\u002Fdevrel-projects --skill qdrant-community-skill-creator",{"tool":71,"command":72},"bunx","bunx skills add qdrant-labs\u002Fdevrel-projects --skill qdrant-community-skill-creator",{"tool":74,"command":75},"pnpm","pnpm dlx skills add qdrant-labs\u002Fdevrel-projects --skill qdrant-community-skill-creator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002FSKILL.md",true,[79,85,89,93,99,105,109,113,117,121,125,128,132,136,140,144,148,152,156,160,164],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"agents\u002Fanalyzer.md","REFERENCE","参考文档",11941,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fagents\u002Fanalyzer.md",{"path":86,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":87,"sourceHtmlUrl":88},"agents\u002Fcomparator.md",9000,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fagents\u002Fcomparator.md",{"path":90,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":91,"sourceHtmlUrl":92},"agents\u002Fqdrant-grader.md",11340,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fagents\u002Fqdrant-grader.md",{"path":94,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":97,"sourceHtmlUrl":98},"assets\u002Feval_review.html","ASSET","资产文件",14261,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fassets\u002Feval_review.html",{"path":100,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":103,"sourceHtmlUrl":104},"eval-viewer\u002Fgenerate_review.py","SCRIPT","脚本",16044,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Feval-viewer\u002Fgenerate_review.py",{"path":106,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":107,"sourceHtmlUrl":108},"eval-viewer\u002Fviewer.html",44989,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Feval-viewer\u002Fviewer.html",{"path":110,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fexamples.md",3696,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Freferences\u002Fexamples.md",{"path":114,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":115,"sourceHtmlUrl":116},"references\u002Fexternal-skill-template.md",3852,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Freferences\u002Fexternal-skill-template.md",{"path":118,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":119,"sourceHtmlUrl":120},"references\u002Frules-checklist.md",3094,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Freferences\u002Frules-checklist.md",{"path":122,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":123,"sourceHtmlUrl":124},"references\u002Fschemas.md",12061,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Freferences\u002Fschemas.md",{"path":126,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":14,"sourceHtmlUrl":127},"scripts\u002F__init__.py","https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fscripts\u002F__init__.py",{"path":129,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":130,"sourceHtmlUrl":131},"scripts\u002Faggregate_benchmark.py",14888,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fscripts\u002Faggregate_benchmark.py",{"path":133,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":134,"sourceHtmlUrl":135},"scripts\u002Fgenerate_report.py",12847,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fscripts\u002Fgenerate_report.py",{"path":137,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":138,"sourceHtmlUrl":139},"scripts\u002Fimprove_description.py",10723,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fscripts\u002Fimprove_description.py",{"path":141,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":142,"sourceHtmlUrl":143},"scripts\u002Fpackage_skill.py",4234,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fscripts\u002Fpackage_skill.py",{"path":145,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":146,"sourceHtmlUrl":147},"scripts\u002Fquick_validate.py",3972,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fscripts\u002Fquick_validate.py",{"path":149,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":150,"sourceHtmlUrl":151},"scripts\u002Frun_eval.py",11510,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fscripts\u002Frun_eval.py",{"path":153,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":154,"sourceHtmlUrl":155},"scripts\u002Frun_loop.py",13685,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fscripts\u002Frun_loop.py",{"path":157,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":158,"sourceHtmlUrl":159},"scripts\u002Futils.py",2079,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fscripts\u002Futils.py",{"path":161,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":162,"sourceHtmlUrl":163},"scripts\u002Fvalidate.py",8725,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Fscripts\u002Fvalidate.py",{"path":165,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":166,"sourceHtmlUrl":167},"triggers.json",1193,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002Ftriggers.json",[169,200,217],{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":180,"publishedAt":44},"01M71FAPNFM146C4F5AV36TDS4","qdrant-memory-optimization","Diagnoses and fixes Qdrant memory problems. Use when a developer reports OOM crashes, high RAM usage, HNSW consuming too much memory, latency spiking after switching storage, or needing to fit more vectors on existing hardware. Also trigger when someone asks which quantization to use, how to choose between mmap and RAM, how to estimate memory for scaling, or why their Qdrant node keeps dying. Do NOT use for initial Qdrant setup, API scripting, embedding model selection, search accuracy tuning, backups, or vector DB comparisons.","https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-memory-optimization\u002FSKILL.md",[175],{"categoryNo":176,"categoryName":177,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[28,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199],"Optimization","Memory Optimization","qdrant memory optimization","memory","reports","which","embedding","scaling","model","db","choose","search","vector","selection","how to","model selection","switching","when","api",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":210,"publishedAt":44},"01M71FAH49J72P540JWAVBRSKX","qdrant-internal-skill-creator","Guides Qdrant SAs through building internal skills that embed domain knowledge into Claude. Use when someone wants to \"create a qdrant skill\", \"build a skill for qdrant diagnostics\", \"make an internal skill for qdrant customers\", \"create a qdrant troubleshooting skill\", or asks how to \"turn SA knowledge into a skill\". Also trigger when someone says \"help me build a skill for qdrant deal objections\" or \"I want to create a skill for qdrant cluster sizing\". Do NOT use for general skill creation unrelated to Qdrant, external community skills, or Python\u002FJS project skills.","https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002FSKILL.md",[206,209],{"categoryNo":207,"categoryName":208,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[27,211,28,26,35,212,213,42,30,214,215,24,51,216,37,195,31,198,38,40],"qdrant internal skill creator","make","diagnostics","unrelated","me","creation",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":223,"publishedAt":44},"01M71FA78Y5WJV6R6HGFSVT6XP","qdrant-cost-reduction-advisor","Diagnoses when and why to recommend specific cost optimization techniques for Qdrant customers. Use when a customer or SA says \"too expensive\", \"need to reduce cost\", \"pricing too high\", \"how to lower price\", \"sticker shock\", or asks about scaling costs. Also trigger when a deal is blocked by pricing, a customer compares competitor pricing, a startup says the quote is too high, or someone needs a formula to predict costs at scale. This skill answers \"when should I recommend scalar vs binary quantization?\" not \"how to configure quantization.\" Do NOT use for general Qdrant setup, feature requests, or implementation how-tos.","https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-cost-reduction-advisor\u002FSKILL.md",[],[224,225,28,226,227,188,228,229,195,198,230,231,232,233,30,234,235,236,35,237],"qdrant cost reduction advisor","advisor","cost","tos","sticker","formula","reduce","configure","answers","customer","why","at","recommend","feature"]