메뉴
Condenses long articles, threads, or documents into concise, engaging newsletter-ready summaries.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Runs a systematic checklist review on any code diff or file, covering correctness, security, performance, and readability.
Writes a high-quality CLAUDE.md, .cursorrules, or .windsurfrules file that gives a coding agent the right project context, conventions, and constraints to work effectively.
Designs an eval suite for an LLM agent or pipeline including success metrics, trajectory scoring, LLM-as-judge setup, and regression test cases.
Designs a hybrid retrieval pipeline combining dense vector search and BM25 sparse search with reciprocal rank fusion, and explains when to use each configuration.
Converts a workflow description into a LangGraph node/edge graph with typed state, conditional routing, and human-in-the-loop checkpoints.
Audits an AI application for unnecessary token spend and recommends prompt caching, model routing, and token reduction techniques to cut costs.
| name | Newsletter Summary Writer |
| description | Condenses long articles, threads, or documents into concise, engaging newsletter-ready summaries. |
| category | writing |
| tags | ["newsletter","writing","summarization","content"] |
| author | simplyutils |
This skill takes any source content — a long article, a Twitter/X thread, a research paper, a podcast transcript, a blog post, or a document — and condenses it into a polished, newsletter-ready summary under 200 words. The output includes a punchy hook, scannable key takeaways, and a "Why it matters" closing line that gives readers a reason to care.
Use this when curating content for a weekly newsletter, a team digest, a Slack summary post, or any context where you need to surface the key ideas from something long without making people read the whole thing.
Copy this file to .agents/skills/newsletter-summary-writer/SKILL.md in your project root.
Then paste the source content and ask:
You can also specify tone (casual, professional, technical) and the newsletter's audience if you want the output tailored.
Add the "Prompt / Instructions" section to your .cursorrules file. Paste the source content into the chat and ask for a newsletter summary.
Paste the full source content (or a URL if Codex can access it) along with the instructions below. Specify word count if you need something shorter or longer than the 200-word default.
When asked to write a newsletter summary, follow these steps:
Read the full source content. Do not skim — identify:
Extract 3–5 key takeaways. Each takeaway must:
Write a 2–3 sentence hook. The hook should:
Write a "Why it matters" line (1 sentence):
Assemble the summary:
Check total length. The default target is under 200 words. If the user specifies a different length, honor it. Cut from the takeaways first, then tighten the hook.
Match the tone to the audience:
Output format:
[Hook paragraph — 2–3 sentences]
**Key takeaways:**
- [Takeaway 1]
- [Takeaway 2]
- [Takeaway 3]
- [Takeaway 4 — if applicable]
- [Takeaway 5 — if applicable]
**Why it matters:** [One sentence]
Do not add a title, author name, or source link — the newsletter curator will add those. Just output the summary block.
Input to Agent:
"Use the Newsletter Summary Writer skill on this article. Audience: software engineering managers.
[Long article about a study showing that developers who write tests first (TDD) ship 40% fewer bugs in production but take 15–35% longer in the short term, with the time cost disappearing after 6 months as the codebase matures. The study tracked 24 teams over 18 months. Teams using TDD had significantly lower onboarding time for new engineers and reported higher code confidence. The main barrier to adoption was manager pressure to ship fast in early sprints.]"
Output from Agent:
A new 18-month study of 24 software teams just put a number on the TDD debate: 40% fewer production bugs, at a short-term cost of 15–35% slower delivery. The catch? That speed penalty disappears entirely after about 6 months — and your new engineers will thank you for it.
Key takeaways:
- Teams practicing TDD shipped 40% fewer production bugs over the 18-month study period
- The short-term speed cost (15–35% slower) fully recovered within 6 months as the codebase matured
- TDD teams had measurably faster onboarding for new engineers due to better-documented behavior
- Developer confidence in making changes was significantly higher on TDD teams
- The biggest barrier to adoption was manager pressure to ship fast in early sprints — not developer resistance
Why it matters: If you're managing a team building something that will still exist in a year, the data now suggests TDD is a performance investment, not a slowdown — but only if you protect the first 6 months.