Daniel is your business intelligence analyst. He continuously researches your market, tracks competitor product updates, pricing changes, and content strategies, then compiles actionable intelligence reports. He stores findings in your CMS so the whole team can access battle cards, competitor profiles, and trend analysis. Schedule him for weekly competitive briefs.

Daniel, Business Intelligence Analyst

Elena is your dedicated SEO analyst. She audits your CMS content for SEO best practices, rewrites meta titles and descriptions at scale, identifies keyword opportunities, and monitors your search performance. She can fix common SEO issues automatically or flag them for review. Schedule her for weekly audits that post directly to Slack.

Elena, SEO Analyst

Ava is your Content Lead. She researches topics using web browsing, writes SEO-optimized blog posts, creates landing page copy, and manages your editorial calendar in the CMS. She generates AI images for featured graphics, writes social media teasers, and can coordinate with your SEO analyst to ensure every piece of content is search-optimized. Connect her to Slack for content planning discussions.

Ava, Content Lead

Lina translates your CMS content into multiple languages while preserving tone, context, and SEO value. She handles locale-specific formatting (dates, currencies, units), maintains translation consistency across your catalog, flags untranslated or outdated translations, and organizes localized content in the CMS. She can translate blog posts, product descriptions, landing pages, UI strings, and more.

Lina, Translator & Localization Manager

A Competitors type with 2 example pages to replace with your own
A Competitor Briefs type that keeps every brief and what changed
Daniel, Business Intelligence Analyst as the agent
One weekly workflow, schedule off until you enable it

# Competitor Monitoring

A weekly workflow that reads the competitor pages you choose, compares each one against what it recorded last week, and drafts a brief on what changed.

## What it installs

- `competitor-watch`: the watch list, one page per record, editable as content
- `competitor-briefs`: one object per brief, including which competitors were checked
- Agent: Daniel, Business Intelligence Analyst (`business-intel-analyst`)
- One weekly workflow in two steps, created with its recurring schedule disabled

## How change detection works

Most pages worth watching carry no publish date, so recency cannot do the filtering. Each competitor record therefore holds a `last_snapshot`: the facts the workflow recorded last run. A pricing page is compared field by field against it, and a plan moving from $19 to $29 is a reportable change. Dated changelogs skip the comparison and use their dates instead.

Two consequences worth knowing:

1. The first run reports "baseline recorded" rather than changes. There is nothing to compare against yet, and claiming otherwise would be a guess.
2. The snapshot only advances after the brief is written. If the brief step fails, the old snapshot stays, so next week still catches the change instead of silently swallowing it.

## The example rows

| Example | Page | Why it is here |
| --- | --- | --- |
| GitHub Changelog | `https://github.blog/changelog/` | A dated changelog, where recency does the filtering |
| Netlify Pricing | `https://www.netlify.com/pricing/` | An undated page, where only the snapshot comparison finds anything |

Both are placeholders: replace them with your own competitors. The one requirement is that the page renders in plain HTML, because `fetch_url` does not execute JavaScript. Several well-known changelogs are client-rendered and return an empty page, so check that a new row returns real content on its first run.

## What keeps it honest

- A page that fails to fetch is reported as failed. The agent is told never to substitute what it already knows about a company for a page it could not read.
- Every reported change carries the wording on the page that shows it, so a claim can be checked without refetching.
- Competitors that were checked and did not move are named, so a short brief cannot be confused with a brief that skipped the work.
- Every brief is created as a draft, and the workflow never publishes.

## Install it

Hosted MCP endpoint: `https://mcp.cosmicjs.com/v1/buckets/{bucket-slug}`

Or install in one click from https://www.cosmicjs.com/marketplace/workflows/competitor-monitoring

## Step 1 prompt

