chore: initialize skvlt manifest repository

2026-03-27 07:02:36 +08:00
commit 55eeff23a8
@@ -0,0 +1,2 @@
 # Auto detect text files and perform LF normalization
 * text=auto
@@ -0,0 +1,2 @@
 custom: https://xi-xu.me/#sponsorships
 buy_me_a_coffee: xixu
@@ -0,0 +1 @@
 AGENTS.md
@@ -0,0 +1,94 @@
 # AGENTS.md
 ## Project Overview
 This repository is a lightweight Agent Skills manifest repo.
 The primary artifact is `skvlt.yaml`, which tracks approved skill sources, installed skill names, and manifest counts.
 The main companion document is `MANIFEST_POLICY.md`, which defines how agents should decide whether to add, replace, reject, or escalate manifest changes.
 There is currently no application code, package manager, build pipeline, or automated test suite checked into this repository.
 ## Repository Layout
 - `skvlt.yaml` - source-of-truth manifest for installed skills
 - `MANIFEST_POLICY.md` - maintenance policy for agent-driven manifest changes
 - `LICENSE` - repository license
 ## Working Rules
 - Treat `skvlt.yaml` as the primary file.
 - Keep `MANIFEST_POLICY.md` aligned with actual maintenance behavior.
 - Prefer small, auditable edits over broad manifest churn.
 - Do not invent missing metadata about skills; inspect local skill files or trusted upstream sources first.
 - Do not add agent-specific, repo-specific, or runtime-bound skills unless the policy explicitly allows them.
 ## Manifest Editing Instructions
 When editing `skvlt.yaml`:
 1. Preserve the generated header comment if present.
 2. Keep `total_sources` equal to the number of source blocks.
 3. Keep `total_skills` equal to the sum of all per-source counts.
 4. Keep each source `count` equal to the number of listed skills in that block.
 5. Remove a source block entirely if its last skill is removed.
 6. Avoid duplicate skill names across the manifest.
 7. Prefer updating an existing trusted source block over adding a new source block.
 8. Treat source-level additions or removals as higher risk than skill-level additions or removals.
 ## Change Decision Rules
 Follow `MANIFEST_POLICY.md` before making substantive manifest changes.
 High-level defaults:
 - Add specialized or dependency-closing skills only when they fit an already trusted source.
 - Replace only when two general skills substantially overlap and the replacement is clearly better maintained or more authoritative.
 - Reject skills that are tightly bound to a specific agent, repository, or runtime unless explicitly approved.
 - Escalate ambiguous overlap, process-shaping changes, or source-level churn to a human.
 ## Validation
 There is no dedicated validation script in this repository today.
 Before claiming a manifest edit is complete, verify:
 - the YAML remains readable
 - the manifest counts are internally consistent
 - the edited source block count matches the listed skills
 - any dependency-based addition is actually justified by installed skills or policy
 Useful manual checks in PowerShell:
 ```powershell
 Get-Content -Raw skvlt.yaml
 ```
 ```powershell
 $lines = Get-Content skvlt.yaml
 $lines
 ```
 If you need upstream skill discovery, prefer checking the local installed skill files first, then use the relevant skills tooling or trusted upstream listing.
 ## Documentation Updates
 - Update `MANIFEST_POLICY.md` when maintenance behavior changes.
 - Update `AGENTS.md` when repository layout, validation steps, or working rules change.
 - Keep docs concise and operational; this repo does not need broad product documentation.
 ## Commit and Review Guidance
 - Keep commits focused on one manifest or documentation change at a time.
 - Mention the affected source or skill family in the commit message when possible.
 - Summarize why a skill was added, replaced, rejected, or escalated.
 - Call out count updates explicitly if `total_sources`, `total_skills`, or source `count` fields changed.
 ## Common Gotchas
 - Forgetting to update manifest counts after editing a source block
 - Leaving an empty source block behind after removing its last skill
 - Adding a skill dependency without adding the dependency itself
 - Treating a specialized skill as a duplicate of a general skill
 - Keeping a skill only because it exists locally, without checking whether it belongs in the manifest
@@ -0,0 +1 @@
 AGENTS.md
@@ -0,0 +1 @@
 AGENTS.md
