This repository contains the Standard Terms and Special Terms template for independent contractors working with Holdex Limited. It is published publicly for transparency.
Issues and Discussions are disabled. For questions, reach out through your existing Holdex contact.
contractor-terms/
├── .github/
│ └── workflows/
│ └── lint.yml — markdown lint and link validation
├── .rumdl.toml — markdown lint configuration
├── README.md — this file
├── STANDARD_TERMS.md — the legal document (versioned by git tags)
├── SPECIAL_TERMS.md — blank template (filled in per contractor by HR; keep only the relevant compensation subsection)
└── CHANGELOG.md — plain English version history
Each contractor engagement produces two documents:
1. Standard Terms (STANDARD_TERMS.md)
The boilerplate legal terms governing all contractor relationships. Versioned
by git tags (e.g. v1.0.0). The tag is the version — git timestamps it
automatically. Never edited retroactively.
2. Special Terms (SPECIAL_TERMS.md)
A blank template stored here. When preparing an agreement for a specific
contractor, HR copies and fills in the template, then stores the completed
version in the private HR repository alongside any signed artifacts.
The contractor signs a document that references both:
- The Standard Terms by tag (e.g.
v1.0.0) - The Special Terms by the commit of their filled-in copy
Copy SPECIAL_TERMS.md to the private HR repository and name it AGREEMENT.md. Fill in all
<!-- PLACEHOLDER --> fields. In the Compensation section, keep only
the subsection that applies to this contractor (Hourly, Per Project, or
Milestone-Based) and delete the other two. Record the Standard Terms tag
currently in effect (e.g. v1.1.0) at the top of the document.
Share the filled-in Special Terms with the contractor for review and signature.
Signatures are collected digitally through PandaDoc.
Store the signed AGREEMENT_SIGNED.pdf file in the private HR repository.
Ensure the signed copy clearly references the Standard Terms tag in effect at the date of signing. This is the version that governs that contractor's relationship indefinitely unless updated per the process below.
Follow these steps every time STANDARD_TERMS.md is changed.
Never edit past releases.
git checkout main
git pull
git checkout -b update/describe-your-changeMake your changes. Keep formatting consistent — the lint workflow will flag issues automatically when you open a PR.
Add a new entry at the top describing what changed and why, in plain English.
Push your branch and open a PR against main. A review and approval is
required before merging.
git add STANDARD_TERMS.md CHANGELOG.md
git commit -m "update: describe your change in plain English"
git push origin update/describe-your-changeOnce approved and merged:
git checkout main
git pull
git tag v1.1.0 # increment the version number
git push origin v1.1.0Then go to GitHub → Releases → Draft a new release, select the tag, and publish. Copy the release URL — you will need it for contractor notifications.
Send an email to all active contractors with:
- A summary of what changed
- A link to the new release
- The date the new terms take effect (minimum 14 days from the email date)
Use the subject line: Holdex Contractor Terms Update — [version_number] effective [DATE]
| Tag | Meaning |
|---|---|
v1.0.0 |
Initial release |
v1.1.0 |
Minor update — clarification, new clause, small change |
v2.0.0 |
Major update — significant change to rights, obligations, or payment terms |
When in doubt, increment the minor version. Use a major version bump when the change materially affects contractor obligations or Company rights — these warrant extra care in contractor communication.
Runs on every PR to main that touches a .md file. Two steps:
- rumdl — enforces consistent markdown formatting per
.rumdl.toml - lychee — validates all URLs and internal anchor links
A PR cannot be merged if either step fails.
This repository is owned and maintained by the HR team at Holdex Limited. For questions or proposed changes, raise them internally through the HR team.
Holdex Limited — holdex.io