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/saski/arnesto/gcp-dataflownpx skills add saski/arnesto --skill gcp-dataflowgit clone --depth 1 https://github.com/saski/arnestoWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/saski/arnesto/gcp-dataflow)<a href="https://agentmods.dev/skills/saski/arnesto/gcp-dataflow"><img src="https://agentmods.dev/badge/skills/saski/arnesto/gcp-dataflow.svg" alt="Measured on agentmods" height="20"></a>What 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.00043 | $0.01662 |
| Opus 5 | $0.00022 | $0.00831 |
| Sonnet 5 | $0.00009 | $0.00332 |
| Haiku 4.5 | $0.00004 | $0.00166 |
Grade A, and why
gcp-dataflow 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 4d ago.
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 — 164 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Apache Beam Pipelines on Cloud Dataflow
Expert guidance for writing and packaging Apache Beam pipelines to run on Google Cloud Dataflow.
Creating a new project
Use this section when creating a new project for a Dataflow pipeline.
- If the user doesn't say explicitly which language (Java, Python, Go) shall be used to write the pipeline, you MUST confirm the language.
- Determine which version of Beam SDK should be used by searching for the most
recently released version of Apache Beam, unless the user already uses a
particular version.
- Action: Run a web search for the latest Apache Beam SDK release.
- YOU MUST use same version of Apache Beam consistently throughout the project
in Dockerfiles,
requirements.txt, and other similar files where versions are specified.
Java projects using Gradle
Use this section when configuring a Dataflow Java pipeline project using gradle.
- Shadow Jars (Fat Jars): Do NOT propose to use the Shadow plugin
(
com.github.johnrengelman.shadow) unless the user explicitly requests a Fat Jar. - Passing command-line parameters: Use the
applicationplugin for passing command-line parameters. - SLF4J Logging Dependency Alignment:
- Verify the
slf4j-apiversion pulled transitively by Apache Beam. - You MUST configure the application logging backend (
slf4j-simple,logback-classic, etc.) to exactly match the major/minor version of the resolvedslf4j-api.
- Verify the
Structure the pipeline as a Dataflow Flex Template
When creating new Dataflow pipeline projects, configure them as a Flex template.
Flex Templates offer a hermetic and reproducible launch environment, and are
easy to launch with gcloud or with orchestrators like Cloud Composer.
Follow the Flex Templates section below.
Flex Templates
- Provide Instructions: Provide instructions on rebuilding and running Flex Templates to the user in walkthrough.
- Use Single Docker Image for Python pipelines: For Python Flex Templates,
it is better to use a single image for the template launcher image and for
the worker runtime environment (
--sdk_container_image). Whenever configuring or suggesting a Dataflow Flex Template for a Python pipeline that requires extra dependencies (e.g., using--requirements_file,--setup_file, or--extra_package), YOU MUST recommend the Single Docker Image Configuration as detailed in python_flex_template_reference.md. - Prefer Cloud Build over Local Docker:
- Do NOT assume local Docker availability on the workspace machine.
- Action: Suggest and provide
cloudbuild.yamlout-of-the-box for building and pushing images unless local setup is explicitly requested. - When building images with Cloud Build in the background you MUST provide the link where the user can monitor the long-running operation.
What ships with it
6 files 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.
- 4d ago First seen · 164 lines · 43 tokens per session scan A f9a2c3223cdf
gcp-dataflow is a skill published in the GitHub repository saski/arnesto (5 stars, last pushed 8d ago), licensed Unlicense. It adds 43 tokens to every session and 1,662 once invoked, about $0.0002 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
pixir-delegate
Use Pixir as a headless subagent runtime from Claude Code or any harness with skill ! preprocessing (Codex roots and other no-hydration hosts use pixir-delegate-codex instead) — one-shot workers (pixir --json), parallel fan-out to N children (pixir delegate --spec), resumable steering (pixir resume), evidence…
pixir-delegate-codex
Use when a Codex CLI/Desktop root should fan out subagents, delegate to Pixir workers, run parallel workers, or manage a resident delegation daemon via Pixir Delegate; covers Codex preflight, AGENTS.md, approvals/sandbox, dry-run, daemon start/status/attach/cancel, closure evidence, and audited single-run execution…
pixir-diagnostics
Diagnose Pixir and T3 Code Pixir incidents from local canonical evidence. Use when a Pixir run, ACP/T3 thread, subagent/workflow, provider replay, or daily-driver dogfood session appears stuck, inconsistent, missing tool output, or hard to classify.
readonly-review
Run a no-network read-only review practice with two explorer steps and one synthesis step.
pixir-delegate-native
Delegate work to subagents from INSIDE a Pixir session using the native Subagent tools (spawnagent, waitagent, closeagent, listagents, sendinput) instead of shelling out to the pixir CLI. Use when you are a Pixir session that needs to fan out parallel workers, steer a child, or run skill-backed workflow templates …
repo-contracts-and-boundaries
Use when turning architecture, layering, ownership, dependency direction, schemas, structural metrics, quality thresholds, baselines, allowlists, or generated quality snapshots into repository checks.