building-with-llms

name	building-with-llms
description	Produce an LLM Build Pack (prompt+tool contract, data/eval plan, architecture+safety, launch checklist). See also: ai-evals (eval only), ai-product-strategy (strategy only).

Building with LLMs

Scope

Covers

• Building and shipping LLM-powered features/apps (assistant, copilot, light agent workflows)
• Prompt + tool contract design (instructions, schemas, examples, guardrails)
• Data quality + evaluation (test sets, rubrics, red teaming, iteration loop)
• Production readiness (latency/cost budgets, logging, fallbacks, safety/security checks)
• Using coding agents (Codex/Claude Code) to accelerate engineering safely

When to use

• “Turn this LLM feature idea into a build plan with prompts, evals, and launch checks.”
• “We need a system prompt + tool definitions + output schema for our LLM workflow.”
• “Our LLM is flaky—design an eval plan and iteration loop to stabilize quality.”
• “Design a RAG/tool-using agent approach with safety and monitoring.”
• “We want to use an AI coding agent to implement this—set constraints and review gates.”

When NOT to use

• You need product/portfolio strategy and positioning (use ai-product-strategy).
• You need a full PRD/spec set for cross-functional alignment (use writing-prds / writing-specs-designs).
• You need primary user research (use conducting-user-interviews / usability-testing).
• You are doing model training/research, infra architecture, or bespoke model tuning (delegate to ML/eng; this skill assumes API models).
• You only want “which model/provider should we pick?” (treat as an input; if it dominates, do a separate evaluation doc).
• You want to design an eval/benchmark framework without building a specific feature (use ai-evals).
• You need to evaluate a vendor/tool for adoption rather than build an LLM feature (use evaluating-new-technology).
• You want to quickly prototype or vibe-code an idea without production planning (use vibe-coding).

Inputs

Minimum required

• Use case + target user + what “good” looks like (success metrics + failure modes)
• The LLM’s job: generate text, transform data, classify, extract, plan, or take actions via tools
• Constraints: privacy/compliance, data sensitivity, latency, cost, reliability, supported regions
• Integration surface: UI/workflow, downstream systems/APIs/tools, and any required output schema

Missing-info strategy

• Ask up to 5 questions from references/INTAKE.md (3–5 at a time).
• If details remain missing, proceed with explicit assumptions and provide 2–3 options (prompting vs RAG vs tool use; autonomy level).
• If asked to write code or run commands, request confirmation and use least privilege (no secrets; avoid destructive changes).

Outputs (deliverables)

Produce an LLM Build Pack (in chat; or as files if requested), in this order:

1. Feature brief (goal, users, non-goals, constraints, success + guardrails)
2. System design sketch (pattern + architecture, context strategy, budgets, failure handling)
3. Prompt + tool contract (system prompt, tool schemas, output schema, examples, refusal/guardrails)
4. Data + evaluation plan (test set, rubrics, automated checks, red-team suite, acceptance thresholds)
5. Build + iteration plan (prototype slice, instrumentation, debugging loop, how to use coding agents safely)
6. Launch + monitoring plan (logging, dashboards/alerts, fallback/rollback, incident playbook hooks)
7. Risks / Open questions / Next steps (always included)

Templates: references/TEMPLATES.md

Workflow (8 steps)

1) Frame the job, boundary, and “good”

• Inputs: Use case, target user, constraints.
• Actions: Write a crisp job statement (“The LLM must…”) + 3–5 non-goals. Define success metrics and guardrails (quality, safety, cost, latency).
• Outputs: Draft Feature brief.
• Checks: A stakeholder can restate what the LLM does and does not do, and how success is measured.

2) Choose the minimum viable autonomy pattern

• Inputs: Workflow + risk tolerance.
• Actions: Decide assistant vs copilot vs agent-like tool use. Identify “human control points” (review/approve moments) and what the model is never allowed to do.
• Outputs: Autonomy decisions captured in Feature brief.
• Checks: Any action-taking behavior has explicit permissions, confirmations, and an undo/rollback story.

3) Design the context strategy (prompting → RAG → tools)

• Inputs: Data sources, integration points, constraints.
• Actions: Decide how the model gets reliable context: instruction hierarchy, retrieval strategy, tool calls, structured inputs. Define the “source of truth” and how conflicts are handled.
• Outputs: Draft System design sketch.
• Checks: You can explain (a) what data is used, (b) where it comes from, (c) how freshness/authority is enforced.

