open-nudge/opentemplate
open-nudge/opentemplate has 42 GitHub stars and 1 forks. GitHot measured 0 stars in 24 hours. Last checked 2026-11-09 13:43 UTC. Last push 2026-11-03.
All-in-one Python template. One click. Everything included.
What you can do
- Truly open source: no tokens, no fees, no premium plans, open source software only
- Easy to use: clone templated repo, run uv run poe setup and focus on your code
- State of the art: best checkers for Python, YAML, Markdown, prose, and more unified
- Secure: SLSA Build L3, SBOMs, attestations, secured egress, OSSF Best Practices
Measured star growth
- in 24h
- 0
- in 7 days
- Update delayed
- in 15 days
- Update delayed
- in 1 month
- Update delayed
Net star changes over overlapping periods, not daily totals. Missing measurements are left blank. Stars measure attention, not software quality.
README.md
Originalopentemplate
All-in-one Python template. One click. Everything included.
✨ Features 🚀 Quick start 📚 Documentation 🤝 Contribute 👍 Adopters 📜 Legal
Features
opentemplate is a Python template which is:
- Truly open source: no tokens, no fees, no premium plans, open source software only
- Easy to use:
clone templated repo, run
uv run poe setupand focus on your code - State of the art: best checkers for Python, YAML, Markdown, prose, and more unified
- Secure: SLSA Build L3, SBOMs, attestations, secured egress, OSSF Best Practices
- Consistent:
package metadata is static in
pyproject.toml, while uv resolves dependencies intouv.lock - Performant: parallel checks, builds, minimally-sized caches and checkouts
[!IMPORTANT] An example repository using
opentemplate
[!CAUTION] All files in this repo will be copied to your project, using the title and description you provide.
Code quality (Python focused)
[!IMPORTANT] Adjust package metadata and tool configuration in
pyproject.toml.
- Package manager:
uv(withpoetasks) and a singleuv run poe setupmanages everything! (see why uv) - Testing:
pytest(withcoverage, andhypothesisfor fuzzing, doctests, andmutmutfor mutation testing); testing across all Python versions done WITHOUTtoxornox(managed directly byuv!) - Documentation:
mkdocs- document once, have it everywhere (unified look on GitHub and hosted docs), semantically versioned (viamike), autogenerated from coverage, deadlink and spell-checked docstrings, automatically deployed after each GitHub release with clean material design look - Code formatting and linting:
ruff(checks hand-picked for best quality and ease of use; most are enabled),pyreflyfor type checking - Each file is copyrighted with your git information -
copyrights added automatically by
prek, see REUSE and SPDX Licensing for more information - Dependency license compliance: distributed Python dependencies
are checked by Trivy
(per Python version and OS), GitHub Actions and other dependencies
checked by
dependency-review-action, both against a single list of allowed licenses (as defined in.trivy.yaml) - Automated Python version updates:
pyproject.toml(and GitHub Actions pipelines where necessary) are automatically updated to always use 3 latest Python versions (viacogeol) according to Scientific Python SPEC0 deprecation and end-of-life policies - Other code linting: checks for
YAML,Markdown,INI,JSON,prose, all config files,shell,GitHub Actions- all grouped ascheck-<group>andfix-<group>poetasks - Release to
PyPIandGitHub: done by making a GitHub release, each release is attested and immutably versioned viacommition prek: all checks and fixers are run before commit, no need to remember them! (prekis also setup after running a singleuv run poe setupcommand!)
Security
[!IMPORTANT] Everything below is already provided out of the box, one-click only!
- Hardening:
during setup, an automated issue is created to guide you step by step
through enabling rulesets, branch protection, mandatory reviewers,
necessary signatures etc.
(see here for an example).
Best part?
harden.ymlworkflow, which does that automatically (if you follow the instructions in the issue)! - SLSA Build L3 provenance:
wheel and source distributions are built in a reusable workflow
which runs no project code, their digests are
attested in a separate job
and the signed bundle is attached to each release
(public repositories or GitHub Enterprise Cloud,
once
harden.ymlpins the reusable workflows) - SLSA Verification Summary Attestation (VSA): the build provenance of the distributions is verified and the achieved SLSA Build level is attested for them
- Software Bills of Materials (SBOMs): generated per-Python, per-OS, per-dependency group - each attested, and attached to the release
- Static security analysis tooling:
uv auditchecks against OSV database,semgrepmonitors code quality and security,guarddogdetects malicious runtime dependencies and actions,zizmorand CodeQL verify workflows, whiletrufflehoglooks for leaked secrets - Reusable workflows: OpenTemplate tests its own workflow changes through
local references. The
harden.ymlworkflow converts those references toopen-nudge/opentemplate/.github/workflows/<workflow>.yml@<commit-SHA>calls using the latest OpenTemplatemaincommit, so generated repositories receive pinned pipeline updates. - Pinned dependencies: all dependencies are pinned to specific versions
(GitHub Actions,
prekanduv.lock), with weekly Dependabot pull requests (one per ecosystem) - Monitored egress in GitHub Actions:
harden-runnerwith a whitelisted minimal set of domains necessary to run the workflows - Security documentation:
SECURITY.md,SECURITY-INSIGHTS.yml,SECURITY-SELF-ASSESSMENT.md(only security file to update manually before release), andSECURITY-DEPENDENCY.mddefine high quality security policies
[!TIP] See this example release for all security artifacts described above.
[!NOTE] Although there is around 100 workflows helping you maintain high quality, most of them reuse the same workflow, which makes them maintainable and extendable.
GitHub
- GitHub Actions cache - after each merge
to the
mainbranch, dependencies are cached per-group and per-OS for maximum performance - Minimal checkouts and triggers - each workflow is
triggered based on appropriate path and performs
sparse-checkoutwhen possible to minimize the amount of data transferred; great for large repositories with many files and large history - Templates: every possible template included (discussions, issues, pull requests - each extensively described)
- Predefined labels - each pull request will be automatically labeled
(over
20labels created during setup!) based on changed files (e.g.docs,tests,deps,configetc.). No need to specify semverscopeof commit anymore! - Open source documents:
CODE_OF_CONDUCT.md,CONTRIBUTING.md,ROADMAP.md,CHANGELOG.md,CODEOWNERS,DCO, and much more - all automatically added and linked to your Python documentation out of the box - Release changelog:
git-cliff- commits automatically divided based onlabels,types, human/bot authors, and linked to appropriate issues and pull requests - Config files: editorconfig,
.gitattributes, always the latest Python.gitignoreetc. - Commit checks: verification of signatures, commit messages, DCO signing, no commit to the main branch policy (via conform)
Comparison
- Broader scope than other
cookiecuttertemplates (e.g. one-click and one-command setup, security, GitHub Actions, comprehensive docs, rulesets. deprecation policies, automated copyrights and more). Check the cookiecutter-uv template or the cookiecutter-pypackage template to compare yourself. - Truly FOSS (no freemium, no paid plans, no tokens) when compared to
commercial offerings like
snyk. Additionally Python-centric and sticks with tools widely known by developers (their own environment and GitHub interface).
[!TIP] See detailed comparison in the documentation
Quick start
Installation
[!NOTE] Install
uv(if you don't have it already), for Linux/MacOS:
curl -LsSf https://astral.sh/uv/install.sh | sh
- Create a new GitHub repository using this template
(green
Use this templatebutton) - Name your repo (use underscore
_, not hyphens-) - Add project description (necessary!)
- Wait until the setup commit appears
(performed by
github-actions[bot], it may take a few minutes) - Clone the repository
- Run
uv run poe setupcommand locally to setup development environment
[!TIP] For more details read the documentation
Usage
- Create a new branch
- Optionally adjust package metadata in
[project]inpyproject.toml(includingdependencies,keywords, orclassifiers),prekrunsuv lockon every commit, Dependabot updatesuv.lockweekly (releases at least a week old) and on security advisories - Write code in
/src/<project_name>and tests in/tests - Use
git add,git commitandgit pushyour changes prekwill guide you through the process
[!TIP] For more details read the documentation
Examples
[!CAUTION] Click on each example to see it in action!
Run checkers or fixers manually (click me)
> uv run poe check-<group> [FILE1, FILE2, ...] # uv run poe fix-<group>
For example, to check all Python files:
> uv run poe check-python
Or to check /src/__init__.py:
> uv run poe check-python src/__init__.py
To run all checks and fixers at once (via prek):
> uv run poe fix-all
Adjust template (click me)
Package metadata is configured directly in the static
[project]fields inpyproject.toml.
Common package metadata changes in pyproject.toml:
- Add runtime dependencies in
[project].dependencies - Add package keywords in
[project].keywords - Add package classifiers in
[project].classifiers
Advanced tool and development changes still belong in pyproject.toml:
- Add dev dependencies under
[dependency-groups](everything is nameddev-<group>) - Modify
[tool.poe.tasks]for custom command (check-<group>orfix-<group>, the latter modifies files) - Use
[tool.<name>]to adjust specific tool configuration
Adjusting these sections will affect
prekandGitHub Actions
Disable some prek check (click me)
Disabling checks should be done cautiously!
prek checks are defined in prek.toml.
Disable a check using SKIP environment variable:
SKIP="<group1>,<group2>" git commit -m <message>
For example, the following will skip DCO and ini checks
and Python fixes (which would modify files):
SKIP="dco,ini,fix-python" git commit -m <message>
For details, refer to the id fields in prek.toml.
Some commands have both
<group>-fixand<group>-checkfor different actions!
Disable GitHub Actions checks (click me)
Disabling checks should be done cautiously!
When making a commit you can add one of the following strings to the message:
[skip ci][ci skip][no ci][skip actions][actions skip]
Note that you can also merge pull requests even if the checks fail.
Contribute
We welcome your contributions! Start here:
Legal
- This project is licensed under the Apache 2.0 License - see the LICENSE file for details.
- This project is copyrighted by open-nudge - the appropriate copyright notice is included in each file.
Explore related projects
n8n-io/n8n
Fair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400+ integrations.
209,959 starslanggenius/dify
Build Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.
160,773 starsmicrosoft/PowerToys
Microsoft PowerToys is a collection of utilities that supercharge productivity and customization on Windows
140,755 starsstablyai/orca
Orca is the place for working with a fleet of agents (e.g. Grok Bot, Claude Code). Run any coding agent with your own subscription. Available on desktop, mobile and remote runtime.
120,604 stars