npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@flowcerta/cli

v0.2.0

Published

Governance gate for RPA automations. Checks UiPath, Power Automate, Automation Anywhere and Blue Prism workflows against your policy - locally, without uploading them.

Downloads

642

Readme

flowcerta

Checks an RPA workflow against governance policy, on the machine it is sitting on. Nothing is uploaded.

It exists because coding agents now write automations. An agent can generate a UiPath workflow in seconds, and nothing in that loop knows your organisation forbids hardcoded credentials until a human opens a pull request days later. flowcerta gate is a check the agent can run itself, before it hands the work back.

Install

npx @flowcerta/cli gate MyWorkflow.xaml

On Windows, if PowerShell refuses

npm : File C:\Program Files\nodejs\npm.ps1 cannot be loaded. The file ... is not
digitally signed. You cannot run this script on the current system.

Nothing to do with this package. PowerShell resolves npm to npm.ps1, a script Node ships unsigned, and an execution policy of AllSigned refuses it. The same applies to npx, and to every command npm installs globally, because npm writes a .ps1 shim beside each one. A machine set up this way blocks the install and then blocks the tool afterwards.

The .cmd shims are not scripts as far as the policy is concerned, so they work as they are:

npm.cmd i -g @flowcerta/cli
flowcerta.cmd gate MyWorkflow.xaml

cmd.exe, Git Bash and WSL are unaffected either way. If you would rather fix it once, this needs no administrator and leaves the machine-wide setting alone:

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

RemoteSigned is the Windows default for workstations: local scripts run, scripts downloaded from the internet still do not.

The three commands an agent needs

flowcerta policy                 # what the rules are, before writing anything
flowcerta gate MyWorkflow.xaml   # did this break any of them
flowcerta explain FC-UIP-HCD-001 # how to fix the one it broke

gate decides for itself how to judge the file. If the workflow is tracked in git and modified, it compares against the committed version and only reports what you introduced, so inherited debt does not block the change in front of you. If there is no committed version, the whole file is judged.

Exit codes are the contract:

| code | meaning | |------|---------| | 0 | nothing at or above the threshold | | 1 | policy violation - the automation broke a rule | | 2 | the tool could not answer - bad file, bad argument |

1 and 2 are kept apart on purpose. An agent that read "the tool is stuck" as "your automation is wrong" would start editing a workflow that was fine.

Default threshold is high, not medium. Inside an agent loop a false positive costs more than a missed low-severity finding: it sends the agent off to change something that did not need changing.

In CI

The gate belongs in the agent's loop, before the work comes back. A pull-request job is the backstop - it catches the agent that skipped the check.

BASE=origin/main
git diff --name-only --diff-filter=d "$BASE...HEAD" -- '*.xaml' > changed.txt
while IFS= read -r f; do flowcerta gate "$f" --baseline "$BASE" --no-report; done < changed.txt

Three things to get right, each of which otherwise produces a green build that checked nothing:

  • Fetch the history. A shallow clone has nothing to compare against, so every file is judged on its own and the job fails for debt it inherited. fetch-depth: 0 on GitHub, GIT_DEPTH: 0 on GitLab.
  • Pass --baseline. It defaults to HEAD, and in a pull-request checkout the working tree is HEAD - so the obvious flowcerta gate "$f" compares the file against itself and exits 0 on a workflow that hardcodes a password. The CLI prints "Gate judged nothing" when that happens, but the job is still green unless you look.
  • Keep 1 and 2 apart. 1 is a policy violation, 2 is the check being unable to run. Fail on both, because a check that could not answer must not read as a pass, but report them separately so nobody hunts for a policy problem that is really a malformed file.

--no-report because CI is not the author. The agent's own gate run is the one worth counting; replaying it here adds an unattributed verdict per push.

Then tell the reviewer who has been writing these workflows:

flowcerta provenance Main.xaml Billing.xaml --markdown | gh pr comment --body-file -

It prints markdown rather than posting anything itself, because this tool has no business knowing which forge you use. Only the file names are sent, and they need not exist locally - pass the changed set from a diff.

Read one thing carefully: "no verdicts recorded" is not a clean history. It means nothing was reported, which points the opposite way.

Complete GitHub Actions and GitLab CI jobs: https://flowcerta.com/ci-integration/

Platforms

UiPath (.xaml), Power Automate, Automation Anywhere and Blue Prism.

Prebuilt binaries for win32-x64, linux-x64, darwin-arm64 and darwin-x64, shipped as optional dependencies. There is no install script - plenty of enterprises block those, and this is a tool sold partly on being safe to run inside one.

Organisation policy

The built-in rules ship with the binary and work signed out. Signing in adds your organisation's own rules and policy packs on top.

flowcerta login --key <key>   # create one at app.flowcerta.com/settings/api-keys
flowcerta whoami              # who you are, and where the key is stored
flowcerta logout

For CI and for agents, set FLOWCERTA_API_KEY instead. It takes precedence over anything stored locally and never touches the disk.

Where the key is kept

Your operating system's keystore, wherever there is one:

| Platform | Stored in | |----------|-----------| | Windows | DPAPI, encrypted for your user account | | macOS | Keychain | | Linux | Secret Service (gnome-keyring, KWallet) via secret-tool | | no keystore available | ~/.flowcerta/credentials.json, owner-only |

flowcerta whoami always names which one is in use, so you never have to guess how the key is protected.

On a headless box with no keyring there is no honest encryption available — any key we could decrypt with would have to be readable by the same process. So that case gets an owner-only file and says so plainly, rather than scrambling it and implying protection it does not have. FLOWCERTA_API_KEY is the better answer there.

Apache-2.0. https://flowcerta.com/agents/