mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-13 21:33:32 +08:00
Ports functionality from 10+ separate plugins into ECC so users only need one plugin installed. Consolidates: pr-review-toolkit, feature-dev, commit-commands, hookify, code-simplifier, security-guidance, frontend-design, explanatory-output-style, and personal skills. New agents (8): code-architect, code-explorer, code-simplifier, comment-analyzer, conversation-analyzer, pr-test-analyzer, silent-failure-hunter, type-design-analyzer New commands (9): commit, commit-push-pr, clean-gone, review-pr, feature-dev, hookify, hookify-list, hookify-configure, hookify-help New skills (8): frontend-design, hookify-rules, github-ops, knowledge-ops, lead-intelligence, oura-health, pmx-guidelines, remotion Enhanced skills (8): article-writing, content-engine, market-research, investor-materials, investor-outreach, x-api, security-scan, autonomous-loops — merged with personal skill content New hook: security-reminder.py (pattern-based OWASP vulnerability warnings on file edits) Totals: 36 agents, 69 commands, 128 skills, 29 hook scripts
147 lines
5.2 KiB
Markdown
147 lines
5.2 KiB
Markdown
---
|
|
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
|
|
|
|
## Tone Calibration
|
|
|
|
Match tone to context:
|
|
|
|
| Context | Tone |
|
|
|---------|------|
|
|
| Technical content | Direct, opinionated, practical. Share what works from experience. |
|
|
| Personal/journey | Honest, reflective. No performative humility, no toxic positivity. |
|
|
| Security content | Urgent but not alarmist. Evidence-based. Show the vulnerability, then the fix. |
|
|
| Community updates | Grateful but not sycophantic. Numbers speak louder than adjectives. |
|
|
| Product launches | Matter-of-fact. Let features speak. No hype language. |
|
|
|
|
## Approved Voice Patterns
|
|
|
|
These patterns work well for developer and founder audiences:
|
|
|
|
- "here's exactly how..."
|
|
- "no fluff."
|
|
- "zero [X]. just [Y]."
|
|
- "the short version:"
|
|
- Direct address: "you want X. here's X."
|
|
- Parenthetical asides for personality and self-awareness (use roughly once every 2-3 paragraphs)
|
|
|
|
## Platform-Specific Structure
|
|
|
|
### Technical Guides
|
|
- open with what the reader gets
|
|
- use code or terminal examples in every major section
|
|
- use "Pro tip:" callouts for non-obvious insights
|
|
- end with concrete takeaways as short bullets, not a summary paragraph
|
|
- link to resources at the bottom
|
|
|
|
### 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
|
|
|
|
### LinkedIn
|
|
- proper capitalization
|
|
- short paragraphs (2-3 sentences max)
|
|
- first line is the hook (truncates at ~210 chars)
|
|
- professional framing: impact, lessons, takeaways
|
|
- 3-5 hashtags at the bottom only
|
|
|
|
### X/Twitter Threads
|
|
- each tweet must standalone (people see them individually)
|
|
- hook in first tweet, no "thread:" or "1/" prefix
|
|
- one point per tweet
|
|
- last tweet: CTA or punchline, not "follow for more"
|
|
- 4-7 tweets ideal length
|
|
- no links in tweet body (kills reach). Links in first reply.
|
|
|
|
## 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
|
|
- zero banned patterns in entire document
|
|
- at least 2-3 parenthetical asides for personality (if voice calls for it)
|
|
- examples/evidence before explanation in each section
|
|
- specific numbers used where available
|