mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-01 22:53:27 +08:00
docs: tighten voice-driven content skills
This commit is contained in:
Affaan Mustafa
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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 `<ThreeCanvas>` and include proper lighting.
|
||||
You MUST wrap 3D content in `<ThreeCanvas>` and include proper lighting.
|
||||
`<ThreeCanvas>` 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.
|
||||
|
||||
|
||||
@@ -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 (
|
||||
<div style={{ opacity }}>Hello World!</div>
|
||||
);
|
||||
};
|
||||
```
|
||||
|
||||
CSS transitions or animations are FORBIDDEN - they will not render correctly.
|
||||
Tailwind animation class names are FORBIDDEN - they will not render correctly.
|
||||
CSS transitions or animations are FORBIDDEN - they will not render correctly.
|
||||
Tailwind animation class names are FORBIDDEN - they will not render correctly.
|
||||
@@ -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
|
||||
|
||||
@@ -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 `<Folder>` to organize compositions in the sidebar.
|
||||
Use `<Folder>` to organize compositions in the sidebar.
|
||||
Folder names can only contain letters, numbers, and hyphens.
|
||||
|
||||
```tsx
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -20,7 +20,7 @@ const {fps} = useVideoConfig();
|
||||
</Sequence>
|
||||
```
|
||||
|
||||
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 `<Sequence>`!
|
||||
|
||||
```tsx
|
||||
|
||||
@@ -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 <https://www.remotion.dev/docs/tailwind> using WebFetch for instructions.
|
||||
@@ -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
|
||||
|
||||
@@ -7,12 +7,12 @@ metadata:
|
||||
|
||||
## Fullscreen transitions
|
||||
|
||||
Using `<TransitionSeries>` to animate between multiple scenes or clips.
|
||||
Using `<TransitionSeries>` 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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user