mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-03-30 21:53:28 +08:00
Compare commits
5 Commits
7713ceeec0
...
v1.7.0
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
b3d3eac532 | ||
|
|
706ee80069 | ||
|
|
87fc2d5089 | ||
|
|
2d9cc5c336 | ||
|
|
b21596de20 |
85
.agents/skills/article-writing/SKILL.md
Normal file
85
.agents/skills/article-writing/SKILL.md
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: article-writing
|
||||
description: Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Article Writing
|
||||
|
||||
Write long-form content that sounds like a real person or brand, not generic AI output.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- drafting blog posts, essays, launch posts, guides, tutorials, or newsletter issues
|
||||
- turning notes, transcripts, or research into polished articles
|
||||
- matching an existing founder, operator, or brand voice from examples
|
||||
- tightening structure, pacing, and evidence in already-written long-form copy
|
||||
|
||||
## Core Rules
|
||||
|
||||
1. Lead with the concrete thing: example, output, anecdote, number, screenshot description, or code block.
|
||||
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.
|
||||
|
||||
## Voice Capture Workflow
|
||||
|
||||
If the user wants a specific voice, collect one or more of:
|
||||
- published articles
|
||||
- newsletters
|
||||
- X / LinkedIn posts
|
||||
- docs or memos
|
||||
- a short 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
|
||||
|
||||
If no voice references are given, default to a direct, operator-style voice: concrete, practical, and low on hype.
|
||||
|
||||
## 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
|
||||
|
||||
## 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.
|
||||
|
||||
## 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
|
||||
- keep one argument thread per section
|
||||
- use examples that earn the opinion
|
||||
|
||||
### Newsletters
|
||||
- keep the first screen strong
|
||||
- mix insight with updates, not diary filler
|
||||
- use clear section labels and easy skim structure
|
||||
|
||||
## 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
|
||||
7
.agents/skills/article-writing/agents/openai.yaml
Normal file
7
.agents/skills/article-writing/agents/openai.yaml
Normal file
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Article Writing"
|
||||
short_description: "Write long-form content in a supplied voice without sounding templated"
|
||||
brand_color: "#B45309"
|
||||
default_prompt: "Draft a sharp long-form article from these notes and examples"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
88
.agents/skills/content-engine/SKILL.md
Normal file
88
.agents/skills/content-engine/SKILL.md
Normal file
@@ -0,0 +1,88 @@
|
||||
---
|
||||
name: content-engine
|
||||
description: Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Content Engine
|
||||
|
||||
Turn one idea into strong, platform-native content instead of posting the same thing everywhere.
|
||||
|
||||
## 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
|
||||
|
||||
## First Questions
|
||||
|
||||
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
|
||||
|
||||
## Core Rules
|
||||
|
||||
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.
|
||||
|
||||
## Platform Guidance
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### YouTube
|
||||
- show the result early
|
||||
- structure by chapter
|
||||
- refresh the visual every 20-30 seconds
|
||||
|
||||
### Newsletter
|
||||
- deliver one clear lens, not a bundle of unrelated items
|
||||
- make section titles skimmable
|
||||
- keep the opening paragraph doing real work
|
||||
|
||||
## 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
|
||||
|
||||
## Deliverables
|
||||
|
||||
When asked for a campaign, return:
|
||||
- the core angle
|
||||
- platform-specific drafts
|
||||
- optional posting order
|
||||
- optional CTA variants
|
||||
- any missing inputs needed before publishing
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- each draft reads natively for its platform
|
||||
- hooks are strong and specific
|
||||
- no generic hype language
|
||||
- no duplicated copy across platforms unless requested
|
||||
- the CTA matches the content and audience
|
||||
7
.agents/skills/content-engine/agents/openai.yaml
Normal file
7
.agents/skills/content-engine/agents/openai.yaml
Normal file
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Content Engine"
|
||||
short_description: "Turn one idea into platform-native social and content outputs"
|
||||
brand_color: "#DC2626"
|
||||
default_prompt: "Turn this source asset into strong multi-platform content"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
184
.agents/skills/frontend-slides/SKILL.md
Normal file
184
.agents/skills/frontend-slides/SKILL.md
Normal file
@@ -0,0 +1,184 @@
|
||||
---
|
||||
name: frontend-slides
|
||||
description: Create stunning, animation-rich HTML presentations from scratch or by converting PowerPoint files. Use when the user wants to build a presentation, convert a PPT/PPTX to web, or create slides for a talk/pitch. Helps non-designers discover their aesthetic through visual exploration rather than abstract choices.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Frontend Slides
|
||||
|
||||
Create zero-dependency, animation-rich HTML presentations that run entirely in the browser.
|
||||
|
||||
Inspired by the visual exploration approach showcased in work by [zarazhangrui](https://github.com/zarazhangrui).
|
||||
|
||||
## When to Activate
|
||||
|
||||
- Creating a talk deck, pitch deck, workshop deck, or internal presentation
|
||||
- Converting `.ppt` or `.pptx` slides into an HTML presentation
|
||||
- Improving an existing HTML presentation's layout, motion, or typography
|
||||
- Exploring presentation styles with a user who does not know their design preference yet
|
||||
|
||||
## Non-Negotiables
|
||||
|
||||
1. **Zero dependencies**: default to one self-contained HTML file with inline CSS and JS.
|
||||
2. **Viewport fit is mandatory**: every slide must fit inside one viewport with no internal scrolling.
|
||||
3. **Show, don't tell**: use visual previews instead of abstract style questionnaires.
|
||||
4. **Distinctive design**: avoid generic purple-gradient, Inter-on-white, template-looking decks.
|
||||
5. **Production quality**: keep code commented, accessible, responsive, and performant.
|
||||
|
||||
Before generating, read `STYLE_PRESETS.md` for the viewport-safe CSS base, density limits, preset catalog, and CSS gotchas.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Detect Mode
|
||||
|
||||
Choose one path:
|
||||
- **New presentation**: user has a topic, notes, or full draft
|
||||
- **PPT conversion**: user has `.ppt` or `.pptx`
|
||||
- **Enhancement**: user already has HTML slides and wants improvements
|
||||
|
||||
### 2. Discover Content
|
||||
|
||||
Ask only the minimum needed:
|
||||
- purpose: pitch, teaching, conference talk, internal update
|
||||
- length: short (5-10), medium (10-20), long (20+)
|
||||
- content state: finished copy, rough notes, topic only
|
||||
|
||||
If the user has content, ask them to paste it before styling.
|
||||
|
||||
### 3. Discover Style
|
||||
|
||||
Default to visual exploration.
|
||||
|
||||
If the user already knows the desired preset, skip previews and use it directly.
|
||||
|
||||
Otherwise:
|
||||
1. Ask what feeling the deck should create: impressed, energized, focused, inspired.
|
||||
2. Generate **3 single-slide preview files** in `.ecc-design/slide-previews/`.
|
||||
3. Each preview must be self-contained, show typography/color/motion clearly, and stay under roughly 100 lines of slide content.
|
||||
4. Ask the user which preview to keep or what elements to mix.
|
||||
|
||||
Use the preset guide in `STYLE_PRESETS.md` when mapping mood to style.
|
||||
|
||||
### 4. Build the Presentation
|
||||
|
||||
Output either:
|
||||
- `presentation.html`
|
||||
- `[presentation-name].html`
|
||||
|
||||
Use an `assets/` folder only when the deck contains extracted or user-supplied images.
|
||||
|
||||
Required structure:
|
||||
- semantic slide sections
|
||||
- a viewport-safe CSS base from `STYLE_PRESETS.md`
|
||||
- CSS custom properties for theme values
|
||||
- a presentation controller class for keyboard, wheel, and touch navigation
|
||||
- Intersection Observer for reveal animations
|
||||
- reduced-motion support
|
||||
|
||||
### 5. Enforce Viewport Fit
|
||||
|
||||
Treat this as a hard gate.
|
||||
|
||||
Rules:
|
||||
- every `.slide` must use `height: 100vh; height: 100dvh; overflow: hidden;`
|
||||
- all type and spacing must scale with `clamp()`
|
||||
- when content does not fit, split into multiple slides
|
||||
- never solve overflow by shrinking text below readable sizes
|
||||
- never allow scrollbars inside a slide
|
||||
|
||||
Use the density limits and mandatory CSS block in `STYLE_PRESETS.md`.
|
||||
|
||||
### 6. Validate
|
||||
|
||||
Check the finished deck at these sizes:
|
||||
- 1920x1080
|
||||
- 1280x720
|
||||
- 768x1024
|
||||
- 375x667
|
||||
- 667x375
|
||||
|
||||
If browser automation is available, use it to verify no slide overflows and that keyboard navigation works.
|
||||
|
||||
### 7. Deliver
|
||||
|
||||
At handoff:
|
||||
- delete temporary preview files unless the user wants to keep them
|
||||
- open the deck with the platform-appropriate opener when useful
|
||||
- summarize file path, preset used, slide count, and easy theme customization points
|
||||
|
||||
Use the correct opener for the current OS:
|
||||
- macOS: `open file.html`
|
||||
- Linux: `xdg-open file.html`
|
||||
- Windows: `start "" file.html`
|
||||
|
||||
## PPT / PPTX Conversion
|
||||
|
||||
For PowerPoint conversion:
|
||||
1. Prefer `python3` with `python-pptx` to extract text, images, and notes.
|
||||
2. If `python-pptx` is unavailable, ask whether to install it or fall back to a manual/export-based workflow.
|
||||
3. Preserve slide order, speaker notes, and extracted assets.
|
||||
4. After extraction, run the same style-selection workflow as a new presentation.
|
||||
|
||||
Keep conversion cross-platform. Do not rely on macOS-only tools when Python can do the job.
|
||||
|
||||
## Implementation Requirements
|
||||
|
||||
### HTML / CSS
|
||||
|
||||
- Use inline CSS and JS unless the user explicitly wants a multi-file project.
|
||||
- Fonts may come from Google Fonts or Fontshare.
|
||||
- Prefer atmospheric backgrounds, strong type hierarchy, and a clear visual direction.
|
||||
- Use abstract shapes, gradients, grids, noise, and geometry rather than illustrations.
|
||||
|
||||
### JavaScript
|
||||
|
||||
Include:
|
||||
- keyboard navigation
|
||||
- touch / swipe navigation
|
||||
- mouse wheel navigation
|
||||
- progress indicator or slide index
|
||||
- reveal-on-enter animation triggers
|
||||
|
||||
### Accessibility
|
||||
|
||||
- use semantic structure (`main`, `section`, `nav`)
|
||||
- keep contrast readable
|
||||
- support keyboard-only navigation
|
||||
- respect `prefers-reduced-motion`
|
||||
|
||||
## Content Density Limits
|
||||
|
||||
Use these maxima unless the user explicitly asks for denser slides and readability still holds:
|
||||
|
||||
| Slide type | Limit |
|
||||
|------------|-------|
|
||||
| Title | 1 heading + 1 subtitle + optional tagline |
|
||||
| Content | 1 heading + 4-6 bullets or 2 short paragraphs |
|
||||
| Feature grid | 6 cards max |
|
||||
| Code | 8-10 lines max |
|
||||
| Quote | 1 quote + attribution |
|
||||
| Image | 1 image constrained by viewport |
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- generic startup gradients with no visual identity
|
||||
- system-font decks unless intentionally editorial
|
||||
- long bullet walls
|
||||
- code blocks that need scrolling
|
||||
- fixed-height content boxes that break on short screens
|
||||
- invalid negated CSS functions like `-clamp(...)`
|
||||
|
||||
## Related ECC Skills
|
||||
|
||||
- `frontend-patterns` for component and interaction patterns around the deck
|
||||
- `liquid-glass-design` when a presentation intentionally borrows Apple glass aesthetics
|
||||
- `e2e-testing` if you need automated browser verification for the final deck
|
||||
|
||||
## Deliverable Checklist
|
||||
|
||||
- presentation runs from a local file in a browser
|
||||
- every slide fits the viewport without scrolling
|
||||
- style is distinctive and intentional
|
||||
- animation is meaningful, not noisy
|
||||
- reduced motion is respected
|
||||
- file paths and customization points are explained at handoff
|
||||
330
.agents/skills/frontend-slides/STYLE_PRESETS.md
Normal file
330
.agents/skills/frontend-slides/STYLE_PRESETS.md
Normal file
@@ -0,0 +1,330 @@
|
||||
# Style Presets Reference
|
||||
|
||||
Curated visual styles for `frontend-slides`.
|
||||
|
||||
Use this file for:
|
||||
- the mandatory viewport-fitting CSS base
|
||||
- preset selection and mood mapping
|
||||
- CSS gotchas and validation rules
|
||||
|
||||
Abstract shapes only. Avoid illustrations unless the user explicitly asks for them.
|
||||
|
||||
## Viewport Fit Is Non-Negotiable
|
||||
|
||||
Every slide must fully fit in one viewport.
|
||||
|
||||
### Golden Rule
|
||||
|
||||
```text
|
||||
Each slide = exactly one viewport height.
|
||||
Too much content = split into more slides.
|
||||
Never scroll inside a slide.
|
||||
```
|
||||
|
||||
### Density Limits
|
||||
|
||||
| Slide Type | Maximum Content |
|
||||
|------------|-----------------|
|
||||
| Title slide | 1 heading + 1 subtitle + optional tagline |
|
||||
| Content slide | 1 heading + 4-6 bullets or 2 paragraphs |
|
||||
| Feature grid | 6 cards maximum |
|
||||
| Code slide | 8-10 lines maximum |
|
||||
| Quote slide | 1 quote + attribution |
|
||||
| Image slide | 1 image, ideally under 60vh |
|
||||
|
||||
## Mandatory Base CSS
|
||||
|
||||
Copy this block into every generated presentation and then theme on top of it.
|
||||
|
||||
```css
|
||||
/* ===========================================
|
||||
VIEWPORT FITTING: MANDATORY BASE STYLES
|
||||
=========================================== */
|
||||
|
||||
html, body {
|
||||
height: 100%;
|
||||
overflow-x: hidden;
|
||||
}
|
||||
|
||||
html {
|
||||
scroll-snap-type: y mandatory;
|
||||
scroll-behavior: smooth;
|
||||
}
|
||||
|
||||
.slide {
|
||||
width: 100vw;
|
||||
height: 100vh;
|
||||
height: 100dvh;
|
||||
overflow: hidden;
|
||||
scroll-snap-align: start;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
position: relative;
|
||||
}
|
||||
|
||||
.slide-content {
|
||||
flex: 1;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
justify-content: center;
|
||||
max-height: 100%;
|
||||
overflow: hidden;
|
||||
padding: var(--slide-padding);
|
||||
}
|
||||
|
||||
:root {
|
||||
--title-size: clamp(1.5rem, 5vw, 4rem);
|
||||
--h2-size: clamp(1.25rem, 3.5vw, 2.5rem);
|
||||
--h3-size: clamp(1rem, 2.5vw, 1.75rem);
|
||||
--body-size: clamp(0.75rem, 1.5vw, 1.125rem);
|
||||
--small-size: clamp(0.65rem, 1vw, 0.875rem);
|
||||
|
||||
--slide-padding: clamp(1rem, 4vw, 4rem);
|
||||
--content-gap: clamp(0.5rem, 2vw, 2rem);
|
||||
--element-gap: clamp(0.25rem, 1vw, 1rem);
|
||||
}
|
||||
|
||||
.card, .container, .content-box {
|
||||
max-width: min(90vw, 1000px);
|
||||
max-height: min(80vh, 700px);
|
||||
}
|
||||
|
||||
.feature-list, .bullet-list {
|
||||
gap: clamp(0.4rem, 1vh, 1rem);
|
||||
}
|
||||
|
||||
.feature-list li, .bullet-list li {
|
||||
font-size: var(--body-size);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(min(100%, 250px), 1fr));
|
||||
gap: clamp(0.5rem, 1.5vw, 1rem);
|
||||
}
|
||||
|
||||
img, .image-container {
|
||||
max-width: 100%;
|
||||
max-height: min(50vh, 400px);
|
||||
object-fit: contain;
|
||||
}
|
||||
|
||||
@media (max-height: 700px) {
|
||||
:root {
|
||||
--slide-padding: clamp(0.75rem, 3vw, 2rem);
|
||||
--content-gap: clamp(0.4rem, 1.5vw, 1rem);
|
||||
--title-size: clamp(1.25rem, 4.5vw, 2.5rem);
|
||||
--h2-size: clamp(1rem, 3vw, 1.75rem);
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-height: 600px) {
|
||||
:root {
|
||||
--slide-padding: clamp(0.5rem, 2.5vw, 1.5rem);
|
||||
--content-gap: clamp(0.3rem, 1vw, 0.75rem);
|
||||
--title-size: clamp(1.1rem, 4vw, 2rem);
|
||||
--body-size: clamp(0.7rem, 1.2vw, 0.95rem);
|
||||
}
|
||||
|
||||
.nav-dots, .keyboard-hint, .decorative {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-height: 500px) {
|
||||
:root {
|
||||
--slide-padding: clamp(0.4rem, 2vw, 1rem);
|
||||
--title-size: clamp(1rem, 3.5vw, 1.5rem);
|
||||
--h2-size: clamp(0.9rem, 2.5vw, 1.25rem);
|
||||
--body-size: clamp(0.65rem, 1vw, 0.85rem);
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-width: 600px) {
|
||||
:root {
|
||||
--title-size: clamp(1.25rem, 7vw, 2.5rem);
|
||||
}
|
||||
|
||||
.grid {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
}
|
||||
|
||||
@media (prefers-reduced-motion: reduce) {
|
||||
*, *::before, *::after {
|
||||
animation-duration: 0.01ms !important;
|
||||
transition-duration: 0.2s !important;
|
||||
}
|
||||
|
||||
html {
|
||||
scroll-behavior: auto;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Viewport Checklist
|
||||
|
||||
- every `.slide` has `height: 100vh`, `height: 100dvh`, and `overflow: hidden`
|
||||
- all typography uses `clamp()`
|
||||
- all spacing uses `clamp()` or viewport units
|
||||
- images have `max-height` constraints
|
||||
- grids adapt with `auto-fit` + `minmax()`
|
||||
- short-height breakpoints exist at `700px`, `600px`, and `500px`
|
||||
- if anything feels cramped, split the slide
|
||||
|
||||
## Mood to Preset Mapping
|
||||
|
||||
| Mood | Good Presets |
|
||||
|------|--------------|
|
||||
| Impressed / Confident | Bold Signal, Electric Studio, Dark Botanical |
|
||||
| Excited / Energized | Creative Voltage, Neon Cyber, Split Pastel |
|
||||
| Calm / Focused | Notebook Tabs, Paper & Ink, Swiss Modern |
|
||||
| Inspired / Moved | Dark Botanical, Vintage Editorial, Pastel Geometry |
|
||||
|
||||
## Preset Catalog
|
||||
|
||||
### 1. Bold Signal
|
||||
|
||||
- Vibe: confident, high-impact, keynote-ready
|
||||
- Best for: pitch decks, launches, statements
|
||||
- Fonts: Archivo Black + Space Grotesk
|
||||
- Palette: charcoal base, hot orange focal card, crisp white text
|
||||
- Signature: oversized section numbers, high-contrast card on dark field
|
||||
|
||||
### 2. Electric Studio
|
||||
|
||||
- Vibe: clean, bold, agency-polished
|
||||
- Best for: client presentations, strategic reviews
|
||||
- Fonts: Manrope only
|
||||
- Palette: black, white, saturated cobalt accent
|
||||
- Signature: two-panel split and sharp editorial alignment
|
||||
|
||||
### 3. Creative Voltage
|
||||
|
||||
- Vibe: energetic, retro-modern, playful confidence
|
||||
- Best for: creative studios, brand work, product storytelling
|
||||
- Fonts: Syne + Space Mono
|
||||
- Palette: electric blue, neon yellow, deep navy
|
||||
- Signature: halftone textures, badges, punchy contrast
|
||||
|
||||
### 4. Dark Botanical
|
||||
|
||||
- Vibe: elegant, premium, atmospheric
|
||||
- Best for: luxury brands, thoughtful narratives, premium product decks
|
||||
- Fonts: Cormorant + IBM Plex Sans
|
||||
- Palette: near-black, warm ivory, blush, gold, terracotta
|
||||
- Signature: blurred abstract circles, fine rules, restrained motion
|
||||
|
||||
### 5. Notebook Tabs
|
||||
|
||||
- Vibe: editorial, organized, tactile
|
||||
- Best for: reports, reviews, structured storytelling
|
||||
- Fonts: Bodoni Moda + DM Sans
|
||||
- Palette: cream paper on charcoal with pastel tabs
|
||||
- Signature: paper sheet, colored side tabs, binder details
|
||||
|
||||
### 6. Pastel Geometry
|
||||
|
||||
- Vibe: approachable, modern, friendly
|
||||
- Best for: product overviews, onboarding, lighter brand decks
|
||||
- Fonts: Plus Jakarta Sans only
|
||||
- Palette: pale blue field, cream card, soft pink/mint/lavender accents
|
||||
- Signature: vertical pills, rounded cards, soft shadows
|
||||
|
||||
### 7. Split Pastel
|
||||
|
||||
- Vibe: playful, modern, creative
|
||||
- Best for: agency intros, workshops, portfolios
|
||||
- Fonts: Outfit only
|
||||
- Palette: peach + lavender split with mint badges
|
||||
- Signature: split backdrop, rounded tags, light grid overlays
|
||||
|
||||
### 8. Vintage Editorial
|
||||
|
||||
- Vibe: witty, personality-driven, magazine-inspired
|
||||
- Best for: personal brands, opinionated talks, storytelling
|
||||
- Fonts: Fraunces + Work Sans
|
||||
- Palette: cream, charcoal, dusty warm accents
|
||||
- Signature: geometric accents, bordered callouts, punchy serif headlines
|
||||
|
||||
### 9. Neon Cyber
|
||||
|
||||
- Vibe: futuristic, techy, kinetic
|
||||
- Best for: AI, infra, dev tools, future-of-X talks
|
||||
- Fonts: Clash Display + Satoshi
|
||||
- Palette: midnight navy, cyan, magenta
|
||||
- Signature: glow, particles, grids, data-radar energy
|
||||
|
||||
### 10. Terminal Green
|
||||
|
||||
- Vibe: developer-focused, hacker-clean
|
||||
- Best for: APIs, CLI tools, engineering demos
|
||||
- Fonts: JetBrains Mono only
|
||||
- Palette: GitHub dark + terminal green
|
||||
- Signature: scan lines, command-line framing, precise monospace rhythm
|
||||
|
||||
### 11. Swiss Modern
|
||||
|
||||
- Vibe: minimal, precise, data-forward
|
||||
- Best for: corporate, product strategy, analytics
|
||||
- Fonts: Archivo + Nunito
|
||||
- Palette: white, black, signal red
|
||||
- Signature: visible grids, asymmetry, geometric discipline
|
||||
|
||||
### 12. Paper & Ink
|
||||
|
||||
- Vibe: literary, thoughtful, story-driven
|
||||
- Best for: essays, keynote narratives, manifesto decks
|
||||
- Fonts: Cormorant Garamond + Source Serif 4
|
||||
- Palette: warm cream, charcoal, crimson accent
|
||||
- Signature: pull quotes, drop caps, elegant rules
|
||||
|
||||
## Direct Selection Prompts
|
||||
|
||||
If the user already knows the style they want, let them pick directly from the preset names above instead of forcing preview generation.
|
||||
|
||||
## Animation Feel Mapping
|
||||
|
||||
| Feeling | Motion Direction |
|
||||
|---------|------------------|
|
||||
| Dramatic / Cinematic | slow fades, parallax, large scale-ins |
|
||||
| Techy / Futuristic | glow, particles, grid motion, scramble text |
|
||||
| Playful / Friendly | springy easing, rounded shapes, floating motion |
|
||||
| Professional / Corporate | subtle 200-300ms transitions, clean slides |
|
||||
| Calm / Minimal | very restrained movement, whitespace-first |
|
||||
| Editorial / Magazine | strong hierarchy, staggered text and image interplay |
|
||||
|
||||
## CSS Gotcha: Negating Functions
|
||||
|
||||
Never write these:
|
||||
|
||||
```css
|
||||
right: -clamp(28px, 3.5vw, 44px);
|
||||
margin-left: -min(10vw, 100px);
|
||||
```
|
||||
|
||||
Browsers ignore them silently.
|
||||
|
||||
Always write this instead:
|
||||
|
||||
```css
|
||||
right: calc(-1 * clamp(28px, 3.5vw, 44px));
|
||||
margin-left: calc(-1 * min(10vw, 100px));
|
||||
```
|
||||
|
||||
## Validation Sizes
|
||||
|
||||
Test at minimum:
|
||||
- Desktop: `1920x1080`, `1440x900`, `1280x720`
|
||||
- Tablet: `1024x768`, `768x1024`
|
||||
- Mobile: `375x667`, `414x896`
|
||||
- Landscape phone: `667x375`, `896x414`
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
Do not use:
|
||||
- purple-on-white startup templates
|
||||
- Inter / Roboto / Arial as the visual voice unless the user explicitly wants utilitarian neutrality
|
||||
- bullet walls, tiny type, or code blocks that require scrolling
|
||||
- decorative illustrations when abstract geometry would do the job better
|
||||
7
.agents/skills/frontend-slides/agents/openai.yaml
Normal file
7
.agents/skills/frontend-slides/agents/openai.yaml
Normal file
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Frontend Slides"
|
||||
short_description: "Create distinctive HTML slide decks and convert PPTX to web"
|
||||
brand_color: "#FF6B3D"
|
||||
default_prompt: "Create a viewport-safe HTML presentation with strong visual direction"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
96
.agents/skills/investor-materials/SKILL.md
Normal file
96
.agents/skills/investor-materials/SKILL.md
Normal file
@@ -0,0 +1,96 @@
|
||||
---
|
||||
name: investor-materials
|
||||
description: Create and update pitch decks, one-pagers, investor memos, accelerator applications, financial models, and fundraising materials. Use when the user needs investor-facing documents, projections, use-of-funds tables, milestone plans, or materials that must stay internally consistent across multiple fundraising assets.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Investor Materials
|
||||
|
||||
Build investor-facing materials that are consistent, credible, and easy to defend.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- creating or revising a pitch deck
|
||||
- writing an investor memo or one-pager
|
||||
- building a financial model, milestone plan, or use-of-funds table
|
||||
- answering accelerator or incubator application questions
|
||||
- aligning multiple fundraising docs around one source of truth
|
||||
|
||||
## Golden Rule
|
||||
|
||||
All investor materials must agree with each other.
|
||||
|
||||
Create or confirm a single source of truth before writing:
|
||||
- traction metrics
|
||||
- pricing and revenue assumptions
|
||||
- raise size and instrument
|
||||
- use of funds
|
||||
- team bios and titles
|
||||
- milestones and timelines
|
||||
|
||||
If conflicting numbers appear, stop and resolve them before drafting.
|
||||
|
||||
## Core Workflow
|
||||
|
||||
1. inventory the canonical facts
|
||||
2. identify missing assumptions
|
||||
3. choose the asset type
|
||||
4. draft the asset with explicit logic
|
||||
5. cross-check every number against the source of truth
|
||||
|
||||
## Asset Guidance
|
||||
|
||||
### Pitch Deck
|
||||
Recommended flow:
|
||||
1. company + wedge
|
||||
2. problem
|
||||
3. solution
|
||||
4. product / demo
|
||||
5. market
|
||||
6. business model
|
||||
7. traction
|
||||
8. team
|
||||
9. competition / differentiation
|
||||
10. ask
|
||||
11. use of funds / milestones
|
||||
12. appendix
|
||||
|
||||
If the user wants a web-native deck, pair this skill with `frontend-slides`.
|
||||
|
||||
### One-Pager / Memo
|
||||
- state what the company does in one clean sentence
|
||||
- show why now
|
||||
- include traction and proof points early
|
||||
- make the ask precise
|
||||
- keep claims easy to verify
|
||||
|
||||
### Financial Model
|
||||
Include:
|
||||
- explicit assumptions
|
||||
- bear / base / bull cases when useful
|
||||
- clean layer-by-layer revenue logic
|
||||
- milestone-linked spending
|
||||
- sensitivity analysis where the decision hinges on assumptions
|
||||
|
||||
### Accelerator Applications
|
||||
- answer the exact question asked
|
||||
- prioritize traction, insight, and team advantage
|
||||
- avoid puffery
|
||||
- keep internal metrics consistent with the deck and model
|
||||
|
||||
## Red Flags to Avoid
|
||||
|
||||
- unverifiable claims
|
||||
- fuzzy market sizing without assumptions
|
||||
- inconsistent team roles or titles
|
||||
- revenue math that does not sum cleanly
|
||||
- inflated certainty where assumptions are fragile
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- every number matches the current source of truth
|
||||
- use of funds and revenue layers sum correctly
|
||||
- assumptions are visible, not buried
|
||||
- the story is clear without hype language
|
||||
- the final asset is defensible in a partner meeting
|
||||
7
.agents/skills/investor-materials/agents/openai.yaml
Normal file
7
.agents/skills/investor-materials/agents/openai.yaml
Normal file
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Investor Materials"
|
||||
short_description: "Create decks, memos, and financial materials from one source of truth"
|
||||
brand_color: "#7C3AED"
|
||||
default_prompt: "Draft investor materials that stay numerically consistent across assets"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
76
.agents/skills/investor-outreach/SKILL.md
Normal file
76
.agents/skills/investor-outreach/SKILL.md
Normal file
@@ -0,0 +1,76 @@
|
||||
---
|
||||
name: investor-outreach
|
||||
description: Draft cold emails, warm intro blurbs, follow-ups, update emails, and investor communications for fundraising. Use when the user wants outreach to angels, VCs, strategic investors, or accelerators and needs concise, personalized, investor-facing messaging.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Investor Outreach
|
||||
|
||||
Write investor communication that is short, personalized, and easy to act on.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- writing a cold email to an investor
|
||||
- drafting a warm intro request
|
||||
- sending follow-ups after a meeting or no response
|
||||
- writing investor updates during a process
|
||||
- tailoring outreach based on fund thesis or partner fit
|
||||
|
||||
## Core Rules
|
||||
|
||||
1. Personalize every outbound message.
|
||||
2. Keep the ask low-friction.
|
||||
3. Use proof, not adjectives.
|
||||
4. Stay concise.
|
||||
5. Never send generic copy that could go to any investor.
|
||||
|
||||
## 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
|
||||
4. ask: one concrete next step
|
||||
5. sign-off: name, role, one credibility anchor if needed
|
||||
|
||||
## Personalization Sources
|
||||
|
||||
Reference one or more of:
|
||||
- relevant portfolio companies
|
||||
- a public thesis, talk, post, or article
|
||||
- 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.
|
||||
|
||||
## 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
|
||||
|
||||
Do not keep nudging after that unless the user wants a longer sequence.
|
||||
|
||||
## Warm Intro Requests
|
||||
|
||||
Make life easy for the connector:
|
||||
- explain why the intro is a fit
|
||||
- include a forwardable blurb
|
||||
- keep the forwardable blurb under 100 words
|
||||
|
||||
## Post-Meeting Updates
|
||||
|
||||
Include:
|
||||
- the specific thing discussed
|
||||
- the answer or update promised
|
||||
- one new proof point if available
|
||||
- the next step
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- message is personalized
|
||||
- the ask is explicit
|
||||
- there is no fluff or begging language
|
||||
- the proof point is concrete
|
||||
- word count stays tight
|
||||
7
.agents/skills/investor-outreach/agents/openai.yaml
Normal file
7
.agents/skills/investor-outreach/agents/openai.yaml
Normal file
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Investor Outreach"
|
||||
short_description: "Write concise, personalized outreach and follow-ups for fundraising"
|
||||
brand_color: "#059669"
|
||||
default_prompt: "Draft a personalized investor outreach email with a clear low-friction ask"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
75
.agents/skills/market-research/SKILL.md
Normal file
75
.agents/skills/market-research/SKILL.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
name: market-research
|
||||
description: Conduct market research, competitive analysis, investor due diligence, and industry intelligence with source attribution and decision-oriented summaries. Use when the user wants market sizing, competitor comparisons, fund research, technology scans, or research that informs business decisions.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Market Research
|
||||
|
||||
Produce research that supports decisions, not research theater.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- researching a market, category, company, investor, or technology trend
|
||||
- building TAM/SAM/SOM estimates
|
||||
- comparing competitors or adjacent products
|
||||
- preparing investor dossiers before outreach
|
||||
- pressure-testing a thesis before building, funding, or entering a market
|
||||
|
||||
## Research Standards
|
||||
|
||||
1. Every important claim needs a source.
|
||||
2. Prefer recent data and call out stale data.
|
||||
3. Include contrarian evidence and downside cases.
|
||||
4. Translate findings into a decision, not just a summary.
|
||||
5. Separate fact, inference, and recommendation clearly.
|
||||
|
||||
## Common Research Modes
|
||||
|
||||
### Investor / Fund Diligence
|
||||
Collect:
|
||||
- fund size, stage, and typical check size
|
||||
- relevant portfolio companies
|
||||
- public thesis and recent activity
|
||||
- reasons the fund is or is not a fit
|
||||
- any obvious red flags or mismatches
|
||||
|
||||
### Competitive Analysis
|
||||
Collect:
|
||||
- product reality, not marketing copy
|
||||
- funding and investor history if public
|
||||
- traction metrics if public
|
||||
- distribution and pricing clues
|
||||
- strengths, weaknesses, and positioning gaps
|
||||
|
||||
### Market Sizing
|
||||
Use:
|
||||
- top-down estimates from reports or public datasets
|
||||
- bottom-up sanity checks from realistic customer acquisition assumptions
|
||||
- explicit assumptions for every leap in logic
|
||||
|
||||
### Technology / Vendor Research
|
||||
Collect:
|
||||
- how it works
|
||||
- trade-offs and adoption signals
|
||||
- integration complexity
|
||||
- lock-in, security, compliance, and operational risk
|
||||
|
||||
## Output Format
|
||||
|
||||
Default structure:
|
||||
1. executive summary
|
||||
2. key findings
|
||||
3. implications
|
||||
4. risks and caveats
|
||||
5. recommendation
|
||||
6. sources
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- all numbers are sourced or labeled as estimates
|
||||
- old data is flagged
|
||||
- the recommendation follows from the evidence
|
||||
- risks and counterarguments are included
|
||||
- the output makes a decision easier
|
||||
7
.agents/skills/market-research/agents/openai.yaml
Normal file
7
.agents/skills/market-research/agents/openai.yaml
Normal file
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Market Research"
|
||||
short_description: "Source-attributed market, competitor, and investor research"
|
||||
brand_color: "#2563EB"
|
||||
default_prompt: "Research this market and summarize the decision-relevant findings"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
@@ -1,8 +1,10 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
|
||||
"name": "everything-claude-code",
|
||||
"description": "Battle-tested Claude Code configurations from an Anthropic hackathon winner — agents, skills, hooks, commands, and rules evolved over 10+ months of intensive daily use",
|
||||
"owner": {
|
||||
"name": "Affaan Mustafa",
|
||||
"email": "affaan@example.com"
|
||||
"email": "me@affaanmustafa.com"
|
||||
},
|
||||
"metadata": {
|
||||
"description": "Battle-tested Claude Code configurations from an Anthropic hackathon winner"
|
||||
@@ -11,9 +13,11 @@
|
||||
{
|
||||
"name": "everything-claude-code",
|
||||
"source": "./",
|
||||
"description": "Complete collection of agents, skills, hooks, commands, and rules evolved over 10+ months of intensive daily use",
|
||||
"description": "The most comprehensive Claude Code plugin — 14+ agents, 56+ skills, 33+ commands, and production-ready hooks for TDD, security scanning, code review, and continuous learning",
|
||||
"version": "1.7.0",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa"
|
||||
"name": "Affaan Mustafa",
|
||||
"email": "me@affaanmustafa.com"
|
||||
},
|
||||
"homepage": "https://github.com/affaan-m/everything-claude-code",
|
||||
"repository": "https://github.com/affaan-m/everything-claude-code",
|
||||
@@ -38,7 +42,8 @@
|
||||
"code-review",
|
||||
"security",
|
||||
"best-practices"
|
||||
]
|
||||
],
|
||||
"strict": false
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "everything-claude-code",
|
||||
"version": "1.4.1",
|
||||
"version": "1.7.0",
|
||||
"description": "Complete collection of battle-tested Claude Code configs from an Anthropic hackathon winner - agents, skills, hooks, and rules evolved over 10+ months of intensive daily use",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
@@ -21,21 +21,5 @@
|
||||
"workflow",
|
||||
"automation",
|
||||
"best-practices"
|
||||
],
|
||||
"skills": ["./skills/", "./commands/"],
|
||||
"agents": [
|
||||
"./agents/architect.md",
|
||||
"./agents/build-error-resolver.md",
|
||||
"./agents/code-reviewer.md",
|
||||
"./agents/database-reviewer.md",
|
||||
"./agents/doc-updater.md",
|
||||
"./agents/e2e-runner.md",
|
||||
"./agents/go-build-resolver.md",
|
||||
"./agents/go-reviewer.md",
|
||||
"./agents/planner.md",
|
||||
"./agents/python-reviewer.md",
|
||||
"./agents/refactor-cleaner.md",
|
||||
"./agents/security-reviewer.md",
|
||||
"./agents/tdd-guide.md"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -22,6 +22,12 @@ Available skills:
|
||||
- security-review — Comprehensive security checklist
|
||||
- coding-standards — Universal coding standards
|
||||
- frontend-patterns — React/Next.js patterns
|
||||
- frontend-slides — Viewport-safe HTML presentations and PPTX-to-web conversion
|
||||
- article-writing — Long-form writing from notes and voice references
|
||||
- content-engine — Platform-native social content and repurposing
|
||||
- market-research — Source-attributed market and competitor research
|
||||
- investor-materials — Decks, memos, models, and one-pagers
|
||||
- investor-outreach — Personalized investor outreach and follow-ups
|
||||
- backend-patterns — API design, database, caching
|
||||
- e2e-testing — Playwright E2E tests
|
||||
- eval-harness — Eval-driven development
|
||||
|
||||
85
.cursor/skills/article-writing/SKILL.md
Normal file
85
.cursor/skills/article-writing/SKILL.md
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: article-writing
|
||||
description: Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Article Writing
|
||||
|
||||
Write long-form content that sounds like a real person or brand, not generic AI output.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- drafting blog posts, essays, launch posts, guides, tutorials, or newsletter issues
|
||||
- turning notes, transcripts, or research into polished articles
|
||||
- matching an existing founder, operator, or brand voice from examples
|
||||
- tightening structure, pacing, and evidence in already-written long-form copy
|
||||
|
||||
## Core Rules
|
||||
|
||||
1. Lead with the concrete thing: example, output, anecdote, number, screenshot description, or code block.
|
||||
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.
|
||||
|
||||
## Voice Capture Workflow
|
||||
|
||||
If the user wants a specific voice, collect one or more of:
|
||||
- published articles
|
||||
- newsletters
|
||||
- X / LinkedIn posts
|
||||
- docs or memos
|
||||
- a short 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
|
||||
|
||||
If no voice references are given, default to a direct, operator-style voice: concrete, practical, and low on hype.
|
||||
|
||||
## 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
|
||||
|
||||
## 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.
|
||||
|
||||
## 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
|
||||
- keep one argument thread per section
|
||||
- use examples that earn the opinion
|
||||
|
||||
### Newsletters
|
||||
- keep the first screen strong
|
||||
- mix insight with updates, not diary filler
|
||||
- use clear section labels and easy skim structure
|
||||
|
||||
## 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
|
||||
88
.cursor/skills/content-engine/SKILL.md
Normal file
88
.cursor/skills/content-engine/SKILL.md
Normal file
@@ -0,0 +1,88 @@
|
||||
---
|
||||
name: content-engine
|
||||
description: Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Content Engine
|
||||
|
||||
Turn one idea into strong, platform-native content instead of posting the same thing everywhere.
|
||||
|
||||
## 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
|
||||
|
||||
## First Questions
|
||||
|
||||
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
|
||||
|
||||
## Core Rules
|
||||
|
||||
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.
|
||||
|
||||
## Platform Guidance
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### YouTube
|
||||
- show the result early
|
||||
- structure by chapter
|
||||
- refresh the visual every 20-30 seconds
|
||||
|
||||
### Newsletter
|
||||
- deliver one clear lens, not a bundle of unrelated items
|
||||
- make section titles skimmable
|
||||
- keep the opening paragraph doing real work
|
||||
|
||||
## 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
|
||||
|
||||
## Deliverables
|
||||
|
||||
When asked for a campaign, return:
|
||||
- the core angle
|
||||
- platform-specific drafts
|
||||
- optional posting order
|
||||
- optional CTA variants
|
||||
- any missing inputs needed before publishing
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- each draft reads natively for its platform
|
||||
- hooks are strong and specific
|
||||
- no generic hype language
|
||||
- no duplicated copy across platforms unless requested
|
||||
- the CTA matches the content and audience
|
||||
184
.cursor/skills/frontend-slides/SKILL.md
Normal file
184
.cursor/skills/frontend-slides/SKILL.md
Normal file
@@ -0,0 +1,184 @@
|
||||
---
|
||||
name: frontend-slides
|
||||
description: Create stunning, animation-rich HTML presentations from scratch or by converting PowerPoint files. Use when the user wants to build a presentation, convert a PPT/PPTX to web, or create slides for a talk/pitch. Helps non-designers discover their aesthetic through visual exploration rather than abstract choices.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Frontend Slides
|
||||
|
||||
Create zero-dependency, animation-rich HTML presentations that run entirely in the browser.
|
||||
|
||||
Inspired by the visual exploration approach showcased in work by [zarazhangrui](https://github.com/zarazhangrui).
|
||||
|
||||
## When to Activate
|
||||
|
||||
- Creating a talk deck, pitch deck, workshop deck, or internal presentation
|
||||
- Converting `.ppt` or `.pptx` slides into an HTML presentation
|
||||
- Improving an existing HTML presentation's layout, motion, or typography
|
||||
- Exploring presentation styles with a user who does not know their design preference yet
|
||||
|
||||
## Non-Negotiables
|
||||
|
||||
1. **Zero dependencies**: default to one self-contained HTML file with inline CSS and JS.
|
||||
2. **Viewport fit is mandatory**: every slide must fit inside one viewport with no internal scrolling.
|
||||
3. **Show, don't tell**: use visual previews instead of abstract style questionnaires.
|
||||
4. **Distinctive design**: avoid generic purple-gradient, Inter-on-white, template-looking decks.
|
||||
5. **Production quality**: keep code commented, accessible, responsive, and performant.
|
||||
|
||||
Before generating, read `STYLE_PRESETS.md` for the viewport-safe CSS base, density limits, preset catalog, and CSS gotchas.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Detect Mode
|
||||
|
||||
Choose one path:
|
||||
- **New presentation**: user has a topic, notes, or full draft
|
||||
- **PPT conversion**: user has `.ppt` or `.pptx`
|
||||
- **Enhancement**: user already has HTML slides and wants improvements
|
||||
|
||||
### 2. Discover Content
|
||||
|
||||
Ask only the minimum needed:
|
||||
- purpose: pitch, teaching, conference talk, internal update
|
||||
- length: short (5-10), medium (10-20), long (20+)
|
||||
- content state: finished copy, rough notes, topic only
|
||||
|
||||
If the user has content, ask them to paste it before styling.
|
||||
|
||||
### 3. Discover Style
|
||||
|
||||
Default to visual exploration.
|
||||
|
||||
If the user already knows the desired preset, skip previews and use it directly.
|
||||
|
||||
Otherwise:
|
||||
1. Ask what feeling the deck should create: impressed, energized, focused, inspired.
|
||||
2. Generate **3 single-slide preview files** in `.ecc-design/slide-previews/`.
|
||||
3. Each preview must be self-contained, show typography/color/motion clearly, and stay under roughly 100 lines of slide content.
|
||||
4. Ask the user which preview to keep or what elements to mix.
|
||||
|
||||
Use the preset guide in `STYLE_PRESETS.md` when mapping mood to style.
|
||||
|
||||
### 4. Build the Presentation
|
||||
|
||||
Output either:
|
||||
- `presentation.html`
|
||||
- `[presentation-name].html`
|
||||
|
||||
Use an `assets/` folder only when the deck contains extracted or user-supplied images.
|
||||
|
||||
Required structure:
|
||||
- semantic slide sections
|
||||
- a viewport-safe CSS base from `STYLE_PRESETS.md`
|
||||
- CSS custom properties for theme values
|
||||
- a presentation controller class for keyboard, wheel, and touch navigation
|
||||
- Intersection Observer for reveal animations
|
||||
- reduced-motion support
|
||||
|
||||
### 5. Enforce Viewport Fit
|
||||
|
||||
Treat this as a hard gate.
|
||||
|
||||
Rules:
|
||||
- every `.slide` must use `height: 100vh; height: 100dvh; overflow: hidden;`
|
||||
- all type and spacing must scale with `clamp()`
|
||||
- when content does not fit, split into multiple slides
|
||||
- never solve overflow by shrinking text below readable sizes
|
||||
- never allow scrollbars inside a slide
|
||||
|
||||
Use the density limits and mandatory CSS block in `STYLE_PRESETS.md`.
|
||||
|
||||
### 6. Validate
|
||||
|
||||
Check the finished deck at these sizes:
|
||||
- 1920x1080
|
||||
- 1280x720
|
||||
- 768x1024
|
||||
- 375x667
|
||||
- 667x375
|
||||
|
||||
If browser automation is available, use it to verify no slide overflows and that keyboard navigation works.
|
||||
|
||||
### 7. Deliver
|
||||
|
||||
At handoff:
|
||||
- delete temporary preview files unless the user wants to keep them
|
||||
- open the deck with the platform-appropriate opener when useful
|
||||
- summarize file path, preset used, slide count, and easy theme customization points
|
||||
|
||||
Use the correct opener for the current OS:
|
||||
- macOS: `open file.html`
|
||||
- Linux: `xdg-open file.html`
|
||||
- Windows: `start "" file.html`
|
||||
|
||||
## PPT / PPTX Conversion
|
||||
|
||||
For PowerPoint conversion:
|
||||
1. Prefer `python3` with `python-pptx` to extract text, images, and notes.
|
||||
2. If `python-pptx` is unavailable, ask whether to install it or fall back to a manual/export-based workflow.
|
||||
3. Preserve slide order, speaker notes, and extracted assets.
|
||||
4. After extraction, run the same style-selection workflow as a new presentation.
|
||||
|
||||
Keep conversion cross-platform. Do not rely on macOS-only tools when Python can do the job.
|
||||
|
||||
## Implementation Requirements
|
||||
|
||||
### HTML / CSS
|
||||
|
||||
- Use inline CSS and JS unless the user explicitly wants a multi-file project.
|
||||
- Fonts may come from Google Fonts or Fontshare.
|
||||
- Prefer atmospheric backgrounds, strong type hierarchy, and a clear visual direction.
|
||||
- Use abstract shapes, gradients, grids, noise, and geometry rather than illustrations.
|
||||
|
||||
### JavaScript
|
||||
|
||||
Include:
|
||||
- keyboard navigation
|
||||
- touch / swipe navigation
|
||||
- mouse wheel navigation
|
||||
- progress indicator or slide index
|
||||
- reveal-on-enter animation triggers
|
||||
|
||||
### Accessibility
|
||||
|
||||
- use semantic structure (`main`, `section`, `nav`)
|
||||
- keep contrast readable
|
||||
- support keyboard-only navigation
|
||||
- respect `prefers-reduced-motion`
|
||||
|
||||
## Content Density Limits
|
||||
|
||||
Use these maxima unless the user explicitly asks for denser slides and readability still holds:
|
||||
|
||||
| Slide type | Limit |
|
||||
|------------|-------|
|
||||
| Title | 1 heading + 1 subtitle + optional tagline |
|
||||
| Content | 1 heading + 4-6 bullets or 2 short paragraphs |
|
||||
| Feature grid | 6 cards max |
|
||||
| Code | 8-10 lines max |
|
||||
| Quote | 1 quote + attribution |
|
||||
| Image | 1 image constrained by viewport |
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- generic startup gradients with no visual identity
|
||||
- system-font decks unless intentionally editorial
|
||||
- long bullet walls
|
||||
- code blocks that need scrolling
|
||||
- fixed-height content boxes that break on short screens
|
||||
- invalid negated CSS functions like `-clamp(...)`
|
||||
|
||||
## Related ECC Skills
|
||||
|
||||
- `frontend-patterns` for component and interaction patterns around the deck
|
||||
- `liquid-glass-design` when a presentation intentionally borrows Apple glass aesthetics
|
||||
- `e2e-testing` if you need automated browser verification for the final deck
|
||||
|
||||
## Deliverable Checklist
|
||||
|
||||
- presentation runs from a local file in a browser
|
||||
- every slide fits the viewport without scrolling
|
||||
- style is distinctive and intentional
|
||||
- animation is meaningful, not noisy
|
||||
- reduced motion is respected
|
||||
- file paths and customization points are explained at handoff
|
||||
330
.cursor/skills/frontend-slides/STYLE_PRESETS.md
Normal file
330
.cursor/skills/frontend-slides/STYLE_PRESETS.md
Normal file
@@ -0,0 +1,330 @@
|
||||
# Style Presets Reference
|
||||
|
||||
Curated visual styles for `frontend-slides`.
|
||||
|
||||
Use this file for:
|
||||
- the mandatory viewport-fitting CSS base
|
||||
- preset selection and mood mapping
|
||||
- CSS gotchas and validation rules
|
||||
|
||||
Abstract shapes only. Avoid illustrations unless the user explicitly asks for them.
|
||||
|
||||
## Viewport Fit Is Non-Negotiable
|
||||
|
||||
Every slide must fully fit in one viewport.
|
||||
|
||||
### Golden Rule
|
||||
|
||||
```text
|
||||
Each slide = exactly one viewport height.
|
||||
Too much content = split into more slides.
|
||||
Never scroll inside a slide.
|
||||
```
|
||||
|
||||
### Density Limits
|
||||
|
||||
| Slide Type | Maximum Content |
|
||||
|------------|-----------------|
|
||||
| Title slide | 1 heading + 1 subtitle + optional tagline |
|
||||
| Content slide | 1 heading + 4-6 bullets or 2 paragraphs |
|
||||
| Feature grid | 6 cards maximum |
|
||||
| Code slide | 8-10 lines maximum |
|
||||
| Quote slide | 1 quote + attribution |
|
||||
| Image slide | 1 image, ideally under 60vh |
|
||||
|
||||
## Mandatory Base CSS
|
||||
|
||||
Copy this block into every generated presentation and then theme on top of it.
|
||||
|
||||
```css
|
||||
/* ===========================================
|
||||
VIEWPORT FITTING: MANDATORY BASE STYLES
|
||||
=========================================== */
|
||||
|
||||
html, body {
|
||||
height: 100%;
|
||||
overflow-x: hidden;
|
||||
}
|
||||
|
||||
html {
|
||||
scroll-snap-type: y mandatory;
|
||||
scroll-behavior: smooth;
|
||||
}
|
||||
|
||||
.slide {
|
||||
width: 100vw;
|
||||
height: 100vh;
|
||||
height: 100dvh;
|
||||
overflow: hidden;
|
||||
scroll-snap-align: start;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
position: relative;
|
||||
}
|
||||
|
||||
.slide-content {
|
||||
flex: 1;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
justify-content: center;
|
||||
max-height: 100%;
|
||||
overflow: hidden;
|
||||
padding: var(--slide-padding);
|
||||
}
|
||||
|
||||
:root {
|
||||
--title-size: clamp(1.5rem, 5vw, 4rem);
|
||||
--h2-size: clamp(1.25rem, 3.5vw, 2.5rem);
|
||||
--h3-size: clamp(1rem, 2.5vw, 1.75rem);
|
||||
--body-size: clamp(0.75rem, 1.5vw, 1.125rem);
|
||||
--small-size: clamp(0.65rem, 1vw, 0.875rem);
|
||||
|
||||
--slide-padding: clamp(1rem, 4vw, 4rem);
|
||||
--content-gap: clamp(0.5rem, 2vw, 2rem);
|
||||
--element-gap: clamp(0.25rem, 1vw, 1rem);
|
||||
}
|
||||
|
||||
.card, .container, .content-box {
|
||||
max-width: min(90vw, 1000px);
|
||||
max-height: min(80vh, 700px);
|
||||
}
|
||||
|
||||
.feature-list, .bullet-list {
|
||||
gap: clamp(0.4rem, 1vh, 1rem);
|
||||
}
|
||||
|
||||
.feature-list li, .bullet-list li {
|
||||
font-size: var(--body-size);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(min(100%, 250px), 1fr));
|
||||
gap: clamp(0.5rem, 1.5vw, 1rem);
|
||||
}
|
||||
|
||||
img, .image-container {
|
||||
max-width: 100%;
|
||||
max-height: min(50vh, 400px);
|
||||
object-fit: contain;
|
||||
}
|
||||
|
||||
@media (max-height: 700px) {
|
||||
:root {
|
||||
--slide-padding: clamp(0.75rem, 3vw, 2rem);
|
||||
--content-gap: clamp(0.4rem, 1.5vw, 1rem);
|
||||
--title-size: clamp(1.25rem, 4.5vw, 2.5rem);
|
||||
--h2-size: clamp(1rem, 3vw, 1.75rem);
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-height: 600px) {
|
||||
:root {
|
||||
--slide-padding: clamp(0.5rem, 2.5vw, 1.5rem);
|
||||
--content-gap: clamp(0.3rem, 1vw, 0.75rem);
|
||||
--title-size: clamp(1.1rem, 4vw, 2rem);
|
||||
--body-size: clamp(0.7rem, 1.2vw, 0.95rem);
|
||||
}
|
||||
|
||||
.nav-dots, .keyboard-hint, .decorative {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-height: 500px) {
|
||||
:root {
|
||||
--slide-padding: clamp(0.4rem, 2vw, 1rem);
|
||||
--title-size: clamp(1rem, 3.5vw, 1.5rem);
|
||||
--h2-size: clamp(0.9rem, 2.5vw, 1.25rem);
|
||||
--body-size: clamp(0.65rem, 1vw, 0.85rem);
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-width: 600px) {
|
||||
:root {
|
||||
--title-size: clamp(1.25rem, 7vw, 2.5rem);
|
||||
}
|
||||
|
||||
.grid {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
}
|
||||
|
||||
@media (prefers-reduced-motion: reduce) {
|
||||
*, *::before, *::after {
|
||||
animation-duration: 0.01ms !important;
|
||||
transition-duration: 0.2s !important;
|
||||
}
|
||||
|
||||
html {
|
||||
scroll-behavior: auto;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Viewport Checklist
|
||||
|
||||
- every `.slide` has `height: 100vh`, `height: 100dvh`, and `overflow: hidden`
|
||||
- all typography uses `clamp()`
|
||||
- all spacing uses `clamp()` or viewport units
|
||||
- images have `max-height` constraints
|
||||
- grids adapt with `auto-fit` + `minmax()`
|
||||
- short-height breakpoints exist at `700px`, `600px`, and `500px`
|
||||
- if anything feels cramped, split the slide
|
||||
|
||||
## Mood to Preset Mapping
|
||||
|
||||
| Mood | Good Presets |
|
||||
|------|--------------|
|
||||
| Impressed / Confident | Bold Signal, Electric Studio, Dark Botanical |
|
||||
| Excited / Energized | Creative Voltage, Neon Cyber, Split Pastel |
|
||||
| Calm / Focused | Notebook Tabs, Paper & Ink, Swiss Modern |
|
||||
| Inspired / Moved | Dark Botanical, Vintage Editorial, Pastel Geometry |
|
||||
|
||||
## Preset Catalog
|
||||
|
||||
### 1. Bold Signal
|
||||
|
||||
- Vibe: confident, high-impact, keynote-ready
|
||||
- Best for: pitch decks, launches, statements
|
||||
- Fonts: Archivo Black + Space Grotesk
|
||||
- Palette: charcoal base, hot orange focal card, crisp white text
|
||||
- Signature: oversized section numbers, high-contrast card on dark field
|
||||
|
||||
### 2. Electric Studio
|
||||
|
||||
- Vibe: clean, bold, agency-polished
|
||||
- Best for: client presentations, strategic reviews
|
||||
- Fonts: Manrope only
|
||||
- Palette: black, white, saturated cobalt accent
|
||||
- Signature: two-panel split and sharp editorial alignment
|
||||
|
||||
### 3. Creative Voltage
|
||||
|
||||
- Vibe: energetic, retro-modern, playful confidence
|
||||
- Best for: creative studios, brand work, product storytelling
|
||||
- Fonts: Syne + Space Mono
|
||||
- Palette: electric blue, neon yellow, deep navy
|
||||
- Signature: halftone textures, badges, punchy contrast
|
||||
|
||||
### 4. Dark Botanical
|
||||
|
||||
- Vibe: elegant, premium, atmospheric
|
||||
- Best for: luxury brands, thoughtful narratives, premium product decks
|
||||
- Fonts: Cormorant + IBM Plex Sans
|
||||
- Palette: near-black, warm ivory, blush, gold, terracotta
|
||||
- Signature: blurred abstract circles, fine rules, restrained motion
|
||||
|
||||
### 5. Notebook Tabs
|
||||
|
||||
- Vibe: editorial, organized, tactile
|
||||
- Best for: reports, reviews, structured storytelling
|
||||
- Fonts: Bodoni Moda + DM Sans
|
||||
- Palette: cream paper on charcoal with pastel tabs
|
||||
- Signature: paper sheet, colored side tabs, binder details
|
||||
|
||||
### 6. Pastel Geometry
|
||||
|
||||
- Vibe: approachable, modern, friendly
|
||||
- Best for: product overviews, onboarding, lighter brand decks
|
||||
- Fonts: Plus Jakarta Sans only
|
||||
- Palette: pale blue field, cream card, soft pink/mint/lavender accents
|
||||
- Signature: vertical pills, rounded cards, soft shadows
|
||||
|
||||
### 7. Split Pastel
|
||||
|
||||
- Vibe: playful, modern, creative
|
||||
- Best for: agency intros, workshops, portfolios
|
||||
- Fonts: Outfit only
|
||||
- Palette: peach + lavender split with mint badges
|
||||
- Signature: split backdrop, rounded tags, light grid overlays
|
||||
|
||||
### 8. Vintage Editorial
|
||||
|
||||
- Vibe: witty, personality-driven, magazine-inspired
|
||||
- Best for: personal brands, opinionated talks, storytelling
|
||||
- Fonts: Fraunces + Work Sans
|
||||
- Palette: cream, charcoal, dusty warm accents
|
||||
- Signature: geometric accents, bordered callouts, punchy serif headlines
|
||||
|
||||
### 9. Neon Cyber
|
||||
|
||||
- Vibe: futuristic, techy, kinetic
|
||||
- Best for: AI, infra, dev tools, future-of-X talks
|
||||
- Fonts: Clash Display + Satoshi
|
||||
- Palette: midnight navy, cyan, magenta
|
||||
- Signature: glow, particles, grids, data-radar energy
|
||||
|
||||
### 10. Terminal Green
|
||||
|
||||
- Vibe: developer-focused, hacker-clean
|
||||
- Best for: APIs, CLI tools, engineering demos
|
||||
- Fonts: JetBrains Mono only
|
||||
- Palette: GitHub dark + terminal green
|
||||
- Signature: scan lines, command-line framing, precise monospace rhythm
|
||||
|
||||
### 11. Swiss Modern
|
||||
|
||||
- Vibe: minimal, precise, data-forward
|
||||
- Best for: corporate, product strategy, analytics
|
||||
- Fonts: Archivo + Nunito
|
||||
- Palette: white, black, signal red
|
||||
- Signature: visible grids, asymmetry, geometric discipline
|
||||
|
||||
### 12. Paper & Ink
|
||||
|
||||
- Vibe: literary, thoughtful, story-driven
|
||||
- Best for: essays, keynote narratives, manifesto decks
|
||||
- Fonts: Cormorant Garamond + Source Serif 4
|
||||
- Palette: warm cream, charcoal, crimson accent
|
||||
- Signature: pull quotes, drop caps, elegant rules
|
||||
|
||||
## Direct Selection Prompts
|
||||
|
||||
If the user already knows the style they want, let them pick directly from the preset names above instead of forcing preview generation.
|
||||
|
||||
## Animation Feel Mapping
|
||||
|
||||
| Feeling | Motion Direction |
|
||||
|---------|------------------|
|
||||
| Dramatic / Cinematic | slow fades, parallax, large scale-ins |
|
||||
| Techy / Futuristic | glow, particles, grid motion, scramble text |
|
||||
| Playful / Friendly | springy easing, rounded shapes, floating motion |
|
||||
| Professional / Corporate | subtle 200-300ms transitions, clean slides |
|
||||
| Calm / Minimal | very restrained movement, whitespace-first |
|
||||
| Editorial / Magazine | strong hierarchy, staggered text and image interplay |
|
||||
|
||||
## CSS Gotcha: Negating Functions
|
||||
|
||||
Never write these:
|
||||
|
||||
```css
|
||||
right: -clamp(28px, 3.5vw, 44px);
|
||||
margin-left: -min(10vw, 100px);
|
||||
```
|
||||
|
||||
Browsers ignore them silently.
|
||||
|
||||
Always write this instead:
|
||||
|
||||
```css
|
||||
right: calc(-1 * clamp(28px, 3.5vw, 44px));
|
||||
margin-left: calc(-1 * min(10vw, 100px));
|
||||
```
|
||||
|
||||
## Validation Sizes
|
||||
|
||||
Test at minimum:
|
||||
- Desktop: `1920x1080`, `1440x900`, `1280x720`
|
||||
- Tablet: `1024x768`, `768x1024`
|
||||
- Mobile: `375x667`, `414x896`
|
||||
- Landscape phone: `667x375`, `896x414`
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
Do not use:
|
||||
- purple-on-white startup templates
|
||||
- Inter / Roboto / Arial as the visual voice unless the user explicitly wants utilitarian neutrality
|
||||
- bullet walls, tiny type, or code blocks that require scrolling
|
||||
- decorative illustrations when abstract geometry would do the job better
|
||||
96
.cursor/skills/investor-materials/SKILL.md
Normal file
96
.cursor/skills/investor-materials/SKILL.md
Normal file
@@ -0,0 +1,96 @@
|
||||
---
|
||||
name: investor-materials
|
||||
description: Create and update pitch decks, one-pagers, investor memos, accelerator applications, financial models, and fundraising materials. Use when the user needs investor-facing documents, projections, use-of-funds tables, milestone plans, or materials that must stay internally consistent across multiple fundraising assets.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Investor Materials
|
||||
|
||||
Build investor-facing materials that are consistent, credible, and easy to defend.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- creating or revising a pitch deck
|
||||
- writing an investor memo or one-pager
|
||||
- building a financial model, milestone plan, or use-of-funds table
|
||||
- answering accelerator or incubator application questions
|
||||
- aligning multiple fundraising docs around one source of truth
|
||||
|
||||
## Golden Rule
|
||||
|
||||
All investor materials must agree with each other.
|
||||
|
||||
Create or confirm a single source of truth before writing:
|
||||
- traction metrics
|
||||
- pricing and revenue assumptions
|
||||
- raise size and instrument
|
||||
- use of funds
|
||||
- team bios and titles
|
||||
- milestones and timelines
|
||||
|
||||
If conflicting numbers appear, stop and resolve them before drafting.
|
||||
|
||||
## Core Workflow
|
||||
|
||||
1. inventory the canonical facts
|
||||
2. identify missing assumptions
|
||||
3. choose the asset type
|
||||
4. draft the asset with explicit logic
|
||||
5. cross-check every number against the source of truth
|
||||
|
||||
## Asset Guidance
|
||||
|
||||
### Pitch Deck
|
||||
Recommended flow:
|
||||
1. company + wedge
|
||||
2. problem
|
||||
3. solution
|
||||
4. product / demo
|
||||
5. market
|
||||
6. business model
|
||||
7. traction
|
||||
8. team
|
||||
9. competition / differentiation
|
||||
10. ask
|
||||
11. use of funds / milestones
|
||||
12. appendix
|
||||
|
||||
If the user wants a web-native deck, pair this skill with `frontend-slides`.
|
||||
|
||||
### One-Pager / Memo
|
||||
- state what the company does in one clean sentence
|
||||
- show why now
|
||||
- include traction and proof points early
|
||||
- make the ask precise
|
||||
- keep claims easy to verify
|
||||
|
||||
### Financial Model
|
||||
Include:
|
||||
- explicit assumptions
|
||||
- bear / base / bull cases when useful
|
||||
- clean layer-by-layer revenue logic
|
||||
- milestone-linked spending
|
||||
- sensitivity analysis where the decision hinges on assumptions
|
||||
|
||||
### Accelerator Applications
|
||||
- answer the exact question asked
|
||||
- prioritize traction, insight, and team advantage
|
||||
- avoid puffery
|
||||
- keep internal metrics consistent with the deck and model
|
||||
|
||||
## Red Flags to Avoid
|
||||
|
||||
- unverifiable claims
|
||||
- fuzzy market sizing without assumptions
|
||||
- inconsistent team roles or titles
|
||||
- revenue math that does not sum cleanly
|
||||
- inflated certainty where assumptions are fragile
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- every number matches the current source of truth
|
||||
- use of funds and revenue layers sum correctly
|
||||
- assumptions are visible, not buried
|
||||
- the story is clear without hype language
|
||||
- the final asset is defensible in a partner meeting
|
||||
76
.cursor/skills/investor-outreach/SKILL.md
Normal file
76
.cursor/skills/investor-outreach/SKILL.md
Normal file
@@ -0,0 +1,76 @@
|
||||
---
|
||||
name: investor-outreach
|
||||
description: Draft cold emails, warm intro blurbs, follow-ups, update emails, and investor communications for fundraising. Use when the user wants outreach to angels, VCs, strategic investors, or accelerators and needs concise, personalized, investor-facing messaging.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Investor Outreach
|
||||
|
||||
Write investor communication that is short, personalized, and easy to act on.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- writing a cold email to an investor
|
||||
- drafting a warm intro request
|
||||
- sending follow-ups after a meeting or no response
|
||||
- writing investor updates during a process
|
||||
- tailoring outreach based on fund thesis or partner fit
|
||||
|
||||
## Core Rules
|
||||
|
||||
1. Personalize every outbound message.
|
||||
2. Keep the ask low-friction.
|
||||
3. Use proof, not adjectives.
|
||||
4. Stay concise.
|
||||
5. Never send generic copy that could go to any investor.
|
||||
|
||||
## 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
|
||||
4. ask: one concrete next step
|
||||
5. sign-off: name, role, one credibility anchor if needed
|
||||
|
||||
## Personalization Sources
|
||||
|
||||
Reference one or more of:
|
||||
- relevant portfolio companies
|
||||
- a public thesis, talk, post, or article
|
||||
- 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.
|
||||
|
||||
## 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
|
||||
|
||||
Do not keep nudging after that unless the user wants a longer sequence.
|
||||
|
||||
## Warm Intro Requests
|
||||
|
||||
Make life easy for the connector:
|
||||
- explain why the intro is a fit
|
||||
- include a forwardable blurb
|
||||
- keep the forwardable blurb under 100 words
|
||||
|
||||
## Post-Meeting Updates
|
||||
|
||||
Include:
|
||||
- the specific thing discussed
|
||||
- the answer or update promised
|
||||
- one new proof point if available
|
||||
- the next step
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- message is personalized
|
||||
- the ask is explicit
|
||||
- there is no fluff or begging language
|
||||
- the proof point is concrete
|
||||
- word count stays tight
|
||||
75
.cursor/skills/market-research/SKILL.md
Normal file
75
.cursor/skills/market-research/SKILL.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
name: market-research
|
||||
description: Conduct market research, competitive analysis, investor due diligence, and industry intelligence with source attribution and decision-oriented summaries. Use when the user wants market sizing, competitor comparisons, fund research, technology scans, or research that informs business decisions.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Market Research
|
||||
|
||||
Produce research that supports decisions, not research theater.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- researching a market, category, company, investor, or technology trend
|
||||
- building TAM/SAM/SOM estimates
|
||||
- comparing competitors or adjacent products
|
||||
- preparing investor dossiers before outreach
|
||||
- pressure-testing a thesis before building, funding, or entering a market
|
||||
|
||||
## Research Standards
|
||||
|
||||
1. Every important claim needs a source.
|
||||
2. Prefer recent data and call out stale data.
|
||||
3. Include contrarian evidence and downside cases.
|
||||
4. Translate findings into a decision, not just a summary.
|
||||
5. Separate fact, inference, and recommendation clearly.
|
||||
|
||||
## Common Research Modes
|
||||
|
||||
### Investor / Fund Diligence
|
||||
Collect:
|
||||
- fund size, stage, and typical check size
|
||||
- relevant portfolio companies
|
||||
- public thesis and recent activity
|
||||
- reasons the fund is or is not a fit
|
||||
- any obvious red flags or mismatches
|
||||
|
||||
### Competitive Analysis
|
||||
Collect:
|
||||
- product reality, not marketing copy
|
||||
- funding and investor history if public
|
||||
- traction metrics if public
|
||||
- distribution and pricing clues
|
||||
- strengths, weaknesses, and positioning gaps
|
||||
|
||||
### Market Sizing
|
||||
Use:
|
||||
- top-down estimates from reports or public datasets
|
||||
- bottom-up sanity checks from realistic customer acquisition assumptions
|
||||
- explicit assumptions for every leap in logic
|
||||
|
||||
### Technology / Vendor Research
|
||||
Collect:
|
||||
- how it works
|
||||
- trade-offs and adoption signals
|
||||
- integration complexity
|
||||
- lock-in, security, compliance, and operational risk
|
||||
|
||||
## Output Format
|
||||
|
||||
Default structure:
|
||||
1. executive summary
|
||||
2. key findings
|
||||
3. implications
|
||||
4. risks and caveats
|
||||
5. recommendation
|
||||
6. sources
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- all numbers are sourced or labeled as estimates
|
||||
- old data is flagged
|
||||
- the recommendation follows from the evidence
|
||||
- risks and counterarguments are included
|
||||
- the output makes a decision easier
|
||||
@@ -130,23 +130,27 @@ OpenCode has 20+ additional events not available in Claude Code.
|
||||
|
||||
## Skills
|
||||
|
||||
All 16 ECC skills are available via the `instructions` array:
|
||||
The default OpenCode config loads 11 curated ECC skills via the `instructions` array:
|
||||
|
||||
- coding-standards
|
||||
- backend-patterns
|
||||
- frontend-patterns
|
||||
- frontend-slides
|
||||
- security-review
|
||||
- tdd-workflow
|
||||
- continuous-learning
|
||||
- continuous-learning-v2
|
||||
- iterative-retrieval
|
||||
- strategic-compact
|
||||
- eval-harness
|
||||
- verification-loop
|
||||
- golang-patterns
|
||||
- golang-testing
|
||||
- clickhouse-io
|
||||
- pmx-guidelines
|
||||
- api-design
|
||||
- e2e-testing
|
||||
|
||||
Additional specialized skills are shipped in `skills/` but not loaded by default to keep OpenCode sessions lean:
|
||||
|
||||
- article-writing
|
||||
- content-engine
|
||||
- market-research
|
||||
- investor-materials
|
||||
- investor-outreach
|
||||
|
||||
## Configuration
|
||||
|
||||
|
||||
@@ -11,6 +11,7 @@
|
||||
"skills/security-review/SKILL.md",
|
||||
"skills/coding-standards/SKILL.md",
|
||||
"skills/frontend-patterns/SKILL.md",
|
||||
"skills/frontend-slides/SKILL.md",
|
||||
"skills/backend-patterns/SKILL.md",
|
||||
"skills/e2e-testing/SKILL.md",
|
||||
"skills/verification-loop/SKILL.md",
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "ecc-universal",
|
||||
"version": "1.6.0",
|
||||
"version": "1.7.0",
|
||||
"description": "Everything Claude Code (ECC) plugin for OpenCode - agents, commands, hooks, and skills",
|
||||
"main": "dist/index.js",
|
||||
"types": "dist/index.d.ts",
|
||||
|
||||
29
README.md
29
README.md
@@ -69,6 +69,14 @@ This repo is the raw code only. The guides explain everything.
|
||||
|
||||
## What's New
|
||||
|
||||
### v1.7.0 — Cross-Platform Expansion & Presentation Builder (Feb 2026)
|
||||
|
||||
- **Codex app + CLI support** — Direct `AGENTS.md`-based Codex support, installer targeting, and Codex docs
|
||||
- **`frontend-slides` skill** — Zero-dependency HTML presentation builder with PPTX conversion guidance and strict viewport-fit rules
|
||||
- **5 new generic business/content skills** — `article-writing`, `content-engine`, `market-research`, `investor-materials`, `investor-outreach`
|
||||
- **Broader tool coverage** — Cursor, Codex, and OpenCode support tightened so the same repo ships cleanly across all major harnesses
|
||||
- **992 internal tests** — Expanded validation and regression coverage across plugin, hooks, skills, and packaging
|
||||
|
||||
### v1.6.0 — Codex CLI, AgentShield & Marketplace (Feb 2026)
|
||||
|
||||
- **Codex CLI support** — New `/codex-setup` command generates `codex.md` for OpenAI Codex CLI compatibility
|
||||
@@ -126,7 +134,6 @@ Get up and running in under 2 minutes:
|
||||
|
||||
> ⚠️ **Important:** Claude Code plugins cannot distribute `rules` automatically. Install them manually:
|
||||
|
||||
|
||||
```bash
|
||||
# Clone the repo first
|
||||
git clone https://github.com/affaan-m/everything-claude-code.git
|
||||
@@ -155,7 +162,7 @@ For manual install instructions see the README in the `rules/` folder.
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
✨ **That's it!** You now have access to 13 agents, 48 skills, and 32 commands.
|
||||
✨ **That's it!** You now have access to 13 agents, 56 skills, and 32 commands.
|
||||
|
||||
---
|
||||
|
||||
@@ -224,6 +231,12 @@ everything-claude-code/
|
||||
| |-- clickhouse-io/ # ClickHouse analytics, queries, data engineering
|
||||
| |-- backend-patterns/ # API, database, caching patterns
|
||||
| |-- frontend-patterns/ # React, Next.js patterns
|
||||
| |-- frontend-slides/ # HTML slide decks and PPTX-to-web presentation workflows (NEW)
|
||||
| |-- article-writing/ # Long-form writing in a supplied voice without generic AI tone (NEW)
|
||||
| |-- content-engine/ # Multi-platform social content and repurposing workflows (NEW)
|
||||
| |-- market-research/ # Source-attributed market, competitor, and investor research (NEW)
|
||||
| |-- investor-materials/ # Pitch decks, one-pagers, memos, and financial models (NEW)
|
||||
| |-- investor-outreach/ # Personalized fundraising outreach and follow-up (NEW)
|
||||
| |-- continuous-learning/ # Auto-extract patterns from sessions (Longform Guide)
|
||||
| |-- continuous-learning-v2/ # Instinct-based learning with confidence scoring
|
||||
| |-- iterative-retrieval/ # Progressive context refinement for subagents
|
||||
@@ -796,7 +809,7 @@ ECC provides **full Cursor IDE support** with hooks, rules, agents, skills, comm
|
||||
| Hook Scripts | 16 | Thin Node.js scripts delegating to `scripts/hooks/` via shared adapter |
|
||||
| Rules | 29 | 9 common (alwaysApply) + 20 language-specific (TypeScript, Python, Go, Swift) |
|
||||
| Agents | Shared | Via AGENTS.md at root (read by Cursor natively) |
|
||||
| Skills | Shared | Via AGENTS.md at root |
|
||||
| Skills | Shared + Bundled | Via AGENTS.md at root and `.cursor/skills/` for translated additions |
|
||||
| Commands | Shared | `.cursor/commands/` if installed |
|
||||
| MCP Config | Shared | `.cursor/mcp.json` if installed |
|
||||
|
||||
@@ -832,7 +845,7 @@ alwaysApply: false
|
||||
|
||||
## Codex CLI Support
|
||||
|
||||
ECC provides **first-class Codex CLI support** with a reference configuration, Codex-specific AGENTS.md supplement, and 10 ported skills.
|
||||
ECC provides **first-class Codex CLI support** with a reference configuration, Codex-specific AGENTS.md supplement, and 16 ported skills.
|
||||
|
||||
### Quick Start (Codex)
|
||||
|
||||
@@ -850,7 +863,7 @@ codex
|
||||
|-----------|-------|---------|
|
||||
| Config | 1 | `.codex/config.toml` — model, permissions, MCP servers, persistent instructions |
|
||||
| AGENTS.md | 2 | Root (universal) + `.codex/AGENTS.md` (Codex-specific supplement) |
|
||||
| Skills | 10 | `.agents/skills/` — SKILL.md + agents/openai.yaml per skill |
|
||||
| Skills | 16 | `.agents/skills/` — SKILL.md + agents/openai.yaml per skill |
|
||||
| MCP Servers | 4 | GitHub, Context7, Memory, Sequential Thinking (command-based) |
|
||||
| Profiles | 2 | `strict` (read-only sandbox) and `yolo` (full auto-approve) |
|
||||
|
||||
@@ -864,6 +877,12 @@ Skills at `.agents/skills/` are auto-loaded by Codex:
|
||||
| security-review | Comprehensive security checklist |
|
||||
| coding-standards | Universal coding standards |
|
||||
| frontend-patterns | React/Next.js patterns |
|
||||
| frontend-slides | HTML presentations, PPTX conversion, visual style exploration |
|
||||
| article-writing | Long-form writing from notes and voice references |
|
||||
| content-engine | Platform-native social content and repurposing |
|
||||
| market-research | Source-attributed market and competitor research |
|
||||
| investor-materials | Decks, memos, models, and one-pagers |
|
||||
| investor-outreach | Personalized outreach, follow-ups, and intro blurbs |
|
||||
| backend-patterns | API design, database, caching |
|
||||
| e2e-testing | Playwright E2E tests |
|
||||
| eval-harness | Eval-driven development |
|
||||
|
||||
10
package.json
10
package.json
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "ecc-universal",
|
||||
"version": "1.6.0",
|
||||
"version": "1.7.0",
|
||||
"description": "Complete collection of battle-tested Claude Code configs — agents, skills, hooks, commands, and rules evolved over 10+ months of intensive daily use by an Anthropic hackathon winner",
|
||||
"keywords": [
|
||||
"claude-code",
|
||||
@@ -19,7 +19,10 @@
|
||||
"best-practices",
|
||||
"cursor",
|
||||
"cursor-ide",
|
||||
"opencode"
|
||||
"opencode",
|
||||
"codex",
|
||||
"presentations",
|
||||
"slides"
|
||||
],
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
@@ -35,6 +38,8 @@
|
||||
"url": "https://github.com/affaan-m/everything-claude-code/issues"
|
||||
},
|
||||
"files": [
|
||||
".agents/",
|
||||
".codex/",
|
||||
".cursor/",
|
||||
".opencode/commands/",
|
||||
".opencode/instructions/",
|
||||
@@ -65,6 +70,7 @@
|
||||
"scripts/setup-package-manager.js",
|
||||
"scripts/skill-create-output.js",
|
||||
"skills/",
|
||||
"AGENTS.md",
|
||||
".claude-plugin/plugin.json",
|
||||
".claude-plugin/README.md",
|
||||
"install.sh",
|
||||
|
||||
@@ -5,7 +5,10 @@ set -euo pipefail
|
||||
# Usage: ./scripts/release.sh VERSION
|
||||
|
||||
VERSION="${1:-}"
|
||||
ROOT_PACKAGE_JSON="package.json"
|
||||
PLUGIN_JSON=".claude-plugin/plugin.json"
|
||||
MARKETPLACE_JSON=".claude-plugin/marketplace.json"
|
||||
OPENCODE_PACKAGE_JSON=".opencode/package.json"
|
||||
|
||||
# Function to show usage
|
||||
usage() {
|
||||
@@ -39,31 +42,40 @@ if ! git diff --quiet || ! git diff --cached --quiet; then
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Verify plugin.json exists
|
||||
if [[ ! -f "$PLUGIN_JSON" ]]; then
|
||||
echo "Error: $PLUGIN_JSON not found"
|
||||
exit 1
|
||||
fi
|
||||
# Verify versioned manifests exist
|
||||
for FILE in "$ROOT_PACKAGE_JSON" "$PLUGIN_JSON" "$MARKETPLACE_JSON" "$OPENCODE_PACKAGE_JSON"; do
|
||||
if [[ ! -f "$FILE" ]]; then
|
||||
echo "Error: $FILE not found"
|
||||
exit 1
|
||||
fi
|
||||
done
|
||||
|
||||
# Read current version
|
||||
OLD_VERSION=$(grep -oE '"version": *"[^"]*"' "$PLUGIN_JSON" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
|
||||
# Read current version from plugin.json
|
||||
OLD_VERSION=$(grep -oE '"version": *"[^"]*"' "$PLUGIN_JSON" | head -1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
|
||||
if [[ -z "$OLD_VERSION" ]]; then
|
||||
echo "Error: Could not extract current version from $PLUGIN_JSON"
|
||||
exit 1
|
||||
fi
|
||||
echo "Bumping version: $OLD_VERSION -> $VERSION"
|
||||
|
||||
# Update version in plugin.json (cross-platform sed, pipe-delimiter avoids issues with slashes)
|
||||
if [[ "$OSTYPE" == "darwin"* ]]; then
|
||||
# macOS
|
||||
sed -i '' "s|\"version\": *\"[^\"]*\"|\"version\": \"$VERSION\"|" "$PLUGIN_JSON"
|
||||
else
|
||||
# Linux
|
||||
sed -i "s|\"version\": *\"[^\"]*\"|\"version\": \"$VERSION\"|" "$PLUGIN_JSON"
|
||||
fi
|
||||
update_version() {
|
||||
local file="$1"
|
||||
local pattern="$2"
|
||||
if [[ "$OSTYPE" == "darwin"* ]]; then
|
||||
sed -i '' "$pattern" "$file"
|
||||
else
|
||||
sed -i "$pattern" "$file"
|
||||
fi
|
||||
}
|
||||
|
||||
# Update all shipped package/plugin manifests
|
||||
update_version "$ROOT_PACKAGE_JSON" "s|\"version\": *\"[^\"]*\"|\"version\": \"$VERSION\"|"
|
||||
update_version "$PLUGIN_JSON" "s|\"version\": *\"[^\"]*\"|\"version\": \"$VERSION\"|"
|
||||
update_version "$MARKETPLACE_JSON" "0,/\"version\": *\"[^\"]*\"/s|\"version\": *\"[^\"]*\"|\"version\": \"$VERSION\"|"
|
||||
update_version "$OPENCODE_PACKAGE_JSON" "s|\"version\": *\"[^\"]*\"|\"version\": \"$VERSION\"|"
|
||||
|
||||
# Stage, commit, tag, and push
|
||||
git add "$PLUGIN_JSON"
|
||||
git add "$ROOT_PACKAGE_JSON" "$PLUGIN_JSON" "$MARKETPLACE_JSON" "$OPENCODE_PACKAGE_JSON"
|
||||
git commit -m "chore: bump plugin version to $VERSION"
|
||||
git tag "v$VERSION"
|
||||
git push origin main "v$VERSION"
|
||||
|
||||
85
skills/article-writing/SKILL.md
Normal file
85
skills/article-writing/SKILL.md
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: article-writing
|
||||
description: Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Article Writing
|
||||
|
||||
Write long-form content that sounds like a real person or brand, not generic AI output.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- drafting blog posts, essays, launch posts, guides, tutorials, or newsletter issues
|
||||
- turning notes, transcripts, or research into polished articles
|
||||
- matching an existing founder, operator, or brand voice from examples
|
||||
- tightening structure, pacing, and evidence in already-written long-form copy
|
||||
|
||||
## Core Rules
|
||||
|
||||
1. Lead with the concrete thing: example, output, anecdote, number, screenshot description, or code block.
|
||||
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.
|
||||
|
||||
## Voice Capture Workflow
|
||||
|
||||
If the user wants a specific voice, collect one or more of:
|
||||
- published articles
|
||||
- newsletters
|
||||
- X / LinkedIn posts
|
||||
- docs or memos
|
||||
- a short 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
|
||||
|
||||
If no voice references are given, default to a direct, operator-style voice: concrete, practical, and low on hype.
|
||||
|
||||
## 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
|
||||
|
||||
## 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.
|
||||
|
||||
## 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
|
||||
- keep one argument thread per section
|
||||
- use examples that earn the opinion
|
||||
|
||||
### Newsletters
|
||||
- keep the first screen strong
|
||||
- mix insight with updates, not diary filler
|
||||
- use clear section labels and easy skim structure
|
||||
|
||||
## 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
|
||||
@@ -81,7 +81,7 @@ Options:
|
||||
|
||||
For each selected category, print the full list of skills below and ask the user to confirm or deselect specific ones. If the list exceeds 4 items, print the list as text and use `AskUserQuestion` with an "Install all listed" option plus "Other" for the user to paste specific names.
|
||||
|
||||
**Category: Framework & Language (16 skills)**
|
||||
**Category: Framework & Language (17 skills)**
|
||||
|
||||
| Skill | Description |
|
||||
|-------|-------------|
|
||||
@@ -92,6 +92,7 @@ For each selected category, print the full list of skills below and ask the user
|
||||
| `django-tdd` | Django testing with pytest-django, factory_boy, mocking, coverage |
|
||||
| `django-verification` | Django verification loop: migrations, linting, tests, security scans |
|
||||
| `frontend-patterns` | React, Next.js, state management, performance, UI patterns |
|
||||
| `frontend-slides` | Zero-dependency HTML presentations, style previews, and PPTX-to-web conversion |
|
||||
| `golang-patterns` | Idiomatic Go patterns, conventions for robust Go applications |
|
||||
| `golang-testing` | Go testing: table-driven tests, subtests, benchmarks, fuzzing |
|
||||
| `java-coding-standards` | Java coding standards for Spring Boot: naming, immutability, Optional, streams |
|
||||
@@ -123,6 +124,16 @@ For each selected category, print the full list of skills below and ask the user
|
||||
| `tdd-workflow` | Enforces TDD with 80%+ coverage: unit, integration, E2E |
|
||||
| `verification-loop` | Verification and quality loop patterns |
|
||||
|
||||
**Category: Business & Content (5 skills)**
|
||||
|
||||
| Skill | Description |
|
||||
|-------|-------------|
|
||||
| `article-writing` | Long-form writing in a supplied voice using notes, examples, or source docs |
|
||||
| `content-engine` | Multi-platform social content, scripts, and repurposing workflows |
|
||||
| `market-research` | Source-attributed market, competitor, fund, and technology research |
|
||||
| `investor-materials` | Pitch decks, one-pagers, investor memos, and financial models |
|
||||
| `investor-outreach` | Personalized investor cold emails, warm intros, and follow-ups |
|
||||
|
||||
**Standalone**
|
||||
|
||||
| Skill | Description |
|
||||
|
||||
88
skills/content-engine/SKILL.md
Normal file
88
skills/content-engine/SKILL.md
Normal file
@@ -0,0 +1,88 @@
|
||||
---
|
||||
name: content-engine
|
||||
description: Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Content Engine
|
||||
|
||||
Turn one idea into strong, platform-native content instead of posting the same thing everywhere.
|
||||
|
||||
## 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
|
||||
|
||||
## First Questions
|
||||
|
||||
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
|
||||
|
||||
## Core Rules
|
||||
|
||||
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.
|
||||
|
||||
## Platform Guidance
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### YouTube
|
||||
- show the result early
|
||||
- structure by chapter
|
||||
- refresh the visual every 20-30 seconds
|
||||
|
||||
### Newsletter
|
||||
- deliver one clear lens, not a bundle of unrelated items
|
||||
- make section titles skimmable
|
||||
- keep the opening paragraph doing real work
|
||||
|
||||
## 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
|
||||
|
||||
## Deliverables
|
||||
|
||||
When asked for a campaign, return:
|
||||
- the core angle
|
||||
- platform-specific drafts
|
||||
- optional posting order
|
||||
- optional CTA variants
|
||||
- any missing inputs needed before publishing
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- each draft reads natively for its platform
|
||||
- hooks are strong and specific
|
||||
- no generic hype language
|
||||
- no duplicated copy across platforms unless requested
|
||||
- the CTA matches the content and audience
|
||||
@@ -9,6 +9,8 @@ version: 2.0.0
|
||||
|
||||
An advanced learning system that turns your Claude Code sessions into reusable knowledge through atomic "instincts" - small learned behaviors with confidence scoring.
|
||||
|
||||
Inspired in part by the Homunculus work from [humanplane](https://github.com/humanplane).
|
||||
|
||||
## When to Activate
|
||||
|
||||
- Setting up automatic learning from Claude Code sessions
|
||||
|
||||
184
skills/frontend-slides/SKILL.md
Normal file
184
skills/frontend-slides/SKILL.md
Normal file
@@ -0,0 +1,184 @@
|
||||
---
|
||||
name: frontend-slides
|
||||
description: Create stunning, animation-rich HTML presentations from scratch or by converting PowerPoint files. Use when the user wants to build a presentation, convert a PPT/PPTX to web, or create slides for a talk/pitch. Helps non-designers discover their aesthetic through visual exploration rather than abstract choices.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Frontend Slides
|
||||
|
||||
Create zero-dependency, animation-rich HTML presentations that run entirely in the browser.
|
||||
|
||||
Inspired by the visual exploration approach showcased in work by [zarazhangrui](https://github.com/zarazhangrui).
|
||||
|
||||
## When to Activate
|
||||
|
||||
- Creating a talk deck, pitch deck, workshop deck, or internal presentation
|
||||
- Converting `.ppt` or `.pptx` slides into an HTML presentation
|
||||
- Improving an existing HTML presentation's layout, motion, or typography
|
||||
- Exploring presentation styles with a user who does not know their design preference yet
|
||||
|
||||
## Non-Negotiables
|
||||
|
||||
1. **Zero dependencies**: default to one self-contained HTML file with inline CSS and JS.
|
||||
2. **Viewport fit is mandatory**: every slide must fit inside one viewport with no internal scrolling.
|
||||
3. **Show, don't tell**: use visual previews instead of abstract style questionnaires.
|
||||
4. **Distinctive design**: avoid generic purple-gradient, Inter-on-white, template-looking decks.
|
||||
5. **Production quality**: keep code commented, accessible, responsive, and performant.
|
||||
|
||||
Before generating, read `STYLE_PRESETS.md` for the viewport-safe CSS base, density limits, preset catalog, and CSS gotchas.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Detect Mode
|
||||
|
||||
Choose one path:
|
||||
- **New presentation**: user has a topic, notes, or full draft
|
||||
- **PPT conversion**: user has `.ppt` or `.pptx`
|
||||
- **Enhancement**: user already has HTML slides and wants improvements
|
||||
|
||||
### 2. Discover Content
|
||||
|
||||
Ask only the minimum needed:
|
||||
- purpose: pitch, teaching, conference talk, internal update
|
||||
- length: short (5-10), medium (10-20), long (20+)
|
||||
- content state: finished copy, rough notes, topic only
|
||||
|
||||
If the user has content, ask them to paste it before styling.
|
||||
|
||||
### 3. Discover Style
|
||||
|
||||
Default to visual exploration.
|
||||
|
||||
If the user already knows the desired preset, skip previews and use it directly.
|
||||
|
||||
Otherwise:
|
||||
1. Ask what feeling the deck should create: impressed, energized, focused, inspired.
|
||||
2. Generate **3 single-slide preview files** in `.ecc-design/slide-previews/`.
|
||||
3. Each preview must be self-contained, show typography/color/motion clearly, and stay under roughly 100 lines of slide content.
|
||||
4. Ask the user which preview to keep or what elements to mix.
|
||||
|
||||
Use the preset guide in `STYLE_PRESETS.md` when mapping mood to style.
|
||||
|
||||
### 4. Build the Presentation
|
||||
|
||||
Output either:
|
||||
- `presentation.html`
|
||||
- `[presentation-name].html`
|
||||
|
||||
Use an `assets/` folder only when the deck contains extracted or user-supplied images.
|
||||
|
||||
Required structure:
|
||||
- semantic slide sections
|
||||
- a viewport-safe CSS base from `STYLE_PRESETS.md`
|
||||
- CSS custom properties for theme values
|
||||
- a presentation controller class for keyboard, wheel, and touch navigation
|
||||
- Intersection Observer for reveal animations
|
||||
- reduced-motion support
|
||||
|
||||
### 5. Enforce Viewport Fit
|
||||
|
||||
Treat this as a hard gate.
|
||||
|
||||
Rules:
|
||||
- every `.slide` must use `height: 100vh; height: 100dvh; overflow: hidden;`
|
||||
- all type and spacing must scale with `clamp()`
|
||||
- when content does not fit, split into multiple slides
|
||||
- never solve overflow by shrinking text below readable sizes
|
||||
- never allow scrollbars inside a slide
|
||||
|
||||
Use the density limits and mandatory CSS block in `STYLE_PRESETS.md`.
|
||||
|
||||
### 6. Validate
|
||||
|
||||
Check the finished deck at these sizes:
|
||||
- 1920x1080
|
||||
- 1280x720
|
||||
- 768x1024
|
||||
- 375x667
|
||||
- 667x375
|
||||
|
||||
If browser automation is available, use it to verify no slide overflows and that keyboard navigation works.
|
||||
|
||||
### 7. Deliver
|
||||
|
||||
At handoff:
|
||||
- delete temporary preview files unless the user wants to keep them
|
||||
- open the deck with the platform-appropriate opener when useful
|
||||
- summarize file path, preset used, slide count, and easy theme customization points
|
||||
|
||||
Use the correct opener for the current OS:
|
||||
- macOS: `open file.html`
|
||||
- Linux: `xdg-open file.html`
|
||||
- Windows: `start "" file.html`
|
||||
|
||||
## PPT / PPTX Conversion
|
||||
|
||||
For PowerPoint conversion:
|
||||
1. Prefer `python3` with `python-pptx` to extract text, images, and notes.
|
||||
2. If `python-pptx` is unavailable, ask whether to install it or fall back to a manual/export-based workflow.
|
||||
3. Preserve slide order, speaker notes, and extracted assets.
|
||||
4. After extraction, run the same style-selection workflow as a new presentation.
|
||||
|
||||
Keep conversion cross-platform. Do not rely on macOS-only tools when Python can do the job.
|
||||
|
||||
## Implementation Requirements
|
||||
|
||||
### HTML / CSS
|
||||
|
||||
- Use inline CSS and JS unless the user explicitly wants a multi-file project.
|
||||
- Fonts may come from Google Fonts or Fontshare.
|
||||
- Prefer atmospheric backgrounds, strong type hierarchy, and a clear visual direction.
|
||||
- Use abstract shapes, gradients, grids, noise, and geometry rather than illustrations.
|
||||
|
||||
### JavaScript
|
||||
|
||||
Include:
|
||||
- keyboard navigation
|
||||
- touch / swipe navigation
|
||||
- mouse wheel navigation
|
||||
- progress indicator or slide index
|
||||
- reveal-on-enter animation triggers
|
||||
|
||||
### Accessibility
|
||||
|
||||
- use semantic structure (`main`, `section`, `nav`)
|
||||
- keep contrast readable
|
||||
- support keyboard-only navigation
|
||||
- respect `prefers-reduced-motion`
|
||||
|
||||
## Content Density Limits
|
||||
|
||||
Use these maxima unless the user explicitly asks for denser slides and readability still holds:
|
||||
|
||||
| Slide type | Limit |
|
||||
|------------|-------|
|
||||
| Title | 1 heading + 1 subtitle + optional tagline |
|
||||
| Content | 1 heading + 4-6 bullets or 2 short paragraphs |
|
||||
| Feature grid | 6 cards max |
|
||||
| Code | 8-10 lines max |
|
||||
| Quote | 1 quote + attribution |
|
||||
| Image | 1 image constrained by viewport |
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- generic startup gradients with no visual identity
|
||||
- system-font decks unless intentionally editorial
|
||||
- long bullet walls
|
||||
- code blocks that need scrolling
|
||||
- fixed-height content boxes that break on short screens
|
||||
- invalid negated CSS functions like `-clamp(...)`
|
||||
|
||||
## Related ECC Skills
|
||||
|
||||
- `frontend-patterns` for component and interaction patterns around the deck
|
||||
- `liquid-glass-design` when a presentation intentionally borrows Apple glass aesthetics
|
||||
- `e2e-testing` if you need automated browser verification for the final deck
|
||||
|
||||
## Deliverable Checklist
|
||||
|
||||
- presentation runs from a local file in a browser
|
||||
- every slide fits the viewport without scrolling
|
||||
- style is distinctive and intentional
|
||||
- animation is meaningful, not noisy
|
||||
- reduced motion is respected
|
||||
- file paths and customization points are explained at handoff
|
||||
330
skills/frontend-slides/STYLE_PRESETS.md
Normal file
330
skills/frontend-slides/STYLE_PRESETS.md
Normal file
@@ -0,0 +1,330 @@
|
||||
# Style Presets Reference
|
||||
|
||||
Curated visual styles for `frontend-slides`.
|
||||
|
||||
Use this file for:
|
||||
- the mandatory viewport-fitting CSS base
|
||||
- preset selection and mood mapping
|
||||
- CSS gotchas and validation rules
|
||||
|
||||
Abstract shapes only. Avoid illustrations unless the user explicitly asks for them.
|
||||
|
||||
## Viewport Fit Is Non-Negotiable
|
||||
|
||||
Every slide must fully fit in one viewport.
|
||||
|
||||
### Golden Rule
|
||||
|
||||
```text
|
||||
Each slide = exactly one viewport height.
|
||||
Too much content = split into more slides.
|
||||
Never scroll inside a slide.
|
||||
```
|
||||
|
||||
### Density Limits
|
||||
|
||||
| Slide Type | Maximum Content |
|
||||
|------------|-----------------|
|
||||
| Title slide | 1 heading + 1 subtitle + optional tagline |
|
||||
| Content slide | 1 heading + 4-6 bullets or 2 paragraphs |
|
||||
| Feature grid | 6 cards maximum |
|
||||
| Code slide | 8-10 lines maximum |
|
||||
| Quote slide | 1 quote + attribution |
|
||||
| Image slide | 1 image, ideally under 60vh |
|
||||
|
||||
## Mandatory Base CSS
|
||||
|
||||
Copy this block into every generated presentation and then theme on top of it.
|
||||
|
||||
```css
|
||||
/* ===========================================
|
||||
VIEWPORT FITTING: MANDATORY BASE STYLES
|
||||
=========================================== */
|
||||
|
||||
html, body {
|
||||
height: 100%;
|
||||
overflow-x: hidden;
|
||||
}
|
||||
|
||||
html {
|
||||
scroll-snap-type: y mandatory;
|
||||
scroll-behavior: smooth;
|
||||
}
|
||||
|
||||
.slide {
|
||||
width: 100vw;
|
||||
height: 100vh;
|
||||
height: 100dvh;
|
||||
overflow: hidden;
|
||||
scroll-snap-align: start;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
position: relative;
|
||||
}
|
||||
|
||||
.slide-content {
|
||||
flex: 1;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
justify-content: center;
|
||||
max-height: 100%;
|
||||
overflow: hidden;
|
||||
padding: var(--slide-padding);
|
||||
}
|
||||
|
||||
:root {
|
||||
--title-size: clamp(1.5rem, 5vw, 4rem);
|
||||
--h2-size: clamp(1.25rem, 3.5vw, 2.5rem);
|
||||
--h3-size: clamp(1rem, 2.5vw, 1.75rem);
|
||||
--body-size: clamp(0.75rem, 1.5vw, 1.125rem);
|
||||
--small-size: clamp(0.65rem, 1vw, 0.875rem);
|
||||
|
||||
--slide-padding: clamp(1rem, 4vw, 4rem);
|
||||
--content-gap: clamp(0.5rem, 2vw, 2rem);
|
||||
--element-gap: clamp(0.25rem, 1vw, 1rem);
|
||||
}
|
||||
|
||||
.card, .container, .content-box {
|
||||
max-width: min(90vw, 1000px);
|
||||
max-height: min(80vh, 700px);
|
||||
}
|
||||
|
||||
.feature-list, .bullet-list {
|
||||
gap: clamp(0.4rem, 1vh, 1rem);
|
||||
}
|
||||
|
||||
.feature-list li, .bullet-list li {
|
||||
font-size: var(--body-size);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(min(100%, 250px), 1fr));
|
||||
gap: clamp(0.5rem, 1.5vw, 1rem);
|
||||
}
|
||||
|
||||
img, .image-container {
|
||||
max-width: 100%;
|
||||
max-height: min(50vh, 400px);
|
||||
object-fit: contain;
|
||||
}
|
||||
|
||||
@media (max-height: 700px) {
|
||||
:root {
|
||||
--slide-padding: clamp(0.75rem, 3vw, 2rem);
|
||||
--content-gap: clamp(0.4rem, 1.5vw, 1rem);
|
||||
--title-size: clamp(1.25rem, 4.5vw, 2.5rem);
|
||||
--h2-size: clamp(1rem, 3vw, 1.75rem);
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-height: 600px) {
|
||||
:root {
|
||||
--slide-padding: clamp(0.5rem, 2.5vw, 1.5rem);
|
||||
--content-gap: clamp(0.3rem, 1vw, 0.75rem);
|
||||
--title-size: clamp(1.1rem, 4vw, 2rem);
|
||||
--body-size: clamp(0.7rem, 1.2vw, 0.95rem);
|
||||
}
|
||||
|
||||
.nav-dots, .keyboard-hint, .decorative {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-height: 500px) {
|
||||
:root {
|
||||
--slide-padding: clamp(0.4rem, 2vw, 1rem);
|
||||
--title-size: clamp(1rem, 3.5vw, 1.5rem);
|
||||
--h2-size: clamp(0.9rem, 2.5vw, 1.25rem);
|
||||
--body-size: clamp(0.65rem, 1vw, 0.85rem);
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-width: 600px) {
|
||||
:root {
|
||||
--title-size: clamp(1.25rem, 7vw, 2.5rem);
|
||||
}
|
||||
|
||||
.grid {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
}
|
||||
|
||||
@media (prefers-reduced-motion: reduce) {
|
||||
*, *::before, *::after {
|
||||
animation-duration: 0.01ms !important;
|
||||
transition-duration: 0.2s !important;
|
||||
}
|
||||
|
||||
html {
|
||||
scroll-behavior: auto;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Viewport Checklist
|
||||
|
||||
- every `.slide` has `height: 100vh`, `height: 100dvh`, and `overflow: hidden`
|
||||
- all typography uses `clamp()`
|
||||
- all spacing uses `clamp()` or viewport units
|
||||
- images have `max-height` constraints
|
||||
- grids adapt with `auto-fit` + `minmax()`
|
||||
- short-height breakpoints exist at `700px`, `600px`, and `500px`
|
||||
- if anything feels cramped, split the slide
|
||||
|
||||
## Mood to Preset Mapping
|
||||
|
||||
| Mood | Good Presets |
|
||||
|------|--------------|
|
||||
| Impressed / Confident | Bold Signal, Electric Studio, Dark Botanical |
|
||||
| Excited / Energized | Creative Voltage, Neon Cyber, Split Pastel |
|
||||
| Calm / Focused | Notebook Tabs, Paper & Ink, Swiss Modern |
|
||||
| Inspired / Moved | Dark Botanical, Vintage Editorial, Pastel Geometry |
|
||||
|
||||
## Preset Catalog
|
||||
|
||||
### 1. Bold Signal
|
||||
|
||||
- Vibe: confident, high-impact, keynote-ready
|
||||
- Best for: pitch decks, launches, statements
|
||||
- Fonts: Archivo Black + Space Grotesk
|
||||
- Palette: charcoal base, hot orange focal card, crisp white text
|
||||
- Signature: oversized section numbers, high-contrast card on dark field
|
||||
|
||||
### 2. Electric Studio
|
||||
|
||||
- Vibe: clean, bold, agency-polished
|
||||
- Best for: client presentations, strategic reviews
|
||||
- Fonts: Manrope only
|
||||
- Palette: black, white, saturated cobalt accent
|
||||
- Signature: two-panel split and sharp editorial alignment
|
||||
|
||||
### 3. Creative Voltage
|
||||
|
||||
- Vibe: energetic, retro-modern, playful confidence
|
||||
- Best for: creative studios, brand work, product storytelling
|
||||
- Fonts: Syne + Space Mono
|
||||
- Palette: electric blue, neon yellow, deep navy
|
||||
- Signature: halftone textures, badges, punchy contrast
|
||||
|
||||
### 4. Dark Botanical
|
||||
|
||||
- Vibe: elegant, premium, atmospheric
|
||||
- Best for: luxury brands, thoughtful narratives, premium product decks
|
||||
- Fonts: Cormorant + IBM Plex Sans
|
||||
- Palette: near-black, warm ivory, blush, gold, terracotta
|
||||
- Signature: blurred abstract circles, fine rules, restrained motion
|
||||
|
||||
### 5. Notebook Tabs
|
||||
|
||||
- Vibe: editorial, organized, tactile
|
||||
- Best for: reports, reviews, structured storytelling
|
||||
- Fonts: Bodoni Moda + DM Sans
|
||||
- Palette: cream paper on charcoal with pastel tabs
|
||||
- Signature: paper sheet, colored side tabs, binder details
|
||||
|
||||
### 6. Pastel Geometry
|
||||
|
||||
- Vibe: approachable, modern, friendly
|
||||
- Best for: product overviews, onboarding, lighter brand decks
|
||||
- Fonts: Plus Jakarta Sans only
|
||||
- Palette: pale blue field, cream card, soft pink/mint/lavender accents
|
||||
- Signature: vertical pills, rounded cards, soft shadows
|
||||
|
||||
### 7. Split Pastel
|
||||
|
||||
- Vibe: playful, modern, creative
|
||||
- Best for: agency intros, workshops, portfolios
|
||||
- Fonts: Outfit only
|
||||
- Palette: peach + lavender split with mint badges
|
||||
- Signature: split backdrop, rounded tags, light grid overlays
|
||||
|
||||
### 8. Vintage Editorial
|
||||
|
||||
- Vibe: witty, personality-driven, magazine-inspired
|
||||
- Best for: personal brands, opinionated talks, storytelling
|
||||
- Fonts: Fraunces + Work Sans
|
||||
- Palette: cream, charcoal, dusty warm accents
|
||||
- Signature: geometric accents, bordered callouts, punchy serif headlines
|
||||
|
||||
### 9. Neon Cyber
|
||||
|
||||
- Vibe: futuristic, techy, kinetic
|
||||
- Best for: AI, infra, dev tools, future-of-X talks
|
||||
- Fonts: Clash Display + Satoshi
|
||||
- Palette: midnight navy, cyan, magenta
|
||||
- Signature: glow, particles, grids, data-radar energy
|
||||
|
||||
### 10. Terminal Green
|
||||
|
||||
- Vibe: developer-focused, hacker-clean
|
||||
- Best for: APIs, CLI tools, engineering demos
|
||||
- Fonts: JetBrains Mono only
|
||||
- Palette: GitHub dark + terminal green
|
||||
- Signature: scan lines, command-line framing, precise monospace rhythm
|
||||
|
||||
### 11. Swiss Modern
|
||||
|
||||
- Vibe: minimal, precise, data-forward
|
||||
- Best for: corporate, product strategy, analytics
|
||||
- Fonts: Archivo + Nunito
|
||||
- Palette: white, black, signal red
|
||||
- Signature: visible grids, asymmetry, geometric discipline
|
||||
|
||||
### 12. Paper & Ink
|
||||
|
||||
- Vibe: literary, thoughtful, story-driven
|
||||
- Best for: essays, keynote narratives, manifesto decks
|
||||
- Fonts: Cormorant Garamond + Source Serif 4
|
||||
- Palette: warm cream, charcoal, crimson accent
|
||||
- Signature: pull quotes, drop caps, elegant rules
|
||||
|
||||
## Direct Selection Prompts
|
||||
|
||||
If the user already knows the style they want, let them pick directly from the preset names above instead of forcing preview generation.
|
||||
|
||||
## Animation Feel Mapping
|
||||
|
||||
| Feeling | Motion Direction |
|
||||
|---------|------------------|
|
||||
| Dramatic / Cinematic | slow fades, parallax, large scale-ins |
|
||||
| Techy / Futuristic | glow, particles, grid motion, scramble text |
|
||||
| Playful / Friendly | springy easing, rounded shapes, floating motion |
|
||||
| Professional / Corporate | subtle 200-300ms transitions, clean slides |
|
||||
| Calm / Minimal | very restrained movement, whitespace-first |
|
||||
| Editorial / Magazine | strong hierarchy, staggered text and image interplay |
|
||||
|
||||
## CSS Gotcha: Negating Functions
|
||||
|
||||
Never write these:
|
||||
|
||||
```css
|
||||
right: -clamp(28px, 3.5vw, 44px);
|
||||
margin-left: -min(10vw, 100px);
|
||||
```
|
||||
|
||||
Browsers ignore them silently.
|
||||
|
||||
Always write this instead:
|
||||
|
||||
```css
|
||||
right: calc(-1 * clamp(28px, 3.5vw, 44px));
|
||||
margin-left: calc(-1 * min(10vw, 100px));
|
||||
```
|
||||
|
||||
## Validation Sizes
|
||||
|
||||
Test at minimum:
|
||||
- Desktop: `1920x1080`, `1440x900`, `1280x720`
|
||||
- Tablet: `1024x768`, `768x1024`
|
||||
- Mobile: `375x667`, `414x896`
|
||||
- Landscape phone: `667x375`, `896x414`
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
Do not use:
|
||||
- purple-on-white startup templates
|
||||
- Inter / Roboto / Arial as the visual voice unless the user explicitly wants utilitarian neutrality
|
||||
- bullet walls, tiny type, or code blocks that require scrolling
|
||||
- decorative illustrations when abstract geometry would do the job better
|
||||
96
skills/investor-materials/SKILL.md
Normal file
96
skills/investor-materials/SKILL.md
Normal file
@@ -0,0 +1,96 @@
|
||||
---
|
||||
name: investor-materials
|
||||
description: Create and update pitch decks, one-pagers, investor memos, accelerator applications, financial models, and fundraising materials. Use when the user needs investor-facing documents, projections, use-of-funds tables, milestone plans, or materials that must stay internally consistent across multiple fundraising assets.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Investor Materials
|
||||
|
||||
Build investor-facing materials that are consistent, credible, and easy to defend.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- creating or revising a pitch deck
|
||||
- writing an investor memo or one-pager
|
||||
- building a financial model, milestone plan, or use-of-funds table
|
||||
- answering accelerator or incubator application questions
|
||||
- aligning multiple fundraising docs around one source of truth
|
||||
|
||||
## Golden Rule
|
||||
|
||||
All investor materials must agree with each other.
|
||||
|
||||
Create or confirm a single source of truth before writing:
|
||||
- traction metrics
|
||||
- pricing and revenue assumptions
|
||||
- raise size and instrument
|
||||
- use of funds
|
||||
- team bios and titles
|
||||
- milestones and timelines
|
||||
|
||||
If conflicting numbers appear, stop and resolve them before drafting.
|
||||
|
||||
## Core Workflow
|
||||
|
||||
1. inventory the canonical facts
|
||||
2. identify missing assumptions
|
||||
3. choose the asset type
|
||||
4. draft the asset with explicit logic
|
||||
5. cross-check every number against the source of truth
|
||||
|
||||
## Asset Guidance
|
||||
|
||||
### Pitch Deck
|
||||
Recommended flow:
|
||||
1. company + wedge
|
||||
2. problem
|
||||
3. solution
|
||||
4. product / demo
|
||||
5. market
|
||||
6. business model
|
||||
7. traction
|
||||
8. team
|
||||
9. competition / differentiation
|
||||
10. ask
|
||||
11. use of funds / milestones
|
||||
12. appendix
|
||||
|
||||
If the user wants a web-native deck, pair this skill with `frontend-slides`.
|
||||
|
||||
### One-Pager / Memo
|
||||
- state what the company does in one clean sentence
|
||||
- show why now
|
||||
- include traction and proof points early
|
||||
- make the ask precise
|
||||
- keep claims easy to verify
|
||||
|
||||
### Financial Model
|
||||
Include:
|
||||
- explicit assumptions
|
||||
- bear / base / bull cases when useful
|
||||
- clean layer-by-layer revenue logic
|
||||
- milestone-linked spending
|
||||
- sensitivity analysis where the decision hinges on assumptions
|
||||
|
||||
### Accelerator Applications
|
||||
- answer the exact question asked
|
||||
- prioritize traction, insight, and team advantage
|
||||
- avoid puffery
|
||||
- keep internal metrics consistent with the deck and model
|
||||
|
||||
## Red Flags to Avoid
|
||||
|
||||
- unverifiable claims
|
||||
- fuzzy market sizing without assumptions
|
||||
- inconsistent team roles or titles
|
||||
- revenue math that does not sum cleanly
|
||||
- inflated certainty where assumptions are fragile
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- every number matches the current source of truth
|
||||
- use of funds and revenue layers sum correctly
|
||||
- assumptions are visible, not buried
|
||||
- the story is clear without hype language
|
||||
- the final asset is defensible in a partner meeting
|
||||
76
skills/investor-outreach/SKILL.md
Normal file
76
skills/investor-outreach/SKILL.md
Normal file
@@ -0,0 +1,76 @@
|
||||
---
|
||||
name: investor-outreach
|
||||
description: Draft cold emails, warm intro blurbs, follow-ups, update emails, and investor communications for fundraising. Use when the user wants outreach to angels, VCs, strategic investors, or accelerators and needs concise, personalized, investor-facing messaging.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Investor Outreach
|
||||
|
||||
Write investor communication that is short, personalized, and easy to act on.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- writing a cold email to an investor
|
||||
- drafting a warm intro request
|
||||
- sending follow-ups after a meeting or no response
|
||||
- writing investor updates during a process
|
||||
- tailoring outreach based on fund thesis or partner fit
|
||||
|
||||
## Core Rules
|
||||
|
||||
1. Personalize every outbound message.
|
||||
2. Keep the ask low-friction.
|
||||
3. Use proof, not adjectives.
|
||||
4. Stay concise.
|
||||
5. Never send generic copy that could go to any investor.
|
||||
|
||||
## 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
|
||||
4. ask: one concrete next step
|
||||
5. sign-off: name, role, one credibility anchor if needed
|
||||
|
||||
## Personalization Sources
|
||||
|
||||
Reference one or more of:
|
||||
- relevant portfolio companies
|
||||
- a public thesis, talk, post, or article
|
||||
- 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.
|
||||
|
||||
## 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
|
||||
|
||||
Do not keep nudging after that unless the user wants a longer sequence.
|
||||
|
||||
## Warm Intro Requests
|
||||
|
||||
Make life easy for the connector:
|
||||
- explain why the intro is a fit
|
||||
- include a forwardable blurb
|
||||
- keep the forwardable blurb under 100 words
|
||||
|
||||
## Post-Meeting Updates
|
||||
|
||||
Include:
|
||||
- the specific thing discussed
|
||||
- the answer or update promised
|
||||
- one new proof point if available
|
||||
- the next step
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- message is personalized
|
||||
- the ask is explicit
|
||||
- there is no fluff or begging language
|
||||
- the proof point is concrete
|
||||
- word count stays tight
|
||||
75
skills/market-research/SKILL.md
Normal file
75
skills/market-research/SKILL.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
name: market-research
|
||||
description: Conduct market research, competitive analysis, investor due diligence, and industry intelligence with source attribution and decision-oriented summaries. Use when the user wants market sizing, competitor comparisons, fund research, technology scans, or research that informs business decisions.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Market Research
|
||||
|
||||
Produce research that supports decisions, not research theater.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- researching a market, category, company, investor, or technology trend
|
||||
- building TAM/SAM/SOM estimates
|
||||
- comparing competitors or adjacent products
|
||||
- preparing investor dossiers before outreach
|
||||
- pressure-testing a thesis before building, funding, or entering a market
|
||||
|
||||
## Research Standards
|
||||
|
||||
1. Every important claim needs a source.
|
||||
2. Prefer recent data and call out stale data.
|
||||
3. Include contrarian evidence and downside cases.
|
||||
4. Translate findings into a decision, not just a summary.
|
||||
5. Separate fact, inference, and recommendation clearly.
|
||||
|
||||
## Common Research Modes
|
||||
|
||||
### Investor / Fund Diligence
|
||||
Collect:
|
||||
- fund size, stage, and typical check size
|
||||
- relevant portfolio companies
|
||||
- public thesis and recent activity
|
||||
- reasons the fund is or is not a fit
|
||||
- any obvious red flags or mismatches
|
||||
|
||||
### Competitive Analysis
|
||||
Collect:
|
||||
- product reality, not marketing copy
|
||||
- funding and investor history if public
|
||||
- traction metrics if public
|
||||
- distribution and pricing clues
|
||||
- strengths, weaknesses, and positioning gaps
|
||||
|
||||
### Market Sizing
|
||||
Use:
|
||||
- top-down estimates from reports or public datasets
|
||||
- bottom-up sanity checks from realistic customer acquisition assumptions
|
||||
- explicit assumptions for every leap in logic
|
||||
|
||||
### Technology / Vendor Research
|
||||
Collect:
|
||||
- how it works
|
||||
- trade-offs and adoption signals
|
||||
- integration complexity
|
||||
- lock-in, security, compliance, and operational risk
|
||||
|
||||
## Output Format
|
||||
|
||||
Default structure:
|
||||
1. executive summary
|
||||
2. key findings
|
||||
3. implications
|
||||
4. risks and caveats
|
||||
5. recommendation
|
||||
6. sources
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
- all numbers are sourced or labeled as estimates
|
||||
- old data is flagged
|
||||
- the recommendation follows from the evidence
|
||||
- risks and counterarguments are included
|
||||
- the output makes a decision easier
|
||||
Reference in New Issue
Block a user