使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/affaan-m/ecc --skill article-writing開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
Article Writing
Write long-form content that sounds like an actual person with a point of view, not an LLM smoothing itself into paste.
When to Activate
- 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
- Lead with the concrete thing: artifact, example, output, anecdote, number, screenshot, or code.
- Explain after the example, not before.
- Keep sentences tight unless the source voice is intentionally expansive.
- Use proof instead of adjectives.
- Never invent facts, credibility, or customer evidence.
Voice Handling
If the user wants a specific voice, run brand-voice first and reuse its VOICE PROFILE. Do not duplicate a second style-analysis pass here unless the user explicitly asks for one.
If no voice references are given, default to a sharp operator voice: concrete, unsentimental, useful.
Banned Patterns
Delete and rewrite any of these:
- "In today's rapidly evolving landscape"
- "game-changer", "cutting-edge", "revolutionary"
- "here's why this matters" as a standalone bridge
- fake vulnerability arcs
- a closing question added only to juice engagement
- biography padding that does not move the argument
- generic AI throat-clearing that delays the point
Writing Process
- Clarify the audience and purpose.
- Build a hard outline with one job per section.
- Start sections with proof, artifact, conflict, or example.
- Expand only where the next sentence earns space.
- Cut anything that sounds templated, overexplained, or self-congratulatory.
Structure Guidance
Technical Guides
- open with what the reader gets
- use code, commands, screenshots, or concrete output in major sections
- end with actionable takeaways, not a soft recap
Essays / Opinion
- start with tension, contradiction, or a specific observation
- keep one argument thread per section
- make opinions answer to evidence
Newsletters
- keep the first screen doing real work
- do not front-load diary filler
- use section labels only when they improve scanability
Quality Gate
Before delivering:
- factual claims are backed by provided sources
- generic AI transitions are gone
- the voice matches the supplied examples or the agreed
VOICE PROFILE - every section adds something new
- formatting matches the intended medium
