Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/googlecloudplatform/cortex-framework/create_python_testsnpx skills add GoogleCloudPlatform/cortex-framework --skill create_python_testsgit clone --depth 1 https://github.com/GoogleCloudPlatform/cortex-frameworkWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00028 | $0.00960 |
| Opus 5 | $0.00014 | $0.00480 |
| Sonnet 5 | $0.00006 | $0.00192 |
| Haiku 4.5 | $0.00003 | $0.00096 |
Grade A, and why
create-python-tests scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 51 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Creating Python Unit Tests for a Data Product
When a new data product is created or updated, you MUST create a corresponding Python unit test using pytest. This test ensures that the compiled SQL query correctly implements the business logic, transformations, joins, and filtering criteria documented in the implementation plan.
Workflow
Step 1: Analyze the Implementation Plan and Code
- Retrieve Assumptions & Transformations: Read the implementation plan (from
/create-data-product) to identify:- Which source tables are joined (e.g.,
KNA1andADRC). - What filtering rules are applied (e.g.,
mandt = '100', specific system versions). - What columns are expected and how they are transformed (e.g., coalesced fields, calculations).
- Which source tables are joined (e.g.,
- Locate Scaffolding Files: Locate the custom data product's definition file (
src/data_modules/<namespace>/<source>/products/<type>/definitions/*.js). - Leverage SAP & Domain Knowledge (CRITICAL): Apply your technical understanding of SAP DDIC structures (e.g., how client-specific data is separated, document lines vs headers, translation checks) and the business domain (e.g., Order-to-Cash, Procure-to-Pay, General Ledger) to design meaningful assertions. If any transformations or business rules are complex, custom, or ambiguous, you MUST ask the user for clarifying inputs on how those requirements should be verified in the unit tests before writing the test file.
Step 2: Scaffold the Test File
- Test Location: Create the test file under
tests/unit/<namespace>/namedtest_<type>.py. - Template Reference: Use the base test template in test_template.py.md to structure the test file.
Step 3: Implement Test Assertions
Write assertions to verify the following from the compiled query:
- Join Logic Verification: Parse the query to assert that the correct source tables are joined on the appropriate keys.
- Example: Verify that
KNA1is joined withADRConkunnr.
- Example: Verify that
- Filter Logic Verification: Assert that filtering constraints from the user profile or assumptions are present in the SQL.
- Example: Verify that
mandt = '100'ormandt = "100"is enforced in theWHEREorONclauses.
- Example: Verify that
- Field Transformations Verification: Verify that specific aliased or transformed fields exist in the SELECT statement.
- Example: Verify that
COALESCEis used on postal code fields or region fields.
- Example: Verify that
- Important Field Existence Verification: Verify that key or important fields (like primary keys, key foreign relations, and required business dimensions) are actively selected and projected in the final SQL statement.
- Example: Verify that fields like
customer_number_kunnrorvalid_from_dateare selected.
- Example: Verify that fields like
- Custom Z-Fields Assertions: If the data product maps custom SAP fields (Z-fields, ZZ-fields, or YY-fields), write explicit assertions to verify that these custom columns are correctly projected in the SELECT query and adhere to the snake_case description mapping convention (e.g., asserting that
'zz_'or'yy_'matches are present).
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 51 lines · 28 tokens per session scan A a34872088829
create-python-tests is a skill published in the GitHub repository GoogleCloudPlatform/cortex-framework (10 stars, last pushed 6d ago), licensed Apache-2.0. It adds 28 tokens to every session and 960 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
google-mobile-ads-android-migrate-to-next-gen
Migrates Android applications from the old, legacy Google Mobile Ads (GMA) SDK (com.google.android.gms:play-services-ads) to the new GMA Next-Gen SDK (com.google.android.libraries.ads.mobile.sdk:ads-mobile-sdk). Provides comprehensive mapping tables for imports, classes, and method signatures to help determine…
agent-platform-tuning
Agent Platform Model Tuning. Use when you need to fine-tune open models or Gemini models using Agent Platform infrastructure. Don't use for model training outside Agent Platform, model deployment to endpoints (use agent-platform-deploy), or managing serving endpoints (use agent-platform-endpoint-management).
application-design-center-design-deploy
Processes GCP infrastructure design and deployment workflows within Application Design Center (ADC). Use when: - Designing GCP infrastructure with Terraform. - Validating local HCL. - Performing best-practice plan scans. - Importing templates to Application Design Center (ADC). - Deploying templates. - Troubleshooting…
cloud-run-basics
Manages Cloud Run services, jobs, and worker pools. Use when you need to deploy applications responding to HTTP requests (services), run event-triggered or scheduled tasks (jobs), or handle always-on pull-based background processing (worker pools).
google-analytics-data-api-basics
Manages Google Analytics reporting data, enables the Analytics Data API via the Cloud CLI, and creates reports using the Google Analytics Data API (v1beta). Use when you need to interact with Google Analytics properties, run customized analytics reports, query metrics (like activeUsers, screenPageViews) and dimensions…
agent-platform-rag-engine-management
Manage and query Agent Platform RAG Engine Corpora and retrieve grounded contexts using the Google GenAI SDK. Use when listing RAG corpora or files, inspecting a corpus, retrieving contexts, or generating content grounded in a RAG corpus. Do not use for standard database queries (use SQL/Spanner skills), Google…