Read this entire file before starting. This skill is for turning user-fed data into AnyCap-style articles, then adding evidence where the article needs proof.

1. normalize the input data into a working brief
2. draft a page in AnyCap's website tone
3. decide whether the article needs first-party evidence blocks
4. add AnyCap-generated visuals only when they materially improve the page

anycap-cli

anycap-ai-tool-seo

• voice.md
• patterns.md
• input-brief.md

• data-driven blog drafting
• learn pages and tutorials built from research notes
• glossary or concept pages built from product facts and supporting examples
• SEO articles where the user feeds benchmarks, examples, or feature data first
• content workflows where the input is bullets, tables, JSON, spreadsheets, links, or rough notes
• AnyCap website content that should sound operational, answer-first, and product-literate instead of generic content-marketing prose

1. Verify AnyCap is available:

anycap status

1. Inspect the page structure before editing:
   • find the base page
   • find the localized wrapper
   • check whether localized or duplicated routes simply re-export the base page
2. Normalize the input into a brief:
   • what is the article topic?
   • who is it for?
   • what does the data actually prove?
   • what is the one-sentence answer or promise?
   • what can be stated confidently, and what is still unknown?
3. Check the git worktree and do not overwrite unrelated user edits.
4. Read the tone and structure references before writing.

• bullets
• product facts
• competitive notes
• spreadsheet exports
• JSON
• URLs
• benchmarks
• rough observations

• target reader
• search or page intent
• page thesis
• 3-6 supporting facts
• missing proof or uncertainty
• recommended page shape

1. short eyebrow
2. direct H1 with one concrete promise
3. concise intro for readers who already know the general category
4. answer-first summary block near the top
5. one or more structured sections:
   • workflow
   • comparison
   • checklist
   • use cases
   • FAQ
6. CTA or internal links that move the reader to the next relevant page

• Show the final outcome: generate one polished hero or showcase image.
• Show a transformation: generate a rough source image, then a refined after-image from the same subject.
• Show range or iteration: generate a triptych or clean review board with multiple variations.
• Support a time-based workflow: generate a companion still or keyframe that represents the brief. Do not present a static image as the full video result.
• Support an audio-based workflow: generate a mood image or cover visual that supports the prompt. Do not imply the image is audio output.
• Support a process explanation: generate a clean step illustration or diagram-like visual that makes the written explanation easier to scan.

mkdir -p web/public/content-evidence

anycap image generate \
  --model <model> \
  --prompt "<subject-specific brief> ... no readable text, no watermark" \
  --param aspect_ratio=16:9 \
  -o web/public/content-evidence/<page-slug>-hero.png

• Always use

  -o

  with a descriptive filename.
• Prefer

  16:9

  for hero or showcase blocks unless the layout needs another ratio.
• Version or split files clearly for before/after workflows.
• Keep assets topic-specific at generation time, but keep the skill itself topic-agnostic.
• If the page is localized through wrapper files, keep assets shared unless a locale-specific image is genuinely needed.

• Compress oversized PNGs to JPG or WebP when the visual difference is acceptable.
• Prefer a reusable component plus a lookup table over duplicating large JSX blocks in every page.
• Keep captions factual:
  • static images can say the image was generated through AnyCap for the page
  • time-based or audio-based pages should explicitly label the visual as a companion still or cover visual
• If localized routes simply re-export the base page, edit the base page once instead of patching every localized copy.
• Keep the reusable block generic enough that it can be dropped into articles, guides, or landing pages without rewriting the component itself.

• a compact brief distilled from the input data
• an article draft in AnyCap website tone
• generated assets in a stable public directory
• one reusable content or UI component if multiple pages need the same evidence pattern
• page copy that explains what the asset proves
• alt text, caption, and prompt block that match the real artifact
• concise validation notes covering generation, verification, and code checks

• Do not write generic "AI blog" copy that could belong to any SaaS site.
• Do not let the article drift beyond what the provided data can support.
• Do not bury the answer under a long warm-up.
• Do not use stock art when the whole point is to show first-party AnyCap output.
• Do not present a static image as if it were the actual output of a video or music model.
• Do not leave visible text or watermarks in showcase assets unless the page specifically needs them.
• Do not duplicate localized page implementations when a wrapper already reuses the base page.
• Do not inflate pages with generic prose when the missing piece is proof.
• Do not bake page topic, keyword cluster, or niche-specific nouns into the skill itself. Those belong to the actual task input, not to the reusable workflow.