메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | write-from-scratch |
| description | 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. |
Write a new article from source material, following the correct structure for the article type and the project style guide.
.agents/references/content-types.md — article type decision and templates.agents/references/style-guide.md — writing rules.agents/references/procedures.md — step format, Optional prefix, location/purpose before action.agents/references/mdx-rules.md — MDX and frontmatter rules.agents/references/mcp-tools/confluence.md — only if fetching from Confluence.agents/references/mcp-tools/jira.md — only if fetching from Jira directlyDo not read more than two reference articles. Do not read articles from other product areas unless directly relevant.
| Input | Required | Notes |
|---|---|---|
| Topic or feature description | Yes | What the article is about |
| Source material | One of these | Jira brief, Confluence URL, or free-text description |
| Article type | No | If not specified, determine from content-types.md |
| Product area | No | If not specified, infer from topic |
If coming from jira-context skill — the brief from that skill is your source material.
Do not re-fetch the Jira ticket.
Collect everything needed to write accurately. Do not write from memory or assumptions.
If a jira-context brief was provided: Use it directly. The brief already contains what changed, which article, and scope of work.
If a Jira ticket ID is provided directly:
Fetch the ticket. Extract: summary, description, acceptance criteria, linked dev ticket.
Follow the instructions in .agents/references/mcp-tools/jira.md.
If a Confluence URL is provided:
Fetch the page. Look for: feature description, API fields, known limitations, screenshots.
Follow the instructions in .agents/references/mcp-tools/confluence.md.
Never copy Confluence text verbatim — use it to understand the feature, write in your own words.
If free-text description is provided: Use it as the primary source. Note what is known vs what needs verification.
For API content — check the OpenAPI spec:
Find the relevant YAML file in /api-reference/services_documented/{product}_api.yaml.
Verify field names, parameter types, and endpoint paths against the spec — not against
Confluence or memory.
Mark gaps: If important details are missing (exact field names, UI navigation path,
behavior in edge cases), note them as {TODO: verify X} inline in the draft.
Do not invent technical details.
Read .agents/references/content-types.md and answer two questions:
1. Does the feature have both Customer Portal UI and REST API coverage?
2. For articles with an API section — do the steps require sequential execution?
Rule of thumb:
If unsure — ask the user before writing.
Determine the file path:
/{product}/{section}/{article-name}.mdx
cloud, cdn, dns, waap, etc.)create-an-instance.mdx,
configure-firewall-rules.mdxFind one reference article: Look for an existing article of the same type in the same product folder:
ls {product}/{section}/*.mdx
Read it fully. Use it to understand:
Use the template from .agents/references/content-types.md for the article type
determined in Phase 2.
The first sentence must state what the reader will accomplish and why it matters. Never open with "This guide covers...", "This article explains...", or any description of the document itself.
Bad: "This guide covers creating a virtual machine using the Gcore Cloud API." Good: "Deploy a Linux virtual machine using the Gcore Cloud REST API — create SSH keys, select a flavor and image, and assign a floating IP address."
Before writing a section:
Follow the paragraph formulas in style-guide.md:
For <MethodSection id="portal">:
1. (not 1\.)<p> tags#### headings — use bold text for sub-labels{TODO: screenshot — [what it shows]}Always single-line Frame with Markdown image syntax:
<Frame></Frame>
Never use <img> tags with JSX style={{...}} inside <Frame>. Never multi-line Frame with indented content. Image path convention: /images/docs/{product}/{section}/{article-slug}/{name}.png.
Take screenshots with user-Playwright MCP, viewport 1400×900, save to the matching path under images/docs/ in the repository.
For <MethodSection id="api"> or standalone API articles:
Opening sentence (required, before the <Info> block):
Describe what this section enables. Not "The steps below...".
Good: "Create a subnet inside an existing network and customize its DHCP settings."
<Info> block (required):
<Info>
An [API token](/account-settings/api-tokens) is required, along with a
[project ID](...) and a [region ID](...).
</Info>
Tab order: always Python SDK → Go SDK → curl (curl always last). In Quickstart: Python SDK and Go SDK only — no curl tab.
Step anatomy (for Structure A sequential steps):
The API returns: label, then the response JSONQuickstart scripts:
# Step 1. / // Step 1. — never combine (# Step 3+4)# IDs are region-specific; selects 2 vCPU / 4 GB RAM
flavor = next(f for f in flavors if f.vcpus == 2 and f.ram == 4096)
When technical details cannot be verified from source material:
{TODO: verify — [what needs to be checked and where]}
Use for: exact UI navigation paths, field names not in the spec, behavior in edge cases, screenshot content.
Do not publish speculation as fact.
Before writing frontmatter, find everything you wrote that did NOT come directly from the provided source material.
The rule: if the contributor or source gave you the information — trust it and use it, even if it is not yet in Jira or Confluence. Verification only targets what you added through your own reasoning.
What counts as agent-added:
What does NOT need verification:
For each agent-added claim, check in order:
Use .agents/references/mcp-tools/jira.md and .agents/references/mcp-tools/confluence.md.
Decision:
| Situation | Action |
|---|---|
| Claim came from contributor or source | Keep it — no verification needed |
| Claim confirmed in Jira or Confluence | Keep it |
| Claim is your own reasoning, not found anywhere | {TODO: verify — added by agent, not confirmed in source} |
| Sources disagree | Use most authoritative (Confluence spec > ticket description), note the discrepancy |
When in doubt, ask yourself: "Where did I get this from?" If the answer is "I reasoned it" or "it seemed logical" — mark it as TODO.
Every article requires these fields:
---
title: [Full title — shown in browser tab]
sidebarTitle: [Short sidebar label]
ai-navigation: [One sentence, starts with action verb, max 160 chars, no {braces} or /slashes/]
---
Write ai-navigation last — after the article is complete, it is easier to
summarize accurately.
Check the rules in .agents/references/mdx-rules.md — curly braces and colons in
ai-navigation break the Mintlify build.
MDX:
.jsx extension: from "/snippets/method-switch.jsx"<MethodSwitch> wraps both sections, label is on <MethodSection><MethodSection> wrapped in <p> tags or proper list syntax{identifier} in inline backtick spans — use <code> with #### headings inside <MethodSection></MethodSection> tags at column 0 (not indented after a list)Frontmatter:
title presentai-navigation present, no forbidden charactersdescription fieldStyle:
## Prerequisites, ## Next steps, ## See also## heading followed by a prose sentence before code or tableShow the complete article content. Then:
File: [path]
Article type: [type from content-types.md]
Structure: [A — sequential / B — independent / N/A]
TODO items requiring verification:
- {TODO: ...} at Step N — [what to check]
- {TODO: ...} in [section] — [what to check]
Recommended next step:
- No TODOs → ready for review, create PR with skill pr
- Has portal TODOs → run skill full-audit to verify UI steps
- Has API TODOs → verify against API spec or test manually
When the user confirms the result looks good — load .agents/skills/pr/SKILL.md
to create the branch, commit, and open a draft PR.
Never use the word permanent when referring to API tokens. The expiration is user-controlled.
Always write: An [API token](/account-settings/api-tokens) is required.
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).