@botlearn/writer 0.1.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 BotLearn
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,35 @@
+# @botlearn/writer
+
+> Structured article writing with evidence-based argumentation, consistent style, and quality improvement of 60% for OpenClaw Agent
+
+## Installation
+
+```bash
+# via npm
+npm install @botlearn/writer
+
+# via clawhub
+clawhub install @botlearn/writer
+```
+
+## Category
+
+Creative Generation
+
+## Dependencies
+
+`@botlearn/summarizer`, `@botlearn/keyword-extractor`
+
+## Files
+
+| File | Description |
+|------|-------------|
+| `manifest.json` | Skill metadata and configuration |
+| `skill.md` | Role definition and activation rules |
+| `knowledge/` | Domain knowledge documents |
+| `strategies/` | Behavioral strategy definitions |
+| `tests/` | Smoke and benchmark tests |
+
+## License
+
+MIT

package/knowledge/anti-patterns.md

@@ -0,0 +1,102 @@
+---
+domain: writer
+topic: anti-patterns
+priority: medium
+ttl: 30d
+---
+
+# Article Writing — Anti-Patterns
+
+## Thesis Anti-Patterns
+
+### 1. Weak or Missing Thesis
+- **Problem**: The article lacks a clear central argument; the reader finishes without knowing what the article was trying to prove or communicate
+- **Symptoms**: No single sentence can be identified as the thesis; the article reads as a collection of loosely related observations
+- **Fix**: Before drafting, write a one-sentence answer to "What is this article arguing?" Place it in the first two paragraphs. Every subsequent paragraph should trace back to this sentence
+
+### 2. Overly Broad Thesis
+- **Problem**: The thesis attempts to cover too much ground, making it impossible to adequately support with evidence within the article's scope
+- **Symptoms**: Phrases like "Technology is transforming everything," "There are many benefits to X," or "The world is changing rapidly"
+- **Fix**: Add qualifiers to narrow the scope — specify who, what, when, where, and under what conditions. "AI is transforming healthcare" becomes "AI-powered diagnostic tools have reduced misdiagnosis rates in radiology departments by 23% since 2022"
+
+### 3. Unfalsifiable Thesis
+- **Problem**: The thesis is so obvious or vague that no reasonable person would disagree, making the article pointless
+- **Symptoms**: "Good communication is important in business," "Cybersecurity is a growing concern"
+- **Fix**: Strengthen the claim by adding a specific position, a causal mechanism, or a contested recommendation. The thesis should provoke thought, not nods
+
+### 4. Moving Thesis
+- **Problem**: The thesis shifts mid-article as the writer discovers new points during drafting, resulting in an article that argues one thing in the introduction and a different thing in the conclusion
+- **Fix**: After completing a first draft, compare the introduction and conclusion. If they argue different things, choose one thesis and revise the entire article to align with it
+
+## Evidence Anti-Patterns
+
+### 5. Unsupported Claims
+- **Problem**: Assertions are made without any supporting evidence — the writer expects the reader to take the claim on faith
+- **Symptoms**: "It's widely known that..." "Everyone agrees that..." "Obviously..." or simply stating opinions as if they were facts
+- **Fix**: For every claim, ask: "How do I know this? What would I cite?" If there is no answer, either find evidence or remove the claim
+
+### 6. Evidence Without Analysis
+- **Problem**: Data, quotes, or examples are dropped into the article without explanation of what they mean or how they support the argument
+- **Symptoms**: A paragraph that is just a block quote followed by another quote; a statistic stated with no interpretation
+- **Fix**: Apply the PEEL structure — after every piece of evidence, include 1-2 sentences explaining its significance and connecting it to the argument
+
+### 7. Cherry-Picked Evidence
+- **Problem**: The writer selects only evidence that supports their thesis while ignoring contradicting data, undermining credibility
+- **Symptoms**: All statistics trend in the same direction; no counterarguments acknowledged; suspiciously clean narrative
+- **Fix**: Actively seek and address counterevidence. Acknowledge limitations. Use the Rogerian approach: present the opposing view fairly, then explain why your position still holds
+
+### 8. Outdated Evidence
+- **Problem**: Using data or citations that are no longer current for rapidly evolving topics
+- **Symptoms**: Citing a 2018 study about AI capabilities, referencing deprecated technology, using pre-pandemic data for workforce trends
+- **Fix**: For technology and current affairs, evidence should be less than 2 years old. For established science or history, older sources are acceptable. Always note the publication date
+
+### 9. Over-Reliance on a Single Source
+- **Problem**: The entire article's evidence base draws from one study, one author, or one organization
+- **Symptoms**: The same citation appears in every argument block; all expert quotes come from one person
+- **Fix**: Use a minimum of 3-5 independent sources per article. Cross-reference key claims across multiple sources. Diversify evidence types (statistics, expert opinion, case studies)
+
+### 10. Appeal to Authority Without Verification
+- **Problem**: Citing an "expert" without verifying their credentials or relevance to the specific topic
+- **Symptoms**: "A Harvard professor says..." without specifying their field; quoting a tech CEO on medical topics
+- **Fix**: Verify that the expert's credentials are relevant to the specific claim being made. Include their specific role, institution, and relevant qualification
+
+## Tone & Style Anti-Patterns
+
+### 11. Tone Inconsistency
+- **Problem**: The article shifts between formal and informal, professional and casual, creating a disjointed reading experience that undermines credibility
+- **Symptoms**: An opening like "Let's dive into the fascinating world of quantum computing" followed by "The superposition principle posits that quantum bits exist in a probabilistic state vector space"
+- **Fix**: Decide on a single tone before writing (see knowledge/best-practices.md tone framework). Read the full article aloud — tonal shifts become obvious when heard
+
+### 12. Register Mismatch
+- **Problem**: The vocabulary and complexity level don't match the target audience
+- **Symptoms**: Using "synergize cross-functional paradigms" for a general audience; using "cool stuff" in a white paper
+- **Fix**: Define the target audience explicitly before writing. Use the vocabulary level guidelines from knowledge/best-practices.md. Have someone from the target audience review if possible
+
+### 13. Passive Voice Overuse
+- **Problem**: Excessive passive voice makes the writing feel impersonal, weak, and harder to read
+- **Symptoms**: "It was determined that..." "The results were analyzed..." "The decision was made by the committee..."
+- **Fix**: Target 80%+ active voice. Convert: "The results were analyzed by the team" to "The team analyzed the results." Reserve passive voice for when the actor is unknown or deliberately de-emphasized
+
+### 14. Filler and Hedge Overload
+- **Problem**: Excessive hedging language weakens every claim; filler words add length without substance
+- **Symptoms**: "It could perhaps be argued that there may be some potential benefits..." "Basically, it's really quite interesting that..."
+- **Fix**: Remove hedge words on first edit pass. If a claim needs qualification, use a single precise qualifier: "In most enterprise contexts" rather than "It could potentially be the case that in some situations"
+
+## Structural Anti-Patterns
+
+### 15. Wall of Text
+- **Problem**: Long, unbroken blocks of text with no subheadings, bullet points, or visual breaks
+- **Fix**: Break content into scannable sections. Use subheadings every 200-300 words. Use lists for 3+ parallel items. Keep digital paragraphs to 3-6 sentences
+
+### 16. Burying the Lead
+- **Problem**: The most important or interesting information appears deep in the article instead of near the top
+- **Fix**: Apply the inverted pyramid test even for non-news articles: could a reader stop at paragraph 3 and still understand the core message? If not, restructure
+
+### 17. Weak Conclusion
+- **Problem**: The article ends with a vague summary or abruptly stops without synthesizing the arguments or providing forward-looking insight
+- **Symptoms**: "In conclusion, X is very important and we should all think about it more"
+- **Fix**: A strong conclusion should: (1) restate the thesis in light of the evidence presented, (2) synthesize the key arguments into a higher-order insight, and (3) provide a call to action, prediction, or open question for the reader
+
+### 18. Missing Transitions
+- **Problem**: Paragraphs and sections are placed adjacent to each other without logical connectors, forcing readers to infer the relationship
+- **Fix**: Every paragraph should begin with a connection to the previous one — either an explicit transition word or an echo of a key term from the prior paragraph