```text
Check each competitor page and report what changed since the last run. Do not write the brief and do not create any objects in this step.

Scope for this run:
1. Read the competitor-watch type and take every object where active is true. Each one gives you a watch_url, a what_matters describing which facts to track, and a last_snapshot holding what you recorded last time.
2. Fetch each active page with fetch_url. Read only the page you were given. Do not follow links to other pages: the record names the page that matters, and wandering makes the run unbounded.
3. Decide what changed, using whichever of these the page supports:
   - When the page carries dates, treat entries from the last {{lookback_days}} days as new.
   - When it does not, compare what you see against last_snapshot field by field. A plan that went from $19 to $29, a tier that gained a limit, a headline claim that was reworded: those are changes.
   - When last_snapshot is empty, there is no baseline yet. Record the current facts as the baseline and report this page as "baseline recorded", not as a change. Saying a competitor changed on the first run would be a guess.
4. Keep at most {{max_changes}} changes across all competitors. When there are more, keep the ones that affect positioning, pricing, or what a customer can do.
5. If a page errors, returns almost no text, or clearly needs JavaScript, record it as failed and move on. Never fill the gap with what you already know about that company. An unread page contributes nothing to this brief.

Return a single JSON array and nothing else before it. One entry per competitor you fetched:
{ "competitor", "slug", "url", "status", "changes", "snapshot" }

- status is "changed", "unchanged", "baseline recorded", or "failed".
- changes is an array of { what_changed, from, to, evidence }. Leave it empty unless status is "changed". from and to are what the page said before and now; use null for from when the page carries dates rather than a comparable value. evidence is the wording on the page that shows it, not your paraphrase.
- snapshot is the current facts for this page in the same shape you would want to compare against next week: plan names and prices for a pricing page, the newest dated entries for a changelog. Keep it compact, since it is stored and read back every run.

Finally, set last_checked to today on each competitor-watch object you fetched successfully. Leave last_snapshot alone: the next step advances it once the change has actually been written down.
```

## Step 2 prompt

```text
Write this week's competitor brief from the previous step, save it as a draft, then advance each snapshot.

Scope for this run:
1. Work only from the JSON you were handed. You did not read the pages in this step, so the facts available to you are the changes and evidence recorded there.
2. Write the brief:
   - Open with two or three sentences on the through-line. If the week was quiet, say so plainly rather than inflating a wording tweak into a strategy shift.
   - One short section per competitor that changed: what moved, the before and after, and a link to the page. Two to four sentences each.
   - Where a change has an obvious implication for your own pricing, positioning, or roadmap, say it in one sentence. Do not manufacture an implication for every item.
   - Close with one takeaway sentence.
3. Name competitors that were checked and did not move in a single closing line. A brief that only lists movement leaves the reader unsure whether the rest was even looked at.
4. Create exactly one object in the competitor-briefs type with status draft:
   - title: "Competitor Brief: <Month D, YYYY>"
   - brief_date: today
   - content: the body as HTML, using h3 subheads, paragraphs, and inline links
   - takeaway: the closing sentence on its own
   - change_count: how many changes you reported
   - competitors_checked: JSON array of { competitor, status } for every competitor from the previous step, failures included
5. Only after the brief exists, write the snapshot from the previous step onto each competitor-watch object whose status was "changed" or "baseline recorded". Change nothing else on those objects.

Step 5 is last on purpose. The snapshot is the memory of what you have already reported, so advancing it before the brief is written would lose the change if this step failed: the page would look unchanged next week and nobody would ever hear about it.

Leave the brief as a draft. Whether this goes to the team, and with what framing, is a human call.
```

Watches the competitor pages you choose, compares each one against what it saw last week, and drafts a brief covering what moved, what stayed put, and what it means for you.

Competitor Monitoring

A Localize Demo Pages type with 2 English pages and localization enabled
A Translation Log type to record each run
Lina, Translator & Localization Manager as the agent
One weekly workflow, schedule off until you enable it

# Localization Sweep

A weekly workflow that finds published pages with no translation in your target language, translates them, and creates each one as a native Cosmic locale variant in draft.

## What it installs

- `localize-pages`: two published English pages, with localization already enabled and English as the priority locale
- `translation-log`: one object per run
- Agent: Lina, Translator & Localization Manager (`translator`)
- One weekly workflow, created with its recurring schedule disabled

## Locale variants, not duplicate objects

A translation in Cosmic is a separate object that shares the original's slug and carries a different locale. That is what links it to its source and what drives the locale switcher in the dashboard and the `locale` parameter in the API. The workflow never creates a slug like `shipping-and-delivery-es`, which is the shape you are stuck with when translation is bolted onto a CMS that has no locale model.

## Install it

Hosted MCP endpoint: `https://mcp.cosmicjs.com/v1/buckets/{bucket-slug}`

Or install in one click from https://www.cosmicjs.com/marketplace/workflows/localization-sweep

## The prompt

