Thanks for your interest in contributing! This guide explains how to set up your environment, follow our style and commit conventions, run linters, and submit pull requests.
This repository provides prompts that enable a spec‑driven development workflow. Contributions generally fall into one of these areas:
- Documentation improvements
- Prompt and workflow improvements
- Examples and use cases
Please open an issue first for significant changes to discuss the approach.
- Fork and clone the repository.
- Ensure you have Python 3.12+ installed (for pre-commit hooks).
- Set up the development environment:
pip install pre-commit
pre-commit install- Install pre-commit hooks once with
pre-commit install. - Keep changes small and focused; prefer incremental PRs.
- All prompts are plain Markdown files in the
prompts/directory.
To prevent accidental commits of API keys, tokens, or other sensitive data (especially in proof artifacts), consider adding secret scanning to your pre-commit configuration:
# Add to .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0 # Update to the latest version (run `pre-commit autoupdate`)
hooks:
- id: gitleaks# Add to .pre-commit-config.yaml
repos:
- repo: https://github.com/trufflesecurity/trufflehog
rev: v3.63.0 # Update to the latest version (run `pre-commit autoupdate`)
hooks:
- id: trufflehog
args: ['--trace', 'filesystem', '.']# Add to .pre-commit-config.yaml
repos:
- repo: https://github.com/Yelp/detect-secrets
rev: v1.4.0 # Update to the latest version (run `pre-commit autoupdate`)
hooks:
- id: detect-secrets
args: ['--baseline', '.secrets.baseline']After adding a secret scanner, run pre-commit install again to activate it. The scanner will automatically check files before each commit and block commits containing potential secrets.
See the pre-commit hooks documentation for more secret scanning options.
⚠️ Note: To keep your hooks current with the latest versions, periodically runpre-commit autoupdate.
# Preview the docs site locally with hot reload
uvx livereload --port 8012 docs/
# Run full pre-commit checks across the repo
pre-commit run --all-files
# Run markdown linting only
pre-commit run markdownlint-fix --all-files
# Run docs and prompt spell checking only
pre-commit run cspell --all-files- Markdown is linted using markdownlint (via pre-commit). Keep lines reasonably short and headings well structured.
- Public-facing docs and workflow prompts are spell-checked with cspell. Add broadly reusable project terms to
cspell.config.yamland prefer file-specific config for one-off names. - YAML files are validated for syntax errors.
- Commit messages must follow Conventional Commits specification (enforced via commitlint).
- Keep documentation consistent with
README.md.
Before submitting a PR, run:
# Run all pre-commit checks
pre-commit run --all-filesThis will:
- Check YAML syntax
- Fix Markdown formatting issues
- Spell-check public-facing documentation and workflow prompts
- Validate commit message format (on commit)
Use short, descriptive branch names with a category prefix:
feat/<short-topic>fix/<short-topic>docs/<short-topic>chore/<short-topic>refactor/<short-topic>
Examples:
feat/new-promptdocs/usage-examplesfix/prompt-typo
We follow the Conventional Commits specification. Examples:
feat: add new validation promptfix: correct typo in generate-spec promptdocs: add usage exampleschore: update markdownlint config
If a change is breaking, include ! (e.g., feat!: restructure prompt format).
Semantic versioning and releases are automated in CI using python-semantic-release. Contributors only need to follow Conventional Commits; no manual tagging is required.
- Keep PRs focused and well scoped.
- PR titles must follow Conventional Commits format (e.g.,
feat: add new feature). This is enforced by an automated check. - PR description template:
## Why?
## What Changed?
## Additional Notes- Ensure all checks pass (pre-commit) before requesting review.
- Reference related issues where applicable.
PR titles are validated automatically and must follow this format:
<type>(<optional scope>): <description>
Valid types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
Examples:
feat(auth): add login button to navigationfix: resolve race condition in async handlerdocs: update installation instructionschore: bump dependencies and run pre-commit
The description should:
- Start with a lowercase letter
- Be concise and descriptive
- Use imperative mood (e.g., "add" not "added" or "adds")
Breaking changes: Add ! after the type (e.g., feat!: drop Python 3.10 support)
If the automated check fails, update your PR title and it will re-run automatically.
Use the GitHub issue templates under .github/ISSUE_TEMPLATE/ for bug reports, feature requests, and questions. These templates prompt for summary, context/repro, and related prompt/workflow information.
We strive to maintain a welcoming and respectful community. Please review our Code of Conduct to understand our community standards and expectations.
If you have any concerns, please contact the Liatrio Maintainers team (@liatrio-labs/liatrio-labs-maintainers) or use GitHub's private reporting form for this repository.
README.md— overview and quick start.pre-commit-config.yaml— linting and formatting hooks.github/ISSUE_TEMPLATE/— issue forms