[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X0DZDB028J6S7MTYWGC6BN":3,"skill-same:01M6X0DZDB028J6S7MTYWGC6BN":108},{"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":75,"commitSha":76,"skillDirectory":77,"forksCount":14,"repositoryHtmlUrl":78,"repositoryHomepageUrl":79,"ownerHtmlUrl":80,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":81,"install":82,"resources":95},"01M6X0DZDB028J6S7MTYWGC6BN","skill-builder",null,"Author a new processkit skill end-to-end — use-case interview, frontmatter, body sections, Gotchas, and trigger-phrase generation.","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\u002Fprocesskit\u002Fskill-builder\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],"Skill Builder","builder","wed","when","audit trail","body","skill-template","end","creation","project","query","case interview","workflow","duplicates","log","work","template","start","audit","create","2026-11-10 10:12:30",false,"---\nname: skill-builder\ndescription: >\n  Author a new processkit skill end-to-end — use-case interview,\n  frontmatter, body sections, Gotchas, and trigger-phrase generation.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-skill-builder\n    version: \"1.0.0\"\n    created: 2026-04-08T00:00:00Z\n    category: processkit\n    layer: null\n    uses:\n      - skill: index-management\n        purpose: \"Query existing skills before creating a new one to surface duplicates and to find related skills the new one should reference under uses:.\"\n      - skill: event-log\n        purpose: \"Log skill.created and skill.reviewed events so the project's audit trail captures when new skills enter the catalog.\"\n    provides:\n      primitives: []\n      mcp_tools: []\n      assets: [skill-template]\n      processes: [skill-creation]\n    commands:\n      - name: skill-builder-create\n        args: \"skill-topic\"\n        description: \"Start the interactive skill-creation workflow for a given topic\"\n---\n\n# Skill Builder\n\n## Intro\n\n`skill-builder` is the canonical interactive workflow for authoring a\nnew processkit skill from scratch. It walks the user through use-case\ndiscovery, frontmatter authoring, body section drafting, mandatory\nGotchas authoring, validation against the 5 Skill Killers, and trigger\ntest generation — producing a complete `src\u002Fskills\u002F\u003Cname>\u002F` folder that\nfollows the [Agent Skills](https:\u002F\u002Fagentskills.io) standard and\nprocesskit's conventions.\n\nThis is the first skill to reach for whenever a new skill needs to be\nwritten. Building a skill without skill-builder almost always produces\nsomething with at least one of the 5 Skill Killers — usually a vague\ndescription, a missing or generic Gotchas section, or scope creep.\n\n## Overview\n\n### The seven-step workflow\n\n```\n1. Interview      → 2-3 concrete use cases the skill should enable\n2. Scope check    → confirm one-sentence-one-skill rule\n3. Pattern pick   → match the use case to one of the 5 patterns (or none)\n4. Frontmatter    → name, description (with triggers), metadata.processkit\n5. Body draft     → Intro, Overview, Gotchas (mandatory!), Full reference\n6. Self-check     → 5 Skill Killers + Anthropic troubleshooting playbook\n7. Trigger tests  → positive cases that fire, negatives that don't\n```\n\nWalk the user through each step in order. Skipping a step (especially #1\nor #5) is the single most common failure mode.\n\n### Step 1 — Interview\n\nBefore writing any YAML or Markdown, ask the user for **2-3 concrete use\ncases** the skill should enable. Anthropic's guide insists on this for\ngood reason: a skill defined without use cases ends up vague,\nover-scoped, or both.\n\nGood use case format:\n\n```\nUse Case: \u003Cname>\nTrigger: User says \"...\" or \"...\"\nSteps:\n  1. ...\n  2. ...\n  3. ...\nResult: \u003Cwhat success looks like>\n```\n\nFor each use case, capture (a) the literal trigger phrases, (b) the\nsteps the skill would execute, (c) the result that proves success.\n\nIf the user can't articulate 2-3 use cases, the skill isn't ready to be\nbuilt. Push back: *\"Can you give me one more concrete example where\nyou'd use this?\"*\n\n### Step 2 — Scope check\n\nApply the **one sentence, one skill** rule (Skills Master Class Level\n2): if you can't describe what the skill does in one sentence without\nconjunctions (\"and\", \"also\", \"plus\"), it's probably two skills. Split\nbefore continuing.\n\n| Bad scope | Good scope |\n|---|---|\n| \"Create work items AND record decisions AND log events.\" | \"Create work items with proper state-machine handling.\" |\n| → Three skills (workitem-management, decision-record, event-log). | → One skill (workitem-management). |\n\n### Step 3 — Pattern pick\n\nMatch the use cases to one of the **5 patterns** from Anthropic's guide\n(PDF Chapter 5):\n\n| Pattern | Use when | Example |\n|---|---|---|\n| **Sequential workflow orchestration** | Multi-step process in a specific order | Onboard a new customer (account → payment → subscription → email) |\n| **Multi-MCP coordination** | Workflow spans multiple services with phase separation | Design-to-development handoff (Figma → Drive → Linear → Slack) |\n| **Iterative refinement** | Output quality improves with iteration loops | Report generation (draft → quality check → refinement → finalization) |\n| **Context-aware tool selection** | Same outcome, different tools depending on context | Smart file storage (cloud \u002F docs \u002F git \u002F local based on file properties) |\n| **Domain-specific intelligence** | Skill adds specialized knowledge beyond raw tool access | Payment processing with compliance checks before\u002Fafter the call |\n\nSome skills don't fit any pattern — pure knowledge skills like\n`python-best-practices` or `code-review`. That's fine. Use no pattern;\njust write the conventions clearly.\n\n### Step 4 — Frontmatter\n\nGenerate the YAML frontmatter following the Agent Skills standard.\nStart from `assets\u002Fskill-template.md` and fill in the placeholders.\nThe shape:\n\n```yaml\n---\nname: \u003Ckebab-case-name>\ndescription: >\n  \u003COne-sentence imperative (verb-first): what the skill does.>\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-\u003Ckebab-case-name>\n    version: \"1.0.0\"\n    created: \u003CYYYY-MM-DDTHH:MM:SSZ>\n    category: \u003Cprocess|language|framework|infrastructure|...>\n    layer: \u003C0-4 for process skills, null otherwise>\n    uses:\n      - skill: \u003Cother-skill>\n        purpose: \"\u003Cone sentence: why this skill uses the other>\"\n    provides:\n      primitives: [...]\n      mcp_tools: [...]\n      assets: [...]\n    # If the skill has user-invocable workflows, add:\n    commands:\n      - name: \u003Cskill-name>-\u003Cworkflow>\n        args: \"arg-shape\"          # no angle brackets\n        description: \"One sentence: what this command does\"\n---\n```\n\n**Critical rules** (Anthropic PDF p10-11):\n\n- `name` must be kebab-case, must match the directory name, must NOT\n  contain \"claude\" or \"anthropic\" (reserved by Anthropic).\n- `description` must be a **one-sentence imperative** (verb-first:\n  \"Author X\", \"Review Y for Z\", \"Generate W\"). Under 200 characters.\n  NO \"Use when the user says…\" — trigger phrases live in\n  skill-finder's trigger table (Step 9), not here. NO XML angle\n  brackets (`\u003C` \u002F `>`) in frontmatter — they inject into the system\n  prompt.\n- Every entry under `uses:` must have a `purpose` field — no bare\n  strings.\n\n### Step 5 — Body draft\n\nThe SKILL.md body has FOUR sections, in this order: Intro, Overview,\nGotchas, Full reference. See the template at `assets\u002Fskill-template.md`\nfor the canonical structure.\n\n**Write Gotchas BEFORE finalizing Overview.** Anthropic's guide and the\nSkills Master Class both call Gotchas the \"highest-signal content\" —\nwhere the model goes wrong. Authoring it first surfaces the assumptions\nthe skill is implicitly making and often forces clarifications back into\nOverview.\n\nRules for a good Gotchas section:\n\n- **Agent-only failure modes**, not general practitioner pitfalls.\n  (Those go in Anti-patterns under Full reference.)\n- **Provider-neutral.** What's obvious to Claude may not be obvious to\n  Gemini, ChatGPT, or whatever harness loads the skill. Don't assume\n  the agent is Claude.\n- **Specific.** \"Don't be sloppy\" is useless. \"Always check call sites\n  before approving a function signature change because the diff hides\n  unchanged callers\" is useful.\n- **5-10 items.** Fewer means you haven't thought hard enough; more\n  means you're padding.\n\nTo draft Gotchas, ask yourself five questions:\n\n1. What would an agent get wrong on the first try?\n2. What does the agent need to KNOW that the user wouldn't think to say?\n3. Where would the agent helpfully overshoot (do more than asked)?\n4. Where would the agent helpfully undershoot (leave the user hanging)?\n5. What conventions are unique to this skill that the agent has to learn?\n\nIf you can't answer all five concretely, the Gotchas section isn't\nready.\n\n### Step 6 — Self-check (the 5 Skill Killers)\n\nBefore declaring the skill done, run it through the **5 Skill Killers**\nchecklist (Skills Master Class Level 2):\n\n| # | Killer | Self-check question |\n|---|---|---|\n| 1 | Description doesn't trigger | Does the description include literal trigger phrases? Specific enough that an agent would know when to load it? |\n| 2 | Over-defining process | Did you over-prescribe steps when the agent should have degrees of freedom? |\n| 3 | Stating the obvious | Is anything in the SKILL.md what a decent agent already knows? Cut it. (BUT — be careful about provider neutrality.) |\n| 4 | Missing Gotchas | Is the Gotchas section present, specific, and provider-neutral? |\n| 5 | Monolithic blob | Is the SKILL.md under 5000 words? If not, push detail to `references\u002F`. |\n\nPlus Anthropic's troubleshooting playbook (PDF p25-27): under-trigger,\nover-trigger, instructions not followed, large context. Each has a\nknown fix listed there.\n\nIf any check fails, fix it before continuing.\n\n### Step 7 — Trigger tests\n\nWrite a list of positive and negative trigger test cases. The agent (or\n`skill-reviewer`) can run these mentally:\n\n```\nShould trigger:\n  - \"\u003Cphrase the user might actually say>\"\n  - \"\u003Cparaphrased version>\"\n  - \"\u003Cedge case that should still trigger>\"\n\nShould NOT trigger:\n  - \"\u003Cadjacent task that belongs to a different skill>\"\n  - \"\u003Ctoo-vague phrase>\"\n  - \"\u003Cunrelated task>\"\n```\n\nIf you can't write at least 3 positive and 3 negative cases, the\ndescription is too vague — go back to Step 4.\n\n### Step 8 — Create command adapter files\n\nIf the skill's `metadata.processkit.commands` list is non-empty, create one\nadapter file per command under `commands\u002F`:\n\n**File:** `commands\u002F\u003Cskill-name>-\u003Cworkflow>.md`\n\n```markdown\n---\nargument-hint: arg-shape\nallowed-tools: []\n---\n\nUse the \u003Cskill-name> skill, Workflow X (name), for $ARGUMENTS.\n```\n\nRules:\n- File name must exactly match the `name` field in `commands:`.\n- Body is one sentence — no logic, no workflow steps. Everything lives in SKILL.md.\n- `allowed-tools` scoped as narrowly as possible. Use `[]` if no shell access is\n  needed. Never use `Bash(*)` unless the command genuinely runs arbitrary shell.\n- `argument-hint` must match the `args` field from `metadata.processkit.commands`.\n\nAdd a one-line mention of the command in SKILL.md's Overview so agents discover it\nwhen reading the skill, not only when the user types `\u002Fcommand-name`:\n\n```markdown\nThis skill also provides the `\u002Fmodel-recommender-profile` command for direct\ninvocation — see `commands\u002Fmodel-recommender-profile.md`.\n```\n\nFor harness UI registration (Claude Code tab-complete), copy the adapter files to\n`.claude\u002Fcommands\u002F` in the project root. This is optional and not required for the\ncommand to work at runtime.\n\nThis skill also provides the `\u002Fskill-builder-create` slash command for direct invocation — see `commands\u002Fskill-builder-create.md`.\n\n### Step 9 — Update skill-finder\n\nAfter the skill passes the self-check, add it to `skill-finder`:\n\n1. Add 1–3 trigger phrases to the trigger-phrase table in\n   `src\u002Fskills\u002Fskill-finder\u002FSKILL.md`\n2. Add a one-liner under the appropriate category in the by-category section\n3. If no existing category fits, add a new one\n\nThis step is not optional — a skill that is not in skill-finder is\ninvisible to agents who do not already know its name.\n\n## Gotchas\n\nThese are agent-specific failure modes you (the agent USING\nskill-builder) will hit if you're not careful. Pause-and-self-check\nitems.\n\n- **Skipping the interview and going straight to writing.** If the user\n  says *\"build me a skill for X\"*, do NOT immediately produce a\n  SKILL.md. Ask for 2-3 concrete use cases first, even if the user is\n  impatient. A skill built without use cases is almost always too vague\n  to trigger reliably and ends up rewritten.\n- **Writing the description as narrative or including \"Use when…\".**\n  The description must be a one-sentence imperative (verb-first, under\n  200 characters). Trigger phrases (\"Use when the user says X, Y, or\n  Z\") belong in skill-finder's trigger-phrase table (Step 9), NOT in\n  the description field. \"Use when…\" in a description is a must-fix\n  finding in skill-reviewer.\n- **Padding Gotchas with general anti-patterns.** Gotchas is for\n  agent-specific failure modes that recur across providers. If a pitfall\n  applies to humans too, it belongs in Anti-patterns under Full\n  reference, not Gotchas.\n- **Defaulting Gotchas to \"be careful\" generalities.** *\"Don't make\n  mistakes\"* teaches the agent nothing. Each Gotchas item must name a\n  specific failure mode AND a specific countermeasure.\n- **Forgetting the 1024-char description limit.** Anthropic's loader\n  truncates descriptions over 1024 characters. Count characters before\n  finalizing. If too long, trim by cutting the least-distinctive trigger\n  phrases first, not the \"what it does\" part.\n- **Using XML angle brackets in frontmatter.** Anthropic explicitly\n  forbids `\u003C` and `>` in any frontmatter field because the frontmatter\n  lands in the system prompt and angle brackets could inject. Use them\n  freely in body text where needed; never in frontmatter.\n- **Naming a skill with \"claude\" or \"anthropic\" in the name.**\n  Reserved by Anthropic. Use a neutral name even if your skill is\n  Claude-specific (it shouldn't be — provider neutrality applies).\n- **Putting the skill in the wrong category.** processkit's category\n  taxonomy is fixed (`process`, `language`, `framework`, `infrastructure`,\n  `architecture`, `design`, `data`, `ai`, `api`, `security`,\n  `observability`, `database`, `performance`, `meta`). If the new skill\n  doesn't fit, push back on the user — they're probably trying to build\n  something out of scope, not invent a new category.\n- **Inventing dependencies under `uses:` that don't exist.** Always\n  query `index-management` first to confirm the skills you list under\n  `uses:` actually exist. A `uses: [foo-thing]` entry pointing at a\n  phantom skill makes the dependency graph invalid and silently breaks\n  the agent's expectation that delegation will work.\n- **Writing one giant skill instead of two focused ones.** If you find\n  yourself writing \"and also\" or \"plus\" in the description, stop. Apply\n  the one-sentence-one-skill rule and split.\n- **Creating the skill folder before finalizing the design.** Don't\n  write to disk during Steps 1-3. The folder should appear all at\n  once after Step 6 passes — otherwise you end up with stranded\n  half-finished skill folders that pollute the catalog.\n- **Skipping the trigger-test step \"because the description seems\n  obvious\".** If you can't write 3 positive and 3 negative test cases,\n  the description is not as obvious as you think. The exercise of\n  writing the negatives is what surfaces over-triggering risks.\n- **Forgetting command file naming requires the skill-name prefix.**\n  Command files must be named `\u003Cskill-name>-\u003Cworkflow>.md`, not just\n  `\u003Cworkflow>.md`. Unprefixed names collide across skills once all\n  commands land in `.claude\u002Fcommands\u002F`. Always include the skill name.\n- **Writing logic into command adapter files.** The adapter's body is\n  one sentence pointing at the skill and workflow. If you find yourself\n  writing workflow steps in the adapter, move them to SKILL.md. The\n  adapter is an invocation shim, not a skill.\n- **Shipping an MCP server without tool annotations.** Every `@server.tool()`\n  must carry explicit `readOnlyHint`, `destructiveHint`, `idempotentHint`,\n  and `openWorldHint` annotations. Missing annotations are a must-fix in\n  skill-reviewer. Default them conservatively: query tools get\n  `readOnlyHint: true`; anything that overwrites state gets\n  `destructiveHint: true`; HTTP-calling tools get `openWorldHint: true`.\n\n## Full reference\n\n### Asset: the SKILL.md template\n\n`assets\u002Fskill-template.md` is a complete SKILL.md scaffold with TODO\nmarkers in every section. Copy it as the starting point for any new\nskill, then walk through Steps 1-7 to fill in each section.\n\n### File system layout for the new skill\n\nAfter running through all 7 steps, the new skill folder should look\nlike:\n\n```\nsrc\u002Fskills\u002F\u003Cskill-name>\u002F\n  SKILL.md              ← required, the only file Claude reads automatically\n  scripts\u002F              ← always present (with .gitkeep), per processkit convention\n  references\u002F           ← only if SKILL.md > 5000 words and content was extracted\n  assets\u002F               ← only if the skill ships templates \u002F icons \u002F brand assets\n  examples\u002F             ← optional, recommended for skills with complex outputs\n  commands\u002F             ← only if metadata.processkit.commands is non-empty\n    \u003Cskill>-\u003Cworkflow>.md  ← one file per command; provider-specific adapter\n  mcp\u002F                  ← only if the skill ships an MCP server\n```\n\nEmpty subdirectories (`scripts\u002F`, especially) should still have a\n`.gitkeep` so they survive the clone.\n\n### Trigger phrase library\n\nCommon verbs that agents have learned to recognize as triggers:\n\n| Skill type | Common trigger verbs |\n|---|---|\n| Creation | \"create\", \"add\", \"make\", \"scaffold\", \"draft\", \"set up\" |\n| Review | \"review\", \"check\", \"audit\", \"look at\", \"evaluate\" |\n| Query | \"what's\", \"show me\", \"list\", \"find\", \"search\" |\n| Analysis | \"analyze\", \"explain\", \"diagnose\", \"why\", \"investigate\" |\n| Decision | \"should we\", \"compare\", \"trade-off\", \"pick\", \"choose\" |\n| Documentation | \"document\", \"write up\", \"explain to others\" |\n\nWhen in doubt, prefer the user's actual words over a \"cleaner\" version.\nThe closer the description trigger matches what users naturally say,\nthe more reliably the skill loads.\n\n### Description length budget\n\nAnthropic's hard limit is 1024 characters, but the processkit\nconvention is stricter: **one-sentence imperative, under 200\ncharacters**. Trigger phrases (\"when the user says X\") live in\nskill-finder's trigger table, not the description. A good description\nis 60-150 characters — short enough to skim in a catalog listing.\nIf you find yourself going over 200 characters, you are either\nover-scoping the skill (split it) or smuggling trigger language\ninto the wrong field (move it to skill-finder Step 9).\n\n### When to use skill-reviewer instead\n\nIf the task is reviewing or improving an EXISTING skill, use\n`skill-reviewer` instead. skill-reviewer takes an existing SKILL.md\nand runs the 5 Skill Killers + Anthropic troubleshooting playbook\nagainst it, returning a report of what to fix. **skill-builder is for\ngreenfield; skill-reviewer is for brownfield.**\n\n### Anti-patterns (general — humans + agents alike)\n\nThese are pitfalls that go wrong regardless of who is authoring:\n\n- **Description-as-summary.** If the description reads like an \"About\"\n  paragraph from a wiki, it's wrong. The description is a TRIGGER, not\n  a summary.\n- **Inventing categories.** Push back on the user about scope before\n  inventing a new category — almost always the right answer is to fit\n  into an existing one or to NOT build the skill.\n- **Massive Full reference, empty Overview.** Overview is what the\n  agent reads when it's actually doing work. Full reference is what the\n  agent reads when something goes wrong. Don't put core workflow in\n  Full reference.\n- **Skipping the assets layer.** If the skill produces a structured\n  artifact, ship the template under `assets\u002F` so the agent fills it in\n  instead of regenerating the structure each time.\n- **Including a `README.md` inside the skill folder.** Anthropic's\n  hard rule: no README.md inside a skill folder, including\n  subdirectories. Documentation goes in SKILL.md or references\u002F.\n  MCP server documentation goes in `mcp\u002FSERVER.md`, not\n  `mcp\u002FREADME.md`.\n- **Omitting the commands mention from SKILL.md Overview.** If the skill has\n  `commands\u002F` adapter files, the Overview section must reference them so agents\n  learn the commands exist from reading the skill — not only when the user\n  happens to type the slash. One sentence per command is enough.\n\n### Cross-references\n\n- `skill-reviewer` — for reviewing existing skills (brownfield)\n- `index-management` — call before creating to avoid duplicates\n- `event-log` — call after creating to log the new skill\n- `src\u002Fskills\u002FFORMAT.md` — the canonical format spec, always-current\n  source of truth for frontmatter fields and conventions\n- `src\u002Fskills\u002FINDEX.md` — the catalog index, lists every shipped skill\n","# Skill Builder\n\n## Intro\n\n`skill-builder` is the canonical interactive workflow for authoring a\nnew processkit skill from scratch. It walks the user through use-case\ndiscovery, frontmatter authoring, body section drafting, mandatory\nGotchas authoring, validation against the 5 Skill Killers, and trigger\ntest generation — producing a complete `src\u002Fskills\u002F\u003Cname>\u002F` folder that\nfollows the [Agent Skills](https:\u002F\u002Fagentskills.io) standard and\nprocesskit's conventions.\n\nThis is the first skill to reach for whenever a new skill needs to be\nwritten. Building a skill without skill-builder almost always produces\nsomething with at least one of the 5 Skill Killers — usually a vague\ndescription, a missing or generic Gotchas section, or scope creep.\n\n## Overview\n\n### The seven-step workflow\n\n```\n1. Interview      → 2-3 concrete use cases the skill should enable\n2. Scope check    → confirm one-sentence-one-skill rule\n3. Pattern pick   → match the use case to one of the 5 patterns (or none)\n4. Frontmatter    → name, description (with triggers), metadata.processkit\n5. Body draft     → Intro, Overview, Gotchas (mandatory!), Full reference\n6. Self-check     → 5 Skill Killers + Anthropic troubleshooting playbook\n7. Trigger tests  → positive cases that fire, negatives that don't\n```\n\nWalk the user through each step in order. Skipping a step (especially #1\nor #5) is the single most common failure mode.\n\n### Step 1 — Interview\n\nBefore writing any YAML or Markdown, ask the user for **2-3 concrete use\ncases** the skill should enable. Anthropic's guide insists on this for\ngood reason: a skill defined without use cases ends up vague,\nover-scoped, or both.\n\nGood use case format:\n\n```\nUse Case: \u003Cname>\nTrigger: User says \"...\" or \"...\"\nSteps:\n  1. ...\n  2. ...\n  3. ...\nResult: \u003Cwhat success looks like>\n```\n\nFor each use case, capture (a) the literal trigger phrases, (b) the\nsteps the skill would execute, (c) the result that proves success.\n\nIf the user can't articulate 2-3 use cases, the skill isn't ready to be\nbuilt. Push back: *\"Can you give me one more concrete example where\nyou'd use this?\"*\n\n### Step 2 — Scope check\n\nApply the **one sentence, one skill** rule (Skills Master Class Level\n2): if you can't describe what the skill does in one sentence without\nconjunctions (\"and\", \"also\", \"plus\"), it's probably two skills. Split\nbefore continuing.\n\n| Bad scope | Good scope |\n|---|---|\n| \"Create work items AND record decisions AND log events.\" | \"Create work items with proper state-machine handling.\" |\n| → Three skills (workitem-management, decision-record, event-log). | → One skill (workitem-management). |\n\n### Step 3 — Pattern pick\n\nMatch the use cases to one of the **5 patterns** from Anthropic's guide\n(PDF Chapter 5):\n\n| Pattern | Use when | Example |\n|---|---|---|\n| **Sequential workflow orchestration** | Multi-step process in a specific order | Onboard a new customer (account → payment → subscription → email) |\n| **Multi-MCP coordination** | Workflow spans multiple services with phase separation | Design-to-development handoff (Figma → Drive → Linear → Slack) |\n| **Iterative refinement** | Output quality improves with iteration loops | Report generation (draft → quality check → refinement → finalization) |\n| **Context-aware tool selection** | Same outcome, different tools depending on context | Smart file storage (cloud \u002F docs \u002F git \u002F local based on file properties) |\n| **Domain-specific intelligence** | Skill adds specialized knowledge beyond raw tool access | Payment processing with compliance checks before\u002Fafter the call |\n\nSome skills don't fit any pattern — pure knowledge skills like\n`python-best-practices` or `code-review`. That's fine. Use no pattern;\njust write the conventions clearly.\n\n### Step 4 — Frontmatter\n\nGenerate the YAML frontmatter following the Agent Skills standard.\nStart from `assets\u002Fskill-template.md` and fill in the placeholders.\nThe shape:\n\n```yaml\n---\nname: \u003Ckebab-case-name>\ndescription: >\n  \u003COne-sentence imperative (verb-first): what the skill does.>\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-\u003Ckebab-case-name>\n    version: \"1.0.0\"\n    created: \u003CYYYY-MM-DDTHH:MM:SSZ>\n    category: \u003Cprocess|language|framework|infrastructure|...>\n    layer: \u003C0-4 for process skills, null otherwise>\n    uses:\n      - skill: \u003Cother-skill>\n        purpose: \"\u003Cone sentence: why this skill uses the other>\"\n    provides:\n      primitives: [...]\n      mcp_tools: [...]\n      assets: [...]\n    # If the skill has user-invocable workflows, add:\n    commands:\n      - name: \u003Cskill-name>-\u003Cworkflow>\n        args: \"arg-shape\"          # no angle brackets\n        description: \"One sentence: what this command does\"\n---\n```\n\n**Critical rules** (Anthropic PDF p10-11):\n\n- `name` must be kebab-case, must match the directory name, must NOT\n  contain \"claude\" or \"anthropic\" (reserved by Anthropic).\n- `description` must be a **one-sentence imperative** (verb-first:\n  \"Author X\", \"Review Y for Z\", \"Generate W\"). Under 200 characters.\n  NO \"Use when the user says…\" — trigger phrases live in\n  skill-finder's trigger table (Step 9), not here. NO XML angle\n  brackets (`\u003C` \u002F `>`) in frontmatter — they inject into the system\n  prompt.\n- Every entry under `uses:` must have a `purpose` field — no bare\n  strings.\n\n### Step 5 — Body draft\n\nThe SKILL.md body has FOUR sections, in this order: Intro, Overview,\nGotchas, Full reference. See the template at `assets\u002Fskill-template.md`\nfor the canonical structure.\n\n**Write Gotchas BEFORE finalizing Overview.** Anthropic's guide and the\nSkills Master Class both call Gotchas the \"highest-signal content\" —\nwhere the model goes wrong. Authoring it first surfaces the assumptions\nthe skill is implicitly making and often forces clarifications back into\nOverview.\n\nRules for a good Gotchas section:\n\n- **Agent-only failure modes**, not general practitioner pitfalls.\n  (Those go in Anti-patterns under Full reference.)\n- **Provider-neutral.** What's obvious to Claude may not be obvious to\n  Gemini, ChatGPT, or whatever harness loads the skill. Don't assume\n  the agent is Claude.\n- **Specific.** \"Don't be sloppy\" is useless. \"Always check call sites\n  before approving a function signature change because the diff hides\n  unchanged callers\" is useful.\n- **5-10 items.** Fewer means you haven't thought hard enough; more\n  means you're padding.\n\nTo draft Gotchas, ask yourself five questions:\n\n1. What would an agent get wrong on the first try?\n2. What does the agent need to KNOW that the user wouldn't think to say?\n3. Where would the agent helpfully overshoot (do more than asked)?\n4. Where would the agent helpfully undershoot (leave the user hanging)?\n5. What conventions are unique to this skill that the agent has to learn?\n\nIf you can't answer all five concretely, the Gotchas section isn't\nready.\n\n### Step 6 — Self-check (the 5 Skill Killers)\n\nBefore declaring the skill done, run it through the **5 Skill Killers**\nchecklist (Skills Master Class Level 2):\n\n| # | Killer | Self-check question |\n|---|---|---|\n| 1 | Description doesn't trigger | Does the description include literal trigger phrases? Specific enough that an agent would know when to load it? |\n| 2 | Over-defining process | Did you over-prescribe steps when the agent should have degrees of freedom? |\n| 3 | Stating the obvious | Is anything in the SKILL.md what a decent agent already knows? Cut it. (BUT — be careful about provider neutrality.) |\n| 4 | Missing Gotchas | Is the Gotchas section present, specific, and provider-neutral? |\n| 5 | Monolithic blob | Is the SKILL.md under 5000 words? If not, push detail to `references\u002F`. |\n\nPlus Anthropic's troubleshooting playbook (PDF p25-27): under-trigger,\nover-trigger, instructions not followed, large context. Each has a\nknown fix listed there.\n\nIf any check fails, fix it before continuing.\n\n### Step 7 — Trigger tests\n\nWrite a list of positive and negative trigger test cases. The agent (or\n`skill-reviewer`) can run these mentally:\n\n```\nShould trigger:\n  - \"\u003Cphrase the user might actually say>\"\n  - \"\u003Cparaphrased version>\"\n  - \"\u003Cedge case that should still trigger>\"\n\nShould NOT trigger:\n  - \"\u003Cadjacent task that belongs to a different skill>\"\n  - \"\u003Ctoo-vague phrase>\"\n  - \"\u003Cunrelated task>\"\n```\n\nIf you can't write at least 3 positive and 3 negative cases, the\ndescription is too vague — go back to Step 4.\n\n### Step 8 — Create command adapter files\n\nIf the skill's `metadata.processkit.commands` list is non-empty, create one\nadapter file per command under `commands\u002F`:\n\n**File:** `commands\u002F\u003Cskill-name>-\u003Cworkflow>.md`\n\n```markdown\n---\nargument-hint: arg-shape\nallowed-tools: []\n---\n\nUse the \u003Cskill-name> skill, Workflow X (name), for $ARGUMENTS.\n```\n\nRules:\n- File name must exactly match the `name` field in `commands:`.\n- Body is one sentence — no logic, no workflow steps. Everything lives in SKILL.md.\n- `allowed-tools` scoped as narrowly as possible. Use `[]` if no shell access is\n  needed. Never use `Bash(*)` unless the command genuinely runs arbitrary shell.\n- `argument-hint` must match the `args` field from `metadata.processkit.commands`.\n\nAdd a one-line mention of the command in SKILL.md's Overview so agents discover it\nwhen reading the skill, not only when the user types `\u002Fcommand-name`:\n\n```markdown\nThis skill also provides the `\u002Fmodel-recommender-profile` command for direct\ninvocation — see `commands\u002Fmodel-recommender-profile.md`.\n```\n\nFor harness UI registration (Claude Code tab-complete), copy the adapter files to\n`.claude\u002Fcommands\u002F` in the project root. This is optional and not required for the\ncommand to work at runtime.\n\nThis skill also provides the `\u002Fskill-builder-create` slash command for direct invocation — see `commands\u002Fskill-builder-create.md`.\n\n### Step 9 — Update skill-finder\n\nAfter the skill passes the self-check, add it to `skill-finder`:\n\n1. Add 1–3 trigger phrases to the trigger-phrase table in\n   `src\u002Fskills\u002Fskill-finder\u002FSKILL.md`\n2. Add a one-liner under the appropriate category in the by-category section\n3. If no existing category fits, add a new one\n\nThis step is not optional — a skill that is not in skill-finder is\ninvisible to agents who do not already know its name.\n\n## Gotchas\n\nThese are agent-specific failure modes you (the agent USING\nskill-builder) will hit if you're not careful. Pause-and-self-check\nitems.\n\n- **Skipping the interview and going straight to writing.** If the user\n  says *\"build me a skill for X\"*, do NOT immediately produce a\n  SKILL.md. Ask for 2-3 concrete use cases first, even if the user is\n  impatient. A skill built without use cases is almost always too vague\n  to trigger reliably and ends up rewritten.\n- **Writing the description as narrative or including \"Use when…\".**\n  The description must be a one-sentence imperative (verb-first, under\n  200 characters). Trigger phrases (\"Use when the user says X, Y, or\n  Z\") belong in skill-finder's trigger-phrase table (Step 9), NOT in\n  the description field. \"Use when…\" in a description is a must-fix\n  finding in skill-reviewer.\n- **Padding Gotchas with general anti-patterns.** Gotchas is for\n  agent-specific failure modes that recur across providers. If a pitfall\n  applies to humans too, it belongs in Anti-patterns under Full\n  reference, not Gotchas.\n- **Defaulting Gotchas to \"be careful\" generalities.** *\"Don't make\n  mistakes\"* teaches the agent nothing. Each Gotchas item must name a\n  specific failure mode AND a specific countermeasure.\n- **Forgetting the 1024-char description limit.** Anthropic's loader\n  truncates descriptions over 1024 characters. Count characters before\n  finalizing. If too long, trim by cutting the least-distinctive trigger\n  phrases first, not the \"what it does\" part.\n- **Using XML angle brackets in frontmatter.** Anthropic explicitly\n  forbids `\u003C` and `>` in any frontmatter field because the frontmatter\n  lands in the system prompt and angle brackets could inject. Use them\n  freely in body text where needed; never in frontmatter.\n- **Naming a skill with \"claude\" or \"anthropic\" in the name.**\n  Reserved by Anthropic. Use a neutral name even if your skill is\n  Claude-specific (it shouldn't be — provider neutrality applies).\n- **Putting the skill in the wrong category.** processkit's category\n  taxonomy is fixed (`process`, `language`, `framework`, `infrastructure`,\n  `architecture`, `design`, `data`, `ai`, `api`, `security`,\n  `observability`, `database`, `performance`, `meta`). If the new skill\n  doesn't fit, push back on the user — they're probably trying to build\n  something out of scope, not invent a new category.\n- **Inventing dependencies under `uses:` that don't exist.** Always\n  query `index-management` first to confirm the skills you list under\n  `uses:` actually exist. A `uses: [foo-thing]` entry pointing at a\n  phantom skill makes the dependency graph invalid and silently breaks\n  the agent's expectation that delegation will work.\n- **Writing one giant skill instead of two focused ones.** If you find\n  yourself writing \"and also\" or \"plus\" in the description, stop. Apply\n  the one-sentence-one-skill rule and split.\n- **Creating the skill folder before finalizing the design.** Don't\n  write to disk during Steps 1-3. The folder should appear all at\n  once after Step 6 passes — otherwise you end up with stranded\n  half-finished skill folders that pollute the catalog.\n- **Skipping the trigger-test step \"because the description seems\n  obvious\".** If you can't write 3 positive and 3 negative test cases,\n  the description is not as obvious as you think. The exercise of\n  writing the negatives is what surfaces over-triggering risks.\n- **Forgetting command file naming requires the skill-name prefix.**\n  Command files must be named `\u003Cskill-name>-\u003Cworkflow>.md`, not just\n  `\u003Cworkflow>.md`. Unprefixed names collide across skills once all\n  commands land in `.claude\u002Fcommands\u002F`. Always include the skill name.\n- **Writing logic into command adapter files.** The adapter's body is\n  one sentence pointing at the skill and workflow. If you find yourself\n  writing workflow steps in the adapter, move them to SKILL.md. The\n  adapter is an invocation shim, not a skill.\n- **Shipping an MCP server without tool annotations.** Every `@server.tool()`\n  must carry explicit `readOnlyHint`, `destructiveHint`, `idempotentHint`,\n  and `openWorldHint` annotations. Missing annotations are a must-fix in\n  skill-reviewer. Default them conservatively: query tools get\n  `readOnlyHint: true`; anything that overwrites state gets\n  `destructiveHint: true`; HTTP-calling tools get `openWorldHint: true`.\n\n## Full reference\n\n### Asset: the SKILL.md template\n\n`assets\u002Fskill-template.md` is a complete SKILL.md scaffold with TODO\nmarkers in every section. Copy it as the starting point for any new\nskill, then walk through Steps 1-7 to fill in each section.\n\n### File system layout for the new skill\n\nAfter running through all 7 steps, the new skill folder should look\nlike:\n\n```\nsrc\u002Fskills\u002F\u003Cskill-name>\u002F\n  SKILL.md              ← required, the only file Claude reads automatically\n  scripts\u002F              ← always present (with .gitkeep), per processkit convention\n  references\u002F           ← only if SKILL.md > 5000 words and content was extracted\n  assets\u002F               ← only if the skill ships templates \u002F icons \u002F brand assets\n  examples\u002F             ← optional, recommended for skills with complex outputs\n  commands\u002F             ← only if metadata.processkit.commands is non-empty\n    \u003Cskill>-\u003Cworkflow>.md  ← one file per command; provider-specific adapter\n  mcp\u002F                  ← only if the skill ships an MCP server\n```\n\nEmpty subdirectories (`scripts\u002F`, especially) should still have a\n`.gitkeep` so they survive the clone.\n\n### Trigger phrase library\n\nCommon verbs that agents have learned to recognize as triggers:\n\n| Skill type | Common trigger verbs |\n|---|---|\n| Creation | \"create\", \"add\", \"make\", \"scaffold\", \"draft\", \"set up\" |\n| Review | \"review\", \"check\", \"audit\", \"look at\", \"evaluate\" |\n| Query | \"what's\", \"show me\", \"list\", \"find\", \"search\" |\n| Analysis | \"analyze\", \"explain\", \"diagnose\", \"why\", \"investigate\" |\n| Decision | \"should we\", \"compare\", \"trade-off\", \"pick\", \"choose\" |\n| Documentation | \"document\", \"write up\", \"explain to others\" |\n\nWhen in doubt, prefer the user's actual words over a \"cleaner\" version.\nThe closer the description trigger matches what users naturally say,\nthe more reliably the skill loads.\n\n### Description length budget\n\nAnthropic's hard limit is 1024 characters, but the processkit\nconvention is stricter: **one-sentence imperative, under 200\ncharacters**. Trigger phrases (\"when the user says X\") live in\nskill-finder's trigger table, not the description. A good description\nis 60-150 characters — short enough to skim in a catalog listing.\nIf you find yourself going over 200 characters, you are either\nover-scoping the skill (split it) or smuggling trigger language\ninto the wrong field (move it to skill-finder Step 9).\n\n### When to use skill-reviewer instead\n\nIf the task is reviewing or improving an EXISTING skill, use\n`skill-reviewer` instead. skill-reviewer takes an existing SKILL.md\nand runs the 5 Skill Killers + Anthropic troubleshooting playbook\nagainst it, returning a report of what to fix. **skill-builder is for\ngreenfield; skill-reviewer is for brownfield.**\n\n### Anti-patterns (general — humans + agents alike)\n\nThese are pitfalls that go wrong regardless of who is authoring:\n\n- **Description-as-summary.** If the description reads like an \"About\"\n  paragraph from a wiki, it's wrong. The description is a TRIGGER, not\n  a summary.\n- **Inventing categories.** Push back on the user about scope before\n  inventing a new category — almost always the right answer is to fit\n  into an existing one or to NOT build the skill.\n- **Massive Full reference, empty Overview.** Overview is what the\n  agent reads when it's actually doing work. Full reference is what the\n  agent reads when something goes wrong. Don't put core workflow in\n  Full reference.\n- **Skipping the assets layer.** If the skill produces a structured\n  artifact, ship the template under `assets\u002F` so the agent fills it in\n  instead of regenerating the structure each time.\n- **Including a `README.md` inside the skill folder.** Anthropic's\n  hard rule: no README.md inside a skill folder, including\n  subdirectories. Documentation goes in SKILL.md or references\u002F.\n  MCP server documentation goes in `mcp\u002FSERVER.md`, not\n  `mcp\u002FREADME.md`.\n- **Omitting the commands mention from SKILL.md Overview.** If the skill has\n  `commands\u002F` adapter files, the Overview section must reference them so agents\n  learn the commands exist from reading the skill — not only when the user\n  happens to type the slash. One sentence per command is enough.\n\n### Cross-references\n\n- `skill-reviewer` — for reviewing existing skills (brownfield)\n- `index-management` — call before creating to avoid duplicates\n- `event-log` — call after creating to log the new skill\n- `src\u002Fskills\u002FFORMAT.md` — the canonical format spec, always-current\n  source of truth for frontmatter fields and conventions\n- `src\u002Fskills\u002FINDEX.md` — the catalog index, lists every shipped skill\n",{"name":5,"metadata":49,"description":74},{"processkit":50},{"id":51,"uses":52,"layer":6,"created":59,"version":60,"category":61,"commands":62,"provides":67,"apiVersion":73},"SKILL-skill-builder",[53,56],{"skill":54,"purpose":55},"index-management","Query existing skills before creating a new one to surface duplicates and to find related skills the new one should reference under uses:.",{"skill":57,"purpose":58},"event-log","Log skill.created and skill.reviewed events so the project's audit trail captures when new skills enter the catalog.",1775606400000,"1.0.0","processkit",[63],{"args":64,"name":65,"description":66},"skill-topic","skill-builder-create","Start the interactive skill-creation workflow for a given topic",{"assets":68,"mcp_tools":69,"processes":70,"primitives":72},[30],[],[71],"skill-creation",[],"processkit.projectious.work\u002Fv1","Author a new processkit skill end-to-end — use-case interview, frontmatter, body sections, Gotchas, and trigger-phrase generation.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-builder","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":83,"prompt":93,"zipAvailable":94},[84,87,90],{"tool":85,"command":86},"npx","npx skills add projectious-work\u002Fprocesskit --skill skill-builder",{"tool":88,"command":89},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill skill-builder",{"tool":91,"command":92},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill skill-builder","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-builder\u002FSKILL.md",true,[96,102],{"path":97,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"assets\u002Fskill-template.md","ASSET","资产文件",2856,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-builder\u002Fassets\u002Fskill-template.md",{"path":103,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":106,"sourceHtmlUrl":107},"commands\u002Fpk-skill-new.md","REFERENCE","参考文档",138,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-builder\u002Fcommands\u002Fpk-skill-new.md",[109,131,150,168,185,203],{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":116,"publishedAt":44},"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",[115],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[117,118,43,119,120,121,39,122,123,124,111,125,126,127,128,129,130],"management","skill management","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":138,"publishedAt":44},"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",[137],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[117,139,140,141,142,143,121,39,144,145,123,146,26,147,125,148,149],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","deterministic","contract","mode",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":44},"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",[],[117,157,158,43,119,159,121,39,38,160,161,34,125,32,162,163,164,165,166,167],"proposition","proposition management","index","world","record","event","interface","updates","facts","claims","WSJF",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":44},"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",[],[117,124,175,43,121,176,177,144,178,38,123,179,180,125,181,182,162,183,128,184],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":191,"publishedAt":44},"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",[],[192,193,194,195,121,196,197,198,39,199,200,201,202],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":209,"publishedAt":44},"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",[],[117,210,211,43,119,159,121,176,39,122,38,212,123,161,125,182,162,163,213,130],"capability","capability management","queries","changes"]