菜单
This skill should be used when the user asks to "look up docs for Polly", "find code examples for MediatR", "check FluentValidation setup", "verify library API usage", "how to configure Redis", or needs documentation or code snippets for any non-Microsoft third-party library.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when writing, editing, reviewing, restructuring, or deploying IntegratoR GitHub WIKI pages (the in-repo /wiki folder synced to <repo>.wiki.git) — tutorial, how-to/recipe, reference, concept/architecture, troubleshooting, release-notes, and hub prose. Enforces the code-first, one-Diataxis-mode-per-page, lean British-spelling house voice; the three-group IA (Get Started / Use Cases / Reference); Title-Case-hyphenated filenames + [Text](Slug) links; per-page "Last verified against vX" freshness stamps; rationed GitHub alert callouts; show-the-failure-path; and docs-in-lockstep-with-source grounding. Do NOT use for C# XML doc comments (see csharp-documentation) or README / CHANGELOG / ADRs.
Use when writing, reviewing, or refactoring C# in this repository — authoring a handler/service/entity/command/query, adding a test, or fixing a .cs file. Enforces IntegratoR's FluentResults Result<T> error model (never throw for business flow), async discipline (ConfigureAwait(false), CancellationToken), records-for-CQRS vs mutable-OData-entities, naming, file-scoped namespaces, British spelling (Behaviour), Central Package Management, and xUnit v3 + NSubstitute + FluentAssertions + TestKit assertions. Do NOT use for docs/wiki, JSON/config, PowerShell, or non-C# changes.
Use when writing, reviewing, trimming, or fixing CODE documentation in C# — XML doc comments (/// <summary>, <param>, <returns>, <typeparam>, <remarks>, <exception>, <inheritdoc>, <see>) and inline // comments. Enforces IntegratoR's lean-by-default doc philosophy (document the general logic concisely; inline only when truly necessary; no essays, no task/changelog narratives), 100% public coverage on packable libraries, BCL house wording, British spelling, the Result<T> failure-in-<returns> rule, and the ban on FILE-LEVEL banner comments. Do NOT use for wiki/README/architecture prose (see the /docs command) or non-C#.
Use when changing the public/published API of a NuGet-packable .NET library — adding, removing, renaming, or re-signing a public type or member; adding a parameter to an already-shipped public method; tightening what a public method accepts or changing its serialised/wire output; marking something [Obsolete]; or reviewing a PR for source, binary, or wire compatibility. Covers extend-only design, the three compatibility types, deprecation, and versioning. Do NOT use for internal-only code or an application/host with no published surface.
Use this skill AUTOMATICALLY whenever tests need to be written, planned, or reviewed — including when the user asks to "write tests", "add tests", "test this", or any variation that involves creating test code. This skill MUST run before the test-writer agent to ensure tests are planned properly, avoiding structural bloat and focusing on real behaviour. Trigger this skill when: the user asks to write, add, or create tests for any component; a new feature was implemented and needs test coverage; code was changed and you need to figure out which tests are affected; the user says "what tests do we need", "plan tests", "test strategy", "which tests break", "review test quality", "test coverage for", "write tests for", "add tests for", or any request involving test creation; after fixing a bug and needing to verify the fix is testable; when reviewing test suites for bloat or quality. This skill is the mandatory thinking step before any test writing — it produces the brief that the test-writer agent executes. Do NO
This skill should be used when the user asks to "find a code sample", "check if this method exists", "verify SDK method signature", "look up Azure SDK API", "troubleshoot an SDK error", or needs to verify Microsoft API references, find working code examples, or catch hallucinated methods and deprecated patterns.
| name | context7-docs |
| description | This skill should be used when the user asks to "look up docs for Polly", "find code examples for MediatR", "check FluentValidation setup", "verify library API usage", "how to configure Redis", or needs documentation or code snippets for any non-Microsoft third-party library. |
| version | 0.1.0 |
| context | fork |
Query up-to-date, version-specific documentation and code examples for any non-Microsoft library, framework, or package using the Context7 MCP server.
Prerequisite: Requires Context7 MCP Server (@upstash/context7-mcp).
| Use This Skill | Use Microsoft Skills Instead |
|---|---|
| Third-party libraries (MediatR, Polly, FluentValidation) | Azure SDKs (Azure.*, Microsoft.*) |
| Open-source frameworks (React, Express, Django) | .NET BCL and runtime APIs |
| Language ecosystems (npm, PyPI, NuGet non-Microsoft) | Microsoft Graph, Office 365 APIs |
| Infrastructure tools (Docker, Terraform, Redis) | Azure services documentation |
When a query involves both Microsoft and non-Microsoft libraries, use both skills to get complete coverage.
| Step | Tool | Purpose |
|---|---|---|
| 1 | mcp__context7__resolve-library-id | Resolve a package name to a Context7 library ID |
| 2 | mcp__context7__query-docs | Query documentation and code examples using the resolved ID |
Always resolve the library ID first. The query-docs tool requires an exact Context7-compatible library ID (format: /org/project).
resolve-library-id(
libraryName: "MediatR",
query: "CQRS command handler pipeline behaviour"
)
Selection criteria when multiple results appear:
query-docs(
libraryId: "/jbogard/mediatr",
query: "How to create a pipeline behaviour for validation"
)
Query tips for better results:
"retry policy with exponential backoff" not "retry""Polly v8 resilience pipeline" not "Polly retry""configure dependency injection for MediatR handlers" not "DI"resolve-library-id(libraryName: "Polly", query: "configure resilience pipeline with retry and circuit breaker")
query-docs(libraryId: "/<id-from-step-1>", query: "configure resilience pipeline retry circuit breaker dependency injection")
resolve-library-id(libraryName: "FluentValidation", query: "create custom validator with async rules")
query-docs(libraryId: "/<id-from-step-1>", query: "custom validator async validation rules example")
resolve-library-id(libraryName: "PanoramicData.OData.Client", query: "batch operations OData v4")
query-docs(libraryId: "/<id-from-step-1>", query: "batch create update operations OData v4 entities")
resolve-library-id(libraryName: "Polly", query: "migrate from Polly v7 to v8")
query-docs(libraryId: "/<id-from-step-1>", query: "migration guide v7 to v8 breaking changes")
Before generating code using third-party libraries, verify correctness:
resolve-library-id(libraryName: "[package]", query: "[specific need]")query-docs(libraryId: "/<id-from-step-1>", query: "[specific API or pattern]")For simple lookups, steps 1-2 suffice. For complex integrations or unfamiliar APIs, complete all three.
Always verify when:
| Need | Query Style |
|---|---|
| Setup/install | "getting started setup configuration" |
| Specific method | "[ClassName] [MethodName] parameters" |
| Pattern/recipe | "how to [task] with [library]" |
| Configuration | "configure [feature] options settings" |
| Error resolution | "[error message or type] troubleshooting" |
| Version-specific | "v[X] [feature] breaking changes" |
resolve-library-id per questionquery-docs per questionWhen Context7 returns insufficient results, fall back to web search or project-local documentation.
For detailed query patterns organised by library type and ecosystem:
references/query-patterns.md — Ecosystem-specific patterns for NuGet, npm, PyPI, and infrastructure tools. Includes IntegratoR-relevant library examples.