```text
Translate published pages into {{target_locale}} as locale variants, leaving the originals untouched.

How Cosmic locales work, because this is the part that is easy to get wrong: a translation is a separate object that shares the original's slug and carries a different locale. Never create a new slug like "shipping-and-delivery-es". The shared slug is what links a translation to its source and what makes the locale switcher work.

Prepare.
1. Call get_object_types and read the localization settings of the type you are translating. If "{{target_locale}}" is not in its locales, call update_object_type to add it: localization true, locales set to the existing list plus "{{target_locale}}", and priority_locale left as the source language.
2. If the type has published objects with no locale at all, they predate localization. Stamp each one with the priority locale using update_object so it is recognized as the source of its translations.

Find what needs translating.
3. Call get_objects for published objects in the source locale, then again with locale "{{target_locale}}". Any slug in the first list and missing from the second needs a translation.
4. Translate at most {{max_objects}} objects on this run. Stop at that number even if more remain: translation is output-heavy, and this cap is what keeps the run affordable.

Translate.
5. Translate the title, the body, and any SEO or excerpt fields. Every field, not just the body: a translated page with an English meta description is worse than an untranslated one.
6. Write naturally in {{target_locale}} rather than word for word. Adapt dates, currencies, units, and idioms to what a reader in that locale expects. Leave proper nouns, product names, and code samples in the original.
7. Create each variant with create_object: the same slug as the original, locale "{{target_locale}}", status draft. Drafts, because a human who reads the language should approve the first batch.

Log it.
8. Create one object in the translation-log type recording run_date, target_locale, objects_translated, a markdown summary listing each page you translated, and details as a JSON array of { slug, title_translated }.
9. If a translation already exists but its source has changed since, do not overwrite it. Note it in the summary as needing review, so a human edit is never silently replaced.
```

## Before you point it at your own content

The workflow adds your target locale to the type it is translating on the first run, and stamps the source locale onto any published objects that predate localization so they are recognized as the source. Translations land as drafts: have someone who reads the language approve the first batch before you raise the cap.

## Cost

Every translated page produces a full page of output tokens, which makes this the most expensive template in the library per object. Two or three pages a week is a realistic Free plan pace.

Translates your published pages into another language as native Cosmic locale variants, leaving the originals untouched and filing each translation as a draft for review.

Localization Sweep

A Link Demo Posts type with 3 related posts and no links yet
A Link Report type that names every anchor added
Elena, SEO Analyst as the agent
One weekly workflow, schedule off until you enable it

# Internal Link Pass

A weekly workflow that finds published pages covering related subjects and links them to each other, then reports every anchor it added.

## What it installs

- `link-posts`: three related posts with no internal links, so the first run has real opportunities
- `link-report`: one object per run, naming every anchor added
- Agent: Elena, SEO Analyst (`seo-analyst`)
- One weekly workflow, created with its recurring schedule disabled

## Why this is different

Relevance comes from `search_content`, which is semantic: it matches on meaning across the whole bucket rather than on shared keywords. Tools that bolt linking onto a CMS from outside only see the pages you hand them.

## Install it

Hosted MCP endpoint: `https://mcp.cosmicjs.com/v1/buckets/{bucket-slug}`

Or install in one click from https://www.cosmicjs.com/marketplace/workflows/internal-link-pass

## The prompt

```text
Add internal links between published pages that genuinely relate to each other, and report every anchor you add.

Rules, in order of importance. Read them before you write anything.
1. The only edit you may make to a body field is wrapping text that is already there in a link. Do not reword, rewrite, reorder, reformat, summarize, or add sentences. If the body cannot be linked without changing the prose, skip the object and say so in the report.
2. Never insert a link inside a heading, a code block, a blockquote, a table, or existing link text.
3. Match the format of the field you are editing: markdown links for markdown and rich-text fields, an anchor tag for HTML fields.

How to do the pass.
4. Read at most {{max_objects}} published objects that have a body field. Stop at that number even if more remain.
5. For each one, use search_content to find other published objects in this bucket that cover a related subject. Only link when the target actually covers the phrase you are linking: a link that surprises the reader is worse than no link.
6. Link to {{link_path}}/SLUG, where SLUG is the target object's slug. If the body already contains internal links, copy the path pattern they use instead, since it reflects how the site is actually routed.
7. At most 3 links per object, at most one link per target per object, and never link an object to itself.
8. Skip any phrase that is already linked. Skip the object entirely if you would be adding a link to a page that already links back in the same paragraph.
9. Write the change with update_object, sending only the body field.

When finished, create one object in the link-report type recording:
- run_date: today
- objects_updated: how many objects you changed
- links_added: how many anchors you added in total
- summary: a markdown list with one line per anchor, in the form "source-slug: \"anchor text\" to target-slug"
- details: JSON array of { source_slug, anchor_text, target_slug }

Every edit creates a revision, so a human can revert an individual object from its revision history if they disagree with a link. Name every anchor in the summary so that review is possible without opening each page. If you found no genuine opportunities, create the report with zero changes rather than forcing links.
```

