decionisdecionis/agent-safe-pipeline/.claude/skills/workflowsetup/SKILL.md

workflowsetup

Skill672 starsChanged yesterdayApache-2.0View on GitHub

Set up governed CI workflows with govern init and move a policy through its lifecycle: roles, review inbox, shadow and production.

Reads credentials

In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/AgentSafeImplementation.mdcCursor rule
- .cursor/rules/PolicyAuthoring.mdcCursor rule
- .cursor/rules/WorkflowSetup.mdcCursor rule
- llms-full.txtllms.txt
- llms.txtllms.txt
- agentsafeSkill
- policyauthoringSkill
- Decionis Commerce GateSkill

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific
could be automatic: a setting could enforce it

Distinctive:
After init, a person adds the Decionis key and tenant as CI secrets and commits the files.
line 24
Distinctive:
Start in shadow. Every decision is recorded and nothing is stopped.
line 32
Distinctive:
Read the shadow results with the policy owner and adjust the workspace policy.
line 33
Distinctive:
Never add a step that skips, retries around or overrides a BLOCK or ESCALATE.
line 37

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Workflow Setup

Two workflows meet here: the delivery workflow that asks Decionis before a deploy, migration or agent-authored change runs, and the policy workflow that takes a rule from draft to production.

Governed delivery with Govern

govern init writes a repository's starter files and nothing else:

govern init --action production-deploy

A shadow-mode workflow for the runner the repository uses: .github/workflows/decionis-govern.yml, .gitlab/ci/decionis-govern.yml (include it from .gitlab-ci.yml), or jenkins/decionis-govern.groovy (paste it into the Jenkinsfile). --host overrides the detection.
DECIONIS_POLICY.md at the repository root, unless --no-policy.
Existing files are kept unless --force. --dry-run writes nothing. --mode, --action and --branch shape the starter. Git is never touched.

After init, a person adds the Decionis key and tenant as CI secrets and commits the files. Never write a key into the workflow file.

`DECIONIS_POLICY.md`

Govern hashes the file and sends its path and SHA-256 with every intent, so each signed Decision Dossier records which revision the repository held. Nothing in the file is evaluated. The rules Decionis enforces are the workspace's policy, versioned there. Keep the file as the readable statement of those rules, and change both together.

Rolling out

Start in shadow. Every decision is recorded and nothing is stopped.
Read the shadow results with the policy owner and adjust the workspace policy.
Switch the workflow to mode: enforce. A step with a command then runs only after Decionis allows it and the grant is claimed. A step without a command fails on the outcomes fail-on lists (block by default). With escalation: managed and an approver or approver role, ESCALATE holds the step for that person.
Enforcement without DECIONIS_API_KEY and DECIONIS_TENANT_ID runs nothing.

Never add a step that skips, retries around or overrides a BLOCK or ESCALATE.

Policy lifecycle in the workspace

Policies live at https://decionis.com/workspace?view=policies.

Stage	Who acts
Draft	Author or Policy Owner edits
Review Ready	Author or Policy Owner submits
Approved for Testing	Independent reviewers approve
Tested	Test Approver or Technical Reviewer qualifies
Approved for Shadow	Independent reviewers approve
Shadow Active	Deployer deploys; decisions are observed only
Approved for Production	Independent reviewers approve
Production Active	Deployer deploys; decisions are enforced
Superseded / Retired	Replaced by a newer revision, or withdrawn

The Policy Owner assigns roles. Policy Owners and Deployers can stop a deployment.
Approving, qualifying and deploying need someone who did not author the revision.
Policy Owners and Auditors export the record.

Assistants in the workflow

Assistants may read policies, explain differences, prepare proposals with decionis.propose_policy_change, and request a review when asked.
Assistants never approve, qualify, deploy or assign roles, and never present their own confirmation as a review.
Report the recorded state from decionis.get_policy_workflow, not what you expect it to be.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free