跳到正文
cccskills
免费在 GitHub 公开

ce-noslop

Draft, edit, or check prose for formulaic wording and readability problems while preserving source facts and the writer’s voice. Use it to produce plain text or receive specific findings without a full rewrite.

中文简介正在准备中。当前显示英语简介。

原文查看原文说明

Rewrite, check, or draft prose so it carries no AI writing tells, reads plainly on the first read, and keeps every source fact. Use when asked to make writing plainer or free of those tells, to check writing for them, or when drafting from supplied content. Use ce-promote for channel-specific marketing copy.

查看安装方法

适用场景

  • Editing a draft while preserving facts and voice
  • Checking prose for formulaic wording
  • Drafting clear prose from supplied material
  • Identifying readability problems without rewriting

包含的文件(3)

  • SKILL.md3.9 KB
  • references/patterns.md7.4 KB
  • references/terminology.md470 B

SKILL.md(原文)

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

Write without slop

Prose that carries no AI tells and that a reader understands on the first read, with every fact the source stated still there. Both goals hold at once: text that is free of tells but still dense has failed, and text that is plain but changes how certain a claim is has failed.

Done: the mode's output is returned, every fact, number, name, quote, and citation in the input survives, and nothing was added that the source or the caller did not supply.

Boundaries: never touch code blocks, quoted text, frontmatter, link targets, identifiers, or a token the caller's own contract requires, unless the user names that content as the thing to fix. Never say whether text was written by a model. Write a named file in place only when the request asks for that; otherwise return the text.

Mode

Take a mode: token when one is given. Otherwise: no draft means author; an imperative on a draft means edit; a question about a draft means detect.

  • author. Hold the tests below while the caller writes; return nothing. When handed content and asked to write, draft it under the same tests.
  • edit. Rewrite only the sentences a test fails on, and return the text. A sentence that passes stays as written, so a second pass on the returned text changes nothing. Say what changed in one line only when the caller asks for it, and keep that line outside the rewritten text and out of any artifact.
  • detect. Name each pattern found, quote the line, give the fix in a few words. Do not rewrite.

For edit and detect, and for an author passage the tests alone do not settle, read references/patterns.md. On text that is not English, apply the tests only. Note that the pattern catalog did not apply inside detect findings or inside a change line the caller asked for, and nowhere else.

Register

Pick by who reads the result. The caller's own interaction contract wins over any line here.

  • Agent talking to the user. The reader is a teammate who knows the domain and did not watch the work. Write each sentence as you would say it to them.
  • Repo or team artifact. Neutral. Match the surrounding document's idiom. No first person, no opinion the artifact does not need. This is the default when no reader is named.
  • The user's own writing. Preserve voice; make the minimum effective edit. Understandability edits stop at sentence splits and actor restoration that keep the user's word choice.

The tests

Apply these to every sentence, in author mode as constraints and in edit or detect mode as checks.

  1. Mechanism. Does the sentence say what the thing does, or how it feels? Replace the feeling with the fact it displaced, or cut the sentence.
  2. Portability. Could the sentence move to another project unchanged? Then it carries no fact about this one.
  3. Actor. Who does the verb? Name them when the source says who. Keep the passive when the actor is unknown or naming it adds nothing.
  4. One idea. Would the reader have to reread to hold the sentence? Split it. A sentence the reader gets on the first pass stays, however long.
  5. Density. One device proves nothing. Three or more distinct patterns in a passage, or one repeated across passages, is a finding.
  6. Decision first. Does the first sentence carry the outcome the reader needs?
  7. Reader. Can someone without the document or the code open act on this? Gloss the identifier or name the consequence.

Keep exact identifiers, paths, commands, and thresholds. For wording choices, read references/terminology.md.

评价

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

评论

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

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

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

0 / 1000 字

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

同一仓库的技能

Monitor an open GitHub pull request over time, respond to review feedback, and address automated check failures. Apply and push fixes, then report whether it appears ready to merge or what still blocks progress.

中文简介正在准备中。当前显示英语简介。

  • Monitoring a pull request until it appears ready to merge
  • Addressing review feedback as it arrives
  • Handling automated check failures during review
EveryInc/compound-engineering-plugin2.6万2026年10月19日 更新

Develop independent solutions to a defined problem, compare them against shared requirements, and combine useful contributions into a coherent recommendation. An independent assessment and evidence checks support the selection, while unresolved tradeoffs and verification needs remain explicit.

中文简介正在准备中。当前显示英语简介。

  • Comparing concrete solutions to a defined problem
  • Developing rough options before choosing an approach
  • Comparing architectural or product proposals
EveryInc/compound-engineering-plugin2.6万2026年10月19日 更新

Turn a vague feature idea into clear requirements through dialogue. Define what to build, its scope, and success criteria, then capture the result in a short chat summary or a requirements document ready for implementation planning.

中文简介正在准备中。当前显示英语简介。

  • Clarifying a vague feature idea
  • Narrowing the scope of an ambitious improvement
  • Documenting requirements before implementation planning
EveryInc/compound-engineering-plugin2.6万2026年10月19日 更新

Review code changes or a pull request for bugs, effects on existing behavior, test gaps, and project standards. Receive findings supported by the code and a clear account of review coverage, with local fixes available when explicitly requested.

中文简介正在准备中。当前显示英语简介。

  • Reviewing a pull request before release
  • Checking changes for bugs and test gaps
  • Applying review findings locally
EveryInc/compound-engineering-plugin2.6万2026年10月19日 更新

ce-commit

免费

Save working changes as local Git commits with messages that explain the outcome. Follow the project's commit style, select files explicitly, and split clearly separate changes into a few logical commits when appropriate.

中文简介正在准备中。当前显示英语简介。

  • Saving completed work as a local commit
  • Writing messages that explain the outcome
  • Separating unrelated changes into commits
EveryInc/compound-engineering-plugin2.6万2026年10月19日 更新

Commit and push code changes, then open a pull request with a clear title and description. You can also draft or update PR descriptions and hand published requests to the follow-up monitoring workflow.

中文简介正在准备中。当前显示英语简介。

  • Committing changes and opening a pull request
  • Drafting only a PR title and description
  • Updating an existing PR description
EveryInc/compound-engineering-plugin2.6万2026年10月19日 更新

查看 EveryInc 的全部技能

报告此技能的问题