Anycap Blog Production

AnyCap Blog Production

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.

Use this skill when the user provides facts, notes, examples, benchmarks, product capabilities, or other raw inputs and wants a finished blog post that sounds like the AnyCap website. The core job is:

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

This skill is about blog production workflow. For raw CLI syntax, authentication, and command behavior, read the anycap-cli skill. For broader search-intent planning, read the anycap-ai-tool-seo skill.

Read these reference files before drafting:

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

Best Fit

• 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

Before You Start

1. Verify AnyCap is available:

anycap status

2. 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

3. 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?

4. Check the git worktree and do not overwrite unrelated user edits.

5. Read the tone and structure references before writing.

Workflow

1. Build a working brief from the input data

The user may feed:

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

Your first job is to convert that into a compact internal brief:

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

If the input is sparse, infer carefully but keep the article scoped to what the data can actually support.

2. Draft in AnyCap website tone before expanding

Default AnyCap article pattern:

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

Do not start with generic scene-setting. Start with the actual problem, constraint, or useful outcome.

3. Match the evidence type to the page's claim

• 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.

If the article already lands without media, do not force a proof block. This skill is for useful proof, not decorative filler.

4. Discover real model constraints before prompting

If the article needs media, inspect the live model catalog and schema first:

anycap image models
anycap image models <model> schema --operation generate --mode <mode>

anycap video models
anycap video models <model> schema --operation generate --mode <mode>

anycap music models
anycap music models <model> schema --operation generate

Never assume mode names, parameter names, or supported aspect ratios.

5. Generate assets into a reusable public path

Use descriptive filenames and keep related artifacts together:

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

Rules:

• 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.

6. Verify the generated asset before wiring it into the page

Use AnyCap vision to validate the artifact:

anycap actions image-read \
  --file web/public/content-evidence/<page-slug>-hero.png \
  --instruction "Describe this image, confirm it matches the intended page claim, and mention any visible text or watermark."

For edit workflows, compare source and revision:

anycap actions image-read \
  --file web/public/content-evidence/<page-slug>-before.png \
  --file web/public/content-evidence/<page-slug>-after.png \
  --instruction "Confirm whether the second preserves the same subject while improving composition and background cleanliness."

If verification reveals visible text, stray signage, wrong subject identity, or prompt drift, re-prompt and regenerate before editing code.

7. Optimize the asset and wire it into reusable code

• 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.

8. Verify the page integration

Run targeted checks on the files you touched:

pnpm exec eslint \
  'src/components/seo/ContentEvidenceBlock.tsx' \
  'src/lib/content-evidence.ts' \
  'src/app/(seo)/<section>/<page>/page.tsx'

If a full repo-wide typecheck fails because of pre-existing issues, record the exact blocking file and keep the skill output focused on what was actually validated.

Output Expectations

Default deliverables:

• 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

Guardrails

• 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.

Quick Reference

# Check auth and feature availability
anycap status

# Normalize the topic with a small brief before writing
# Then inspect model parameters only if the article truly needs media

# Discover image models and parameters
anycap image models
anycap image models <model> schema --operation generate --mode text-to-image

# Generate a page-specific artifact
anycap image generate --model <model> --prompt "..." -o web/public/content-evidence/<page-slug>-hero.png

# Validate the artifact with vision
anycap actions image-read --file web/public/content-evidence/<page-slug>-hero.png --instruction "Describe this image and mention visible text."

# Compress a heavy PNG to JPG
sips -s format jpeg -s formatOptions 80 web/public/content-evidence/<page-slug>-hero.png --out web/public/content-evidence/<page-slug>-hero.jpg

Input Brief

Use this file when the user feeds raw data and wants an article draft.

Goal

Convert raw input into a brief before writing. Do not draft directly from a messy blob of facts.

Minimum Brief Fields

• topic: what the page is about
• reader: who the article is for
• intent: why the reader is here
• main_claim: the one-sentence promise
• facts: 3-6 strongest inputs that can be stated confidently
• proof_gaps: what still needs evidence, if anything
• page_shape: tutorial, learn page, glossary page, comparison, landing page, or other
• cta: what the reader should do next

Accepted Input Types

• bullet notes
• tables
• benchmark exports
• product facts
• competitor notes
• JSON
• CSV summaries
• URLs or crawled notes

Conversion Rules

• compress duplicate facts
• separate hard facts from inferred framing
• throw away weak inputs instead of padding the article
• if the data is too thin, write a narrower article instead of inventing depth

Writing Decision

After the brief is built, decide:

• what belongs in the intro
• what belongs in the answer-first box
• what deserves a section
• whether the page needs media evidence

Important

The user-provided data defines the page topic. The skill defines the workflow and tone.

Patterns

Use this file when choosing prompts, filenames, captions, and proof blocks for blog-style content pages. The workflow is reusable; the topic should come from the actual task, not from this file.

Blog Block Shapes

Answer-first box

• Best near the top
• Answers the page's main promise in 3-5 sentences
• Should explain why the shallow default approach is not enough

Workflow section