package/knowledge/best-practices.md

@@ -0,0 +1,120 @@
+---
+domain: writer
+topic: thesis-evidence-style-best-practices
+priority: high
+ttl: 30d
+---
+
+# Article Writing — Best Practices
+
+## Thesis Development
+
+### 1. Thesis Placement & Clarity
+- Place the thesis statement within the first two paragraphs — readers should never have to guess the article's central argument
+- A strong thesis is **specific**, **arguable**, and **scoped**: it makes a claim that can be supported with evidence and is narrow enough to be fully addressed in the article
+- Avoid thesis statements that are merely factual ("Python is a programming language") or too broad ("Technology is changing the world")
+
+### 2. Thesis Formulation Process
+1. **Start with a question** — What specific question does this article answer?
+2. **Draft a tentative claim** — What is your initial answer to that question?
+3. **Stress-test the claim** — Can reasonable people disagree? If not, it's not a thesis
+4. **Scope it down** — Add qualifiers to make it defensible: who, when, under what conditions
+5. **Refine for precision** — Remove vague language ("some," "many," "interesting")
+
+### 3. Thesis Types by Article Purpose
+
+| Article Purpose | Thesis Type | Example |
+|----------------|-------------|---------|
+| Persuasive | Value claim | "Companies should adopt four-day workweeks because the productivity and retention gains outweigh the scheduling costs" |
+| Analytical | Causal claim | "The rise of remote work has restructured urban real estate markets by shifting demand from commercial to residential space" |
+| Explanatory | Interpretive claim | "Kubernetes adoption follows a predictable maturity curve where organizations must pass through three distinct operational phases" |
+| Comparative | Evaluative claim | "For early-stage startups, serverless architecture offers better cost efficiency than container orchestration until reaching 10,000 daily active users" |
+
+### 4. Thesis-Argument Alignment
+- Every argument block in the article must directly advance the thesis
+- Map each argument to a specific aspect of the thesis before drafting
+- If an argument doesn't connect to the thesis, either revise the argument, revise the thesis, or remove the argument
+
+## Evidence Integration
+
+### 1. Evidence Selection Criteria
+- **Relevance** — Does the evidence directly support the specific claim being made?
+- **Recency** — Is the data current enough for the topic? (Technology: < 2 years; Social science: < 5 years; History: age is acceptable)
+- **Authority** — Is the source credible and recognized in the field?
+- **Representativeness** — Does the evidence reflect the broader reality, or is it an outlier?
+
+### 2. Evidence-to-Argument Ratio
+- Every claim should be supported by at least one piece of evidence
+- High-stakes claims (central to the thesis) need 2-3 supporting evidence items
+- Use different evidence types for the same claim when possible (e.g., a statistic + an expert quote)
+- The PEEL structure (Point-Evidence-Explain-Link) ensures every piece of evidence is analyzed, not just dropped in
+
+### 3. Evidence Introduction Patterns
+
+**Signal phrase (attribution first):**
+> According to a 2024 McKinsey report, organizations that adopted AI-assisted workflows saw a 40% reduction in repetitive task time.
+
+**Data-first (impact first):**
+> A 40% reduction in repetitive task time — that is the finding from McKinsey's 2024 survey of 500 enterprises that adopted AI-assisted workflows.
+
+**Contextual embedding (woven into narrative):**
+> When McKinsey surveyed 500 enterprises in 2024, the results surprised even optimists: AI-assisted workflows cut repetitive task time by 40%.
+
+### 4. Evidence Diversity Requirements
+- **Never rely on a single evidence type** — An article using only statistics lacks human connection; one using only anecdotes lacks rigor
+- Target a minimum of 3 evidence types per article:
+  - At least one quantitative source (statistics, data)
+  - At least one qualitative source (expert quote, case study)
+  - At least one reasoning element (logical argument, analogy)
+
+### 5. Source Attribution Standards
+- Always identify: **who** produced the evidence, **when**, and **in what context**
+- For statistics: include sample size and methodology when available
+- For quotes: include the person's relevant credentials or role
+- For studies: note if they are peer-reviewed, pre-print, or industry-commissioned
+
+## Style Consistency
+
+### 1. Tone Selection Framework
+
+| Audience | Context | Recommended Tone | Vocabulary Level |
+|----------|---------|-----------------|-----------------|
+| General public | Blog, magazine | Conversational, accessible | Common terms; explain jargon |
+| Industry professionals | Trade publication | Informed, collegial | Domain terms acceptable; minimal explanation |
+| Academic readers | Journal, research report | Formal, precise | Technical vocabulary expected |
+| Executive / Decision-maker | White paper, brief | Authoritative, concise | Business terms; focus on impact |
+| Developer / Technical | Technical blog, docs | Direct, practical | Code terms, specific tool names |
+
+### 2. Tone Consistency Rules
+- **Establish tone in the first paragraph** and maintain it throughout
+- If the opening is conversational ("Let's face it, nobody likes debugging"), do not shift to formal academic language in the body
+- If the opening is formal ("This analysis examines the causal relationship..."), do not insert casual asides
+- Transitions between sections should not shift register — use consistent bridging language
+
+### 3. Voice & Person Conventions
+- **First person singular ("I")** — Personal essays, opinion columns, experience-based articles
+- **First person plural ("we")** — Collaborative or organizational pieces, tutorials ("Let's build...")
+- **Second person ("you")** — How-to guides, advice articles, directly addressing the reader
+- **Third person** — News articles, analytical pieces, formal reports
+- **Do not mix** person within an article unless there is a deliberate rhetorical reason
+
+### 4. Sentence & Paragraph Rhythm
+- Vary sentence length: mix short (8-12 words) and long (20-30 words) sentences to create rhythm
+- Short sentences create emphasis. Long sentences build complexity and nuance, allowing the reader to absorb multiple related ideas in a single breath.
+- Paragraphs should be 3-6 sentences in digital content; longer paragraphs are acceptable in print
+- Each paragraph should contain exactly one main idea — the topic sentence
+
+### 5. Transition Quality
+- Every paragraph must connect logically to the one before it
+- Use explicit transitions for clarity: "However," "Furthermore," "As a result," "In contrast"
+- Use implicit transitions through keyword echo: repeat a key term from the previous paragraph's conclusion in the next paragraph's opening
+- Avoid abrupt topic changes — if a new section is necessary, use a subheading
+
+### 6. Readability Standards
+- **Flesch-Kincaid grade level** targets:
+  - General audience: Grade 8-10
+  - Professional audience: Grade 10-12
+  - Academic audience: Grade 12-16
+- Prefer active voice over passive voice (target 80%+ active sentences)
+- Eliminate filler words: "very," "really," "basically," "actually," "just"
+- Replace nominalizations with verbs: "made an improvement" becomes "improved"

package/knowledge/domain.md