@@ -0,0 +1,21 @@
 MIT License
 Copyright (c) 2026 Xi Xu
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
@@ -0,0 +1,321 @@
 # MANIFEST POLICY
 This document defines how agents should maintain the Agent Skills manifest at `skvlt.yaml`.
 It covers four outcomes:
 - addition
 - replacement
 - rejection
 - escalation to humans
 The policy is intentionally conservative because the manifest is global. A bad addition creates trigger noise everywhere, not just in one repository.
 ## Audience
 This policy is for:
 - agents proposing changes to `skvlt.yaml`
 - humans reviewing manifest changes
 - future automation that scans, scores, and patches the manifest
 ## Scope
 This policy applies to:
 - adding a skill to an existing source block
 - replacing one installed skill with another
 - rejecting candidate skills
 - escalating ambiguous or high-impact cases to humans
 - maintaining manifest integrity fields such as `total_sources`, `total_skills`, and per-source `count`
 This policy does not define:
 - how to install skills on disk
 - how to evaluate runtime correctness of a skill beyond metadata, prerequisites, and trigger scope
 - how to author new skills
 ## Operating Model
 Manifest maintenance should be split across small agent roles.
 ### Scout Agent
 Finds candidate additions, upstream updates, and removal opportunities from approved sources.
 ### Metadata Agent
 Extracts:
 - source repository
 - skill name
 - trigger description
 - explicit prerequisites
 - references to a specific agent, repository, or runtime
 - dependency skills
 - external API or paid service requirements
 - installation count
 - author trust signal
 - maintenance activity signal
 ### Taxonomy Agent
 Maps each skill to a task category such as:
 - browser automation
 - documentation authoring
 - Cloudflare development
 - LLM security
 - skill authoring
 - social research
 ### Comparator Agent
 Compares a candidate against installed skills in the same category.
 Its job is to answer:
 - Is this a general skill or a specialized skill?
 - Does it substantially overlap an installed skill's trigger scope?
 - If there is overlap, is it "general vs. general" or "general vs. specialized"?
 - Does it introduce new constraints that make it less portable?
 ### Decision Agent
 Returns exactly one outcome:
 - `add`
 - `replace`
 - `reject`
 - `escalate`
 ### Manifest Editor Agent
 Prepares the patch to `skvlt.yaml`, updates counts, and records the rationale.
 ### Human Reviewer
 Approves only escalated changes or batched high-impact changes.
 ## Core Principles
 ### 1. Conservative Global Bias
 `skvlt.yaml` is a global manifest. The default should be to avoid broad, noisy, or brittle skills unless they add clear value.
 ### 2. Trigger Overlap Matters
 Substantial similarity of task triggers means two skills occupy the same task category without a real capability distinction. Those should be treated as overlapping.
 ### 3. General and Specialized Can Coexist
 Do not force a trade-off between a broad general skill and a clearly narrower specialized skill.
 Trade-offs are required only when the comparison is effectively "general vs. general".
 ### 4. Trust and Maintenance Break Ties
 When trigger scope is the same, prefer:
 - official or domain-relevant authors
 - repositories with strong installation counts
 - active maintenance
 ### 5. Dependencies Must Close
 A skill should not be auto-added if it depends on another skill that is missing from the manifest, unless the same change adds the dependency or a human approves an exception.
 ## Decision Workflow
 1. The Scout Agent identifies a candidate.
 2. The Metadata Agent extracts the candidate's signals.
 3. The Taxonomy Agent places it into a task category.
 4. A hard exclusion pass runs first.
 5. The Comparator Agent evaluates overlap against installed skills in the same category.
 6. The Decision Agent chooses `add`, `replace`, `reject`, or `escalate`.
 7. If the decision is `add` or `replace`, the Manifest Editor Agent drafts a patch.
 8. If the decision is `escalate`, a human receives a short review packet.
 ## Hard Exclusion Rules
 The Decision Agent should immediately return `reject` when any of the following is true, unless the skill is explicitly whitelisted:
 - the skill is tightly bound to a specific agent
 - the skill assumes a specific repository context
 - the skill depends on a runtime or execution model that is outside the manifest's baseline
 - the skill's prerequisites cannot be satisfied from the current manifest or the same proposed patch
 - the trigger description is broad but the actual capability is narrow and misleading
 ## Action Policy
 ### Addition
 Return `add` only when all of the following are true:
 - the candidate survives hard exclusion
 - its task category is already allowed in the manifest
 - it is either specialized or genuinely non-overlapping
 - its dependencies close cleanly
 - it does not introduce broad trigger ambiguity
 Typical examples:
 - adding a specialized companion skill under an already trusted source
 - adding a dependency skill already referenced by installed skills
 ### Replacement
 Return `replace` only when all of the following are true:
 - the candidate and incumbent are both general skills
 - their trigger scopes are substantially similar
 - the candidate is at least as portable as the incumbent
 - the candidate wins clearly on trust and maintenance signals
 - there is no meaningful capability loss
 Replacement should not be used for "general vs. specialized" comparisons.
 ### Rejection
 Return `reject` when any of the following is true:
 - the skill is bound to a specific agent, repository, or runtime
 - it is a weaker duplicate of an installed general skill
 - it creates dependency debt
 - it adds noise without adding distinct capability
 - it loses a tie-break on trust and maintenance
 ### Escalation
 Return `escalate` when the case is not safely automatable.
 Escalation is required when:
 - the overlap judgment depends on interpretation rather than clear capability boundaries
 - the change adds a brand-new source block
 - the change removes the last skill from a source block
 - the candidate introduces external auth, paid APIs, or unusual runtime assumptions
 - official-status and install-count signals disagree
 - the skill shapes broad workflow behavior across many tasks
 ## Scoring Rubric
 Use the scoring rubric only after the hard exclusion pass.
 ### Positive Signals
 - `+3` clear specialization with distinct capability
 - `+2` official or strongly domain-relevant author
 - `+2` active maintenance
 - `+2` strong installation signal
 - `+2` dependency closure is already satisfied
 - `+1` complements an already trusted source
 ### Negative Signals
 - `-3` vague or noisy trigger wording
 - `-3` external service requirement that is not already normal for the manifest
 - `-4` missing dependency
 - `-4` portability concerns
 ### Hard Stop
 - `reject immediately` for explicit agent / repo / runtime binding unless whitelisted
 ### Decision Bands
 - `score >= 5`: eligible for `add` if no overlap concerns remain
 - `score 2 to 4`: prefer `escalate`
 - `score <= 1`: prefer `reject`
 For `replace`, compare candidate score against incumbent score. Auto-replace only when the candidate is ahead by at least `3` points and no escalation condition is present.
 ## Human Escalation Packet
 When escalation is required, provide a short packet with:
 - candidate skill
 - source repository
 - task category
 - incumbent skill, if any
 - overlap summary
 - binding and dependency notes
 - trust and maintenance comparison
 - recommended action
 - confidence level
 ## Manifest Invariants
 Every accepted patch must preserve the following:
 - `total_sources` matches the number of source blocks
 - `total_skills` matches the sum of per-source counts
 - each source `count` matches the number of listed skills
 - no duplicate skill names appear in the manifest
 - no hard-reject skill is present unless explicitly whitelisted
 - dependency exceptions are documented in the review note
 ## Change Classes
 Treat these classes differently:
 ### Safe to Automate
 - adding a skill to an existing trusted source
 - adding a missing dependency that is already referenced by installed skills
 - replacing a low-trust general skill with a clearly better general skill
 ### Must Escalate
 - new source added
 - source removed
 - process-shaping skill added, removed, or replaced
 - ambiguous overlap between two broad general skills
 - any change that would alter maintenance policy itself
 ## Recommended Cadence
 ### Weekly
 - scout for new candidates in already approved sources
 - check for dependency gaps and broken references
 ### Monthly
 - review overlapping general skills
 - re-evaluate trust and maintenance signals
 ### Quarterly
 - review category taxonomy
 - review source allowlist
 - review any existing whitelists for otherwise excluded skills
 ## Output Format for Agents
 Every maintenance run should emit a compact decision log.
 Recommended fields:
 ```json
 {
  "candidate": "nanobanana",
  "source": "resciencelab/opc-skills",
  "category": "image generation",
  "incumbent": null,
  "action": "add",
  "reason": "dependency closure for installed skills",
  "confidence": 0.91,
  "needs_human": false
 }
 ```
 ## Current Manifest Guidance
 For the current `skvlt.yaml`:
 - broad workflow skills should be treated as high-impact
 - source-level edits should escalate more readily than skill-level edits
 - dependency-completion additions inside an existing trusted source can be auto-approved
 This means a change like "add a missing dependency skill under an existing source" is lower risk than "replace a broad browser automation skill family" or "swap out a process-shaping skill".