4) Draft the prompt + tool contract (make the system legible)

• Inputs: Job statement + context strategy + output schema needs.
• Actions: Write the system prompt, tool descriptions, and output schema. Add examples and explicit DO/DO NOT rules. Include safe failure behavior (ask clarifying questions, abstain, cite sources).
• Outputs: Prompt + tool contract.
• Checks: A reviewer can predict behavior for 5–10 representative inputs; contract includes at least 3 hard constraints and examples.

5) Build the eval set + rubric (debug like software)

• Inputs: Expected behaviors + failure modes + edge cases.
• Actions: Create a test set covering normal cases, tricky cases, and red-team cases. Define a scoring rubric and acceptance thresholds. Add automated checks where possible (schema validity, citation presence, forbidden content).
• Outputs: Data + evaluation plan.
• Checks: You can run the same prompts repeatedly and measure improvement/regression; evals cover the top failure modes.

6) Prototype a thin slice, using coding agents safely

• Inputs: System sketch + prompt contract + eval plan.
• Actions: Implement the smallest end-to-end slice. Use coding agents for “lower hanging fruit” tasks, but keep tight constraints: small diffs, tests, code review, no secret handling.
• Outputs: Build + iteration plan (and optionally a prototype plan/checklist).
• Checks: You can explain what the agent changed, why, and how it was validated (tests, evals, manual review).

7) Production readiness: budgets, monitoring, and failure handling

• Inputs: Prototype learnings + constraints.
• Actions: Define cost/latency budgets, fallbacks, rate limits, logging fields, and alert thresholds. Address prompt injection/tool misuse risks; add safeguards and review processes.
• Outputs: Launch + monitoring plan.
• Checks: There is a clear path to detect regressions, cap cost, and safely degrade when the model misbehaves.

8) Quality gate + finalize

• Inputs: Full draft pack.
• Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Tighten unclear contracts, add missing tests, and always include Risks / Open questions / Next steps.
• Outputs: Final LLM Build Pack.
• Checks: A team can execute the plan without a meeting; unknowns are explicit and owned.

Anti-patterns (common failure modes)

1. "Prompt and pray" — Shipping a system prompt with no eval set, no automated checks, and no iteration loop. Result: quality regresses silently after every model update.
2. Skipping the tool contract — Giving the LLM tool access without explicit schemas, permission boundaries, and confirmation gates. Result: unintended side-effects (e.g., deleting records, sending emails) in production.
3. RAG without retrieval quality metrics — Building a retrieval pipeline but never measuring recall, precision, or freshness of retrieved chunks. Result: the LLM confidently hallucinates from stale or irrelevant context.
4. Optimizing cost before correctness — Compressing prompts, switching to smaller models, or removing examples to save tokens before the eval set proves the system works. Result: false savings with broken quality.
5. Ignoring adversarial inputs — No red-team cases or prompt-injection tests. Result: the first creative user bypasses guardrails in ways the team never imagined.

Quality gate (required)

• Use references/CHECKLISTS.md and references/RUBRIC.md.
• Always include: Risks, Open questions, Next steps.

Examples

Example 1 (RAG copilot): “Use building-with-llms to plan a support-response copilot that drafts replies using our internal KB. Constraints: no PII leakage; must cite sources; p95 latency < 3s; cost < $0.10/ticket.”
Expected: LLM Build Pack with prompt/tool contract, eval set (including privacy red-team cases), and monitoring/rollback plan.

Example 2 (tool-using workflow): “Use building-with-llms to design an LLM workflow that turns meeting notes into action items and Jira tickets (human review required). Output must be valid JSON.”
Expected: output schema + tool contract + eval plan for structured extraction + guardrails against over-creation.

Boundary example (out of scope — redirect): “We need to decide whether to adopt an AI coding assistant tool for our engineering team.” Response: This is a technology evaluation/adoption decision, not an LLM build task. Redirect to evaluating-new-technology for an options matrix, pilot plan, and decision memo. If they later decide to build a custom coding assistant, return here.

Boundary example (out of scope — ML/infra): “Fine-tune/train a new LLM from scratch.” Response: Out of scope; this skill assumes API-hosted models. Propose an API-model approach first and highlight what ML/infra work is required if training is truly needed.