AgentStack
SKILL verified MIT Self-run

Account Health Check

skill-orchestra-hq-orchestra-skills-account-health-check · by orchestra-hq

>

No reviews yet
0 installs
12 views
0.0% view→install

Install

$ agentstack add skill-orchestra-hq-orchestra-skills-account-health-check

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Account Health Check? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

A read-only audit. Gather, don't change. Narrate briefly like a data engineer; never print secrets. End with a scorecard and prioritised recommendations, each with a docs link.

0. Access

Use the Orchestra MCP if connected (list_pipelines, list_task_runs, etc.). If it isn't, fall back to the public REST API with $ORCHESTRA_API_KEY (often already in the env); for reading git-backed YAMLs, $GITHUB_TOKEN. If neither MCP nor a key is available, walk the user through ../../../references/orchestra/mcp/setup.md and stop. Recommend connecting the MCP regardless — it makes every future fix/triage skill work.

REST base: https://app.getorchestra.io/api/engine/public — header Authorization: Bearer $ORCHESTRA_API_KEY.

1. Inventory the pipelines

list_pipelines (MCP) or GET /pipelines. For each, capture name, id/alias, storageProvider, and the env(s) it runs in. Then read each definition:

  • Git-backed (storageProvider: GITHUB): read the YAML from the repo (orchestra/*.yml).
  • Orchestra-backed: get the definition from the MCP/API.

You'll run the checks below against the full set of definitions.

2. Checks

For each, state coverage as N/total pipelines and give the fix + doc link.

A. Git control

Rule: every pipeline should be git-backed (storageProvider: GITHUB). If any are Orchestra-backed, recommend moving them to git for version control, PRs, CI, and so the fix/triage skills can hotfix them. → Git Control

B. Secret / env hygiene in connections

Rule: connection: and credential-bearing params should reference ${{ ENV.VAR }} (or a named connection), never hardcoded ids, account names, or secrets inline. Flag any literal connection strings/ids/tokens in YAML. Recommend ${{ ENV.* }} so the same definition is portable across dev/prod and nothing sensitive sits in git. → Connections & Credential Management

C. Alerting coverage

Rule: every pipeline has an alerts: block firing on failure (and ideally RUNNING_TIMEOUT) to a real destination (Slack/Teams/PagerDuty/email). List pipelines with no alerts, or alerts that don't cover FAILED. Recommend adding alerts everywhere — a silent failure is the worst failure.

alerts:
- name: On Failure
  statuses: [FAILED, RUNNING_TIMEOUT]
  destinations: [{ integration: SLACK, destination: '#data-alerts' }]

Slack · PagerDuty · Email · Datadog

D. Repeated tasks → MetaEngine

Rule: when a pipeline repeats near-identical tasks differing only by a parameter (e.g. many FIVETRAN_SYNC_ALL with different connector_id, or dbt runs per source), it should use a MetaEngine matrix (a "for-each") instead of copy-paste. Detect: ≥3 tasks in one definition sharing integration + integration_job and differing only in one param. Recommend collapsing to a matrix — one definition, automatic per-item task IDs, controllable parallelism, inputs that can resolve from upstream outputs.

matrix:
  inputs:
    connectors: [conn_1, conn_2, conn_3]
# reference as ${{ MATRIX.connectors }}

MetaEngine Tasks

E. Metadata / lineage enabled (dbt, dbt Cloud, Coalesce)

Rule: transformation tasks should emit metadata so Orchestra builds lineage and data assets.

  • dbt Core: confirm manifest.json + run_results.json artifacts are produced/uploaded (and state orchestration where used). Without them there's no lineage.
  • dbt Cloud jobs and Coalesce jobs: confirm metadata collection is enabled on the integration/connection.

Flag any transform task with metadata off and recommend enabling it — lineage, column-level impact, and the triage skills all depend on it. → dbt metadata/artifacts · Metadata API

F. Security — SSO & RBAC

Rule: workspace should have SSO and RBAC configured (and consider IP restrictions). This is account-level (not visible in pipeline YAML) — surface it as a standing recommendation: enforce SSO, assign least-privilege roles, scope connections per role. → Security & Data Protection

G. Auto-fix AI agents

Rule: recommend setting up AI agents/agentic pipelines that can triage and auto-fix failures (the same flows as the fix-pipeline-* / triage-orchestra-pipeline skills), so common breakages self-heal or arrive pre-diagnosed. → AI Agent pipelines · Agentic Workflow Templates

H. Hybrid-deployment fit (Python-heavy workloads)

Rule: if the account runs a lot of Python compute, hybrid deployment (compute in the customer's own environment, control plane in Orchestra) is often better for cost, scale, and data-residency/security. Measure it — pull recent Python task runs and total their duration:

GET /task_runs?integration=PYTHON&page_size=200&time_from=&time_to=
# sum (completedAt - startedAt); also note count, max memory/cpu params, frequency

If Python compute is a large/long share of runs (e.g. many long-running or high-memory tasks), recommend evaluating hybrid (and self-hosted tasks). Quantify in the report ("Python tasks = X runs, Y total minutes/week"). → Hybrid Deployment · Architecture & Security · Self-hosted Tasks

I. Other helpful checks (opportunistic)

  • Schedules & timezones: pipelines with no schedule and no webhook/trigger may be orphaned; cron should be Quartz 6-field.
  • No-PR / direct-to-main: git-backed pipelines without CI (Slim CI) — point to the orchestra-dbt-slim-ci-setup skill.
  • Reliability: from list_task_runs, flag tasks with a high recent failure rate or frequent timeouts (candidates for retries/compute bump).
  • Stale connections / unused pipelines: never-run or long-idle pipelines.
  • Approval gates on production-writing/destructive steps.

3. Report

Lead with a one-line health grade, then the scorecard, then prioritised actions.

## Orchestra Account Health —   ()
Overall: 

| Check                       | Status | Coverage      |
|-----------------------------|--------|---------------|
| Git control                 | 🟢/🟡/🔴 | 8/10 git-backed |
| Env vars in connections     |        | 2 pipelines hardcode ids |
| Alerting coverage           |        | 6/10 have failure alerts |
| MetaEngine for repeats      |        | 3 pipelines repeat tasks |
| Metadata/lineage enabled    |        | dbt ✓, Coalesce ✗ |
| SSO & RBAC                  |        | recommend |
| Auto-fix agents             |        | not set up |
| Hybrid fit (Python load)    |        | Python = N runs / M min/wk |

### Top recommendations (priority order)
1.  —  → 
2. ...

Sort recommendations by risk/impact (silent-failure alerting and leaked secrets first). Offer to action the fixable ones (e.g. add alerts: blocks, convert to MetaEngine, swap hardcoded ids for ${{ ENV.* }}) via the relevant skill — but only on request; this skill itself only reports.

Notes

  • Read-only: never edit pipelines, connections, or settings during the audit.
  • Don't print secrets you find — report "hardcoded credential in ``", not the value.
  • Mind the 7-day metadata window and pagination; batch list_* calls.
  • SSO/RBAC/hybrid are account-level — recommend with links rather than trying to detect from YAML.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.