@@ -0,0 +1,102 @@
 # skvlt
 **_[汉语](./README.zh.md)_**
 This repository is organized around a single-file Agent Skills manifest, [`skvlt.yaml`](./skvlt.yaml), for [Skills Vault](https://github.com/xixu-me/skills-vault).
 It is intended for people who want a reviewed, portable snapshot of approved skill sources and installed skill names.
 ## Repository Contents
 - [`skvlt.yaml`](./skvlt.yaml): the source-of-truth manifest
 - [`MANIFEST_POLICY.md`](./MANIFEST_POLICY.md): the agent-facing policy for additions, replacements, rejections, and escalations
 > [!IMPORTANT]
 > In normal use, manifest changes are proposed and applied by agents following the policy.
 ## Manifest Overview
 The manifest records:
 - approved upstream skill sources
 - installed skill names under each source
 - integrity fields such as `total_sources`, `total_skills`, and per-source `count`
 - the current manifest scope, `global`
 Minimal example:
 ```yaml
 total_sources: 21
 total_skills: 137
 scope: "global"
 sources:
  "openai/skills":
    count: 27
    skills:
      - "openai-docs"
      - "slides"
      - "sentry"
 ```
 Today, the manifest covers a broad set of real-world development tasks, including general engineering workflows, AI, cloud platforms, security, testing, documentation, design, deployment, and research-oriented work.
 It is especially useful for:
 - developers working across a wide range of modern software tasks
 - teams that want a shared, reviewed skills baseline across domains
 - Skills Vault users who do not want to assemble trusted sources one by one
 ## Using It With Skills Vault
 This repository is a maintained manifest source intended to be used with Skills Vault.
 Recommended workflow:
 1. [Fork this repository](https://github.com/xixu-me/skvlt/fork) and clone it.
 2. Run the restore flow through Skills Vault.
 Example:
 ```bash
 git clone https://github.com/<your-username>/skvlt.git
 cd skvlt
 bunx skvlt restore --all
 ```
 This repository is not a standalone installer. Its role is to provide a maintained manifest for the Skills Vault toolchain.
 > [!IMPORTANT]
 > This repository is meant to be used with Skills Vault. Standalone use outside the Skills Vault workflow is not considered a supported primary workflow.
 ## Change Policy
 Because this manifest is global rather than project-specific, changes are handled conservatively.
 High-level rules include:
 - prefer small, auditable changes
 - prefer adding skills under existing trusted sources over introducing source churn
 - reject skills tied to a specific repository, agent, or runtime unless explicitly allowed
 - escalate ambiguous overlap, process-shaping changes, and source-level edits to a human reviewer
 See [`MANIFEST_POLICY.md`](./MANIFEST_POLICY.md) for the complete decision model.
 ## Updating The Manifest Through Agents
 In most cases, manifest changes should be requested through an agent rather than edited directly in [`skvlt.yaml`](./skvlt.yaml).
 Recommended flow:
 1. [Fork this repository](https://github.com/xixu-me/skvlt/fork) and clone it.
 2. Give an agent access to the cloned repository and request a manifest change.
 3. Provide the candidate skill or source and the change you want.
 4. Let the agent evaluate the request against [`MANIFEST_POLICY.md`](./MANIFEST_POLICY.md) and prepare a patch if the change is justified.
 5. Review the agent's rationale and diff before accepting the change.
 6. Commit the result.
 If the case is ambiguous, high-impact, or source-level, the agent should normally escalate to a human instead of applying the change automatically.
 ## License
 Released under the MIT License. See [`LICENSE`](./LICENSE) for details.
@@ -0,0 +1,102 @@
 # skvlt
 **_[English](./README.md)_**
 这是一个围绕单个文件 [Skills Vault](https://github.com/xixu-me/skills-vault) 的 Agent Skills 清单 [`skvlt.yaml`](./skvlt.yaml) 组织的存储库。
 它适合希望获得一份经过审阅、可移植的已批准 skills 的来源与 skills 的名称快照的用户。
 ## 存储库内容
 - [`skvlt.yaml`](./skvlt.yaml)：唯一事实来源的清单文件
 - [`MANIFEST_POLICY.md`](./MANIFEST_POLICY.md)：面向智能体的清单变更决策策略，用于处理新增、替换、拒绝或需要进一步请人类确认的情况
 > [!IMPORTANT]
 > 一般情况下，清单变更通过智能体按照策略提出和应用。
 ## 清单概览
 这份清单记录了：
 - 已批准的上游 skills 的来源
 - 每个来源下包含的 skills 的名称
 - `total_sources`、`total_skills`、每个来源的 `count` 等统计字段
 - 当前的清单作用域 `global`
 精简示例：
 ```yaml
 total_sources: 21
 total_skills: 137
 scope: "global"
 sources:
  "openai/skills":
    count: 27
    skills:
      - "openai-docs"
      - "slides"
      - "sentry"
 ```
 目前，这份清单覆盖了较广的实际开发场景，从通用工程工作流到 AI、云平台、安全、测试、文档、设计、部署与研究型任务都有覆盖。
 它尤其适合：
 - 面向广泛现代开发场景工作的开发者
 - 希望在多个领域共享一份经过审阅的 skills 基线的团队
 - 使用 Skills Vault 且不想手动逐个拼装来源的用户
 ## 配合 Skills Vault 使用
 本存储库是 Skills Vault 推荐的一份受维护的清单来源。
 推荐工作流：
 1. [fork 本存储库](https://github.com/xixu-me/skvlt/fork)并克隆。
 2. 通过 Skills Vault 执行恢复流程。
 示例：
 ```bash
 git clone https://github.com/<your-username>/skvlt.git
 cd skvlt
 bunx skvlt restore --all
 ```
 本存储库本身不是独立安装器。它的作用是为 Skills Vault 工具链提供一份持续维护的清单。
 > [!IMPORTANT]
 > 本存储库只能配合 Skills Vault 使用。不支持脱离 Skills Vault 的独立使用方式，也不将临时手工使用视为正式工作流。
 ## 变更策略
 由于这份清单面向的是全局 skills 集合，而不是单个项目，所以这里对变更采取保守策略。
 高层规则包括：
 - 优先做小而可审计的变更
 - 相比新增来源，更优先在已信任的来源块内增补 skills 条目
 - 默认拒绝绑定特定存储库或特定运行时的 skills 条目，除非有明确允许
 - 对重叠判断不清晰、会改变流程形态或涉及来源级变更的情况，通常需要进一步请人类确认
 完整决策模型见 [`MANIFEST_POLICY.md`](./MANIFEST_POLICY.md)。
 ## 如何通过智能体变更清单
 一般情况下，应当通过智能体提出清单变更请求，而不是直接手改 [`skvlt.yaml`](./skvlt.yaml)。
 推荐流程：
 1. [fork 本存储库](https://github.com/xixu-me/skvlt/fork)并克隆。
 2. 使智能体可以访问克隆的存储库，并在其中提出清单变更请求。
 3. 说明候选的 skills 条目或来源、希望做什么调整。
 4. 智能体自动依据 [`MANIFEST_POLICY.md`](./MANIFEST_POLICY.md) 评估请求；如果变更成立，再由它准备补丁。
 5. 在接受变更前，先审阅智能体给出的理由和 diff。
 6. 提交变更。
 如果变更存在歧义、影响面较大，或者涉及来源级调整，智能体通常会先请人类确认，而不是自动落地。
 ## 许可证
 采用 MIT 许可证。详见 [`LICENSE`](./LICENSE)。
@@ -0,0 +1,226 @@
 # Generated by Skills Vault: https://github.com/xixu-me/skills-vault
 total_sources: 21
 total_skills: 137
 scope: "global"
 sources:
  "anthropics/skills":
    count: 11
    skills:
      - "algorithmic-art"
      - "canvas-design"
      - "doc-coauthoring"
      - "docx"
      - "mcp-builder"
      - "pdf"
      - "skill-creator"
      - "slack-gif-creator"
      - "theme-factory"
      - "webapp-testing"
      - "xlsx"
  "blader/humanizer":
    count: 1
    skills:
      - "humanizer"
  "callstackincubator/agent-skills":
    count: 5
    skills:
      - "github"
      - "react-native-best-practices"
      - "react-native-brownfield-migration"
      - "upgrading-react-native"
      - "validate-skills"
  "chromedevtools/chrome-devtools-mcp":
    count: 4
    skills:
      - "a11y-debugging"
      - "chrome-devtools"
      - "debug-optimize-lcp"
      - "troubleshooting"
  "cloudflare/skills":
    count: 8
    skills:
      - "agents-sdk"
      - "building-mcp-server-on-cloudflare"
      - "cloudflare"
      - "durable-objects"
      - "sandbox-sdk"
      - "web-perf"
      - "workers-best-practices"
      - "wrangler"
  "github/awesome-copilot":
    count: 19
    skills:
      - "agent-governance"
      - "agentic-eval"
      - "automate-this"
      - "cloud-design-patterns"
      - "codeql"
      - "create-agentsmd"
      - "create-architectural-decision-record"
      - "create-readme"
      - "dependabot"
      - "documentation-writer"
      - "doublecheck"
      - "editorconfig"
      - "git-commit"
      - "github-issues"
      - "mcp-cli"
      - "publish-to-pages"
      - "python-mcp-server-generator"
      - "refactor"
      - "secret-scanning"
  "huggingface/skills":
    count: 11
    skills:
      - "hf-cli"
      - "huggingface-community-evals"
      - "huggingface-datasets"
      - "huggingface-gradio"
      - "huggingface-jobs"
      - "huggingface-llm-trainer"
      - "huggingface-paper-publisher"
      - "huggingface-papers"
      - "huggingface-trackio"
      - "huggingface-vision-trainer"
      - "transformers-js"
  "langchain-ai/langchain-skills":
    count: 11
    skills:
      - "deep-agents-core"
      - "deep-agents-memory"
      - "deep-agents-orchestration"
      - "framework-selection"
      - "langchain-dependencies"
      - "langchain-fundamentals"
      - "langchain-middleware"
      - "langchain-rag"
      - "langgraph-fundamentals"
      - "langgraph-human-in-the-loop"
      - "langgraph-persistence"
  "makenotion/skills":
    count: 1
    skills:
      - "notion-cli"
  "obra/superpowers":
    count: 14
    skills:
      - "brainstorming"
      - "dispatching-parallel-agents"
      - "executing-plans"
      - "finishing-a-development-branch"
      - "receiving-code-review"
      - "requesting-code-review"
      - "subagent-driven-development"
      - "systematic-debugging"
      - "test-driven-development"
      - "using-git-worktrees"
      - "using-superpowers"
      - "verification-before-completion"
      - "writing-plans"
      - "writing-skills"
  "openai/skills":
    count: 27
    skills:
      - "aspnet-core"
      - "chatgpt-apps"
      - "develop-web-game"
      - "figma"
      - "frontend-skill"
      - "gh-address-comments"
      - "gh-fix-ci"
      - "imagegen"
      - "jupyter-notebook"
      - "linear"
      - "netlify-deploy"
      - "notion-knowledge-capture"
      - "notion-meeting-intelligence"
      - "notion-research-documentation"
      - "notion-spec-to-implementation"
      - "openai-docs"
      - "playwright-interactive"
      - "render-deploy"
      - "screenshot"
      - "security-ownership-map"
      - "security-threat-model"
      - "sentry"
      - "slides"
      - "sora"
      - "speech"
      - "transcribe"
      - "winui-app"
  "redis/agent-skills":
    count: 1
    skills:
      - "redis-development"
  "remotion-dev/skills":
    count: 1
    skills:
      - "remotion-best-practices"
  "resciencelab/opc-skills":
    count: 10
    skills:
      - "archive"
      - "banner-creator"
      - "domain-hunter"
      - "logo-creator"
      - "nanobanana"
      - "producthunt"
      - "reddit"
      - "requesthunt"
      - "seo-geo"
      - "twitter"
  "semgrep/skills":
    count: 3
    skills:
      - "code-security"
      - "llm-security"
      - "semgrep"
  "supabase/agent-skills":
    count: 1
    skills:
      - "supabase-postgres-best-practices"
  "upstash/context7":
    count: 1
    skills:
      - "context7-mcp"
  "vercel-labs/agent-browser":
    count: 2
    skills:
      - "dogfood"
      - "electron"
  "vercel-labs/agent-skills":
    count: 4
    skills:
      - "deploy-to-vercel"
      - "vercel-composition-patterns"
      - "vercel-react-best-practices"
      - "web-design-guidelines"
  "xixu-me/xdrop":
    count: 1
    skills:
      - "xdrop"
  "xixu-me/xget":
    count: 1
    skills:
      - "xget"
		`@@ -0,0 +1,2 @@`
							`# Auto detect text files and perform LF normalization`
							`* text=auto`
		`@@ -0,0 +1,2 @@`
							`custom: https://xi-xu.me/#sponsorships`
							`buy_me_a_coffee: xixu`