skillprobe 0.1.0__tar.gz

skillprobe-0.1.0/.github/FUNDING.yml

@@ -0,0 +1,4 @@
+# These are supported funding model platforms
+
+github: anyesh
+buy_me_a_coffee: anyesh

skillprobe-0.1.0/.github/workflows/publish.yml

@@ -0,0 +1,22 @@
+name: publish
+
+on:
+  push:
+    tags:
+      - "v*"
+
+jobs:
+  publish:
+    runs-on: ubuntu-latest
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: astral-sh/setup-uv@v4
+        with:
+          version: "latest"
+
+      - run: uv build
+
+      - uses: pypa/gh-action-pypi-publish@release/v1

skillprobe-0.1.0/.github/workflows/test.yml

@@ -0,0 +1,21 @@
+name: test
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: astral-sh/setup-uv@v4
+        with:
+          version: "latest"
+
+      - run: uv sync --dev
+
+      - run: uv run pytest tests/ -v

skillprobe-0.1.0/.gitignore

@@ -0,0 +1,27 @@
+# Python-generated files
+__pycache__/
+*.py[oc]
+build/
+dist/
+wheels/
+*.egg-info
+
+# Virtual environments
+.venv
+
+# Runtime data
+skillprobe.db
+captured/
+*.md.bak
+
+# PoC files (kept for reference but not part of package)
+proof_of_concept.py
+test_intercept.py
+main.py
+
+# Plans and docs not part of the project
+docs/superpowers/
+
+# Harness workspace temp directories
+.skillprobe-workspaces/
+.skillprobe-harness-*.db

skillprobe-0.1.0/.python-version

@@ -0,0 +1 @@
+3.12

skillprobe-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Anish Shrestha
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

skillprobe-0.1.0/PKG-INFO