@@ -0,0 +1,183 @@
+---
+domain: writer
+topic: article-structures-argumentation-evidence
+priority: high
+ttl: 30d
+---
+
+# Article Writing — Structures, Argumentation Frameworks & Evidence Types
+
+## Article Structure Patterns
+
+### 1. Inverted Pyramid
+
+The most important information appears first, with details following in descending order of significance. Ideal for news articles, reports, and time-sensitive content.
+
+**Structure:**
+1. **Lead** — The core finding, conclusion, or newsworthy element in 1-2 sentences
+2. **Key supporting facts** — The essential context: who, what, when, where, why, how
+3. **Background & detail** — Additional context, historical perspective, secondary quotes
+4. **Supplementary material** — Related information, further reading, tangential points
+
+**Best for:** News articles, executive summaries, blog posts where readers may not finish
+
+**Strengths:**
+- Readers get value even if they stop early
+- Forces the writer to prioritize information
+- Easy to trim from the bottom for length constraints
+
+### 2. Narrative Arc
+
+Follows a storytelling structure that engages readers emotionally while delivering information. Ideal for feature articles, case studies, and long-form content.
+
+**Structure:**
+1. **Hook / Opening scene** — An anecdote, vivid scene, or provocative question that draws the reader in
+2. **Context / Rising action** — Background information that sets the stage and introduces complexity
+3. **Central tension / Problem** — The core conflict, challenge, or question being explored
+4. **Resolution / Insight** — The answer, finding, or transformation revealed through the narrative
+5. **Denouement / Reflection** — Broader implications, lessons learned, or forward-looking perspective
+
+**Best for:** Feature articles, profiles, case studies, long-form journalism, storytelling-driven blog posts
+
+**Strengths:**
+- High reader engagement through emotional connection
+- Complex ideas become accessible through concrete stories
+- Memorable — readers retain narrative better than abstract arguments
+
+### 3. Analytical Framework
+
+Presents a systematic examination of a topic through structured analysis. Ideal for opinion pieces, thought leadership, and technical articles.
+
+**Structure:**
+1. **Thesis statement** — A clear, arguable claim stated within the first two paragraphs
+2. **Framework introduction** — The analytical lens or criteria being applied
+3. **Argument block 1** — First supporting argument with evidence and analysis
+4. **Argument block 2** — Second supporting argument with evidence and analysis
+5. **Argument block 3** — Third supporting argument (or counterargument + rebuttal)
+6. **Synthesis** — How the arguments work together to prove the thesis
+7. **Conclusion** — Restatement of thesis with broader implications and call to action
+
+**Best for:** Opinion pieces, thought leadership, academic articles, technical analysis, persuasive essays
+
+**Strengths:**
+- Rigorous and credible; shows depth of analysis
+- Easy for readers to follow the logical chain
+- Well-suited to topics requiring evidence-based persuasion
+
+### 4. Listicle / Modular
+
+Organizes content into discrete, numbered or thematic sections that can be read independently. Ideal for practical guides, how-to articles, and reference content.
+
+**Structure:**
+1. **Introduction** — Context, scope, and why this list matters
+2. **Item 1** — Standalone section with heading, explanation, and supporting detail
+3. **Item 2-N** — Each item follows the same internal structure for consistency
+4. **Conclusion / Summary** — Ties the items together and provides next steps
+
+**Best for:** How-to guides, "top N" articles, best practice compilations, tool comparisons
+
+**Strengths:**
+- Scannable; readers can jump to relevant sections
+- Lower cognitive load per section
+- Strong SEO performance due to clear heading structure
+
+### 5. Problem-Solution
+
+Identifies a specific problem, explores its dimensions, and presents a solution with evidence. Ideal for technical articles, white papers, and persuasive content.
+
+**Structure:**
+1. **Problem statement** — Define the problem clearly with data on its scope and impact
+2. **Root cause analysis** — Why the problem exists; underlying factors
+3. **Solution proposal** — The recommended approach, method, or framework
+4. **Evidence of effectiveness** — Data, case studies, or expert validation supporting the solution
+5. **Implementation guidance** — Practical steps for adopting the solution
+6. **Conclusion** — Summary of impact and call to action
+
+**Best for:** White papers, technical blog posts, consulting reports, product marketing content
+
+## Argumentation Frameworks
+
+### Toulmin Model
+
+A practical framework for constructing and evaluating arguments:
+
+| Component | Definition | Example |
+|-----------|-----------|---------|
+| **Claim** | The assertion being made | "Remote work increases productivity" |
+| **Data** | The evidence supporting the claim | "Stanford study showing 13% performance increase" |
+| **Warrant** | The logical connection between data and claim | "Fewer distractions and flexible schedules enable deeper focus" |
+| **Backing** | Support for the warrant itself | "Research on flow states confirms uninterrupted work improves output" |
+| **Qualifier** | Conditions or limitations | "For knowledge workers in roles not requiring physical presence" |
+| **Rebuttal** | Acknowledgment of counterarguments | "Though some roles benefit from in-person collaboration" |
+
+### Classical Rhetorical Appeals (Aristotle)
+
+| Appeal | Definition | Article Application |
+|--------|-----------|-------------------|
+| **Ethos** (Credibility) | Establish authority and trustworthiness | Cite expert sources, demonstrate domain knowledge, acknowledge limitations |
+| **Pathos** (Emotion) | Connect with the reader emotionally | Use vivid anecdotes, relatable scenarios, human-impact framing |
+| **Logos** (Logic) | Appeal through reasoning and evidence | Present data, logical deductions, structured arguments, causal chains |
+
+**Balanced usage:** Strong articles blend all three appeals. Lead with ethos (establish credibility), engage with pathos (make it matter), and convince with logos (prove it with evidence).
+
+### Rogerian Argument
+
+A collaborative approach for contentious topics:
+1. **Acknowledge the opposing view** — Present it fairly and accurately
+2. **Find common ground** — Identify shared values or goals
+3. **Present your position** — With evidence, framed as building on the common ground
+4. **Propose a synthesis** — Show how both perspectives can be accommodated
+
+**Best for:** Controversial topics, opinion pieces aiming to persuade skeptics, policy discussions
+
+### PEEL Paragraph Structure
+
+A micro-framework for individual paragraphs within any article structure:
+- **P**oint — State the paragraph's main idea in one sentence
+- **E**vidence — Provide supporting data, quotes, or examples
+- **E**xplain — Analyze how the evidence supports the point
+- **L**ink — Connect back to the thesis or transition to the next paragraph
+
+## Evidence Types
+
+### 1. Statistical Data
+- Quantitative findings from research studies, surveys, or official reports
+- **Strength:** Objective, measurable, difficult to dispute
+- **Usage:** "According to a 2024 Gartner report, 65% of enterprises..."
+- **Caution:** Always cite the source, sample size, and methodology when available
+
+### 2. Expert Testimony
+- Quotes, opinions, or findings from recognized authorities in the field
+- **Strength:** Leverages established credibility (ethos)
+- **Usage:** Direct quotes for impact, paraphrased for flow
+- **Caution:** Verify the expert's credentials and check for conflicts of interest
+
+### 3. Case Studies
+- Detailed real-world examples demonstrating a principle in practice
+- **Strength:** Concrete, relatable, shows causation in context
+- **Usage:** Narrative description of situation, action, and outcome
+- **Caution:** Individual cases may not be generalizable; acknowledge limitations
+
+### 4. Analogies & Metaphors
+- Comparisons that make abstract concepts accessible
+- **Strength:** Bridges the knowledge gap between writer and reader
+- **Usage:** "Microservices are like a team of specialists, each handling one task..."
+- **Caution:** Analogies simplify; acknowledge where the comparison breaks down
+
+### 5. Historical Precedent
+- Past events or decisions that inform the current discussion
+- **Strength:** Provides temporal context and pattern recognition
+- **Usage:** "The 2008 financial crisis demonstrated that..."
+- **Caution:** Context changes over time; historical parallels are imperfect
+
+### 6. Logical Reasoning
+- Deductive or inductive chains that lead the reader to a conclusion
+- **Strength:** Self-contained; doesn't depend on external sources
+- **Usage:** "If A is true, and B follows from A, then C must follow..."
+- **Caution:** Ensure premises are sound; avoid hidden assumptions
+
+### 7. Anecdotal Evidence
+- Personal stories or individual experiences that illustrate a point
+- **Strength:** Highly engaging and relatable (pathos)
+- **Usage:** Opening hooks, humanizing abstract topics, illustrating impact
+- **Caution:** Not generalizable; should supplement, not replace, systematic evidence

package/manifest.json

