references/behance-social-reference-extraction.md
# Behance social reference extraction notes
Use this when the user provides a Behance social-media project URL and asks to download/reference the posts.
## Extraction approach
1. Fetch the Behance project HTML and save it under a project-specific folder, e.g.:
- `/Users/akhilaston/Documents/Ai_Hub/behance_<slug>/page.html`
2. Extract only project image URLs from `mir-s3-cdn-cf.behance.net/project_modules/...`.
3. Download all matched image files first; Behance pages often include duplicates, thumbnail versions, hero composites, and supporting mockups.
4. Inspect dimensions and file sizes after download.
5. For final social posts, prefer files matching the post format, commonly `1080x1350` for 4:5 posts. Build a contact sheet before selecting if there are duplicates.
6. Copy the final unique posts into a clean `final_9_posts/` or equivalent folder and write a manifest.
## Selection pattern from the Social Media Automation project
For Behance project `245958151/Social-Media-Automation`, the 9 unique final 4:5 posts were the high-size `1080x1350` files, not the smaller duplicates:
- `116.png`
- `109.png`
- `095.png`
- `088.png`
- `123.png`
- `081.png`
- `130.png`
- `102.png`
- `074.png`
The project also contained repeated duplicate versions of the same posts with smaller file sizes. Do not assume every extracted `1080x1350` file is unique; use a contact sheet or visual dedupe.
## User-facing behavior
If the user says “download all posts,” do the extraction and return only the destination path and brief done status. Do not start analyzing unless asked.
If the user asks to recreate a reference “exactly,” do not describe it as inspiration. Build a coordinate/component-level spec from the selected image.
references/html-social-card-mp4-export.md
# HTML social card → MP4 export pattern
Use when the user asks to “download it as an mp4” after building an animated single-card HTML/Tailwind social post.
## Pattern
1. Create a dedicated export HTML file sized exactly to the card/canvas.
- `html, body { width: 384px; height: 384px; margin: 0; overflow: hidden; }`
- Render the card at `384px × 384px` with no surrounding page background/browser chrome.
- If the live page centers the card in a larger viewport, do not record that page directly; make an export-only page.
2. Record with Playwright video capture.
- Use Chromium headless with `record_video_dir` and `record_video_size: { width: 384, height: 384 }`.
- Use `viewport: { width: 384, height: 384 }` and `device_scale_factor: 1`.
- Load the export HTML via `Path(...).as_uri()`.
- Wait for `networkidle`, then record for enough time for animations/video to reach the intended visual state.
3. Convert WebM to MP4 with ffmpeg.
- `ffmpeg -y -i input.webm -vf 'scale=384:384:flags=lanczos,format=yuv420p' -c:v libx264 -preset medium -crf 18 -movflags +faststart output.mp4`
- Verify with `ffprobe` for codec, dimensions, duration, and size.
4. If the first seconds are blank or missing the lower video state, trim from a later timestamp.
- Example: `ffmpeg -y -ss 10 -i long-recording.mp4 -t 7 -c:v libx264 -preset medium -crf 18 -pix_fmt yuv420p -movflags +faststart final.mp4`
5. Generate a preview frame and visually QA it.
- `ffmpeg -y -ss 2 -i final.mp4 -frames:v 1 -update 1 preview.jpg`
- Check the preview contains the intended card only, no browser chrome, no outer page background, and the video/overlays are visible.
## Pitfalls
- Browser video capture produces WebM first; user usually wants MP4, so transcode to H.264/yuv420p for compatibility.
- Recording too early can capture a blank/white phase before the media layer appears. Record longer, inspect later frames, then trim the best 7–10s segment.
- Do not claim export success without checking dimensions and a preview frame.
- Keep both the final MP4 and a preview JPG in an `exports/` directory with clear names.
references/public-asset-backed-social-prompts.md
# Public asset-backed social post prompts
Use this reference when the user wants a shareable prompt that other people can run on their own machine without local asset paths.
## Workflow
1. Extract or collect only approved/public assets.
- Do not invent fallback images, logos, backgrounds, or copy.
- If scraping a brand site, save original source URLs and local copies.
2. Build a prompt as a production spec, not a vibe prompt.
- Include canvas size, exact asset URLs, exact copy, x/y placement, max widths, font sizes, colors, crop rules, layer order, button/footer placement, and quality rules.
- Explicitly ban weird backgrounds, fake screenshots, random decoration, overlapping text, tiny text, text outside safe areas, and spelling/capitalization changes.
3. Produce a real test output before saying the prompt works.
- Create a terminal-runnable generator when possible.
- Render PNG/MP4.
- Visually QA the final output for text, layout, logo matte/white boxes, image crop, button/footer, and brand fit.
4. Host assets for sharing.
- Package a tiny static site with `/assets/...`, `PROMPT.md`, `assets.json`, and optionally an example output image.
- Deploy to a public static host such as Vercel.
- Verify every direct URL returns HTTP 200 without login/protection.
5. Update the prompt after hosting.
- Replace local filesystem paths with public HTTPS URLs.
- Include an example output reference URL and manifest URL.
- Re-deploy and fetch the hosted `PROMPT.md` to confirm public URLs are present.
## Quality bar for this user
Keep replies short. The user cares most about: no text issues, no layout issues, no weird backgrounds, no invented assets, and proof via rendered/verified output.
references/single-animated-video-card-builds.md
# Single animated social video card build notes
Use when a user provides a production-style prompt for one social card with video, background image, Tailwind font mappings, and explicit “do not create a grid / other cards” constraints.
Key reusable pattern:
1. Treat the brief as an implementation spec, not a copywriting prompt.
- Build real `index.html` + `index.css` files.
- Preserve wording exactly.
- Keep exactly one card/post node in the DOM.
- If the prompt names a grid position like “CARD 3 (top-right),” treat that as source context only; still render one centered card unless the user explicitly asks for the whole grid.
2. Asset handling:
- If the brief says “download and save as public/bg.jpeg,” attempt the download before final verification.
- If a signed/private asset URL returns `403 AccessDenied`, do not swap in a random replacement image.
- Still wire CSS to `./public/bg.jpeg` and report the blocker clearly so the user can provide a fresh/public URL.
3. DOM/browser verification checklist:
- `document.querySelectorAll('article').length === 1`
- no CTA/button/logo/icons/particles/extra copy if brief forbids them
- card dimensions exactly 384 x 384
- border radius is 12px
- overflow is hidden
- video covers required area/full card as specified
- loop/autoplay/muted/playsInline attributes match the prompt
- particle count/animated decorative elements match requested range, or are absent when forbidden
- visual QA screenshot confirms no accidental grid or extra content
4. Visual tuning:
- If the supplied video frame is brighter than the requested mood, prefer subtle CSS filters/overlays on the video (`brightness`, `contrast`, `saturate`) plus the specified layered overlay.
- Do not invent new gradients beyond the brief; strengthen the specified overlay values if needed to satisfy “dark/cinematic.”
5. Video implementation patterns:
- Full-card loop video: absolute `inset-0`, `w-full h-full object-cover`, `pointer-events-none`, `autoplay loop muted playsinline`.
- Pushed-down video card: keep the video absolute/full-card/object-cover but add `pt-[140px]`; add a white fade overlay at `top-[140px]`, `h-[120px]`, `linear-gradient(to bottom, white 0%, transparent 100%)`, above video and below content.
- Custom non-loop fade restart: when the prompt says not to use `loop`, implement React `useRef/useEffect` with `FADE_DURATION = 0.5`, a `requestAnimationFrame` opacity loop, and an `ended` handler that sets opacity 0, waits 100ms, resets `currentTime = 0`, then calls `play()`. Verify `video.hasAttribute('loop') === false`.
6. Reusable starter:
- See `templates/single-animated-video-card.html` for the one-card structure and z-index layering.
Final response style for this user:
- Keep it blunt: “Done,” files changed, verified checklist, blockers only.
- Do not include long rationale or restate the whole prompt.
references/social-carousel-prompt-engineering.md
# Social carousel prompt engineering session notes
## User correction
The user rejected a generic “master carousel prompt” and clarified that the prompt should not be written before the reference and design logic are engineered. Future sessions should research, reverse-engineer, and structure the design system first.
The user also asked for short messages in this discussion; when collaborating interactively on prompt/design systems, keep replies concise and move step by step.
## What a carousel is
A carousel is a multi-slide social post where the viewer swipes through frames. It is a mini presentation/editorial story, not a collection of disconnected posts.
The best carousel design depends on:
- hook strength
- swipe motivation
- slide narrative
- visual rhythm
- idea density
- text hierarchy
- brand recall
- save/share value
- final CTA
## Research summary
High-performing carousel types:
- Educational: useful, saveable lessons.
- Framework: repeatable mental model.
- Before/after: visual proof and contrast.
- Myth vs truth: tension and reframe.
- Case study: proof plus story.
- Checklist: high save value.
- Point of view: authority and brand belief.
Common patterns in strong carousels:
- Slide 1 behaves like a poster.
- One idea per slide.
- Visual rhythm changes across slides.
- Editorial hierarchy is clearer than decorative styling.
- Every slide creates a reason to swipe.
- The post is useful enough to save or sharp enough to share.
Common failures:
- generic Canva templates
- weak hooks
- paragraphs crammed into slides
- centered text everywhere
- random icons/blobs/gradients
- low contrast
- no final takeaway
- seven disconnected layouts
## Team content calendar input pattern
The user’s team often receives long-form LinkedIn content calendars like:
- Week/day
- long LinkedIn post body
- hashtags
- “Design Team” note
- image caption
This is not carousel-ready. First convert long-form content into a carousel idea.
Example insight from a Biz Hub post:
Original long topic: organisations using same software as competitors.
Core carousel hook: “If your software is the same, where is your advantage?”
Distillation path:
1. Identify the real argument.
2. Pull the strongest hook/image caption.
3. Extract 5–7 key beats.
4. Convert into slide roles.
5. Only then define visual direction.
## Exact reference recreation standard
When the user provides a reference image and says exact, do not create a “similar vibe” prompt.
Produce a spec like:
- Canvas: 1240×1550 or 1080×1350.
- Purple card: x/y/width/height/radius.
- Orange pill: x/y/width/height/radius.
- Headline: x/y/width/font/size/line-height/color.
- Feature pills: x/y/width/height/spacing/opacity.
- Product/laptop mockup: x/y/width/rotation/crop/overlap.
- Footer strip: x/y/height/color/logo placement.
- Decorative arrow/shape: position, stroke, direction.
- Layer order.
## Behance reference lesson
The chosen Behance post (`207.png`) was a purple/orange SaaS-style post with:
- off-white background
- large rounded purple panel on the left
- orange top pill label
- large white headline
- translucent purple feature pills
- angled laptop/dashboard mockup overlapping from right
- white hand-drawn curved arrow
- bottom-left closing copy
- orange footer strip with logo
The first attempted prompt said “closely”; the user corrected: “i don’t want closely brooo.” For this user, exact recreation requires measurable layout specs, not descriptive approximation.
## Preferred prompt style example
The user showed a strong prompt example that specified:
- 3x2 grid
- exact card size and gap
- background download path
- Google Font mappings
- Tailwind config
- global CSS animations
- liquid glass utility classes
- per-card layer order
- exact video URL and placement
- gradient overlays
- exact typography sizes
- exact copy
- icons, buttons, badges, and z-index behavior
This is the target prompt style: implementation-level, not taste-level.
references/terminal-runnable-asset-based-posts.md
# Terminal-runnable asset-based social posts
Use this when the user wants a prompt that does not just describe a post, but can be executed from the terminal to produce a real PNG/MP4 using provided or extracted assets.
## Workflow
1. Extract or receive assets first.
- If a brand website is the source, save a manifest and curated folders for logo, team/product/project images, videos, and social examples.
- Do not invent backgrounds, fake screenshots, icons, or replacement photos.
- Reference exact local asset paths in the prompt and generator.
2. Write a strict build-spec prompt.
- Canvas size and export format.
- Exact copy to use; no rewriting unless asked.
- Logo path, image/video path, crop instructions, and placement.
- x/y/width/height placement for logo, headline, body, pills/buttons, image card, footer.
- Font size, line-height, color, safe margins, layer order.
- Explicit negative constraints: no weird backgrounds, no random décor, no text overlap, no invented assets.
3. Implement deterministic generation.
- For static posts, a Python/Pillow generator is often enough and avoids browser/font variability.
- Use a flat brand-safe background unless a real background asset is supplied.
- Use rounded image cards, safe margins, and simple editorial hierarchy rather than generic Canva grids.
- If using an SVG logo, rasterize carefully and remove matte/padding; verify no white box remains.
4. Render and QA before final.
- Confirm output dimensions with `file` or image metadata.
- Load the rendered PNG visually.
- Check: spelling, capitalization, cropped text, overlaps, safe area, logo matte/white box, image crop, button/footer alignment, and whether any background/decor feels invented.
- Fix visible issues and re-render before telling the user it is done.
## User-specific quality bar
The user explicitly cares about: no text issues, no layout issues, no weird backgrounds, no invented assets. Final replies should be short and status-oriented: files created, command to run, and verified checklist only.
## Example artifact set
For a finished post, save:
- `PROMPT.md` — strict placement/build spec.
- `generate_post.py` or equivalent — terminal-runnable generator.
- final exported `*.png` / `*.mp4`.
SKILL.md
---
name: social-carousel-design
description: Research, reverse-engineer, prompt, and build high-quality social media posts/carousels from long-form content calendars or visual references. Use when the user asks for LinkedIn/Instagram post design, carousel prompt engineering, exact recreation of a social reference, or converting long LinkedIn copy into designed slides.
version: 1.0.0
created_by: agent
---
# Social Carousel Design
Use this skill when the user wants to create, recreate, or systematize social media post/carousel design prompts.
The user's standard is not generic Canva-style output. Treat social post prompting like a Figma/build specification: exact layout, typography, colors, spacing, layer order, and reference-driven art direction.
## Core principles
1. Do not jump straight to the final prompt.
- First understand the content source and/or visual reference.
- The user explicitly dislikes premature prompt-writing before the design logic is engineered.
2. A carousel is one continuous idea revealed across frames.
- It is not seven separate posts.
- The swipe is part of the product.
- Every slide should create a reason to continue.
3. Social carousel work needs three systems:
- Story system: what each slide does.
- Design system: how it looks and stays consistent.
- Swipe system: why the viewer keeps going.
4. For exact recreation, use measurable spec, not vibe.
- “Similar style” is not enough when the user asks for exact.
- Build a coordinate/component-level spec from the reference.
## Workflow
### 0. For this user: keep the conversation short, make the artifact concrete
When the user asks whether a social prompt can drive actual output, answer directly and briefly. The preferred workflow is not just writing a prompt: create a strict build-spec prompt that can be executed into real HTML/CSS/React, exported as PNG/MP4, and visually verified. Avoid long conceptual explanations unless asked.
For brand-site-based social work, do not invent assets. First extract or accept real assets, then reference exact local paths/URLs in the prompt. The prompt should specify which logo/image/video file to use, placement, crop, size, layer order, colors, typography, button styling, export dimensions, and explicit “do not invent/replace assets” constraints.
### 1. Identify the input type
Common inputs:
- Long LinkedIn content calendar entry.
- Single social post reference image.
- Behance/Dribbble/social reference URL.
- Brand website plus rough post topic.
- Existing carousel copy that needs visual design.
### 2. If the input is a long LinkedIn post, distill first
The user's team often receives content calendars with long-form LinkedIn captions, hashtags, and “Design Team / Image caption” notes.
Before designing, extract:
- core argument
- strongest hook
- audience pain
- key insight
- proof/context
- final question/CTA
- best image-caption angle
Then convert into carousel/post structure.
Never do: long post → directly make slides.
Do: long post → editorial distillation → slide narrative → visual storyboard → production prompt.
### 3. Choose the carousel/post type
Useful types:
- Educational carousel
- Framework carousel
- Before/after carousel
- Myth vs truth carousel
- Case-study carousel
- Checklist carousel
- Point-of-view carousel
- Single announcement/product post
### 4. Build the narrative arc
For a 7-slide carousel, default arc:
1. Hook / poster slide
2. Tension or problem
3. Why it matters
4. Reframe or insight
5. Method, example, or proof
6. Takeaway
7. CTA / brand close
For a single post, default hierarchy:
1. visual hook
2. headline
3. support line / proof / feature list
4. product/image/motif
5. brand mark / CTA
### 5. Reverse-engineer visual references before prompting
Study:
- canvas size/aspect ratio
- logo placement
- logo size
- margins
- background color/texture
- headline position
- headline font style, size, weight, line-height
- subheadline/body placement
- text alignment
- color hierarchy
- image/mockup placement
- decorative elements
- borders/shapes
- footer/header system
- CTA/button/pill styling
- layer order
- what makes it feel premium or weak
### 6. Write spec-style prompts
A good social design prompt should specify:
- exact canvas dimensions
- object positions using x/y/width/height or percentages
- color values
- font families and weights
- type scale and line heights
- image/mockup crop, rotation, overlap
- margins and spacing rhythm
- layer order
- export format
- what not to do
The user showed a preferred prompt style that specified Tailwind classes, Google Fonts, animations, card dimensions, video placement, overlays, z-indexes, and exact copy. Match that implementation-level detail.
## Pitfalls
- Do not use generic language like “clean, modern, premium” without translating it into concrete design instructions.
- Do not write a broad master prompt when the user asks to study a reference first.
- Do not interpret “exact” as “close.” Exact means measurable placement and component-level recreation.
- When the user asks for a prompt “taken from” a provided Motionsites/build-spec prompt, extract/adapt only the requested card/section and preserve the original prompt structure, concrete assets, fonts, animations, classes, URLs, and implementation details. Do not replace asset URLs with placeholders. Do not invent a new brand, concept, color system, or layout. If the exact source prompt is not available in context, ask for it again instead of reconstructing from memory.
- Do not rely on AI taste. Encode the taste in the prompt/spec.
- Do not produce Canva-style grids, random icons, blobs, stock-photo smiles, or disconnected slide templates unless specifically requested.
- When a prompt explicitly says “single card only” or “do not create a grid/other cards,” enforce it in the implementation and verify with DOM/browser checks: exactly one `article`/post, requested dimensions, requested border radius, and `overflow: hidden`.
- If the user names a card’s grid position (e.g. “CARD 3 (top-right)”) while only providing that card’s spec, treat the position as context only; render one centered card unless they explicitly ask for the full grid.
- For implementation prompts that require remote background/media assets, download and save assets to the specified local path before finalizing. If a signed/private URL returns AccessDenied/403, still wire the code to the requested local path, but clearly report the asset blocker and ask for a fresh/public URL; do not silently substitute a different image.
- When a new card prompt forbids elements that existed in the previous iteration (particles, icons, CTA, logo, paragraph, decorative gradients), rewrite/clean the files so old CSS/DOM does not leak into the new card.
- When the user gives a production-style HTML/CSS/Tailwind prompt, produce real files and browser-verify the rendered card instead of returning only a rewritten prompt/spec.
- Final replies for this user should be short and status-oriented: files changed, verified checklist, and blockers only.
- When the user stresses “no text issues, layout issues, or weird backgrounds,” treat that as a hard QA gate: render the final image/video, inspect it visually, and fix spelling, cropping, overlap, logo matte/white-box artifacts, image crop, button/footer placement, and invented-looking décor before saying done.
- For terminal-runnable social posts, prefer deterministic generation from exact assets (for example Python/Pillow or browser export) and save both the strict `PROMPT.md` and the generator script so the user can rerun the post creation command.
## Reference files
- `references/social-carousel-prompt-engineering.md` — detailed notes from the Open Engine/social post prompt-engineering session, including long LinkedIn content calendar handling and exact Behance reference recreation lessons.
- `references/single-animated-video-card-builds.md` — reusable notes for building and verifying one-off animated video social cards from Tailwind/HTML prompts, including asset handling and DOM QA.
- `references/html-social-card-mp4-export.md` — Playwright + ffmpeg workflow for exporting animated HTML social cards as clean 384×384 H.264 MP4 files with preview-frame QA.
- `references/behance-social-reference-extraction.md` — how to extract, dedupe, and separate final social posts from Behance project pages; includes the Social Media Automation 9-post selection pattern.
- `references/terminal-runnable-asset-based-posts.md` — workflow for turning a strict social post prompt into a deterministic terminal-runnable PNG/MP4 generator using only supplied or extracted assets, with visual QA.
- `references/public-asset-backed-social-prompts.md` — workflow for extracting/hosting public brand assets, writing shareable HTTPS asset prompts, building a real terminal-rendered output, and QAing no text/layout/weird-background issues.
## Templates
- `templates/single-animated-video-card.html` — starter structure for a single 384×384 video-backed animated card with outer background shell, z-index layers, and Tailwind font mappings.
templates/single-animated-video-card.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>{{CARD_TITLE}}</title>
<!-- Load only the fonts the brief requests. Example: -->
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link href="{{GOOGLE_FONTS_URL}}" rel="stylesheet" />
<script src="https://cdn.tailwindcss.com"></script>
<script>
tailwind.config = {
theme: {
extend: {
fontFamily: {
instrument: ['Instrument Serif', 'serif'],
inter: ['Inter', 'sans-serif'],
grotesk: ['Anton', 'sans-serif'],
condiment: ['Condiment', 'cursive'],
barlow: ['Barlow', 'sans-serif'],
poppins: ['Poppins', 'sans-serif'],
'source-serif': ['Source Serif 4', 'serif']
}
}
}
};
</script>
<link rel="stylesheet" href="./index.css" />
</head>
<body>
<div class="page-shell min-h-screen overflow-auto bg-cover bg-center bg-no-repeat flex items-center justify-center p-6">
<div class="flex items-center justify-center">
<article class="relative h-[384px] w-[384px] overflow-hidden rounded-xl bg-black shadow-2xl">
<video
class="card-video pointer-events-none absolute inset-0 z-0 h-full w-full object-cover"
src="{{VIDEO_URL}}"
autoplay
loop
muted
playsinline
aria-hidden="true"
></video>
<div class="cinematic-overlay absolute inset-0 z-[1]" aria-hidden="true"></div>
<!-- Optional badge / particles / overlay elements go here. Keep z-index below main copy unless explicitly foreground. -->
<section class="absolute inset-0 z-10 flex flex-col items-center justify-center pt-6 text-center">
{{CARD_CONTENT}}
</section>
</article>
</div>
</div>
</body>
</html>