菜单
Create a pull request on strapi/documentation following git-rules.md. Strict flat-text description, no headings, no test plan.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Top-level review orchestrator: runs style-check, outline-check, outline-ux-analyzer, code-verify, coherence-check, and pitfalls-check on a file, directory, or PR.
End-to-end documentation orchestrator: chains all four inki phases (research, write, review, submit) for a single subject. Gates between each phase by default; --non-interactive chains without pauses and runs a review-fix loop. The simplest way to document a subject from scratch.
Generate an outline for a new documentation page from a topic brief and the appropriate template.
Add a new entry to the known-pitfalls catalog that pitfalls-check audits against. Verifies the correct pattern against the Strapi source before adding, and confirms with the user. Use when you have found a documentation mistake worth catching automatically in future reviews.
Rewrite the title or description/body of one or more open PRs on strapi/documentation to match git-rules.md. Strict one-by-one confirmation, or auto-edit with --non-interactive.
Top-level orchestrator: branch (if needed), commit, push, then open a PR. Each step asks for confirmation before continuing, unless --non-interactive is passed.
| name | pr |
| description | Create a pull request on strapi/documentation following git-rules.md. Strict flat-text description, no headings, no test plan. |
| argument-hint | [optional issue reference, e.g. 'Fixes #2143'] |
| user-invocable | true |
Scope: designed for strapi/documentation (and its forks).
$ARGUMENTS: optional issue reference (e.g., Fixes #2143, #2143) or additional context.
Read and follow ../_shared/pr-rules.md for: gathering context, analyzing changes, generating the title (delegates to ../_shared/pr-title-rules.md), generating the description (delegates to ../_shared/pr-description-rules.md), showing the plan, and creating the PR.
Append a Vercel preview link as the last line of the PR body, in the form:
Direct preview link 👉 [here](<host><page-path>)
For example: https://documentation-git-cms-mcp-server-strapijs.vercel.app/cms/features/strapi-mcp-server
The link has two parts: the deployment host and the page path. Build the page path first, then the host.
Identify the primary page path from the changed files: the most important new or modified .md/.mdx file under docusaurus/docs/, stripped of the docusaurus/docs/ prefix and the .md/.mdx extension (e.g. docusaurus/docs/cms/features/users-permissions.md → /cms/features/users-permissions). Prefer a newly added page over a modified one.
When no page under docusaurus/docs/ is changed (for example a repo/ PR touching only claude-plugins/, config, or tooling), there is no doc page to preview: omit the preview line entirely rather than building a link to a page that does not exist. Do not fall back to the preview root. Skip the rest of this step.
Vercel deploys this branch to https://documentation-git-<slug>-strapijs.vercel.app, where <slug> is the branch name with / replaced by - (e.g. cms/mcp-server → cms-mcp-server). But Vercel truncates long branch slugs to fit the ~63-char DNS label and appends a short hash, so the slug-built host is only reliable for short branches. The full host (documentation-git- + slug + -strapijs) must fit in 63 chars, which leaves 35 characters for the slug.
Note that at PR-creation time the Vercel bot comment does not exist yet (Vercel reacts to the PR after it is opened, ~1-2 min later), so the real host with its hash cannot be read up front. Handle the two cases:
A. Short branch (slug ≤ 35 characters): the slug-built host is reliable. Use it directly:
https://documentation-git-<slug>-strapijs.vercel.app/<page-path>
Optionally verify with curl -s -o /dev/null -w '%{http_code}' -L --max-time 25 "<url>" (expect 200).
B. Long branch (slug > 35 characters): the slug-built host will be truncated and will not resolve. The real host is only known once Vercel posts its comment. After creating the PR (Step 3), poll for the Vercel bot comment, then edit the description:
gh pr view <num> --repo strapi/documentation --json comments \
-q '.comments[] | select(.author.login | test("vercel"; "i")) | .body' \
| grep -oE 'https://documentation-git-[a-z0-9-]+\.vercel\.app' | sort -u | head -1
<host>/<page-path>, verify it returns 200 with curl, and edit the PR description (gh pr edit <num> --repo strapi/documentation --body ...) to use the correct link.⚠️ The branch slug for this preview URL is <N> characters long (over the 35-character limit), so the URL above is likely truncated and incorrect. It must be fixed with `/inki:pr-fix` once Vercel has finished building the preview.
<N> is the actual slug length.Order note: the PR is created in Step 1 (via the shared PR rules). Build the preview link as part of the body you propose there, but case A's optional curl verification and case B's polling + description edit necessarily run after the PR exists.
If no upstream exists, suggest running /inki:push first.
This PR documents the new hasPublishedVersion parameter added in strapi/strapi#2847.
- Adds parameter to the findMany() parameters table
- Updates the filtering description
- Adds usage tip
Fixes #2143
This PR adds conditional retrieval rules to the Code Verifier and Coherence Checker agent prompts, and a new "separate facts from prose" behavioral note to the Drafter.