Skip to content
cccskills
FreePublished on GitHub

codexkit-sop-writer

Draft standard operating procedures with scope, roles, steps, controls, exceptions, and review cadence. Use when a recurring business process needs clear repeatable instructions.

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md3.5 KB
  • agents/openai.yaml185 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

SOP Writer

When to Use

  • Documenting a recurring office, operations, finance, HR, support, or admin process.
  • Turning tribal knowledge into repeatable instructions.
  • Creating a first SOP draft for review by a process owner.
  • Standardizing handoffs, approvals, evidence capture, or exception handling.

Procedure

Step 1 - Define Scope

State process purpose, start trigger, end state, included work, excluded work, and target users.

Step 2 - Identify Roles

List process owner, performers, approvers, reviewers, and escalation contacts.

Step 3 - Write Procedure

Use numbered steps. Each step should include:

  • action
  • owner
  • input
  • system or document used
  • expected output

Step 4 - Add Controls And Exceptions

Document approval gates, quality checks, evidence retained, common exceptions, and escalation rules.

Step 5 - Add Maintenance

Set review cadence, version owner, and change log expectations.

Inputs

InputRequiredFormat
Process name and goalYesPlain language
Process trigger and end stateRecommendedEvent, deadline, output
Roles involvedRecommendedOwner, performer, approver
Current stepsRecommendedNotes, bullets, transcript
Controls or policiesOptionalApproval rules, compliance needs

Output

# SOP - [Process Name]

## Purpose
## Scope
## Roles And Responsibilities
## Inputs And Systems
## Procedure
## Quality Checks
## Exceptions And Escalation
## Records / Evidence
## Review Cadence
## Changelog

Quality Criteria

  • A new team member can follow the SOP without relying on tribal knowledge.
  • Each step has an owner and expected output.
  • Exceptions and escalation paths are clear.
  • Controls and evidence requirements are included where relevant.
  • The SOP avoids policy overclaims and is marked for process-owner review.

Verification (4C)

CheckQuestion
CorrectnessDoes the SOP match the actual process and tool reality?
CompletenessAre scope, roles, steps, controls, exceptions, evidence, and maintenance covered?
Context-fitIs the level of detail appropriate for process risk and frequency?
ConsequenceWhat could break if someone followed this SOP exactly?

Edge Cases

  • Process is not stable yet - Draft a temporary runbook and mark review date.
  • Multiple teams perform variants - Document the common path first, then add variant sections.
  • Regulated process - Include evidence and approval controls, and require SME/legal/compliance review.
  • No clear owner - Flag ownership as a blocker before finalizing.

Examples

Prompt: "Write an SOP for monthly vendor invoice approval. Include owner roles, approval thresholds, exceptions, and evidence retention."

Bad pattern: A paragraph describing the process. Good pattern: A step-by-step procedure with owner, input, output, control, and escalation.

Definition of Done

  • SOP has a named owner and review cadence.
  • Steps are numbered and executable.
  • Exceptions and evidence handling are documented.
  • Human review requirements are visible.

Changelog

  • v1.0.0 - Initial release

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Design rigorous A/B test plans with hypothesis, sample size calculation, Minimum Detectable Effect (MDE), randomization strategy, and decision rules. Includes guardrail metrics and rollout playbook. Use when planning product experiments, conversion optimization, or data-driven feature decisions.

The English summary is being prepared. Showing the original description.

hoavdc/CodexKit25Updated Oct 11, 2026

Review REST and GraphQL API designs for consistency, usability, and best practices. Covers naming conventions, versioning strategy, error format, pagination, authentication patterns, and breaking change detection. Use when reviewing API specs, designing new APIs, or auditing existing endpoints.

The English summary is being prepared. Showing the original description.

hoavdc/CodexKit25Updated Oct 11, 2026

Write Architecture Decision Records (ADRs) following the Michael Nygard format. Captures context, options considered, decision rationale, and consequences. Use when making technology choices, framework selections, or any architectural decision that future developers need to understand.

The English summary is being prepared. Showing the original description.

hoavdc/CodexKit25Updated Oct 11, 2026

Assess organizational readiness for financial audits (internal or external). Map assertions to account balances, check evidence completeness, score readiness using a Red/Amber/Green framework, and generate a remediation timeline. Aligned with SOX, IFRS, and GAAP audit standards. Use before scheduled audits or when preparing for first-time compliance.

The English summary is being prepared. Showing the original description.

hoavdc/CodexKit25Updated Oct 11, 2026

Design safe recurring Codex automations with clear prompts, outputs, schedules, and gating rules.

The English summary is being prepared. Showing the original description.

hoavdc/CodexKit25Updated Oct 11, 2026

Refine Product Backlog Items to meet INVEST criteria. Write User Stories with Acceptance Criteria in Given/When/Then format, estimate with Story Points, and flag dependencies. Use before sprint planning when backlog items need grooming. Do not use to prioritize the backlog — that is the Product Owner's decision.

The English summary is being prepared. Showing the original description.

hoavdc/CodexKit25Updated Oct 11, 2026

See all skills by hoavdc

Report a problem with this skill