[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K58T2J3MKA5KYP8D2AP8N7":3,"skill-same:01M6K58T2J3MKA5KYP8D2AP8N7":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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6K58T2J3MKA5KYP8D2AP8N7","doc-maintenance",null,"Audit top-level documentation (README, SPEC, PRODUCT) against recent git history to find drift — shipped features missing from docs or features listed as upcoming that already landed. Proposes minimal edits, creates a branch, and opens a PR. Use when asked to review docs for accuracy, after major feature merges, or on a periodic schedule.","kangnam7654\u002Fstapler","kangnam7654","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F70181315?v=4","01M6K57VNJ3PFBHBRQNBTYTSJM","Kangnam Kim","01M6K57VT1NK9FARCSD23JGTMY",1,"MIT","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdoc-maintenance\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"doc maintenance","doc","maintenance","branch","features","for","top","as","feature","drift","review docs","README","review","schedule","history","audit","product","git","pr","documentation","2026-11-10 10:12:30",false,"---\nname: doc-maintenance\ndescription: >\n  Audit top-level documentation (README, SPEC, PRODUCT) against recent git\n  history to find drift — shipped features missing from docs or features\n  listed as upcoming that already landed. Proposes minimal edits, creates\n  a branch, and opens a PR. Use when asked to review docs for accuracy,\n  after major feature merges, or on a periodic schedule.\n---\n\n# Doc Maintenance Skill\n\nDetect documentation drift and fix it via PR — no rewrites, no churn.\n\n## When to Use\n\n- Periodic doc review (e.g. weekly or after releases)\n- After major feature merges\n- When asked \"are our docs up to date?\"\n- When asked to audit README \u002F SPEC \u002F PRODUCT accuracy\n\n## Target Documents\n\n| Document | Path | What matters |\n|----------|------|-------------|\n| README | `README.md` | Features table, roadmap, quickstart, \"what is\" accuracy, \"works with\" table |\n| SPEC | `doc\u002FSPEC.md` | No false \"not supported\" claims, major model\u002Fschema accuracy |\n| PRODUCT | `doc\u002FPRODUCT.md` | Core concepts, feature list, principles accuracy |\n\nOut of scope: DEVELOPING.md, DATABASE.md, CLI.md, doc\u002Fplans\u002F, skill files,\nrelease notes. These are dev-facing or ephemeral — lower risk of user-facing\nconfusion.\n\n## Workflow\n\n### Step 1 — Detect what changed\n\nFind the last review cursor:\n\n```bash\n# Read the last-reviewed commit SHA\nCURSOR_FILE=\".doc-review-cursor\"\nif [ -f \"$CURSOR_FILE\" ]; then\n  LAST_SHA=$(cat \"$CURSOR_FILE\" | head -1)\nelse\n  # First run: look back 60 days\n  LAST_SHA=$(git log --format=\"%H\" --after=\"60 days ago\" --reverse | head -1)\nfi\n```\n\nThen gather commits since the cursor:\n\n```bash\ngit log \"$LAST_SHA\"..HEAD --oneline --no-merges\n```\n\n### Step 2 — Classify changes\n\nScan commit messages and changed files. Categorize into:\n\n- **Feature** — new capabilities (keywords: `feat`, `add`, `implement`, `support`)\n- **Breaking** — removed\u002Frenamed things (keywords: `remove`, `breaking`, `drop`, `rename`)\n- **Structural** — new directories, config changes, new adapters, new CLI commands\n\n**Ignore:** refactors, test-only changes, CI config, dependency bumps, doc-only\nchanges, style\u002Fformatting commits. These don't affect doc accuracy.\n\nFor borderline cases, check the actual diff — a commit titled \"refactor: X\"\nthat adds a new public API is a feature.\n\n### Step 3 — Build a change summary\n\nProduce a concise list like:\n\n```\nSince last review (\u003Csha>, \u003Cdate>):\n- FEATURE: Plugin system merged (runtime, SDK, CLI, slots, event bridge)\n- FEATURE: Project archiving added\n- BREAKING: Removed legacy webhook adapter\n- STRUCTURAL: New .agents\u002Fskills\u002F directory convention\n```\n\nIf there are no notable changes, skip to Step 7 (update cursor and exit).\n\n### Step 4 — Audit each target doc\n\nFor each target document, read it fully and cross-reference against the change\nsummary. Check for:\n\n1. **False negatives** — major shipped features not mentioned at all\n2. **False positives** — features listed as \"coming soon\" \u002F \"roadmap\" \u002F \"planned\"\n   \u002F \"not supported\" \u002F \"TBD\" that already shipped\n3. **Quickstart accuracy** — install commands, prereqs, and startup instructions\n   still correct (README only)\n4. **Feature table accuracy** — does the features section reflect current\n   capabilities? (README only)\n5. **Works-with accuracy** — are supported adapters\u002Fintegrations listed correctly?\n\nUse `references\u002Faudit-checklist.md` as the structured checklist.\nUse `references\u002Fsection-map.md` to know where to look for each feature area.\n\n### Step 5 — Create branch and apply minimal edits\n\n```bash\n# Create a branch for the doc updates\nBRANCH=\"docs\u002Fmaintenance-$(date +%Y%m%d)\"\ngit checkout -b \"$BRANCH\"\n```\n\nApply **only** the edits needed to fix drift. Rules:\n\n- **Minimal patches only.** Fix inaccuracies, don't rewrite sections.\n- **Preserve voice and style.** Match the existing tone of each document.\n- **No cosmetic changes.** Don't fix typos, reformat tables, or reorganize\n  sections unless they're part of a factual fix.\n- **No new sections.** If a feature needs a whole new section, note it in the\n  PR description as a follow-up — don't add it in a maintenance pass.\n- **Roadmap items:** Move shipped features out of Roadmap. Add a brief mention\n  in the appropriate existing section if there isn't one already. Don't add\n  long descriptions.\n\n### Step 6 — Open a PR\n\nCommit the changes and open a PR:\n\n```bash\ngit add README.md doc\u002FSPEC.md doc\u002FPRODUCT.md .doc-review-cursor\ngit commit -m \"docs: update documentation for accuracy\n\n- [list each fix briefly]\n\nCo-Authored-By: Paperclip \u003Cnoreply@paperclip.ing>\"\n\ngit push -u origin \"$BRANCH\"\n\ngh pr create \\\n  --title \"docs: periodic documentation accuracy update\" \\\n  --body \"$(cat \u003C\u003C'EOF'\n## Summary\nAutomated doc maintenance pass. Fixes documentation drift detected since\nlast review.\n\n### Changes\n- [list each fix]\n\n### Change summary (since last review)\n- [list notable code changes that triggered doc updates]\n\n## Review notes\n- Only factual accuracy fixes — no style\u002Fcosmetic changes\n- Preserves existing voice and structure\n- Larger doc additions (new sections, tutorials) noted as follow-ups\n\n? Generated by doc-maintenance skill\nEOF\n)\"\n```\n\n### Step 7 — Update the cursor\n\nAfter a successful audit (whether or not edits were needed), update the cursor:\n\n```bash\ngit rev-parse HEAD > .doc-review-cursor\n```\n\nIf edits were made, this is already committed in the PR branch. If no edits\nwere needed, commit the cursor update to the current branch.\n\n## Change Classification Rules\n\n| Signal | Category | Doc update needed? |\n|--------|----------|-------------------|\n| `feat:`, `add`, `implement`, `support` in message | Feature | Yes if user-facing |\n| `remove`, `drop`, `breaking`, `!:` in message | Breaking | Yes |\n| New top-level directory or config file | Structural | Maybe |\n| `fix:`, `bugfix` | Fix | No (unless it changes behavior described in docs) |\n| `refactor:`, `chore:`, `ci:`, `test:` | Maintenance | No |\n| `docs:` | Doc change | No (already handled) |\n| Dependency bumps only | Maintenance | No |\n\n## Patch Style Guide\n\n- Fix the fact, not the prose\n- If removing a roadmap item, don't leave a gap — remove the bullet cleanly\n- If adding a feature mention, match the format of surrounding entries\n  (e.g. if features are in a table, add a table row)\n- Keep README changes especially minimal — it shouldn't churn often\n- For SPEC\u002FPRODUCT, prefer updating existing statements over adding new ones\n  (e.g. change \"not supported in V1\" to \"supported via X\" rather than adding\n  a new section)\n\n## Output\n\nWhen the skill completes, report:\n\n- How many commits were scanned\n- How many notable changes were found\n- How many doc edits were made (and to which files)\n- PR link (if edits were made)\n- Any follow-up items that need larger doc work\n","# Doc Maintenance Skill\n\nDetect documentation drift and fix it via PR — no rewrites, no churn.\n\n## When to Use\n\n- Periodic doc review (e.g. weekly or after releases)\n- After major feature merges\n- When asked \"are our docs up to date?\"\n- When asked to audit README \u002F SPEC \u002F PRODUCT accuracy\n\n## Target Documents\n\n| Document | Path | What matters |\n|----------|------|-------------|\n| README | `README.md` | Features table, roadmap, quickstart, \"what is\" accuracy, \"works with\" table |\n| SPEC | `doc\u002FSPEC.md` | No false \"not supported\" claims, major model\u002Fschema accuracy |\n| PRODUCT | `doc\u002FPRODUCT.md` | Core concepts, feature list, principles accuracy |\n\nOut of scope: DEVELOPING.md, DATABASE.md, CLI.md, doc\u002Fplans\u002F, skill files,\nrelease notes. These are dev-facing or ephemeral — lower risk of user-facing\nconfusion.\n\n## Workflow\n\n### Step 1 — Detect what changed\n\nFind the last review cursor:\n\n```bash\n# Read the last-reviewed commit SHA\nCURSOR_FILE=\".doc-review-cursor\"\nif [ -f \"$CURSOR_FILE\" ]; then\n  LAST_SHA=$(cat \"$CURSOR_FILE\" | head -1)\nelse\n  # First run: look back 60 days\n  LAST_SHA=$(git log --format=\"%H\" --after=\"60 days ago\" --reverse | head -1)\nfi\n```\n\nThen gather commits since the cursor:\n\n```bash\ngit log \"$LAST_SHA\"..HEAD --oneline --no-merges\n```\n\n### Step 2 — Classify changes\n\nScan commit messages and changed files. Categorize into:\n\n- **Feature** — new capabilities (keywords: `feat`, `add`, `implement`, `support`)\n- **Breaking** — removed\u002Frenamed things (keywords: `remove`, `breaking`, `drop`, `rename`)\n- **Structural** — new directories, config changes, new adapters, new CLI commands\n\n**Ignore:** refactors, test-only changes, CI config, dependency bumps, doc-only\nchanges, style\u002Fformatting commits. These don't affect doc accuracy.\n\nFor borderline cases, check the actual diff — a commit titled \"refactor: X\"\nthat adds a new public API is a feature.\n\n### Step 3 — Build a change summary\n\nProduce a concise list like:\n\n```\nSince last review (\u003Csha>, \u003Cdate>):\n- FEATURE: Plugin system merged (runtime, SDK, CLI, slots, event bridge)\n- FEATURE: Project archiving added\n- BREAKING: Removed legacy webhook adapter\n- STRUCTURAL: New .agents\u002Fskills\u002F directory convention\n```\n\nIf there are no notable changes, skip to Step 7 (update cursor and exit).\n\n### Step 4 — Audit each target doc\n\nFor each target document, read it fully and cross-reference against the change\nsummary. Check for:\n\n1. **False negatives** — major shipped features not mentioned at all\n2. **False positives** — features listed as \"coming soon\" \u002F \"roadmap\" \u002F \"planned\"\n   \u002F \"not supported\" \u002F \"TBD\" that already shipped\n3. **Quickstart accuracy** — install commands, prereqs, and startup instructions\n   still correct (README only)\n4. **Feature table accuracy** — does the features section reflect current\n   capabilities? (README only)\n5. **Works-with accuracy** — are supported adapters\u002Fintegrations listed correctly?\n\nUse `references\u002Faudit-checklist.md` as the structured checklist.\nUse `references\u002Fsection-map.md` to know where to look for each feature area.\n\n### Step 5 — Create branch and apply minimal edits\n\n```bash\n# Create a branch for the doc updates\nBRANCH=\"docs\u002Fmaintenance-$(date +%Y%m%d)\"\ngit checkout -b \"$BRANCH\"\n```\n\nApply **only** the edits needed to fix drift. Rules:\n\n- **Minimal patches only.** Fix inaccuracies, don't rewrite sections.\n- **Preserve voice and style.** Match the existing tone of each document.\n- **No cosmetic changes.** Don't fix typos, reformat tables, or reorganize\n  sections unless they're part of a factual fix.\n- **No new sections.** If a feature needs a whole new section, note it in the\n  PR description as a follow-up — don't add it in a maintenance pass.\n- **Roadmap items:** Move shipped features out of Roadmap. Add a brief mention\n  in the appropriate existing section if there isn't one already. Don't add\n  long descriptions.\n\n### Step 6 — Open a PR\n\nCommit the changes and open a PR:\n\n```bash\ngit add README.md doc\u002FSPEC.md doc\u002FPRODUCT.md .doc-review-cursor\ngit commit -m \"docs: update documentation for accuracy\n\n- [list each fix briefly]\n\nCo-Authored-By: Paperclip \u003Cnoreply@paperclip.ing>\"\n\ngit push -u origin \"$BRANCH\"\n\ngh pr create \\\n  --title \"docs: periodic documentation accuracy update\" \\\n  --body \"$(cat \u003C\u003C'EOF'\n## Summary\nAutomated doc maintenance pass. Fixes documentation drift detected since\nlast review.\n\n### Changes\n- [list each fix]\n\n### Change summary (since last review)\n- [list notable code changes that triggered doc updates]\n\n## Review notes\n- Only factual accuracy fixes — no style\u002Fcosmetic changes\n- Preserves existing voice and structure\n- Larger doc additions (new sections, tutorials) noted as follow-ups\n\n? Generated by doc-maintenance skill\nEOF\n)\"\n```\n\n### Step 7 — Update the cursor\n\nAfter a successful audit (whether or not edits were needed), update the cursor:\n\n```bash\ngit rev-parse HEAD > .doc-review-cursor\n```\n\nIf edits were made, this is already committed in the PR branch. If no edits\nwere needed, commit the cursor update to the current branch.\n\n## Change Classification Rules\n\n| Signal | Category | Doc update needed? |\n|--------|----------|-------------------|\n| `feat:`, `add`, `implement`, `support` in message | Feature | Yes if user-facing |\n| `remove`, `drop`, `breaking`, `!:` in message | Breaking | Yes |\n| New top-level directory or config file | Structural | Maybe |\n| `fix:`, `bugfix` | Fix | No (unless it changes behavior described in docs) |\n| `refactor:`, `chore:`, `ci:`, `test:` | Maintenance | No |\n| `docs:` | Doc change | No (already handled) |\n| Dependency bumps only | Maintenance | No |\n\n## Patch Style Guide\n\n- Fix the fact, not the prose\n- If removing a roadmap item, don't leave a gap — remove the bullet cleanly\n- If adding a feature mention, match the format of surrounding entries\n  (e.g. if features are in a table, add a table row)\n- Keep README changes especially minimal — it shouldn't churn often\n- For SPEC\u002FPRODUCT, prefer updating existing statements over adding new ones\n  (e.g. change \"not supported in V1\" to \"supported via X\" rather than adding\n  a new section)\n\n## Output\n\nWhen the skill completes, report:\n\n- How many commits were scanned\n- How many notable changes were found\n- How many doc edits were made (and to which files)\n- PR link (if edits were made)\n- Any follow-up items that need larger doc work\n",{"name":5,"description":7},"main","83f8367d44a638ab2f3cefa0eb4f2e55cf128411",".agents\u002Fskills\u002Fdoc-maintenance",0,"https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler","https:\u002F\u002Fgithub.com\u002Fkangnam7654","kangnam7654.github.io","AI Engineer","2026-04-21 01:56:05",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add kangnam7654\u002Fstapler --skill doc-maintenance",{"tool":59,"command":60},"bunx","bunx skills add kangnam7654\u002Fstapler --skill doc-maintenance",{"tool":62,"command":63},"pnpm","pnpm dlx skills add kangnam7654\u002Fstapler --skill doc-maintenance","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdoc-maintenance\u002FSKILL.md",true,[67,73],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Faudit-checklist.md","REFERENCE","参考文档",2720,"https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdoc-maintenance\u002Freferences\u002Faudit-checklist.md",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fsection-map.md",1410,"https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdoc-maintenance\u002Freferences\u002Fsection-map.md",[78,104,131,157,180,187],{"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":84,"publishedAt":39},"01M6K5BEQC9HE20WYMESKVC8FS","para-memory-files","File-based memory system using Tiago Forte's PARA method. Use this skill whenever you need to store, retrieve, update, or organize knowledge across sessions. Covers three memory layers: (1) Knowledge graph in PARA folders with atomic YAML facts, (2) Daily notes as raw timeline, (3) Tacit knowledge about user patterns. Also handles planning files, memory decay, weekly synthesis, and recall via qmd. Trigger on any memory operation: saving facts, writing daily notes, creating entities, running weekly synthesis, recalling past context, or managing plans.","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fskills\u002Fpara-memory-files\u002FSKILL.md",[],[85,86,87,88,89,90,91,92,93,26,94,95,96,97,98,99,100,101,102,103],"para","para memory files","files","memory","patterns","weekly","past","you","memory system","across","organize","weekly synthesis","context","knowledge","knowledge graph","graph","update","notes","writing",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":115,"publishedAt":39},"01M6K5BAA23289JDBBR8R1WSJN","paperclip","Interact with the Paperclip control plane API to manage tasks, coordinate with other agents, and follow company governance. Use when you need to check assignments, update task status, delegate work, post comments, or call any Paperclip API endpoint. Do NOT use for the actual domain work itself (writing code, research, etc.) — only for Paperclip coordination.","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fskills\u002Fpaperclip\u002FSKILL.md",[110],{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[106,116,92,117,118,119,120,121,122,123,124,125,126,127,128,24,129,130,103,101],"only","domain","update task","plane","coordinate","do","api endpoint","code","delegate","work","coordination","api","endpoint","tasks","status",{"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":137,"publishedAt":39},"01M6K5B48SE9AFAM77SEPJ8R5K","paperclip-create-plugin","Create new Paperclip plugins with the current alpha SDK\u002Fruntime. Use when scaffolding a plugin package, adding a new example plugin, or updating plugin authoring docs. Covers the supported worker\u002FUI surface, route conventions, scaffold flow, and verification steps.","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fskills\u002Fpaperclip-create-plugin\u002FSKILL.md",[],[138,139,140,106,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156],"create plugin","plugin","create","paperclip create plugin","worker","sdk","route","with","authoring","runtime","scaffolding","plugin authoring","example","use","flow","alpha","plugins","package","verification",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":164,"publishedAt":39},"01M6K5AZ86H1RMTNDC5XCYCEVE","paperclip-create-agent","Create new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt\u002Fconfig, and submit a hire request.","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fskills\u002Fpaperclip-create-agent\u002FSKILL.md",[163],{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},[165,106,140,166,167,168,169,92,145,170,171,172,173,174,175,151,176,177,178,179],"paperclip create agent","create agent","new agent","Existing","inspect","hire","compare","adapter","submit","draft","options","prompt","Hiring","governance","config",{"skillNo":181,"name":182,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":39},"01M6K5AVNJ2YWX6A4YB8RM0VNW","Workspace Skill","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fnative\u002Fskills-scanner\u002Ftests\u002Ffixtures\u002Fws_project_root\u002FSKILL.md",[],[182,186],"workspace",{"skillNo":188,"name":189,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":39},"01M6K5AQYTEY5GYM79GYVYKZDG","Inline Metadata Skill","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fnative\u002Fskills-scanner\u002Ftests\u002Ffixtures\u002Fws_inline_yaml\u002FSKILL.md",[],[189,193,194,106,195],"inline","metadata","github"]