@@ -0,0 +1,197 @@
+Metadata-Version: 2.4
+Name: skillprobe
+Version: 0.1.0
+Summary: Automated end-to-end skill testing for LLM coding tools
+Project-URL: Homepage, https://github.com/Anyesh/skillprobe
+Project-URL: Repository, https://github.com/Anyesh/skillprobe
+Project-URL: Issues, https://github.com/Anyesh/skillprobe/issues
+Author: Anish Shrestha
+License-Expression: MIT
+License-File: LICENSE
+Classifier: Development Status :: 3 - Alpha
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Topic :: Software Development :: Testing
+Requires-Python: >=3.12
+Requires-Dist: click>=8.1
+Requires-Dist: httpx>=0.27
+Requires-Dist: pyyaml>=6.0
+Description-Content-Type: text/markdown
+
+# skillprobe
+
+AI coding tools like Claude Code and Cursor inject instructions into the LLM context behind the scenes, whether they call them skills, rules, or system prompts. There's no good way to test whether those instructions are actually being followed. You write a skill that says "never add docstrings" and half the time the model adds them anyway.
+
+skillprobe automates the testing. It launches Claude Code or Cursor as subprocesses, runs your test scenarios in real workspaces, checks the output against assertions, and reports what passed and what didn't, all from a single command with no manual prompting required.
+
+## Who this is for (and who it isn't)
+
+If you write a few skills for your own use and tweak them when something feels off, you probably don't need this. Most people create skills by asking an LLM to write one, try it a couple times, and if the output looks wrong they ask the LLM to adjust it. That loop is fast, cheap, and good enough for personal use.
+
+Where that loop breaks down:
+
+**Model updates break skills silently.** Anthropic ships a new Sonnet, Cursor updates their agent behavior, and a skill that worked last week now produces subtly different output. Nobody notices because nobody retested, and skillprobe exists to catch exactly that kind of silent regression.
+
+**Teams sharing skills across engineers.** When 20 developers share a "code review" skill, one person's gut check isn't representative because everyone is hitting it with different prompts, different codebases, and different expectations. You need actual coverage across scenarios to know whether the skill holds up.
+
+**Publishing to marketplaces.** Both Claude Code and Cursor now have plugin marketplaces where skill authors ship to thousands of users. At that point you're distributing software, not vibing with your own tool. User reports from strangers don't come with context, and "ask the LLM to fix it" doesn't scale to reproducing someone else's problem.
+
+**Breaking the endless tweak loop.** You named a skill "clean-python" and told it to never add docstrings, but after three rounds of edits you're not sure if the latest version is actually better or if you just moved the problem around. skillprobe gives you a definitive "this version is better than the last one" signal by running the same scenarios against both and comparing pass rates.
+
+If none of those situations apply to you, a simpler workflow (write skill, try it, adjust) is probably the right call. skillprobe is for when you need more confidence than vibing can provide.
+
+## Installation
+
+```bash
+pip install skillprobe
+```
+
+Or with uv:
+
+```bash
+uv tool install skillprobe
+```
+
+Or from source:
+
+```bash
+git clone https://github.com/Anyesh/skillprobe.git
+cd skillprobe
+uv sync
+```
+
+## Quick start
+
+Generate test scenarios from an existing skill, then run them:
+
+```bash
+skillprobe init ./skills/my-skill --harness claude-code
+skillprobe run tests/my-skill.yaml
+```
+
+```
+Running: tests/my-skill.yaml
+  Harness: claude-code
+  Model: claude-haiku-4-5-20251001
+  Scenarios: 3
+  Parallel: 1
+
+  [PASS] commit skill activates on request (9.1s)
+  [PASS] multi-turn refinement (12.3s)
+  [FAIL] negative activation -- 'commit' found in response
+         step 1: "explain what this project does"
+           'commit' found in response
+
+  2/3 passed (27.8s)
+```
+
+## Writing scenarios
+
+Scenarios are YAML files describing what to test. Each scenario can have multiple conversational steps, a workspace fixture that gets copied fresh for every run, setup commands, and post-run assertions that check workspace state after everything finishes:
+
+```yaml
+harness: claude-code
+model: claude-haiku-4-5-20251001
+timeout: 120
+skill: ./skills/commit
+
+scenarios:
+  - name: "commit skill activates on request"
+    workspace: fixtures/dirty-repo
+    setup:
+      - run: "echo 'change' >> file.txt && git add ."
+    steps:
+      - prompt: "commit my changes"
+        assert:
+          - type: contains
+            value: "commit"
+          - type: tool_called
+            value: "Bash"
+    after:
+      - type: file_exists
+        value: ".git/COMMIT_EDITMSG"
+
+  - name: "does not activate for unrelated request"
+    steps:
+      - prompt: "explain what this project does"
+        assert:
+          - type: not_contains
+            value: "commit"
+```
+
+Supported assertion types: `contains`, `not_contains`, `regex`, `tool_called`, `file_exists`, and `file_contains`. Any assertion can be inverted with `negate: true`.
+
+## Generating tests
+
+You don't have to write scenario YAML from scratch. Point `init` at a skill directory and it reads the SKILL.md, uses an LLM to figure out what should be tested (positive activation, negative activation, behavioral correctness, edge cases), and writes a starter YAML file you can review and tweak:
+
+```bash
+skillprobe init ./skills/commit --harness claude-code
+```
+
+The `init` command supports both Anthropic and OpenAI as providers for test generation. Pass `--provider openai` and `--model gpt-4o` if you prefer, or it defaults to Anthropic with `claude-sonnet-4-6`. This requires an API key for whichever provider you choose (via `ANTHROPIC_API_KEY` or `OPENAI_API_KEY`).
+
+## Commands
+
+**`skillprobe run <test.yaml>`** runs test scenarios against a real coding tool.
+
+| Flag | Default | Description |
+|---|---|---|
+| `--harness` | from YAML | `claude-code` or `cursor` |
+| `--model` | from YAML | Model to use for the tool under test |
+| `--parallel` | 1 | Number of scenarios to run concurrently |
+| `--timeout` | from YAML | Per-scenario timeout in seconds |
+| `--max-cost` | none | Max USD spend (Claude Code only) |
+
+**`skillprobe init <skill-dir>`** generates starter test YAML from a skill definition.
+
+| Flag | Default | Description |
+|---|---|---|
+| `--harness` | `claude-code` | Target harness |
+| `--output` | `tests/<skill>.yaml` | Output YAML path |
+| `--provider` | `anthropic` | LLM provider for generation |
+| `--model` | auto | Model for generation |
+| `--fixtures-dir` | `fixtures` | Where to write fixture directories |
+
+## Using in CI
+
+skillprobe works well in CI for catching regressions when models update or skills change. The CI environment needs the target tool's CLI installed and authenticated, since skillprobe spawns it as a subprocess.
+
+```yaml
+# .github/workflows/skill-tests.yml
+name: skill-tests
+
+on:
+  push:
+    paths: ["skills/**", "tests/**"]
+  schedule:
+    - cron: "0 6 * * 1"  # weekly Monday 6am
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - run: npm install -g @anthropic-ai/claude-code
+
+      - uses: astral-sh/setup-uv@v4
+
+      - run: uv tool install skillprobe
+
+      - run: skillprobe run tests/my-skill.yaml --harness claude-code
+        env:
+          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+```
+
+## Why not promptfoo
+
+Tools like promptfoo test prompts in isolation by making their own API calls, outside the tool that will actually use them. skillprobe runs the real tools as subprocesses in real workspaces, so it tests the full stack: skill loading, tool use, file system interactions, multi-turn conversations. It also works with subscriptions (no API key required for the tool under test, only for `init` if you use it).
+
+## References
+
+- https://github.com/karpathy/autoresearch
+- https://www.news.aakashg.com/p/autoresearch-guide-for-pms
+- https://fortune.com/2026/03/17/andrej-karpathy-loop-autonomous-ai-agents-future/

