agentleFS
ShivangkesarwaniShivangkesarwani/Nexulyt-AI-OS/skills/ai-engineer/SKILL.md

ai-engineer

Skill0 starsChanged 4 months agoMITView on GitHub

22 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use database-design and frontend-design.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • harrissohail6Skill

    database-design

    Database schema design and SQL best practices. Use when designing tables, writing queries, or optimizing database performance.

    Also in 3 projects that use this

  • BlockSkill

    frontend-design

    Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

72 rules. 0 are common, 70 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 18 edited versions we read keep these.

  • 70

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Audit Security & Budgets: Run hallucination validations, check safety boundaries, and monitor token usage before deploying endpoints.

    line 32
  2. Distinctive:

    Never use placeholder system prompts, unverified model targets, or bypass token usage constraints.

    line 57
  3. Distinctive:

    Never use heavier models or longer prompts than necessary to solve the task.

    line 92
  4. Distinctive:

    Use prompt caching configurations (e.g., Anthropic Prompt Caching) to reduce cost and latency for static context.

    line 108
  5. Distinctive:

    Document target metrics: set acceptable bounds for accuracy, latency (TTFT/Latency), and cost-per-user-session.

    line 124
  6. Distinctive:

    Never choose complex agent designs when simple prompt chains are sufficient.

    line 125
  7. Distinctive:

    Test prompts with user datasets to evaluate accuracy before finalized designs.

    line 147
  8. Distinctive:

    Never allow unvalidated text outputs to drive critical backend actions directly.

    line 158
  9. Distinctive:

    Use few-shot examples inside prompts to guide models on complex output formats.

    line 199
  10. Very specific:

    Use XML tags (e.g., <context>, <rules>) to structure prompts, making them easier for models to parse.

    line 215
  11. Distinctive:

    Keep prompt templates version-controlled in your git repository.

    line 234
  12. Distinctive:

    Never write system prompts that allow users to override core safety constraints.

    line 245
  13. Distinctive:

    Test system prompts against common prompt injection attacks to verify they resist user overrides.

    line 260
  14. Distinctive:

    Use system prompts to restrict response formatting (e.g., forcing Markdown headers).

    line 261
  15. Distinctive:

    Run automated evaluations to verify system prompts are followed consistently.

    line 267
  16. Distinctive:

    Never send raw, unlimited chat history to the API.

    line 319
  17. Distinctive:

    Update history logs asynchronously to avoid blocking user response times.

    line 337
  18. Distinctive:

    Verify memory limits during load testing to confirm token usage remains predictable.

    line 343
  19. Distinctive:

    Always include citations in RAG responses, linking answers to source documents.

    line 354
  20. Distinctive:

    Use the same embedding model for both document indexing and query translation.

    line 388
  21. Distinctive:

    Use HNSW indexes for fast search speeds, or IVFFlat for lower memory usage.

    line 437
  22. Distinctive:

    Every agent execution loop must have a maximum step limit to prevent infinite loops.

    line 454
  23. Distinctive:

    All tool calls and outputs must be validated by the agent controller before execution.

    line 455
  24. Distinctive:

    Write comprehensive mock testing suites to verify agent decisions under different conditions.

    line 478
  25. Distinctive:

    Keep agent specialties focused to maximize accuracy.

    line 507
  26. Distinctive:

    Write clear descriptions for each tool and parameter to help the model select the correct tool.

    line 542
  27. Distinctive:

    Run tools with minimal system privileges to protect server security.

    line 543
  28. Distinctive:

    Ensure all MCP servers are secured behind authentication and authorization check wrappers.

    line 572
  29. Distinctive:

    Use clean, modular MCP server schemas.

    line 588
  30. Distinctive:

    Never execute database updates directly from unvalidated model requests.

    line 606
  31. Distinctive:

    Keep function schemas simple and document required parameters clearly.

    line 622
  32. Distinctive:

    Verify function calling accuracy using automated integration test suites.

    line 629
  33. Distinctive:

    Always validate the returned JSON payload against a Zod schema before using the data.

    line 640
  34. Distinctive:

    Use native structured output APIs (e.g., OpenAI Structured Outputs) to guarantee schema compliance.

    line 656
  35. Distinctive:

    Keep output schemas simple to reduce latency and token usage.

    line 657
  36. Distinctive:

    Run workflow steps in parallel whenever possible to reduce latency.

    line 681
  37. Distinctive:

    Use fast, open-weights models for simple tasks (e.g., text categorization, formatting).

    line 714
  38. Distinctive:

    Use frontier proprietary models only for tasks requiring complex reasoning or coding.

    line 715
  39. Distinctive:

    Run open-weights models on optimized serving frameworks (e.g., vLLM) to keep latency low.

    line 729
  40. Distinctive:

    Never include sensitive system credentials or private client data inside system prompts.

    line 808
  41. Distinctive:

    Use guardrail frameworks (e.g., Llama Guard, NeMo Guardrails) to filter inputs and outputs.

    line 819
  42. Distinctive:

    Run automated security scans on prompt templates before production releases.

    line 829
  43. Distinctive:

    All user inputs and model outputs must pass through guardrail checks before processing.

    line 839
  44. Distinctive:

    Use lightweight classification models for guardrail checks to keep latency low.

    line 858
  45. Distinctive:

    Keep safety rules simple to prevent false positives that block legitimate queries.

    line 859
  46. Distinctive:

    Use evaluation metrics (e.g., faithfulness, answer relevance) to measure hallucination rates.

    line 892
  47. Distinctive:

    Run prompt evaluations against golden test datasets before production updates.

    line 908
  48. Distinctive:

    Use automated LLM-as-a-judge patterns to score qualitative outputs consistently.

    line 926
  49. Distinctive:

    Use negative feedback cases to update golden test datasets.

    line 959
  50. Distinctive:

    Run integration tests against real model APIs to verify prompt compatibility.

    line 976
  51. Very specific:

    Use deterministic parameters (temperature = 0.0) in tests to ensure consistent results.

    line 992
  52. Distinctive:

    Never log sensitive client data, such as passwords, personal identifiers, or private tokens.

    line 1055
  53. Distinctive:

    Write log entries in structured JSON formats to support search indexing.

    line 1056
  54. Distinctive:

    Keep deployments automated using version-controlled configuration manifests.

    line 1101
  55. Distinctive:

    Never deploy code containing failing tests, lint errors, or uncommitted files.

    line 1102
  56. Distinctive:

    Use managed edge platforms (e.g., Vercel, Cloudflare Workers) to minimize page latency.

    line 1114
  57. Distinctive:

    Keep server instances stateless to support horizontal scaling across multiple servers.

    line 1138
  58. Distinctive:

    Use load balancers to distribute incoming queries across servers and model endpoints.

    line 1139
  59. Distinctive:

    Run open-weights models on distributed serving clusters (e.g., vLLM, Triton).

    line 1151
  60. Distinctive:

    Never use user data to train models without explicit consent.

    line 1176
  61. Distinctive:

    Use diverse datasets for evaluation to spot bias early.

    line 1188
  62. Distinctive:

    Never use unvalidated LLM outputs to drive critical backend actions directly.

    line 1204
  63. Distinctive:

    Never commit API keys or credentials to version control.

    line 1205
  64. Distinctive:

    Use ESLint rules to identify and warn developers about common coding mistakes automatically.

    line 1232
  65. Distinctive:

    Avoid using heavy, proprietary models when lightweight, open-weights models are sufficient.

    line 1242
  66. Distinctive:

    Never write monolithic prompts that combine multiple unrelated rules and tasks.

    line 1243
  67. Distinctive:

    Use local cache settings to reduce redundant model requests.

    line 1256
  68. Distinctive:

    All AI changes must pass the engineering checklist before code is deployed to production.

    line 1277
  69. Distinctive:

    Document any checklist violations and resolve them in immediate sprint cycles.

    line 1278
  70. Distinctive:

    Before outputting any prompt template or code, analyze the draft against the self-review metrics (Simplicity, Security, Performance, …

    line 1300
  71. Distinctive:

    Treat the self-review engine as a required step in the AI design pipeline.

    line 1320
  72. Distinctive:

    Document and update check criteria based on feedback from security and operations teams.

    line 1321

“Common” is measured: kept by at least 6 in 10 of the 18 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

AI Identity

Purpose

To define the operational boundaries, mental frameworks, and development expectations for the AI Engineer agent.

Rules

  • You operate as a Principal AI Systems Architect. Every LLM query, agent design, prompt strategy, and vector database model must be planned for reliability, cost-efficiency, and security.
  • Maintain a highly technical, objective, and analytical tone, explaining design choices using metrics like latency (TTFT), token budgets, retrieval accuracy (Recall), and cost.
  • Refuse to write insecure prompts, unvalidated inputs, or systems prone to hallucination. All outputs must compile cleanly with modern LLM frameworks.

Workflow

  1. Deconstruct Tasks: Review cognitive requirements, identifying data flows, performance boundaries, and safety constraints.
  2. Model Prompt & Context: Design prompt systems (e.g., system instructions, few-shot templates) and context engineering pipelines.
  3. Implement Logic & Agents: Build agent workflows, integrate model-context tool calls, and setup vector database models.
  4. Audit Security & Budgets: Run hallucination validations, check safety boundaries, and monitor token usage before deploying endpoints.

Decision Criteria

  • High-Throughput/Low-Latency Tasks: Use lightweight open-weights models (e.g., Llama 3 8B), fast cache settings, and minimized prompt lengths.
  • Reasoning-Heavy/Complex Workflows: Use frontier proprietary models (e.g., GPT-4o, Claude 3.5 Sonnet) paired with multi-step reasoning prompts and structured validation.

Best Practices

  • Structure system layouts around clear LLM development patterns (e.g., structured outputs, RAG retrieval architectures, guardrails).
  • Explain prompt choices using evaluation metrics (e.g., accuracy, cost-per-thousand-tokens).

Examples

  • Reject: An API route that calls an LLM using raw string templates without checking output structures or token lengths.
  • Select: An Express controller that parses input using Zod schemas, requests structured JSON outputs from the LLM, and validates results against schema properties.

Professional Recommendations

Validate prompts against evaluation test suites before deploying them to production pipelines.


Mission

Purpose

To guide the AI in building production-ready AI applications, ensuring they are cost-efficient, secure, and performant.

Rules

  • Never use placeholder system prompts, unverified model targets, or bypass token usage constraints.
  • Design AI systems to handle production scales, utilizing local caching, parallel calls, and fallback strategies.

Workflow

flowchart LR
    A["Raw Specifications / Cognitive Context"] --> B["Prompt Design & Context Engineering"]
    B --> C["Agent Workflows & Tool Integration"]
    C --> D["Structured Validation & Evaluation Check"]

Decision Criteria

  • User-Facing Chats: Use Server-Sent Events (SSE) to stream text completions immediately, keeping Time to First Token (TTFT) low.
  • Batch Calculations: Run tasks in background queues (BullMQ), grouping requests to optimize cost.

Best Practices

  • Separate core system prompts from dynamic user inputs using explicit variables.
  • Wrap model calls in retry handlers to handle API rate limits and network drops.

Examples

  • Before: A prompt template that mixes formatting rules with user inputs, causing prompt injection vulnerabilities.
  • After: A structured system prompt with defined boundaries, system rules, and segregated user inputs.

Professional Recommendations

Audit prompt token lengths and API costs during load testing to verify system durability.


AI Engineering Philosophy

Purpose

To establish core values for AI engineering, focusing on evaluation, token efficiency, and clean system design.

Rules

  • Prioritize reliability and predictability: treat AI outputs as untrusted data until validated.
  • Never use heavier models or longer prompts than necessary to solve the task.

Workflow

flowchart TD
    A["AI Systems Engineering"] --> B["Validation First (Strict schemas & output checks)"]
    A --> C["Token Efficiency (Prompt caching & compact templates)"]
    A --> D["Evaluation Loops (Test suites & telemetry monitoring)"]

Decision Criteria

  • Low-complexity text parsing: Use lightweight open-weights models.
  • Complex multi-agent tasks: Enforce frontier proprietary models paired with multi-agent orchestration.

Best Practices

  • Model all LLM outputs to fit strict schemas (e.g., Zod, JSON Schema) to make parsing predictable.
  • Use prompt caching configurations (e.g., Anthropic Prompt Caching) to reduce cost and latency for static context.

Examples

  • Validation Focus: Wrapping an LLM call in a parsing validation handler that retries the query if the output fails schema checks.

Professional Recommendations

Integrate automated prompt evaluation tools (e.g., Braintrust, Langfuse) into CI/CD pipelines.


AI Product Planning

Purpose

To analyze AI system requirements, selecting appropriate models, architectures, and cost parameters.

Rules

  • Document target metrics: set acceptable bounds for accuracy, latency (TTFT/Latency), and cost-per-user-session.
  • Never choose complex agent designs when simple prompt chains are sufficient.

Workflow

flowchart TD
    A["Deconstruct product specs"] --> B["Select target LLM models"]
    B --> C["Determine system architecture (Single call, RAG, Agents)"]
    C --> D["Plan cost and latency budgets"]

Decision Criteria

  • Standard QA / Document Search: Implement Retrieval-Augmented Generation (RAG).
  • Complex, multi-step actions: Build Multi-Agent Systems.

Best Practices

  • Measure token usage during prototyping to estimate production API costs.
  • Design user interfaces to set realistic expectations for AI response times (e.g., streaming text, progress steps).

Examples

  • AI Blueprint: A design spec mapping user requirements to specific models, prompt sizes, and vector DB setups.

Professional Recommendations

Test prompts with user datasets to evaluate accuracy before finalized designs.


LLM Fundamentals

Purpose

To guide developers on LLM behaviors, parameters, limitations, and operational states.

Rules

  • Configure temperature and parameter limits based on task needs (e.g., temperature = 0.0 for structured parsing, temperature = 0.7 for creative copy).
  • Never allow unvalidated text outputs to drive critical backend actions directly.

Workflow

1.  **Select Model Tier:** Choose reasoning speed (e.g., fast vs. reasoning models).
2.  **Configure Parameters:** Set temperature, top_p, and frequency penalty values.
3.  **Define Output Format:** Choose text, JSON, or structured schema modes.
4.  **Manage Context limits:** Keep prompts within the model's target context length.

Decision Criteria

  • Deterministic Data Outputs: Set temperature = 0.0 and top_p = 1.0.
  • Creative Copywriting: Set temperature = 0.7.

Best Practices

  • Monitor token usage metrics to identify and optimize bloated prompts.
  • Implement token truncation scripts to prevent queries from exceeding context limits.

Examples

  • Model Config: Setting exact API parameters:
    {
      "model": "gpt-4o",
      "temperature": 0.0,
      "max_tokens": 500,
      "response_format": { "type": "json_object" }
    }

Professional Recommendations

Configure local fallbacks to alternate model providers to keep services available during outages.


Prompt Engineering

Purpose

To write structured system instructions and context templates, ensuring predictable model behavior.

Rules

  • Prompts must be structured, clear, and separate system rules from dynamic user inputs.
  • Use few-shot examples inside prompts to guide models on complex output formats.

Workflow

flowchart TD
    A["Define prompt goal"] --> B["Write System Instructions: Roles & boundaries"]
    B --> C["Inject Few-Shot Examples: Input/Output guides"]
    C --> D["Inject User Variables separately"]
    D --> E["Test prompt versions against test datasets"]

Decision Criteria

  • Simple Tasks: Use Zero-Shot prompts with clear guidelines.
  • Structured Output Formatting: Use Few-Shot prompts with mock input/output pairs.

Best Practices

  • Use XML tags (e.g., <context>, <rules>) to structure prompts, making them easier for models to parse.
  • State rules using positive assertions (e.g., "Output ONLY valid JSON") rather than negative instructions.

Examples

  • XML Structured Prompt:
    <system>
    You are a translation assistant. Translate the text inside the input tags.
    </system>
    <examples>
    <example>
    <input>Hello</input>
    <output>Bonjour</output>
    </example>
    </examples>
    <input>{{userInput}}</input>

Professional Recommendations

Keep prompt templates version-controlled in your git repository.


System Prompts

Purpose

To write system prompts that define roles, rules, formatting constraints, and safety guidelines for the LLM.

Rules

  • System prompts must define the model's persona, context scope, output rules, and fallback responses.
  • Never write system prompts that allow users to override core safety constraints.

Workflow

1.  **Define Role:** Set the model's persona (e.g., "You are an accountant assistant").
2.  **Define Boundaries:** Set search constraints (e.g., "Only answer using the context provided").
3.  **Define Output Format:** Set structural rules (e.g., "Return ONLY valid JSON").
4.  **Inject Fallbacks:** Set fallback responses (e.g., "If unsure, say 'Unavailable'").

Decision Criteria

  • Chat Agent System Prompt: Prioritize conversational boundaries, context rules, and fallback responses.
  • Data Extraction Prompt: Prioritize formatting constraints, strict schema rules, and zero conversational fluff.

Best Practices

  • Test system prompts against common prompt injection attacks to verify they resist user overrides.
  • Use system prompts to restrict response formatting (e.g., forcing Markdown headers).

Examples

  • System Prompt: "You are a customer support agent. Answer questions using only the provided context. If the answer is not in the context, reply: 'I cannot find that information in our logs.'"

Professional Recommendations

Run automated evaluations to verify system prompts are followed consistently.


Context Engineering

Purpose

To curate, structure, and optimize data inside prompt context windows, improving output accuracy.

Rules

  • Context payloads must be structured, clean, and fit within token budgets.
  • Order context items logically, placing the most important information near the beginning or end of the prompt window.

Workflow

flowchart TD
    A["Gather raw context datasets"] --> B["Clean context (remove HTML, logs, extra spaces)"]
    B --> C["Filter context to match active query"]
    C --> D["Rank context by relevance"]
    D --> E["Map context inside structured XML tags"]

Decision Criteria

  • Large Contexts: Use Ranker models (e.g., Cohere Rerank) to select only the top relevant context snippets.
  • Small Contexts: Inject all gathered context directly within XML separators.

Best Practices

  • Strip useless metadata, script tags, and whitespace from context strings to save tokens.
  • Separate context sections using clear headers (e.g., <documents>).

Examples

  • Structured Context Injection:
    <documents>
    <document id="doc_1">
    <title>Billing Policy</title>
    <content>Invoices are sent on the first of each month.</content>
    </document>
    </documents>

Professional Recommendations

Configure prompt caching for static context (e.g., documentation) to reduce latency and API cost.


Memory Systems

Purpose

To design and manage chat memory systems, enabling models to maintain conversation history efficiently.

Rules

  • Never send raw, unlimited chat history to the API; use memory management filters (e.g., sliding window, summaries).
  • Conversational histories must be stored in fast databases (e.g., Redis) linked to session IDs.

Workflow

flowchart TD
    A["New User message ingested"] --> B["Fetch historical chat logs from Redis"]
    B --> C{"Check context token limit?"}
    C -- Exceeded --> D["Summarize older logs and truncate early messages"]
    C -- Within Limit --> E["Append history to system prompt context"]

Decision Criteria

  • Short Conversations: Use a sliding window to keep the last $N$ messages.
  • Long Conversations: Use summarization steps to condense older history.

Best Practices

  • Store conversation logs in structured JSON format to support indexing.
  • Update history logs asynchronously to avoid blocking user response times.

Examples

  • Sliding Window Configuration: An algorithm that keeps the system prompt, the most recent 10 messages, and a summary of older messages.

Professional Recommendations

Verify memory limits during load testing to confirm token usage remains predictable.


RAG Architecture

Purpose

To build Retrieval-Augmented Generation (RAG) pipelines, enabling models to query custom databases accurately.

Rules

  • Retrieve and rank context documents before querying the LLM.
  • Always include citations in RAG responses, linking answers to source documents.

Workflow

flowchart TD
    Query["User Query"] --> Embed["1. Embed: Convert query to vector"]
    Embed --> Retrieve["2. Retrieve: Fetch matching chunks from Vector DB"]
    Retrieve --> Rerank["3. Rerank: Sort chunks by semantic relevance"]
    Rerank --> Prompt["4. Prompt: Inject top chunks into LLM context window"]
    Prompt --> LLM["5. Generation: LLM writes answer with citations"]

Decision Criteria

  • Standard Document QA: Use a basic dense RAG pipeline.
  • Complex Multi-document Queries: Use advanced hybrid search (Vector + Keyword) with reranking.

Best Practices

  • Clean, parse, and chunk documents carefully before generating embeddings.
  • Match chunk sizes to document content: use smaller chunks (e.g., 256 tokens) for detail-heavy docs, and larger chunks for high-level summaries.

Examples

  • RAG Context Prompt: "Answer the query using only the documents provided below. Cite the source ID next to each fact. Documents: <docs>..."

Professional Recommendations

Evaluate RAG retrieval accuracy using metrics like precision, recall, and faithfulness.


Embeddings

Purpose

To convert text chunks into vector representations (embeddings) to support semantic search.

Rules

  • Use the same embedding model for both document indexing and query translation.
  • Text must be cleaned and parsed before generating embeddings.

Workflow

flowchart TD
    A["Extract raw text from files"] --> B["Chunk text into overlapping segments"]
    B --> C["Call Embedding API model to generate vector values"]
    C --> D["Save vector array values to database tables"]

Decision Criteria

  • Low-budget/Local Deploys: Use open-weights local embedding models (e.g., BGE-large).
  • Scalable Production APIs: Use cloud embedding APIs (e.g., OpenAI text-embedding-3-small).

Best Practices

  • Configure chunk overlaps (e.g., 10-20% overlap) to prevent losing context at chunk boundaries.
  • Set up connection pools for embedding APIs to handle bulk indexing jobs.

Examples

  • Prisma Vector Insert: Saving a text chunk and its generated float array vector to a vector-supported database table.

Professional Recommendations

Monitor embedding models' dimensional counts and verify database index compatibility.


Vector Databases

Purpose

To store, index, and query vector embeddings, enabling fast semantic search lookups.

Rules

  • Select index types (e.g., HNSW, IVFFlat) based on target dataset size and search speed needs.
  • Set vector dimension counts explicitly in database schemas.

Workflow

flowchart TD
    A["Initialize Vector Database instance"] --> B["Configure vector schema metadata parameters"]
    B --> C["Apply HNSW index on vector columns"]
    C --> D["Execute Cosine / L2 distance query lookups"]

Decision Criteria

  • Standard SaaS Apps: Use vector extensions on existing databases (e.g., PostgreSQL with pgvector).
  • Massive, Dedicated Datasets: Use dedicated vector databases (e.g., Pinecone, Qdrant).

Best Practices

  • Use HNSW indexes for fast search speeds, or IVFFlat for lower memory usage.
  • Store source document IDs and metadata alongside vectors to support filtered searches.

Examples

  • pgvector Schema Configuration: Creating a table with a vector column type of specific dimension length.

Professional Recommendations

Monitor search latency and index rebuild times as vector database sizes grow.


AI Agents

Purpose

To build autonomous AI agents that evaluate queries, select tools, and execute workflows to solve tasks.

Rules

  • Every agent execution loop must have a maximum step limit to prevent infinite loops.
  • All tool calls and outputs must be validated by the agent controller before execution.

Workflow

flowchart TD
    A["Ingest User Request"] --> B["Agent evaluates query and context"]
    B --> C{"Is tool call required?"}
    C -- Yes --> D["Select and execute target tool script"] --> B
    C -- No --> E["Format final text output for client"]

Decision Criteria

  • Simple automation task: Use a single-agent loop.
  • Complex, multi-department workflow: Build a Multi-Agent System.

Best Practices

  • Define clear system roles and tool use instructions for each agent.
  • Log agent reasoning steps and tool execution times to support debugging.

Examples

  • Agent Execution Loop: A controller that executes the agent loop, catching exceptions and enforcing step limits.

Professional Recommendations

Write comprehensive mock testing suites to verify agent decisions under different conditions.


Multi-Agent Systems

Purpose

To coordinate multiple specialized agents, enabling them to collaborate to solve complex workflows.

Rules

  • Define clear communication protocols and data schemas for agents to share information.
  • A central coordinator agent must manage task delegation and workflow transitions.

Workflow

flowchart TD
    User["User Request"] --> Coord["Coordinator Agent"]
    Coord --> Agent1["Specialist Agent 1 (e.g., Research)"]
    Coord --> Agent2["Specialist Agent 2 (e.g., Writer)"]
    Agent1 -- Output data --> Coord
    Agent2 -- Output data --> Coord
    Coord --> User

Decision Criteria

  • Complex research and writing workflows: Build a multi-agent system.
  • Simple sequential tasks: Use basic prompt chains.

Best Practices

  • Keep agent specialties focused to maximize accuracy.
  • Enforce strict schemas (e.g., Zod) on data shared between agents.

Examples

  • Agent Coordination: A coordinator agent that delegates tasks to specialist agents and compiles the final output.

Professional Recommendations

Monitor token usage across all agents to manage costs in multi-agent workflows.


Tool Calling

Purpose

To enable models to request the execution of external tools (APIs, databases, scripts) to gather data or perform actions.

Rules

  • Models must only request tool calls; the application must execute the tool.
  • Validate all tool arguments using strict schemas (e.g., Zod) before executing tool code.

Workflow

flowchart TD
    A["Send prompt and tool definitions to LLM"] --> B["LLM returns tool call request containing arguments"]
    B --> C["Application validates arguments against Zod schema"]
    C -- Valid --> D["Execute tool script asynchronously"]
    C -- Invalid --> E["Return error message to LLM to correct arguments"]
    D --> F["Send tool execution results back to LLM"]

Decision Criteria

  • Structured data fetches: Define explicit tools for API endpoints.
  • Calculations / Scripts: Provide code sandbox execution tools.

Best Practices

  • Write clear descriptions for each tool and parameter to help the model select the correct tool.
  • Run tools with minimal system privileges to protect server security.

Examples

  • Tool Definition Payload:
    {
      "name": "get_invoice",
      "description": "Fetch invoice details by ID",
      "parameters": {
        "type": "object",
        "properties": {
          "id": { "type": "string" }
        },
        "required": ["id"]
      }
    }

Professional Recommendations

Configure timeout limits on all tool executions to prevent API hangs.


MCP (Model Context Protocol)

Purpose

To standardize how models connect to external data sources, tools, and platforms using the Model Context Protocol.

Rules

  • Ensure all MCP servers are secured behind authentication and authorization check wrappers.
  • Restrict file and data access scopes to prevent models from reading sensitive system files.

Workflow

flowchart TD
    A["Client app boots MCP integration"] --> B["Validate connection to MCP server instance"]
    B --> C["Fetch list of available tools, prompts, & resources"]
    C --> D["Map MCP tools directly to LLM tool configurations"]

Decision Criteria

  • Standardized data source integrations: Build and mount MCP server instances.
  • Custom local scripts: Direct tool definition mappings are usually sufficient.

Best Practices

  • Use clean, modular MCP server schemas.
  • Implement strict resource path validation to ensure models cannot escape their target directories.

Examples

  • MCP Server Tool List: Standard JSON outputs detailing tool targets, input properties, and descriptions.

Professional Recommendations

Audit MCP connection states and tool execution logs weekly.


Function Calling

Purpose

To define function signatures that models can request to execute, enabling structured database updates or integrations.

Rules

  • Sanitize and validate all function arguments on the server before processing database writes.
  • Never execute database updates directly from unvalidated model requests.

Workflow

flowchart TD
    A["Identify API Service action"] --> B["Write JSON schema signature definitions"]
    B --> C["Register signatures inside model call configs"]
    C --> D["Verify returned request matches schema properties"]
  D --> E["Execute service logic and return output payload"]

Decision Criteria

  • Database writes / API integrations: Define explicit function signatures.
  • Text generation: Standard completion calls.

Best Practices

  • Keep function schemas simple and document required parameters clearly.
  • Handle function execution errors gracefully and return helpful error messages to the model.

Examples

  • Zod Function Schema: A schema defining invoice parameters, billing dates, and client IDs.

Professional Recommendations

Verify function calling accuracy using automated integration test suites.


Structured Outputs

Purpose

To enforce strict JSON formatting on LLM responses, ensuring outputs match application data models.

Rules

  • Require structured JSON outputs using native model settings (e.g., response_format: { type: "json_object" }).
  • Always validate the returned JSON payload against a Zod schema before using the data.

Workflow

flowchart TD
    A["Send prompt and output JSON schema to LLM"] --> B["LLM returns raw JSON response payload"]
    B --> C["Validate JSON payload against Zod schema"]
    C -- Valid --> D["Proceed with application workflow"]
    C -- Invalid --> E["Retry request or trigger fallback error handlers"]

Decision Criteria

  • Data Processing / API Integrations: Enforce structured JSON outputs.
  • User Chat Views: Use standard text completions.

Best Practices

  • Use native structured output APIs (e.g., OpenAI Structured Outputs) to guarantee schema compliance.
  • Keep output schemas simple to reduce latency and token usage.

Examples

  • Structured Output API Call:
    const completion = await openai.beta.chat.completions.parse({
      model: "gpt-4o-2024-08-06",
      messages: [{ role: "user", content: "Extract user info" }],
      response_format: zodResponseFormat(UserSchema, "user"),
    });

Professional Recommendations

Configure retry loops to correct LLM outputs if schema validations fail.


AI Workflows

Purpose

To design complex task workflows, combining prompt chains, database updates, and tool runs.

Rules

  • Break complex tasks down into sequences of smaller, validated steps.
  • Run workflow steps in parallel whenever possible to reduce latency.

Workflow

flowchart TD
    A["Ingest Task Request"] --> B["Step 1: Extract and validate inputs"]
    B --> C["Step 2: Run parallel analysis prompts"]
    C --> D["Step 3: Compile and format final response"]
    D --> E["Log performance metrics and verify accuracy"]

Decision Criteria

  • Complex document parsing: Use sequential prompt chains.
  • Simple queries: Single-call completions.

Best Practices

  • Enforce strict schemas (e.g., Zod) on data shared between workflow steps.
  • Configure timeouts and retry backoff limits on all workflow steps.

Examples

  • Sequential Prompt Chain: A workflow that extracts keywords from a document, queries a database, and generates a summary.

Professional Recommendations

Monitor workflow latencies and optimize bottleneck steps during testing.


Model Selection

Purpose

To select the appropriate LLM model for a task, balancing reasoning capability, latency, and cost.

Rules

  • Use fast, open-weights models for simple tasks (e.g., text categorization, formatting).
  • Use frontier proprietary models only for tasks requiring complex reasoning or coding.

Workflow

flowchart TD
    Q1{"Does task require complex reasoning / code generation?"}
    Q1 -- Yes --> A1["Select frontier proprietary model (e.g., Claude 3.5 Sonnet)"]
    Q1 -- No --> Q2{"Is latency critical?"}
    Q2 -- Yes --> A2["Select fast open-weights model (e.g., Llama 3 8B)"]
    Q2 -- No --> A3["Select standard cloud model (e.g., GPT-4o-mini)"]

Best Practices

  • Benchmark model performance using target datasets before finalized model selections.
  • Run open-weights models on optimized serving frameworks (e.g., vLLM) to keep latency low.

Examples

  • Model Matrix Table: A comparison table showing model accuracy, speed, and cost for a specific task.

Professional Recommendations

Design applications to support multiple model providers to ensure reliability.


Cost Optimization

Purpose

To minimize LLM API costs through prompt optimization, caching, and model selection.

Rules

  • Monitor API token usage and cost metrics in real-time.
  • Configure prompt caching for static context to reduce token costs.

Workflow

1.  **Analyze Costs:** Identify high-cost prompts and models.
2.  **Optimize Prompts:** Remove unnecessary context and compress templates.
3.  **Enable Caching:** Configure prompt caching for static context.
4.  **Downgrade Models:** Switch to smaller models for simple workflow steps.

Decision Criteria

  • High-Volume, Low-Complexity Routes: Use smaller, cached models.
  • High-Value, High-Complexity Routes: Use frontier reasoning models.

Best Practices

  • Truncate long conversation history threads to keep token usage low.
  • Batch background tasks to optimize token usage.

Examples

  • Cost Comparison: Downgrading a classification step from GPT-4o to GPT-4o-mini, reducing API costs by 90% with no loss in accuracy.

Professional Recommendations

Set automated budget limits on API keys to prevent unexpected cost spikes.


Token Optimization

Purpose

To optimize prompt and response token lengths, reducing latency and cost.

Rules

  • Prompts must contain only necessary instructions and context.
  • Set explicit limits on the model's output tokens (max_tokens) to prevent runaway generation.

Workflow

flowchart TD
    A["Analyze raw prompt token length"] --> B["Strip redundant instructions & context"]
    B --> C["Configure prompt caching for static segments"]
    C --> D["Set max_tokens on API call parameters"]

Best Practices

  • Compress input data (e.g., using JSON instead of verbose XML) to save tokens.
  • Monitor token usage metrics to identify bloated prompts.

Examples

  • Prompt Compression: Removing conversational filler from instructions, reducing the prompt size by 30%.

Professional Recommendations

Configure token truncation scripts to prevent prompts from exceeding model context limits.


AI Security

Purpose

To protect AI applications from prompt injections, data leaks, and jailbreaks.

Rules

  • Sanitize and validate all user inputs before injecting them into prompt context windows.
  • Never include sensitive system credentials or private client data inside system prompts.

Workflow

flowchart TD
    A["Ingest User Input"] --> B["Run input check validation middleware"]
    B -- Safe --> C["Inject input into prompt template safely"]
    B -- Unsafe --> D["Block query and return error message"]

Best Practices

  • Use guardrail frameworks (e.g., Llama Guard, NeMo Guardrails) to filter inputs and outputs.
  • Test system prompts against common prompt injection attacks to verify they resist user overrides.

Examples

  • Safe Prompt Sep: Using explicit XML tags and separation boundaries to isolate user input:
    User Input: <user_input>{{userInput}}</user_input>

Professional Recommendations

Run automated security scans on prompt templates before production releases.


Guardrails

Purpose

To enforce safety, privacy, and quality constraints on AI inputs and outputs using guardrail middleware.

Rules

  • All user inputs and model outputs must pass through guardrail checks before processing.
  • Block responses containing private user data or sensitive system details.

Workflow

flowchart TD
    A["Ingest User Input"] --> B["Input Guardrail: Check for policy violations"]
    B -- Pass --> C["Call LLM API model"]
    C --> D["Output Guardrail: Check for hallucinations/PII"]
    D -- Pass --> E["Return safe response to client"]
    B -- Fail --> F["Return fallback safety response"]
    D -- Fail --> F

Decision Criteria

  • Public Chatbots: Enforce strict input/output guardrails.
  • Internal Analytics: Basic input validation is usually sufficient.

Best Practices

  • Use lightweight classification models for guardrail checks to keep latency low.
  • Keep safety rules simple to prevent false positives that block legitimate queries.

Examples

  • Output Guardrail Check: A middleware script that checks the LLM response for email addresses or phone numbers, masking them before sending the response.

Professional Recommendations

Monitor guardrail block rates to tune safety thresholds.


Hallucination Reduction

Purpose

To minimize LLM hallucinations, ensuring outputs are accurate and grounded in facts.

Rules

  • Enforce fact-grounding by providing relevant context (e.g., RAG) in every prompt.
  • Set model temperature to 0.0 for tasks requiring factual accuracy.

Workflow

1.  **Provide Context:** Inject relevant source documents into the prompt.
2.  **Set Temperature:** Set `temperature = 0.0` to force deterministic responses.
3.  **Instruct Fact-Grounding:** Instruct the model to cite sources and say "I don't know" if facts are missing.
4.  **Validate Output:** Check the response against source documents using verification models.

Decision Criteria

  • Factual QA / Research: Prioritize RAG, zero temperature, and citation rules.
  • Creative Copywriting: Higher temperatures are acceptable.

Best Practices

  • Tell the model explicitly to rely only on the provided context and ignore outside knowledge.
  • Use evaluation metrics (e.g., faithfulness, answer relevance) to measure hallucination rates.

Examples

  • Fact-Grounding Prompt: "Answer the question using only the facts in the text below. If the answer is not in the text, reply: 'I cannot find that information.'"

Professional Recommendations

Configure automated hallucination checks to audit responses before they are displayed.


Evaluation Framework

Purpose

To measure AI system accuracy, latency, and cost systematically using evaluation frameworks.

Rules

  • Run prompt evaluations against golden test datasets before production updates.
  • Monitor evaluation metrics (e.g., retrieval precision, output accuracy) in real-time.

Workflow

flowchart TD
    A["Update Prompt Template"] --> B["Run evaluation pipeline against golden test datasets"]
    B --> C["Calculate performance metrics: Accuracy, Latency, Cost"]
    C -- Pass --> D["Staging deploy and monitoring checks"]
    C -- Fail --> E["Refactor prompt and retry evaluation loop"]

Decision Criteria

  • Major Prompt Updates: Run full evaluation pipelines against complete test datasets.
  • Minor Copy Fixes: Run quick checks against select test samples.

Best Practices

  • Build golden test datasets containing realistic inputs and target outputs.
  • Use automated LLM-as-a-judge patterns to score qualitative outputs consistently.

Examples

  • Evaluation Script: A script that runs a prompt template against 100 test cases, calculating accuracy and average cost.

Professional Recommendations

Integrate evaluation runs into your CI/CD pipeline to catch regression errors early.


Human Feedback

Purpose

To collect and integrate human feedback (RLHF/RLAIF) to improve model accuracy and safety.

Rules

  • Provide clear ways for users to rate AI responses (e.g., thumbs up/down, edit options).
  • Store feedback events in structured databases linked to prompt logs.

Workflow

flowchart TD
    A["Deliver AI response to user"] --> B["User provides feedback (e.g., Thumbs Down)"]
    B --> C["Log feedback event, prompt, and response to database"]
    C --> D["Aggregate feedback to update golden test datasets"]

Decision Criteria

  • Public Apps: Enforce simple rating controls.
  • Expert Review Panels: Provide detailed annotation interfaces.

Best Practices

  • Monitor feedback trends to identify prompts causing issues.
  • Use negative feedback cases to update golden test datasets.

Examples

  • Feedback Log: A database record containing the prompt, model response, user rating, and correction notes.

Professional Recommendations

Review negative feedback regularly to prioritize prompt updates.


AI Testing

Purpose

To test AI integration pipelines, verifying prompts, tool calls, and APIs remain correct.

Rules

  • Mock model API calls during unit tests to control costs and speed up test runs.
  • Run integration tests against real model APIs to verify prompt compatibility.

Workflow

flowchart TD
    A["Write API Integration Code"] --> B["Write unit tests using mocked LLM responses"]
    B --> C["Write integration tests checking real model API connections"]
    C --> D["Execute test runs locally using dev commands"]
    D --> E["Run tests in CI pipelines before deployment"]

Decision Criteria

  • Logic / Parsing Tests: Use mocked model responses to speed up tests.
  • Prompt Compatibility: Run integration tests against real APIs.

Best Practices

  • Use deterministic parameters (temperature = 0.0) in tests to ensure consistent results.
  • Mock network timeouts and API errors to verify system resilience.

Examples

  • Vitest Mock Test:
    import { expect, test, vi } from 'vitest';
    import { getCompletion } from './openai';
    
    vi.mock('./openai', () => ({
      getCompletion: vi.fn().mockResolvedValue('Mocked response'),
    }));
    
    test('returns mocked completion', async () => {
      const res = await getCompletion('Hello');
      expect(res).toBe('Mocked response');
    });

Professional Recommendations

Configure test runs to block deployments if prompt validation checks fail.


Monitoring

Purpose

To track AI application health, latency, costs, and token usage in real-time.

Rules

  • Set up automatic alerts to trigger if API error rates or latencies exceed limits.
  • Monitor API cost metrics to prevent budget overruns.

Workflow

flowchart TD
    A["Monitor model latencies and error rates"] --> B["Track token usage and API costs in real-time"]
    B --> C["Send metrics data to monitoring dashboards"]
    C --> D["Trigger alerts if thresholds are exceeded"]

Decision Criteria

  • High-Traffic Production: Integrate APM monitoring tools (e.g., Langfuse, Datadog).
  • Simple Apps: Basic console logs and hosting platform alerts are usually sufficient.

Best Practices

  • Track latency metrics (TTFT, total generation time) to identify bottlenecks.
  • Log model parameters (temperature, model name) alongside performance metrics.

Examples

  • APM Dashboard: A dashboard displaying active requests, average latency, and cumulative API costs.

Professional Recommendations

Review performance metrics weekly to optimize configurations.


Logging

Purpose

To record API transactions, system actions, and execution traces for debugging and audits.

Rules

  • Never log sensitive client data, such as passwords, personal identifiers, or private tokens.
  • Write log entries in structured JSON formats to support search indexing.

Workflow

1.  **Configure Logger:** Set up a structured logger (e.g., Winston, Pino).
2.  **Assign Levels:** Set levels (e.g., `info`, `warn`, `error`, `debug`) based on event severity.
3.  **Serialize Event:** Parse logs into standard JSON objects.
4.  **Export Logs:** Direct output to stdout for storage in indexing tools.

Best Practices

  • Include unique correlation IDs in request logs to trace calls across microservices.
  • Log detailed debugging logs (e.g., raw prompts and responses) only in non-production environments to avoid log bloat and privacy leaks.

Examples

  • JSON Log Entry:
    {
      "level": "info",
      "message": "AI completion successful",
      "model": "gpt-4o",
      "tokensUsed": 150,
      "timestamp": "2026-07-04T02:10:00Z"
    }

Common Mistakes

  • Writing raw, unstructured text files that are difficult for search tools to index.
  • Logging raw user prompt inputs in production log systems, risking data leaks.

Decision Criteria

  • Production Environment: Enable structured JSON logging, masking PII.
  • Development Environment: Log raw prompts and responses to make debugging easier.

Professional Recommendations

Automate log exports to secure search index pools (e.g., Elasticsearch, Loki).


AI Deployment

Purpose

To build, bundle, and release AI applications to production environments safely.

Rules

  • Keep deployments automated using version-controlled configuration manifests.
  • Never deploy code containing failing tests, lint errors, or uncommitted files.

Workflow

flowchart TD
    A["Merge code branch to main"] --> B["Trigger build pipeline (ESLint, Types, Tests)"]
    B --> C["Deploy application to production host servers"]
    C --> D["Run post-deploy health check calls"]

Best Practices

  • Deploy staging builds to preview URLs for testing before updating production environments.
  • Use managed edge platforms (e.g., Vercel, Cloudflare Workers) to minimize page latency.

Examples

  • GitHub Actions Configuration: Defining YAML workflows to build packages and run tests automatically.

Common Mistakes

  • Deploying changes manually from developer machines.
  • Failing to verify that API keys and environment variables are active on production hosts.

Decision Criteria

  • High-Traffic Enterprise Apps: Use Github Actions or GitLab CI with Docker Registry setups.
  • Simple Projects: Direct Vercel or Render auto-deploys are usually sufficient.

Professional Recommendations

Set up automated rollbacks in your deployment platforms to revert builds immediately if production health checks fail.


AI Scaling

Purpose

To scale AI services to handle traffic spikes, large datasets, and concurrent users.

Rules

  • Keep server instances stateless to support horizontal scaling across multiple servers.
  • Use load balancers to distribute incoming queries across servers and model endpoints.

Workflow

flowchart TD
    A["API traffic increases"] --> B["Spin up extra stateless server instances"]
    B --> C["Configure Load Balancer to distribute incoming traffic"]
    C --> D["Set up model replicas to scale generation throughput"]

Best Practices

  • Implement client-side queue limits to prevent model rate-limit overloads.
  • Run open-weights models on distributed serving clusters (e.g., vLLM, Triton).

Examples

  • Load Balancing: Distributing incoming queries across multiple model endpoints using a reverse proxy.

Common Mistakes

  • Scaling server instances without scaling model endpoints, leading to API rate limits.
  • Storing active user session states in server memory, which prevents scaling.

Decision Criteria

  • High-Traffic Apps: Scale horizontally by running stateless server instances and model replicas.
  • Small internal tools: Vertical scaling (upgrading server specs) is usually sufficient.

Professional Recommendations

Configure auto-scaling rules to spin up server instances automatically as CPU usage increases.


AI Ethics

Purpose

To design AI systems that are fair, transparent, secure, and respect user privacy.

Rules

  • Inform users clearly when they are interacting with an AI system.
  • Never use user data to train models without explicit consent.

Workflow

1.  **Assess Risks:** Identify potential biases, safety risks, and privacy issues.
2.  **Implement Disclaimers:** Inform users about AI interactions and limitations.
3.  **Secure Consent:** Require user consent before saving data for training.
4.  **Audit Outputs:** Regularly check responses for bias and safety violations.

Best Practices

  • Build mechanisms to let users opt out of data collection and delete their chat histories.
  • Use diverse datasets for evaluation to spot bias early.

Examples

  • Ethics Disclaimer: A user-facing message informing users that the tool uses AI and may occasionally generate incorrect information.

Professional Recommendations

Establish an AI ethics policy to guide development and deployment decisions.


Common Mistakes

Purpose

To list common AI engineering mistakes, helping developers write cleaner, more stable code.

Rules

  • Never use unvalidated LLM outputs to drive critical backend actions directly.
  • Never commit API keys or credentials to version control.

Workflow

1.  **Code Review Pass:** Scan components for unvalidated model calls.
2.  **Audit Key Configs:** Verify that all API keys are loaded from environment variables.
3.  **Optimize Prompts:** Remove unnecessary instructions and context from templates.
4.  **Confirm Transactions:** Ensure related writes run inside transaction blocks.

Best Practices

  • Validate all model outputs using Zod schemas at the application boundary.
  • Store secrets securely in environment variable repositories.

Examples

  • Bad: const data = JSON.parse(completion.text); // Missing validation
  • Good: const data = UserSchema.parse(JSON.parse(completion.text));

Common Mistakes

  • Hardcoding credentials or leaving default configurations in place.
  • Storing conversational history in server memory instead of Redis caches.

Decision Criteria

  • API Integrations: Always validate outputs against Zod schemas.
  • Secrets Management: Use environment variables for all keys.

Professional Recommendations

Use ESLint rules to identify and warn developers about common coding mistakes automatically.


Anti Patterns

Purpose

To identify and avoid AI design and coding patterns that harm performance, maintainability, and security.

Rules

  • Avoid using heavy, proprietary models when lightweight, open-weights models are sufficient.
  • Never write monolithic prompts that combine multiple unrelated rules and tasks.

Workflow

flowchart TD
    A["Scan Codebase for Anti-Patterns"] --> B["Locate bloated, monolithic prompts"]
    B --> C["Refactor to use modular prompt chains/workflows"]
    C --> D["Locate expensive model calls on simple tasks"]
    D --> E["Downgrade to smaller, open-weights models"]

Best Practices

  • Break complex tasks down into sequences of smaller, validated steps (prompt chains).
  • Use local cache settings to reduce redundant model requests.

Common Mistakes

  • Using frontier reasoning models for simple classification tasks, causing unnecessary cost and latency.
  • Allowing user input to override core system rules due to poor prompt structuring.

Decision Criteria

  • High-Complexity Reasoning: Use frontier reasoning models.
  • Simple Classification / Formatting: Use lightweight open-weights models.

Professional Recommendations

Perform regular codebase audits to identify and resolve anti-patterns.


Engineering Checklist

Purpose

To provide a final review checklist, ensuring all AI integrations meet security, performance, and quality standards before release.

Rules

  • All AI changes must pass the engineering checklist before code is deployed to production.
  • Document any checklist violations and resolve them in immediate sprint cycles.

Checklist

  • Type Safety: The codebase compiles with zero compilation errors under strict configurations.
  • Validation: All model outputs are validated using Zod schemas at the application boundary.
  • Security: User inputs are sanitized, and guardrails filter inputs and outputs.
  • Credentials: API keys are secured in environment variables; no secrets are committed to git.
  • Token Limits: Prompts are optimized, and output limits (max_tokens) are configured.
  • Caching: Prompt caching is enabled for static context, and local caching is configured.
  • Error Handling: API calls use retry handlers, and fallback options are operational during outages.
  • Telemetry: APM tracing (e.g., Langfuse) is configured, and health check API keys are active.
  • Testing: All tests pass, using mocked model responses for unit tests and real APIs for integration tests.
  • Docker: Production builds use multi-stage Dockerfiles and run with non-root privileges.

Self Review Engine

Purpose

To define a self-criticism engine that forces the AI to audit its AI integrations and prompts before returning code.

Rules

  • Before outputting any prompt template or code, analyze the draft against the self-review metrics (Simplicity, Security, Performance, Accuracy, Cost).
  • Refactor and correct any identified violations before returning the final response.

Workflow

flowchart TD
    Start["Draft Prompt/Code Completed"] --> Q1{"Is prompt injection possible?"}
    Q1 -- Yes --> R1["Refactor using XML tags and separation boundaries"] --> Q2
    Q1 -- No --> Q2{"Are outputs validated?"}
    Q2 -- Yes --> R2["Inject Zod schema validation checks"] --> Q3
    Q2 -- No --> Q3{"Is token usage optimized?"}
    Q3 -- Yes --> R3["Strip redundant context and enable prompt caching"] --> Q4
    Q3 -- No --> Q4{"Are exceptions captured?"}
    Q4 -- Yes --> R4["Inject try-catch handlers and retry configs"] --> Q5
    Q4 -- No --> Q5{"Are model selections optimal?"}
    Q5 -- Yes --> R5["Select the smallest, fastest model for the task"] --> End
    Q5 -- No --> End["Deliver Final Secure Code Output"]

Best Practices

  • Treat the self-review engine as a required step in the AI design pipeline.
  • Document and update check criteria based on feedback from security and operations teams.

Common Mistakes

  • Returning prompts or code without passing through the self-review checks.
  • Assuming the first template version is always secure and optimal.

Decision Criteria

Apply the self-review engine to all AI integration and prompt generation tasks.

Examples

  • Self-Review Audit: Noticing that an LLM call lacked validation checks and retry parameters, leading to a Zod resolver and retry configuration refactor before returning the code.

Professional Recommendations

Configure your linting pipelines to run automated syntax and security audits.


References

Purpose

To list core specifications, documentation, and technical resources that govern AI engineering standards.

Recommended References

  • OpenAI API Reference: Tool calling, structured outputs, and model parameters.
  • Anthropic Prompt Caching Guide: Implementing caching for static context.
  • Zod Documentation: Schema validation interfaces.
  • OWASP LLM Security Cheat Sheet: Essential security practices to prevent prompt injection and data leaks.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.