product-documentation

Full regression test of an existing article against the live portal. Use when articles may be stale and need end-to-end verification against the current portal UI before updating.

Add REST API coverage to an existing Customer Portal article with MethodSwitch and repository OpenAPI specs. Use when asked to add API coverage or create a REST API tab for a portal-only article.

Audit and update an existing documentation article by testing each step against the live Gcore portal. Use when asked to verify, audit, or fix an outdated article through portal testing.

Triage and work on a GitHub issue from G-Core/product-documentation one at a time. Use when the user asks to pick up an issue, work the issue queue, or gives an issue number or URL from https://github.com/G-Core/product-documentation/issues.

Write the opening paragraph(s) for a documentation tab or section. Use when adding or rewriting an intro for a MethodSection (Portal, REST API, Terraform, etc.) or any article section that needs a short lead-in.

Use this skill to triage and work on GitHub issues from G-Core/product-documentation one at a time. It fetches the issue via gh or GitHub API, checks whether the work is already on main, classifies the request, finds the affected MDX article, creates an issue/{number}-{slug} branch, routes to update-page, write-from-scratch, full-audit, or cookbook, and closes the loop with a PR that references Closes #N. Trigger when the user says "work on GitHub issues", "pick up issue #1845", "next issue from the queue", pastes a link to github.com/G-Core/product-documentation/issues/, or asks to start documentation work from the issue tracker. Use BEFORE loading other writing skills unless the user already completed triage. Do not use for Jira tickets (use jira-context instead).

Compile an end-to-end scenario guide that combines multiple Gcore products or sections into one article. Use when asked for a real-world guide spanning more than one product or section.

Draft documentation for new Gcore product features or product changes, research context, update or create the right article, and open a draft PR. Use when product teams provide feature context and want a documentation draft.

Create a draft GitHub pull request after documentation changes are complete. Use when the user confirms they want to open a PR.

Add a Terraform tab to an existing Portal + REST API article using the Gcore Terraform provider v2. Use when asked to add Terraform coverage to a cloud article that already has Portal and REST API tabs.

Update existing documentation when product, feature, or portal UI changes are provided. Use when the user describes changes and wants affected articles updated.

Write a new Gcore documentation article from source material such as a Jira brief, Confluence page, or direct description. Use when asked to create an article that does not exist yet.

Verify whether documented API articles need updates after a backend change ticket (migration, refactoring, version bump). Use when a Jira ticket describes backend changes to API handlers and the user asks to check if documentation is still accurate.

Write a new documentation article from scratch. Use when creating a new MDX file that does not yet exist in the repository.

Analyze a Jira ticket or Jira URL and produce a structured documentation brief. Use when asked to determine what documentation work is needed from Jira.

Adds a REST API tab as a MethodSection id api inside a MethodSwitch to an existing Customer Portal documentation article, mapping each Portal step to the matching endpoints from the product's OpenAPI spec in /api-reference/services_documented/. Use this skill when the user wants to give API coverage to a portal-only article or build the REST API side of a tabbed (Portal + API) article — for example "add an API tab to this article", "add API coverage to this guide", "write the REST API section for this page", "add a REST API method to this doc", "map these portal steps to API calls", or "show the API version of these steps". It reads the article, optionally runs live curl calls to verify responses, writes Python SDK / Go SDK / curl examples with quickstart and step-by-step sections, wraps content in MethodSwitch, and updates ai-navigation frontmatter. Do not use it to write a brand-new article from scratch or to audit an existing one — only to add the API method to an article that already exists.

Compiles an end-to-end, multi-product cookbook article that stitches together steps from several Gcore products into one unified scenario guide, with explicit cross-product handoffs and an expected-outcome section. Use this skill when the user asks to write a cookbook, a use-case guide, an end-to-end or integration walkthrough, or a "how to do X using A + B + C" article that spans more than one Gcore product or section (for example "set up live streaming with CDN and DDoS protection", "deploy Kubernetes with load balancing and object storage", "write a use case combining streaming and CDN", "create an end-to-end guide that connects these products"). It finds the relevant source articles across the repo, determines the correct setup sequence and dependencies, optionally verifies the flow end-to-end in the Customer Portal via Playwright, and writes the article following the cookbook template and style rules. Do not use it for documenting a single product feature (use update-page or write-from-scratch instead).

