Testland
Browse all skills & agents

giskard-llm

Authors and runs Giskard LLM scans - adversarial test-case generation for LLM applications via `giskard.scan(model)` covering 7 vulnerability categories (hallucination, harmful_content, prompt_injection, sensitive_information_disclosure, stereotypes, robustness, basic_sycophancy); wraps any callable model behind `giskard.Model(model_predict, model_type="text_generation", ...)`; emits HTML report. Use when the user needs adversarial / red-team coverage on top of functional eval suites.

Install with skills.sh (any agent)

npx skills add testland/qa --skill giskard-llm
View source

giskard-llm

Overview

Distinct from functional eval frameworks (Promptfoo, DeepEval, Ragas), Giskard's value (per gk-gh (opens in new window)) is adversarial test generation - auto-generates inputs designed to break LLMs along documented vulnerability dimensions, then reports findings in a triageable HTML report.

Important version note (2026-05-06): per gk-gh (opens in new window), "Giskard v2 is no longer actively maintained. The current v3 focus is on giskard-checks for evaluations, while vulnerability scanning and RAG evaluation still rely on Giskard v2." This skill targets v2 LLM scanning; pin >2,<3 per the install command.

When to use

  • The team needs a red-team / adversarial pass before shipping an LLM feature.
  • Functional evals (Promptfoo / DeepEval / Ragas) pass but the team wants to surface vulnerabilities beyond the test corpus.
  • Compliance-driven assurance needs reportable evidence of hallucination / harmful-content / prompt-injection coverage.
  • Product owners need an HTML report (not raw test output) to triage and sign off.

Step 1 - Install

Per gk-gh (opens in new window) (v2-pinned):

pip install "giskard[llm]>2,<3"

The [llm] extra pulls in the LLM scan dependencies.

Step 2 - Wrap your model

Per gk-gh (opens in new window) (verbatim quickstart):

import giskard
import pandas as pd

def model_predict(df: pd.DataFrame):
    """The function takes a DataFrame and must return a list of outputs (one per row)."""
    return [my_llm_chain.run({"query": question}) for question in df["question"]]

giskard_model = giskard.Model(
    model=model_predict,
    model_type="text_generation",
    name="My LLM Application",
    description="A question answering assistant",
    feature_names=["question"],
)

The description field steers Giskard's adversarial generator - make it specific (e.g., "A question answering assistant for medical guidance" vs the generic "A QA assistant"). Better description ⇒ better-targeted adversarial inputs.

Step 3 - Run the scan

scan_results = giskard.scan(giskard_model)
display(scan_results)

(Per gk-gh (opens in new window).)

In a Jupyter notebook this renders the report inline. To export:

scan_results.to_html("giskard-report.html")

Step 4 - Vulnerability detector catalog

Per gk-gh (opens in new window) the v2 LLM scan covers these detector categories:

DetectorWhat it tries to surface
hallucinationGenerated content not grounded in inputs / facts
harmful_contentToxic, dangerous, or harmful generation
prompt_injectionInputs that override system instructions
sensitive_information_disclosurePII / credentials / system prompt leakage
stereotypesDiscriminatory / stereotyped output by protected attribute
robustnessBrittleness to small input perturbations
basic_sycophancyAgreeing with falsehoods to please the user

Detector selection (subset run):

scan_results = giskard.scan(
    giskard_model,
    only=["hallucination", "prompt_injection"],
)

(Per the scan() API; consult docs.giskard.ai (opens in new window) for the exact parameter list per Giskard release.)

Step 5 - Convert findings to test suites

After a scan surfaces issues, Giskard can synthesize tests for regression coverage:

test_suite = scan_results.generate_test_suite("My LLM Test Suite")
test_suite.run()

This produces deterministic regression tests from the failing adversarial prompts found by the scan - re-run on every PR to prevent regression on previously surfaced vulnerabilities.

Step 6 - CI integration

Giskard does not ship a first-party CI action; pattern:

python -m my_giskard_scan_script  # produces giskard-report.html

Then upload as a CI artifact:

- uses: actions/upload-artifact@v4
  with: { name: giskard-report, path: giskard-report.html }

For PR-blocking gating, parse scan_results for severity and fail CI if any critical findings appear:

critical = [issue for issue in scan_results.issues if issue.level == "major"]
if critical:
    sys.exit(1)

Anti-patterns

Anti-patternWhy it failsFix
Generic description= fieldAdversarial generator produces off-target inputs; many false positivesSpecific description (Step 2)
Run scan once, never regenerate test suiteVulnerabilities resurface in new codeRegenerate test suite per release (Step 5)
Skip Step 5 - only rely on scansNo regression protection between scansAlways synthesize the test suite
Pin Giskard but not the judge-LLM providerJudge-model drift causes flakePin both in CI env

