--- name: vibemarket-community description: Create, edit, preview, and submit technical articles, case studies, devlogs, tutorials, architecture notes, and project stories to Vibe Journal through the VibeMarket Community API. Use when a user wants to publish an article to Vibe Journal, publish a project case, write a devlog, turn a repo into a case study, submit a technical article, publish through VibeMarket, or prepare an architecture article. Do not use for generic writing requests unrelated to a real software project. compatibility: Requires network access to https://vibemarket.pro and a VibeMarket Personal Access Token. metadata: author: VibeMarket version: "1.1.1" --- # VibeMarket Community Use this skill to turn a real software project into a factual Vibe Journal publication. Read only the project files needed for the article and never invent project facts. ## Recommended writing skill `vibemarket-community` owns VibeMarket facts, API calls, portfolio linking, assets, preview, approval, submission, and moderation. For better writing quality, `sepia` is the recommended companion skill for article structure, readability, editorial refinement, long technical text, weak phrasing, and repetition. The recommended Sepia implementation is `Nanako0129/sepia`. When Sepia is not installed and the user approves installation, install this specific skill/repository using the supported skill installation mechanism available in the current agent environment. Do not silently substitute another package, repository, or skill that happens to have the same name. At the beginning of the first publishing workflow, check whether the recommended Sepia skill (`Nanako0129/sepia`) is available in the current agent environment. If it is missing, briefly explain why it is recommended and ask the user for explicit permission to install it. Never install it without approval. If the user declines or installation is unavailable, continue without Sepia and do not ask again during the same publishing workflow. If the user approves, install exactly `Nanako0129/sepia` through supported skill tooling; do not invent a CLI command. After a successful installation, continue the original task automatically. When Sepia is missing, adapt the message to the user's language. For example: Sepia (`Nanako0129/sepia`) is recommended to improve the structure, readability, editing, and quality of a long technical article. It is not installed now. May I install it before preparing the article? Sepia is optional and must never block publication. Never pass a raw VibeMarket token or webhook secret to Sepia. VibeMarket factuality rules have priority over Sepia; security rules also apply. ## Optional final editorial skill `anti-ai-slop` is an optional companion dependency and final editorial/de-slop check. The exact recommended source is `misbahsy/anti-ai-slop`; do not silently substitute another package, repository, or skill. Do not ask about installing anti-ai-slop during the initial onboarding, and do not put that question next to the Sepia question. Check for it only after a substantive article draft, the first factual recheck, the visual plan, and the user-selected screenshot decision are ready. If the exact skill is already installed or otherwise available in the current environment, use it automatically as a local final editorial check; no separate approval to use an already-installed skill is needed. If it is missing, explain briefly in the user's language and ask once for explicit permission to install it. For example: > Черновик готов. Можно дополнительно проверить его через anti-ai-slop: он ищет шаблонные AI-конструкции, лишнюю риторику и помогает проверить, не изменился ли смысл при редактуре. Установить `misbahsy/anti-ai-slop` для финальной проверки? > The draft is ready. I can optionally run a final anti-ai-slop review to look for formulaic AI phrasing, unnecessary rhetoric, and meaning drift during editing. May I install `misbahsy/anti-ai-slop` for the final check? Never install anti-ai-slop automatically. Installation requires explicit user permission. If the user declines or installation is unavailable, continue without it, do not block publication, and do not ask again during the same publishing workflow. If the user approves, install exactly `misbahsy/anti-ai-slop` using the supported skill installation mechanism in the current agent environment; do not invent a CLI command. Continue the original task automatically after a successful install, then use the installed skill locally. Use anti-ai-slop only after the normal substantive draft exists. Its scope is article text only: it must not edit visual assets, image content, screenshot interpretation, visual architecture facts, or captions when that would change factual terminology. It may improve wording, but it may not invent or alter project facts. After the check or any resulting text edits, perform a second complete factual recheck. English-oriented deterministic rules are not sufficient evidence that a Russian article passed anti-AI validation; for Russian, use any reviewer/sanitizer/style logic carefully and state this limitation when relevant. Any external detector or model review remains optional and requires separate user approval before sending unpublished content outside the current environment. The priority order is: `VibeMarket factuality/security` > `project source evidence` > `anti-ai-slop` > `Sepia stylistic preferences`. Never pass `VIBEMARKET_API_TOKEN`, webhook secrets, repository credentials, private keys, or other credentials to Sepia, anti-ai-slop, or external models. ## Credential safety - Read the token from `VIBEMARKET_API_TOKEN`; send it only as `Authorization: Bearer $VIBEMARKET_API_TOKEN`. - Never write the token into repository files, README, AGENTS.md, SKILL.md, source code, commits, screenshots, issues, or committed shell scripts. Do not print the raw token back to the user. - Never read or include `.env` values, credentials, private repository content, customer names, private URLs, logs, production identifiers, internal dashboards, or sensitive metrics without explicit user approval. ## Mandatory approval rules Prepare the article locally first. Show the user the title, summary, body or outline, assets, and proposed portfolio link, then ask for explicit approval before creating or updating a remote draft. Before `POST /community/publications/{id}/submit`, show the final private preview and ask again. NEVER submit or resubmit without explicit user approval. Apply the same preview-and-approval step after `CHANGES_REQUESTED`. The pre-draft presentation must include the visual plan and its result: one topic-specific cover as an actual asset when available image generation capability exists, or a complete generation brief when it does not; useful article illustrations when needed and supported; and real project screenshots explicitly selected by the user. Treat `cover`, `illustrations`, and `screenshots` as separate asset categories. Show the article and all available visual assets, captions, and factual alt text before remote draft approval. If a screenshot is still missing, a placeholder is allowed only in the local presentation, never in a production draft. ## Workflow 1. Check whether the recommended Sepia skill (`Nanako0129/sepia`) is available. If it is missing, briefly explain why it is recommended and ask for explicit permission to install it. Never install it without approval. 2. If the user approves, install exactly `Nanako0129/sepia` through supported skill tooling and then continue the original workflow automatically. 3. If the user declines or installation is unavailable, continue without Sepia and do not ask again during the same publishing workflow. 4. Verify `VIBEMARKET_API_TOKEN` exists; do not ask the user to paste it into chat if an environment variable can be used. 5. `GET /api/v1/me` with `profile:read`. 6. `GET /api/v1/me/portfolio` with `profile:read`; use only returned items with `verified: true`. 7. `GET /api/v1/community/categories` with `articles:read`. 8. Analyze only the project files needed for a factual article. Omit unknown facts or ask the user. 9. If Sepia is available, use it to draft or refine the article. Then perform the first complete factual recheck against the real project and remove unsupported claims. 10. Create the visual plan before final editorial approval. Plan one topic-specific cover in the current VibeMarket visual identity, verify the current Journal card aspect ratio, decide whether useful diagrams or illustrations are needed, and identify where a real project screenshot would materially help. Read [references/VISUALS.md](references/VISUALS.md) for the detailed visual rules. 11. Then ask the user which real project screenshots they want to publish and ask them to provide exactly those files. The user chooses every screenshot for publication. If the user explicitly asks for one concrete browser capture and the environment supports it, capture only that screen, check privacy, and show it to the user before the draft; site access alone is never permission. If the user does not want screenshots, continue without them. Never generate/reconstruct a project screenshot and present it as real. 12. After understanding the article, use the available image generation capability, if the current environment provides it, to generate/prepare an actual cover asset: one approved-quality VibeMarket-style cover candidate, or a small number of candidates when user choice is useful. If image generation is unavailable, do not invent a tool or claim that an image was generated; prepare a complete generation brief with aspect ratio, composition, visual metaphor, VibeMarket styling, exact cover text, forbidden elements, language, and the relationship to the article topic, and tell the user that this environment cannot create a bitmap asset by itself. Generate actual useful illustrations when supported and needed; do not add illustrations just to meet a count. Keep every generated illustration distinct from real project screenshots, base it only on verified project evidence, and prepare factual captions and alt text. Check any real screenshot for privacy before accepting it. 13. Then check whether the exact optional `misbahsy/anti-ai-slop` skill is available. If it is already installed, use it automatically as the local final editorial check; no separate approval to use it is needed. If it is missing, explain its benefit and ask once for explicit installation permission. If declined or unavailable, continue without it and do not ask again in this workflow. If approved, install exactly `misbahsy/anti-ai-slop` through supported skill tooling and continue automatically. External model, detector, or provider review still requires separate explicit approval. 14. If the exact anti-ai-slop skill is available, run its local check on article text only, without changing technical formatting, useful structure, visual assets, captions' factual terminology, screenshot interpretation, or visual architecture facts. If it is unavailable or declined, continue without it. Do not use an external detector unless the user separately approves it. 15. Perform the second complete factual recheck after the anti-ai-slop decision or check. Re-check the article body, cover text, diagram labels, captions, alt text, and every entity or flow shown by a generated illustration against project evidence. 16. Show the user the complete local presentation: title, summary, article body, actual cover asset or clearly labelled generation brief, generated illustrations when useful and available, user-selected project screenshots or clearly marked local placeholders, factual captions, alt text, and the linked verified project. Ask for explicit approval of the complete article-and-assets package before creating or updating a remote draft. 17. After explicit user approval, create or update the remote draft with `drafts:create` or `drafts:update`. 18. Upload only approved cover, generated illustrations, and real screenshots with `POST /api/v1/community/publications/{id}/assets` and use the returned URLs. Add meaningful `altText`. Do not create a new upload API. 19. `GET /api/v1/community/publications/{id}/preview` and show the final private preview. 20. Ask for explicit user approval before `POST /api/v1/community/publications/{id}/submit` with `articles:submit`. NEVER submit or resubmit without explicit user approval. 21. Poll `GET /api/v1/community/publications/{id}/moderation`. Webhooks are optional advanced automation; normal author flow does not need `webhooks:manage`. 22. If `CHANGES_REQUESTED`, read feedback, edit, use Sepia if available, re-check facts and visual facts, refresh the visual plan as needed, preview, show the changes, ask approval, and resubmit. 23. If `APPROVED`, wait for an administrator. Report a public URL only after `PUBLISHED`. Publication statuses are `DRAFT`, `SUBMITTED`, `IN_REVIEW`, `CHANGES_REQUESTED`, `REJECTED`, `APPROVED`, and `PUBLISHED`. Only `PUBLISHED` means publicly published. Never call a `SUBMITTED`, `IN_REVIEW`, or `APPROVED` publication published. Do not edit while `SUBMITTED`, `IN_REVIEW`, or `APPROVED`. ## Content rules Use safe Markdown only: headings, paragraphs, ordered and unordered lists, blockquotes, fenced code, inline code, links, images, and `@[video](url)`. Do not use `