Speq writing guardrails
Skill marconae/speq-skill/.claude/skills/speq-writing-guardrails
A light-weight and straightforward system for spec-driven development with Claude Code or OpenAI Codex. Written in Rust π¦
npx -y skills add marconae/speq-skill --skill speq-writing-guardrailsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Prose guardrails for speq artifacts and GitHub PRs, issues, and comments β front-loaded (BLUF), terse, unambiguous writing anchored in established style and requirements standards. Triggered by /speq-mission, /speq-audit, /speq-implement, /speq-plan-pr, /speq-implement-pr, planner-agent, plan-reviewer, and recorder-agent.
SKILL.md
3.7 KB, as published. Nobody here has run it
Writing Guardrails
Prose anchored in BLUF / Inverted Pyramid, Strunk & White, INCOSE GtWR, ISO/IEC/IEEE 29148, and RFC 2119 / 8174.
Scope
Governed (free prose β fix these):
plan.mdβ Summary, Goals, Non-Goals, Migration, Testing, Dead-Code, Impact prosespec.mdβ the Feature-description line under# Feature:mission.mdβ Problem, Architecture, Constraints prose- decision-log β Rationale and Finding prose
- verification-report β Notes and Review-Summary bullets, and its condensed PR-comment excerpt
- every GitHub PR, issue, and comment body and title, including advisory/assumption PR comments
Not governed (leave alone): Gherkin scenarios, Background bullets, tables, ASCII diagrams, delta markers, RFC-2119 keyword casing (validator-owned).
PR-facing content β invoke the writing:* skills
For content newly composed for a PR (a verification-report comment, an open-questions/advisory comment, or a plan's ## Impact section), the rules below are necessary but not sufficient β additionally invoke, via the Skill tool, before composing:
writing:clarity-editingwriting:evidence-and-credibilitywriting:revision-and-qa-checklist
Target expert tier Γ Evaluator stance per the Audience-Fit Ladder (writing:revision-and-qa-checklist): the reader is an architect deciding whether to approve β lead with tradeoffs and boundaries, cite the actual diff/file/test as evidence, never pad or hedge.
Structure first β BLUF / Inverted Pyramid
Anchored in NN/g F-pattern and Anthropic context-engineering.
- Lead with the conclusion. State the decision or outcome in the first sentence.
- One idea per paragraph. Split a paragraph that carries two.
- Write statement headings that form a scan path. Prefer
## Rebuild the indexover## Migration. - Make each section self-contained. Agents retrieve sections out of order.
Cut verbosity β "Omit needless words"
Anchored in Strunk & White and Zinsser.
- Cap sentences at 25 words; paragraphs at 3β7 lines. The Summary two-sentence cap is hard.
- Start statements with a verb. Delete
you can,there is,it is worth noting. - Cut adverbs, qualifiers, and hedges. Delete
very,for now, and non-committal time hedges. - Ban filler:
basically,simply,obviously,just,actually.
Kill ambiguity β INCOSE GtWR + ISO/IEC/IEEE 29148
Target: unambiguous, singular, verifiable, complete.
- Quantify vague terms. Write
within 2.0 s, notfast. - Delete escape clauses:
as appropriate,where possible,etc., and the/inand/or. - Use one term per concept. Do not alternate names for one thing.
- Use active voice and name the actor. Write
speq record merges the delta. - Repeat the noun over a distant
itorthis. Pronouns lose their referent across sentences.
Word swaps
| Write | Not |
|---|---|
| use | utilize |
| to | in order to |
| because | due to the fact that |
| now | at this point in time |
| can | has the ability to |
| some | a number of |
| if | in the event that |
Register: descriptive vs normative β RFC 2119 / 8174
- Descriptive prose β warm, concise, present tense.
- Normative statements β ALL-CAPS
MUST/SHOULD/MAY, used sparingly. - Lowercase
shouldis non-binding. Only the ALL-CAPS keyword carries obligation.