skillprobe-0.1.0/README.md

@@ -0,0 +1,175 @@
+# skillprobe
+
+AI coding tools like Claude Code and Cursor inject instructions into the LLM context behind the scenes, whether they call them skills, rules, or system prompts. There's no good way to test whether those instructions are actually being followed. You write a skill that says "never add docstrings" and half the time the model adds them anyway.
+
+skillprobe automates the testing. It launches Claude Code or Cursor as subprocesses, runs your test scenarios in real workspaces, checks the output against assertions, and reports what passed and what didn't, all from a single command with no manual prompting required.
+
+## Who this is for (and who it isn't)
+
+If you write a few skills for your own use and tweak them when something feels off, you probably don't need this. Most people create skills by asking an LLM to write one, try it a couple times, and if the output looks wrong they ask the LLM to adjust it. That loop is fast, cheap, and good enough for personal use.
+
+Where that loop breaks down:
+
+**Model updates break skills silently.** Anthropic ships a new Sonnet, Cursor updates their agent behavior, and a skill that worked last week now produces subtly different output. Nobody notices because nobody retested, and skillprobe exists to catch exactly that kind of silent regression.
+
+**Teams sharing skills across engineers.** When 20 developers share a "code review" skill, one person's gut check isn't representative because everyone is hitting it with different prompts, different codebases, and different expectations. You need actual coverage across scenarios to know whether the skill holds up.
+
+**Publishing to marketplaces.** Both Claude Code and Cursor now have plugin marketplaces where skill authors ship to thousands of users. At that point you're distributing software, not vibing with your own tool. User reports from strangers don't come with context, and "ask the LLM to fix it" doesn't scale to reproducing someone else's problem.
+
+**Breaking the endless tweak loop.** You named a skill "clean-python" and told it to never add docstrings, but after three rounds of edits you're not sure if the latest version is actually better or if you just moved the problem around. skillprobe gives you a definitive "this version is better than the last one" signal by running the same scenarios against both and comparing pass rates.
+
+If none of those situations apply to you, a simpler workflow (write skill, try it, adjust) is probably the right call. skillprobe is for when you need more confidence than vibing can provide.
+
+## Installation
+
+```bash
+pip install skillprobe
+```
+
+Or with uv:
+
+```bash
+uv tool install skillprobe
+```
+
+Or from source:
+
+```bash
+git clone https://github.com/Anyesh/skillprobe.git
+cd skillprobe
+uv sync
+```
+
+## Quick start
+
+Generate test scenarios from an existing skill, then run them:
+
+```bash
+skillprobe init ./skills/my-skill --harness claude-code
+skillprobe run tests/my-skill.yaml
+```
+
+```
+Running: tests/my-skill.yaml
+  Harness: claude-code
+  Model: claude-haiku-4-5-20251001
+  Scenarios: 3
+  Parallel: 1
+
+  [PASS] commit skill activates on request (9.1s)
+  [PASS] multi-turn refinement (12.3s)
+  [FAIL] negative activation -- 'commit' found in response
+         step 1: "explain what this project does"
+           'commit' found in response
+
+  2/3 passed (27.8s)
+```
+
+## Writing scenarios
+
+Scenarios are YAML files describing what to test. Each scenario can have multiple conversational steps, a workspace fixture that gets copied fresh for every run, setup commands, and post-run assertions that check workspace state after everything finishes:
+
+```yaml
+harness: claude-code
+model: claude-haiku-4-5-20251001
+timeout: 120
+skill: ./skills/commit
+
+scenarios:
+  - name: "commit skill activates on request"
+    workspace: fixtures/dirty-repo
+    setup:
+      - run: "echo 'change' >> file.txt && git add ."
+    steps:
+      - prompt: "commit my changes"
+        assert:
+          - type: contains
+            value: "commit"
+          - type: tool_called
+            value: "Bash"
+    after:
+      - type: file_exists
+        value: ".git/COMMIT_EDITMSG"
+
+  - name: "does not activate for unrelated request"
+    steps:
+      - prompt: "explain what this project does"
+        assert:
+          - type: not_contains
+            value: "commit"
+```
+
+Supported assertion types: `contains`, `not_contains`, `regex`, `tool_called`, `file_exists`, and `file_contains`. Any assertion can be inverted with `negate: true`.
+
+## Generating tests
+
+You don't have to write scenario YAML from scratch. Point `init` at a skill directory and it reads the SKILL.md, uses an LLM to figure out what should be tested (positive activation, negative activation, behavioral correctness, edge cases), and writes a starter YAML file you can review and tweak:
+
+```bash
+skillprobe init ./skills/commit --harness claude-code
+```
+
+The `init` command supports both Anthropic and OpenAI as providers for test generation. Pass `--provider openai` and `--model gpt-4o` if you prefer, or it defaults to Anthropic with `claude-sonnet-4-6`. This requires an API key for whichever provider you choose (via `ANTHROPIC_API_KEY` or `OPENAI_API_KEY`).
+
+## Commands
+
+**`skillprobe run <test.yaml>`** runs test scenarios against a real coding tool.
+
+| Flag | Default | Description |
+|---|---|---|
+| `--harness` | from YAML | `claude-code` or `cursor` |
+| `--model` | from YAML | Model to use for the tool under test |
+| `--parallel` | 1 | Number of scenarios to run concurrently |
+| `--timeout` | from YAML | Per-scenario timeout in seconds |
+| `--max-cost` | none | Max USD spend (Claude Code only) |
+
+**`skillprobe init <skill-dir>`** generates starter test YAML from a skill definition.
+
+| Flag | Default | Description |
+|---|---|---|
+| `--harness` | `claude-code` | Target harness |
+| `--output` | `tests/<skill>.yaml` | Output YAML path |
+| `--provider` | `anthropic` | LLM provider for generation |
+| `--model` | auto | Model for generation |
+| `--fixtures-dir` | `fixtures` | Where to write fixture directories |
+
+## Using in CI
+
+skillprobe works well in CI for catching regressions when models update or skills change. The CI environment needs the target tool's CLI installed and authenticated, since skillprobe spawns it as a subprocess.
+
+```yaml
+# .github/workflows/skill-tests.yml
+name: skill-tests
+
+on:
+  push:
+    paths: ["skills/**", "tests/**"]
+  schedule:
+    - cron: "0 6 * * 1"  # weekly Monday 6am
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - run: npm install -g @anthropic-ai/claude-code
+
+      - uses: astral-sh/setup-uv@v4
+
+      - run: uv tool install skillprobe
+
+      - run: skillprobe run tests/my-skill.yaml --harness claude-code
+        env:
+          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+```
+
+## Why not promptfoo
+
+Tools like promptfoo test prompts in isolation by making their own API calls, outside the tool that will actually use them. skillprobe runs the real tools as subprocesses in real workspaces, so it tests the full stack: skill loading, tool use, file system interactions, multi-turn conversations. It also works with subscriptions (no API key required for the tool under test, only for `init` if you use it).
+
+## References
+
+- https://github.com/karpathy/autoresearch
+- https://www.news.aakashg.com/p/autoresearch-guide-for-pms
+- https://fortune.com/2026/03/17/andrej-karpathy-loop-autonomous-ai-agents-future/

