Prompting

Customization

Before executing, check for user customizations at: ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Prompting/

If this directory exists, load and apply any PREFERENCES.md, configurations, or resources found there. These override default behavior. If the directory does not exist, proceed with skill defaults.

🚨 MANDATORY: Voice Notification (REQUIRED BEFORE ANY ACTION)

You MUST send this notification BEFORE doing anything else when this skill is invoked.

1. Send voice notification:

   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the Prompting skill to ACTION"}' \
     > /dev/null 2>&1 &
   

2. Output text notification:

   Running the **WorkflowName** workflow in the **Prompting** skill to ACTION...
   

This is not optional. Execute this curl command immediately upon skill invocation.

Prompting - Meta-Prompting & Template System

What It Does

Generates, optimizes, and composes prompts programmatically. It's the standard library for prompt engineering — other skills call it when they need to build or improve a prompt. The output is always a prompt to be used elsewhere, never the final content itself.

Invoke when: meta-prompting, template generation, prompt optimization, programmatic prompt composition, creating dynamic agents, generating structured prompts from data.

The Problem

Prompt engineering tends to get copy-pasted and rewritten by hand across every skill that needs it, so the same patterns drift apart and best practices live in one person's head. When you want to compose a prompt from data — spin up a custom agent, build an eval judge, generate a phased workflow — there's no clean way to separate the structure from the content. This skill makes structure code and content data: one Handlebars template plus different data renders specialized agents, workflows, and eval frameworks, and the engineering standards live in one place every skill can reference.

Ideal-State Prompting — the Default Standard

Every prompt this library generates or optimizes articulates the ideal state, not the procedure. Say WHAT done looks like (as testable outcomes), the CONSTRAINTS, and the high-quality TOOLS available — then trust the model to find HOW. Reasoning choreography ("first analyze, then consider, then decide") is BPE-violating scaffolding: it caps a capable model and rots as models improve. Ideal-state prompting is more precise, not vaguer — the specificity moves to the outcome.

Four keep-classes are legitimate HOW and survive the cut: safety-gate, verified-gotcha, tool-contract, output-format-contract. Deterministic tools (*.ts) are exempt. The test for any procedural line: would a smarter model make this rule unnecessary? Yes → cut; No → it's a keep-class. Full standard: Standards.md § Ideal-State Prompting.

How It Works

Three pillars carry the work:

• Standards - Anthropic best practices, Claude 4.x patterns, empirical research (markdown-first design, context engineering, the Fabric pattern system, 1,500+ academic papers on prompt optimization). Full guide in Standards.md.
• Templates - Handlebars-based system for programmatic prompt generation: Primitives (Briefing, Structure, Gate, Roster, Voice) plus eval templates (Judge, Rubric, TestCase, Comparison, Report). The agent-specific DynamicAgent.hbs lives in the Agents skill (Agents/Templates/DynamicAgent.hbs), not here.
• Tools - Template rendering (RenderTemplate.ts), validation, and data-content separation.

Workflow Routing

Library skill — no Workflows/ directory. Requests route to the rendering tools and reference docs:

Examples

Example 1: Using Briefing Template (compose an agent brief)

// Render a structured agent brief from data before launching general-purpose
import { renderTemplate } from '${LIFEOS_SKILL_DIR}/Tools/RenderTemplate.ts';

const prompt = renderTemplate('Primitives/Briefing.hbs', {
  briefing: { type: 'research' },
  agent: { id: 'EN-1', name: 'Skeptical Thinker', personality: {...} },
  task: { description: 'Analyze security architecture', questions: [...] },
  output_format: { type: 'markdown' }
});

Example 2: Using Structure Template (Workflow)

# Data: phased-analysis.yaml
phases:
  - name: Discovery
    purpose: Identify attack surface
    steps:
      - action: Map entry points
        instructions: List all external interfaces...
  - name: Analysis
    purpose: Assess vulnerabilities
    steps:
      - action: Test boundaries
        instructions: Probe each entry point...

bun run RenderTemplate.ts \
  --template Primitives/Structure.hbs \
  --data phased-analysis.yaml

Example 3: Render an Agent Brief from Data

// Render a structured agent brief, then launch general-purpose with it
const brief = renderTemplate('Primitives/Briefing.hbs', {
  agent: { name: 'Skeptical Security Reviewer', role: 'auth bypass and input validation' },
  task: { description: 'Review the auth flow', questions: [...] },
});
// Pass `brief` as the prompt to Agent(subagent_type="general-purpose")

Integration with Other Skills

Agents Skill

• Uses Templates/Primitives/Briefing.hbs for agent context handoff
• Uses RenderTemplate.ts to compose dynamic agents
• Maintains agent-specific template: Agents/Templates/DynamicAgent.hbs

Evals Skill

• Uses eval-specific templates: Judge, Rubric, TestCase, Comparison, Report
• Leverages RenderTemplate.ts for eval prompt generation
• Eval templates may be stored in Evals/Templates/ but use Prompting's engine

Development Skill

• References Standards.md for prompt best practices
• Uses Structure.hbs for workflow patterns
• Applies Gate.hbs for validation checklists

Token Efficiency

The templating system eliminated ~35,000 tokens (65% reduction) across LifeOS:

Best Practices

1. Separation of Concerns

• Templates: Structure and formatting only
• Data: Content and parameters (YAML/JSON)
• Logic: Rendering and validation (TypeScript)

2. DRY Principle

• Extract repeated patterns into partials
• Use presets for common configurations
• Single source of truth for definitions

3. Version Control

• Templates and data in separate files
• Track changes independently
• Enable A/B testing of structures

References

Primary Documentation:

• Standards.md - Complete prompt engineering guide
• Templates/README.md - Template system overview
• Tools/RenderTemplate.ts - Implementation details

Official anchors (drift check): the two authoritative Anthropic sources this skill's standards derive from:

• Prompt engineering: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview
• Context engineering: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

When authoring or auditing Standards.md (not on routine template renders), fetch both and flag where our standards diverge from the current official guidance — these pages change with each model family, and standards written against an older one rot silently. Advisory only: report drift, never auto-adopt; unreachable URLs never block the work.

Research Foundation:

• Anthropic: "Claude 4.x Best Practices" (November 2025)
• Anthropic: "Effective Context Engineering for AI Agents"
• Anthropic: "Prompt Templates and Variables"
• The Fabric System (January 2024)
• "The Prompt Report" - arXiv:2406.06608
• "The Prompt Canvas" - arXiv:2412.05127

Related Skills:

• Agents - Dynamic agent composition
• Evals - LLM-as-Judge prompting
• Development - Spec-driven development patterns

Philosophy: Prompts that write prompts. Structure is code, content is data. Meta-prompting enables dynamic composition where the same template with different data generates specialized agents, workflows, and evaluation frameworks. This is core LifeOS DNA - programmatic prompt generation at scale.

Gotchas

• Meta-prompting generates PROMPTS, not content. The output is a prompt that gets used elsewhere — not the final deliverable.
• Templates should be model-agnostic. Don't write prompts that depend on specific model quirks.
• Test generated prompts before declaring them ready. A prompt that looks good may perform poorly.

Execution Log

After completing any workflow, append a single JSONL entry:

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Prompting","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl

Replace WORKFLOW_USED with the workflow executed, 8_WORD_SUMMARY with a brief input description, and SECONDS with approximate wall-clock time. Log status: "error" if the workflow failed.