You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
--body "Automated release of ${{ steps.version.outputs.version }}.
151
167
152
168
This PR was created by the Release Trigger workflow. The git tag \`${{ steps.version.outputs.tag }}\` has already been pushed and the release artifacts are being built.
153
169
154
-
Merge this PR to record the version bump and changelog update on \`main\`."
170
+
Merging this PR will set \`main\` to \`${{ steps.dev_version.outputs.dev_version }}\` so that development installs are clearly marked as pre-release."
155
171
156
172
- name: Summary
157
173
run: |
158
174
echo "✅ Version bumped to ${{ steps.version.outputs.version }}"
159
175
echo "✅ Tag ${{ steps.version.outputs.tag }} created and pushed"
176
+
echo "✅ Dev version set to ${{ steps.dev_version.outputs.dev_version }}"
160
177
echo "✅ PR opened to merge version bump into main"
161
178
echo "🚀 Release workflow is building artifacts from the tag"
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+14-1Lines changed: 14 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,14 +36,17 @@ On [GitHub Codespaces](https://github.com/features/codespaces) it's even simpler
36
36
> If your pull request introduces a large change that materially impacts the work of the CLI or the rest of the repository (e.g., you're introducing new templates, arguments, or otherwise major changes), make sure that it was **discussed and agreed upon** by the project maintainers. Pull requests with large changes that did not have a prior conversation and agreement will be closed.
37
37
38
38
1. Fork and clone the repository
39
-
1. Configure and install the dependencies: `uv sync`
39
+
1. Configure and install the dependencies: `uv sync --extra test`
40
40
1. Make sure the CLI works on your machine: `uv run specify --help`
41
41
1. Create a new branch: `git checkout -b my-branch-name`
42
42
1. Make your change, add tests, and make sure everything still works
43
43
1. Test the CLI functionality with a sample project if relevant
44
44
1. Push to your fork and submit a pull request
45
45
1. Wait for your pull request to be reviewed and merged.
46
46
47
+
For the detailed test workflow, command-selection prompt, and PR reporting template, see [`TESTING.md`](./TESTING.md).
48
+
Activate the project virtual environment (see the Setup block in [`TESTING.md`](./TESTING.md)), then install the CLI from your working tree (`uv pip install -e .` after `uv sync --extra test`) or otherwise ensure the shell uses the local `specify` binary before running the manual slash-command tests described below.
49
+
47
50
Here are a few things you can do that will increase the likelihood of your pull request being accepted:
48
51
49
52
- Follow the project's coding conventions.
@@ -62,6 +65,14 @@ When working on spec-kit:
62
65
3. Test script functionality in the `scripts/` directory
63
66
4. Ensure memory files (`memory/constitution.md`) are updated if major process changes are made
64
67
68
+
### Recommended validation flow
69
+
70
+
For the smoothest review experience, validate changes in this order:
71
+
72
+
1.**Run focused automated checks first** — use the quick verification commands in [`TESTING.md`](./TESTING.md) to catch packaging, scaffolding, and configuration regressions early.
73
+
2.**Run manual workflow tests second** — if your change affects slash commands or the developer workflow, follow [`TESTING.md`](./TESTING.md) to choose the right commands, run them in an agent, and capture results for your PR.
74
+
3.**Use local release packages when debugging packaged output** — if you need to inspect the exact files CI-style packaging produces, generate local release packages as described below.
75
+
65
76
### Testing template and command changes locally
66
77
67
78
Running `uv run specify init` pulls released packages, which won’t include your local changes.
@@ -85,6 +96,8 @@ To test your templates, commands, and other changes locally, follow these steps:
85
96
86
97
Navigate to your test project folder and open the agent to verify your implementation.
87
98
99
+
If you only need to validate generated file structure and content before doing manual agent testing, start with the focused automated checks in [`TESTING.md`](./TESTING.md). Keep this section for the cases where you need to inspect the exact packaged output locally.
0 commit comments