Portfolio and Case Study 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 Portfolio and Case Study 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 person or studio name, ideal client, positioning, biography, services, actual case studies, project outcomes, real testimonials, process, availability, inquiry URL, brand direction, SEO specialty, and available headshots or project images.

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 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 — BUILD THIS EXACT STRUCTURE

Create the page through POST /api/v1/page_blueprints with status: draft. Give every built-in section and row status: active, sequential order values, generous section_classes spacing, readable contrast, and normal document flow.

1. Create a hero section with type_of: hero and hero_type: split using the supplied positioning, inquiry action, and a supplied or neutral portfolio placeholder.
2. Create an introduction section with type_of: rows_in_columns and columns: 2. Add exactly 4 rows with type_of: text for specialization, background, capabilities, and availability.
3. Create a case-study section with type_of: slider, slider_variant: split_rows, and slider_behavior: controls. Add exactly 3 rows with type_of: split; each row represents a real project and includes a supplied or neutral placeholder image_desktop attachment.
4. Create a services section with type_of: cards and cards_per_row: 3. Add 3-6 rows with type_of: card and card_variant: feature_text.
5. Create a client-proof section with type_of: slider, slider_variant: mixed, and slider_behavior: auto. Add 3-5 rows with type_of: testimonial using only real supplied testimonials.
6. Create a process section with type_of: rows_in_columns and columns: 3. Add exactly 3 rows with type_of: card and card_variant: numbered_step.
7. Create a final inquiry section with type_of: text containing availability, fit guidance, and the verified inquiry action. It has no child rows.
8. End with an owned or copied Footer Liquid section template using template_id instead of type_of.

CONTENT AND IMAGE RULES

- Map my answers to the specified sections and rows. Do not replace the requested component types with one large 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 image_alt text for supplied images. Label neutral placeholders as placeholders rather than describing them as real people, products, places, or results.
- If your API/client cannot attach an image file, leave that attachment empty. Do not insert a fabricated image URL or use raw_html to work around attachment handling.
- After creation, return an image-upload checklist containing each affected section or row ID, its image purpose, required alt text, and recommended desktop dimensions. Use 1600x900 for wide media and 900x1200 for portrait media unless the selected component requires another ratio.
- Use type_of for every built-in renderer listed above. For the Footer Liquid section, template_id replaces type_of: send template_id plus template_data and never send type_of on that section. Follow the chosen footer template's field schema, template_html, sample_data, and preview. Build 3-4 populated visual columns with one compatible Liquid row per column, assign the exact row_group values expected by rows_by_group or rows_by_column, and put every link in that row's ordered actions collection.
- Do not create or assign tags. Do not send organization_id because the API token determines the organization.

PHASE 3 — VERIFY AND REPORT

Inspect layout_warnings and the returned page, section, and row 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 columns are populated correctly, and no content overlaps, clips, disappears, or creates large empty gaps. Patch individual sections or rows and repeat the rendered inspection 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. An ordered list of section IDs with their type_of or Footer template_id.
3. Each child row ID and type_of.
4. The image-upload checklist.
5. Any factual content still awaiting my confirmation.
6. Any layout_warnings and the revisions made in response.