write-fluentcommunity-doc

스타1

포크0

업데이트2026년 7월 16일 03:19

Create a NEW FluentCommunity end-user documentation page in this VitePress site, correctly placed in a section folder, wired into the hand-maintained sidebar in .vitepress/config.mts, with its image folder created and a clean build. USE FOR: add a doc, write a new doc page, create a guide for X, document this feature, scaffold a new article, turn these notes into a doc page. DO NOT USE FOR: editing an existing page (use edit-fluentcommunity-doc), renaming/moving/deleting/reordering pages (use restructure-fluentcommunity-docs), site-wide quality checks (use audit-fluentcommunity-docs), or non-doc markdown like README.md / CLAUDE.md.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

WPManageNinja

WPManageNinja/fluent-community-user-docs

GitHub 저장소 열기 Creator 저장소 보기

다운로드

관련 직업SOC

SOC 직업 분류 기준

웹 개발자컴퓨터 및 수학직·SOC 15-1254

SKILL.md

readonly

이 저장소의 다른 Skills

같은 저장소

audit-fluentcommunity-docs

WPManageNinja/fluent-community-user-docs

Read-only quality gate for the FluentCommunity docs site: run the production build, catch dead internal links, and scan for this repo's known content issues (unresolved [Screenshot: ...] placeholders, missing frontmatter descriptions, mangled acronym titles, remote-hosted images). Produces a ✅/⚠️/❌ report and proposes fixes but does NOT apply them. USE FOR: audit the docs, quality check, find broken links, what needs fixing, pre-release check, lint the docs. DO NOT USE FOR: creating a page (use write-fluentcommunity-doc), editing/fixing a specific page (use edit-fluentcommunity-doc), or renaming/moving/deleting pages (use restructure-fluentcommunity-docs).

2026-07-161

edit-fluentcommunity-doc

WPManageNinja/fluent-community-user-docs

Edit the content of an EXISTING FluentCommunity doc page in place — rewrite/expand/correct prose, add sections, swap in real screenshots, fix frontmatter — without moving, renaming, or deleting the file. Applies this repo house style and fixes known content issues as it goes. USE FOR: update this doc, revise/expand a page, fix wording, add a section, replace a [Screenshot: ...] placeholder, add a missing description, correct a mangled title. DO NOT USE FOR: creating a new page (use write-fluentcommunity-doc), renaming/moving/deleting/reordering pages (use restructure-fluentcommunity-docs), or a read-only site-wide audit (use audit-fluentcommunity-docs).

2026-07-161

restructure-fluentcommunity-docs

WPManageNinja/fluent-community-user-docs

Rename, move, delete, merge, or reorder FluentCommunity doc pages while keeping the markdown file, its image folder, the sidebar in .vitepress/config.mts, and every inbound cross-link in sync. USE FOR: rename a page, change a slug/URL, move a page to another section, delete/remove a page, merge two pages, reorder the sidebar, regroup pages, add or collapse a sidebar sub-group. DO NOT USE FOR: creating a brand-new page (use write-fluentcommunity-doc), editing the prose/content of a page that stays put (use edit-fluentcommunity-doc), or a read-only audit (use audit-fluentcommunity-docs).

2026-07-161

name	write-fluentcommunity-doc
description	Create a NEW FluentCommunity end-user documentation page in this VitePress site, correctly placed in a section folder, wired into the hand-maintained sidebar in .vitepress/config.mts, with its image folder created and a clean build. USE FOR: add a doc, write a new doc page, create a guide for X, document this feature, scaffold a new article, turn these notes into a doc page. DO NOT USE FOR: editing an existing page (use edit-fluentcommunity-doc), renaming/moving/deleting/reordering pages (use restructure-fluentcommunity-docs), site-wide quality checks (use audit-fluentcommunity-docs), or non-doc markdown like README.md / CLAUDE.md.
license	MIT
compatibility	VitePress repo. Content at docs/<section>/<slug>.md served at /<section>/<slug> via cleanUrls. Sidebar inline in .vitepress/config.mts (themeConfig.sidebar). Images at docs/public/images/<section>/<article-slug>/ as .webp. Requires Node + npm (vitepress).
metadata	{"project":"fluent-community-user-docs","canonical-rules":"CLAUDE.md"}

Write a FluentCommunity Doc

Create one new documentation page end-to-end: place it in the right section folder, write it in the house style, set up its image folder, wire it into .vitepress/config.mts, and verify with a clean build. Adding a page is a 3-place operation — the markdown file, the image folder, and the sidebar entry must all be created or the page is orphaned or 404s.

Agent Behavior Rules

