Generate Harness pipelines with FeatureFlag or Custom stages for flag rollout scenarios: progressive ramp, multi-env promotion, beta cohorts, config promotion, bootstrap, retirement, segment sync…
$ npx skills add harness/harness-skills --skill fme-pipeline -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install harness/harness-skills fme-pipeline --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/harness/harness-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/fme-pipeline .claude/skills/fme-pipeline && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "fme-pipeline" agent skill from https://github.com/harness/harness-skills/tree/main/skills/fme-pipeline into .claude/skills/fme-pipeline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fme-pipeline", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/harness/harness-skills/tree/main/skills/fme-pipelineType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add harness/harness-skills --skill fme-pipeline -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install harness/harness-skills fme-pipeline --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/harness/harness-skills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/fme-pipeline .agents/skills/fme-pipeline && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "fme-pipeline" agent skill from https://github.com/harness/harness-skills/tree/main/skills/fme-pipeline into .agents/skills/fme-pipeline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fme-pipeline", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add harness/harness-skills --skill fme-pipeline -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install harness/harness-skills fme-pipeline --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/harness/harness-skills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/fme-pipeline .cursor/skills/fme-pipeline && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "fme-pipeline" agent skill from https://github.com/harness/harness-skills/tree/main/skills/fme-pipeline into .cursor/skills/fme-pipeline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fme-pipeline", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/harness/harness-skills.git --path skills/fme-pipeline--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add harness/harness-skills --skill fme-pipeline -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install harness/harness-skills fme-pipeline --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/harness/harness-skills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/fme-pipeline .gemini/skills/fme-pipeline && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "fme-pipeline" agent skill from https://github.com/harness/harness-skills/tree/main/skills/fme-pipeline into .gemini/skills/fme-pipeline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fme-pipeline", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install harness/harness-skills fme-pipelineInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add harness/harness-skills --skill fme-pipeline -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/harness/harness-skills.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/fme-pipeline .github/skills/fme-pipeline && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "fme-pipeline" agent skill from https://github.com/harness/harness-skills/tree/main/skills/fme-pipeline into .github/skills/fme-pipeline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fme-pipeline", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add harness/harness-skills --skill fme-pipeline -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install harness/harness-skills fme-pipeline --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/harness/harness-skills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/fme-pipeline .opencode/skills/fme-pipeline && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "fme-pipeline" agent skill from https://github.com/harness/harness-skills/tree/main/skills/fme-pipeline into .opencode/skills/fme-pipeline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fme-pipeline", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
fme-pipelineGenerate Harness pipelines with FeatureFlag or Custom stages for flag rollout scenarios: progressive ramp, multi-env promotion, beta cohorts, config promotion, bootstrap, retirement, segment sync…
Fme Pipeline is an agent skill from harness/harness-skills. Generate Harness pipelines with FeatureFlag or Custom stages for flag rollout scenarios: progressive ramp, multi-env promotion, beta cohorts, config promotion, bootstrap, retirement, segment sync, test targeting. Composes FmeFlag steps with optional HarnessApproval/Wait/Jira/ServiceNow/metric gates. Use when asked to build a flag rollout pipeline, promote flags across environments, or automate flag lifecycle. Do not use for direct flag operations (update-flag-targeting) or general CI/CD (create-pipeline)…
Its SKILL.md is about 3.9k tokens, which your agent loads only when the skill is triggered. The skill folder holds 14 other files, including reference files (for example `references/blueprints.md`, `references/blueprints/l1-flag-bootstrap.yaml` and `references/blueprints/l2-flag-retirement.yaml`). Compatibility notes: Requires the Harness MCP server or the Harness CLI
It sits in DevOps & Cloud, covering CI/CD. It works with Jira and ServiceNow. The repository describes itself as: A collection of structured AI agent skills that enable Claude Code, Cursor, GitHub Copilot, and other AI coding assistants to create, operate, debug, and govern Harness CI/CD… The licence is Apache-2.0.
9 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit c25faee. It shows what the files ask for, not the result of running them.
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
No scripts in the folder and no shell commands in SKILL.md.
From the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Requires the Harness MCP server or the Harness CLI
From compatibility in the SKILL.md frontmatter.
Fme Pipeline loads about 3.9k tokens when it runs, and up to ~31k if it reads all its reference files. Until then it costs about 182 tokens; SKILL.md has 1,663 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
The full file from harness/harness-skills at commit c25faee, republished under its Apache-2.0 licence (© harness). 1,663 words, ~3,916 tokens.
.claude/skills/fme-pipeline/SKILL.md (or your agent's skills folder). This skill also uses 12 other files; get the full folder from GitHub.Compose Harness pipelines with FmeFlag* / FmeSegment* steps for flag rollout scenarios. Generates tailored pipelines — progressive ramp, multi-environment promotion, beta cohorts, config promotion, bootstrap, retirement, segment sync, and test targeting — rather than a single fixed template.
Related: Direct flag operations → /update-flag-targeting. Experiments → /manage-experiments, /review-experiment-results. Flag creation → /create-feature-flag. Lifecycle → /manage-flag-lifecycle. Segments → /manage-segments. State → /explain-flag. Discovery → /discover-feature-flags. Code removal → /cleanup-feature-flags. Running → /run-pipeline. Triggers → /create-trigger.
Works through the Harness MCP server or the Harness CLI; names are from tool-map.md.
| Operation | MCP | CLI |
|---|---|---|
| List environments | harness_list · fme_environment · compact: false | harness list fme_environment --json |
| Get flag | harness_get · fme_feature_flag · params: { feature_flag_name } | harness get feature_flag <name> --json |
| List definitions | harness_list · fme_feature_flag_definition · params: { feature_flag_name } · filters: { offset: 0, limit: 100 } · compact: false | harness list feature_flag:definition <name> --json |
| List rollout statuses | harness_list · fme_rollout_status · compact: false | harness list rollout_status --json |
| List experiments | harness_list · fme_experiment · filters: { parent_type: "FEATURE_FLAG", parent_name, status: ["ACTIVE", "PAUSED"] } · compact: false | harness list experiment --parent-type FEATURE_FLAG --parent-name <flag> --status ACTIVE --json, then again with --status PAUSED |
| List user groups | harness_list · user_group | harness list user_group --json |
| List connectors | harness_list · connector | harness list connector --json |
| Get project | harness_list · project · org_id | harness list project --org <org> --json |
| Get pipeline | harness_get · pipeline · params: { pipeline_id } · org_id · project_id | harness get pipeline <id> --org <org> --project <proj> --json |
| Create pipeline | harness_create · pipeline · org_id · project_id · body: { yamlPipeline } | harness create pipeline -f pipeline.yaml --org <org> --project <proj> |
| Update pipeline | harness_update · pipeline · params: { pipeline_id } · org_id · project_id · body: { yamlPipeline } | harness update pipeline <id> -f pipeline.yaml --org <org> --project <proj> |
Confirm before write. Do not create or update until the user explicitly confirms the plan.
No automatic metric rollback. FmeMetricCheck fails the step when its JEXL condition is true — it does not kill the flag. Rollback requires an explicit FmeFlagKill stage.
Follow scope-establishment.md. Restate: Working in org=..., project=...
| Mode | User signal | Outcome |
|---|---|---|
| Design (default) | "How should we roll out…?" | Pattern + stage plan; no YAML write |
| New pipeline | "Create a rollout pipeline for…" | Plan + YAML draft; create after confirm |
| Update existing | "Add FME stages to pipeline X" | Fetch, merge, show diff; update after confirm |
Map user intent to scenarios.md:
| User intent | Scenario | Primary steps |
|---|---|---|
| Increase traffic in one environment | R1 Progressive ramp | Initial allocation while killed → manual readback/approval → restore → soak/later allocations (5→25→50→100) |
| Promote across dev/qa/staging/prod | R2 Multi-environment promotion | ONE STAGE PER ENVIRONMENT, initial allocation → readback/approval → restore → soak/ramps |
| Beta users first, then everyone | R3 Beta cohort | 0% default + beta targeting → full-audience readback/approval → restore → soak/ramps |
| Copy staging config to prod | R4 Config promotion | FmeFlagDefinitionInstructions or FmeFlagPatchDefinition |
| Create flag with initial targeting | L1 Flag bootstrap | FmeFlagCreate → treatments → kill/restore/targets → flagsets |
| Prepare a fully-launched flag for retirement | L2 Flag retirement (preparatory only) | Verify 100% at authoring time → update rolloutStatus → remove flagsets → hand off to /manage-flag-lifecycle for the archive step itself, re-checked at execution time |
| Import keys from external system | L3 Segment sync | ShellScript fetch → FmeSegmentAddRemoveTargets |
| Add test keys, run tests, clean up | L4 Test targeting | Add keys → ShellScript tests → remove keys |
Collect only what is missing. Do not guess environment names, treatments, or approver groups. For all scenarios: flag name, baseline and variant treatments, target environments, existing pipeline (update mode). For R2: per-env ramp schedule and gates. Ask: reusable pipeline (flag name as <+input>) or one-off (literal name)? Gate policy: never add a gate the user didn't agree to. Killed-flag resume requires the manual readback/approval checkpoint below; if declined, stop the automated resume and hand off rather than omitting the safeguard. Ask which building blocks: gates (HarnessApproval, Wait, FmeMetricCheck), rollback (FmeFlagKill stage on failure), ticket integration (Jira/ServiceNow), or none. For approvals: user groups, minimum count.
L1 is the one scenario where the flag does not exist yet. Do not demand an existing flag, its definitions, or its targeting state as a prerequisite. Instead gather: flag name (and confirm it is NOT already taken — see Phase 5), traffic type (must exist in the project/account scope), treatments, default/baseline treatment, per-env kill/restore plan, flagset name if attaching.
List environments to build promotion-order proposal (non-prod first, prod last via isProduction). Confirm order.
For R1–R4 and L2–L4 (flag must already exist): Get flag + List definitions to note per environment: isKilled, defaultTreatment, defaultRule, trafficAllocation, rules, targeting.
For L1 (flag bootstrap): do the opposite check — Get flag to confirm the name is NOT already in use (stop and ask if it is), and confirm the requested traffic type exists at the relevant scope. Do not call List definitions expecting prior state; there is none yet.
Killed-flag resume (R1/R2/R3 and any previously-targeted flag): write the approved initial allocation/rules/targets while killed; then require a manual readback and HarnessApproval checkpoint before FmeFlagRestore, followed by soak/later increases. The approver must inspect the complete definition through /explain-flag or Harness UI: still killed, approved defaultRule/trafficAllocation, all rules and treatment-level key/segment memberships, served default/configuration, and current experiment impacts. Reject mismatches or stale evidence. R3 must verify that no existing rule/target exposes non-beta users; 0% default plus appended beta keys does not prove isolation. If initially active, plan the immediate live impact explicitly and omit the unnecessary restore/resume checkpoint; never silently kill it.
No native readback step exists in this catalog. Use the agreed manual checkpoint, not a fabricated verifier or API-success claim. If no approver/readback is available, stop before automated restore and hand off. This checks stored configuration, not SDK propagation; FmeMetricCheck after a soak is a separate measurement. Changing defaultTreatment or its configuration can affect killed traffic immediately—disclose that impact before approval.
For L2: List rollout statuses. For approvals: List user groups. For tickets: List connectors (type Jira or ServiceNow; if missing, hand off to /create-connector). If unavailable, skip and ask user for details.
Before any write, show: scenario(s) and rationale, environment promotion order, stage table (stage | environment | steps | gates | notes), pipeline variables (flag name as <+input>, treatments as variables — treatment <+input> directly in allocation is rejected), prerequisites (project/flag/approvers/connectors exist — for L1, project/traffic-type instead of flag), rollback path (FmeFlagKill when pipelineStatus: Failure), current vs planned state. Run experiment check with List experiments if targeting steps can invalidate experiments or for the L2 retirement-preparation scenario; link and confirm acknowledgement. For L2, also state explicitly that the generated pipeline stops short of archiving and that /manage-flag-lifecycle must re-verify readiness (staleness, dependents, active/paused experiments) at execution time before archiving. Do not proceed until user confirms.
Compose from blueprints.md and building-blocks.md. Get step fields from step-catalog.md. YAML rules: FME stages use type: Custom (schema allows type: FeatureFlag for flag steps, but Custom is more flexible for mixing FME steps with Wait/approvals/scripts). Custom stages need failureStrategies (MarkAsFailure; no StageRollback). Stage names: ^[a-zA-Z_0-9-.][-0-9a-zA-Z_\s.]{0,127}$. Step identifiers: ^[a-zA-Z_][0-9a-zA-Z_]{0,127}$. environment = FME environment name/ID (case-sensitive). Allocations: integers 0–100 summing to 100. Quote boolean-like treatment names ("on", "off"). Stage when.pipelineStatus: Success, Failure, or All. Pipeline YAML must include pipeline: root and be passed as a YAML string. Treatment <+input> rejected — use pipeline variables. Step naming traps: FmeFlagSetIndividualTargets not FmeFlagSetTargets, FmeFlagAddRemoveIndividualTargets not FmeFlagAddRemoveTargets, FmeSegmentAddRemoveTargets not FmeSegmentAddRemoveKeys. If update mode, Get pipeline before merging; show diff. Show YAML before write.
Follow write-safety.md. Verify project (Get project), then Create pipeline or Update pipeline (YAML as string). On validation errors, read message, fix, retry. Do not run; point to /run-pipeline.
Follow operation-summary.md: operation, scope, pipeline ID, what each stage does, what was confirmed, rollback path, how to run, follow-up.
Triggers (use /create-trigger), scheduled launches, CD/CI coupling (use /create-pipeline), governance/OPA, kill-switch runbooks, experiment launch/analysis (use /manage-experiments, /review-experiment-results, /choose-metric, /create-metric, /instrument-metric), guarded rollout (FME-18554 deferred), FmeFlagSetImpressionTracking/FmeChangeProposalSubmit, running pipelines (use /run-pipeline), direct flag changes (use /update-flag-targeting).
new-checkout-flow 10% at a time in staging with approval before each increase"dark-mode from dev → staging → prod, with prod needing approval and slower ramp"new-search for beta users first, then ramp to 10% → 50% → 100% for everyone"dark-mode flag with on and off treatments, keep it killed in prod, restore it in dev"old-checkout-flow for retirement now that it's at 100% off everywhere" — generates status-update and flagset-detach stages only; archiving itself happens in /manage-flag-lifecycle after a fresh readiness checksize: set filters.limit: 100 and advance filters.offset until a short page. Follow pagination for environment inventories too; incomplete reads cannot establish that a definition is missing or an environment is safe to target.| Issue | Resolution |
|---|---|
| Environments disagree on targeting | Don't generate prod steps contradicting staging. Offer config promotion or manual alignment. |
| Flag killed in target | Write approved initial targeting → manual full-definition readback/approval → restore → soak/later increases. Stop if verification or approval is unavailable; disclose any immediate change to the killed flag's served default/configuration. |
| L2 pipeline expected to archive automatically | By design it does not. 100% rollout at authoring time is not archive readiness — staleness, dependents, and active/paused experiments must be re-checked at execution time. The generated pipeline only updates rollout status and detaches flagsets; hand off to /manage-flag-lifecycle for the archive step with fresh evidence. |
| L1 discovery returns "flag not found" | Expected for bootstrap — this confirms the name is free to use, it is not a blocking error. |
| User wants metric auto-rollback | Explain no auto-kill on metric regression. Offer FmeMetricCheck that fails step + explicit FmeFlagKill rollback stage. |
HarnessApproval validation error | Schema requires includePipelineExecutionHistory and approvers object with disallowPipelineExecutor, minimumCount, and either userGroups or serviceAccounts. |
| Pipeline update overwrote stages | Always Get pipeline, merge surgically, show diff. |
| Environment name mismatch | Names are case-sensitive. List environments and confirm. |
Treatment <+input> rejected | Use pipeline variables: define under pipeline: spec, reference as <+pipeline.variables.onTreatment>. |
| Connector missing | List connectors (type Jira/ServiceNow). If missing, offer /create-connector. |
| FME environment approval settings | FME environment-level approval settings do not gate pipeline step execution — use a HarnessApproval step in the pipeline for gating. |
© harness, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
SKILL.md and 12 other files (references) in skills/fme-pipeline of harness/harness-skills.
Open the folder on GitHubat commit c25faee
Fme Pipeline next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Fme Pipeline this skillharness/harness-skills | 115 | — | ~3.9k | Automated safety check: Pass | Apache-2.0 | |
| Building Vulnerability Dashboard With Defectdojomukul975/Anthropic-Cybersecurity-Skills | 34k | — | ~2k | Automated safety check: Pass | Apache-2.0 | |
| Implementing Ticketing System For Incidentsmukul975/Anthropic-Cybersecurity-Skills | 34k | — | ~4.1k | Automated safety check: Pass | Apache-2.0 | |
| Monitor CInrwl/nx | 29k | 6 repos | ~4.7k | Automated safety check: Pass | MIT | |
| Terraform and OpenTofu Guideagentscope-ai/QwenPaw | 36k | 6 repos | ~4.2k | Automated safety check: Pass | Apache-2.0 | |
| Analyze GitHub Action Logswithastro/astro | 63k | 1 repos | ~1.3k | Automated safety check: Pass | Custom licence |
mukul975/Anthropic-Cybersecurity-Skills
Deploy DefectDojo as a centralized vulnerability management dashboard that ingests findings from 200+ security scanners, deduplicates results, tracks remediation metrics, and integrates with CI/CD…
mukul975/Anthropic-Cybersecurity-Skills
Implements an integrated incident ticketing system connecting SIEM alerts to ServiceNow, Jira, or TheHive for structured incident tracking, SLA management, escalation workflows, and compliance…
nrwl/nx
Monitor Nx Cloud CI pipeline and handle self-healing fixes. An agent skill from nrwl/nx.
agentscope-ai/QwenPaw
Guidance for writing and testing Terraform and OpenTofu code: module structure, naming, test approaches, CI/CD workflows, state handling and security scanning.
withastro/astro
Analyze recent GitHub Actions workflow runs to identify patterns, mistakes, and improvements.
ansible/ansible
Downloads Azure Pipelines CI logs for an Ansible pull request or build so the agent can analyze test failures, after asking you first.
harness/harness-skills
Generate audit reports and compliance trails using Harness audit trail data via MCP v2 tools.
harness/harness-skills
A skill your agent uses when working with Chaos Engineering steps inside a Harness pipeline.
harness/harness-skills
A skill your agent uses when the user asks to create, edit, update, design, or configure a Harness Chaos Experiment — including faults, probes, actions, experiment YAML, fault injection, pod-delete…
harness/harness-skills
Remove a launched Harness FME feature flag from application code, keeping the treatment FME serves today, and open a pull request.
harness/harness-skills
Configure code scanning in Harness pipelines using STO security scanners.
harness/harness-skills
Generate Harness Agent Template files for AI-powered automation agents.
Works with
Categories
Generate Harness pipelines with FeatureFlag or Custom stages for flag rollout scenarios: progressive ramp, multi-env promotion, beta cohorts, config promotion, bootstrap, retirement, segment sync…. Fme Pipeline is an agent skill from harness/harness-skills. Generate Harness pipelines with FeatureFlag or Custom stages for flag rollout scenarios: progressive ramp, multi-env promotion, beta cohorts, config promotion, bootstrap, retirement, segment sync, test targeting.
Fme Pipeline fits situations like: asked to build a flag rollout pipeline; promote flags across environments; automate flag lifecycle; direct flag operations (update-flag-targeting).
Run `npx skills add harness/harness-skills --skill fme-pipeline -a claude-code`. Or copy the skill folder (skills/fme-pipeline in harness/harness-skills) into .claude/skills/fme-pipeline in your project. Claude Code loads it when a task matches its description.
Run `npx skills add harness/harness-skills --skill fme-pipeline -a codex`. Or copy the skill folder (skills/fme-pipeline in harness/harness-skills) into .agents/skills/fme-pipeline in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add harness/harness-skills --skill fme-pipeline -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/fme-pipeline, .gemini/skills/fme-pipeline, .github/skills/fme-pipeline and .opencode/skills/fme-pipeline in your project.
SKILL.md names no scripts, command-line tools or credentials: Fme Pipeline is instructions for the agent only. Compatibility (from SKILL.md): Requires the Harness MCP server or the Harness CLI.
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
Fme Pipeline is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
About 3.9k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 27k tokens, read only when the agent opens those files.
Skills that share tags, products or a category with Fme Pipeline: Building Vulnerability Dashboard With Defectdojo (mukul975/Anthropic-Cybersecurity-Skills, 34k stars), Implementing Ticketing System For Incidents (mukul975/Anthropic-Cybersecurity-Skills, 34k stars), Monitor CI (nrwl/nx, 29k stars) and Terraform and OpenTofu Guide (agentscope-ai/QwenPaw, 36k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
harness (a GitHub organization) maintains it in harness/harness-skills, which has 115 GitHub stars. The repository holds 24 skills in this directory. The repository was last updated on October 6, 2026.
Source: harness/harness-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.
