@snappedly-tools/shipyard 0.5.0 → 0.6.0

package/dist/templates/parallel-planner-with-review/merge-prompt.md

@@ -1,26 +1,14 @@
-# TASK
+# Final integration for scope #{{TASK_ID}}: {{ISSUE_TITLE}}
 
-Merge the following branches into the current branch:
+On branch `{{BRANCH}}`, inspect the issue and final diff from `{{BASE_BRANCH}}`. Follow `/code-cleanup` on the complete integrated change, including a planning spec and all scoped tickets. The selected template has already run an independent `/code-review`; perform final integration checks and preserve its result when content is unchanged. Reinstall candidate dependencies with `bash .shipyard/setup.sh` after manifest changes. Commit any authorized correction and report its affected checks. The surrounding workflow repeats `/code-review` when this stage makes commits.
 
-{{BRANCHES}}
+Do not close the issue, merge into the target, publish the PR, or start another review chain. If checks remain unresolved, explain why without completion. After verified final content, report `Checks: <commands and results>`, the prior `Review: APPROVED` result, and limitations:
 
-For each branch:
+<handoff>...</handoff>
+<promise>COMPLETE</promise>
 
-1. Run `git merge <branch> --no-edit`
-2. If there are merge conflicts, resolve them intelligently by reading both sides and choosing the correct resolution
-3. After resolving conflicts, read the repository's configured feedback-loop contract and run every applicable check for the merged change
-4. If a check fails, fix the issue before proceeding to the next branch
+For a planning spec, follow `/implement-spec` for whole-spec integration, cleanup, and final checks on the one spec branch. Read parent and all scoped child bodies and comments, inspect dependency order and merged commits, and resolve gaps before completion. Never merge the target branch or close issues.
 
-After all branches are merged, make a single commit summarizing the merge.
-
-# CLOSE ISSUES
-
-For each branch that was merged, close its issue using the following command:
-
-`{{CLOSE_TASK_COMMAND}}`
-
-Here are all the issues:
-
-{{ISSUES}}
-
-Once you've merged everything you can, output <promise>COMPLETE</promise>.
+```json
+{{SCOPE}}
+```

package/dist/templates/parallel-planner-with-review/plan-prompt.md

@@ -1,37 +1,11 @@
-# ISSUES
-
-Here are the open issues in the repo:
+# Activated issue scopes
 
 <issues-json>
-
-!`{{LIST_TASKS_COMMAND}}`
-
+!`node .shipyard/select-issues.mjs`
 </issues-json>
 
-The list above has already been filtered to issues ready for work.
-
-# TASK
-
-Analyze the open issues and build a dependency graph. For each issue, determine whether it **blocks** or **is blocked by** any other open issue.
-
-An issue B is **blocked by** issue A if:
-
-- B requires code or infrastructure that A introduces
-- B and A modify overlapping files or modules, making concurrent work likely to produce merge conflicts
-- B's requirements depend on a decision or API shape that A will establish
-
-An issue is **unblocked** if it has zero blocking dependencies on other open issues.
-
-For each unblocked issue, assign a branch name using the exact format `shipyard/issue-{id}` (no slug or other suffix). This must be deterministic so that re-planning the same issue always produces the same branch name and accumulated progress is preserved.
-
-# OUTPUT
-
-Output your plan as a JSON object wrapped in `<plan>` tags:
-
-<plan>
-{"issues": [{"id": "42", "title": "Fix auth bug", "branch": "shipyard/issue-42"}]}
-</plan>
+Use exactly these resolved scopes as the ready frontier. `scope.tickets` contains only selected tickets with the `shipyard` label; other linked tickets are context and must not be implemented. For planning specs, follow `/implement-spec` when planning the selected scope, honoring child dependencies and overlapping files. The surrounding template will run ready tickets in parallel with scoped `/implement` workers, integrate each dependency wave into one spec branch, then perform integrated cleanup, review, and one PR handoff. Do not omit selected tickets, invent scope IDs, create PRs, merge to target, or close issues.
 
-Include only unblocked issues. If every issue is blocked, include the single highest-priority candidate (the one with the fewest or weakest dependencies).
+Emit each selected scope once, by its parent or standalone ID. If no scope is ready, emit an empty array:
 
-Always emit the `<plan>` tags, even when there is nothing to do. If there are no issues to work on at all, output `<plan>{"issues": []}</plan>` so the run can exit cleanly.
+<plan>{"issues":[{"id":"42"}]}</plan>

package/dist/templates/parallel-planner-with-review/review-prompt.md

@@ -1,55 +1,17 @@
-# TASK
+# Independent review of issue #{{TASK_ID}}
 
-Review the code changes on branch `{{BRANCH}}` and improve code clarity, consistency, and maintainability while preserving exact functionality.
+Review the complete scope on branch `{{BRANCH}}` against `{{BASE_BRANCH}}`, the issue requirements, `AGENTS.md`, `docs/agents/workflow.md`, and `.shipyard/CODING_STANDARDS.md`. Follow `/code-review`. Inspect the exact diff, behavior tests, correctness and security; reuse valid worker checks. This explicit review stage must complete before the final integration stage.
 
-# CONTEXT
+Resolve authorized findings on this branch, run affected checks, and commit fixes. Do not close the issue, create a PR, merge to target, or start another orchestration chain. If required findings remain open or checks are missing, report them and omit approval.
 
-## Branch diff
+Only when review permits handoff, report `Review: APPROVED`, its findings, dispositions, `Checks: <commands and results>` for changed checks, and limitations:
 
-!`git diff {{TARGET_BRANCH}}...{{BRANCH}}`
+<handoff>...</handoff>
+<review>APPROVED</review>
+<promise>COMPLETE</promise>
 
-## Commits on this branch
+For a planning spec, review the integrated parent and all scoped children together. Read all issue bodies and comments. Resolved scope:
 
-!`git log {{TARGET_BRANCH}}..{{BRANCH}} --oneline`
-
-# REVIEW PROCESS
-
-1. **Understand the change**: Read the diff and commits above to understand the intent.
-
-2. **Analyze for improvements**: Look for opportunities to:
-   - Reduce unnecessary complexity and nesting
-   - Eliminate redundant code and abstractions
-   - Improve readability through clear variable and function names
-   - Consolidate related logic
-   - Remove unnecessary comments that describe obvious code
-   - Avoid nested ternary operators - prefer switch statements or if/else chains
-   - Choose clarity over brevity - explicit code is often better than overly compact code
-
-3. **Check correctness**:
-   - Does the implementation match the intent? Are edge cases handled?
-   - Are new/changed behaviours covered by tests?
-   - Are there unsafe casts, `any` types, or unchecked assumptions?
-   - Does the change introduce injection vulnerabilities, credential leaks, or other security issues?
-
-4. **Maintain balance**: Avoid over-simplification that could:
-   - Reduce code clarity or maintainability
-   - Create overly clever solutions that are hard to understand
-   - Combine too many concerns into single functions or components
-   - Remove helpful abstractions that improve code organization
-   - Make the code harder to debug or extend
-
-5. **Apply project standards**: Follow the coding standards defined in @.shipyard/CODING_STANDARDS.md
-
-6. **Preserve functionality**: Never change what the code does - only how it does it. All original features, outputs, and behaviors must remain intact.
-
-# EXECUTION
-
-If you find improvements to make:
-
-1. Make the changes directly on this branch
-2. Run tests and type checking to ensure nothing is broken
-3. Commit describing the refinements
-
-If the code is already clean and well-structured, do nothing.
-
-Once complete, output <promise>COMPLETE</promise>.
+```json
+{{SCOPE}}
+```