Code Implementation Guardrail

---
name: code-implementation-guardrail
description: Guide implementation of production-ready Python RAG components by enforcing correct abstractions, error handling, observability, and safety at coding time.
---

# Production Implementation Guardrail

## Goal
Ensure that **new or modified code** in a Python RAG system is implemented in a **production-ready way from the start**, not retrofitted later.

This skill is used **during active development**, not post-hoc review.

---

## When to Use This Skill
Use this skill when the user is:
- Implementing a new component
- Modifying core RAG logic
- Adding integrations (LLM, embeddings, DB, cache)
- Unsure how to implement something safely for production

---

## Instructions

1. Assume the user is actively writing or modifying code.
2. Identify the component being implemented (e.g., retriever, embedder, API handler).
3. Provide **implementation-level guidance**, not a backlog.
4. Enforce **production defaults**.
5. Be opinionated.

---

## Required Production Checks
For the component under implementation, explicitly address:

### 1. Interface & Responsibility
- What does this component own?
- What must it NOT do?
- What are its inputs and outputs?

### 2. Error Handling
- What failures are expected?
- Which are retriable?
- Which must fail fast?
- What is logged vs returned?

### 3. Configuration & Secrets
- What must be configurable?
- What must NOT be hardcoded?
- How are secrets injected?

### 4. Observability
- What must be logged?
- What metrics should be emitted?
- What trace spans should exist?

### 5. Performance & Cost
- What are the default limits?
- What guardrails exist (timeouts, batch sizes)?
- What prevents runaway cost?

### 6. Testing (Non-Optional)
- What unit tests are required?
- What integration tests must exist?
- What failure paths must be tested?

---

## Constraints
- ❌ Do not suggest “add later”
- ❌ Do not hand-wave production concerns
- ❌ Do not provide generic best practices
- ✅ Tie guidance directly to code being written
- ✅ Prefer explicit patterns over flexibility

---

## Output Format
Produce a **concise implementation checklist** and **code-level guidance** tailored to the specific component. When needed, update one or more of the  EXISTING documents :
1) docs/RAG_ARCHITECTURE.md
2) docs/IMPLEMENTATION_PLAN.md
3) docs/Progress_Tracker.md
Do NOT produce:
- Large backlogs
- Multi-category tables
- Architecture reviews

---

## Expected Outcome
The user can implement the code **once**, correctly, without needing a later hardening pass.