Turns a contributor's feature description into a documentation draft and opens a draft PR for a technical writer to review. Use this skill when a product team member or contributor (not a writer) provides context about a new feature, product change, or release and wants documentation written for them. Trigger on requests like "document this new feature", "draft docs for this Jira ticket", "create a draft article from this Confluence spec", or "turn this feature into a doc and open a PR". Also use when given a Jira ticket, Confluence link, feature description, or UI screenshots and asked for a draft. The skill gathers context, decides whether the change is documentable, finds an existing article or a new article path, optionally tests the feature in the portal, writes the draft, marks unverified claims with TODO, and opens a draft PR. Use for contributor first-drafts, not for auditing or polishing published articles.

Audits an existing documentation article by walking through every step against the live portal with Playwright, recording all discrepancies (wrong UI labels, changed navigation paths, reordered or missing steps, outdated screenshots, deprecated options), then fixing the article and running a mandatory style review. Use this skill when the user wants to verify, audit, test, or update an existing/outdated article by checking it in real conditions — e.g. "audit this article", "verify this doc against the portal", "this article is outdated, update it", "test these steps in the live portal", "check the screenshots are current", "the UI changed, fix the doc". Also use when a Jira ticket asks to update a specific article (the ticket adds required changes but the audit still covers the whole portal section). For writing a brand-new article from scratch, use write-from-scratch instead; for a small targeted edit to one page without portal verification, use update-page.

Use this skill to analyze a Jira ticket and produce a structured documentation brief: it fetches the ticket and any linked dev/Confluence pages, checks status, classifies whether the change is customer-facing (PUBLIC_PRODUCT_DOC, PUBLIC_TROUBLESHOOTING, BUG_FIX, INTERNAL_DOC, NOT_DOCUMENTABLE, INCIDENT_POSTMORTEM), finds the affected article, scores update complexity, and recommends the next skill. Trigger it whenever the user gives a Jira ticket ID or URL (especially a DOC-#### key) and asks what work is needed, for example "look at DOC-1234", "what does this ticket need", "should we document this ticket", "is this ticket documentable", "triage this Jira ticket", "what doc work does this require", or pastes a Jira link and asks to understand the change. Use it BEFORE writing or editing any article, since it only produces a brief and decides whether documentation work should happen at all. Do not use it to actually write or update docs (use update-page or write-from-scratch after).

Creates a draft GitHub pull request for documentation changes made in the current session. Use this skill at the very end of a docs workflow, after another skill (write a new doc, add an API tab, update an article, audit an article, or contributor feature draft) has finished and the user wants to ship the work. Trigger on phrases like "open a PR", "create a pull request", "raise a PR for these changes", "push this and make a draft PR", "submit my doc changes", "ship this article", or "let's get this reviewed". It checks gh and git auth, optionally starts a Mintlify local preview, derives the product name from the file path, creates a correctly named branch, stages only the session's files, commits with a [Product] message, pushes, and opens a draft PR (--base main --draft) with a What changed / Files changed / TODO body. Do not use it to make documentation edits — only to package finished work into a PR.

Updates an existing documentation article (.mdx) to reflect product, feature, or portal UI changes the user describes. Use this skill when the user reports that something changed and the docs are now outdated — for example "the button was renamed", "we added a new field/option", "this limit changed to X", "the setup flow has a new step", "the API got a new parameter", "update the docs for this UI change", "this article is out of date", or "fix the doc to match the new product". It finds the affected article(s) (searching the repo if no path is given), edits the relevant sections so the change reads naturally, optionally captures fresh portal screenshots via Playwright when UI changed and none were provided, validates MDX/frontmatter/style/links, and reports the changes. Use this for editing existing pages, not for writing a brand-new article from scratch and not for full content audits.

Writes a brand-new documentation article (.mdx) from scratch based on provided source material — a Jira ticket or brief, a Confluence page/URL, or a plain free-text description — following the project's content types, style guide, and MDX/frontmatter rules. Use this skill when the user wants to create a page that does not yet exist, with phrases like "write a new doc", "create a doc for this feature", "draft documentation from this Jira ticket", "turn this Confluence page into an article", "document this new API endpoint from scratch", or "write up a guide for X". It picks the article type, chooses the right structure, finds the file path and a reference article, drafts the content, marks unverified facts as TODO, verifies agent-added claims, and produces compliant frontmatter. Do not use it to edit, update, audit, or fix an existing article.