## Reviewing a run

The agent only wraps text that is already in the body, and the report names every anchor in the form `source-slug: "anchor text" to target-slug`. Every edit writes a revision, so an individual object can be reverted from its revision history without undoing the rest of the run. Start with the default of 5 objects per run before raising it.

## Cost

The pass reads each candidate body plus its search results, so cost scales with objects per run rather than with links added.

Finds published pages that genuinely relate to each other and adds contextual internal links between them, then reports every anchor it added so you can scan the run in one place.

Internal Link Pass

A Rundown Sources type with 5 working sources: Hacker News, Anthropic, OpenAI, Google DeepMind, Google Developers
A Rundown Editions type that keeps every edition and what it covered
Daniel, Business Intelligence Analyst as the agent
One weekly workflow, schedule off until you enable it

# AI Rundown

A weekly workflow that reads AI and developer tooling news, skips stories you already covered, and drafts a linked rundown for a human to approve.

## What it installs

- `rundown-sources`: five working sources, editable as content
- `rundown-editions`: one object per edition, including the URLs it covered
- Agent: Daniel, Business Intelligence Analyst (`business-intel-analyst`)
- One weekly workflow in two steps, created with its recurring schedule disabled

## The sources

| Source | URL |
| --- | --- |
| Hacker News | `https://news.ycombinator.com` |
| Anthropic News | `https://www.anthropic.com/news` |
| OpenAI API Changelog | `https://platform.openai.com/docs/changelog` |
| Google DeepMind Blog | `https://deepmind.google/discover/blog/` |
| Google Developers Blog | `https://developers.googleblog.com` |

Add your own by creating another Rundown Source with an `active` switch on. The one requirement is that the page renders its headlines in plain HTML. `fetch_url` does not execute JavaScript, so a client-rendered index returns an empty page: this is why the OpenAI source is the API changelog rather than the newsroom.

## How it avoids slop

Three things, all of them structural rather than stylistic:

1. The scan step reads index pages only and is told never to substitute its own knowledge for a page it could not read. A failed fetch is reported as a failure, not quietly filled in.
2. The write step drops any URL that appeared in the last four editions, so the same launch cannot be reported three weeks running.
3. Every edition is created as a draft, and the workflow never publishes.

## Install it

Hosted MCP endpoint: `https://mcp.cosmicjs.com/v1/buckets/{bucket-slug}`

Or install in one click from https://www.cosmicjs.com/marketplace/workflows/ai-rundown

## Step 1 prompt

```text
Scan the configured news sources and return this week's candidate items. Do not write the edition and do not create any objects in this step.

Scope for this run:
1. Read the rundown-sources type and take every object where active is true. Each one gives you a source_url and a focus describing what is worth collecting there.
2. Fetch each active source with fetch_url. These are index pages: the headlines, dates, and links you need are on the page you fetch. Do not follow links into individual articles. The index is enough for a candidate list and it keeps the run bounded.
3. From each page, collect items published within the last {{lookback_days}} days that someone building with AI would care about: model releases, API and SDK changes, pricing changes, deprecations, new developer tools, and substantial engineering write-ups. Skip funding rounds, hiring news, and opinion pieces.
4. Collect at most {{max_items}} items across all sources. When you have more candidates than that, keep the ones with the most concrete news value.
5. If a page errors, returns almost no text, or clearly needs JavaScript to render, record it as failed and move on. Never fill the gap with what you already know about that company: an unread source contributes nothing to this edition.

Return a single JSON array and nothing else before it. One entry per item:
{ "title", "url", "source", "published", "why_it_matters" }

- url must be a link that actually appeared on the page you fetched. If you cannot find the item's own URL, drop the item.
- published is the date shown on the page, or "undated" when the page shows none. Do not infer one.
- why_it_matters is one sentence, grounded in what the page said, not in what you assume the announcement contains.

After the array, add one line per source you fetched saying whether it succeeded or failed.

Finally, set last_checked to today on each rundown-sources object you fetched successfully. Change nothing else on those objects.
```

## Step 2 prompt