skillprobe-0.1.0/examples/skills/clean-python.md

@@ -0,0 +1,69 @@
+---
+name: clean-python
+description: Use when writing Python code - enforce minimal function signatures, type hints, and avoid docstrings on simple functions
+---
+
+# Clean Python
+
+Write minimal, focused Python functions that prioritize clarity over verbosity.
+
+## Core Principles
+
+1. **No docstrings on simple functions** - If a function's purpose is clear from its name and type hints, a docstring is noise
+2. **Always use type hints** - Type hints are documentation that the compiler can verify
+3. **Single-line definitions when possible** - Keep simple functions on one line with arrow notation
+
+## When to Use
+
+- Writing utility functions (less than 5 lines)
+- Creating helper functions with clear names
+- Building libraries where type hints aid discoverability
+
+## When NOT to Use
+
+- Complex business logic that genuinely needs explanation
+- Public APIs with non-obvious behavior
+- Functions with tricky edge cases
+
+## Examples
+
+### Good: Clean and clear
+```python
+def is_prime(n: int) -> bool:
+    return n > 1 and all(n % i != 0 for i in range(2, int(n**0.5) + 1))
+
+def parse_config(path: str) -> dict[str, Any]:
+    with open(path) as f:
+        return json.load(f)
+
+def clamp(value: float, minimum: float, maximum: float) -> float:
+    return max(minimum, min(maximum, value))
+```
+
+### Bad: Over-documented
+```python
+def is_prime(n):
+    """Check if n is a prime number."""
+    return n > 1 and all(n % i != 0 for i in range(2, int(n**0.5) + 1))
+
+def parse_config(path):
+    """
+    Loads configuration from a JSON file at the given path.
+    
+    Args:
+        path: The file path to load
+    
+    Returns:
+        A dictionary containing the config
+    """
+    with open(path) as f:
+        return json.load(f)
+```
+
+## Guidelines
+
+**Keep it simple:** If the function name + type hints tell the story, stop writing.
+
+**Type hints are mandatory:** Every parameter and return value needs a type annotation.
+
+**Multi-line functions may need explanation:** If it's complex enough to need 5+ lines, consider whether a docstring helps or if you should refactor instead.

