rfc2119
Skill3 starsChanged 8 months agoCC0-1.0View on GitHub
Enforces RFC 2119 (BCP 14) requirement level keywords in documentation, specifications, and technical writing. Ensures correct usage of MUST, SHOULD, MAY and related terms as defined by RFC 2119 and clarified by RFC 8174. Use when writing or reviewing specs, RFCs, ADRs, design docs, API contracts, or any normative technical document.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Cogni-AI-OU/cogni-ai-agent-skillstheir own version, first seen May 19, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Cogni-AI-OU/cogni-ai-agent-skills★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository48 other files it gives its agents.
- 3d-printingSkill
- app-securitySkill
- architecture-designSkill
- aws-genai-lensSkill
- aws-well-architected-frameworkSkill
- aws-well-architectedSkill
- azure-well-architectedSkill
- blog-post-with-diagramsSkill
- clean-architectureSkill
- clean-codeSkill
- databricks-genie-spaces-best-practicesSkill
- data-visualization-guideSkill
- design-an-interfaceSkill
- design-patternsSkill
- domain-driven-designSkill
- dry-principleSkill
- edit-articleSkill
- event-driven-designSkill
- git-best-practicesSkill
- git-guardrails-claude-codeSkill
- grill-meSkill
- hexagonal-architectureSkill
- improve-codebase-architectureSkill
- language-conventions-source-en-docs-brSkill
- learn-electronicsSkill
- linked-dataSkill
- microservices-skillSkill
- object-oriented-programmingSkill
- oop-design-patternsSkill
- oreilly-design-referenceSkill
- organize-docs-from-zipSkill
- prd-to-issuesSkill
- prd-to-planSkill
- project-context-syncSkill
- request-refactor-planSkill
- scaffold-exercisesSkill
- semverSkill
- setup-pre-commitSkill
- solid-principlesSkill
- tddSkill
- todoSkill
- triage-issueSkill
- ts-otp-awsSkill
- ubiquitous-languageSkill
- ux-design-principlesSkill
- write-a-prdSkill
- write-a-skillSkill
- yagni-principleSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use this skill when writing or reviewing:
- Distinctive: line 76
When writing or reviewing documents, follow these rules:
- Distinctive: line 84
Use MUST / MUST NOT only for absolute requirements and prohibitions.
- Distinctive: line 85
Use SHOULD / SHOULD NOT when exceptions are legitimate but rare.
- Distinctive: line 86
Use MAY when a feature is truly optional and both inclusion and omission are equally valid choices.
- Distinctive: line 90
When a keyword conveys a BCP 14 requirement level, it MUST be written in ALL CAPITALS.
- Distinctive: line 106
When using MUST NOT or SHOULD NOT, the document SHOULD provide guidance on what to do instead.
- Distinctive: line 116
When reviewing a document for RFC 2119 compliance:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
RFC 2119 — Requirement Level Keywords
This skill enforces the correct use of requirement level keywords as defined in RFC 2119 and clarified by RFC 8174 (together forming BCP 14).
When to Use This Skill
Use this skill when writing or reviewing:
- Technical specifications and standards
- Architecture Decision Records (ADRs)
- API contracts and interface documentation
- Design documents with normative requirements
- RFCs or RFC-style documents
- Configuration or policy documents with enforceable rules
- Any document that needs unambiguous requirement levels
Keywords and Their Meanings
Absolute Requirements
| Keyword | Meaning |
| MUST | An absolute requirement of the specification. |
| REQUIRED | Synonym for MUST. |
| SHALL | Synonym for MUST. |
Absolute Prohibitions
| Keyword | Meaning |
| MUST NOT | An absolute prohibition of the specification. |
| SHALL NOT | Synonym for MUST NOT. |
Recommendations
| Keyword | Meaning |
| SHOULD | Valid reasons MAY exist to ignore this item, but the full implications MUST be understood and carefully weighed before choosing a different course. |
| RECOMMENDED | Synonym for SHOULD. |
Discouraged
| Keyword | Meaning |
| SHOULD NOT | Valid reasons MAY exist when the behavior is acceptable or useful, but the full implications SHOULD be understood and the case carefully weighed. |
| NOT RECOMMENDED | Synonym for SHOULD NOT. |
Truly Optional
| Keyword | Meaning |
| MAY | The item is truly optional. Implementations that do not include the option MUST be prepared to interoperate with implementations that do, and vice versa. |
| OPTIONAL | Synonym for MAY. |
RFC 8174 Clarification — Capitalization Rule
Per RFC 8174, only UPPERCASE usage of these keywords carries the special RFC 2119 meaning. When written in lowercase or mixed case, the words have their normal English meaning and are NOT governed by this specification.
MUST→ normative requirement (RFC 2119 meaning)must→ ordinary English usage (no special meaning)Must→ ordinary English usage (no special meaning)
Boilerplate Text
Documents following BCP 14 MUST include this paragraph near the beginning:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 RFC 8174 when, and only when, they appear in all capitals, as shown here.
Rules for Applying Keywords
When writing or reviewing documents, follow these rules:
1. Use Keywords Sparingly
Keywords MUST only be used where actually required for interoperation or to limit behavior with potential for causing harm. They MUST NOT be used to impose a particular method on implementors when the method is not required for interoperability.
2. Choose the Right Level
- Use MUST / MUST NOT only for absolute requirements and prohibitions. Violations mean the implementation is non-conformant.
- Use SHOULD / SHOULD NOT when exceptions are legitimate but rare. The author expects compliance in the vast majority of cases.
- Use MAY when a feature is truly optional and both inclusion and omission are equally valid choices.
3. Always Capitalize When Normative
When a keyword conveys a BCP 14 requirement level, it MUST be written in ALL CAPITALS. When the word is used in its ordinary English sense, it MUST NOT be written in ALL CAPITALS and SHOULD follow normal English capitalization rules.
Correct:
Clients MUST include the
Authorizationheader in every request. The server must be running before tests can execute.
Incorrect:
Clients must include the
Authorizationheader in every request. (ambiguous — is this normative?) The server MUST be running before tests can execute. (over-use — this is not a spec requirement)
4. Elaborate Security Implications
Authors SHOULD document the security implications of not following a MUST or SHOULD, or of doing something marked MUST NOT or SHOULD NOT. Most implementors will not have had the benefit of the experience and discussion that produced the specification.
5. Pair Prohibitions with Alternatives
When using MUST NOT or SHOULD NOT, the document SHOULD provide guidance on what to do instead.
Good:
Passwords MUST NOT be stored in plaintext. They MUST be hashed using a current, approved algorithm such as bcrypt or Argon2.
Insufficient:
Passwords MUST NOT be stored in plaintext.
Checklist for Document Review
When reviewing a document for RFC 2119 compliance:
- The BCP 14 boilerplate paragraph is present near the beginning of the document
- Keywords are ONLY in ALL CAPS when conveying normative meaning
- Lowercase uses of "must", "should", "may", etc. do not carry normative intent
- MUST / MUST NOT are reserved for absolute requirements and prohibitions
- SHOULD / SHOULD NOT are used where exceptions are possible but discouraged
- MAY / OPTIONAL are used for truly optional features
- Keywords are used sparingly and only where necessary
- Security implications of ignoring MUST/SHOULD items are documented
- MUST NOT / SHOULD NOT are paired with alternative guidance where applicable
References
- RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels (March 1997)
- RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words (May 2017)
- BCP 14 (comprises RFC 2119 + RFC 8174)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.