Community

taskflow is built in the open, and the best flows come from the people who run them every day. Whether you have a workflow that solved a real problem, a question about a tricky phase, or an idea for a new pattern — there is a place for it here.

This page is the short tour: where to talk, how to share a template, what the contribution rules are, and how to ask a question that gets answered fast.

Where the community lives

The single hub for everything is GitHub Discussions. It is the help desk, the template gallery, and the RFC room all at once.

Share a template

A template is a saved taskflow that solves a recurring problem — a release-readiness check, a PR review, a migration planner. The bar to share one is low: a real problem, a working flow, and a short note on how to run it.

What a good template looks like

{
  "name": "release-check",
  "description": "Audit changed files and return a single release-readiness summary.",
  "args": {
    "since": { "description": "Git ref to diff against (e.g. a tag or branch).", "default": "last-tag" }
  },
  "concurrency": 4,
  "budget": { "maxUSD": 1.0 },
  "phases": [
    {
      "id": "discover",
      "type": "agent",
      "agent": "scout",
      "task": "List source files changed since {args.since}. Output ONLY a JSON array of {path} objects.",
      "output": "json"
    },
    {
      "id": "summarize",
      "type": "reduce",
      "from": ["discover"],
      "agent": "writer",
      "task": "Combine these changes into one release-readiness summary:\n{steps.discover.output}",
      "final": true
    }
  ]
}

Contribution guidelines

A few conventions keep the ecosystem navigable. They are light — most of them are things you would do anyway.

• Naming is kebab-case. File names, the name field, and phase IDs all use hyphens (risk-review, audit-each). This matches the interpolation syntax ({steps.risk-review.output}) and the host conventions.
• Required fields are non-negotiable. name, description, and phases on every flow. args must declare description (and required where the flow cannot run without them). A template without these fails /tf verify and will not be merged.
• Phases have a clear purpose. Each phase does one thing. If a task prompt tries to do discovery and review and summarize in one call, split it — that is exactly what map and reduce are for.
• Tests are expected. Add an example invocation in the README (the args to pass and the shape of the result you got). If your flow exercises an unusual branch — a loop, a gate, a flow { def } — add a short note on the input that triggers it. You do not need a full test suite; you need a reproducible run.
• Fail open, stay safe. Follow the runtime's own posture: when parse errors run the phase, gate ambiguity passes, tournament judge failure falls back to variant 1. A template should never silently halt a run on a soft error.
• Cost is a first-class concern. Set a budget on any flow that fans out. A template that can spend unbounded tokens is a footgun for the next person who runs it.

Ask for help

Questions are welcome, and a well-asked question gets a fast answer. Before you post, a quick checklist:

Roadmap and RFCs

Bigger ideas — a new phase type, a change to the caching model, a host port — start as a Discussion tagged rfc. The bar is the same as a template: describe the real problem, sketch the smallest shape that solves it, and note what you would give up. RFCs that survive a round of discussion get a design doc under docs/ and a tracking issue.

Read the design docs for the thinking behind decisions already made — cross-run memoization, dynamic hardening caps, the shared-context tree. They are the best way to understand not just what taskflow does but why.

Last updated on