Public starter workflows are maintained by GitHub and the community and shown to everyone. Organization workflow templates are files your own team publishes from a repository named .github. Both appear in the New workflow page, and both are copied, not linked, into the repository that uses them.
Where each one comes from
The public set lives in a repository of workflow YAML files, each with a matching .properties.json metadata file. The list on the New workflow page is built from it, and templates that match your languages and tech stacks are shown more prominently.
Your organization can publish its own. According to GitHub, you create a repository named .github in the organization, add a workflow-templates directory, and place each workflow file there with a metadata file of the same name ending in .properties.json.
Side by side
| Question | Public starter workflow | Organization template |
|---|---|---|
| Who writes it? | GitHub and community authors | Your platform or security team |
| Where does it live? | A public starter workflows repository | The .github repository, in workflow-templates |
| Who can change it? | Its maintainers | Whoever has write access to your .github repository |
| Does it know your standards? | No, it is generic | Yes, if you write it that way |
| Does a copy stay linked? | No | No |
What this means for review
The risks are different, and so is who you rely on.
- Public template: you trust the maintainers to keep it sound, and you trust yourself to adapt it. Read it as you would any code you copy in.
- Organization template: you trust your own repository permissions. If many people can push to the
.githubrepository, many people can change what new workflows look like across the organization.
That second point is easy to miss. A template repository is a shared supply point. Treat it like production code: protect the branch, require review, and use CODEOWNERS.
Reading the metadata file
The metadata file controls how a template is presented. The documented fields include name and description (both required), an optional icon, categories, and file patterns that decide when the template is suggested. GitHub also supports a $default-branch placeholder that is replaced with the repository default branch when the workflow is created.
None of those fields give a template any special power. The YAML does the work, so the YAML is what you review.
A simple rule
Use public templates to learn the shape of a pipeline. Use organization templates to carry your own decisions: pinned actions, minimal permissions, the scanning step, the timeout. When someone asks why a repository has a certain CI layout, the answer should be a pull request, not a mystery.
For deeper design questions, see workflow template or reusable workflow for a golden path.
Quick check
Do organization templates update the repositories that used them?
No. GitHub copies the file when the workflow is created. Later edits to the template do not change existing repositories.
Can I hide a template from the public list while testing?
The public starter workflows README describes a preview label in the properties file that hides a template unless a preview query parameter is used. That is about how the public set is maintained.
Sources
- Using workflow templates, GitHub Docs
- Creating workflow templates for your organization, GitHub Docs
- actions/starter-workflows README
Last reviewed: 19 October 2026.
