For help, support, questions and ideas please use our forum 🚑.
The codebase documentation explains how to set up the monorepo and find your way around it. Start with the development setup guide, then use the contribution workflow when you are ready to make a change.
If you're not sure what to work on, start with good first issues or browse the broader help wanted list.
Discuss new features and substantial product or architectural changes in the forum before implementing them.
We have a handful of simple standards for commit messages which keep the main branch readable and generate useful release notes. They matter most for pull request titles and squash commits; follow them for intermediate commits where practical.
<optional release-note emoji> <past-tense summary, at most 80 characters>
<optional issue relationship, or "no ref">
<why this change was made>
- Start the summary with
Fixed,Changed,Updated,Improved,Added,Removed,Reverted,Moved,Released,Bumped, orCleaned. - Keep the second line blank.
- When an issue exists, use a supported relationship followed by its URL, such
as
ref <issue URL>,fixes <issue URL>, orcloses <issue URL>. Useno refwhen it is useful to state explicitly that there is no issue, or leave this line blank. - Explain the context in the body: why this change, why now, and why this approach. The diff already describes what changed.
The local hook warns about most deviations without blocking the commit. It
does require the common invalid forms refs ... and ref: ... to be corrected
to a supported relationship such as ref ....
A leading release-note emoji opts the squash commit into generated release notes. Add one only for a significant change that is relevant to users, and write the summary from their perspective. Alpha or experimental work does not need an emoji until it becomes user-facing.
- ✨ Feature
- 🎨 Improvement or change
- 🐛 Bug fix
- 💡 Other noteworthy user-facing change
Use 🌐 for translation submissions. Translation commits are not selected for generated release notes by that emoji alone.
Good final commit examples include a new feature, a bug fix, and a translation.
Bumping @tryghost dependencies
When bumping @tryghost/* dependencies, describe the user-visible result rather
than which packages were bumped. The diff already shows the package changes;
the message should explain what changed because of them. See this
good example.
Ghost publishes several workspace packages to npm — the @tryghost/* editor and adapter packages under koenig/ and packages/. When your change affects one of these publishable packages, including by changing a catalog entry it consumes, add a changeset so it gets a version bump and a changelog entry:
pnpm changeThis records which packages changed and the bump type (patch / minor / major); the summary you provide becomes the changelog entry. If the change genuinely needs no release (an internal refactor, tests, tooling), record that explicitly instead:
pnpm change --bump noneA package README.md is published with the package and requires a release.
Repository-only Markdown such as AGENTS.md, CLAUDE.md, changelogs, and
package-local docs/ does not.
CI enforces this — the Check app version bump job fails a pull request that affects a publishable package without a covering changeset. The pre-commit hook prints a non-blocking reminder locally, and pnpm change status shows what's currently pending.
For more detail, see the contribution workflow.
We aim to merge any straightforward, well-understood bug fixes or improvements immediately, as long as they pass our tests (run pnpm check to ensure everything works). We generally don’t merge new features and larger changes without prior discussion with the core product team for tech/design specification.
Please provide plenty of context and reasoning around your changes, to help us merge quickly. Closing an already open issue is our preferred workflow. If your PR gets out of date, we may ask you to rebase as you are more familiar with your changes than we will be.
For branch, validation, and pull request details, follow the contribution workflow.
By contributing your code to Ghost you grant the Ghost Foundation a non-exclusive, irrevocable, worldwide, royalty-free, sublicenseable, transferable license under all of Your relevant intellectual property rights (including copyright, patent, and any other rights), to use, copy, prepare derivative works of, distribute and publicly perform and display the Contributions on any licensing terms, including without limitation: (a) open source licenses like the MIT license; and (b) binary, proprietary, or commercial licenses. Except for the licenses granted herein, You reserve all right, title, and interest in and to the Contribution.
You confirm that you are able to grant us these rights. You represent that You are legally entitled to grant the above license. If Your employer has rights to intellectual property that You create, You represent that You have received permission to make the Contributions on behalf of that employer, or that Your employer has waived such rights for the Contributions.
You represent that the Contributions are Your original works of authorship, and to Your knowledge, no other person claims, or has the right to claim, any right in any invention or patent related to the Contributions. You also represent that You are not legally obligated, whether by entering into an agreement or otherwise, in any way that conflicts with the terms of this license.
The Ghost Foundation acknowledges that, except as explicitly described in this Agreement, any Contribution which you provide is on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.