• Best for tutorials, guides, and operational pages
• Usually 3-6 steps
• Each step should move the reader closer to a usable result

Comparison or options block

• Best when the input data includes alternatives, tradeoffs, or choices
• Use tables or short cards, not long prose

FAQ

• Best when the query has repeated objections or high-intent clarifications
• Answers should stay specific and operational

Proof block

• Only add when the article benefits from a real artifact
• Good forms: hero, before/after, variation board, keyframe, cover visual, step illustration

Asset Shapes

Single hero or showcase

• Goal: one polished hero or showcase image
• File shape: <page-slug>-hero.jpg
• Good fit: landing pages, intros, strong answer-first sections

Before/after proof

• Goal: prove the revision loop with the same subject
• File shape:
• <page-slug>-before.jpg
• <page-slug>-after.jpg
• Good fit: workflows, case studies, transformation claims

Variation board

• Goal: prove throughput with a triptych or review board
• File shape: <page-slug>-variants.jpg
• Good fit: ideation pages, option selection, comparison sections

Step illustration

• Goal: make a process section easier to scan
• File shape: <page-slug>-step-<n>.jpg
• Good fit: guides, tutorials, docs, workflows

Companion still

• Goal: show a companion still that matches the motion brief
• File shape: <page-slug>-keyframe.jpg
• Good fit: video workflows or any time-based process

Companion cover visual

• Goal: show a mood visual or cover image for the soundtrack brief
• File shape: <page-slug>-cover.jpg
• Good fit: audio workflows or mood-driven sections

Prompt Patterns

Polished hero

Use language like:

clear subject, premium hero composition, soft editorial lighting, crisp layout, no readable text, no watermark

Before/after edit proof

Source image prompt:

rough draft version of the same subject, mixed lighting, everyday context, realistic image, no readable text, no watermark

Edit prompt:

preserve the same subject, clean the background, center the product, improve lighting, launch-ready marketing photo, no text, no watermark

Variation board

Use language like:

triptych, three side-by-side panels, same subject in three visual directions, clean review board layout, no labels, no sticky notes, no text, no watermark

Step illustration

Use language like:

clean process illustration, one clear step, uncluttered composition, readable without text overlay, no watermark

Companion still

Use language like:

cinematic still, motion implication, atmospheric scene, no storefront signs, no billboards, no text, no watermark

Important:

• explicitly remove signs, labels, and typography
• caption it as a companion still, not the video output itself

Companion cover visual

Use language like:

abstract cover visual, mood-first composition, no readable text, no watermark

Caption it as a companion cover visual, not as primary output.

Caption Patterns

Safe factual caption for static image pages

This visual was generated through AnyCap for this page.

Safe factual caption for edit pages

The left image is the rough source draft. The right image is the AnyCap revision generated from that source asset.

Safe factual caption for companion stills

This still was generated through AnyCap as a visual proxy for the kind of scene or motion brief discussed in this section.

Safe factual caption for cover visuals

This companion cover visual was generated through AnyCap to anchor the prompt or mood described on this page.

Verification Checklist

Before shipping an asset, confirm:

• the subject matches the page claim
• there is no visible watermark
• there is no stray readable text unless intentionally allowed
• for before/after pages, the subject identity is preserved
• the alt text describes what is actually visible
• the caption does not over-claim what the artifact proves
• the workflow stays generic even though the prompt is page-specific

AnyCap Voice

Use this file to keep blog output aligned with the AnyCap website.

Core Voice

• direct, operational, and specific
• assumes the reader is smart and already somewhat technical
• answer-first instead of slow narrative buildup
• product-literate without sounding like a feature dump
• confident, but not breathless or hype-heavy

What the Writing Usually Does

• frames a concrete problem early
• explains the shortest useful workflow
• contrasts shallow alternatives with a better operational path
• states what role AnyCap plays in the workflow
• uses structured sections, not long essay blocks
• gives the reader a clear "best next move"

Sentence-Level Style

• prefer clear claims over clever phrasing
• use short-to-medium sentences
• use contrast cleanly:
• You do not need X. You need Y.
• The problem is not the agent. It is the missing capability layer.
• keep paragraphs tight
• explain abstractions through workflow, not philosophy

Common AnyCap Moves

1. Answer-first summary

Often near the top, usually after the intro.

It should answer:

• what this page helps with
• why the obvious shallow approach is not enough
• where AnyCap changes the workflow

2. Problem -> workflow -> outcome

Many pages follow:

• problem statement
• capability or workflow explanation
• use-case breakdown
• FAQ or next steps

3. Product role clarity

The article should say what AnyCap does in the workflow, not just that it is "useful."

Examples of the pattern:

• the agent does the reasoning; AnyCap provides the capability layer
• AnyCap handles search, crawl, generation, storage, or delivery around the agent

Avoid

• generic SEO fluff
• inflated thought-leadership tone
• bland intros that restate the keyword
• broad claims that the page cannot support
• vague statements like streamlines your workflow without saying how

Good Output Shape

• eyebrow
• direct H1
• concise intro
• answer-first summary
• structured middle sections
• clear CTA or internal next links