create-ailk 0.10.0 → 0.11.1

package/templates/.claude/skills/check-site/references/findings-glossary.md

@@ -1,140 +0,0 @@
-# Findings Glossary — Per-Rule Plain-Language Explanations
-
-What each AEO rule means in plain language, what its `pass: false`
-result indicates, and what the consumer can do about it. Used by the
-`check-site` skill in Step 6 (drill-down) and Step 7 (fix-tool
-pointer).
-
-The structure deliberately matches `perRule[].id` from the audit
-JSON so the skill can grep this file for `## <rule-id>` to find the
-explanation. New rules added to `@working-theory/aeo` will not appear here
-until this file is updated; render unrecognized rule IDs as the raw
-ID (no synthesis).
-
----
-
-## schema-coverage
-
-**Plain language:** every page on your site should emit at least
-one JSON-LD object whose `@type` matches what the page is _about_.
-A `/pricing` page should have `Product` (or `Service`, or
-`OfferCatalog`) schema; a `/about` page should have `AboutPage`;
-and so on.
-
-**`pass: false` means:** one or more pages emit no JSON-LD whose
-`@type` matches the registry's expected `pageType` for that page's
-content type. The `evidence` field names which pages.
-
-**Why it matters:** structured data is what answer engines (Google
-SGE, Perplexity, ChatGPT search) read to understand your pages. A
-page with no schema is invisible to citation; a page with the
-wrong schema gets miscategorized.
-
-**Fix tool:** `add-page`'s `schema:` frontmatter override — set the
-schema type the registry expects (the audit names it) on the page's
-frontmatter. The typed builder emits a `<JsonLd>` block matching the
-page's content.
-
----
-
-## jsonld-validity
-
-**Plain language:** every JSON-LD block on the site should be
-well-formed schema.org markup with all required fields present
-and non-empty for its `@type`. Missing the `name` on an
-`Organization`, missing `headline` on an `Article`, etc., breaks
-schema validity.
-
-**`pass: false` means:** at least one JSON-LD block has missing or
-empty schema.org-required fields for its declared `@type`.
-
-**Why it matters:** answer engines and crawlers may silently drop
-invalid blocks. The page exists, the JSON-LD exists, but the
-citation surface is broken because the block doesn't parse as
-valid schema.org.
-
-**Fix tool:** `add-page`'s `schema:` frontmatter override — replace
-the malformed block. For one-off edits to MDX, the consumer can also
-hand-edit the JSON-LD inline; the frontmatter override is the safer
-path because it uses typed builders.
-
----
-
-## entity-markup
-
-**Plain language:** somewhere on your site (typically the home
-page or layout root), there should be exactly one identity entity
-JSON-LD — `Organization` if the site represents a business, or
-`Person` if the site represents an individual (a solo lawyer,
-realtor, consultant, author, etc.). The audit picks up on
-`identityMode` (configured in `ailk.config.ts`).
-
-**`pass: false` means:** no `Organization` block (when
-`identityMode: organization`) or no `Person` block (when
-`identityMode: person`) was emitted by any audited page.
-
-**Why it matters:** the identity entity is what ties every other
-piece of structured data together. Without it, schema.org
-relationships (`isPartOf`, `author`, `provider`, `mainEntity`)
-have nothing to anchor to.
-
-**Fix:** Manual MDX or layout edit — ensure your home page (or a
-layout component rendered on every page) emits an
-`Organization` (or `Person`) JSON-LD block. The `<JsonLd
-schema={OrganizationSchema(...)} />` pattern from `@working-theory/schema`
-is the one this is going to ship as. `add-page`'s `schema:`
-frontmatter override can land the block on a specific page if you'd
-rather; but typically
-identity goes in a layout, not a leaf page.
-
----
-
-## faq-howto-incentive
-
-**Plain language:** pages that emit `FAQPage` or `HowTo` schema
-get a small bonus signal. This rule **never fails a page** — it's
-purely incentivizing. Absence of FAQ/HowTo blocks is neutral, not
-a failure.
-
-**`pass: true` and `bonus: true` per page means:** that page
-earned the incentive (has FAQ or HowTo schema).
-
-**`pass: true` and `bonus: false` per page means:** that page is
-fine, just didn't earn the bonus.
-
-**Why it matters:** answer engines preferentially cite pages with
-explicit Q&A or step-by-step content because those are easier to
-quote directly into a generated response. Adding an FAQ or HowTo
-block to relevant pages is a low-effort score boost.
-
-**Fix tool:** `add-page`'s `schema:` frontmatter override — add an
-`FAQPage` block to your `/pricing` or `/contact` page (anywhere your
-customers ask predictable questions), or a `HowTo` block to any
-process/instructions content. `check-site` will surface this as
-an _incentive_ in drill-down, not a finding to "fix."
-
----
-
-## always-passes / always-fails
-
-These are **test rules** that exist for the audit's own test suite
-in `@working-theory/aeo`. They should not appear on a real consumer site
-unless the rule list has been customized. If you see one of these
-IDs in your audit output, the consumer's `ailk-audit` CLI may have
-a non-standard rule list — that's a setup question, not a content
-finding.
-
----
-
-## Unrecognized rule IDs
-
-If the audit JSON includes a rule ID not listed above, the rule is
-new (added to `@working-theory/aeo` after this glossary was last updated).
-Render it as:
-
-> Rule `<id>` — `<evidence text from the audit JSON>` — not in
-> the local glossary; consult the `@working-theory/aeo` package docs.
-
-Do not invent a plain-language explanation for an unrecognized
-rule. The consumer can read the rule's `description` field from
-the JSON if they want the formal definition.