```text
Write this week's edition from the candidate items in the previous step, then save it as a draft.

Scope for this run:
1. Read the 4 most recent objects in rundown-editions and gather every URL in their covered_urls. Drop any candidate whose URL already appears there. This is what stops consecutive editions from recycling the same story.
2. Group what survives into 2 to 4 themes. A theme is a claim about what is happening, like "context windows stopped being the differentiator", not a category label like "model news".
3. Write the edition:
   - Open with two or three sentences naming the through-line of the week. No greeting and no "welcome back".
   - One short section per item: what shipped, why it matters to someone building on these tools, and a link to the source. Two to four sentences each.
   - Close with one takeaway sentence.
4. Ground every sentence in the candidate data you were handed. You read index pages, not full articles, so what you know is the headline, the date, and a line of summary. Do not state version numbers, benchmark results, prices, context limits, or capabilities that were not in that data. An item too thin to say anything specific about gets left out, not padded.
5. Create exactly one object in the rundown-editions type with status draft:
   - title: "AI Rundown: <Month D, YYYY>"
   - edition_date: today
   - content: the body as HTML, using h3 subheads, paragraphs, and inline links
   - takeaway: the closing sentence on its own
   - covered_urls: JSON array of every URL you cited
   - item_count: how many items you covered
   - sources_checked: JSON array of { source, status } from the previous step, failures included

Leave it as a draft. Whether this ships is an editorial decision, and the draft is where a human makes it.

If fewer than 3 items survive step 1, still create the draft, cover what you have, and say plainly that the week was quiet. A short honest edition is worth more than a padded one.
```

Scans AI and developer tooling news each week, drops anything you already covered, and drafts a linked rundown post with a stated through-line. Every edition lands as a draft.

AI Rundown

A Refresh Posts type with 3 aging demo posts to review
A Refresh Queue type holding one prioritized entry per post
Ava, Content Lead as the agent
One weekly workflow, schedule off until you enable it

# Insights-Driven Refresh

A weekly workflow that uses your actual traffic to decide which published pages need work, then files a prioritized queue of specific edits without changing the posts.

## What it installs

- `refresh-posts`: three aging demo posts so the first run has real decay to find
- `refresh-queue`: one prioritized entry per reviewed post, each carrying the traffic number that justifies it
- Agent: Ava, Content Lead (`content-lead`)
- One weekly workflow, created with its recurring schedule disabled

## Install it

Hosted MCP endpoint: `https://mcp.cosmicjs.com/v1/buckets/{bucket-slug}`

Or install in one click from https://www.cosmicjs.com/marketplace/workflows/insights-driven-refresh

## The prompt

```text
Use real traffic to decide which published pages need a refresh, then file a prioritized queue. Do not edit the posts themselves.

Step 1: find out what is actually underperforming.
1. Call read_performance with dimension=path, range=30d, metric=events, order=bottom, limit={{max_objects}}, and path_prefix={{path_prefix}}. These are the pages readers are not reaching.
2. Call read_performance with dimension=path, range=30d, metric=events, order=top, limit=5 and the same path_prefix, for context on what does work on this site.
3. Match each underperforming path to its object by slug: the last segment of the path is usually the object slug. Use get_objects to read the ones you matched. Say so in the queue entry if a path has no matching object, rather than guessing.

If Insights returns no data at all, the project either has no tracker installed or has no traffic yet. Do not stop and do not invent numbers. Fall back to age: pick published posts older than 180 days or with an empty last_reviewed field, oldest first, and record "selected by age, no analytics data" as the traffic_signal on every entry you file.

Step 2: judge each candidate.
4. Review at most {{max_objects}} posts. Stop when you reach that number, even if more remain. This keeps the run inside the token budget.
5. Read each body and look for concrete decay:
   - Facts tied to a specific year, quarter, or price that has since moved on.
   - References to deprecated APIs, versions, tools, or endpoints.
   - Claims hedged as "at the time of writing" that now need a number.
   - Sections that were thin when written and are now the reason the page underperforms.
6. Low traffic is not automatically a content problem. A page can be thin, badly titled, or simply about a topic nobody searches for, and the fix is different in each case. Say which one you think it is.

Step 3: file the queue.
7. Create one object in the refresh-queue type per post worth refreshing, with:
   - run_date: today
   - target_title and target_slug: the post you reviewed
   - priority: High, Medium, or Low. High means the post is actively misleading a reader today, or it is losing traffic it used to earn.
   - traffic_signal: the measured reason you picked it, with the number and the window, e.g. "31 visitors in 30d, bottom of the range". This is the evidence, so never leave it empty.
   - reasons: a short markdown list, one line per specific problem, quoting the phrase in the post that dates it.
   - suggested_edits: what to change, specific enough that a writer can act without rereading the whole post.
8. Skip posts that have aged well. An empty queue entry is worse than no entry.

Never modify the posts, their titles, or their metadata. This workflow proposes work; a human decides what to do with it.

If every post you reviewed has aged well, create a single refresh-queue entry with priority Low, target_title "No refresh needed", and reasons explaining what you checked. A run that reports honestly is more useful than one that invents work.
```

