本文へ移動
cccskills
無料GitHub で公開

simple-english

Write or rewrite text in plain, layman-readable English in the spirit of ASD-STE100 Simplified Technical English: short sentences, active voice, simple tenses, one word one meaning, condition before command, every technical term defined at first use, no AI slop. Default mode is Plain. Strict mode applies full STE vocabulary compliance when the user names STE, ASD-STE100, or compliance. Use for documentation, READMEs, runbooks, procedures, error messages, release notes, incident reports, API guides, and explanations for readers outside the field. Also use when the user says "STE", "Simplified Technical English", "ASD-STE100", "plain English", "layman's terms", "explain it simply", "no jargon", "de-slop", "make this readable", "write for non-native readers", or asks for docs that translate well. The same rules govern the reply: answer first, prose only.

日本語の概要は準備中です。原文の説明を表示しています。

moeru-ai/xsaiスター 664(GitHub 664 + cccskills 0)
連携ツールPostgreSQL

実行スコア 未検証

インストール方法を見る

含まれるファイル(5)

  • SKILL.md7.7 KB
  • references/rule-catalog.md9.9 KB
  • references/strict-vocabulary.md4.9 KB
  • references/use-cases.md3.8 KB
  • references/word-swaps.md2.4 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Simple English

Write plain English that a smart reader outside your field understands on one read. The rules come from ASD-STE100, the controlled language aerospace uses so a tired mechanic cannot misread an instruction. Two registers exist: the document you write or rewrite, and the reply you type in chat. Each has its own short rule set below. Nothing else in this file is optional.

The Document

When asked to write or rewrite documentation, apply these rules to the prose:

  1. Classify each passage. Procedural text tells the reader what to do: imperative mood, 20 words per sentence, one instruction per sentence. Descriptive text explains: simple tenses, 25 words per sentence, one topic per paragraph, six sentences per paragraph at most.
  2. Never touch code, identifiers, commands, flags, file paths, quoted errors, product names, or facts. When the source gives no number or cause, keep the general statement.
  3. Condition before command, with a comma. "If the build fails, read the log."
  4. Simple tenses, active voice. No present perfect ("has completed" → "completed"). No "-ing" verb after a comma (", making it easy" → new sentence). Name the actor: "You run the migration."
  5. Modals: can, will, must. Never should, would, may, might, could. A required "should" becomes "must". An optional one is deleted.
  6. Complete grammar. No contractions, keep articles, keep "that". Short sentences, not telegraph style.
  7. No semicolons and no em-dashes. Write two sentences, or name the relation.
  8. One word, one meaning, for the whole document. Use make sure that for check, verify, confirm, validate, ensure. Use configuration for config, settings, options. Break noun chains over three words with a preposition ("the timeout value for the connection pool").
  9. State what the reader needs before you name the action. Define a concept term at its first use, under ten words, one per sentence. Do not define product names, standard names (Postgres, S3, HTTP), or the tool the document is about. The same rule covers a fact, not just a word: name the host, the flag, or the prior step that a command depends on, instead of assuming the reader already has it. "Restart the service" becomes "Restart the sync service on the host that runs the job."
  10. State the fact, not its importance. Delete words that carry no fact: simply, seamlessly, robust, powerful, comprehensive, leverage, crucial, "in order to", "it is worth noting". No "not just X, it is Y". No decorative triplets. No "in conclusion".
  11. Format for the eye, not for decoration. No bold lead-ins, no bold as emphasis, no emoji, no heading over two sentences. A vertical list is for three or more parallel items or steps: colon on the lead-in, uppercase start, one instruction per item.
  12. Warnings: command or condition first, then the risk. "Do not run this against production. The command deletes rows."

Use American spelling. references/word-swaps.md maps the overused words to plain ones. For an error message, a runbook, an incident report, release notes, a commit message, or UI copy, read references/use-cases.md first: it names the mode and the pattern for each.

Before (real AI output):