@@ -0,0 +1,29 @@
+{
+  "name": "@botlearn/writer",
+  "version": "0.1.0",
+  "description": "Structured article writing with evidence-based argumentation, consistent style, and quality improvement of 60% for OpenClaw Agent",
+  "category": "creative-generation",
+  "author": "BotLearn",
+  "benchmarkDimension": "creative-generation",
+  "expectedImprovement": 60,
+  "dependencies": {
+    "@botlearn/summarizer": "^1.0.0",
+    "@botlearn/keyword-extractor": "^1.0.0"
+  },
+  "compatibility": {
+    "openclaw": ">=0.5.0"
+  },
+  "files": {
+    "skill": "skill.md",
+    "knowledge": [
+      "knowledge/domain.md",
+      "knowledge/best-practices.md",
+      "knowledge/anti-patterns.md"
+    ],
+    "strategies": [
+      "strategies/main.md"
+    ],
+    "smokeTest": "tests/smoke.json",
+    "benchmark": "tests/benchmark.json"
+  }
+}

package/package.json

@@ -0,0 +1,39 @@
+{
+  "name": "@botlearn/writer",
+  "version": "0.1.0",
+  "description": "Structured article writing with evidence-based argumentation, consistent style, and quality improvement of 60% for OpenClaw Agent",
+  "type": "module",
+  "main": "manifest.json",
+  "files": [
+    "manifest.json",
+    "skill.md",
+    "knowledge/",
+    "strategies/",
+    "tests/",
+    "README.md"
+  ],
+  "keywords": [
+    "botlearn",
+    "openclaw",
+    "skill",
+    "creative-generation"
+  ],
+  "author": "BotLearn",
+  "license": "MIT",
+  "dependencies": {
+    "@botlearn/keyword-extractor": "0.1.0",
+    "@botlearn/summarizer": "0.1.0"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/readai-team/botlearn-awesome-skills.git",
+    "directory": "packages/skills/writer"
+  },
+  "homepage": "https://github.com/readai-team/botlearn-awesome-skills/tree/main/packages/skills/writer",
+  "bugs": {
+    "url": "https://github.com/readai-team/botlearn-awesome-skills/issues"
+  },
+  "publishConfig": {
+    "access": "public"
+  }
+}

package/skill.md

@@ -0,0 +1,45 @@
+---
+name: writer
+role: Article Writing Specialist
+version: 1.0.0
+triggers:
+  - "write an article"
+  - "write about"
+  - "compose"
+  - "draft article"
+  - "blog post"
+---
+
+# Role
+
+You are an Article Writing Specialist. When activated, you produce structured, evidence-based articles with clear thesis statements, well-supported arguments, and consistent style. You leverage summarization capabilities to distill research and keyword extraction to optimize topic coverage and SEO relevance.
+
+# Capabilities
+
+1. Construct well-organized articles following established structural patterns (inverted pyramid, narrative arc, analytical framework) appropriate to the topic and audience
+2. Develop clear, defensible thesis statements and decompose them into supporting arguments with logical progression
+3. Integrate multiple evidence types (statistical data, expert quotes, case studies, analogies) to substantiate claims while maintaining readability
+4. Maintain consistent tone, voice, and style throughout the article, adapting register to the target audience and publication context
+5. Use @botlearn/summarizer to condense research material into key points for evidence integration
+6. Use @botlearn/keyword-extractor to identify core terms, optimize topic coverage, and ensure semantic completeness
+
+# Constraints
+
+1. Never present claims without supporting evidence — every assertion must be backed by data, expert opinion, or logical reasoning
+2. Never switch tone or register mid-article without deliberate rhetorical intent — style must remain consistent from introduction to conclusion
+3. Never produce an article without a clearly identifiable thesis statement within the first two paragraphs
+4. Never use a single evidence type exclusively — diversify between statistics, expert testimony, examples, and logical arguments
+5. Always include a strong conclusion that reinforces the thesis and provides forward-looking insight or a call to action
+6. Always verify that each paragraph serves a clear purpose in advancing the overall argument
+
+# Activation
+
+WHEN the user requests article writing, composition, or blog post creation:
+1. Analyze the topic, target audience, desired length, and publication context
+2. Use @botlearn/keyword-extractor to identify core terms and related concepts for comprehensive topic coverage
+3. Use @botlearn/summarizer to distill any provided research material or references into usable evidence points
+4. Follow strategies/main.md for the 7-step writing workflow
+5. Apply knowledge/domain.md for article structure selection and argumentation framework
+6. Ensure quality using knowledge/best-practices.md for thesis development, evidence integration, and style consistency
+7. Verify against knowledge/anti-patterns.md to avoid weak thesis, unsupported claims, and tone inconsistency
+8. Output a complete, publication-ready article with clear structure and sourced evidence

package/strategies/main.md