package/templates/.claude/skills/check-site/references/severity-levels.md

@@ -1,114 +0,0 @@
-# Severity Levels — Score Banding + Severity Mapping
-
-The AEO audit JSON does **not** include explicit severity fields.
-Severity is **derived** by the `check-site` skill from each rule's
-`weight` and `pass`. This file is the source of truth for that
-mapping.
-
-The skill applies these rules in `SKILL.md` Step 5.
-
----
-
-## Severity tiers
-
-| Tier     | Source signal                                   | Meaning                                                                 |
-| -------- | ----------------------------------------------- | ----------------------------------------------------------------------- |
-| Critical | `pass: false` AND `weight >= 10`                | Rule that materially affects citation readiness; failure is blocking.   |
-| Warning  | `pass: false` AND `weight` in `[1, 9]`          | Rule that nudges citation quality; failure is fixable, not blocking.    |
-| Info     | `pass: true` AND `weight: 0` (incentive rules)  | Positive signal earned. Bonus, not a finding.                           |
-| Neutral  | `pass: true` AND `weight: 0` AND `bonus: false` | Page is fine but didn't earn the incentive. Don't surface unless asked. |
-
-A rule with `pass: false` AND `weight: 0` is **not possible** today
-(incentive rules are designed to never fail — see
-`faq-howto-incentive` in `@working-theory/aeo`). If one ever appears,
-treat it as Info (the rule's own design says failures are neutral).
-
----
-
-## Why weight thresholds, not explicit severity
-
-The AEO type system intentionally keeps rules weight-based, not
-severity-based. Reasons:
-
-- **Score arithmetic stays simple.** `passing-weight / total-weight`
-  is the score; introducing severity as a separate axis would force
-  every rule to choose two attributes (weight AND severity) when
-  one is enough.
-- **The skill is the right place for the translation.** Consumers
-  don't care about weights — they care about "should I fix this?".
-  The skill turns "weight 10 fail" into "Critical" because that's
-  the language consumers can act on.
-- **Rule authors don't have to think about severity.** A new rule
-  added to `@working-theory/aeo` gets a weight (its impact on the score)
-  and the skill maps that to a severity tier automatically. No
-  coupling between rule authoring and consumer-facing UX.
-
----
-
-## Score banding (optional)
-
-When the consumer asks "is this a good score?", you can map the
-numeric score to a band. This is optional — Step 4 always emits
-the raw score first.
-
-| Score  | Band              | Hint                                                             |
-| ------ | ----------------- | ---------------------------------------------------------------- |
-| 90–100 | Excellent         | All critical rules pass; site is well-instrumented for citation. |
-| 75–89  | Good              | Probably a critical or warning fixable on a couple of pages.     |
-| 50–74  | Needs work        | Multiple critical rules failing; address those first.            |
-| 0–49   | Foundational gaps | Site likely has no schema or invalid schema across most pages.   |
-
-Hint sentences are suggestions; adapt phrasing to the consumer's
-context. Don't quote the band tag verbatim if a more natural
-phrasing fits the conversation ("you're at 87 — couple of fixes
-away from clean").
-
----
-
-## Severity counting for the summary line
-
-Step 5 of SKILL.md asks for a summary like:
-
-```
-2 critical · 1 warning · 0 info
-```
-
-Counts are computed as:
-
-- **Critical count** = count of `perRule[]` entries where
-  `pass === false && weight >= 10`.
-- **Warning count** = count of `perRule[]` entries where
-  `pass === false && weight >= 1 && weight < 10`.
-- **Info count** = count of `perRule[]` entries where
-  `pass === true && weight === 0` (i.e., earned incentives).
-
-Some rules surface per-page failures (`perRule[].perPage[]`).
-Those are deeper-level findings the skill can drill into in Step 6;
-they don't change the rule-level severity counts. A `schema-coverage`
-rule with `pass: false` and 5 failing pages is **one** critical
-finding (the rule failed), with 5 page-specific evidence entries
-for drill-down.
-
----
-
-## What this skill does NOT classify as severity
-
-- **`bonus: true` per page** is not a finding; it's a positive
-  signal. Surface it on drill-down ("These pages earned the FAQ
-  bonus: …") but don't include it in the severity summary.
-- **Schema-version mismatch** (a `meta.schemaVersion` from the
-  audit that doesn't match the consumer's `@working-theory/schema`) is not a
-  rule failure — it's a setup-drift signal. Surface only if the
-  consumer asks why the score might be inconsistent across runs.
-
----
-
-## Future rules
-
-When `@working-theory/aeo` adds a new rule, this glossary may not name
-it. The severity mapping still works because it keys off `weight`
-and `pass` only — both fields are guaranteed by the
-`PerRuleResult` type. New critical-tier rules will surface as
-`Critical` automatically; new warnings as `Warning`. The findings
-glossary may lag in offering plain-language explanations until
-this template is updated.

package/templates/.claude/skills/fill-page/SKILL.md

@@ -1,199 +0,0 @@
----
-name: fill-page
-description: Fill one existing page's section content from a category profile. Tier 1 writes realistic, labelled sample content for the category (a plumber's home page, say). Tier 2 asks the owner the profile's questions and writes the company's own first draft from their answers and `_site.mdx`. Use when the user says "fill this page", "fill the home page for a plumber", "write sample content for my services page", or "write my real copy from what I tell you". It never creates a page, never changes a page's section stack, and never edits `_site.mdx`.
----
-
-# fill-page
-
-Replace one page's `{brace}` instructions with content, reading the
-content from a **category profile** (`profiles/<slug>.yaml` beside this
-file). A profile is the data for one business type: the schema.org
-subtype, the typical offerings, the proof buyers expect, the buyer's own
-words, and the questions to ask the owner.
-
-Two tiers:
-
-| Tier | Source                                                   | Result                                     | `placeholder` |
-| ---- | -------------------------------------------------------- | ------------------------------------------ | ------------- |
-| 1    | the profile                                              | realistic sample content for the category  | `true`        |
-| 2    | `_site.mdx` + the owner's answers (`content/_intake.yaml`) | the company's own first draft              | by the rule in Step 2.4 |
-
-`placeholder: true` in a page's frontmatter makes the site render a
-**PLACEHOLDER — REPLACE BEFORE LAUNCH** label at the top of the page.
-The label is for people. Structured data reaches agents without it, so
-tier-1 content must be safe to publish by itself (see the never-invent
-list).
-
-## Inputs
-
-- **The page file** — `content/<locale>/<Type>/<slug>.mdx`. It must
-  already exist; `add-page` creates pages.
-- **The page type** — the frontmatter `type`.
-- **The profile slug** — a file under `profiles/` (e.g. `plumbing`).
-  Ask if the user did not name one. If there is no profile for their
-  category, say so and stop.
-- **The tier** — 1 unless the user asks for their own copy.
-
-## What never changes
-
-- The page's **section stack**: every section's `id` and `type`, in
-  order. Never add, remove or reorder a section. The starter's manifest
-  records each page's sections, and a changed stack fails its check.
-- Each section's **layout options** that are already present:
-  `variant`, `columns`, `layout`, `initialOpen`, `size` and the like.
-  They are the site's locked look.
-- Link targets (`href`) that are already present, except a link to a
-  Service page, which follows that page's slug (Step 1.3).
-- `{/* … */}` comments in the MDX body.
-- `_site.mdx`. Identity strings (the company name) are read from it,
-  never written to it.
-
-## Never invent (tier 1)
-
-At tier 1, write none of these. Remove any you find in the page:
-
-- `price`, `priceCurrency`, `availability` or `stripe` — each feeds the
-  schema.org `Offer` an agent quotes as the company's price.
-- A person's name or another company's name.
-- A phone number, a street address, or a licence or registration number.
-- A town, a county, or a distance: the service area is a company fact.
-- Testimonials: `author` is the literal `Sample customer`; no `company`,
-  `rating` or `avatar`.
-- Statistics a reader would take as measured (a count of jobs, a years
-  figure). Use the profile's `proof[]` labels as words, not numbers.
-
-The company name is the one identity string tier 1 may write, and it
-comes from `_site.mdx` `siteIdentity.name`.
-
-## Step 0 — Read
-
-1. Read `.ailk-site-manifest.json` at the site root, the site's roster
-   of record: `modules` (the modules this site has) and `rows` (every
-   route it carries). Add any module the `# Modules:` line of
-   `architecture.yaml` names that `modules` does not — `create-ailk
-   add-module` records a module it adds there; with no manifest, or none
-   carrying `modules`, that line is the set. `level`, when present, never
-   decides anything here.
-
-   The page's `type` must render on this site: its **Module** in
-   `../add-page/references/page-types.md` is in that set, or a row
-   already renders it (`rows[].pageType` — a Free starter's `/meet/<slug>`
-   `BookCall` placeholders). When it does not,
-   say which module renders the type and which level carries it, point at
-   the `upgrade-plan` skill, and stop. Never fill a page this site cannot
-   render.
-2. Read the profile: `profiles/<slug>.yaml`.
-3. Read `content/_site.mdx` for `siteIdentity.name`.
-4. Read the page file. Note its stack (`sections[].type` in order).
-5. For each section type in the stack, read its data schema: the
-   `<Type>SectionDataSchema` (or `<Type>DataSchema`) export in the
-   installed `@working-theory/validation`'s `schemas/page-sections`. Fill
-   only fields the schema declares. Every field a section renders from
-   copy gets content; a field the source page did not use stays unused.
-6. Find the route that renders this page type under `apps/web/app/[locale]/`
-   and read its `bodyMode`. When it is `"mdx-body"`, the MDX body is
-   rendered and must be filled too. Otherwise the body is a short note,
-   and you rewrite it as one plain sentence that names no braces.
-
-`references/section-sources.md` maps each section type to the profile
-fields and intake answers that fill it.
-
-## Step 1 — Tier 1: sample content
-
-1. **Sections.** For each section, in place, write every copy field from
-   the profile using `references/section-sources.md`:
-   - offerings → `items` entries (`title` = the offering `name`,
-     `description` = its `job`, `link.href` = `/services/<kebab name>`
-     only when the manifest's `rows` carry `/services/[slug]`; otherwise
-     no `link`, so no entry points at a page the site does not have);
-   - vocabulary → headlines, eyebrows and FAQ questions (the buyer's own
-     words: the `problem` list for what went wrong, `outcome` for what
-     they get);
-   - proof → `stats` labels and `testimonials` quotes, under the
-     never-invent list.
-   Keep `id`, `type` and every layout option.
-2. **Frontmatter.** Rewrite `title` and `description` without braces.
-   Use the company name from `_site.mdx` where the page names the
-   company. On a page that carries `provider.name`, set it to the company
-   name. Drop `schema.areaServed`; set `schema.serviceType` to the
-   offering name. Remove every key the never-invent list names.
-3. **Service pages.** A `Service` page is one offering. The user names
-   the offering, or you take the first profile offering that no other
-   Service page carries yet. Set `title` and `schema.serviceType` to the
-   offering `name`, and `slug` and the file name to its name in kebab
-   case (`Drain clearing` → `drain-clearing`): rename the file, never
-   copy it. To give every offering a page, the user first adds one
-   Service page per offering (`add-page`, or a copy of an existing one),
-   then runs this skill on each.
-4. **Body.** When the route renders `mdx-body`, rewrite each paragraph
-   and list item under the page's existing headings in the category's
-   words. Keep the headings, keep the order, keep the comments. Drop
-   every `\{…\}` instruction. Under a price heading, say how the job is
-   priced (the offering's `pricing`: `quote`, `fixed`, `hourly`,
-   `subscription`) in words, with no figure.
-5. **Label.** Set `placeholder: true` in the frontmatter.
-6. **Check** (below).
-
-## Step 2 — Tier 2: the company's own draft
-
-1. **Ask.** Ask each `intake[]` question from the profile, in order, one
-   at a time. Record the answers in `content/_intake.yaml`:
-
-   ```yaml
-   answers:
-     offerings: [Drain clearing, Emergency call-out]
-     service_area: "…"
-     faq: null # unanswered
-   ```
-
-   A list answer stays a list. An unanswered or skipped question is
-   `null`. Offerings are named exactly as the profile names them.
-2. **Fill.** Fill the page as in Step 1, but from `_site.mdx` and the
-   answers first; the profile fills only what the answers leave open.
-   - A profile offering the owner does not offer appears on no page:
-     remove its `items` entries, and ask before deleting its Service
-     page (the one file this skill may delete).
-   - A price appears only when the owner gave one, with `priceCurrency`.
-   - The company name appears in each page's frontmatter (`title` or
-     `description`), and the service area in the home hero when given.
-   - A section whose sources have no answer keeps its tier-1 sample
-     content.
-3. **Never invent** still holds for everything the owner did not give.
-   Testimonials stay `Sample customer` unless the owner supplies a
-   customer's name with permission to publish it.
-4. **Label.** Set `placeholder: false` only when every section is filled
-   from company facts:
-   - every section type in the stack appears in the `fills` of at least
-     one intake item whose answer is not empty, and
-   - when the stack has a `hero` or `cta`, `_site.mdx` has
-     `siteIdentity.name`.
-
-   A page with no sections is judged on its body: a `Service` page is
-   cleared only when the `offerings` answer names its offering; any
-   other page with no sections keeps `placeholder: true`. In every other
-   case, keep `placeholder: true`.
-5. **Check** (below).
-
-## The check
-
-Run the site's own structured-data check. It reads every content page
-through the same frontmatter and section schemas the site renders with,
-and validates each page's JSON-LD:
-
-```bash
-pnpm --filter web test -- lib/__tests__/structured-data.test.tsx
-```
-
-Then search the filled file for a `{` or `}` in any frontmatter string or
-in the body outside `{/* … */}` comments. Fix everything either reports
-and run both again. Stop only when both are clean.
-
-## What this skill does not do
-
-- Tier 3 (the Messaging Canvas through the content pipeline).
-- Create a page — use `add-page`.
-- Edit `_site.mdx`, the nav or the page roster. A profile's `roster` and
-  `nav` entries are declared for a later step and are not applied here,
-  and a profile page type this site cannot render (Step 0) is never
-  suggested.
-- Write a price, a name or an address the owner did not give.

package/templates/.claude/skills/fill-page/profiles/plumbing.yaml

@@ -1,80 +0,0 @@
-# Category profile — Local Plumbing (#6640; starter-template contract § D).
-# Read by the `fill-page` skill: tier 1 fills a page with labelled sample
-# content from this file; tier 2 asks `intake[]` and fills from the answers.
-# Twin: templates/.claude/skills/fill-page/profiles/plumbing.yaml (byte-identical).
-slug: plumbing
-shape: local-business-service
-subtype: Plumber
-secondary: Person
-offerings:
-  - name: Drain clearing
-    job: Clears blocked sinks, showers, toilets and main drains, and says what caused the blockage.
-    pricing: quote
-  - name: Water heater installation
-    job: Removes the old tank or boiler and fits, tests and registers a new water heater.
-    pricing: fixed
-  - name: Emergency call-out
-    job: A plumber at the door the same day for a burst pipe, a flood or no water at all.
-    pricing: hourly
-  - name: Leak detection and repair
-    job: Finds the hidden leak behind a wall or under a floor and fixes it with the least damage.
-    pricing: quote
-proof:
-  - kind: credential
-    label: Licensed and insured
-  - kind: reviews
-    label: Reviews from local customers
-  - kind: response-time
-    label: Same-day response on emergency calls
-  - kind: guarantee
-    label: Workmanship guaranteed
-vocabulary:
-  problem:
-    - burst pipe
-    - blocked drain
-    - no hot water
-    - leaking tap
-    - low water pressure
-    - water stain on the ceiling
-  service:
-    - drain clearing
-    - water heater install
-    - emergency call-out
-    - leak repair
-    - pipe replacement
-  outcome:
-    - same-day fix
-    - hot water back on
-    - no water damage
-    - upfront quote
-    - tidy job, nothing left behind
-roster:
-  - op: add
-    route: /meet/emergency
-    pageType: BookCall
-    reason: Emergency jobs book a call, not a form.
-  - op: drop
-    route: /pricing
-    reason: Most plumbing work is quote-priced, so a price table misleads.
-nav:
-  Services: Plumbing services
-content_posture: sample
-intake:
-  - id: offerings
-    ask: Which of these jobs do you take on, and is there one you do not list? (Drain clearing, water heater installation, emergency call-out, leak detection and repair.)
-    fills: [hero, items]
-  - id: service_area
-    ask: Which towns, postcodes or radius do you cover?
-    fills: [hero, cta]
-  - id: about
-    ask: How did the business start, who does the work, and what will you not take on?
-    fills: [content-block]
-  - id: proof
-    ask: What can a customer check — your licence, your insurance, your reviews, your response time, your guarantee?
-    fills: [stats, testimonials, social-proof]
-  - id: faq
-    ask: What do customers ask before they book, and what do you tell them?
-    fills: [faq]
-  - id: contact
-    ask: How should a customer reach you — phone, form or booking — and how fast do you reply?
-    fills: [cta]

package/templates/.claude/skills/fill-page/references/section-sources.md

@@ -1,41 +0,0 @@
-# Section sources
-
-Where each section's copy comes from. **Profile** is tier 1's source;
-**Intake** lists the `intake[]` answers that fill the section at tier 2
-(the same ids appear in each question's `fills`). Fields not named here
-are layout options: keep them as they are.
-
-| Section type    | Copy fields                                                                 | Profile (tier 1)                                                                                                 | Intake (tier 2)                          |
-| --------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------- |
-| `hero`          | `eyebrow`, `headline`, `subheadline`, `primaryCta.label`, `secondaryCta.label` | `vocabulary.problem` + `vocabulary.outcome` for the headline; the category name for the eyebrow                 | `offerings`, `service_area`              |
-| `items`         | `headline`, `description`, `items[].title`, `items[].description`, `items[].link` | one item per `offerings[]` entry: `title` = `name`, `description` = `job`, `link.href` = `/services/<kebab name>` | `offerings`                              |
-| `cta`           | `headline`, `description`, `primaryCta.label`, `secondaryCta.label`         | `vocabulary.outcome`                                                                                             | `service_area`, `contact`                |
-| `content-block` | `eyebrow`, `headline`, `body`                                               | `proof[].label` and `vocabulary.service`, with no names, places or numbers                                        | `about`                                  |
-| `faq`           | `headline`, `items[].question`, `items[].answer`                            | questions in `vocabulary.problem` words; answers from `offerings[].pricing` and `proof[]`                        | `faq`                                    |
-| `stats`         | `headline`, `items[].label`, `items[].value`                                | `proof[].label` as the label; a value only when it is not a measurement (e.g. `Same day`)                        | `proof`                                  |
-| `testimonials`  | `headline`, `items[].quote`, `items[].author`                               | quotes in `vocabulary.outcome` words; `author: Sample customer`; no `company`, `rating` or `avatar`              | `proof`                                  |
-| `social-proof`  | `headline`, labels                                                          | `proof[].label`                                                                                                  | `proof`                                  |
-
-A section type not in this table: fill its copy fields from the profile's
-`vocabulary` and leave its data otherwise as it was. At tier 2 no intake
-answer fills it, so a page carrying it keeps `placeholder: true`.
-
-## Frontmatter
-
-| Key                    | Tier 1                                             | Tier 2                                      |
-| ---------------------- | -------------------------------------------------- | ------------------------------------------- |
-| `title`, `description` | the category's words; the company name from `_site.mdx` where the page names the company | the company name and the owner's answers    |
-| `provider.name`        | `siteIdentity.name`                                | `siteIdentity.name`                         |
-| `schema.serviceType`   | the offering `name`                                | the offering `name`                         |
-| `schema.areaServed`    | removed                                            | the `service_area` answer                   |
-| `price`, `priceCurrency`, `availability`, `stripe` | removed                | only a price the owner gave, with its currency |
-| `placeholder`          | `true`                                             | by the rule in `SKILL.md` Step 2.4           |
-
-## Pricing words (Service bodies, FAQ answers)
-
-| `pricing`      | Say                                                                 |
-| -------------- | ------------------------------------------------------------------- |
-| `quote`        | priced after a look at the job; the quote is given before work starts |
-| `fixed`        | one fixed price for the job, agreed before work starts               |
-| `hourly`       | charged by the hour on site, with the call-out rate stated up front  |
-| `subscription` | a regular plan, billed on a schedule                                 |