RFC 2119 SOP Authoring

Overview

Agent SOPs (Standard Operating Procedures) are markdown-based instruction sets that guide AI agents through sophisticated workflows using natural language, parameterized inputs, and RFC 2119 constraint-based execution.

Core principle: Precise control over agent behavior without rigid scripting—RFC 2119 keywords (MUST, SHOULD, MAY) provide graduated constraints that allow agents to adapt while maintaining boundaries.

When to Use

• Creating new workflow automation SOPs

• Structuring multi-step agent workflows with constraints

• Converting processes into reusable parameterized templates

• Validating existing SOP format and structure

• Need graduated constraints (hard requirements vs recommendations vs options)

When NOT to use:

• Simple one-shot instructions (overkill)

• Process doesn't need parameterization (use plain documentation)

• Requirements are binary pass/fail (simpler formats suffice)

RFC 2119 Keywords

You MUST use these keywords as defined in RFC 2119:

Keyword Meaning When to Use

MUST / REQUIRED Absolute requirement Hard constraints that cannot be violated

MUST NOT / SHALL NOT Absolute prohibition Actions that would cause failure/harm

SHOULD / RECOMMENDED Strong recommendation Best practice with valid exceptions

SHOULD NOT / NOT RECOMMENDED Strong discouragement Usually bad but sometimes acceptable

MAY / OPTIONAL Truly optional Agent decides based on context

Required SOP Structure

Every Agent SOP MUST include these sections in order:

[SOP Name]

Overview

[Concise description of what the SOP does and when to use it]

Parameters

• required_param (required): Description
• optional_param (optional, default: "value"): Description

Constraints for parameter acquisition:

• If all required parameters are already provided, You MUST proceed to the Steps
• If any required parameters are missing, You MUST ask for them before proceeding
• When asking for parameters, You MUST request all parameters in a single prompt
• When asking for parameters, You MUST use the exact parameter names as defined

Steps

1. [Step Name]

Description of what happens in this step.

Constraints:

• You MUST [specific requirement]
• You SHOULD [recommended behavior]
• You MAY [optional behavior]

Examples

[Concrete usage examples]

Troubleshooting

[Common issues and solutions]

File Naming & Location

Naming conventions:

• File extension: .sop.md

• Filename: kebab-case (e.g., code-assist.sop.md , idea-honing.sop.md )

• Descriptive names indicating purpose

Location:

• If agent-sops/ directory exists → write there

• Otherwise → current directory or ask user

Parameter Section Rules

Parameter format:

• parameter_name (required): Description of required input
• optional_param (optional): Description of optional input
• with_default (optional, default: "default_value"): Description

Parameter naming:

• Lowercase letters only

• Underscores for spaces (snake_case)

• Descriptive of purpose

• Required parameters listed before optional

Required constraints block:

Constraints for parameter acquisition:

• If all required parameters are already provided, You MUST proceed to the Steps
• If any required parameters are missing, You MUST ask for them before proceeding
• When asking for parameters, You MUST request all parameters in a single prompt
• When asking for parameters, You MUST use the exact parameter names as defined

Steps Section Rules

Each step MUST have:

• Numbered heading: ### 1. Step Name

• Natural language description

• Constraints: section with RFC 2119 keywords

Example step:

1. Setup

Initialize the project environment and create necessary structures.

Constraints:

• You MUST validate directory structure exists
• You MUST create missing directories
• You MUST NOT proceed if directory creation fails
• You SHOULD log all setup actions
• You MAY skip validation if --force flag is provided

Conditional logic:

3. Conditional Processing

If validation passes, proceed with processing. Otherwise, report errors.

Constraints:

• You MUST check validation status before proceeding
• If validation passes, You MUST process the data
• If validation fails, You MUST report specific errors
• You MUST NOT continue with invalid data

Negative Constraints

Always provide context for negative constraints:

✅ Good (with context):

• You MUST NOT use ellipses (...) because output will be read aloud by text-to-speech
• You SHOULD NOT delete Git history since this could corrupt the repository
• You MUST NOT run git push because this could publish unreviewed code

❌ Bad (without context):

• You MUST NOT use ellipses
• You SHOULD NOT delete Git files
• You MUST NOT run git push

Common contexts:

• Technical limitations: "because the system cannot handle..."

• Security risks: "since this could expose sensitive data..."

• Data integrity: "as this could corrupt important information..."

• User experience: "because users will be confused by..."

• Performance: "as this could cause significant slowdowns..."

Validation

Run validation after EVERY change:

From this skill's directory:

./validate-sop.sh path/to/your-sop.sop.md

You MUST fix all errors (❌) before proceeding. You SHOULD address warnings (⚠️) when possible.

Examples Section

Include concrete examples showing:

• Input parameters

• Expected output/behavior

• Common usage patterns

Examples

Example 1: Basic Usage

Input:

• task_description: "Create user authentication system"
• mode: "interactive"

Expected Behavior: Agent will guide through workflow, creating tests first, then implementation.

Troubleshooting Section

Include common issues and solutions:

Troubleshooting

Parameter Validation Fails

If parameter validation fails, check that:

• All required parameters are provided
• Parameter names use snake_case
• Values match expected types

Interactive SOPs

For SOPs requiring user interaction:

• Clearly indicate when user interaction is expected

• Specify how to handle user responses

• Specify where to save interaction records

2. Requirements Clarification

Guide the user through questions to refine their initial idea.

Constraints:

• You MUST ask one question at a time
• You MUST append each Q&A to "idea-honing.md"
• You SHOULD adapt follow-up questions based on previous answers
• You MUST continue until sufficient detail is gathered

Quick Reference: Validation Checklist

Check Requirement

File extension .sop.md

Title H1 heading present

Overview

Overview

section

Parameters

Parameters

with constraints block

Steps

Steps

with numbered headings (### 1. )

Constraints Constraints: in each step

RFC 2119 Uses MUST/SHOULD/MAY keywords

Negative constraints Include "because/since/as" context

Examples

Examples

(recommended)

Troubleshooting

Troubleshooting

(recommended)

Common Mistakes

Missing Parameter Constraints Block

Every Parameters section needs the acquisition constraints block—this ensures consistent behavior.

Numbered Steps Missing

Steps must be numbered: ### 1. Step Name , not ### Step Name

Negative Constraints Without Context

"You MUST NOT do X" leaves agents guessing why. Always explain the reason.

Constraints Outside Steps

Don't put RFC 2119 constraints in Overview—they belong in the Constraints: section within each step.