DO complete Phase 1 setup and confirm the summary table before writing anything.
DO place the file at docs/<section>/<slug>.md (never at the repo root or docs/ root).
DO give it exactly two frontmatter fields — title and description — then a single # H1 on the first line after the frontmatter that matches title.
DO fix acronym casing in title/H1: write REST API, FluentCRM, FluentCommunity, CDN, S3, R2, SEO, URL — never Rest Api, Fluentcrm, Cdn.
DO use house-style blockquote callouts (see Quick Reference), not native ::: containers, unless the user asks otherwise.
DO reference images as root-absolute .webp: ![real descriptive alt](/images/<section>/<slug>/<file>.webp). Never use <img> tags or filename-as-alt.
DO write internal cross-links as relative links that keep .md: [text](./other.md) same-folder, [text](../section/other.md) cross-folder.
DO add the page to .vitepress/config.mts under the correct sidebar group; the sidebar link is /<section>/<slug> without .md.
DO mark Pro-only features (Pro) in the title/H1, body, and sidebar text; keep the filename/folder lowercase (pro).
DO end on a green npm run docs:build.
DO NOT invent a new section folder or sidebar group without asking the user.
DO NOT leave [Screenshot: ...] placeholders unless the user has no image yet — if you must, flag them in the final report.
DO NOT write inner-whitespace bold (** term **) — use **term**.
DO NOT commit, push, or change existing pages' URLs.

Phase 1: Setup (Interactive)

Ask the user for each item. Do not assume.

Title — becomes the # H1 and the sidebar label. Record as TITLE.

Section folder — show the options and pick one:

ls docs/    # community-hub, courses-&-learning-(pro), files-&-media-storage,
            # for-developers, gamification-(pro), getting-started, help-&-resources,
            # integrations, migration, monetization, portal-settings

Record as SECTION.

Slug — kebab-case; literally keep &, (pro), () and match the phrasing of sibling files (e.g. add-custom-links-(pro), space-settings-&-privacy). Record as SLUG.
Sidebar group — open .vitepress/config.mts and identify the top-level group (and nested collapsed: true sub-group, if any) this page belongs under. Record as GROUP.
Pro? — is this a Pro-plan feature? If yes, append (Pro) to TITLE and sidebar text.
Images / source — does the user have .webp screenshots and/or raw content to convert? Where from?

Then show a confirmation table and wait for approval:

Field	Value
File	`docs/<SECTION>/<SLUG>.md`
URL	`/<SECTION>/<SLUG>`
Sidebar	`<GROUP>` → `{ text: "<TITLE>", link: "/<SECTION>/<SLUG>" }`
Images	`docs/public/images/<SECTION>/<SLUG>/`
Pro	yes / no

Phase 2: Context

Open a sibling article in the SAME section and mirror its structure and tone before writing — e.g. docs/community-hub/creating-a-new-space.md. Read the target sidebar group in .vitepress/config.mts to see exactly where the new entry goes.

Phase 3: Procedure

Scaffold docs/<SECTION>/<SLUG>.md:

---
title: <TITLE>
description: <one-sentence, specific, SEO-friendly summary of the page>
---

# <TITLE>

<intro paragraph with **bold** product terms>

> **Use Case:** <when/why a reader needs this>

## <Section heading>
### Step 1: <action>
![<descriptive alt>](/images/<SECTION>/<SLUG>/<file>.webp)

Body — task-oriented ## sections; step-driven flows use ### Step N: … then #### sub-details. Use house-style blockquote callouts. Keep paragraphs tight.
Images — create docs/public/images/<SECTION>/<SLUG>/ and place .webp files there; reference them root-absolute. If a screenshot is not yet available, insert a clearly-marked [Screenshot: <what it should show>] placeholder and list it in the report.
Sidebar — in .vitepress/config.mts, find the GROUP object (or its nested collapsed: true sub-group) and add, in reading order:
```
{ text: '<TITLE>', link: '/<SECTION>/<SLUG>' },
```
Interlink — add a relative .md link from a related page to this one (prerequisite → next step / "see also"), and link out from this page where it helps.

Phase 4: Verify & Report

npm run docs:build

Must complete with no dead-link warnings. Then report using ✅/⚠️:

✅ File, image folder, and sidebar entry created (list the paths).
⚠️ Any [Screenshot: …] placeholders left, or images still needed.
The live URL: /<SECTION>/<SLUG>.

Quick Reference

Paths

Page: docs/<section>/<slug>.md → URL /<section>/<slug> (cleanUrls, no .md)
Images: docs/public/images/<section>/<slug>/*.webp → ref /images/<section>/<slug>/*.webp
Sidebar: .vitepress/config.mts → themeConfig.sidebar

Frontmatter (exactly these two)

---
title: <Title Case, acronyms fixed>
description: <specific one-sentence summary>
---

House-style callouts (blockquote — the dominant convention)

> **Use Case:** …
> **✨ Note:** …
> **⚠️ Important:** …
> **💡 Tip:** …

Link forms

Body → relative WITH .md: [text](./same-folder.md), [text](../section/other.md)
Sidebar → root-absolute WITHOUT .md: link: '/section/slug'
Image → root-absolute: /images/section/slug/file.webp

Locate where a page lives

grep -n "<slug>" .vitepress/config.mts

Key principles: acronyms fixed in titles · (Pro) in text, (pro) in filenames · one H1 per page · never orphan a page (3-place operation) · always end on a green build.