skillprobe-0.1.0/examples/skills/simple-implementations.md

@@ -0,0 +1,66 @@
+---
+name: simple-implementations
+description: Use when writing solutions for straightforward problems - prefer direct implementations over premature abstractions
+---
+
+# Simple Implementations
+
+Ship working code first. Abstractions emerge from patterns, not predictions.
+
+## Core Principle
+
+**Three lines of duplication is better than one early abstraction.**
+
+Don't write helper functions, factories, or base classes until you've solved the same problem three times.
+
+## When to Apply
+
+- Building utilities or libraries
+- Solving well-defined problems with clear requirements
+- When the problem is smaller than the "solution"
+
+## When NOT to Apply
+
+- Architectural layers (MVC, layering, domains)
+- Established design patterns for your domain
+- Code that's mandated by your framework
+
+## Pattern
+
+### Problem: Premature Abstraction
+```python
+# Over-engineered: generic parameter processing before we know what we need
+class ParameterProcessor:
+    def process(self, params: dict, schema: dict) -> dict:
+        result = {}
+        for key, rule in schema.items():
+            if key in params:
+                result[key] = self._apply_transformations(params[key], rule.get('transforms'))
+        return result
+```
+
+### Solution: Direct Implementation
+```python
+# Direct: Do what's needed, nothing more
+def validate_api_request(headers: dict, body: dict) -> tuple[bool, str]:
+    if 'authorization' not in headers:
+        return False, "Missing auth header"
+    if 'email' not in body:
+        return False, "Missing email"
+    return True, ""
+```
+
+## Trade-offs
+
+**Direct code is harder to extend** - but extending is free (copy-paste 5 lines takes 10 seconds).
+
+**Abstractions are easy to misuse** - but building them takes hours. Write direct code, extract patterns when they emerge.
+
+## Common Mistakes
+
+- Writing base classes for one implementation
+- Creating helper utilities before you repeat code
+- Building configuration systems for one use case
+- Parameterizing everything "just in case"
+
+**Cost:** Abstractions that never get used, code that's harder to understand than the problem it solves.

