Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/claire-gong-18/awesome-cursorrules/workflowgit clone --depth 1 https://github.com/claire-gong-18/awesome-cursorrulesWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/claire-gong-18/awesome-cursorrules/workflow)<a href="https://agentmods.dev/rules/claire-gong-18/awesome-cursorrules/workflow"><img src="https://agentmods.dev/badge/rules/claire-gong-18/awesome-cursorrules/workflow.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.02543 |
| Opus 5 | $0.00000 | $0.01272 |
| Sonnet 5 | $0.00000 | $0.00509 |
| Haiku 4.5 | $0.00000 | $0.00254 |
Grade A, and why
workflow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 321 lines — stays where its author put it; the contents beside it link to each section on GitHub.
This file provides rules and context for generating or understanding Go code related to a custom Domain Specific Language (DSL) for defining Temporal workflows within this project.
DSL Overview:
This project uses a specific Go-based DSL to define Temporal workflows declaratively. The core idea is to represent workflow logic using nested structures rather than imperative Go code directly within the workflow function.
Core DSL Structures (Defined in dsl package):
Workflow: The top-level structure representing the entire workflow definition.Variables map[string]string: Initial variables available to the workflow. These act as the initial state or input.Root Statement: The starting point of the workflow logic (can be a single activity, a sequence, or parallel steps).
Statement: A building block representing a single step or a composite structure. AStatementcan contain one of the following:Activity *ActivityInvocation: Represents a call to a Temporal Activity.Sequence *Sequence: Represents a series of statements executed sequentially.Parallel *Parallel: Represents a set of statements executed in parallel.
Sequence: Contains a sliceElements []*Statementwhich are executed one after another.Parallel: Contains a sliceBranches []*Statementwhich are executed concurrently. The parallel execution waits for all branches to complete. If one branch errors, others are cancelled.ActivityInvocation: Defines how to invoke a specific Temporal Activity.Name string: The registered name of the Temporal Activity to call.Arguments []string: A list of variable names (keys from thebindingsmap) whose values should be passed as arguments to the activity.Result string: The name of the variable (key in thebindingsmap) where the activity's result should be stored.
Execution Flow (SimpleDSLWorkflow):
- The entry point for workflows defined using this DSL is the
SimpleDSLWorkflowfunction:func SimpleDSLWorkflow(ctx workflow.Context, dslWorkflow Workflow) ([]byte, error). - It initializes a
bindingsmap from thedslWorkflow.Variables. - It sets default
workflow.ActivityOptions(e.g.,StartToCloseTimeout). - It uses
workflow.GetLogger(ctx)for logging. - It recursively calls the
executemethod on theRootstatement, passing thectxandbindingsmap.
Data Flow (bindings):
- The
bindings map[string]stringacts as the shared state or memory for the workflow execution. - Initial values come from
Workflow.Variables. ActivityInvocation.Argumentsspecifies which values frombindingsto use as input for an activity.ActivityInvocation.Resultspecifies the key inbindingswhere the activity's return value should be stored.- The
makeInputhelper function retrieves argument values from thebindingsmap based on the names listed inActivityInvocation.Arguments.
Concurrency (Parallel execution):
- The
Parallel.executemethod usesworkflow.Goto launch each branch concurrently. - It uses
workflow.NewSelectorandFuture.Getto wait for branches to complete. workflow.WithCancelis used to cancel pending branches if one branch encounters an error.
Working with the DSL:
- When asked to create or modify workflows, structure the logic using the
Workflow,Statement,Sequence,Parallel, andActivityInvocationtypes. - Define the flow of execution by nesting
SequenceandParallelstructures withinStatements. - Specify activity calls using
ActivityInvocation, ensuringName,Arguments, andResultare correctly defined based on the available activities and the desired data flow through thebindingsmap. - Remember that the actual activity implementation exists separately (see
activities.mdc) and is invoked by name.
package dsl
import (
"time"
"go.temporal.io/sdk/workflow"
)
type (
// Workflow is the type used to express the workflow definition. Variables are a map of valuables. Variables can be
// used as input to Activity.
Workflow struct {
Variables map[string]string
Root Statement
}
// Statement is the building block of dsl workflow. A Statement can be a simple ActivityInvocation or it
// could be a Sequence or Parallel.
Statement struct {
Activity *ActivityInvocation
Sequence *Sequence
Parallel *Parallel
}
// Sequence consist of a collection of Statements that runs in sequential.
Sequence struct {
Elements []*Statement
}
// Parallel can be a collection of Statements that runs in parallel.
Parallel struct {
Branches []*Statement
}
// ActivityInvocation is used to express invoking an Activity. The Arguments defined expected arguments as input to
// the Activity, the result specify the name of variable that it will store the result as which can then be used as
// arguments to subsequent ActivityInvocation.
ActivityInvocation struct {
Name string
Arguments []string
Result string
}
executable interface {
execute(ctx workflow.Context, bindings map[string]string) error
}
)
// SimpleDSLWorkflow workflow definition
func SimpleDSLWorkflow(ctx workflow.Context, dslWorkflow Workflow) ([]byte, error) {
bindings := make(map[string]string)
//workflowcheck:ignore Only iterates for building another map
for k, v := range dslWorkflow.Variables {
bindings[k] = v
}
ao := workflow.ActivityOptions{
StartToCloseTimeout: 10 * time.Second,
}
ctx = workflow.WithActivityOptions(ctx, ao)
logger := workflow.GetLogger(ctx)
err := dslWorkflow.Root.execute(ctx, bindings)
if err != nil {
logger.Error("DSL Workflow failed.", "Error", err)
return nil, err
}
logger.Info("DSL Workflow completed.")
return nil, err
}
func (b *Statement) execute(ctx workflow.Context, bindings map[string]string) error {
if b.Parallel != nil {
err := b.Parallel.execute(ctx, bindings)
if err != nil {
return err
}
}
if b.Sequence != nil {
err := b.Sequence.execute(ctx, bindings)
if err != nil {
return err
}
}
if b.Activity != nil {
err := b.Activity.execute(ctx, bindings)
if err != nil {
return err
}
}
return nil
}
func (a ActivityInvocation) execute(ctx workflow.Context, bindings map[string]string) error {
inputParam := makeInput(a.Arguments, bindings)
var result string
err := workflow.ExecuteActivity(ctx, a.Name, inputParam).Get(ctx, &result)
if err != nil {
return err
}
if a.Result != "" {
bindings[a.Result] = result
}
return nil
}
func (s Sequence) execute(ctx workflow.Context, bindings map[string]string) error {
for _, a := range s.Elements {
err := a.execute(ctx, bindings)
if err != nil {
return err
}
}
return nil
}
func (p Parallel) execute(ctx workflow.Context, bindings map[string]string) error {
//
// You can use the context passed in to activity as a way to cancel the activity like standard GO way.
// Cancelling a parent context will cancel all the derived contexts as well.
//
// In the parallel block, we want to execute all of them in parallel and wait for all of them.
// if one activity fails then we want to cancel all the rest of them as well.
childCtx, cancelHandler := workflow.WithCancel(ctx)
selector := workflow.NewSelector(ctx)
var activityErr error
for _, s := range p.Branches {
f := executeAsync(s, childCtx, bindings)
selector.AddFuture(f, func(f workflow.Future) {
err := f.Get(ctx, nil)
if err != nil {
// cancel all pending activities
cancelHandler()
activityErr = err
}
})
}
for i := 0; i < len(p.Branches); i++ {
selector.Select(ctx) // this will wait for one branch
if activityErr != nil {
return activityErr
}
}
return nil
}
func executeAsync(exe executable, ctx workflow.Context, bindings map[string]string) workflow.Future {
future, settable := workflow.NewFuture(ctx)
workflow.Go(ctx, func(ctx workflow.Context) {
err := exe.execute(ctx, bindings)
settable.Set(nil, err)
})
return future
}
func makeInput(argNames []string, argsMap map[string]string) []string {
var args []string
for _, arg := range argNames {
args = append(args, argsMap[arg])
}
return args
}
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 321 lines · 0 tokens per session scan A fa4b218e3bec
workflow is a cursor rule published in the GitHub repository claire-gong-18/awesome-cursorrules (0 stars, last pushed 1y ago), licensed CC0-1.0. It costs nothing until one of its globs matches a file; then it loads 2,543 tokens. A static security scan graded it A with 0 findings. It comes from a forked repository.
Other cursor rules, from other repositories
ponytail
Ponytail, lazy senior dev mode. Always pick the simplest solution that works.
angular-20
This rule provides comprehensive best practices and coding standards for Angular development, focusing on modern TypeScript, standalone components, signals, and performance optimizations.
dev-standard
Apache Superset development standards and guidelines for Cursor IDE.
cli-error-handling
CLI command error handling patterns.
prefer-direct-imports-over-module-mocks
Prefer extracting a testable core over vi.mock / vi.resetModules when unit tests need to reach production logic entangled with config, env, or singletons.
control-plane-descriptors
Control plane descriptor and instance implementation patterns.