create-workflow-python — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited create-workflow-python (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill describes how to create a Dapr Workflow application using Python.
You MUST follow these phases in strict order:
## Show final message section: the closing sentence followed by the Dev Dashboard recommendation. Do NOT add any other text, summary, or commentary.If you don't have enough context what to build, ask the user the following clarifying questions one by one using an interview style:
Before creating any file, write out the resolved names and restate them to the user in two or three lines, so a wrong reading is caught before it is scaffolded. Resolve them exactly as ../dapr-shared/workflow-placeholders.md defines them: <WorkflowName> from the purpose, <WorkflowInput> and <WorkflowOutput> from its stem, and one <ActivityName> per step with its <ActivityInput> and <ActivityOutput>.
The following must be installed by the user before this skill can run:
uv venv uses the newest interpreter it finds; pin one with uv venv --python 3.12 when you need a specific version)Additional runtime dependencies (handled during project setup):
dapr-ext-workflow version 1.18.0 (pulls in dapr 1.18.0)## Check optional tools); it never installs it and never stops without it.Check once whether the optional Diagrid Dapr Dev Dashboard is installed by following the Check section of ../dapr-shared/dev-dashboard.md (diagrid-dev-dashboard --version). Remember the result (DevDashboardInstalled) for the final message. This check never stops the skill: do not ask the user about it, do not install anything, and continue with the next step whether or not the dashboard is installed.
Create the project root folder inside the current location where the terminal is open:
mkdir <ProjectRoot>
cd <ProjectRoot>The <ProjectName> should start with the <ProjectRoot> and end with -app: <ProjectRoot>-app.
<ProjectRoot>/
├── .gitignore
├── dapr.yaml
├── local.http
├── resources/
│ └── statestore.yaml
└── <ProjectName>/
├── pyproject.toml
├── main.py
├── models.py
├── runtime.py
├── workflow.py
└── activities.pyPython style .gitignore file in the project root. See REFERENCE.md for full example.
Multi-app run file in the project root. Configures the Dapr sidecar and points to the resources folder. See REFERENCE.md for full example and key points.
Dapr Workflow requires a state store component (with actorStateStore set to "true"). See REFERENCE.md for full example and key points.
Python configuration file used by packaging tools. See REFERENCE.md for full example.
Main entry for the Python workflow application. The generic /raise-event endpoint stays in every project, because the event name comes from the request body; only the raise-event example in local.http depends on the workflow. See REFERENCE.md for full example.
Pydantic types for workflow and activity input/output, placed in a models.py file. Models must be serializable since Dapr persists workflow state. As of dapr-ext-workflow 1.18, Pydantic models can be passed directly to schedule_new_workflow, call_activity, and call_child_workflow — no manual model_dump() is needed. See REFERENCE.md for full example and key points.
The runtime.py file creates the shared WorkflowRuntime instance (wfr). Both workflow.py and activities.py import wfr from this file. This avoids a circular import between workflow.py and activities.py. See REFERENCE.md for full example.
A workflow is defined using the @wfr.workflow(name="<NAME>") attribute. The workflow code is placed in a workflow.py file. It imports wfr from runtime.py. See REFERENCE.md for full example, key points, determinism rules, and workflow patterns (chaining, fan-out/fan-in, sub-workflows).
A workflow activity is defined using the @wfr.activity(name="<NAME>") attribute. The activity code is placed in an activities.py file. It imports wfr from runtime.py. See REFERENCE.md for full example and key points.
HTTP request file for testing the workflow endpoints. Contains a start request (POST) to schedule a new workflow instance and a status request (GET) to query the workflow state. Uses the <app-port> from dapr.yaml. The shared template includes a raise-event request: use the event name the workflow waits for, and remove the request when the workflow waits for no external event. See REFERENCE.md for full example.
IMPORTANT: After Project Setup you MUST run these exact verification instructions:
uv venv in the <ProjectName> folder to create a virtual environment.uv sync in the <ProjectName> folder to install dependencies.uv run python -m compileall -q -x .venv . in the <ProjectName> folder. The -x .venv skips the virtual environment, so only the project code is compiled. It must exit with code 0; fix any error and re-run. A SyntaxWarning that comes from a package inside .venv (seen with Python 3.14) is harmless.__pycache__ folders created by the compile step, on every OS, by running this in the <ProjectName> folder: uv run python -c "import pathlib, shutil; [shutil.rmtree(p) for p in pathlib.Path('.').rglob('__pycache__') if '.venv' not in p.parts]".IMPORTANT: After Verify you MUST run these instructions:
Create a README.md file inside the <ProjectRoot> folder.
The README contains the following sections:
local.http file.../dapr-shared/dev-dashboard.md: why it is useful, the install command for each OS (macOS / Linux and Windows) and the run command (diagrid-dev-dashboard, http://localhost:9090).review-workflow-determinism, review-workflow-activity and review-workflow-management skills to audit the generated code.See REFERENCE.md for additional instructions on running locally and running with Catalyst.
IMPORTANT: This is the LAST step. After Create README.md, your final output MUST be ONLY the message below followed by the Dev Dashboard recommendation — no preamble, no summary, no additional commentary, only replace the <ProjectRoot> with the actual value:
The <ProjectRoot> workflow application is created. Open the README.md file in the <ProjectRoot> folder for a summary and instructions for running locally.
Then add, as a separate paragraph, the block from the Final recommendation section of ../dapr-shared/dev-dashboard.md that matches DevDashboardInstalled (installed → start it; not installed → install it). Use it as written, including the link and the commands. Nothing may follow it.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.