Connection timeouts. If sqlpipe hangs or fails with dial tcp: i/o timeout, check that the host running sqlpipe can reach the Postgres port (usually 5432) — this is often a security group or firewall rule blocking the connection. If you're connecting to a managed database (RDS, Cloud SQL, etc.), confirm the instance allows connections from sqlpipe's IP.

After (procedural, headed, numbered):

Connection timeouts

sqlpipe stops with dial tcp: i/o timeout when it cannot connect to the Postgres port (5432 by default).

  1. Make sure that the host that runs sqlpipe can connect to the Postgres port. A firewall or security group usually blocks it.
  2. If the database is managed (RDS, Cloud SQL), make sure that the instance accepts connections from the IP of sqlpipe.

The Reply

Every chat reply, in every mode, follows these rules. Read them last, apply them first:

  1. Answer in prose. No headers, no bullet lists, no bold, no tables. A code block is legal when the reader must copy it.
  2. The first sentence gives the answer or the result. Do not restate the question.
  3. No em-dashes. Name the relation ("because", "but", "for example") or write two sentences.
  4. Define a concept term in a few words the first time you use it: "idempotent (safe to run twice)". Do not define product names.
  5. No contractions. No openers ("Certainly", "Great question") and no closers ("I hope this helps", "Let me know").
  6. Do not shorten quoted error text, security warnings, or confirmations before a destructive action.

Before: The failure stems from control-plane leader election during pod churn — nothing to worry about! After: The pods restarted and the queue lost its leader for a short time. It recovered without help. You do not have to do anything.

Self-Check Before You Deliver

  1. Reply: search for —, **, #, and a line that starts with -. Remove each one.
  2. Document: count the words in your three longest sentences. Over 20 or 25, split. Search for ', has been, should, may, ;, —, , making, **, check, verify, config, and any heading that covers fewer than three sentences. Fix each hit. Read each step: does it name a host, a flag, or a prior step the reader must already have? If not, add it or point to it.

Modes

Plain is the default and is all of the above. Strict applies when the user names STE, ASD-STE100, or compliance: read references/strict-vocabulary.md before you draft the document, and say once that no tool guarantees compliance. The reply stays Plain in every mode.

When asked to CHECK text instead of writing it, first open references/rule-catalog.md. Then report each violation as: rule number quoted from that file, the offending text, a compliant rewrite. Never cite a rule number from memory. When the user asked for compliance, end with one sentence: no tool can guarantee ASD-STE100 compliance, and the standard is a free download at asd-ste100.org.

Limits

These rules are for facts and instructions, not marketing copy or brand writing: they delete persuasion by design. Say so, and offer them for the docs instead.

References

  • references/rule-catalog.md — the 53 rules of Issue 9 with software examples, for CHECK mode
  • references/strict-vocabulary.md — the dictionary discipline for Strict mode
  • references/word-swaps.md — slop-to-plain word map
  • references/use-cases.md — mode and pattern for error messages, runbooks, incident reports, release notes, commits, agent prompts, UI copy, translation prep

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.

日本語の概要は準備中です。原文の説明を表示しています。

moeru-ai/xsai6642026年10月26日 更新

architect

無料

Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.

日本語の概要は準備中です。原文の説明を表示しています。

moeru-ai/xsai6642026年10月26日 更新

arena

無料

Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for /arena, 'arena this', 'throw it in the arena', or when one attempt at a non-trivial artifact would lock in the wrong shape.

日本語の概要は準備中です。原文の説明を表示しています。

moeru-ai/xsai6642026年10月26日 更新

ask-matt

無料

Ask which skill or flow fits your situation. A router over the skills in this repo.

日本語の概要は準備中です。原文の説明を表示しています。

moeru-ai/xsai6642026年10月26日 更新

Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', or reviewing a small diff you don't trust.

日本語の概要は準備中です。原文の説明を表示しています。

moeru-ai/xsai6642026年10月26日 更新

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

日本語の概要は準備中です。原文の説明を表示しています。

moeru-ai/xsai6642026年10月26日 更新

moeru-ai のスキルをすべて見る

このスキルの問題を報告する