Limitations

  • v2 LLM scanning is in maintenance-only mode (per gk-gh (opens in new window)); v3 is forming around giskard-checks. Track upstream before greenlighting new investment.
  • Adversarial generation is non-deterministic - use random seeds when available + pin Giskard version.
  • LLM-as-judge cost: scans invoke a judge model many times; budget for cost spikes when scanning new models.
  • Limited to text_generation and text_classification model types in v2; multi-modal scanning lives elsewhere in the Giskard ecosystem.

References

Related skills

deepeval-evaluation

Authors and runs DeepEval - pytest-native LLM eval framework with `LLMTestCase` (input + actual_output + expected_output + retrieval_context) and ~11 built-in metrics (G-Eval, Answer-Relevancy, Faithfulness, Contextual-Recall / Precision / Relevancy, Hallucination, Bias, Toxicity, Summarization, JSON-Correctness); runs via `deepeval test run {file.py}` with `assert_test()` per test or `evaluate()` for batch; integrates Confident-AI dashboard. Use when the user prefers pytest workflow, works with RAG and needs faithfulness/contextual metrics out-of-the-box, or wants a managed dashboard.

langfuse-tracing

Wires Langfuse tracing into LLM apps for production observability, monitoring, telemetry, and offline eval - instruments via `@observe` (Python) / `startActiveObservation` (TS) decorators that auto-capture inputs / outputs / timings / errors per generation; exposes `langfuse.update_current_span()` for metadata + cost / latency annotation; supports trace-bound scoring for eval datasets and prompt-as-code management. Use when the user needs to monitor, log, trace, or debug LLM API calls in production beyond pre-deploy eval, wants to add LLM observability tooling to an existing app, or wants to ship traces from production to an eval dataset for offline regression testing.

llm-eval-anti-patterns

Audits an existing LLM evaluation suite for eight methodology errors that make its numbers untrustworthy: too few cases per capability, single-provider lock-in, exact-match assertions on open-ended output, no semantic-similarity check on paraphrase-tolerant output, no baseline comparison in CI, no cost or latency ceiling, unpinned model identifiers, and no adversarial coverage. Supplies harness-neutral detection cues, the reason each error invalidates the result, a concrete fix, a Critical/Warning/Info severity scheme, and a findings-table output shape. Covers validating an LLM judge against human labels before its verdicts count as evidence. Use when an eval suite already exists and its pass rate is about to gate a release, a model swap, or a prompt change, and nobody has audited how the suite itself was built.

llm-regression-suite-author

Builds a versioned golden-dataset LLM regression suite for tracking quality across model upgrades: structures a versioned JSONL/CSV golden dataset, configures deterministic eval runs (temperature 0, seed), wires assertion layers (exact, semantic similarity, LLM-as-judge, rubric), enforces a pass-rate threshold with diff reporting vs the baseline model, and gates CI on regression. Use when upgrading an LLM provider model and needing a repeatable before/after quality gate, or when a prompt regression suite must track output quality across model versions over time.

openai-evals

Authors and runs OpenAI Evals - Python framework + registry for evaluating LLMs and LLM-backed systems with `oaieval {model} {eval-name}` CLI; supports template-based evals (Match / Includes / FuzzyMatch / ModelBasedClassify) defined in `evals/registry/evals/*.yaml` against JSONL data files in `evals/registry/data/`, plus custom Python eval classes implementing the Eval interface. Use when the user works with the openai/evals repo, needs the OpenAI-curated eval registry, or contributes new evals via PR to the registry.

promptfoo-evaluation

Authors and runs Promptfoo evals for LLM prompts and RAG pipelines - wires `promptfooconfig.yaml` providers + prompts + tests + assertions (deterministic `equals` / `contains` / `is-json` / `regex`, semantic `similar`, model-graded `llm-rubric` / `factuality` / `g-eval`, performance `latency` / `cost`, custom `javascript` / `python`), runs `npx promptfoo eval`, views HTML report via `promptfoo view`, and integrates CI for regression gating. Use when the user runs Promptfoo, asks about prompt regression suites, or needs an eval-driven workflow for LLM-backed features.

ragas-evaluation

Authors and runs Ragas - RAG-pipeline evaluation framework with metrics organized into RAG (Faithfulness, Response Relevancy, Context Precision/Recall, Context Entities Recall, Noise Sensitivity), Natural Language Comparison (Factual Correctness, Semantic Similarity, BLEU/ROUGE/CHRF/Exact Match), Agents/Tool-Use (Topic Adherence, Tool Call Accuracy/F1, Agent Goal Accuracy), General Purpose (Aspect Critic, Rubrics-based Scoring), Nvidia (Answer Accuracy, Context Relevance, Response Groundedness), and Summarization. Use when the user evaluates a RAG pipeline (retriever + generator) and needs the deepest metric variety in the OSS LLM-eval space.