Add verification toggle to orchestrate preset - #6
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new boolean input run_verify to conditionally enable or disable the verification and documentation reconciliation steps. The feedback highlights an issue where quoting the Jinja expression "{{ inputs.run_verify }}" results in a string value in YAML, which may evaluate to truthy even when false. The reviewer suggests using a Jinja control block to output an unquoted boolean value instead.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| requiredCapabilities: | ||
| - git | ||
| - title: Verify completion | ||
| enabled: "{{ inputs.run_verify }}" |
There was a problem hiding this comment.
Using double quotes around the Jinja expression enabled: "{{ inputs.run_verify }}" will render as enabled: "True" or enabled: "False". In YAML, quoted values are parsed as strings rather than booleans. In many orchestration engines or languages (like Python, JavaScript, or Go), any non-empty string (including "False" or "false") evaluates to True in boolean contexts, which would cause this step to run even when run_verify is set to false.\n\nTo ensure it is parsed as a proper boolean while remaining valid YAML before rendering, you can use a Jinja control block:
enabled: {% if inputs.run_verify %}true{% else %}false{% endif %}| id: moonspec-verify | ||
| args: {} | ||
| - title: Reconcile declarative docs | ||
| enabled: "{{ inputs.run_verify }}" |
There was a problem hiding this comment.
Using double quotes around the Jinja expression enabled: "{{ inputs.run_verify }}" will render as enabled: "True" or enabled: "False". In YAML, quoted values are parsed as strings rather than booleans. In many orchestration engines or languages (like Python, JavaScript, or Go), any non-empty string (including "False" or "false") evaluates to True in boolean contexts, which would cause this step to run even when run_verify is set to false.\n\nTo ensure it is parsed as a proper boolean while remaining valid YAML before rendering, you can use a Jinja control block:
enabled: {% if inputs.run_verify %}true{% else %}false{% endif %}![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
馃挕 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6a804eeb2f
鈩癸笍 About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 馃憤.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| requiredCapabilities: | ||
| - git | ||
| - title: Verify completion | ||
| enabled: "{{ inputs.run_verify }}" |
There was a problem hiding this comment.
When a user sets Run Verification to false on a fresh or stale feature, this only disables the explicit verify step here; the preset still requires tasks.md to include final /moonspec.verify work (bundle/presets/moonspec-orchestrate.yaml:66), and moonspec-implement runs /moonspec.verify whenever that task is present (bundle/skills/moonspec-implement/SKILL.md:179). As a result, the new opt-out still performs verification during the implementation step, defeating the toggle for environments where verification is intentionally skipped.
Useful? React with 馃憤聽/ 馃憥.
Address PR #6 review feedback for the orchestrate verification toggle: - Render the Verify and Reconcile step `enabled` fields as an empty (falsy) string when run_verify is false instead of a quoted "False" string, which orchestration engines treat as truthy. Keeps the preset valid raw YAML so validate_bundle and the bundle tests still parse it. - Honor run_verify end-to-end: the task-breakdown step no longer adds a final /moonspec.verify task and the implement step does not run /moonspec.verify when the toggle is off, so verification cannot leak through the implementation step. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1 participant
Summary
Tests