[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WZWXG27Q4G48SVPEJ6FSF2":3,"skill-same:01M6WZWXG27Q4G48SVPEJ6FSF2":77},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":14,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6WZWXG27Q4G48SVPEJ6FSF2","llm-evaluation",null,"LLM output evaluation — automated metrics, LLM-as-judge, A\u002FB testing, regression testing. Use when measuring LLM output quality, comparing prompt or model versions, building an automated eval pipeline, setting up regression tests for prompt changes, or evaluating RAG systems and bias\u002Fsafety.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fdata-ai\u002Fllm-evaluation\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,5,32,33,34,35,36,37,38,39,40,41,42],"Evaluation","llm evaluation","when","testing","changes","for","v1","output","as","tests","bias","up","use","prompt","eval","work","regression","model","pipeline","2026-11-10 10:12:30",false,"---\nname: llm-evaluation\ndescription: |\n  LLM output evaluation — automated metrics, LLM-as-judge, A\u002FB testing, regression testing. Use when measuring LLM output quality, comparing prompt or model versions, building an automated eval pipeline, setting up regression tests for prompt changes, or evaluating RAG systems and bias\u002Fsafety.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-llm-evaluation\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: data-ai\n---\n\n# LLM Evaluation\n\n## Intro\n\nYou can't improve what you don't measure. LLM evaluation combines a\nsmall high-quality eval dataset, automated metrics where reference\nanswers exist, LLM-as-judge for subjective quality, and regression\ntests in CI. Build the eval set first; everything else depends on it.\n\n## Overview\n\n### Build an evaluation dataset\n\nWithout an eval set, you're guessing. Aim for 50–100 representative\ninput\u002Fexpected-output pairs from real usage, with 10–20% adversarial\nor edge-case examples. Label each row with metadata (difficulty,\ncategory, expected behavior) and split into a dev set (for\niteration) and a held-out test set (for final measurement).\n\nStore as JSONL or CSV:\n\n```jsonl\n{\"input\": \"...\", \"expected\": \"...\", \"category\": \"billing\"}\n```\n\nSources: production logs, user feedback, manually curated examples,\nsynthetic generation followed by human review.\n\n### Automated metrics\n\nUse when output has a clear reference answer. Cheap and fast, but\nmiss nuance — always combine with human or LLM-as-judge.\n\n- **BLEU** — n-gram precision; good for translation, poor for\n  open-ended generation.\n- **ROUGE** (especially ROUGE-L) — recall-oriented; good for\n  summarization.\n- **Exact match** — binary pass\u002Ffail; factual extraction,\n  classification.\n- **BERTScore** — cosine similarity of contextual embeddings;\n  better than BLEU\u002FROUGE for paraphrased correct answers.\n- **Embedding similarity** — quick semantic similarity to a\n  reference.\n- **Code:** Pass@k (does generated code pass test cases?), syntax\n  validity.\n- **Classification:** precision\u002Frecall\u002FF1 per class.\n- **Structured output:** schema compliance rate, field accuracy.\n\n### LLM-as-judge\n\nUse a strong LLM to score outputs from a weaker LLM or competing\nprompt versions.\n\nSetup: define a rubric with 3–5 criteria (accuracy, helpfulness,\nsafety, format compliance), score each on a 1–5 scale with explicit\nlevel definitions, run at temperature 0 for reproducibility, and\ninclude the rubric, input, and output in the judge prompt.\n\n```\nYou are evaluating the quality of an AI response.\n\nCriteria:\n- Accuracy (1-5): Is the information factually correct?\n- Completeness (1-5): Does it address all parts of the question?\n- Clarity (1-5): Is the response well-organized and easy to read?\n\nInput: {input}\nResponse: {response}\n\nScore each criterion and provide a brief justification.\nReturn as JSON:\n{\"accuracy\": N, \"completeness\": N, \"clarity\": N, \"justification\": \"...\"}\n```\n\nMitigate judge bias: swap order in pairwise comparisons (position\nbias), run each evaluation twice for consistency, average across\nmultiple judge models, and calibrate against human ratings on a\nsmall set.\n\n### A\u002FB testing prompts\n\nCompare prompt versions on the same eval set. Run both, score with\nautomated metrics + LLM-as-judge, compare distributions (mean,\nmedian, p25, p75), then run a paired significance test (paired\nt-test or Wilcoxon signed-rank). Critically: even if version B wins\noverall, check whether it regressed on cases version A handled. A\nprompt leaderboard tracking versions over time pays off quickly.\n\n### Regression testing in CI\n\nMaintain a golden suite of critical test cases with expected\noutputs. Run on every prompt or model change. Set thresholds\n(\"accuracy >95%, format compliance 100%\") and fail the build when\nbreached. Alert on degradation trends even within thresholds.\n\n### RAG-specific (RAGAS)\n\nFor RAG pipelines, the four metrics are:\n\n- **Context precision** — fraction of retrieved chunks that are\n  relevant.\n- **Context recall** — fraction of needed information that was\n  retrieved.\n- **Faithfulness** — is the answer grounded in the retrieved\n  context, or hallucinated?\n- **Answer relevance** — does the answer actually address the\n  question?\n\nBuild a golden dataset of 50+ question\u002Fideal-context\u002Freference\ntriples and score with RAGAS to localize the failing stage\n(retrieval vs. generation).\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Eval set built entirely from synthetic data.** Synthetic data captures what you think can go wrong, not what actually goes wrong in production. A chatbot eval set built from GPT-generated questions will miss the real distribution of user queries. Mix production examples into the eval set before using it to make decisions.\n- **Tuning prompts against the test set.** Choosing prompts based on test-set performance makes the test set part of the development loop — it no longer measures generalization. Keep a true held-out test set; iterate on a separate dev set.\n- **Single-number metric hiding subgroup regressions.** A new prompt version with an overall accuracy of 92% may be 80% on billing questions even though it is 99% on FAQ questions. Always slice metrics by category, difficulty, and edge-case subsets before declaring a winner.\n- **LLM-as-judge without calibration.** Judge models have biases: position bias (preferring the first option), verbosity bias (preferring longer answers), and self-preference (preferring their own outputs). Use swap-order evaluation and calibrate the judge on a small set of human-labeled examples before trusting its scores.\n- **No reproducibility on eval runs.** LLM evaluation at temperature > 0 produces different results on every run. Set temperature = 0 for evaluation and pin all model versions and prompt hashes. Without this, you can't tell whether a score change is a real improvement or noise.\n- **Treating automated metrics as ground truth for open-ended tasks.** BLEU and ROUGE measure n-gram overlap, not quality. A correct answer phrased differently from the reference scores poorly; a fluent but wrong answer may score well. Use automated metrics only where reference answers exist; use LLM-as-judge for open-ended tasks.\n- **Reporting only means without distributions.** A mean faithfulness score of 0.85 is compatible with half the responses being hallucinated (0.7) and half being perfect (1.0). Always report p50, p90, p99 and the fraction of responses below a minimum acceptable threshold.\n\n## Full reference\n\n### Human evaluation\n\nThe gold standard, but expensive — reserve for high-stakes\ndecisions. Use 3+ raters per example to measure inter-rater\nagreement (Cohen's kappa). Provide clear rubrics; vague instructions\nproduce noisy ratings. Blind raters to which version they're\nevaluating. 50–100 examples is usually enough for directional\ncalls.\n\n### Bias and safety\n\n- Test with demographically diverse inputs (names, locations,\n  contexts).\n- Probe for stereotyping, toxicity, and refusal of valid requests.\n- Run red-team prompts to provoke harmful outputs.\n- Track refusal rate — too high means the model is over-cautious.\n- Tools: Perspective API for toxicity, custom classifiers for\n  domain-specific harms.\n\n### Choosing metrics by task\n\n| Task | Metrics |\n|---|---|\n| Translation | BLEU, chrF, COMET, human eval |\n| Summarization | ROUGE-L, BERTScore, faithfulness, human eval |\n| Open-ended generation | LLM-as-judge, human eval |\n| Classification | Precision, recall, F1, confusion matrix |\n| Structured extraction | Schema compliance, field accuracy, exact match |\n| Code | Pass@k, syntax validity, lint |\n| RAG | Context precision\u002Frecall, faithfulness, answer relevance |\n| Agents \u002F multi-step | Task success rate, step efficiency, tool-call accuracy |\n\n### Statistical rigor\n\nAlways report variance, not point estimates. For paired comparisons\n(same eval set, two systems) use the paired t-test or Wilcoxon\nsigned-rank. Bootstrap confidence intervals when distributions are\nskewed. Beware multiple-comparison inflation when testing many\nprompt variants — apply Bonferroni or Holm-Bonferroni correction.\n\n### Common eval anti-patterns\n\n- **Eval set built from synthetic data only** — never reflects\n  real failure modes. Mix in real production examples.\n- **Single-number metric** — hides regressions on subgroups. Always\n  slice.\n- **Tuning prompt against the test set** — same data leakage problem\n  as in classical ML. Keep a true held-out test set.\n- **Trusting LLM-as-judge without calibration** — judges have\n  biases. Calibrate against human ratings on a small set.\n- **Reporting averages without distributions** — mean hides tails;\n  always show p50, p90, p99.\n- **No reproducibility** — use temperature 0 for evaluation runs and\n  pin all model and prompt versions.\n\n### Worked scenarios\n\n**Eval pipeline for a support chatbot.** Build a JSONL eval set\nfrom production conversation logs. Define a rubric (accuracy,\nhelpfulness, tone, escalation appropriateness). Implement\nLLM-as-judge with a strong model. Set up CI to run evals on every\nprompt change and report a scorecard. Flag regressions beyond 5% on\nany metric.\n\n**Comparing two summarization prompts.** Run both on 50 diverse\ndocuments. Score with ROUGE-L (automated) and LLM-as-judge\n(quality rubric). Build a per-document comparison table. Run a\npaired significance test. Identify documents where version B\nregressed and analyze why. Recommend the winner with caveats.\n\n**Bias check for a resume screener.** Generate test resumes with\nvaried names (gender, ethnicity signals) but identical\nqualifications. Run the prompt on all variants. Compare score\ndistributions across demographic groups. Flag statistically\nsignificant differences. Recommend debiasing: strip names before\nscoring, add explicit fairness instructions, or run a separate\nbias-check pass.\n","# LLM Evaluation\n\n## Intro\n\nYou can't improve what you don't measure. LLM evaluation combines a\nsmall high-quality eval dataset, automated metrics where reference\nanswers exist, LLM-as-judge for subjective quality, and regression\ntests in CI. Build the eval set first; everything else depends on it.\n\n## Overview\n\n### Build an evaluation dataset\n\nWithout an eval set, you're guessing. Aim for 50–100 representative\ninput\u002Fexpected-output pairs from real usage, with 10–20% adversarial\nor edge-case examples. Label each row with metadata (difficulty,\ncategory, expected behavior) and split into a dev set (for\niteration) and a held-out test set (for final measurement).\n\nStore as JSONL or CSV:\n\n```jsonl\n{\"input\": \"...\", \"expected\": \"...\", \"category\": \"billing\"}\n```\n\nSources: production logs, user feedback, manually curated examples,\nsynthetic generation followed by human review.\n\n### Automated metrics\n\nUse when output has a clear reference answer. Cheap and fast, but\nmiss nuance — always combine with human or LLM-as-judge.\n\n- **BLEU** — n-gram precision; good for translation, poor for\n  open-ended generation.\n- **ROUGE** (especially ROUGE-L) — recall-oriented; good for\n  summarization.\n- **Exact match** — binary pass\u002Ffail; factual extraction,\n  classification.\n- **BERTScore** — cosine similarity of contextual embeddings;\n  better than BLEU\u002FROUGE for paraphrased correct answers.\n- **Embedding similarity** — quick semantic similarity to a\n  reference.\n- **Code:** Pass@k (does generated code pass test cases?), syntax\n  validity.\n- **Classification:** precision\u002Frecall\u002FF1 per class.\n- **Structured output:** schema compliance rate, field accuracy.\n\n### LLM-as-judge\n\nUse a strong LLM to score outputs from a weaker LLM or competing\nprompt versions.\n\nSetup: define a rubric with 3–5 criteria (accuracy, helpfulness,\nsafety, format compliance), score each on a 1–5 scale with explicit\nlevel definitions, run at temperature 0 for reproducibility, and\ninclude the rubric, input, and output in the judge prompt.\n\n```\nYou are evaluating the quality of an AI response.\n\nCriteria:\n- Accuracy (1-5): Is the information factually correct?\n- Completeness (1-5): Does it address all parts of the question?\n- Clarity (1-5): Is the response well-organized and easy to read?\n\nInput: {input}\nResponse: {response}\n\nScore each criterion and provide a brief justification.\nReturn as JSON:\n{\"accuracy\": N, \"completeness\": N, \"clarity\": N, \"justification\": \"...\"}\n```\n\nMitigate judge bias: swap order in pairwise comparisons (position\nbias), run each evaluation twice for consistency, average across\nmultiple judge models, and calibrate against human ratings on a\nsmall set.\n\n### A\u002FB testing prompts\n\nCompare prompt versions on the same eval set. Run both, score with\nautomated metrics + LLM-as-judge, compare distributions (mean,\nmedian, p25, p75), then run a paired significance test (paired\nt-test or Wilcoxon signed-rank). Critically: even if version B wins\noverall, check whether it regressed on cases version A handled. A\nprompt leaderboard tracking versions over time pays off quickly.\n\n### Regression testing in CI\n\nMaintain a golden suite of critical test cases with expected\noutputs. Run on every prompt or model change. Set thresholds\n(\"accuracy >95%, format compliance 100%\") and fail the build when\nbreached. Alert on degradation trends even within thresholds.\n\n### RAG-specific (RAGAS)\n\nFor RAG pipelines, the four metrics are:\n\n- **Context precision** — fraction of retrieved chunks that are\n  relevant.\n- **Context recall** — fraction of needed information that was\n  retrieved.\n- **Faithfulness** — is the answer grounded in the retrieved\n  context, or hallucinated?\n- **Answer relevance** — does the answer actually address the\n  question?\n\nBuild a golden dataset of 50+ question\u002Fideal-context\u002Freference\ntriples and score with RAGAS to localize the failing stage\n(retrieval vs. generation).\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Eval set built entirely from synthetic data.** Synthetic data captures what you think can go wrong, not what actually goes wrong in production. A chatbot eval set built from GPT-generated questions will miss the real distribution of user queries. Mix production examples into the eval set before using it to make decisions.\n- **Tuning prompts against the test set.** Choosing prompts based on test-set performance makes the test set part of the development loop — it no longer measures generalization. Keep a true held-out test set; iterate on a separate dev set.\n- **Single-number metric hiding subgroup regressions.** A new prompt version with an overall accuracy of 92% may be 80% on billing questions even though it is 99% on FAQ questions. Always slice metrics by category, difficulty, and edge-case subsets before declaring a winner.\n- **LLM-as-judge without calibration.** Judge models have biases: position bias (preferring the first option), verbosity bias (preferring longer answers), and self-preference (preferring their own outputs). Use swap-order evaluation and calibrate the judge on a small set of human-labeled examples before trusting its scores.\n- **No reproducibility on eval runs.** LLM evaluation at temperature > 0 produces different results on every run. Set temperature = 0 for evaluation and pin all model versions and prompt hashes. Without this, you can't tell whether a score change is a real improvement or noise.\n- **Treating automated metrics as ground truth for open-ended tasks.** BLEU and ROUGE measure n-gram overlap, not quality. A correct answer phrased differently from the reference scores poorly; a fluent but wrong answer may score well. Use automated metrics only where reference answers exist; use LLM-as-judge for open-ended tasks.\n- **Reporting only means without distributions.** A mean faithfulness score of 0.85 is compatible with half the responses being hallucinated (0.7) and half being perfect (1.0). Always report p50, p90, p99 and the fraction of responses below a minimum acceptable threshold.\n\n## Full reference\n\n### Human evaluation\n\nThe gold standard, but expensive — reserve for high-stakes\ndecisions. Use 3+ raters per example to measure inter-rater\nagreement (Cohen's kappa). Provide clear rubrics; vague instructions\nproduce noisy ratings. Blind raters to which version they're\nevaluating. 50–100 examples is usually enough for directional\ncalls.\n\n### Bias and safety\n\n- Test with demographically diverse inputs (names, locations,\n  contexts).\n- Probe for stereotyping, toxicity, and refusal of valid requests.\n- Run red-team prompts to provoke harmful outputs.\n- Track refusal rate — too high means the model is over-cautious.\n- Tools: Perspective API for toxicity, custom classifiers for\n  domain-specific harms.\n\n### Choosing metrics by task\n\n| Task | Metrics |\n|---|---|\n| Translation | BLEU, chrF, COMET, human eval |\n| Summarization | ROUGE-L, BERTScore, faithfulness, human eval |\n| Open-ended generation | LLM-as-judge, human eval |\n| Classification | Precision, recall, F1, confusion matrix |\n| Structured extraction | Schema compliance, field accuracy, exact match |\n| Code | Pass@k, syntax validity, lint |\n| RAG | Context precision\u002Frecall, faithfulness, answer relevance |\n| Agents \u002F multi-step | Task success rate, step efficiency, tool-call accuracy |\n\n### Statistical rigor\n\nAlways report variance, not point estimates. For paired comparisons\n(same eval set, two systems) use the paired t-test or Wilcoxon\nsigned-rank. Bootstrap confidence intervals when distributions are\nskewed. Beware multiple-comparison inflation when testing many\nprompt variants — apply Bonferroni or Holm-Bonferroni correction.\n\n### Common eval anti-patterns\n\n- **Eval set built from synthetic data only** — never reflects\n  real failure modes. Mix in real production examples.\n- **Single-number metric** — hides regressions on subgroups. Always\n  slice.\n- **Tuning prompt against the test set** — same data leakage problem\n  as in classical ML. Keep a true held-out test set.\n- **Trusting LLM-as-judge without calibration** — judges have\n  biases. Calibrate against human ratings on a small set.\n- **Reporting averages without distributions** — mean hides tails;\n  always show p50, p90, p99.\n- **No reproducibility** — use temperature 0 for evaluation runs and\n  pin all model and prompt versions.\n\n### Worked scenarios\n\n**Eval pipeline for a support chatbot.** Build a JSONL eval set\nfrom production conversation logs. Define a rubric (accuracy,\nhelpfulness, tone, escalation appropriateness). Implement\nLLM-as-judge with a strong model. Set up CI to run evals on every\nprompt change and report a scorecard. Flag regressions beyond 5% on\nany metric.\n\n**Comparing two summarization prompts.** Run both on 50 diverse\ndocuments. Score with ROUGE-L (automated) and LLM-as-judge\n(quality rubric). Build a per-document comparison table. Run a\npaired significance test. Identify documents where version B\nregressed and analyze why. Recommend the winner with caveats.\n\n**Bias check for a resume screener.** Generate test resumes with\nvaried names (gender, ethnicity signals) but identical\nqualifications. Run the prompt on all variants. Compare score\ndistributions across demographic groups. Flag statistically\nsignificant differences. Recommend debiasing: strip names before\nscoring, add explicit fairness instructions, or run a separate\nbias-check pass.\n",{"name":5,"metadata":48,"description":55},{"processkit":49},{"id":50,"created":51,"version":52,"category":53,"apiVersion":54},"SKILL-llm-evaluation",1775433600000,"1.1.0","data-ai","processkit.projectious.work\u002Fv1","LLM output evaluation — automated metrics, LLM-as-judge, A\u002FB testing, regression testing. Use when measuring LLM output quality, comparing prompt or model versions, building an automated eval pipeline, setting up regression tests for prompt changes, or evaluating RAG systems and bias\u002Fsafety.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fdata-ai\u002Fllm-evaluation","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add projectious-work\u002Fprocesskit --skill llm-evaluation",{"tool":69,"command":70},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill llm-evaluation",{"tool":72,"command":73},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill llm-evaluation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fdata-ai\u002Fllm-evaluation\u002FSKILL.md",true,[],[78,101,121,142,159,177],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":87,"publishedAt":43},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[84],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[88,89,90,91,92,93,39,94,95,96,80,97,32,98,30,99,100],"management","skill management","create","update","package","alpha","list","manage","ontology","get","manifests","skill package","transition",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":108,"publishedAt":43},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[107],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},[88,109,110,111,112,113,93,39,114,115,95,116,117,118,97,119,120],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":43},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[88,128,129,90,91,130,93,39,131,132,133,134,97,135,136,137,138,139,140,141],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":43},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[88,96,149,90,93,150,151,114,152,131,95,153,154,97,155,156,136,157,30,158],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":43},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[166,167,168,169,93,170,171,172,39,173,174,175,176],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":43},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[88,184,185,90,91,130,93,150,39,94,131,186,95,133,97,156,136,137,28,100],"capability","capability management","queries"]