菜单
Guide for creating documentation. Use this when asked to create documentation for a new policy or modify existing documentation.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/wso2/gateway-controllers --skill doc-create命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
| name | doc-create |
| description | Guide for creating documentation. Use this when asked to create documentation for a new policy or modify existing documentation. |
Use this skill when the user asks to create new policy documentation or to migrate/update existing documentation so it follows the unified structure defined in DOC_STRUCTURE.md.
For a policy named <policy-name> and version folder v0.1, documentation MUST live under:
docs/<policy-name>/v0.1/metadata.jsondocs/<policy-name>/v0.1/docs/<policy-name>.mdNotes:
v0.1/ version folder).Create/update metadata.json using this exact shape:
{
"name": "<POLICY_NAME>",
"displayName": "<POLICY_DISPLAY_NAME>",
"version": "<POLICY_VERSION>",
"provider": "<PROVIDER_NAME>",
Conventions observed in this repo:
provider is typically WSO2.version is typically 0.1 for v0.1/ docs.All policy markdown docs MUST follow the structure in DOC_STRUCTURE.md.
Section inclusion rules:
Overview, Features, Configuration, Reference Scenarios.Use these headings (recommended canonical form):
---
title: "Overview"
---
# <Policy Display Name>
## Overview
## Features
## Configuration
### User Parameters (API Definition)
### System Parameters (From config.toml) <!-- Include only if system-level parameters exist -->
## Reference Scenarios
## How it Works
## Limitations
## Notes
## Related Policies
Rules:
Overview, Features, Configuration, Reference Scenarios.How it Works, Limitations, Notes, Related Policies.Features.Reference Scenarios.Configuration MUST include a build.yaml integration subsection showing the policy entry snippet.Every policy documentation MUST include a subsection under Configuration that shows what should be added under policies: in build.yaml, aligned with:
api-platform repository.build.yaml path: /gateway/build.yamlUse this format depending on the runtime (replace <policy-name>):
For Go policies:
- name: <policy-name>
gomodule: github.com/wso2/gateway-controllers/policies/<policy-name>@v0
For Python policies:
- name: <policy-name>
pipPackage: github.com/wso2/gateway-controllers/policies/<policy-name>@v0
Example (Go):
- name: add-headers
gomodule: github.com/wso2/gateway-controllers/policies/add-headers@v0
Example (Python):
- name: prompt-compressor
pipPackage: github.com/wso2/gateway-controllers/policies/prompt-compressor@v0
Follow these steps when the user asks to create docs for a policy that does not yet have documentation in the new structure.
<policy-name> (kebab-case)v0.1/ unless the user says otherwise)policies/<policy-name>/policy-definition.yaml.policies/<policy-name>/ (for example, main policy logic and key helpers/tests where needed) to understand actual behavior.docs/<policy-name>/v0.1/.metadata.json with the exact structure above.docs/<policy-name>.md using the strict structure:
Overview (what it does, when to use).Features.Configuration, document all parameters:
User Parameters (API Definition) (per-API/route)System Parameters (Comes from config.toml) (gateway-level) only if system-level parameters exist.build.yaml entry snippet under policies:.Reference Scenarios, include realistic, working examples.When documenting parameters, prefer this table format:
| Parameter | Type | Required | Default | Description |
|----------|------|----------|---------|-------------|
| ... | ... | ... | ... | ... |
Use yaml code blocks for API definition examples and toml for system config examples.
Follow these steps when the user asks to update older docs so they adhere to the new template.
docs/<policy-name>/....policies/<policy-name>/policy-definition.yaml.policies/<policy-name>/ to verify real behavior.Features section content from the original doc as-is unless the associated implementation has changed.Configuration as-is unless the associated implementation has changed.Reference Scenarios.Reference Scenarios.## Internal Architecture (or ## How It Works), create/use ## How it Works and migrate the content.## Best Practices, ## Security Considerations, ## Performance Considerations, or ## Troubleshooting, create ## Notes and merge the content.## Notes, include all useful points (best practices, security guidance, performance guidance, troubleshooting tips, caveats) and avoid dropping actionable details.Configuration includes the mandatory build.yaml policy entry snippet under policies:.| Old Section | Migration Action |
|---|---|
## Internal Architecture | Rename to ## How it Works |
## How It Works | Rename to ## How it Works |
## Use Cases | Merge into ## Reference Scenarios |
## Error Handling / ## Error Response | Move into ## Reference Scenarios |
## Request/Response Flow Examples | Merge into ## Reference Scenarios |
## Policy Behavior | Merge into ## Notes or ## How it Works |
## Best Practices | Merge into ## Notes |
## Security Considerations | Merge into ## Notes |
## Performance Considerations | Merge into ## Notes |
## Troubleshooting | Merge into ## Notes |
## System Configuration Example | Move into ## Configuration |
Standalone concept sections (e.g., ## JSONPath Support) | Move under ## Configuration |
Before finishing:
docs/<policy-name>/v0.1/docs/<policy-name>.md.docs/<policy-name>/v0.1/metadata.json exists and matches the required structure.policies/<policy-name>/policy-definition.yaml and relevant implementation files were reviewed before writing/updating documentation.Features, existing Configuration tables, and sample YAMLs were preserved unless implementation changes required updates.Configuration includes the mandatory build.yaml policy entry snippet under policies:.System Parameters (From/Comes from config.toml) is included only when system-level parameters exist.## Notes preserves all useful guidance merged from best-practice/security/performance/troubleshooting sections.