@@ -0,0 +1,130 @@
+---
+strategy: writer
+version: 1.0.0
+steps: 7
+---
+
+# Article Writing Strategy
+
+## Step 1: Topic Research & Scoping
+- Parse the user's request to identify: **topic**, **target audience**, **desired length**, **publication context**, **tone preference**
+- Use @botlearn/keyword-extractor to extract core terms, related concepts, and semantic clusters from the topic
+- Use @botlearn/summarizer to condense any provided reference materials, sources, or background documents into key evidence points
+- IF the topic is ambiguous or underspecified THEN ask clarifying questions:
+  - "Who is the target audience?"
+  - "What is the desired length and format?"
+  - "Is there a specific angle or thesis you want to pursue?"
+- Identify 3-5 key subtopics that the article must address for comprehensive coverage
+- Assess available evidence: what data, examples, or expert perspectives exist for this topic?
+
+## Step 2: Outline Construction
+- SELECT article structure from knowledge/domain.md based on topic and purpose:
+  - Persuasive or opinion → Analytical Framework
+  - News or time-sensitive → Inverted Pyramid
+  - Feature or case study → Narrative Arc
+  - How-to or reference → Listicle / Modular
+  - Technical or consulting → Problem-Solution
+- Draft a hierarchical outline:
+  - **Level 1**: Major sections (introduction, argument blocks, conclusion)
+  - **Level 2**: Key points within each section
+  - **Level 3**: Evidence placeholders (type of evidence needed for each point)
+- VERIFY outline covers all subtopics identified in Step 1
+- VERIFY each argument block maps directly to the thesis
+- IF outline has fewer than 3 argument blocks THEN expand — the article needs sufficient depth
+- IF outline has more than 5 argument blocks THEN consolidate — focus risks dilution
+
+## Step 3: Argument Building
+- SELECT argumentation framework from knowledge/domain.md:
+  - Default: Toulmin Model (Claim → Data → Warrant → Backing → Qualifier → Rebuttal)
+  - Contentious topics: Rogerian Argument (Acknowledge opposition → Common ground → Position → Synthesis)
+  - Persuasive essays: Classical Rhetorical Appeals (Ethos → Pathos → Logos)
+- For each argument block in the outline:
+  1. State the **claim** in one clear sentence
+  2. Identify the **evidence** needed (type and source)
+  3. Write the **warrant** — the logical bridge between evidence and claim
+  4. Add a **qualifier** if the claim has conditions or limitations
+  5. IF a counterargument exists THEN draft a **rebuttal**
+- VERIFY logical consistency: no argument should contradict another; each should build on the previous
+- SELF-CHECK: Does each argument independently support the thesis? Remove any that don't
+
+## Step 4: Evidence Integration
+- For each evidence placeholder in the outline, SELECT evidence from available sources:
+  - Apply evidence selection criteria from knowledge/best-practices.md: relevance, recency, authority, representativeness
+  - Target a minimum of 3 different evidence types across the article (statistics, expert quotes, case studies, analogies, logical reasoning)
+  - High-stakes claims (central to thesis) require 2-3 supporting evidence items
+- Integrate evidence using appropriate introduction patterns from knowledge/best-practices.md:
+  - Signal phrase for attributed authority
+  - Data-first for maximum impact
+  - Contextual embedding for narrative flow
+- APPLY the PEEL structure to each paragraph: Point → Evidence → Explain → Link
+  - Never leave evidence unanalyzed — always explain what it means and how it connects to the argument
+- VERIFY source attribution: every piece of evidence must identify who, when, and in what context
+- CHECK against knowledge/anti-patterns.md:
+  - No unsupported claims (anti-pattern #5)
+  - No evidence without analysis (anti-pattern #6)
+  - No cherry-picked evidence (anti-pattern #7)
+  - No outdated evidence (anti-pattern #8)
+  - No single-source dependency (anti-pattern #9)
+
+## Step 5: Draft Composition
+- Write the complete article following the outline and assembled arguments:
+- **Introduction** (1-2 paragraphs):
+  - Open with a hook: a surprising statistic, provocative question, vivid anecdote, or bold claim
+  - Provide necessary context for the topic
+  - State the thesis clearly within the first two paragraphs
+- **Body** (per outline):
+  - Follow the selected article structure from Step 2
+  - Use the argumentation framework from Step 3 for each argument block
+  - Embed evidence per Step 4 integration patterns
+  - Include transitions between every section and paragraph
+- **Conclusion** (1-2 paragraphs):
+  - Restate the thesis in light of the evidence presented (do not copy-paste the introduction)
+  - Synthesize the key arguments into a higher-order insight
+  - End with a call to action, forward-looking prediction, or thought-provoking question
+- APPLY sentence rhythm: alternate short and long sentences for readability
+- MAINTAIN consistent tone throughout — refer to the tone selection framework in knowledge/best-practices.md
+
+## Step 6: Style Check & Polish
+- VERIFY tone consistency: read the full draft and flag any shifts in register, formality, or voice
+  - Check: Does the introduction and conclusion use the same register?
+  - Check: Are all sections using the same person (first, second, third)?
+  - Check: Is vocabulary level consistent throughout?
+- VERIFY readability:
+  - Paragraphs are 3-6 sentences (digital) or 4-8 sentences (print)
+  - Sentence variety: mix of short (8-12 words) and long (20-30 words)
+  - Active voice usage is at 80%+ — convert passive constructions where possible
+  - Eliminate filler words: "very," "really," "basically," "actually," "just"
+  - Replace nominalizations: "made an improvement" → "improved"
+- VERIFY transitions:
+  - Every paragraph opens with a connection to the previous one
+  - Subheadings are used every 200-300 words for scannable content
+- CHECK against knowledge/anti-patterns.md:
+  - No tone inconsistency (anti-pattern #11)
+  - No register mismatch (anti-pattern #12)
+  - No passive voice overuse (anti-pattern #13)
+  - No filler/hedge overload (anti-pattern #14)
+  - No wall of text (anti-pattern #15)
+  - No buried lead (anti-pattern #16)
+  - No weak conclusion (anti-pattern #17)
+  - No missing transitions (anti-pattern #18)
+
+## Step 7: Revision & Final Quality Assurance
+- SELF-CHECK — Thesis integrity:
+  - Can you identify the thesis in one sentence? Is it in the first two paragraphs?
+  - Does the conclusion restate it consistently (not contradict it)?
+  - Does every argument block connect back to the thesis? (anti-pattern #4: moving thesis)
+- SELF-CHECK — Evidence sufficiency:
+  - Are there at least 3 different evidence types used?
+  - Is every major claim supported?
+  - Are counterarguments acknowledged for contentious claims?
+- SELF-CHECK — Structural coherence:
+  - Does the article follow the selected structure pattern consistently?
+  - Is the information prioritized appropriately (most important first for inverted pyramid; tension built for narrative)?
+  - Are there clear section markers and logical flow?
+- SELF-CHECK — Audience alignment:
+  - Is the vocabulary appropriate for the target audience?
+  - Is the depth of explanation correct (not too basic, not too advanced)?
+  - Would the target reader find this article valuable?
+- IF any check fails THEN revise the specific section and re-run the failed check
+- Use @botlearn/keyword-extractor to verify final keyword coverage — ensure core topic terms appear with appropriate frequency
+- Output the final article with clear formatting: title, subheadings, paragraphs, and source attributions

package/tests/benchmark.json

@@ -0,0 +1,506 @@
+{
+  "version": "0.0.1",
+  "dimension": "creative-generation",
+  "tasks": [
+    {
+      "id": "bench-easy-01",
+      "difficulty": "easy",
+      "description": "Write a short informational article on a well-known topic",
+      "input": "Write a 400-500 word article explaining why regular code reviews improve software quality. Target audience: junior developers. Use an accessible, encouraging tone.",
+      "rubric": [
+        {
+          "criterion": "Thesis Clarity",
+          "weight": 0.3,
+          "scoring": {
+            "5": "Clear thesis within the first two paragraphs stating that code reviews improve quality, with a specific angle (e.g., catches bugs early, promotes knowledge sharing)",
+            "3": "General statement about code reviews being useful but lacking a specific, arguable claim",
+            "1": "No identifiable thesis; reads as a list of facts",
+            "0": "No central argument"
+          }
+        },
+        {
+          "criterion": "Evidence & Support",
+          "weight": 0.3,
+          "scoring": {
+            "5": "At least two concrete supporting points with evidence (statistics, examples, or expert references); each point analyzed, not just stated",
+            "3": "Supporting points present but evidence is generic or unsupported assertions",
+            "1": "Claims without any evidence",
+            "0": "No supporting arguments"
+          }
+        },
+        {
+          "criterion": "Style & Tone",
+          "weight": 0.4,
+          "scoring": {
+            "5": "Consistently accessible and encouraging tone appropriate for junior developers; no jargon without explanation; active voice; smooth flow",
+            "3": "Mostly appropriate tone with occasional shifts to overly formal or condescending register",
+            "1": "Tone mismatch — too technical or too patronizing for the audience",
+            "0": "No audience awareness"
+          }
+        }
+      ],
+      "expectedScoreWithout": 40,
+      "expectedScoreWith": 80
+    },
+    {
+      "id": "bench-easy-02",
+      "difficulty": "easy",
+      "description": "Write a practical how-to blog post with clear structure",
+      "input": "Write a 400-500 word blog post titled 'How to Write a Great Git Commit Message'. Use a listicle or modular structure with clear sections. Target audience: developers of all levels.",
+      "rubric": [
+        {
+          "criterion": "Structure",
+          "weight": 0.35,
+          "scoring": {
+            "5": "Clear modular/listicle structure with introduction, 3+ distinct sections with subheadings, and a summary/conclusion; each section is self-contained",
+            "3": "Some structure visible but sections blend together or lack clear headings",
+            "1": "Wall of text with no structural organization",
+            "0": "No discernible structure"
+          }
+        },
+        {
+          "criterion": "Content Quality",
+          "weight": 0.35,
+          "scoring": {
+            "5": "Practical, actionable advice with concrete examples of good and bad commit messages; explains the 'why' behind each practice",
+            "3": "Advice is reasonable but generic; lacks concrete examples",
+            "1": "Vague or incorrect guidance",
+            "0": "Content is irrelevant or unusable"
+          }
+        },
+        {
+          "criterion": "Completeness",
+          "weight": 0.3,
+          "scoring": {
+            "5": "Covers key aspects: subject line format, body content, imperative mood, scope, and provides a conclusion tying it together; appropriate length",
+            "3": "Covers 2-3 aspects but misses important ones",
+            "1": "Covers only one aspect superficially",
+            "0": "Incomplete or off-topic"
+          }
+        }
+      ],
+      "expectedScoreWithout": 45,
+      "expectedScoreWith": 82
+    },
+    {
+      "id": "bench-easy-03",
+      "difficulty": "easy",
+      "description": "Write a brief opinion piece with a clear position",
+      "input": "Write a 300-400 word opinion piece arguing that open-source software is essential for innovation in the tech industry. Use a professional tone suitable for a tech publication.",
+      "rubric": [
+        {
+          "criterion": "Thesis & Position",
+          "weight": 0.35,
+          "scoring": {
+            "5": "Strong, specific thesis stated early; clear position that open-source is essential (not just 'useful') with a defined scope (innovation in tech)",
+            "3": "Position is present but hedged or vague; reads more as 'open source is nice' than 'essential'",
+            "1": "No clear position; balanced overview instead of an opinion",
+            "0": "No identifiable argument"
+          }
+        },
+        {
+          "criterion": "Argumentation",
+          "weight": 0.35,
+          "scoring": {
+            "5": "At least two distinct arguments with supporting evidence; logical progression from claim to evidence to analysis; brief acknowledgment of counterpoint",
+            "3": "Arguments present but evidence is thin; no counterargument engagement",
+            "1": "Assertions without supporting logic or evidence",
+            "0": "No argumentation"
+          }
+        },
+        {
+          "criterion": "Conclusion Strength",
+          "weight": 0.3,
+          "scoring": {
+            "5": "Conclusion reinforces thesis, synthesizes arguments into a broader insight, and ends with a call to action or forward-looking statement",
+            "3": "Conclusion restates the thesis but doesn't add new insight",
+            "1": "Abrupt ending or vague summary",
+            "0": "No conclusion"
+          }
+        }
+      ],
+      "expectedScoreWithout": 40,
+      "expectedScoreWith": 78
+    },
+    {
+      "id": "bench-med-01",
+      "difficulty": "medium",
+      "description": "Write an analytical article requiring evidence integration and counterargument handling",
+      "input": "Write a 700-900 word article analyzing whether remote work increases or decreases productivity for software engineering teams. Present evidence for both sides, take a clear position, and address the strongest counterargument. Target audience: engineering managers. Professional, data-informed tone.",
+      "rubric": [
+        {
+          "criterion": "Thesis & Position",
+          "weight": 0.2,
+          "scoring": {
+            "5": "Clear, nuanced thesis within first two paragraphs; takes a specific position (not 'it depends') with qualifiers (e.g., 'for senior engineers on established teams'); conclusion is consistent",
+            "3": "Position is present but too hedged or appears late in the article",
+            "1": "No clear position; article remains neutral throughout",
+            "0": "No thesis; descriptive overview only"
+          }
+        },
+        {
+          "criterion": "Evidence Integration",
+          "weight": 0.3,
+          "scoring": {
+            "5": "Uses 3+ evidence types (statistics, case studies, expert quotes); evidence is properly attributed with source, date, and context; PEEL structure visible in body paragraphs",
+            "3": "Some evidence present but not well-attributed; relies on one evidence type",
+            "1": "Minimal evidence; mostly personal opinion or unverified claims",
+            "0": "No evidence"
+          }
+        },
+        {
+          "criterion": "Counterargument Handling",
+          "weight": 0.25,
+          "scoring": {
+            "5": "Strongest counterargument presented fairly using Rogerian approach; rebutted with specific evidence; concedes valid points while maintaining thesis",
+            "3": "Counterargument acknowledged but dismissed superficially or presented as a straw man",
+            "1": "Counterargument mentioned in passing without engagement",
+            "0": "No counterargument addressed"
+          }
+        },
+        {
+          "criterion": "Style & Structure",
+          "weight": 0.25,
+          "scoring": {
+            "5": "Analytical framework structure; consistent professional tone for engineering managers; smooth transitions; clear subheadings; varied sentence rhythm",
+            "3": "Adequate structure but some tonal shifts or weak transitions",
+            "1": "Poor structure; inconsistent tone; choppy flow",
+            "0": "Unstructured; inappropriate tone"
+          }
+        }
+      ],
+      "expectedScoreWithout": 30,
+      "expectedScoreWith": 72
+    },
+    {
+      "id": "bench-med-02",
+      "difficulty": "medium",
+      "description": "Write a narrative-driven feature article using storytelling techniques",
+      "input": "Write a 700-900 word feature article about how a fictional startup pivoted from a failing product to a successful one by embracing user feedback. Use a narrative arc structure with a compelling opening scene, rising tension, and resolution. Target audience: entrepreneurs and product managers.",
+      "rubric": [
+        {
+          "criterion": "Narrative Structure",
+          "weight": 0.3,
+          "scoring": {
+            "5": "Clear narrative arc: engaging opening scene/hook, rising action with increasing tension, central problem/pivot moment, resolution with specific outcomes, reflection with broader lessons",
+            "3": "Some narrative elements but flat tension curve; events listed chronologically without dramatic structure",
+            "1": "No narrative structure; reads as an expository article about pivots",
+            "0": "No storytelling elements"
+          }
+        },
+        {
+          "criterion": "Evidence Through Story",
+          "weight": 0.25,
+          "scoring": {
+            "5": "Business insights and evidence woven naturally into the narrative; specific details (metrics, user feedback quotes, product decisions) make the story credible and instructive",
+            "3": "Some data points included but feel forced or disconnected from the narrative",
+            "1": "Pure fiction with no instructive business evidence or lessons",
+            "0": "No evidence or data integrated"
+          }
+        },
+        {
+          "criterion": "Character & Scene",
+          "weight": 0.2,
+          "scoring": {
+            "5": "Vivid characters (founder, team members, users) with distinct voices; concrete scenes with sensory details; the reader can visualize key moments",
+            "3": "Characters are named but one-dimensional; scenes are described but lack vividness",
+            "1": "No character development; abstract descriptions",
+            "0": "No characters or scenes"
+          }
+        },
+        {
+          "criterion": "Takeaway & Relevance",
+          "weight": 0.25,
+          "scoring": {
+            "5": "Article concludes with actionable insights for the target audience; lessons are drawn from the narrative rather than appended; readers can apply the insights to their own work",
+            "3": "Lessons stated but feel disconnected from the story; generic startup advice",
+            "1": "No clear takeaway for the audience",
+            "0": "Irrelevant to target audience"
+          }
+        }
+      ],
+      "expectedScoreWithout": 25,
+      "expectedScoreWith": 68
+    },
+    {
+      "id": "bench-med-03",
+      "difficulty": "medium",
+      "description": "Write an article requiring style adaptation to a specific audience",
+      "input": "Write a 600-800 word article explaining Kubernetes container orchestration for a non-technical business audience. The article should justify why a company's leadership should invest in Kubernetes, using business language (ROI, scalability, operational efficiency) rather than technical jargon. Analogies are encouraged.",
+      "rubric": [
+        {
+          "criterion": "Audience Adaptation",
+          "weight": 0.35,
+          "scoring": {
+            "5": "Entirely business-oriented language; no unexplained technical jargon; concepts framed in terms of business value (cost savings, reliability, speed to market); effective analogies that make technical concepts intuitive",
+            "3": "Mostly business language but some technical terms leak through without explanation; analogies attempted but not fully effective",
+            "1": "Heavy technical language; reads as a developer article with a few business terms added",
+            "0": "No audience adaptation; pure technical article"
+          }
+        },
+        {
+          "criterion": "Argument for Investment",
+          "weight": 0.3,
+          "scoring": {
+            "5": "Clear business case with specific benefits (cost reduction %, uptime improvement, deployment speed); addresses likely executive concerns (cost, complexity, timeline); evidence supports each benefit",
+            "3": "Business benefits mentioned but vague ('it saves money'); doesn't address concerns",
+            "1": "No clear business case; describes what Kubernetes does but not why it matters",
+            "0": "No investment argument"
+          }
+        },
+        {
+          "criterion": "Analogies & Clarity",
+          "weight": 0.2,
+          "scoring": {
+            "5": "Uses 2+ effective analogies that accurately represent the concept while being accessible (e.g., 'Kubernetes is like a shipping logistics manager...'); acknowledges where analogies simplify",
+            "3": "One analogy present but not fully developed; or analogy is inaccurate",
+            "1": "No analogies; abstract explanations only",
+            "0": "Confusing or misleading analogies"
+          }
+        },
+        {
+          "criterion": "Completeness & Structure",
+          "weight": 0.15,
+          "scoring": {
+            "5": "Complete article with clear introduction, 3+ benefit sections, and conclusion with recommendation; appropriate length; well-organized for scanability",
+            "3": "Covers some benefits but incomplete; structure needs work",
+            "1": "Fragmentary or significantly too short/long",
+            "0": "Incomplete"
+          }
+        }
+      ],
+      "expectedScoreWithout": 25,
+      "expectedScoreWith": 70
+    },
+    {
+      "id": "bench-med-04",
+      "difficulty": "medium",
+      "description": "Write an article integrating multiple evidence types with proper attribution",
+      "input": "Write a 600-800 word article about the impact of AI on software testing, arguing that AI-assisted testing will complement rather than replace human testers. Include at least one statistic, one expert perspective, one case study or example, and one logical argument. Target: QA professionals. Professional, informed tone.",
+      "rubric": [
+        {
+          "criterion": "Evidence Diversity",
+          "weight": 0.35,
+          "scoring": {
+            "5": "Includes all 4 requested evidence types (statistic, expert perspective, case study, logical argument); each is properly attributed with source, context, and date; evidence types are distributed across different argument blocks",
+            "3": "Includes 2-3 evidence types; attribution is incomplete",
+            "1": "Only one evidence type used; poor attribution",
+            "0": "No evidence; opinion only"
+          }
+        },
+        {
+          "criterion": "Evidence Analysis",
+          "weight": 0.25,
+          "scoring": {
+            "5": "Every piece of evidence is followed by analysis explaining what it means and how it supports the argument (PEEL structure); evidence is woven into the narrative, not dropped in",
+            "3": "Some evidence is analyzed but others are stated without interpretation",
+            "1": "Evidence is listed without analysis",
+            "0": "No analysis"
+          }
+        },
+        {
+          "criterion": "Thesis & Argumentation",
+          "weight": 0.2,
+          "scoring": {
+            "5": "Clear 'complement not replace' thesis stated early; arguments logically build the case with specific examples of complementary roles",
+            "3": "Thesis present but arguments are generic",
+            "1": "Vague position; doesn't clearly argue complement vs. replace",
+            "0": "No thesis"
+          }
+        },
+        {
+          "criterion": "Audience & Tone",
+          "weight": 0.2,
+          "scoring": {
+            "5": "Professional, informed tone respecting QA professionals' expertise; uses QA-specific terminology appropriately; addresses their real concerns (job security, skill evolution)",
+            "3": "Generally appropriate but occasionally condescending or too basic for QA professionals",
+            "1": "Tone mismatch; either too academic or too casual for the audience",
+            "0": "No audience awareness"
+          }
+        }
+      ],
+      "expectedScoreWithout": 25,
+      "expectedScoreWith": 70
+    },
+    {
+      "id": "bench-hard-01",
+      "difficulty": "hard",
+      "description": "Write a long-form article on a contentious topic requiring balanced evidence, strong counterargument handling, and sophisticated structure",
+      "input": "Write a 1000-1200 word article for a technology policy publication arguing whether governments should mandate algorithmic transparency for AI systems used in hiring decisions. Take a clear position, present evidence from multiple domains (technology, law, ethics, business), engage with the two strongest counterarguments, and propose a specific policy recommendation. Formal, authoritative tone.",
+      "rubric": [
+        {
+          "criterion": "Thesis & Policy Position",
+          "weight": 0.2,
+          "scoring": {
+            "5": "Specific, nuanced thesis stated within first two paragraphs; clear policy recommendation (not just 'transparency is good'); scoped to hiring AI specifically; conclusion reinforces with implementation specifics",
+            "3": "Position present but vague or overly general; recommendation lacks specificity",
+            "1": "Balanced overview without taking a position; no policy recommendation",
+            "0": "No identifiable argument or recommendation"
+          }
+        },
+        {
+          "criterion": "Multi-Domain Evidence",
+          "weight": 0.25,
+          "scoring": {
+            "5": "Evidence drawn from all 4 requested domains (technology, law, ethics, business) with proper attribution; domains are connected, not siloed; at least 5 distinct evidence items across the article",
+            "3": "Evidence from 2-3 domains; some well-attributed, others generic",
+            "1": "Evidence from only one domain or unattributed claims",
+            "0": "No substantive evidence"
+          }
+        },
+        {
+          "criterion": "Counterargument Engagement",
+          "weight": 0.25,
+          "scoring": {
+            "5": "Two strongest counterarguments identified and presented fairly (Rogerian approach); each rebutted with specific evidence; valid points conceded; overall argument strengthened by the engagement",
+            "3": "One counterargument addressed adequately; second missing or treated as straw man",
+            "1": "Counterarguments mentioned but not seriously engaged",
+            "0": "No counterarguments addressed"
+          }
+        },
+        {
+          "criterion": "Structure & Sophistication",
+          "weight": 0.15,
+          "scoring": {
+            "5": "Analytical framework structure with clear progression; transitions create a logical chain between sections; subheadings guide the reader; introduction and conclusion frame the article as a coherent argument",
+            "3": "Adequate structure but some sections feel disconnected; transitions need work",
+            "1": "Poor organization; arguments presented randomly",
+            "0": "No discernible structure"
+          }
+        },
+        {
+          "criterion": "Tone & Authority",
+          "weight": 0.15,
+          "scoring": {
+            "5": "Consistently formal, authoritative tone appropriate for a policy publication; precise language; no casual expressions; demonstrates deep domain familiarity through vocabulary and framing",
+            "3": "Mostly formal but occasional informalities; vocabulary sometimes imprecise",
+            "1": "Tone inconsistencies; shifts between formal and casual; vocabulary too basic for a policy audience",
+            "0": "Inappropriate tone throughout"
+          }
+        }
+      ],
+      "expectedScoreWithout": 20,
+      "expectedScoreWith": 65
+    },
+    {
+      "id": "bench-hard-02",
+      "difficulty": "hard",
+      "description": "Write an article requiring creative structure choice, audience adaptation, and synthesis of complex material",
+      "input": "Write a 1000-1200 word article for a general audience explaining why quantum computing will not replace classical computers for most tasks, but will transform specific domains like drug discovery, cryptography, and optimization. The article must be engaging for non-technical readers while being technically accurate. Use a problem-solution structure: frame the common misconception first, then systematically dismantle it while explaining what quantum computing actually excels at.",
+      "rubric": [
+        {
+          "criterion": "Structure Execution",
+          "weight": 0.2,
+          "scoring": {
+            "5": "Effective problem-solution structure: clearly frames the 'quantum will replace classical' misconception as the problem; systematically addresses it through 3+ domain-specific sections; each section debunks while reframing; conclusion synthesizes",
+            "3": "Some problem-solution elements but the misconception isn't clearly framed upfront; structure drifts into general explainer",
+            "1": "No clear problem-solution structure; standard expository article",
+            "0": "No recognizable structure"
+          }
+        },
+        {
+          "criterion": "Technical Accuracy & Accessibility",
+          "weight": 0.3,
+          "scoring": {
+            "5": "Technically accurate explanation of quantum computing limitations and strengths; complex concepts made accessible through analogies and everyday language; no unexplained jargon; reader finishes with correct understanding",
+            "3": "Mostly accurate but some oversimplifications are misleading; 1-2 jargon terms without explanation",
+            "1": "Technical inaccuracies or overly simplified to the point of being wrong; heavy jargon",
+            "0": "Technically incorrect or incomprehensible to target audience"
+          }
+        },
+        {
+          "criterion": "Domain Coverage",
+          "weight": 0.2,
+          "scoring": {
+            "5": "All three requested domains (drug discovery, cryptography, optimization) covered with specific examples of quantum advantage; explains why classical computers struggle in each domain",
+            "3": "Two domains covered well; third is superficial or missing",
+            "1": "Only one domain addressed; others mentioned in passing",
+            "0": "No domain-specific coverage"
+          }
+        },
+        {
+          "criterion": "Engagement & Readability",
+          "weight": 0.15,
+          "scoring": {
+            "5": "Compelling hook; sustained reader interest through varied techniques (analogies, questions, concrete scenarios); sentences are varied in length and rhythm; paragraphs are scannable",
+            "3": "Reasonably engaging but flat in places; limited use of engagement techniques",
+            "1": "Dry, textbook-like prose; no engagement techniques",
+            "0": "Boring or confusing; reader would stop early"
+          }
+        },
+        {
+          "criterion": "Conclusion & Synthesis",
+          "weight": 0.15,
+          "scoring": {
+            "5": "Conclusion synthesizes the domain examples into a coherent view of quantum computing's actual role; provides a forward-looking perspective that is both realistic and exciting; reinforces the thesis",
+            "3": "Summary restates main points but doesn't synthesize into a new insight",
+            "1": "Weak or missing conclusion",
+            "0": "No conclusion"
+          }
+        }
+      ],
+      "expectedScoreWithout": 20,
+      "expectedScoreWith": 62
+    },
+    {
+      "id": "bench-hard-03",
+      "difficulty": "hard",
+      "description": "Write an article requiring integration of dependent skills (summarizer + keyword-extractor) with complex argumentation",
+      "input": "Here is a collection of raw research notes on microservices architecture:\n\n- Netflix migrated to microservices in 2009-2012, reducing deployment time from weeks to minutes. Source: Netflix Tech Blog, 2016.\n- A 2023 InfoQ survey found 78% of organizations using microservices reported increased deployment frequency, but 65% reported increased operational complexity.\n- Martin Fowler warns about the 'microservices premium': the overhead is only justified at a certain scale. Source: martinfowler.com, 2015.\n- Amazon's two-pizza team rule emerged from their service-oriented architecture. Each team owns one service. Source: 'Working Backwards', 2021.\n- A 2024 DORA report found that elite performers using microservices deployed 973x more frequently than low performers, but the gap disappeared when controlling for team practices.\n- Kelsey Hightower tweeted: 'Monoliths are the future because the people who are currently building microservices will realize that most of their problems don't require microservices.'\n- Segment (analytics company) moved FROM microservices BACK to a monolith in 2018, citing excessive operational overhead for their team size. Source: Segment Engineering Blog.\n\nUsing this research material, write a 900-1100 word article for a CTO audience arguing whether startups should begin with a monolith or microservices. Summarize the research into coherent evidence, extract the key themes, take a clear position, and address counterarguments.",
+      "rubric": [
+        {
+          "criterion": "Research Synthesis",
+          "weight": 0.25,
+          "scoring": {
+            "5": "All 7 research notes are synthesized into coherent themes (not listed one by one); evidence is grouped by argument rather than by source; contradictions are acknowledged and resolved; demonstrates summarization capability",
+            "3": "Most research notes used but presented sequentially rather than synthesized; some grouping by theme",
+            "1": "Research notes copy-pasted or minimally rephrased; no synthesis",
+            "0": "Research notes ignored or misrepresented"
+          }
+        },
+        {
+          "criterion": "Keyword & Theme Extraction",
+          "weight": 0.15,
+          "scoring": {
+            "5": "Core themes clearly extracted (deployment frequency, operational complexity, team size, organizational maturity); keyword coverage is comprehensive; themes drive the article structure",
+            "3": "Some themes identified but article structure doesn't follow them; coverage gaps",
+            "1": "No thematic organization; random coverage of research points",
+            "0": "No theme extraction"
+          }
+        },
+        {
+          "criterion": "Argumentation Quality",
+          "weight": 0.25,
+          "scoring": {
+            "5": "Clear position stated early; Toulmin model visible (claim, data, warrant, qualifier, rebuttal); evidence from research notes used as data with analysis; counterarguments addressed with specific evidence from the notes",
+            "3": "Position taken but argumentation is shallow; evidence cited but not analyzed",
+            "1": "Weak or shifting position; evidence not connected to claims",
+            "0": "No clear argument"
+          }
+        },
+        {
+          "criterion": "Evidence Attribution",
+          "weight": 0.15,
+          "scoring": {
+            "5": "Every research note properly attributed (source, date); statistics include context; expert perspectives include credentials/relevance; case studies include outcomes",
+            "3": "Most sources attributed but some are vague ('a study found...')",
+            "1": "Poor attribution; claims presented as facts without sourcing",
+            "0": "No attribution"
+          }
+        },
+        {
+          "criterion": "CTO Audience Fit",
+          "weight": 0.2,
+          "scoring": {
+            "5": "Framed in terms of business decisions CTOs face (team size, deployment speed, operational cost); actionable recommendation with specific conditions; professional, strategic tone; addresses real tradeoffs",
+            "3": "Generally professional but doesn't specifically address CTO decision-making context",
+            "1": "Too technical (developer-focused) or too high-level (executive summary without depth)",
+            "0": "No audience awareness"
+          }
+        }
+      ],
+      "expectedScoreWithout": 20,
+      "expectedScoreWith": 65
+    }
+  ]
+}

package/tests/smoke.json

@@ -0,0 +1,54 @@
+{
+  "version": "0.0.1",
+  "timeout": 60,
+  "tasks": [
+    {
+      "id": "smoke-01",
+      "description": "Write a structured analytical article on a technical topic with clear thesis, evidence, and consistent style",
+      "input": "Write a 600-800 word article arguing that test-driven development (TDD) improves long-term code quality for backend services. Target audience is mid-level software engineers. Include at least two supporting arguments with evidence, address one counterargument, and maintain a professional but accessible tone throughout.",
+      "rubric": [
+        {
+          "criterion": "Thesis Clarity",
+          "weight": 0.25,
+          "scoring": {
+            "5": "Clear, specific, arguable thesis stated within the first two paragraphs; thesis is scoped to backend services and long-term quality; conclusion restates it consistently",
+            "3": "Thesis is present but vague or overly broad (e.g., 'TDD is good'); may appear late in the article",
+            "1": "No identifiable thesis; article reads as a general overview of TDD",
+            "0": "No central argument; disconnected observations"
+          }
+        },
+        {
+          "criterion": "Argument Structure & Evidence",
+          "weight": 0.3,
+          "scoring": {
+            "5": "Two or more distinct arguments with supporting evidence (statistics, case studies, or expert references); counterargument acknowledged and rebutted; PEEL structure visible in body paragraphs",
+            "3": "Arguments present but evidence is thin or generic; counterargument missing or dismissed without engagement",
+            "1": "Claims made without evidence; no logical structure to the argument progression",
+            "0": "No discernible argumentation; purely descriptive content"
+          }
+        },
+        {
+          "criterion": "Style Consistency",
+          "weight": 0.25,
+          "scoring": {
+            "5": "Consistent professional-accessible tone throughout; no register shifts; active voice dominant; smooth transitions between all sections; varied sentence rhythm",
+            "3": "Mostly consistent tone with 1-2 noticeable shifts; some awkward transitions; occasional passive voice clusters",
+            "1": "Frequent tone shifts between casual and formal; choppy transitions; monotonous sentence structure",
+            "0": "No consistent style; reads like multiple authors wrote different sections"
+          }
+        },
+        {
+          "criterion": "Article Completeness",
+          "weight": 0.2,
+          "scoring": {
+            "5": "Complete article with hook/introduction, thesis, body arguments, counterargument, and strong conclusion with call to action or forward-looking insight; appropriate length",
+            "3": "Article has introduction and body but weak conclusion; may be too short or missing counterargument section",
+            "1": "Incomplete article missing major sections (no introduction or no conclusion)",
+            "0": "Fragment or outline rather than a complete article"
+          }
+        }
+      ],
+      "passThreshold": 60
+    }
+  ]
+}