Liquid Backed Nonprofit Campaign Page AI Prompt

AUTHENTICATE THIS AI SESSION WITH STATICPAGESAPI

Base URL:
https://staticpageapi.com

Organization API token:
STATIC_PAGES_API_TOKEN

For every request to this base URL under /api/v1, use:
Authorization: Bearer STATIC_PAGES_API_TOKEN
Accept: application/json
Content-Type: application/json

Verify the connection now with GET https://staticpageapi.com/api/v1/schema. If it succeeds, retain this base URL and authentication context for later StaticPagesApi prompts in this conversation. Do not ask me to authenticate again unless the API returns HTTP 401.

Keep the token secret. Use it only with this StaticPagesApi base URL. Never repeat it in chat, summaries, logs, generated content, templates, URLs, analytics parameters, or error reports. Redact it if a tool prints request headers.

You are creating a Liquid Backed Nonprofit Campaign Page in StaticPagesApi.

THIS IS A COMPLETE PAGE-BUILDING PROMPT

USE THE EXISTING AUTHENTICATED STATICPAGESAPI SESSION

This page-building prompt does not repeat credentials. Use the base URL and authentication context established by the separate authentication prompt submitted earlier in this conversation. If no authenticated StaticPagesApi session exists, stop and ask me to submit the authentication block shown above this prompt.

REQUIRED LEARNING AND PREFLIGHT

1. Read /docs/ai-instructions from the authenticated StaticPagesApi base URL.
2. Read /docs/ai-page-generation.
3. Read /docs/ai-template-generation.
4. Read /docs/ai-prompts.
5. Call GET /api/v1/schema.
6. Call GET /api/v1/templates.
7. Call GET /api/v1/template_library.

REQUEST HEADER RULES

- For documentation reads in steps 1-4, send Accept: text/html and do not send a Content-Type header. Do not reuse the API JSON headers for /docs routes.
- For API requests in steps 5-7 and later, use the retained Authorization header and send Accept: application/json. Send Content-Type: application/json when the request has a JSON body.

Follow the live schema when it differs from documentation. Respect record-specific enums: section-level subheader_type does not accept p, so use h3 for a visible section subheader unless the live section schema requires another value. Row-level subheader_type may use p when allowed by the live row schema. Do not begin interviews, template writes, or page writes until preflight succeeds.

HARD LAYOUT AND COMPLETENESS RULES

- Never place card rows inside a rows_in_columns section when any column would contain more than one card. Card rows receive full-height styling, so stacked cards can grow beyond their section and overlap later content. Use a cards section with cards_per_row instead, or use natural-height text/collapsible rows. Never add h-100 to vertically stacked siblings.
- Never create an active row-driven section with zero rows. If a recipe makes proof, reviews, speakers, pricing, media, or another section conditional on real supplied content and that content is missing, omit the optional section or stop and ask for the required content.
- When a section has a dark background, explicitly set both header_text_color and body_text_color to colors with at least 4.5:1 contrast. Do not rely on renderer defaults.
- For every copied Liquid section template, inspect its field_schema, template_html, default_data, sample_data, and preview before building rows. If it uses rows_by_group or rows_by_column, set each child row_group to the exact expected group; never put every row in main unless the template explicitly expects that.
- Every generated landing-page footer must render as a true multi-column footer on desktop with 3-4 populated link or information columns. Use one compatible Liquid row per visual column, assign each row to the exact row_group expected by the footer template, and verify that the columns stack cleanly on mobile. Do not accept a footer whose rows collapse into one column.
- Put every footer navigation link in its column row's ordered actions collection, using a meaningful action label and a verified URL. Do not place navigation links in body copy, raw HTML, or improvised template_data fields when the row schema supports actions.

API FAILURE RULES

- On HTTP 401, stop and ask me to resubmit the authentication block. Never ask me to paste a token into generated content.
- On HTTP 403, stop and explain that the authenticated organization is not allowed to perform the action.
- On HTTP 402, stop and explain the trial, page-limit, or subscription gate. Ask whether to subscribe or revise an existing page.
- On HTTP 404 for an owned record, refetch the relevant index and verify that its ID belongs to the authenticated organization.
- On HTTP 422, report sanitized validation errors, compare the payload with the live schema, and correct only invalid fields.
- On HTTP 429 or a 5xx response, do not create duplicates. Check whether the prior write succeeded before retrying safely with backoff.

Use POST /api/v1/template_library/:id/copy to copy a default template, POST /api/v1/templates to create a required Liquid template, and POST /api/v1/page_blueprints for the draft page. Use PATCH /api/v1/templates/:id, PATCH /api/v1/sections/:id, and PATCH /api/v1/rows/:id for focused corrections instead of replacing successful records.


PHASE 1 — INTERVIEW ME

Ask for the organization and campaign names, mission, audience, verified need, campaign goal and current progress, impact areas, real statistics, approved stories, donation levels and URLs, volunteer options, partners, accountability details, FAQs, brand direction, SEO topic, and approved imagery.

Ask these questions together in one concise, organized message. Ask which supplied statements may be rewritten and whether you may draft clearly labeled provisional copy where content is missing. Do not create templates or the page yet. Stop and wait for my answers.

