跳到正文
cccskills
免费在 GitHub 公开

stop-slop

Use when: reviewing or producing any external-facing prose — ADRs, proposals, GitHub comments, Telegram messages, cover letters, client drafts, or planner-mode wording. Removes AI-tell patterns and raises writing quality before output leaves the team.

中文简介正在准备中。当前显示原文说明。

集成工具TelegramGitHub
查看安装方法

包含的文件(1)

  • SKILL.md6.1 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Stop Slop

Adapted from hardikpandya/stop-slop (MIT). Removes predictable AI writing patterns from any external-facing output. Load this skill before finalising any prose that will be read by a human outside the team.

When to Apply

Always-on for Architect and Router when producing or reviewing:

  • ADR context and consequences sections
  • Planner-mode client drafts and proposal wording
  • GitHub issue and PR comments intended for external audiences
  • Telegram or relay messages to the remote team
  • Cover letters, recruiter replies, or stakeholder communications
  • Blog posts, articles, and marketing or campaign copy

Do not apply to internal memory files, ticket descriptions, or code comments — those optimise for precision, not prose.


Eight Rules

1. Eliminate filler. Remove throat-clearing openers ("In today's fast-paced...", "It's important to note that..."), intensifying adverbs ("very", "extremely", "incredibly"), and meta-commentary ("This section explores..."). Start with the claim.

2. Break formulas. Avoid binary contrasts ("not just X, but Y"), rhetorical questions as transitions, and three-part lists that exist for rhythm rather than content. If a structure feels satisfying to write, it probably reads as a template.

3. Use active voice. Human subjects performing actions. Passive constructions ("It was decided that...", "Steps were taken to...") hide agency. Name who does what.

4. Be specific. Name the thing. "Azure Function App processing webhook events" beats "cloud-based solution". "96% test coverage enforced via PR gate" beats "strong quality culture". Vague language signals the writer does not know the detail.

5. Engage directly. Write to a person, not at a concept. Replace distant narration ("One might consider...") with direct address or direct claim.

6. Vary sentence rhythm. Achieve burstiness — deliberate sentence length variance that makes text feel written rather than generated. Uniform sentence length is a structural AI tell regardless of word choice. Mix short declarative sentences with longer ones. Do not end every paragraph on a long clause. Read aloud — if it sounds like a slide deck, rewrite it.

7. Trust the audience. Remove softeners that exist to manage your anxiety rather than the reader's understanding: "It is worth noting that...", "One potential consideration might be...", "While there are many factors...". State the thing.

8. Cut quotable lines. Rewrite any sentence that feels like it belongs on a conference slide or LinkedIn post. Aphorisms in prose are a tell. If it feels clever, it is probably slop.


Banned Phrase Categories

Throat-clearing openers:

  • "In today's world..."
  • "It's important to note..."
  • "As we all know..."
  • "At the end of the day..."
  • "It goes without saying..."

False agency and passive constructions:

  • "Steps were taken to..."
  • "It was decided that..."
  • "Consideration should be given to..."
  • "It has been observed that..."

Vague declaratives:

  • "This is a game-changer."
  • "The results speak for themselves."
  • "We are committed to excellence."
  • "Leveraging best-in-class solutions..."

Structural clichés:

  • "Not just X, but Y." (binary contrast)
  • "First... Second... Finally..." (slide-deck list)
  • "The question is not whether X, but when." (rhetorical formula)
  • "In conclusion..." / "To summarise..."

Unnecessary softeners:

  • "It is worth noting that..."
  • "One might argue..."
  • "While there are many perspectives..."
  • "It could be said that..."

Emerging 2026 AI tells:

  • Hedging stacking — three or more hedging words in one sentence ("it might arguably be worth considering")
  • Markdown bleeding — formatting structure leaking into prose (a sentence that reads like a heading; a paragraph that reads like a list item)
  • Paragraph-reshuffling immunity — all paragraphs of equal length and rhetorical weight; rearranging them would not change the piece
  • Significance inflation — framing routine things as pivotal, transformative, or game-changing

Pre-Submission Checklist

Before sending any external prose, scan for:

  • Em dashes used for stylistic effect — remove or rewrite
  • Adverbs ending in -ly modifying a verb — cut or strengthen the verb
  • Sentences beginning with "Wh-" words as transitions — rewrite
  • Passive voice constructions — rewrite with named subject
  • Any sentence that reads like a pull-quote — cut
  • Any sentence with three or more hedging words — rewrite to a direct claim
  • Any paragraph that could be moved elsewhere without losing meaning — cut or rewrite to anchor it

Scoring Rubric

Score the prose on five dimensions (0–10 each, 50 max). Revise if total < 35.

Dimension0–45–78–10
DirectnessBuried claims, hedged throughoutMain point findable but delayedClaim in first sentence, no hedging
RhythmUniform sentence length, monotoneSome variationDeliberate mix of short and long
TrustConstant softening, qualifies everythingOccasional hedgingTrusts the reader, states directly
AuthenticityMultiple AI-tell phrasesOne or two tellsNo recognisable AI patterns
DensityPadded, repetitive, filler presentReasonable but some wasteEvery sentence earns its place

Score interpretation:

  • 45–50: Ship it
  • 35–44: Minor polish, acceptable
  • 25–34: Rewrite needed before sending
  • < 25: Start over

Exit Criteria

Stop Slop is applied when:

  • the prose passes the pre-submission checklist, or
  • the score is ≥ 35 and no banned phrases remain

Do not loop indefinitely. Two passes maximum. If the content cannot reach 35 after two rewrites, surface it to the team lead rather than polishing further.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Universal guardrails loaded by every agent. Defines Verify Before Reporting (VBR), Write-Ahead Log (WAL), and the security baseline. Always-on, role-independent.

中文简介正在准备中。当前显示原文说明。

Agistra/agistra.dev52026年10月14日 更新

Use when: architecture mode, architect this, ADR, C4, PlantUML, system boundary, design decision, PRD gap, high ambiguity, multiple technical approaches, security architecture, data architecture, integration risk, implementability gap, story ticket, or epic ticket.

中文简介正在准备中。当前显示原文说明。

Agistra/agistra.dev52026年10月14日 更新

Use when: assumptions audit, audit assumptions, check for hidden assumptions, plan/ticket has ambiguous scope edges, pre-flight before finalizing a ticket, unstated assumptions, or 'what am I assuming'. Surfaces unstated assumptions, ambiguous scope edges, and untested preconditions in a finished plan/ticket/ADR before it is handed to Builder. Optional pass — Architect judges when to apply it; not a mandatory gate on every ticket.

中文简介正在准备中。当前显示原文说明。

Agistra/agistra.dev52026年10月14日 更新

Use when: Tester needs UI state evidence for VBR, or Builder needs to verify an integration wire is observable end-to-end. Powered by agent-browser MCP — token-efficient browser automation (200–400 tokens/page).

中文简介正在准备中。当前显示原文说明。

Agistra/agistra.dev52026年10月14日 更新

Use when drafting a bug or defect ticket, reviewing one someone else wrote, or deciding whether a reported problem is ready to file. Keeps what the reporter actually saw separate from what the agent later found out, so a reader can tell which lines are testimony and which are collected proof. Trigger phrases: 'file a bug', 'write up this defect', 'triage this report', 'is this ticket ready to file', 'what did the reporter actually see'.

中文简介正在准备中。当前显示原文说明。

Agistra/agistra.dev52026年10月14日 更新

Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.

中文简介正在准备中。当前显示原文说明。

Agistra/agistra.dev52026年10月14日 更新

查看 Agistra 的全部技能

报告此技能的问题