Shishir Tewari, senior manager of data engineering at Procore, presented a session at GitHub Universe 2026 titled “Build once, run on any agent: a practical guide to agent skills”. The talk addressed how teams can capture repeatable instructions so they are not lost in a chat or locked in one person’s head.
An agent skill is a versioned directory containing a SKILL.md file. This file describes when and how to perform a repeatable task. You can share these instructions across agents, but the environment must still provide the necessary tools, credentials, and permissions to carry them out. A skill might explain how to query a database, but it does not grant access to that database.
Define one job and when it applies
A skill works best with a clear job, input, and output. Consider an agent that checks AI-generated changes against the original request. If the same agent assesses its own work, its explanation might influence the review. The Proof Agent uses a separate verifier to examine the changes and provide evidence for its findings.
The skill’s frontmatter names the task and describes its purpose:
---
name: proof-agent
description: Adversarial verification of AI-generated work. Spawns an independent verifier to check for false claims, broken code, and security issues.
---The core rule is simple: self-verification is not verification. The When to Verify section in Proof Agent’s SKILL.md specifies when to invoke the skill. The remaining instructions explain what the verifier reviews and what evidence to include in its findings.
Coordinate multiple skills for a larger workflow
When the judgment that makes a data pipeline correct lives in four different people’s heads, those four people are the roadmap. Each change to the pipeline depends on their availability and knowledge of the data. Data Forge demonstrates how to capture parts of that judgment in skills that work together.
In the support-desk pipeline example, the workflow starts with a request for metrics counting incidents created and resolved. Before building the pipeline, the forge-init skill discovers details such as source tables and naming conventions, then writes them to a resolved manifest. The other skills read that manifest for the project context they need.
The forge-builder skill coordinates the work from the issue through to a pull request. It uses forge-dbx to query the data platform and forge-lint to apply the team’s standards as it designs and builds the pipeline. A person reviews the proposed decisions along the way, and the resulting pull request contains the pipeline code, schema changes, and tests.
Each skill has a defined responsibility, and they share project context instead of rediscovering it independently. When a step changes, you can change one skill and leave the rest alone. Skills fit bounded, repeatable work that benefits from reusable judgment, such as a checklist, release, migration, or metric pipeline. If a workflow needs a stable interface, shared state, an audit trail, long-running control, or permissions enforced outside the model, an application is a better fit.
Keep project configuration out of the skill
The goal is to avoid hardcoding every project’s names, database, or conventions into the skills. In the Data Forge support-desk example, a manifest describes the project, metric store, and platform so the skills can use the right project details without baking them into their instructions:
project:
name: "support-desk"
store_name: "support_metric_store"
platform:
engine: "duckdb"
pipeline_framework: "spark_python"
duckdb_dir: "warehouse"With the discovered details in the resolved manifest, the other skills do not have to make their own assumptions about the project. Keep discovered project details separate from team standards. The forge-init initialization skill can inspect existing schemas and code patterns; the forge-lint skill supplies the rules to follow before code is generated. A pattern found in a repository is not automatically a rule to preserve, so make discovered details reviewable and let people confirm or change them where business judgment is needed. To check portability, ask: could another team use these skills with its own manifest without rewriting them?
Share execution paths between skills
The forge-dbx skill gives the other Data Forge skills one way to access the data platform. It reads the manifest and selects a Databricks or DuckDB adapter, so each skill does not need its own connection and query logic.
The manifest can choose DuckDB for the local support-desk demo, but it cannot install the DuckDB CLI or grant database access. Those remain setup responsibilities for the environment and its user. The manifest picks the engine; the host provides the access.
Put checks and approval points in the workflow
The Data Forge support-desk workflow has seven phases, with a human checkpoint at each one. The workflow overview shows how the skills fit together. Before a phase proceeds, the workflow checks that the previous phase is complete; before schema changes run, it asks for approval.
The Proof Agent example applies the same principle to code review. A GitHub Actions workflow gives the verifier the original request and code changes, but not the coding agent’s own assessment. The verifier returns PASS, FAIL, or PARTIAL and must cite evidence in the changed files. The GitHub Action does a static review of the diff; it does not execute code or run tests. In the demo workflow, the setting block-on-fail: false makes findings advisory. By default, a FAIL fails the check, which blocks the merge if the check is required. The aim is to keep test results and merge requirements in your repository’s CI checks and rules.
Package for each agent client, then verify its setup
Supporting multiple clients can mean keeping several copies of the same instructions in sync. In the Data Forge example, the team keeps skills/*/SKILL.md as the source and uses a packaging script to generate client-specific files: .claude-plugin/plugin.json for Claude Code, .cursor-plugin/plugin.json for Cursor, and .github/agents/*.agent.md for GitHub Copilot. The script also includes a check mode for CI:
node scripts/package.mjs --checkWhat it means
This approach shifts the burden of defining logic from the environment to the instructions. You write the logic once in a standard format and deploy it to different agents. However, the agent itself still requires the underlying tools and permissions to function. The skill defines the how and when, but the system defines the capability.
