[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FAH49J72P540JWAVBRSKX":3,"skill-same:01M71FAH49J72P540JWAVBRSKX":171},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":63,"repositoryHtmlUrl":64,"repositoryHomepageUrl":6,"ownerHtmlUrl":65,"ownerBlogUrl":6,"ownerDescription":66,"updatedAt":67,"install":68,"resources":81},"01M71FAH49J72P540JWAVBRSKX","qdrant-internal-skill-creator",null,"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.","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-internal-skill-creator\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"qdrant internal skill creator","Qdrant","creator","skill creator","do","make","diagnostics","a skill","how","unrelated","me","create","guides","when","knowledge","how to","project","creation","skill-creator","community","2026-11-10 10:12:30",false,"---\nname: qdrant-internal-skill-creator\ndescription: Guides Qdrant SAs through building internal skills that embed\n  domain knowledge into Claude. Use when someone wants to \"create a qdrant\n  skill\", \"build a skill for qdrant diagnostics\", \"make an internal skill\n  for qdrant customers\", \"create a qdrant troubleshooting skill\", or asks\n  how to \"turn SA knowledge into a skill\". Also trigger when someone says\n  \"help me build a skill for qdrant deal objections\" or \"I want to create\n  a skill for qdrant cluster sizing\". Do NOT use for general skill creation\n  unrelated to Qdrant, external community skills, or Python\u002FJS project skills.\nlicense: Apache-2.0\nmetadata:\n  author: thierry\n  version: 2.0.0\n  category: engineering\n  tags: [skill-creator, internal, sa-knowledge, templates]\n---\n\n# Internal Qdrant Skill Creator\n\nA skill for creating internal 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- Pick a symptom category and write a draft using the internal 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 domain knowledge does this embed that Claude does not already know?\"**\n\nIf the answer is \"nothing\", you do not need a skill. You need a prompt.\n\nGood answers:\n- \"SA pricing conversations and objection-handling frameworks\"\n- \"Qdrant quantization thresholds that are not in the public docs\"\n- \"Real customer deployment patterns and failure modes\"\n- \"Internal competitive intelligence and response playbooks\"\n\nBad answers:\n- \"How to use the Qdrant Python client\" (Claude already knows this)\n- \"What is vector search\" (general knowledge)\n- \"Qdrant API reference\" (public docs, use MCP instead)\n\n## Creating a Qdrant skill\n\n### Step 1: Pick the symptom category\n\nEvery internal skill starts with a customer symptom, not a product feature.\n\n| Category | Example symptoms | Example skill |\n|----------|-----------------|---------------|\n| Cost | \"Too expensive\", \"budget won't approve\" | qdrant-cost-reduction-advisor |\n| Performance | \"OOM crashes\", \"latency too high\" | qdrant-memory-optimization |\n| Sales | \"Deal blocked\", \"competitor is cheaper\" | qdrant-deal-unblocker |\n| Operations | \"Cluster sizing\", \"migration planning\" | qdrant-cluster-advisor |\n| Adoption | \"POC failed\", \"team prefers competitor\" | qdrant-adoption-playbook |\n\n### Step 2: Use the internal skill template\n\nLoad `references\u002Finternal-skill-template.md` for the full skeleton.\n\nKey sections every internal skill must have:\n\n1. **Things Claude gets wrong about Qdrant** (corrections section)\n2. **Symptom routing table** (symptom -> reference file mapping)\n3. **Decision tree** with concrete thresholds (not vague guidance)\n4. **Do NOT recommend** (anti-patterns from real SA experience)\n5. **Troubleshooting** (minimum 2 error cases with cause and fix)\n\n### Step 3: Fill in SA knowledge\n\nFor each symptom in your routing table:\n\n1. Write the **diagnosis** (what is actually causing this?)\n2. Write the **solution** with SA quotes from real conversations\n3. Add a **real example** with specific numbers\n4. Link to the **Qdrant doc page** for implementation details\n\nUse this pattern for SA quotes:\n```\n- \"We recommend our customers to use scalar if they want to try\n  that first just to see what the improvement is going to be.\"\n```\n\n### Step 4: Write the SKILL.md\n\nBased on the template and SA knowledge, fill in these components:\n\n- **name**: Skill identifier (kebab-case, matches folder name)\n- **description**: When to trigger, what it does. Include both what the skill does AND specific contexts for when to use it. 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 their Qdrant cluster 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 (real customer language)\n5. Add 4+ negative trigger queries (adjacent topics that should NOT trigger)\n6. Export the JSON and save as `triggers.json`\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 (including the `assertions` field).\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, SA quotes, real customer data). 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 create skills for knowledge Claude already has (API docs, general concepts)\n- Do NOT skip the R-16 check. Skills without unique domain knowledge waste context.\n- Do NOT use generic descriptions. Include exact trigger phrases in quotes.\n- Do NOT put implementation details in SKILL.md body. That goes in references\u002F.\n- Do NOT bundle multiple unrelated symptom categories into one skill.\n\n## Internal metadata conventions\n\nInternal skills should include these metadata fields:\n```yaml\nmetadata:\n  author: firstname       # The SA or engineer who wrote it\n  version: 1.0.0          # Semver (minor for description changes)\n  category: sales         # sales, engineering, support, or operations\n  tags: [keyword1, keyword2]\n```\n\n## Troubleshooting\n\n### \"Skill triggers on everything related to Qdrant\"\n**Cause:** Description is too broad. Missing negative trigger phrases.\n**Fix:** Add \"Do NOT use for\" section listing adjacent topics. Include\n4+ negative cases in triggers.json that cover adjacent territory.\n\n### \"Skill output looks the same as without the skill\"\n**Cause:** The skill does not embed unique domain knowledge. It\nrestates what Claude already knows.\n**Fix:** Apply the R-16 check. Add SA quotes, real customer data,\ninternal pricing formulas, or competitive intelligence that Claude\ncannot access from public sources.\n\n### \"Skill is too long, hitting context limits\"\n**Cause:** Implementation details are in the SKILL.md body instead\nof in references\u002F files.\n**Fix:** Move \"how\" content to references\u002F. Keep SKILL.md under\n5,000 words. Use progressive disclosure: frontmatter (when),\nbody (why), references (how).\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\u002Finternal-skill-template.md`: Full skeleton for internal skills\n- `references\u002Frules-checklist.md`: Validation checklist\n- `references\u002Fexamples.md`: Example skill patterns\n","# Internal Qdrant Skill Creator\n\nA skill for creating internal 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- Pick a symptom category and write a draft using the internal 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 domain knowledge does this embed that Claude does not already know?\"**\n\nIf the answer is \"nothing\", you do not need a skill. You need a prompt.\n\nGood answers:\n- \"SA pricing conversations and objection-handling frameworks\"\n- \"Qdrant quantization thresholds that are not in the public docs\"\n- \"Real customer deployment patterns and failure modes\"\n- \"Internal competitive intelligence and response playbooks\"\n\nBad answers:\n- \"How to use the Qdrant Python client\" (Claude already knows this)\n- \"What is vector search\" (general knowledge)\n- \"Qdrant API reference\" (public docs, use MCP instead)\n\n## Creating a Qdrant skill\n\n### Step 1: Pick the symptom category\n\nEvery internal skill starts with a customer symptom, not a product feature.\n\n| Category | Example symptoms | Example skill |\n|----------|-----------------|---------------|\n| Cost | \"Too expensive\", \"budget won't approve\" | qdrant-cost-reduction-advisor |\n| Performance | \"OOM crashes\", \"latency too high\" | qdrant-memory-optimization |\n| Sales | \"Deal blocked\", \"competitor is cheaper\" | qdrant-deal-unblocker |\n| Operations | \"Cluster sizing\", \"migration planning\" | qdrant-cluster-advisor |\n| Adoption | \"POC failed\", \"team prefers competitor\" | qdrant-adoption-playbook |\n\n### Step 2: Use the internal skill template\n\nLoad `references\u002Finternal-skill-template.md` for the full skeleton.\n\nKey sections every internal skill must have:\n\n1. **Things Claude gets wrong about Qdrant** (corrections section)\n2. **Symptom routing table** (symptom -> reference file mapping)\n3. **Decision tree** with concrete thresholds (not vague guidance)\n4. **Do NOT recommend** (anti-patterns from real SA experience)\n5. **Troubleshooting** (minimum 2 error cases with cause and fix)\n\n### Step 3: Fill in SA knowledge\n\nFor each symptom in your routing table:\n\n1. Write the **diagnosis** (what is actually causing this?)\n2. Write the **solution** with SA quotes from real conversations\n3. Add a **real example** with specific numbers\n4. Link to the **Qdrant doc page** for implementation details\n\nUse this pattern for SA quotes:\n```\n- \"We recommend our customers to use scalar if they want to try\n  that first just to see what the improvement is going to be.\"\n```\n\n### Step 4: Write the SKILL.md\n\nBased on the template and SA knowledge, fill in these components:\n\n- **name**: Skill identifier (kebab-case, matches folder name)\n- **description**: When to trigger, what it does. Include both what the skill does AND specific contexts for when to use it. 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 their Qdrant cluster 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 (real customer language)\n5. Add 4+ negative trigger queries (adjacent topics that should NOT trigger)\n6. Export the JSON and save as `triggers.json`\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 (including the `assertions` field).\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, SA quotes, real customer data). 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 create skills for knowledge Claude already has (API docs, general concepts)\n- Do NOT skip the R-16 check. Skills without unique domain knowledge waste context.\n- Do NOT use generic descriptions. Include exact trigger phrases in quotes.\n- Do NOT put implementation details in SKILL.md body. That goes in references\u002F.\n- Do NOT bundle multiple unrelated symptom categories into one skill.\n\n## Internal metadata conventions\n\nInternal skills should include these metadata fields:\n```yaml\nmetadata:\n  author: firstname       # The SA or engineer who wrote it\n  version: 1.0.0          # Semver (minor for description changes)\n  category: sales         # sales, engineering, support, or operations\n  tags: [keyword1, keyword2]\n```\n\n## Troubleshooting\n\n### \"Skill triggers on everything related to Qdrant\"\n**Cause:** Description is too broad. Missing negative trigger phrases.\n**Fix:** Add \"Do NOT use for\" section listing adjacent topics. Include\n4+ negative cases in triggers.json that cover adjacent territory.\n\n### \"Skill output looks the same as without the skill\"\n**Cause:** The skill does not embed unique domain knowledge. It\nrestates what Claude already knows.\n**Fix:** Apply the R-16 check. Add SA quotes, real customer data,\ninternal pricing formulas, or competitive intelligence that Claude\ncannot access from public sources.\n\n### \"Skill is too long, hitting context limits\"\n**Cause:** Implementation details are in the SKILL.md body instead\nof in references\u002F files.\n**Fix:** Move \"how\" content to references\u002F. Keep SKILL.md under\n5,000 words. Use progressive disclosure: frontmatter (when),\nbody (why), references (how).\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\u002Finternal-skill-template.md`: Full skeleton for internal skills\n- `references\u002Frules-checklist.md`: Validation checklist\n- `references\u002Fexamples.md`: Example skill patterns\n",{"name":5,"license":15,"metadata":52,"description":7},{"tags":53,"author":57,"version":58,"category":59},[45,54,55,56],"internal","sa-knowledge","templates","thierry","2.0.0","engineering","main","49e42b42210ce4eb860fa0745873674c57894331","qdrant-os\u002Fskills\u002Fqdrant-internal-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":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add qdrant-labs\u002Fdevrel-projects --skill qdrant-internal-skill-creator",{"tool":74,"command":75},"bunx","bunx skills add qdrant-labs\u002Fdevrel-projects --skill qdrant-internal-skill-creator",{"tool":77,"command":78},"pnpm","pnpm dlx skills add qdrant-labs\u002Fdevrel-projects --skill qdrant-internal-skill-creator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002FSKILL.md",true,[82,88,92,96,102,108,112,116,120,124,128,131,135,139,143,147,151,155,159,163,167],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"agents\u002Fanalyzer.md","REFERENCE","参考文档",11941,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fagents\u002Fanalyzer.md",{"path":89,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":90,"sourceHtmlUrl":91},"agents\u002Fcomparator.md",9000,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fagents\u002Fcomparator.md",{"path":93,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":94,"sourceHtmlUrl":95},"agents\u002Fqdrant-grader.md",11194,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fagents\u002Fqdrant-grader.md",{"path":97,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"assets\u002Feval_review.html","ASSET","资产文件",14260,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fassets\u002Feval_review.html",{"path":103,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":106,"sourceHtmlUrl":107},"eval-viewer\u002Fgenerate_review.py","SCRIPT","脚本",16044,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Feval-viewer\u002Fgenerate_review.py",{"path":109,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":110,"sourceHtmlUrl":111},"eval-viewer\u002Fviewer.html",44989,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Feval-viewer\u002Fviewer.html",{"path":113,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":114,"sourceHtmlUrl":115},"references\u002Fexamples.md",4425,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Freferences\u002Fexamples.md",{"path":117,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":118,"sourceHtmlUrl":119},"references\u002Finternal-skill-template.md",3123,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Freferences\u002Finternal-skill-template.md",{"path":121,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":122,"sourceHtmlUrl":123},"references\u002Frules-checklist.md",3132,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Freferences\u002Frules-checklist.md",{"path":125,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":126,"sourceHtmlUrl":127},"references\u002Fschemas.md",12061,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Freferences\u002Fschemas.md",{"path":129,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":14,"sourceHtmlUrl":130},"scripts\u002F__init__.py","https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fscripts\u002F__init__.py",{"path":132,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":133,"sourceHtmlUrl":134},"scripts\u002Faggregate_benchmark.py",14888,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fscripts\u002Faggregate_benchmark.py",{"path":136,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":137,"sourceHtmlUrl":138},"scripts\u002Fgenerate_report.py",12847,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fscripts\u002Fgenerate_report.py",{"path":140,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":141,"sourceHtmlUrl":142},"scripts\u002Fimprove_description.py",10723,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fscripts\u002Fimprove_description.py",{"path":144,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":145,"sourceHtmlUrl":146},"scripts\u002Fpackage_skill.py",4234,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fscripts\u002Fpackage_skill.py",{"path":148,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":149,"sourceHtmlUrl":150},"scripts\u002Fquick_validate.py",3972,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fscripts\u002Fquick_validate.py",{"path":152,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":153,"sourceHtmlUrl":154},"scripts\u002Frun_eval.py",11510,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fscripts\u002Frun_eval.py",{"path":156,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":157,"sourceHtmlUrl":158},"scripts\u002Frun_loop.py",13685,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fscripts\u002Frun_loop.py",{"path":160,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":161,"sourceHtmlUrl":162},"scripts\u002Futils.py",2079,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fscripts\u002Futils.py",{"path":164,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":165,"sourceHtmlUrl":166},"scripts\u002Fvalidate.py",8725,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Fscripts\u002Fvalidate.py",{"path":168,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":169,"sourceHtmlUrl":170},"triggers.json",1155,"https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-internal-skill-creator\u002Ftriggers.json",[172,201,222],{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":183,"publishedAt":47},"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",[178],{"categoryNo":179,"categoryName":180,"taxonomyType":181,"taxonomyTypeDesc":182},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[28,184,185,186,187,188,189,190,191,192,193,194,195,196,197,42,198,199,40,200],"Optimization","Memory Optimization","qdrant memory optimization","memory","reports","which","embedding","scaling","model","db","choose","search","vector","selection","model selection","switching","api",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":207,"publishedAt":47},"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",[],[208,209,210,28,211,31,212,213,214,215,191,216,217,42,40,218,219,220,221,35],"advisor","qdrant cost reduction advisor","cost","feature","recommend","tos","at","why","sticker","formula","reduce","configure","answers","customer",{"skillNo":223,"name":224,"nameZh":6,"description":225,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":226,"categories":227,"keywords":229,"publishedAt":47},"01M71FA1G7KS1VX5SCBSJZXBA7","qdrant-community-skill-creator","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.","https:\u002F\u002Fgithub.com\u002Fqdrant-labs\u002Fdevrel-projects\u002Fblob\u002Fmain\u002Fqdrant-os\u002Fskills\u002Fqdrant-community-skill-creator\u002FSKILL.md",[228],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[230,30,29,28,46,231,232,43,233,234,41,39,38,35,34,31,235,236,237,238],"qdrant community skill creator","python","python project","open","open source","domain","for","general","use"]