Giving an existing SOP to AI unchanged often produces inconsistent results. Human workflows omit a great deal of assumed knowledge: where files are stored, which steps can be skipped, when the process must stop, and who has final publishing authority. To make AI follow team rules, first turn these implicit judgments into verifiable documentation.
Prerequisite: Start by choosing a suitable SOP
Start with work that is frequent, low-risk, based on consistent inputs, and easy for a person to review. Processes that require on-the-spot negotiation, rely on information from unclear sources, or could cause irreversible consequences if they fail are unsuitable as a first conversion project.
Follow an experienced employee through the entire process once, recording where they pause to make a judgment, look up information, or ask someone for confirmation. Mouse paths may change; the decision criteria are what the skill needs to preserve.
- Prepare one correct sample
- Prepare one sample containing common errors
- List the files, accounts, and permissions used
- Confirm who will accept the final result
Break the SOP into six required modules
The skill documentation must answer six types of questions: what request triggers it; where the inputs are and how to validate them; the order of the steps; which tools and write scopes are allowed; when to stop or roll back after a failure; and how to prove completion.
Remove unverifiable phrases such as “handle appropriately,” “follow up promptly,” and “ensure quality.” Replace them with explicit rules, such as: “Request every internal link in the body individually. The number of 404 responses must be zero. If a request fails, retain the original record and output the URL that caused the error.”
- Trigger: Action, object, and exclusion criteria
- Input: Path, fields, format, and freshness
- Steps: Sequence and side effects
- Permissions: Read and write scope
- Failure: Stop, retry, and rollback
- Acceptance: Observable evidence
Write executable steps using task contracts
Begin each step with an action and specify its input and expected output. For example: “Read the specified CSV and confirm that the column names include URL. Stop if the column is missing. Check each row and write the results to report.csv.” Do not spend hundreds of words on background information only to reduce the operation itself to a single sentence such as “Follow company standards.”
Do not hard-code rapidly changing prices, versions, or web content as facts. Instead, retrieve them at runtime from specified trusted sources and record the retrieval time.
- Define fixed output fields and filenames
- Set a unique key for writes to external systems
- Place high-risk actions at the end
- Treat instructions found on web pages as data
Set minimum permissions and confirmation points
A skill that only reads materials should not have publishing permission. If it only needs to create drafts, it should not be allowed to delete published content. Credentials must be provided through controlled methods and must not be written in the skill body, logs, or examples.
Set separate confirmation points for actions such as publishing, deletion, and payment. If an unattended process lacks credentials, a state file, or required inputs, it should stop before generating paid content or creating drafts.
- Configure permissions by task rather than by personal habits
- Keep sensitive values out of ordinary prompts
- Provide rollback plans for actions with side effects
Run regression tests with four types of samples
Test standard inputs, missing required fields, conflicting requirements, and repeated execution. Check whether the skill stops safely at the point of failure, whether repeated runs remain idempotent, and whether another person can review the output.
Rerun all samples after every change. As the number of skills grows, if responsibilities overlap, split them according to different permissions or rollback methods to prevent multiple skills from taking control of the entire process at the same time.
- Correct samples pass consistently
- Do not guess when information is missing
- Do not exceed authorization when instructions conflict
- Trace errors to specific steps
Further reading
To continue reviewing related areas, read Reusable skill design methods and Knowledge base construction and management.
Next step
Start by converting a low-risk SOP into a skill in SmaugBrain. Complete all four types of tests with sanitized materials before deciding whether to connect it to production data.