From 5194d2000a001ba939771fc38b9b9f91464c633b Mon Sep 17 00:00:00 2001 From: Affaan Mustafa Date: Wed, 1 Apr 2026 01:31:40 -0700 Subject: [PATCH] docs: tighten voice-driven content skills --- .agents/skills/article-writing/SKILL.md | 91 +++++--- .agents/skills/content-engine/SKILL.md | 156 +++++++++---- .agents/skills/crosspost/SKILL.md | 214 ++++++----------- .agents/skills/investor-outreach/SKILL.md | 31 ++- WORKING-CONTEXT.md | 6 + skills/article-writing/SKILL.md | 91 +++++--- skills/content-engine/SKILL.md | 156 +++++++++---- skills/crosspost/SKILL.md | 216 ++++++------------ skills/investor-outreach/SKILL.md | 31 ++- skills/remotion-video-creation/rules/3d.md | 12 +- .../rules/animations.md | 8 +- .../remotion-video-creation/rules/charts.md | 4 +- .../rules/compositions.md | 4 +- .../remotion-video-creation/rules/lottie.md | 2 +- .../rules/sequencing.md | 4 +- .../remotion-video-creation/rules/tailwind.md | 2 +- .../remotion-video-creation/rules/timing.md | 12 +- .../rules/transitions.md | 4 +- .../remotion-video-creation/rules/videos.md | 2 +- 19 files changed, 545 insertions(+), 501 deletions(-) diff --git a/.agents/skills/article-writing/SKILL.md b/.agents/skills/article-writing/SKILL.md index cc4c17a8..1a890610 100644 --- a/.agents/skills/article-writing/SKILL.md +++ b/.agents/skills/article-writing/SKILL.md @@ -6,7 +6,7 @@ origin: ECC # Article Writing -Write long-form content that sounds like a real person or brand, not generic AI output. +Write long-form content that sounds like an actual person with a point of view, not an LLM smoothing itself into paste. ## When to Activate @@ -17,69 +17,90 @@ Write long-form content that sounds like a real person or brand, not generic AI ## Core Rules -1. Lead with the concrete thing: example, output, anecdote, number, screenshot description, or code block. +1. Lead with the concrete thing: artifact, example, output, anecdote, number, screenshot, or code. 2. Explain after the example, not before. -3. Prefer short, direct sentences over padded ones. -4. Use specific numbers when available and sourced. -5. Never invent biographical facts, company metrics, or customer evidence. +3. Keep sentences tight unless the source voice is intentionally expansive. +4. Use proof instead of adjectives. +5. Never invent facts, credibility, or customer evidence. ## Voice Capture Workflow If the user wants a specific voice, collect one or more of: - published articles - newsletters -- X / LinkedIn posts +- X posts or threads - docs or memos -- a short style guide +- launch notes +- a style guide Then extract: - sentence length and rhythm -- whether the voice is formal, conversational, or sharp -- favored rhetorical devices such as parentheses, lists, fragments, or questions -- tolerance for humor, opinion, and contrarian framing -- formatting habits such as headers, bullets, code blocks, and pull quotes +- whether the writing is compressed, explanatory, sharp, or formal +- how parentheses are used +- how often the writer asks questions +- whether the writer uses fragments, lists, or hard pivots +- formatting habits such as headers, bullets, code blocks, pull quotes +- what the writer clearly avoids -If no voice references are given, default to a direct, operator-style voice: concrete, practical, and low on hype. +If no voice references are given, default to a sharp operator voice: concrete, unsentimental, useful. + +## Affaan / ECC Voice Reference + +When matching Affaan / ECC voice, bias toward: +- direct claims over scene-setting +- high specificity +- parentheticals used for qualification or over-clarification, not comedy +- capitalization chosen situationally, not as a gimmick +- very low tolerance for fake thought-leadership cadence +- almost no bait questions ## Banned Patterns Delete and rewrite any of these: -- generic openings like "In today's rapidly evolving landscape" -- filler transitions such as "Moreover" and "Furthermore" -- hype phrases like "game-changer", "cutting-edge", or "revolutionary" -- vague claims without evidence -- biography or credibility claims not backed by provided context +- "In today's rapidly evolving landscape" +- "game-changer", "cutting-edge", "revolutionary" +- "no fluff" +- "not X, just Y" +- "here's why this matters" as a standalone bridge +- fake vulnerability arcs +- a closing question added only to juice engagement +- forced lowercase +- corny parenthetical asides +- biography padding that does not move the argument ## Writing Process 1. Clarify the audience and purpose. -2. Build a skeletal outline with one purpose per section. -3. Start each section with evidence, example, or scene. -4. Expand only where the next sentence earns its place. -5. Remove anything that sounds templated or self-congratulatory. +2. Build a hard outline with one job per section. +3. Start sections with proof, artifact, conflict, or example. +4. Expand only where the next sentence earns space. +5. Cut anything that sounds templated, overexplained, or self-congratulatory. ## Structure Guidance ### Technical Guides -- open with what the reader gets -- use code or terminal examples in every major section -- end with concrete takeaways, not a soft summary -### Essays / Opinion Pieces -- start with tension, contradiction, or a sharp observation +- open with what the reader gets +- use code, commands, screenshots, or concrete output in major sections +- end with actionable takeaways, not a soft recap + +### Essays / Opinion + +- start with tension, contradiction, or a specific observation - keep one argument thread per section -- use examples that earn the opinion +- make opinions answer to evidence ### Newsletters -- keep the first screen strong -- mix insight with updates, not diary filler -- use clear section labels and easy skim structure + +- keep the first screen doing real work +- do not front-load diary filler +- use section labels only when they improve scanability ## Quality Gate Before delivering: -- verify factual claims against provided sources -- remove filler and corporate language -- confirm the voice matches the supplied examples -- ensure every section adds new information -- check formatting for the intended platform +- factual claims are backed by provided sources +- generic AI transitions are gone +- the voice matches the supplied examples +- every section adds something new +- formatting matches the intended medium diff --git a/.agents/skills/content-engine/SKILL.md b/.agents/skills/content-engine/SKILL.md index 9398c31a..3738de93 100644 --- a/.agents/skills/content-engine/SKILL.md +++ b/.agents/skills/content-engine/SKILL.md @@ -6,83 +6,145 @@ origin: ECC # Content Engine -Turn one idea into strong, platform-native content instead of posting the same thing everywhere. +Build platform-native content without flattening the author's real voice into platform slop. ## When to Activate - writing X posts or threads - drafting LinkedIn posts or launch updates - scripting short-form video or YouTube explainers -- repurposing articles, podcasts, demos, or docs into social content -- building a lightweight content plan around a launch, milestone, or theme +- repurposing articles, podcasts, demos, docs, or internal notes into public content +- building a launch sequence or ongoing content system around a product, insight, or narrative -## First Questions +## Non-Negotiables -Clarify: -- source asset: what are we adapting from -- audience: builders, investors, customers, operators, or general audience -- platform: X, LinkedIn, TikTok, YouTube, newsletter, or multi-platform -- goal: awareness, conversion, recruiting, authority, launch support, or engagement +1. Start from source material, not generic post formulas. +2. Adapt the format for the platform, not the persona. +3. One post should carry one actual claim. +4. Specificity beats adjectives. +5. No engagement bait unless the user explicitly asks for it. -## Core Rules +## Source-First Workflow -1. Adapt for the platform. Do not cross-post the same copy. -2. Hooks matter more than summaries. -3. Every post should carry one clear idea. -4. Use specifics over slogans. -5. Keep the ask small and clear. +Before drafting, identify the source set: +- published articles +- notes or internal memos +- product demos +- docs or changelogs +- transcripts +- screenshots +- prior posts from the same author -## Platform Guidance +If the user wants a specific voice, build a voice profile from real examples before writing. + +## Voice Capture Workflow + +Collect 5 to 20 examples when available. Good sources: +- articles or essays +- X posts or threads +- docs or release notes +- newsletters +- previous launch posts + +If live X access is available, use `x-api` to pull recent original posts before drafting. If not, use the examples already provided or present in the repo. + +Extract and write down: +- sentence length and rhythm +- how compressed or explanatory the writing is +- whether capitalization is conventional, mixed, or situational +- how parentheses are used +- whether the writer uses fragments, lists, or abrupt pivots +- how often the writer asks questions +- how sharp, formal, opinionated, or dry the voice is +- what the writer never does + +Do not start drafting until the voice profile is clear enough to enforce. + +## Affaan / ECC Voice Reference + +When the user wants Affaan / ECC voice specifically, default to this unless newer examples clearly override it: +- direct, compressed, concrete +- strong preference for specific claims, numbers, mechanisms, and receipts +- parentheticals used to qualify, narrow, or over-clarify, not to do corny bits +- lowercase is optional, not mandatory +- questions are rare and should not be added as bait +- transitions should feel earned, not polished +- tone can be sharp or blunt, but should not sound like a content marketer + +## Hard Bans + +Delete and rewrite any of these: +- "In today's rapidly evolving landscape" +- "game-changer", "revolutionary", "cutting-edge" +- "no fluff" +- "not X, just Y" +- "here's why this matters" unless it is followed immediately by something concrete +- "Excited to share" +- fake curiosity gaps +- ending with a LinkedIn-style question just to farm replies +- forced lowercase when the source voice does not call for it +- forced casualness on LinkedIn +- parenthetical jokes that were not present in the source voice + +## Platform Adaptation Rules ### X -- open fast -- one idea per post or per tweet in a thread -- keep links out of the main body unless necessary -- avoid hashtag spam + +- open with the strongest claim, artifact, or tension +- keep the compression if the source voice is compressed +- if writing a thread, each post must advance the argument +- do not pad with context the audience does not need ### LinkedIn -- strong first line -- short paragraphs -- more explicit framing around lessons, results, and takeaways -### TikTok / Short Video -- first 3 seconds must interrupt attention -- script around visuals, not just narration -- one demo, one claim, one CTA +- expand only enough for people outside the immediate niche to follow +- do not turn it into a fake lesson post unless the source material actually is reflective +- no corporate inspiration cadence +- no praise-stacking, no "journey" filler + +### Short Video + +- script around the visual sequence and proof points +- first seconds should show the result, problem, or punch +- do not write narration that sounds better on paper than on screen ### YouTube -- show the result early -- structure by chapter -- refresh the visual every 20-30 seconds + +- show the result or tension early +- organize by argument or progression, not filler sections +- use chaptering only when it helps clarity ### Newsletter -- deliver one clear lens, not a bundle of unrelated items -- make section titles skimmable -- keep the opening paragraph doing real work + +- open with the point, conflict, or artifact +- do not spend the first paragraph warming up +- every section needs to add something new ## Repurposing Flow -Default cascade: -1. anchor asset: article, video, demo, memo, or launch doc -2. extract 3-7 atomic ideas -3. write platform-native variants -4. trim repetition across outputs -5. align CTAs with platform intent +1. Pick the anchor asset. +2. Extract 3 to 7 atomic claims or scenes. +3. Rank them by sharpness, novelty, and proof. +4. Assign one strong idea per output. +5. Adapt structure for each platform. +6. Strip platform-shaped filler. +7. Run the quality gate. ## Deliverables When asked for a campaign, return: +- a short voice profile if voice matching matters - the core angle -- platform-specific drafts -- optional posting order -- optional CTA variants -- any missing inputs needed before publishing +- platform-native drafts +- posting order only if it helps execution +- gaps that must be filled before publishing ## Quality Gate Before delivering: -- each draft reads natively for its platform -- hooks are strong and specific -- no generic hype language +- every draft sounds like the intended author, not the platform stereotype +- every draft contains a real claim, proof point, or concrete observation +- no generic hype language remains +- no fake engagement bait remains - no duplicated copy across platforms unless requested -- the CTA matches the content and audience +- any CTA is earned and user-approved diff --git a/.agents/skills/crosspost/SKILL.md b/.agents/skills/crosspost/SKILL.md index b67192e7..41e84eb3 100644 --- a/.agents/skills/crosspost/SKILL.md +++ b/.agents/skills/crosspost/SKILL.md @@ -6,183 +6,109 @@ origin: ECC # Crosspost -Distribute content across multiple social platforms with platform-native adaptation. +Distribute content across platforms without turning it into the same fake post in four costumes. ## When to Activate -- User wants to post content to multiple platforms -- Publishing announcements, launches, or updates across social media -- Repurposing a post from one platform to others -- User says "crosspost", "post everywhere", "share on all platforms", or "distribute this" +- the user wants to publish the same underlying idea across multiple platforms +- a launch, update, release, or essay needs platform-specific versions +- the user says "crosspost", "post this everywhere", or "adapt this for X and LinkedIn" ## Core Rules -1. **Never post identical content cross-platform.** Each platform gets a native adaptation. -2. **Primary platform first.** Post to the main platform, then adapt for others. -3. **Respect platform conventions.** Length limits, formatting, link handling all differ. -4. **One idea per post.** If the source content has multiple ideas, split across posts. -5. **Attribution matters.** If crossposting someone else's content, credit the source. - -## Platform Specifications - -| Platform | Max Length | Link Handling | Hashtags | Media | -|----------|-----------|---------------|----------|-------| -| X | 280 chars (4000 for Premium) | Counted in length | Minimal (1-2 max) | Images, video, GIFs | -| LinkedIn | 3000 chars | Not counted in length | 3-5 relevant | Images, video, docs, carousels | -| Threads | 500 chars | Separate link attachment | None typical | Images, video | -| Bluesky | 300 chars | Via facets (rich text) | None (use feeds) | Images | +1. Do not publish identical copy across platforms. +2. Preserve the author's voice across platforms. +3. Adapt for constraints, not stereotypes. +4. One post should still be about one thing. +5. Do not invent a CTA, question, or moral if the source did not earn one. ## Workflow -### Step 1: Create Source Content +### Step 1: Start with the Primary Version -Start with the core idea. Use `content-engine` skill for high-quality drafts: -- Identify the single core message -- Determine the primary platform (where the audience is biggest) -- Draft the primary platform version first +Pick the strongest source version first: +- the original X post +- the original article +- the launch note +- the thread +- the memo or changelog -### Step 2: Identify Target Platforms +Use `content-engine` first if the source still needs voice shaping. -Ask the user or determine from context: -- Which platforms to target -- Priority order (primary gets the best version) -- Any platform-specific requirements (e.g., LinkedIn needs professional tone) +### Step 2: Capture the Voice Fingerprint -### Step 3: Adapt Per Platform +Before adapting, note: +- how blunt or explanatory the source is +- whether the source uses fragments, lists, or longer transitions +- whether the source uses parentheses +- whether the source avoids questions, hashtags, or CTA language -For each target platform, transform the content: +The adaptation should preserve that fingerprint. -**X adaptation:** -- Open with a hook, not a summary -- Cut to the core insight fast -- Keep links out of main body when possible -- Use thread format for longer content +### Step 3: Adapt by Platform Constraint -**LinkedIn adaptation:** -- Strong first line (visible before "see more") -- Short paragraphs with line breaks -- Frame around lessons, results, or professional takeaways -- More explicit context than X (LinkedIn audience needs framing) +### X -**Threads adaptation:** -- Conversational, casual tone -- Shorter than LinkedIn, less compressed than X -- Visual-first if possible +- keep it compressed +- lead with the sharpest claim or artifact +- use a thread only when a single post would collapse the argument +- avoid hashtags and generic filler -**Bluesky adaptation:** -- Direct and concise (300 char limit) -- Community-oriented tone -- Use feeds/lists for topic targeting instead of hashtags +### LinkedIn -### Step 4: Post Primary Platform +- add only the context needed for people outside the niche +- do not turn it into a fake founder-reflection post +- do not add a closing question just because it is LinkedIn +- do not force a polished "professional tone" if the author is naturally sharper -Post to the primary platform first: -- Use `x-api` skill for X -- Use platform-specific APIs or tools for others -- Capture the post URL for cross-referencing +### Threads -### Step 5: Post to Secondary Platforms +- keep it readable and direct +- do not write fake hyper-casual creator copy +- do not paste the LinkedIn version and shorten it -Post adapted versions to remaining platforms: -- Stagger timing (not all at once — 30-60 min gaps) -- Include cross-platform references where appropriate ("longer thread on X" etc.) +### Bluesky -## Content Adaptation Examples +- keep it concise +- preserve the author's cadence +- do not rely on hashtags or feed-gaming language -### Source: Product Launch +## Posting Order -**X version:** -``` -We just shipped [feature]. +Default: +1. post the strongest native version first +2. adapt for the secondary platforms +3. stagger timing only if the user wants sequencing help -[One specific thing it does that's impressive] +Do not add cross-platform references unless useful. Most of the time, the post should stand on its own. -[Link] -``` +## Banned Patterns -**LinkedIn version:** -``` -Excited to share: we just launched [feature] at [Company]. +Delete and rewrite any of these: +- "Excited to share" +- "Here's what I learned" +- "What do you think?" +- "link in bio" unless that is literally true +- "not X, just Y" +- generic "professional takeaway" paragraphs that were not in the source -Here's why it matters: +## Output Format -[2-3 short paragraphs with context] - -[Takeaway for the audience] - -[Link] -``` - -**Threads version:** -``` -just shipped something cool — [feature] - -[casual explanation of what it does] - -link in bio -``` - -### Source: Technical Insight - -**X version:** -``` -TIL: [specific technical insight] - -[Why it matters in one sentence] -``` - -**LinkedIn version:** -``` -A pattern I've been using that's made a real difference: - -[Technical insight with professional framing] - -[How it applies to teams/orgs] - -#relevantHashtag -``` - -## API Integration - -### Batch Crossposting Service (Example Pattern) -If using a crossposting service (e.g., Postbridge, Buffer, or a custom API), the pattern looks like: - -```python -import os -import requests - -resp = requests.post( - "https://api.postbridge.io/v1/posts", - headers={"Authorization": f"Bearer {os.environ['POSTBRIDGE_API_KEY']}"}, - json={ - "platforms": ["twitter", "linkedin", "threads"], - "content": { - "twitter": {"text": x_version}, - "linkedin": {"text": linkedin_version}, - "threads": {"text": threads_version} - } - } -) -``` - -### Manual Posting -Without Postbridge, post to each platform using its native API: -- X: Use `x-api` skill patterns -- LinkedIn: LinkedIn API v2 with OAuth 2.0 -- Threads: Threads API (Meta) -- Bluesky: AT Protocol API +Return: +- the primary platform version +- adapted variants for each requested platform +- a short note on what changed and why +- any publishing constraint the user still needs to resolve ## Quality Gate -Before posting: -- [ ] Each platform version reads naturally for that platform -- [ ] No identical content across platforms -- [ ] Length limits respected -- [ ] Links work and are placed appropriately -- [ ] Tone matches platform conventions -- [ ] Media is sized correctly for each platform +Before delivering: +- each version reads like the same author under different constraints +- no platform version feels padded or sanitized +- no copy is duplicated verbatim across platforms +- any extra context added for LinkedIn or newsletter use is actually necessary ## Related Skills -- `content-engine` — Generate platform-native content -- `x-api` — X/Twitter API integration +- `content-engine` for voice capture and source shaping +- `x-api` for X publishing workflows diff --git a/.agents/skills/investor-outreach/SKILL.md b/.agents/skills/investor-outreach/SKILL.md index 4fc69f4c..9abef521 100644 --- a/.agents/skills/investor-outreach/SKILL.md +++ b/.agents/skills/investor-outreach/SKILL.md @@ -6,7 +6,7 @@ origin: ECC # Investor Outreach -Write investor communication that is short, personalized, and easy to act on. +Write investor communication that is short, concrete, and easy to act on. ## When to Activate @@ -20,17 +20,28 @@ Write investor communication that is short, personalized, and easy to act on. 1. Personalize every outbound message. 2. Keep the ask low-friction. -3. Use proof, not adjectives. +3. Use proof instead of adjectives. 4. Stay concise. -5. Never send generic copy that could go to any investor. +5. Never send copy that could go to any investor. + +## Hard Bans + +Delete and rewrite any of these: +- "I'd love to connect" +- "excited to share" +- generic thesis praise without a real tie-in +- vague founder adjectives +- "no fluff" +- begging language +- soft closing questions when a direct ask is clearer ## Cold Email Structure 1. subject line: short and specific 2. opener: why this investor specifically -3. pitch: what the company does, why now, what proof matters +3. pitch: what the company does, why now, and what proof matters 4. ask: one concrete next step -5. sign-off: name, role, one credibility anchor if needed +5. sign-off: name, role, and one credibility anchor if needed ## Personalization Sources @@ -40,14 +51,14 @@ Reference one or more of: - a mutual connection - a clear market or product fit with the investor's focus -If that context is missing, ask for it or state that the draft is a template awaiting personalization. +If that context is missing, state that the draft still needs personalization instead of pretending it is finished. ## Follow-Up Cadence Default: - day 0: initial outbound -- day 4-5: short follow-up with one new data point -- day 10-12: final follow-up with a clean close +- day 4 or 5: short follow-up with one new data point +- day 10 to 12: final follow-up with a clean close Do not keep nudging after that unless the user wants a longer sequence. @@ -69,8 +80,8 @@ Include: ## Quality Gate Before delivering: -- message is personalized +- the message is genuinely personalized - the ask is explicit -- there is no fluff or begging language - the proof point is concrete +- filler praise and softener language are gone - word count stays tight diff --git a/WORKING-CONTEXT.md b/WORKING-CONTEXT.md index 4d7fef00..0a21c997 100644 --- a/WORKING-CONTEXT.md +++ b/WORKING-CONTEXT.md @@ -30,6 +30,10 @@ Public ECC plugin repo for agents, skills, commands, hooks, rules, install surfa - control plane primitives - operator surface - self-improving skills +- Skill quality: + - rewrite content-facing skills to use source-backed voice modeling + - remove generic LLM rhetoric, canned CTA patterns, and forced platform stereotypes + - continue one-by-one audit of overlapping or low-signal skill content - Security: - keep dependency posture clean - preserve self-contained hook and MCP behavior @@ -78,3 +82,5 @@ Keep this file detailed for only the current sprint, blockers, and next actions. - 2026-04-01: Repo catalog truth is now synced at `36` agents, `68` commands, and `142` skills across the tracked English and zh-CN docs. - 2026-04-01: Legacy emoji and non-essential symbol usage in docs, scripts, and tests was normalized to keep the unicode-safety lane green without weakening the check itself. - 2026-04-01: The remaining self-contained piece of `#834`, `docs/zh-CN/skills/browser-qa/SKILL.md`, was ported directly into the repo. After commit, `#834` should be closed as superseded-by-direct-port. +- 2026-04-01: Content skill cleanup started with `content-engine`, `crosspost`, `article-writing`, and `investor-outreach`. The new direction is source-first voice capture, explicit anti-trope bans, and no forced platform persona shifts. +- 2026-04-01: `node scripts/ci/check-unicode-safety.js --write` sanitized the remaining emoji-bearing Markdown files, including several `remotion-video-creation` rule docs and an old local plan note. diff --git a/skills/article-writing/SKILL.md b/skills/article-writing/SKILL.md index cc4c17a8..1a890610 100644 --- a/skills/article-writing/SKILL.md +++ b/skills/article-writing/SKILL.md @@ -6,7 +6,7 @@ origin: ECC # Article Writing -Write long-form content that sounds like a real person or brand, not generic AI output. +Write long-form content that sounds like an actual person with a point of view, not an LLM smoothing itself into paste. ## When to Activate @@ -17,69 +17,90 @@ Write long-form content that sounds like a real person or brand, not generic AI ## Core Rules -1. Lead with the concrete thing: example, output, anecdote, number, screenshot description, or code block. +1. Lead with the concrete thing: artifact, example, output, anecdote, number, screenshot, or code. 2. Explain after the example, not before. -3. Prefer short, direct sentences over padded ones. -4. Use specific numbers when available and sourced. -5. Never invent biographical facts, company metrics, or customer evidence. +3. Keep sentences tight unless the source voice is intentionally expansive. +4. Use proof instead of adjectives. +5. Never invent facts, credibility, or customer evidence. ## Voice Capture Workflow If the user wants a specific voice, collect one or more of: - published articles - newsletters -- X / LinkedIn posts +- X posts or threads - docs or memos -- a short style guide +- launch notes +- a style guide Then extract: - sentence length and rhythm -- whether the voice is formal, conversational, or sharp -- favored rhetorical devices such as parentheses, lists, fragments, or questions -- tolerance for humor, opinion, and contrarian framing -- formatting habits such as headers, bullets, code blocks, and pull quotes +- whether the writing is compressed, explanatory, sharp, or formal +- how parentheses are used +- how often the writer asks questions +- whether the writer uses fragments, lists, or hard pivots +- formatting habits such as headers, bullets, code blocks, pull quotes +- what the writer clearly avoids -If no voice references are given, default to a direct, operator-style voice: concrete, practical, and low on hype. +If no voice references are given, default to a sharp operator voice: concrete, unsentimental, useful. + +## Affaan / ECC Voice Reference + +When matching Affaan / ECC voice, bias toward: +- direct claims over scene-setting +- high specificity +- parentheticals used for qualification or over-clarification, not comedy +- capitalization chosen situationally, not as a gimmick +- very low tolerance for fake thought-leadership cadence +- almost no bait questions ## Banned Patterns Delete and rewrite any of these: -- generic openings like "In today's rapidly evolving landscape" -- filler transitions such as "Moreover" and "Furthermore" -- hype phrases like "game-changer", "cutting-edge", or "revolutionary" -- vague claims without evidence -- biography or credibility claims not backed by provided context +- "In today's rapidly evolving landscape" +- "game-changer", "cutting-edge", "revolutionary" +- "no fluff" +- "not X, just Y" +- "here's why this matters" as a standalone bridge +- fake vulnerability arcs +- a closing question added only to juice engagement +- forced lowercase +- corny parenthetical asides +- biography padding that does not move the argument ## Writing Process 1. Clarify the audience and purpose. -2. Build a skeletal outline with one purpose per section. -3. Start each section with evidence, example, or scene. -4. Expand only where the next sentence earns its place. -5. Remove anything that sounds templated or self-congratulatory. +2. Build a hard outline with one job per section. +3. Start sections with proof, artifact, conflict, or example. +4. Expand only where the next sentence earns space. +5. Cut anything that sounds templated, overexplained, or self-congratulatory. ## Structure Guidance ### Technical Guides -- open with what the reader gets -- use code or terminal examples in every major section -- end with concrete takeaways, not a soft summary -### Essays / Opinion Pieces -- start with tension, contradiction, or a sharp observation +- open with what the reader gets +- use code, commands, screenshots, or concrete output in major sections +- end with actionable takeaways, not a soft recap + +### Essays / Opinion + +- start with tension, contradiction, or a specific observation - keep one argument thread per section -- use examples that earn the opinion +- make opinions answer to evidence ### Newsletters -- keep the first screen strong -- mix insight with updates, not diary filler -- use clear section labels and easy skim structure + +- keep the first screen doing real work +- do not front-load diary filler +- use section labels only when they improve scanability ## Quality Gate Before delivering: -- verify factual claims against provided sources -- remove filler and corporate language -- confirm the voice matches the supplied examples -- ensure every section adds new information -- check formatting for the intended platform +- factual claims are backed by provided sources +- generic AI transitions are gone +- the voice matches the supplied examples +- every section adds something new +- formatting matches the intended medium diff --git a/skills/content-engine/SKILL.md b/skills/content-engine/SKILL.md index 9398c31a..3738de93 100644 --- a/skills/content-engine/SKILL.md +++ b/skills/content-engine/SKILL.md @@ -6,83 +6,145 @@ origin: ECC # Content Engine -Turn one idea into strong, platform-native content instead of posting the same thing everywhere. +Build platform-native content without flattening the author's real voice into platform slop. ## When to Activate - writing X posts or threads - drafting LinkedIn posts or launch updates - scripting short-form video or YouTube explainers -- repurposing articles, podcasts, demos, or docs into social content -- building a lightweight content plan around a launch, milestone, or theme +- repurposing articles, podcasts, demos, docs, or internal notes into public content +- building a launch sequence or ongoing content system around a product, insight, or narrative -## First Questions +## Non-Negotiables -Clarify: -- source asset: what are we adapting from -- audience: builders, investors, customers, operators, or general audience -- platform: X, LinkedIn, TikTok, YouTube, newsletter, or multi-platform -- goal: awareness, conversion, recruiting, authority, launch support, or engagement +1. Start from source material, not generic post formulas. +2. Adapt the format for the platform, not the persona. +3. One post should carry one actual claim. +4. Specificity beats adjectives. +5. No engagement bait unless the user explicitly asks for it. -## Core Rules +## Source-First Workflow -1. Adapt for the platform. Do not cross-post the same copy. -2. Hooks matter more than summaries. -3. Every post should carry one clear idea. -4. Use specifics over slogans. -5. Keep the ask small and clear. +Before drafting, identify the source set: +- published articles +- notes or internal memos +- product demos +- docs or changelogs +- transcripts +- screenshots +- prior posts from the same author -## Platform Guidance +If the user wants a specific voice, build a voice profile from real examples before writing. + +## Voice Capture Workflow + +Collect 5 to 20 examples when available. Good sources: +- articles or essays +- X posts or threads +- docs or release notes +- newsletters +- previous launch posts + +If live X access is available, use `x-api` to pull recent original posts before drafting. If not, use the examples already provided or present in the repo. + +Extract and write down: +- sentence length and rhythm +- how compressed or explanatory the writing is +- whether capitalization is conventional, mixed, or situational +- how parentheses are used +- whether the writer uses fragments, lists, or abrupt pivots +- how often the writer asks questions +- how sharp, formal, opinionated, or dry the voice is +- what the writer never does + +Do not start drafting until the voice profile is clear enough to enforce. + +## Affaan / ECC Voice Reference + +When the user wants Affaan / ECC voice specifically, default to this unless newer examples clearly override it: +- direct, compressed, concrete +- strong preference for specific claims, numbers, mechanisms, and receipts +- parentheticals used to qualify, narrow, or over-clarify, not to do corny bits +- lowercase is optional, not mandatory +- questions are rare and should not be added as bait +- transitions should feel earned, not polished +- tone can be sharp or blunt, but should not sound like a content marketer + +## Hard Bans + +Delete and rewrite any of these: +- "In today's rapidly evolving landscape" +- "game-changer", "revolutionary", "cutting-edge" +- "no fluff" +- "not X, just Y" +- "here's why this matters" unless it is followed immediately by something concrete +- "Excited to share" +- fake curiosity gaps +- ending with a LinkedIn-style question just to farm replies +- forced lowercase when the source voice does not call for it +- forced casualness on LinkedIn +- parenthetical jokes that were not present in the source voice + +## Platform Adaptation Rules ### X -- open fast -- one idea per post or per tweet in a thread -- keep links out of the main body unless necessary -- avoid hashtag spam + +- open with the strongest claim, artifact, or tension +- keep the compression if the source voice is compressed +- if writing a thread, each post must advance the argument +- do not pad with context the audience does not need ### LinkedIn -- strong first line -- short paragraphs -- more explicit framing around lessons, results, and takeaways -### TikTok / Short Video -- first 3 seconds must interrupt attention -- script around visuals, not just narration -- one demo, one claim, one CTA +- expand only enough for people outside the immediate niche to follow +- do not turn it into a fake lesson post unless the source material actually is reflective +- no corporate inspiration cadence +- no praise-stacking, no "journey" filler + +### Short Video + +- script around the visual sequence and proof points +- first seconds should show the result, problem, or punch +- do not write narration that sounds better on paper than on screen ### YouTube -- show the result early -- structure by chapter -- refresh the visual every 20-30 seconds + +- show the result or tension early +- organize by argument or progression, not filler sections +- use chaptering only when it helps clarity ### Newsletter -- deliver one clear lens, not a bundle of unrelated items -- make section titles skimmable -- keep the opening paragraph doing real work + +- open with the point, conflict, or artifact +- do not spend the first paragraph warming up +- every section needs to add something new ## Repurposing Flow -Default cascade: -1. anchor asset: article, video, demo, memo, or launch doc -2. extract 3-7 atomic ideas -3. write platform-native variants -4. trim repetition across outputs -5. align CTAs with platform intent +1. Pick the anchor asset. +2. Extract 3 to 7 atomic claims or scenes. +3. Rank them by sharpness, novelty, and proof. +4. Assign one strong idea per output. +5. Adapt structure for each platform. +6. Strip platform-shaped filler. +7. Run the quality gate. ## Deliverables When asked for a campaign, return: +- a short voice profile if voice matching matters - the core angle -- platform-specific drafts -- optional posting order -- optional CTA variants -- any missing inputs needed before publishing +- platform-native drafts +- posting order only if it helps execution +- gaps that must be filled before publishing ## Quality Gate Before delivering: -- each draft reads natively for its platform -- hooks are strong and specific -- no generic hype language +- every draft sounds like the intended author, not the platform stereotype +- every draft contains a real claim, proof point, or concrete observation +- no generic hype language remains +- no fake engagement bait remains - no duplicated copy across platforms unless requested -- the CTA matches the content and audience +- any CTA is earned and user-approved diff --git a/skills/crosspost/SKILL.md b/skills/crosspost/SKILL.md index da07ec80..41e84eb3 100644 --- a/skills/crosspost/SKILL.md +++ b/skills/crosspost/SKILL.md @@ -6,185 +6,109 @@ origin: ECC # Crosspost -Distribute content across multiple social platforms with platform-native adaptation. +Distribute content across platforms without turning it into the same fake post in four costumes. ## When to Activate -- User wants to post content to multiple platforms -- Publishing announcements, launches, or updates across social media -- Repurposing a post from one platform to others -- User says "crosspost", "post everywhere", "share on all platforms", or "distribute this" +- the user wants to publish the same underlying idea across multiple platforms +- a launch, update, release, or essay needs platform-specific versions +- the user says "crosspost", "post this everywhere", or "adapt this for X and LinkedIn" ## Core Rules -1. **Never post identical content cross-platform.** Each platform gets a native adaptation. -2. **Primary platform first.** Post to the main platform, then adapt for others. -3. **Respect platform conventions.** Length limits, formatting, link handling all differ. -4. **One idea per post.** If the source content has multiple ideas, split across posts. -5. **Attribution matters.** If crossposting someone else's content, credit the source. - -## Platform Specifications - -| Platform | Max Length | Link Handling | Hashtags | Media | -|----------|-----------|---------------|----------|-------| -| X | 280 chars (4000 for Premium) | Counted in length | Minimal (1-2 max) | Images, video, GIFs | -| LinkedIn | 3000 chars | Not counted in length | 3-5 relevant | Images, video, docs, carousels | -| Threads | 500 chars | Separate link attachment | None typical | Images, video | -| Bluesky | 300 chars | Via facets (rich text) | None (use feeds) | Images | +1. Do not publish identical copy across platforms. +2. Preserve the author's voice across platforms. +3. Adapt for constraints, not stereotypes. +4. One post should still be about one thing. +5. Do not invent a CTA, question, or moral if the source did not earn one. ## Workflow -### Step 1: Create Source Content +### Step 1: Start with the Primary Version -Start with the core idea. Use `content-engine` skill for high-quality drafts: -- Identify the single core message -- Determine the primary platform (where the audience is biggest) -- Draft the primary platform version first +Pick the strongest source version first: +- the original X post +- the original article +- the launch note +- the thread +- the memo or changelog -### Step 2: Identify Target Platforms +Use `content-engine` first if the source still needs voice shaping. -Ask the user or determine from context: -- Which platforms to target -- Priority order (primary gets the best version) -- Any platform-specific requirements (e.g., LinkedIn needs professional tone) +### Step 2: Capture the Voice Fingerprint -### Step 3: Adapt Per Platform +Before adapting, note: +- how blunt or explanatory the source is +- whether the source uses fragments, lists, or longer transitions +- whether the source uses parentheses +- whether the source avoids questions, hashtags, or CTA language -For each target platform, transform the content: +The adaptation should preserve that fingerprint. -**X adaptation:** -- Open with a hook, not a summary -- Cut to the core insight fast -- Keep links out of main body when possible -- Use thread format for longer content +### Step 3: Adapt by Platform Constraint -**LinkedIn adaptation:** -- Strong first line (visible before "see more") -- Short paragraphs with line breaks -- Frame around lessons, results, or professional takeaways -- More explicit context than X (LinkedIn audience needs framing) +### X -**Threads adaptation:** -- Conversational, casual tone -- Shorter than LinkedIn, less compressed than X -- Visual-first if possible +- keep it compressed +- lead with the sharpest claim or artifact +- use a thread only when a single post would collapse the argument +- avoid hashtags and generic filler -**Bluesky adaptation:** -- Direct and concise (300 char limit) -- Community-oriented tone -- Use feeds/lists for topic targeting instead of hashtags +### LinkedIn -### Step 4: Post Primary Platform +- add only the context needed for people outside the niche +- do not turn it into a fake founder-reflection post +- do not add a closing question just because it is LinkedIn +- do not force a polished "professional tone" if the author is naturally sharper -Post to the primary platform first: -- Use `x-api` skill for X -- Use platform-specific APIs or tools for others -- Capture the post URL for cross-referencing +### Threads -### Step 5: Post to Secondary Platforms +- keep it readable and direct +- do not write fake hyper-casual creator copy +- do not paste the LinkedIn version and shorten it -Post adapted versions to remaining platforms: -- Stagger timing (not all at once — 30-60 min gaps) -- Include cross-platform references where appropriate ("longer thread on X" etc.) +### Bluesky -## Content Adaptation Examples +- keep it concise +- preserve the author's cadence +- do not rely on hashtags or feed-gaming language -### Source: Product Launch +## Posting Order -**X version:** -``` -We just shipped [feature]. +Default: +1. post the strongest native version first +2. adapt for the secondary platforms +3. stagger timing only if the user wants sequencing help -[One specific thing it does that's impressive] +Do not add cross-platform references unless useful. Most of the time, the post should stand on its own. -[Link] -``` +## Banned Patterns -**LinkedIn version:** -``` -Excited to share: we just launched [feature] at [Company]. +Delete and rewrite any of these: +- "Excited to share" +- "Here's what I learned" +- "What do you think?" +- "link in bio" unless that is literally true +- "not X, just Y" +- generic "professional takeaway" paragraphs that were not in the source -Here's why it matters: +## Output Format -[2-3 short paragraphs with context] - -[Takeaway for the audience] - -[Link] -``` - -**Threads version:** -``` -just shipped something cool — [feature] - -[casual explanation of what it does] - -link in bio -``` - -### Source: Technical Insight - -**X version:** -``` -TIL: [specific technical insight] - -[Why it matters in one sentence] -``` - -**LinkedIn version:** -``` -A pattern I've been using that's made a real difference: - -[Technical insight with professional framing] - -[How it applies to teams/orgs] - -#relevantHashtag -``` - -## API Integration - -### Batch Crossposting Service (Example Pattern) -If using a crossposting service (e.g., Postbridge, Buffer, or a custom API), the pattern looks like: - -```python -import os -import requests - -resp = requests.post( - "https://your-crosspost-service.example/api/posts", - headers={"Authorization": f"Bearer {os.environ['POSTBRIDGE_API_KEY']}"}, - json={ - "platforms": ["twitter", "linkedin", "threads"], - "content": { - "twitter": {"text": x_version}, - "linkedin": {"text": linkedin_version}, - "threads": {"text": threads_version} - } - }, - timeout=30, -) -resp.raise_for_status() -``` - -### Manual Posting -Without Postbridge, post to each platform using its native API: -- X: Use `x-api` skill patterns -- LinkedIn: LinkedIn API v2 with OAuth 2.0 -- Threads: Threads API (Meta) -- Bluesky: AT Protocol API +Return: +- the primary platform version +- adapted variants for each requested platform +- a short note on what changed and why +- any publishing constraint the user still needs to resolve ## Quality Gate -Before posting: -- [ ] Each platform version reads naturally for that platform -- [ ] No identical content across platforms -- [ ] Length limits respected -- [ ] Links work and are placed appropriately -- [ ] Tone matches platform conventions -- [ ] Media is sized correctly for each platform +Before delivering: +- each version reads like the same author under different constraints +- no platform version feels padded or sanitized +- no copy is duplicated verbatim across platforms +- any extra context added for LinkedIn or newsletter use is actually necessary ## Related Skills -- `content-engine` — Generate platform-native content -- `x-api` — X/Twitter API integration +- `content-engine` for voice capture and source shaping +- `x-api` for X publishing workflows diff --git a/skills/investor-outreach/SKILL.md b/skills/investor-outreach/SKILL.md index 4fc69f4c..9abef521 100644 --- a/skills/investor-outreach/SKILL.md +++ b/skills/investor-outreach/SKILL.md @@ -6,7 +6,7 @@ origin: ECC # Investor Outreach -Write investor communication that is short, personalized, and easy to act on. +Write investor communication that is short, concrete, and easy to act on. ## When to Activate @@ -20,17 +20,28 @@ Write investor communication that is short, personalized, and easy to act on. 1. Personalize every outbound message. 2. Keep the ask low-friction. -3. Use proof, not adjectives. +3. Use proof instead of adjectives. 4. Stay concise. -5. Never send generic copy that could go to any investor. +5. Never send copy that could go to any investor. + +## Hard Bans + +Delete and rewrite any of these: +- "I'd love to connect" +- "excited to share" +- generic thesis praise without a real tie-in +- vague founder adjectives +- "no fluff" +- begging language +- soft closing questions when a direct ask is clearer ## Cold Email Structure 1. subject line: short and specific 2. opener: why this investor specifically -3. pitch: what the company does, why now, what proof matters +3. pitch: what the company does, why now, and what proof matters 4. ask: one concrete next step -5. sign-off: name, role, one credibility anchor if needed +5. sign-off: name, role, and one credibility anchor if needed ## Personalization Sources @@ -40,14 +51,14 @@ Reference one or more of: - a mutual connection - a clear market or product fit with the investor's focus -If that context is missing, ask for it or state that the draft is a template awaiting personalization. +If that context is missing, state that the draft still needs personalization instead of pretending it is finished. ## Follow-Up Cadence Default: - day 0: initial outbound -- day 4-5: short follow-up with one new data point -- day 10-12: final follow-up with a clean close +- day 4 or 5: short follow-up with one new data point +- day 10 to 12: final follow-up with a clean close Do not keep nudging after that unless the user wants a longer sequence. @@ -69,8 +80,8 @@ Include: ## Quality Gate Before delivering: -- message is personalized +- the message is genuinely personalized - the ask is explicit -- there is no fluff or begging language - the proof point is concrete +- filler praise and softener language are gone - word count stays tight diff --git a/skills/remotion-video-creation/rules/3d.md b/skills/remotion-video-creation/rules/3d.md index 31fa5c67..9a2cca4a 100644 --- a/skills/remotion-video-creation/rules/3d.md +++ b/skills/remotion-video-creation/rules/3d.md @@ -7,12 +7,12 @@ metadata: # Using Three.js and React Three Fiber in Remotion -Follow React Three Fiber and Three.js best practices. +Follow React Three Fiber and Three.js best practices. Only the following Remotion-specific rules need to be followed: ## Prerequisites -First, the `@remotion/three` package needs to be installed. +First, the `@remotion/three` package needs to be installed. If it is not, use the following command: ```bash @@ -24,7 +24,7 @@ pnpm exec remotion add @remotion/three # If project uses pnpm ## Using ThreeCanvas -You MUST wrap 3D content in `` and include proper lighting. +You MUST wrap 3D content in `` and include proper lighting. `` MUST have a `width` and `height` prop. ```tsx @@ -45,9 +45,9 @@ const { width, height } = useVideoConfig(); ## No animations not driven by `useCurrentFrame()` -Shaders, models etc MUST NOT animate by themselves. -No animations are allowed unless they are driven by `useCurrentFrame()`. -Otherwise, it will cause flickering during rendering. +Shaders, models etc MUST NOT animate by themselves. +No animations are allowed unless they are driven by `useCurrentFrame()`. +Otherwise, it will cause flickering during rendering. Using `useFrame()` from `@react-three/fiber` is forbidden. diff --git a/skills/remotion-video-creation/rules/animations.md b/skills/remotion-video-creation/rules/animations.md index 7e15623f..dfd0eb43 100644 --- a/skills/remotion-video-creation/rules/animations.md +++ b/skills/remotion-video-creation/rules/animations.md @@ -5,7 +5,7 @@ metadata: tags: animations, transitions, frames, useCurrentFrame --- -All animations MUST be driven by the `useCurrentFrame()` hook. +All animations MUST be driven by the `useCurrentFrame()` hook. Write animations in seconds and multiply them by the `fps` value from `useVideoConfig()`. ```tsx @@ -18,12 +18,12 @@ export const FadeIn = () => { const opacity = interpolate(frame, [0, 2 * fps], [0, 1], { extrapolateRight: 'clamp', }); - + return (
Hello World!
); }; ``` -CSS transitions or animations are FORBIDDEN - they will not render correctly. -Tailwind animation class names are FORBIDDEN - they will not render correctly. \ No newline at end of file +CSS transitions or animations are FORBIDDEN - they will not render correctly. +Tailwind animation class names are FORBIDDEN - they will not render correctly. \ No newline at end of file diff --git a/skills/remotion-video-creation/rules/charts.md b/skills/remotion-video-creation/rules/charts.md index a402ed53..63dab217 100644 --- a/skills/remotion-video-creation/rules/charts.md +++ b/skills/remotion-video-creation/rules/charts.md @@ -11,8 +11,8 @@ You can create bar charts in Remotion by using regular React code - HTML and SVG ## No animations not powered by `useCurrentFrame()` -Disable all animations by third party libraries. -They will cause flickering during rendering. +Disable all animations by third party libraries. +They will cause flickering during rendering. Instead, drive all animations from `useCurrentFrame()`. ## Bar Chart Animations diff --git a/skills/remotion-video-creation/rules/compositions.md b/skills/remotion-video-creation/rules/compositions.md index 27b61bb1..cd447130 100644 --- a/skills/remotion-video-creation/rules/compositions.md +++ b/skills/remotion-video-creation/rules/compositions.md @@ -29,7 +29,7 @@ export const RemotionRoot = () => { ## Default Props -Pass `defaultProps` to provide initial values for your component. +Pass `defaultProps` to provide initial values for your component. Values must be JSON-serializable (`Date`, `Map`, `Set`, and `staticFile()` are supported). ```tsx @@ -58,7 +58,7 @@ Use `type` declarations for props rather than `interface` to ensure `defaultProp ## Folders -Use `` to organize compositions in the sidebar. +Use `` to organize compositions in the sidebar. Folder names can only contain letters, numbers, and hyphens. ```tsx diff --git a/skills/remotion-video-creation/rules/lottie.md b/skills/remotion-video-creation/rules/lottie.md index 109da909..5047f3ee 100644 --- a/skills/remotion-video-creation/rules/lottie.md +++ b/skills/remotion-video-creation/rules/lottie.md @@ -9,7 +9,7 @@ metadata: ## Prerequisites -First, the @remotion/lottie package needs to be installed. +First, the @remotion/lottie package needs to be installed. If it is not, use the following command: ```bash diff --git a/skills/remotion-video-creation/rules/sequencing.md b/skills/remotion-video-creation/rules/sequencing.md index 42671376..a75ed4b4 100644 --- a/skills/remotion-video-creation/rules/sequencing.md +++ b/skills/remotion-video-creation/rules/sequencing.md @@ -20,7 +20,7 @@ const {fps} = useVideoConfig(); ``` -This will by default wrap the component in an absolute fill element. +This will by default wrap the component in an absolute fill element. If the items should not be wrapped, use the `layout` prop: ```tsx @@ -31,7 +31,7 @@ If the items should not be wrapped, use the `layout` prop: ## Premounting -This loads the component in the timeline before it is actually played. +This loads the component in the timeline before it is actually played. Always premount any ``! ```tsx diff --git a/skills/remotion-video-creation/rules/tailwind.md b/skills/remotion-video-creation/rules/tailwind.md index 16c8ce36..1d141064 100644 --- a/skills/remotion-video-creation/rules/tailwind.md +++ b/skills/remotion-video-creation/rules/tailwind.md @@ -6,6 +6,6 @@ metadata: You can and should use TailwindCSS in Remotion, if TailwindCSS is installed in the project. -Don't use `transition-*` or `animate-*` classes - always animate using the `useCurrentFrame()` hook. +Don't use `transition-*` or `animate-*` classes - always animate using the `useCurrentFrame()` hook. Tailwind must be installed and enabled first in a Remotion project - fetch using WebFetch for instructions. \ No newline at end of file diff --git a/skills/remotion-video-creation/rules/timing.md b/skills/remotion-video-creation/rules/timing.md index 464d4e29..edda18f5 100644 --- a/skills/remotion-video-creation/rules/timing.md +++ b/skills/remotion-video-creation/rules/timing.md @@ -13,7 +13,7 @@ import {interpolate} from 'remotion'; const opacity = interpolate(frame, [0, 100], [0, 1]); ``` -By default, the values are not clamped, so the value can go outside the range [0, 1]. +By default, the values are not clamped, so the value can go outside the range [0, 1]. Here is how they can be clamped: ```ts title="Going from 0 to 1 over 100 frames with extrapolation" @@ -25,7 +25,7 @@ const opacity = interpolate(frame, [0, 100], [0, 1], { ## Spring animations -Spring animations have a more natural motion. +Spring animations have a more natural motion. They go from 0 to 1 over time. ```ts title="Spring animation from 0 to 1 over 100 frames" @@ -42,7 +42,7 @@ const scale = spring({ ### Physical properties -The default configuration is: `mass: 1, damping: 10, stiffness: 100`. +The default configuration is: `mass: 1, damping: 10, stiffness: 100`. This leads to the animation having a bit of bounce before it settles. The config can be overwritten like this: @@ -68,7 +68,7 @@ const heavy = {damping: 15, stiffness: 80, mass: 2}; // Heavy, slow, small bounc ### Delay -The animation starts immediately by default. +The animation starts immediately by default. Use the `delay` parameter to delay the animation by a number of frames. ```tsx @@ -81,7 +81,7 @@ const entrance = spring({ ### Duration -A `spring()` has a natural duration based on the physical properties. +A `spring()` has a natural duration based on the physical properties. To stretch the animation to a specific duration, use the `durationInFrames` parameter. ```tsx @@ -144,7 +144,7 @@ const value1 = interpolate(frame, [0, 100], [0, 1], { }); ``` -The default easing is `Easing.linear`. +The default easing is `Easing.linear`. There are various other convexities: - `Easing.in` for starting slow and accelerating diff --git a/skills/remotion-video-creation/rules/transitions.md b/skills/remotion-video-creation/rules/transitions.md index c363cd19..1723f566 100644 --- a/skills/remotion-video-creation/rules/transitions.md +++ b/skills/remotion-video-creation/rules/transitions.md @@ -7,12 +7,12 @@ metadata: ## Fullscreen transitions -Using `` to animate between multiple scenes or clips. +Using `` to animate between multiple scenes or clips. This will absolutely position the children. ## Prerequisites -First, the @remotion/transitions package needs to be installed. +First, the @remotion/transitions package needs to be installed. If it is not, use the following command: ```bash diff --git a/skills/remotion-video-creation/rules/videos.md b/skills/remotion-video-creation/rules/videos.md index 4d99b31e..9ad7dff4 100644 --- a/skills/remotion-video-creation/rules/videos.md +++ b/skills/remotion-video-creation/rules/videos.md @@ -9,7 +9,7 @@ metadata: ## Prerequisites -First, the @remotion/media package needs to be installed. +First, the @remotion/media package needs to be installed. If it is not, use the following command: ```bash