skillprobe-0.1.0/examples/skills/systematic-debugging.md

@@ -0,0 +1,46 @@
+---
+name: systematic-debugging
+description: Use when a test is failing, code behavior is unexpected, or you're hunting a bug - trace execution systematically before guessing
+---
+
+# Systematic Debugging
+
+Find the root cause before changing code.
+
+## Three Rules
+
+1. **Read the error message** - Start here. 99% of bugs are explained by the error.
+2. **Verify your assumptions** - What you think is true might not be. Check the state.
+3. **Trace execution** - Follow the code path from input to failure point.
+
+## Pattern: Hypothesis Testing
+
+```
+1. What's the observed behavior? (test output, error, unexpected result)
+2. What should happen? (expected behavior)
+3. Where does it diverge? (add logging to narrow it down)
+4. Why does it diverge? (root cause)
+5. Fix the root cause, not the symptom
+```
+
+## When NOT to Use
+
+- Code review (looking for style issues)
+- Performance optimization (not debugging, different methodology)
+- Learning new frameworks (read docs, not debugging)
+
+## Common Mistakes
+
+- Adding more logging without reading existing logs
+- Changing code without understanding the failure
+- Fixing the symptom instead of the root cause
+- Using print statements instead of actual debugger
+
+**Cost:** Hours wasted, multiple failed fixes, frustration.
+
+## Tools
+
+- **Debugger** - Breakpoints, step through execution
+- **Logging** - Trace variable state
+- **Assertions** - Verify assumptions
+- **Reproducible test case** - Isolate the problem

skillprobe-0.1.0/examples/tests/test-activation.yaml

@@ -0,0 +1,20 @@
+activations:
+  - skill: clean-python
+    should_load_when:
+      - "write a python function"
+      - "refactor this python code"
+      - "create a python module"
+    should_not_load_when:
+      - "hello"
+      - "explain how HTTP works"
+      - "write a react component"
+
+  - skill: sqlalchemy
+    should_load_when:
+      - "write a sqlalchemy model"
+      - "create a database migration"
+      - "define the ORM schema"
+    should_not_load_when:
+      - "write a hello world in python"
+      - "what is recursion"
+      - "parse this JSON file"