Architecting Atomic AI Toolkits

Given a raw source (SOP, checklist, prompt library, or workflow doc), produce an atomic task spec:

YAML
task_id: extract_invoice_line_items
layer: L4_applied_spec
input_schema:
  document: string   # raw OCR text or PDF-extracted text
  currency_hint: string?  # optional ISO 4217 code
output_schema:
  line_items: array<{description: string, qty: number, unit_price: number, total: number}>
  currency: string
  confidence: number  # 0.0-1.0
edge_cases:
  - "Multi-currency invoice -> REJECT_AMBIGUOUS_CURRENCY"
  - "No line items detected -> REJECT_EMPTY_EXTRACTION"
  - "Total mismatch (sum != stated total) -> ERR_INVARIANT_VIOLATION"
rejection_flags: [REJECT_AMBIGUOUS_CURRENCY, REJECT_EMPTY_EXTRACTION]
error_flags: [ERR_INVARIANT_VIOLATION, ERR_MALFORMED_INPUT]
test_vectors:
  - input: {document: "1x Widget @ $10.00 = $10.00\nTotal: $10.00"}
    expect: {line_items: [{description: "Widget", qty: 1, unit_price: 10.00, total: 10.00}], currency: "USD", confidence: ">0.9"}

This is the atomic unit. Everything else in this skill composes, extracts, or orchestrates units like this.

Progress:

• Step 1: Classify the request — is it (a) decomposing a single task, (b) extracting atomic tasks from a raw source, (c) building a domain inventory, (d) writing full applied specs, or (e) composing a pipeline?
• Step 2: Apply the correct section template below (Sections 1–5)
• Step 3: Run the 5-Point Atomicity Acid Test on every generated task
• Step 4: Attach canonical error/rejection enums
• Step 5: Generate CI/CD test vectors (minimum 3: happy path, edge case, rejection case)
• Step 6: If composing a pipeline, define schema handoffs and verification gates between phases
• Step 7: Output as strict markdown/YAML, no prose padding

Section 1 — Architectural Principles

Atomic Task definition: A function f: I -> O where I is a single, fully-specified input schema, O is a single output schema, and f contains no internal branching logic that produces structurally different output shapes (branching on values within one schema is fine; branching that changes the contract is not).

5-Point Atomicity Acid Test — a task passes only if ALL are true:

1. Single I/O: exactly one input schema, exactly one output schema (no optional alternate output shapes).
2. Zero Branching: no "if X do A-shaped output, else do B-shaped output" logic. Route instead.
3. Independent Testability: can be unit-tested with a fixed input and a deterministic/near-deterministic expected output, without invoking any other task.
4. Conjunction-Free Definition: task name/description contains no "and" joining two distinct responsibilities (e.g., reject "summarize and translate").
5. Decoupled Orchestration: task has zero knowledge of what called it or what will consume its output — no upstream/downstream references in its logic.

System-Action Boundary: cognitive transformations (text-in/text-out reasoning, classification, extraction, generation) are separated from environmental actuation (sending emails, writing files, calling APIs). Atomic tasks are ALWAYS cognitive; actuation is handled by an orchestration layer that consumes task output as a command payload.

Canonical error enums:

• REJECT_* — input is well-formed but the task correctly refuses to produce output (e.g., REJECT_AMBIGUOUS_INPUT, REJECT_OUT_OF_SCOPE, REJECT_INSUFFICIENT_EVIDENCE, REJECT_EMPTY_EXTRACTION)
• ERR_* — input is malformed or an invariant was violated (e.g., ERR_MALFORMED_INPUT, ERR_SCHEMA_MISMATCH, ERR_INVARIANT_VIOLATION, ERR_TIMEOUT)

Section 2 — Extraction Engine

3-Part Extraction Anatomy: Identify -> Convert -> Output

• Identify: locate discrete decision points, steps, or fields in the raw source (bullet lists, numbered steps, table rows, conditional clauses).
• Convert: map each identified unit onto one of the four translation schemas below.
• Output: emit as atomic task specs (Section 1 format) or brick YAML (Section 4 format).

Translation schemas:

Canonical extraction prompt template:

Given the following [SOP/checklist/process doc/prompt library] excerpt, perform 3-part extraction:
1. IDENTIFY: list every discrete step, decision point, or field as a numbered inventory.
2. CONVERT: for each item, state which translation schema applies and why.
3. OUTPUT: emit atomic task specs (per Section 1 template) or bricks (per Section 4 template), one per identified unit. Do not merge two identified units into one output.
SOURCE:
<<<{raw_source}>>>

Section 3 — Atomic Data Task Registry (spec template)

Every registry entry uses this exact structure — no field omitted:

YAML
task_id: <snake_case_id>
layer: L4_applied_spec
domain: <craft|ocr|compliance|chat_audit|math_verification|...>
description: <single sentence, conjunction-free>
input_schema: {...}
output_schema: {...}
edge_cases: [<scenario -> flag>, ...]
rejection_flags: [...]
error_flags: [...]
test_vectors:
  - input: {...}
    expect: {...}
  - input: {...}   # edge case
    expect: {...}
  - input: {...}   # rejection case
    expect: {error: REJECT_X}

Ten core domains to cover when building a full registry: craft state machines, OCR entity extraction, local-first compliance rubrics, chat milestone audits, invariant math verifiers, document classification, sentiment/intent tagging, PII redaction, schema validation, and citation/evidence linking. Each gets a full spec — never abbreviate to "similarly, the other 9 follow the same pattern."

Section 4 — Modular Prompt Brick System

Brick YAML standard:

YAML
brick_id: guardrail_no_pii_leak
type: guardrail
framework: CRTF   # Context-Role-Task-Format
content: |
  Context: You are processing user-submitted text that may contain PII.
  Role: Data protection filter.
  Task: Redact any detected PII (names, emails, phone numbers, SSNs) before returning output.
  Format: Return redacted text with [REDACTED:<type>] tokens in place of removed spans.
variables:
  - name: pii_types
    syntax: "${pii_types:name,email,phone,ssn}"

Frameworks:

• CRTF (Context-Role-Task-Format): for persona-driven or guardrail bricks — sets situational grounding, assigns a role, states the task, constrains the output shape.
• C-P-O (Context-Parameter-Output): for pure transformation bricks — context grounds the domain, parameters are the injected variables, output is the strict schema.

Variable syntax:

• ${var} — required, no default, must be supplied by the orchestrator or the brick fails closed with ERR_MISSING_VARIABLE.
• ${var:default} — optional, falls back to default if unsupplied.

Universal common bricks (reference these instead of re-writing boilerplate):

• guardrail_standard — refuses out-of-scope, harmful, or unverifiable requests; emits REJECT_OUT_OF_SCOPE.
• persona_standard — injects role/tone/expertise framing via ${persona:neutral_expert}.
• format_standard — enforces strict output schema, no prose wrapper, no markdown unless ${format:json} specifies otherwise.
• constraint_standard — enforces length, tone, and prohibited-content constraints via ${max_tokens:512}, ${banned_terms}.

Section 5 — Pipeline Composition & Business Deployment

Topological patterns:

• Sequential Chaining: T1.output -> T2.input -> T3.input. Each handoff validated against a shared schema contract before proceeding.
• Fan-Out/Gather: one input dispatched to N independent atomic tasks in parallel; a gather task merges N outputs into one schema, never silently dropping a branch.
• Logic-Gated Routing: a router task emits route: enum; orchestrator dispatches to exactly one downstream chain matching that enum; unmatched routes → ERR_UNROUTABLE.

5-Phase Freelancer Business-in-a-Box Pipeline:

Each phase is it