## What it needs to be at its best

Install the Cosmic Insights tracker on the site this content publishes to, and give it enough traffic to rank. With that in place, candidates are chosen by what readers actually do, and every queue entry carries the number behind it.

Without it, the workflow still runs. It falls back to selecting the oldest unreviewed posts and labels each entry "selected by age, no analytics data", so you can tell the difference between a measured judgment and a guess.

Analytics windows go out to 90 days, so this finds what is underperforming now rather than comparing against last year.

## Why it does not edit

Refreshing a post is an editorial decision. The queue gives an editor the evidence, the traffic number, and the specific change to make, which is the part that takes the longest, and leaves the judgment where it belongs.

Reads your real traffic from Cosmic Insights, finds the published pages losing readers, and files a prioritized refresh queue with the numbers that justify each one. Never touches the posts.

Insights-Driven Refresh

A Demo Articles type with 3 incomplete articles to work on
A Content Audit type to log each run
Elena, SEO Analyst as the agent
One weekly workflow, schedule off until you enable it

# Content Polish Pass

A weekly workflow that fills the supporting fields your published content is missing, describes images that have no alt text, and logs what it changed.

## What it installs

- `demo-articles`: three deliberately incomplete articles so the first run has work to do
- `content-audit`: a log of each run
- Agent: Elena, SEO Analyst (`seo-analyst`)
- One weekly workflow, created with its recurring schedule disabled

## Install it

Hosted MCP endpoint: `https://mcp.cosmicjs.com/v1/buckets/{bucket-slug}`

Or install in one click from https://www.cosmicjs.com/marketplace/workflows/content-polish-pass

## The prompt

```text
Fill in the supporting fields your published content is missing, then describe the images that have no alt text.

Part one: object fields.
1. Find published objects missing any of: excerpt, seo_title, seo_description.
2. Process at most {{max_objects}} objects. Stop when you reach that number, even if more remain. This keeps the run inside the token budget.
3. For each object, read the title and content, then write only the fields that are empty:
   - excerpt: one or two sentences in the author's voice, saying what the piece covers. Not a truncated first paragraph.
   - seo_title: under 60 characters, most important keyword first, no trailing brand suffix.
   - seo_description: under 160 characters, describes what the reader gets, ends with a reason to click.
4. Preserve the author's voice. Do not rewrite body content or titles, and do not touch any field that already has a value.

Part two: image alt text.
5. Call get_media with missing_alt_text=true to list images with no description. Handle at most {{max_images}} of them.
6. For each one, look at the image and call update_media with alt text that describes what is in it for someone who cannot see it: specific, under about 125 characters, no "image of" preamble, no keyword stuffing.
7. Alt text goes on the media record, never into an object field. One description on the media record covers every object that references that image.
8. If an image is purely decorative, leave it alone rather than inventing filler. Note it in the summary instead.

When finished, create one object in the content-audit type recording:
- run_date: today
- objects_scanned: how many objects you examined
- fields_filled: how many individual object fields you wrote
- images_described: how many media records you gave alt text
- summary: a short markdown list of what you changed, one line per object or image
- details: JSON array of { object_slug or media_id, fields_written }

If you found nothing to fill, still create the audit object noting zero changes. A run that reports honestly is more useful than one that invents work.
```

## Where alt text goes

Alt text is written onto the media record, not into a field on the object that happens to use the image. One image described once is then correct everywhere it appears, and stays correct when another object reuses it. This is why the installed content model has no alt text field.

## Cost

The object half of the run costs roughly what a metadata pass costs. Describing images adds an image to the prompt for each one, so the per-image cost is higher: keep the image cap low on the Free plan.

Fills the excerpts, SEO titles, and descriptions your published content is missing, writes alt text onto images that have none, and logs exactly what it changed.

Working AI workflows, one click to install

Don't see the workflow you need?

Start automating with AI workflows