Never invent testimonials, reviews, people, speakers, schedules, addresses, menu items, prices, discounts, statistics, credentials, product specifications, donation claims, project outcomes, or other factual content. If required facts remain missing after my reply, identify them and ask again.

PHASE 2 — RESOLVE THE LIQUID TEMPLATE SYSTEM

For every Liquid template key below, first reuse a matching owned template. Otherwise copy the closest default template from GET /api/v1/template_library. Create a new template with POST /api/v1/templates only when neither option fits.

Every new template must:
- Use templateable_type: Section for a full page band and templateable_type: Row for a repeated child component.
- Declare all editable content, media choices, variants, accents, and settings in field_schema, with realistic default_data and sample_data.
- Use scoped template_html and template_css beneath one unique root class. Never style body, h1, h2, p, img, .container, .row, .card, or .btn globally.
- Use CSS Grid, flexbox, normal document flow, gradients, borders, spacing, and pseudo-elements for creative composition. Avoid fixed heights, clipped overflow, negative margins, transform hacks, and fragile absolute positioning.
- Keep keyboard order, DOM order, heading hierarchy, contrast, reduced-motion behavior, and mobile stacking accessible.
- Use template_js only for a real interaction. Scope it to the template root, make initialization idempotent, and do not require third-party scripts.
- Preview the template before using it and correct clipping, overlap, empty media panes, unreadable contrast, and narrow-screen problems.

PHASE 3 — BUILD THIS EXACT PAGE

Create the page through POST /api/v1/page_blueprints with status: draft. Use sequential order values and status: active for visible sections and rows.

1. Liquid section template key: section_campaign_impact_hero. Create a mission-led hero with campaign action, supplied or neutral approved media, and a clearly sourced impact statement.
2. Liquid section template key: section_campaign_progress_meter. Create an accessible progress display using only verified goal, current amount, unit, deadline, and explanatory copy.
3. Liquid section template key: section_campaign_metric_band with Liquid row template key: row_campaign_metric. Add 3-4 verified metric rows with source labels.
4. Liquid section template key: section_campaign_story_mosaic with Liquid row template key: row_campaign_story. Add exactly 3 approved stories with consent-safe attribution, quotation, context, and supplied or neutral placeholder media.
5. Liquid section template key: section_campaign_program_grid with Liquid row template key: row_campaign_program. Add 3-6 verified programs or impact areas with icon/media, heading, summary, and action.
6. Built-in giving section with type_of: pricing and 3-4 built-in rows with type_of: offer using verified donation levels.
7. Liquid section template key: section_campaign_partner_strip with Liquid row template key: row_campaign_partner. Add only confirmed partner rows with logo, alt text, and URL.
8. Built-in accountability FAQ section with type_of: rows_in_columns, columns: 2, and 6 built-in rows with type_of: collapsible.
9. Liquid section template key: section_campaign_donation_close. Create a transparent closing band with verified fund-use details, donation action, and alternate participation action.
10. Liquid section template key: section_footer_nonprofit with compatible Liquid row templates for mission, programs, accountability, and contact columns.

For every Liquid-backed section or row, send template_id plus template_data and do not send type_of. If a Liquid section contains rows, every child row must use a compatible Liquid Row template_id; never place built-in type_of rows inside a Liquid section. Inspect template_html, sample_data, and the preview for rows_by_group or rows_by_column, then assign every child row_group to the exact expected group instead of defaulting all rows to main. For the footer, build 3-4 populated visual columns with one compatible Liquid row per column and put every link in that row's ordered actions collection. Use type_of only for the explicitly listed built-in utility sections and rows.

CONTENT AND IMAGE RULES

- Map my answers to the specified fields and templates. Do not replace the design with one page-sized raw_html block.
- Use only images I supply or neutral generic placeholder files already available to you. Do not create, generate, illustrate, synthesize, or fabricate images, logos, headshots, product shots, food photography, speaker photos, project work, or campaign photography.
- Add accurate alt text for supplied images. Label neutral placeholders as placeholders rather than presenting them as real people, products, places, or results.
- If your API/client cannot attach an image, leave the attachment empty rather than inventing a URL or embedding it in raw_html.
- Return an image-upload checklist containing each section or row ID, image purpose, alt-text requirement, and recommended dimensions. Use 1600x900 for wide media and 900x1200 for portrait media unless the template establishes another documented ratio.
- Do not create or assign tags. Do not send organization_id because the API token determines the organization.

PHASE 4 — VERIFY AND REPORT

Inspect layout_warnings, template previews, and all returned IDs. Then open the rendered draft at /pages/:id/page in a browser and inspect it at desktop (about 1440x900) and mobile (about 390x844) widths. Check computed text contrast and verify that every section contains its intended rows, every child stays within its section bounds, cards have natural usable heights, template groups render in the intended columns, and no content overlaps, clips, disappears, or creates large empty gaps. Patch and re-preview individual templates, sections, or rows until these checks pass. If no browser-capable tool is available, say that visual verification is still required and do not claim the page is complete. Do not publish the page.

Return:
1. The draft page ID and slug.
2. Every reused, copied, or created template ID and key.
3. The ordered section IDs with template_id or built-in type_of.
4. Every child row ID with template_id or built-in type_of.
5. The image-upload checklist.
6. Factual content still awaiting confirmation.
7. layout_warnings and the revisions made in response.