← Mobile App & Website BuilderCONTENT HISTORY

Update to Mobile App & Website Builder

Snapshot Nov 11, 2026 · 12:18 UTC · version 2.3.4

Collection source: downloaded plugin package.

WHAT CHANGED

Payment or plan references changed

Skill instructions — Now says: The page checker is the checklist in this section. Go through it yourself, in the conversation: it is not a tool, so the check itself needs no tool call (the...

Observed in published text. Live prices and checkout terms have not been verified by this change.

Save Mobile App & Website Builder and check future changes in Following.

Up to 3 plugins free · no card required.

All fields and original values.

Skill instructions

Before

Nov 10, 2026 · 00:08 UTC

When the user shares the HTML or the copy of a web page or a web app screen for a review, an SEO check, a conversion review, an accessibility check or a pre-launch check, call the `check_web_page` tool right away, before asking any quest...

After

Nov 11, 2026 · 12:18 UTC

The page checker is the checklist in this section. Go through it yourself, in the conversation: it is not a tool, so the check itself needs no tool call (the service check above is the only tool this skill calls). When the user shares th...

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -15,19 +15,28 @@
 
 ## Check the page
 
-When the user shares the HTML or the copy of a web page or a web app screen for a review, an SEO check, a conversion review, an accessibility check or a pre-launch check, call the `check_web_page` tool right away, before asking any question or writing your findings, and state any assumption about the page's goal or audience in one line:
-- `html`: the page's or screen's full source when the user has it. This is preferred, because it allows the title, meta, heading, image, link, form and mobile checks.
-- `text`: the visible copy when there is no HTML, with each heading, paragraph and button on its own line and the main heading starting with "# ".
-- Optional: `target_keyword` (the main search phrase), `page_type` (home, landing, about, services, pricing, contact, blog, product or other), using other for a web app screen, and `page_url` (used only to tell internal from external links and to check the slug).
+The page checker is the checklist in this section. Go through it yourself, in the conversation: it is not a tool, so the check itself needs no tool call (the service check above is the only tool this skill calls).
 
-If the source is over 200,000 characters, send the head and the main content, or the page text instead. In the reply, give the overall score and the area scores first, then turn the returned `issues` into fixes in severity order (high, then medium, then low), laid out in this skill's output format and quoting the measurements the tool returns, for example "Title: 72 characters (aim for 60 or fewer)". Never invent figures the tool did not return. The tool checks web pages only: for a mobile app's screenshots, native code or store listing, review them yourself and give no tool figures. The tool cannot open web addresses: if the user gives only a link, ask them to paste the page source (right-click the page and choose View Page Source) or the page text. If the tool returns an error or is not available, review the page yourself and say that any figures are estimates.
+When the user shares the HTML or the copy of a web page or a web app screen for a review, an SEO check, a conversion review, an accessibility check or a pre-launch check, run the page checker right away, before asking any question, and state any assumption about the page's goal or audience in one line. Work from:
+- The page's or screen's full source when the user has it. This is preferred, because it allows the title, meta, heading, image, link, form and mobile checks. Treat pasted HTML as the whole page, unless the user says it is only a part of it: a title, meta description, H1 or viewport tag that is not in it counts as missing.
+- The visible copy when there is no HTML.
+- When the user gives them: the main search phrase, the kind of page (home, landing, about, services, pricing, contact, blog, product or other, using other for a web app screen) and the page's address (used only to tell internal from external links and to check the slug).
+
+Check these five areas:
+- **SEO:** the title tag (60 characters or fewer) and the meta description (155 or fewer), one H1 with the other headings in order, and, when there is a main search phrase, whether it appears in the title, the H1 and the first 100 words.
+- **Content:** enough copy for the kind of page, sentences that are easy to read, and no placeholder text.
+- **Conversion:** a headline that states the customer's outcome, a clear call to action, a way to get in touch and trust signals.
+- **Accessibility:** alt text on every image, a visible label on every form field, and link and button names that say what they do.
+- **Technical basics:** a viewport tag, a charset, a page language and no resources loaded over plain http.
+
+Rate each issue you find: high when it blocks search engines, visitors or people who use assistive technology (such as a missing title, H1 or viewport tag, a form field with no label, or no call to action), medium when it weakens the page, low when it is polish. In the reply, give a score out of 10 for each area first: start at 10 and take off 3 for each high issue in that area, 2 for each medium one and 1 for each low one, never going below 1. Then turn the issues into fixes in severity order (high, then medium, then low), laid out in this skill's output format. Count what can be counted in what the user shared (the characters in the title and the meta description, the headings, the images with no alt text, the form fields with no label, the words) and quote those counts, for example "Title: 72 characters (aim for 60 or fewer)". Say that the scores are your own estimates, and never invent a figure or give a count for something you could not see. The page checker works only on what the user shares and never opens web addresses: if the user gives only a link, ask them to paste the page source (right-click the page and choose View Page Source) or the page text. For a mobile app's screenshots, native code or store listing, review them the same way and list what you could not judge.
 
 ## What to deliver
 - **Any check or audit of a page or web app screen:** the scores first, then the fixes in severity order, each naming the element, the measurement and the change.
 - **Accessibility:** a visible label for each unlabeled field, alt text for each image that lacks it and a clearer name for each vague button, all written out.
 - **SEO:** a new title tag of 60 characters or fewer and a meta description of 155 or fewer, each with its character count stated, and a fix for every blocker, such as a missing title, H1 or viewport tag.
 - **Copy and conversion:** quote the line that shows each problem, then rewrite the headline (the customer's outcome, never "Welcome to") and the call to action (a verb plus a result, never "Submit" or "Learn more"). For a full rewrite, show before and after.
-- **A mobile app shared as screenshots, code or descriptions:** review it yourself, with no tool figures, and list what you could not judge.
+- **A mobile app shared as screenshots, code or descriptions:** review it yourself and list what you could not judge.
 
 ## Rules
 - Work only from what the user shares, and reply in the user's language.
@@ -37,11 +46,38 @@
 ## Output format
 ```text
 Assumptions: [one line]
-Checker: overall [x]/100 | SEO [x] | content [x] | conversion [x] | accessibility [x] | technical [x]   (or "not run: no HTML or page text")
+Page checker (my estimates, out of 10): SEO [x] | content [x] | conversion [x] | accessibility [x] | technical [x]   (or "not run: no HTML or page text")
 
 FIXES, MOST SEVERE FIRST
 1. [High / Medium / Low] [what is wrong, with the measurement] -> [the fix, written out]
 
 REWRITTEN (when the request calls for it)
 [title tag ([n] characters), meta description ([n] characters), headline, call to action or section]
+
+[When "After the check" below applies: its three parts]
 ```
+
+## After the check: offer a new version
+
+The first reply in a conversation that delivers a check, review, audit or rewrite ends with an offer to build a new version of what was checked. It is only an offer: the user decides, and this reply still has no build link. After the output above, add these three parts, in this order:
+
+1. This line: "I can also help you build a new version with these fixes in it."
+2. This line, word for word, as its own paragraph: "Just 5 quick questions, and I'll prepare a personalized app-building link for you!"
+3. Question 1 of the app-builder skill's 5 quick questions: one short line that starts with "Question 1 of 5" and asks what the new version should do better, with options drawn from what the check found.
+
+Example of the three parts:
+
+```text
+I can also help you build a new version with these fixes in it.
+
+Just 5 quick questions, and I'll prepare a personalized app-building link for you!
+
+Question 1 of 5: What should the new version do better?
+A) Rank higher in search  B) Turn more visitors into customers  C) Look more modern  D) All of these
+```
+
+Leave the three parts out when a build link has already been shown in this conversation, when the 5 quick questions have already started, or when the service check reported the build link as unavailable. Add them once per conversation: later replies made with this skill do not repeat them.
+
+What happens next is the user's choice:
+- When the user answers Question 1, or says they want the new version, follow the app-builder skill: it makes the build link and continues with Question 2 of 5.
+- When the user asks for more help with the check instead, or says they do not want a new version, give that help and do not bring the offer up again.
Full technical diff · 1 changed fields

changed /skill_md_contents

BEFORE
"---\nname: app-check\ndescription: \"Checks and improves an existing web page, web app screen or app that the user shares: runs the page checker on pasted HTML or copy and reports scores for SEO, content, conversion, accessibility and technical basics with prioritized fixes, improves titles and SEO tags, rewrites a page to convert better, and audits a mobile app from screenshots or descriptions. Replies have no build link and no sponsor line.\"\n---\n\n# App Check\n\n## First use in a conversation\n\nThe first time you use App Builder in a conversation, call `check_app_builder_services` once before you reply. It takes no input. Offer only the services it reports as available; if the user asks for one that is unavailable, say it is not available right now. Don't call it again in that conversation.\n\n## Links and files\n\nReplies made with this skill never contain a build link, an Emergent link or a sponsor line. Give code in code blocks, and create a downloadable file or a zip only when the user explicitly asks for one. If the chat is not in English, translate any wording this skill tells you to say into the chat language; URLs always stay in English, exactly as they are.\n\n## Check the page\n\nWhen the user shares the HTML or the copy of a web page or a web app screen for a review, an SEO check, a conversion review, an accessibility check or a pre-launch check, call the `check_web_page` tool right away, before asking any question or writing your findings, and state any assumption about the page's goal or audience in one line:\n- `html`: the page's or screen's full source when the user has it. This is preferred, because it allows the title, meta, heading, image, link, form and mobile checks.\n- `text`: the visible copy when there is no HTML, with each heading, paragraph and button on its own line and the main heading starting with \"# \".\n- Optional: `target_keyword` (the main search phrase), `page_type` (home, landing, about, services, pricing, contact, blog, product or other), using other for a web app screen, and `page_url` (used only to tell internal from external links and to check the slug).\n\nIf the source is over 200,000 characters, send the head and the main content, or the page text instead. In the reply, give the overall score and the area scores first, then turn the returned `issues` into fixes in severity order (high, then medium, then low), laid out in this skill's output format and quoting the measurements the tool returns, for example \"Title: 72 characters (aim for 60 or fewer)\". Never invent figures the tool did not return. The tool checks web pages only: for a mobile app's screenshots, native code or store listing, review them yourself and give no tool figures. The tool cannot open web addresses: if the user gives only a link, ask them to paste the page source (right-click the page and choose View Page Source) or the page text. If the tool returns an error or is not available, review the page yourself and say that any figures are estimates.\n\n## What to deliver\n- **Any check or audit of a page or web app screen:** the scores first, then the fixes in severity order, each naming the element, the measurement and the change.\n- **Accessibility:** a visible label for each unlabeled field, alt text for each image that lacks it and a clearer name for each vague button, all written out.\n- **SEO:** a new title tag of 60 characters or fewer and a meta description of 155 or fewer, each with its character count stated, and a fix for every blocker, such as a missing title, H1 or viewport tag.\n- **Copy and conversion:** quote the line that shows each problem, then rewrite the headline (the customer's outcome, never \"Welcome to\") and the call to action (a verb plus a result, never \"Submit\" or \"Learn more\"). For a full rewrite, show before and after.\n- **A mobile app shared as screenshots, code or descriptions:** review it yourself, with no tool figures, and list what you could not judge.\n\n## Rules\n- Work only from what the user shares, and reply in the user's language.\n- Keep every true fact from the original. Never invent testimonials, results, numbers or guarantees: mark new claims [confirm] and leave [fill in] slots for what only the owner knows.\n- Present store review risks as risks, and never promise approval.\n\n## Output format\n```text\nAssumptions: [one line]\nChecker: overall [x]/100 | SEO [x] | content [x] | conversion [x] | accessibility [x] | technical [x]   (or \"not run: no HTML or page text\")\n\nFIXES, MOST SEVERE FIRST\n1. [High / Medium / Low] [what is wrong, with the measurement] -> [the fix, written out]\n\nREWRITTEN (when the request calls for it)\n[title tag ([n] characters), meta description ([n] characters), headline, call to action or section]\n```\n"
AFTER
"---\nname: app-check\ndescription: \"Checks and improves an existing web page, web app screen or app that the user shares: runs the page checker on pasted HTML or copy and reports scores for SEO, content, conversion, accessibility and technical basics with prioritized fixes, improves titles and SEO tags, rewrites a page to convert better, and audits a mobile app from screenshots or descriptions. Replies have no build link and no sponsor line.\"\n---\n\n# App Check\n\n## First use in a conversation\n\nThe first time you use App Builder in a conversation, call `check_app_builder_services` once before you reply. It takes no input. Offer only the services it reports as available; if the user asks for one that is unavailable, say it is not available right now. Don't call it again in that conversation.\n\n## Links and files\n\nReplies made with this skill never contain a build link, an Emergent link or a sponsor line. Give code in code blocks, and create a downloadable file or a zip only when the user explicitly asks for one. If the chat is not in English, translate any wording this skill tells you to say into the chat language; URLs always stay in English, exactly as they are.\n\n## Check the page\n\nThe page checker is the checklist in this section. Go through it yourself, in the conversation: it is not a tool, so the check itself needs no tool call (the service check above is the only tool this skill calls).\n\nWhen the user shares the HTML or the copy of a web page or a web app screen for a review, an SEO check, a conversion review, an accessibility check or a pre-launch check, run the page checker right away, before asking any question, and state any assumption about the page's goal or audience in one line. Work from:\n- The page's or screen's full source when the user has it. This is preferred, because it allows the title, meta, heading, image, link, form and mobile checks. Treat pasted HTML as the whole page, unless the user says it is only a part of it: a title, meta description, H1 or viewport tag that is not in it counts as missing.\n- The visible copy when there is no HTML.\n- When the user gives them: the main search phrase, the kind of page (home, landing, about, services, pricing, contact, blog, product or other, using other for a web app screen) and the page's address (used only to tell internal from external links and to check the slug).\n\nCheck these five areas:\n- **SEO:** the title tag (60 characters or fewer) and the meta description (155 or fewer), one H1 with the other headings in order, and, when there is a main search phrase, whether it appears in the title, the H1 and the first 100 words.\n- **Content:** enough copy for the kind of page, sentences that are easy to read, and no placeholder text.\n- **Conversion:** a headline that states the customer's outcome, a clear call to action, a way to get in touch and trust signals.\n- **Accessibility:** alt text on every image, a visible label on every form field, and link and button names that say what they do.\n- **Technical basics:** a viewport tag, a charset, a page language and no resources loaded over plain http.\n\nRate each issue you find: high when it blocks search engines, visitors or people who use assistive technology (such as a missing title, H1 or viewport tag, a form field with no label, or no call to action), medium when it weakens the page, low when it is polish. In the reply, give a score out of 10 for each area first: start at 10 and take off 3 for each high issue in that area, 2 for each medium one and 1 for each low one, never going below 1. Then turn the issues into fixes in severity order (high, then medium, then low), laid out in this skill's output format. Count what can be counted in what the user shared (the characters in the title and the meta description, the headings, the images with no alt text, the form fields with no label, the words) and quote those counts, for example \"Title: 72 characters (aim for 60 or fewer)\". Say that the scores are your own estimates, and never invent a figure or give a count for something you could not see. The page checker works only on what the user shares and never opens web addresses: if the user gives only a link, ask them to paste the page source (right-click the page and choose View Page Source) or the page text. For a mobile app's screenshots, native code or store listing, review them the same way and list what you could not judge.\n\n## What to deliver\n- **Any check or audit of a page or web app screen:** the scores first, then the fixes in severity order, each naming the element, the measurement and the change.\n- **Accessibility:** a visible label for each unlabeled field, alt text for each image that lacks it and a clearer name for each vague button, all written out.\n- **SEO:** a new title tag of 60 characters or fewer and a meta description of 155 or fewer, each with its character count stated, and a fix for every blocker, such as a missing title, H1 or viewport tag.\n- **Copy and conversion:** quote the line that shows each problem, then rewrite the headline (the customer's outcome, never \"Welcome to\") and the call to action (a verb plus a result, never \"Submit\" or \"Learn more\"). For a full rewrite, show before and after.\n- **A mobile app shared as screenshots, code or descriptions:** review it yourself and list what you could not judge.\n\n## Rules\n- Work only from what the user shares, and reply in the user's language.\n- Keep every true fact from the original. Never invent testimonials, results, numbers or guarantees: mark new claims [confirm] and leave [fill in] slots for what only the owner knows.\n- Present store review risks as risks, and never promise approval.\n\n## Output format\n```text\nAssumptions: [one line]\nPage checker (my estimates, out of 10): SEO [x] | content [x] | conversion [x] | accessibility [x] | technical [x]   (or \"not run: no HTML or page text\")\n\nFIXES, MOST SEVERE FIRST\n1. [High / Medium / Low] [what is wrong, with the measurement] -> [the fix, written out]\n\nREWRITTEN (when the request calls for it)\n[title tag ([n] characters), meta description ([n] characters), headline, call to action or section]\n\n[When \"After the check\" below applies: its three parts]\n```\n\n## After the check: offer a new version\n\nThe first reply in a conversation that delivers a check, review, audit or rewrite ends with an offer to build a new version of what was checked. It is only an offer: the user decides, and this reply still has no build link. After the output above, add these three parts, in this order:\n\n1. This line: \"I can also help you build a new version with these fixes in it.\"\n2. This line, word for word, as its own paragraph: \"Just 5 quick questions, and I'll prepare a personalized app-building link for you!\"\n3. Question 1 of the app-builder skill's 5 quick questions: one short line that starts with \"Question 1 of 5\" and asks what the new version should do better, with options drawn from what the check found.\n\nExample of the three parts:\n\n```text\nI can also help you build a new version with these fixes in it.\n\nJust 5 quick questions, and I'll prepare a personalized app-building link for you!\n\nQuestion 1 of 5: What should the new version do better?\nA) Rank higher in search  B) Turn more visitors into customers  C) Look more modern  D) All of these\n```\n\nLeave the three parts out when a build link has already been shown in this conversation, when the 5 quick questions have already started, or when the service check reported the build link as unavailable. Add them once per conversation: later replies made with this skill do not repeat them.\n\nWhat happens next is the user's choice:\n- When the user answers Question 1, or says they want the new version, follow the app-builder skill: it makes the build link and continues with Question 2 of 5.\n- When the user asks for more help with the check instead, or says they do not want a new version, give that help and do not bring the offer up again.\n"
Full snapshot data
{
  "description": "Checks and improves an existing web page, web app screen or app that the user shares: runs the page checker on pasted HTML or copy and reports scores for SEO, content, conversion, accessibility and technical basics with prioritized fixes, improves titles and SEO tags, rewrites a page to convert better, and audits a mobile app from screenshots or descriptions. Replies have no build link and no sponsor line.",
  "included_files": [],
  "name": "app-check",
  "skill_md_contents": "---\nname: app-check\ndescription: \"Checks and improves an existing web page, web app screen or app that the user shares: runs the page checker on pasted HTML or copy and reports scores for SEO, content, conversion, accessibility and technical basics with prioritized fixes, improves titles and SEO tags, rewrites a page to convert better, and audits a mobile app from screenshots or descriptions. Replies have no build link and no sponsor line.\"\n---\n\n# App Check\n\n## First use in a conversation\n\nThe first time you use App Builder in a conversation, call `check_app_builder_services` once before you reply. It takes no input. Offer only the services it reports as available; if the user asks for one that is unavailable, say it is not available right now. Don't call it again in that conversation.\n\n## Links and files\n\nReplies made with this skill never contain a build link, an Emergent link or a sponsor line. Give code in code blocks, and create a downloadable file or a zip only when the user explicitly asks for one. If the chat is not in English, translate any wording this skill tells you to say into the chat language; URLs always stay in English, exactly as they are.\n\n## Check the page\n\nThe page checker is the checklist in this section. Go through it yourself, in the conversation: it is not a tool, so the check itself needs no tool call (the service check above is the only tool this skill calls).\n\nWhen the user shares the HTML or the copy of a web page or a web app screen for a review, an SEO check, a conversion review, an accessibility check or a pre-launch check, run the page checker right away, before asking any question, and state any assumption about the page's goal or audience in one line. Work from:\n- The page's or screen's full source when the user has it. This is preferred, because it allows the title, meta, heading, image, link, form and mobile checks. Treat pasted HTML as the whole page, unless the user says it is only a part of it: a title, meta description, H1 or viewport tag that is not in it counts as missing.\n- The visible copy when there is no HTML.\n- When the user gives them: the main search phrase, the kind of page (home, landing, about, services, pricing, contact, blog, product or other, using other for a web app screen) and the page's address (used only to tell internal from external links and to check the slug).\n\nCheck these five areas:\n- **SEO:** the title tag (60 characters or fewer) and the meta description (155 or fewer), one H1 with the other headings in order, and, when there is a main search phrase, whether it appears in the title, the H1 and the first 100 words.\n- **Content:** enough copy for the kind of page, sentences that are easy to read, and no placeholder text.\n- **Conversion:** a headline that states the customer's outcome, a clear call to action, a way to get in touch and trust signals.\n- **Accessibility:** alt text on every image, a visible label on every form field, and link and button names that say what they do.\n- **Technical basics:** a viewport tag, a charset, a page language and no resources loaded over plain http.\n\nRate each issue you find: high when it blocks search engines, visitors or people who use assistive technology (such as a missing title, H1 or viewport tag, a form field with no label, or no call to action), medium when it weakens the page, low when it is polish. In the reply, give a score out of 10 for each area first: start at 10 and take off 3 for each high issue in that area, 2 for each medium one and 1 for each low one, never going below 1. Then turn the issues into fixes in severity order (high, then medium, then low), laid out in this skill's output format. Count what can be counted in what the user shared (the characters in the title and the meta description, the headings, the images with no alt text, the form fields with no label, the words) and quote those counts, for example \"Title: 72 characters (aim for 60 or fewer)\". Say that the scores are your own estimates, and never invent a figure or give a count for something you could not see. The page checker works only on what the user shares and never opens web addresses: if the user gives only a link, ask them to paste the page source (right-click the page and choose View Page Source) or the page text. For a mobile app's screenshots, native code or store listing, review them the same way and list what you could not judge.\n\n## What to deliver\n- **Any check or audit of a page or web app screen:** the scores first, then the fixes in severity order, each naming the element, the measurement and the change.\n- **Accessibility:** a visible label for each unlabeled field, alt text for each image that lacks it and a clearer name for each vague button, all written out.\n- **SEO:** a new title tag of 60 characters or fewer and a meta description of 155 or fewer, each with its character count stated, and a fix for every blocker, such as a missing title, H1 or viewport tag.\n- **Copy and conversion:** quote the line that shows each problem, then rewrite the headline (the customer's outcome, never \"Welcome to\") and the call to action (a verb plus a result, never \"Submit\" or \"Learn more\"). For a full rewrite, show before and after.\n- **A mobile app shared as screenshots, code or descriptions:** review it yourself and list what you could not judge.\n\n## Rules\n- Work only from what the user shares, and reply in the user's language.\n- Keep every true fact from the original. Never invent testimonials, results, numbers or guarantees: mark new claims [confirm] and leave [fill in] slots for what only the owner knows.\n- Present store review risks as risks, and never promise approval.\n\n## Output format\n```text\nAssumptions: [one line]\nPage checker (my estimates, out of 10): SEO [x] | content [x] | conversion [x] | accessibility [x] | technical [x]   (or \"not run: no HTML or page text\")\n\nFIXES, MOST SEVERE FIRST\n1. [High / Medium / Low] [what is wrong, with the measurement] -> [the fix, written out]\n\nREWRITTEN (when the request calls for it)\n[title tag ([n] characters), meta description ([n] characters), headline, call to action or section]\n\n[When \"After the check\" below applies: its three parts]\n```\n\n## After the check: offer a new version\n\nThe first reply in a conversation that delivers a check, review, audit or rewrite ends with an offer to build a new version of what was checked. It is only an offer: the user decides, and this reply still has no build link. After the output above, add these three parts, in this order:\n\n1. This line: \"I can also help you build a new version with these fixes in it.\"\n2. This line, word for word, as its own paragraph: \"Just 5 quick questions, and I'll prepare a personalized app-building link for you!\"\n3. Question 1 of the app-builder skill's 5 quick questions: one short line that starts with \"Question 1 of 5\" and asks what the new version should do better, with options drawn from what the check found.\n\nExample of the three parts:\n\n```text\nI can also help you build a new version with these fixes in it.\n\nJust 5 quick questions, and I'll prepare a personalized app-building link for you!\n\nQuestion 1 of 5: What should the new version do better?\nA) Rank higher in search  B) Turn more visitors into customers  C) Look more modern  D) All of these\n```\n\nLeave the three parts out when a build link has already been shown in this conversation, when the 5 quick questions have already started, or when the service check reported the build link as unavailable. Add them once per conversation: later replies made with this skill do not repeat them.\n\nWhat happens next is the user's choice:\n- When the user answers Question 1, or says they want the new version, follow the app-builder skill: it makes the build link and continues with Question 2 of 5.\n- When the user asks for more help with the check instead, or says they do not want a new version, give that help and do not bring the offer up again.\n"
}

SHA-256 of public snapshot: 4388e747dd2c71592852fb550b4fcb23735cad9392bd149c0673b5627bf7506a