@laitszkin/apollo-toolkit 3.9.1 → 3.9.3

package/implement-specs-with-worktree/SKILL.md

@@ -10,7 +10,7 @@ description: >-
 
 ## Dependencies
 
-- Required: `implement-specs` for the shared discovery / implementation / backfill / commit / reporting lifecycle; `enhance-existing-features` and `develop-new-features` for implementation standards.
+- Required: `implement-specs` for the shared discovery / implementation / backfill / **submit** / reporting lifecycle; **`commit-and-push`** for the **final** implementation commit (and push when the user explicitly requests remote update); `enhance-existing-features` and `develop-new-features` for implementation standards.
 - Conditional: `generate-spec` if spec files need clarification or updates.
 - Fallback: If any required dependency skill is unavailable, **MUST** stop and report it.
 
@@ -24,7 +24,7 @@ description: >-
 - **MUST** use `git show-ref` and `git worktree list --porcelain` (not shell guesses) when checking whether a branch or worktree already exists; if creation fails ambiguously, **MUST** re-query those commands before retrying.
 - When `preparation.md` exists: **MUST** treat it as an already-committed shared baseline for parallel work; **MUST NOT** redo its tasks inside the member spec unless the preparation commit is missing or the document states the prerequisite is still blocked. If baseline assumptions break, **MUST** update `preparation.md` or stop for coordination—**MUST NOT** silently move prerequisite work into the member spec.
 - **MUST** complete the same quality bar as `implement-specs`: all in-scope tasks, relevant tests, honest backfill, no sibling-spec scope creep, revert formatter-only noise outside owned files before commit.
-- **MUST NOT** `git push` unless the user explicitly asks.
+- **MUST NOT** `git push` **outside** **`commit-and-push`** unless the user explicitly requests remote update through that workflow (or a release/PR skill the user named).
 - For targeted Rust tests: **MUST** pass at most one positional `cargo test` filter per invocation; use separate commands or a broader confirmed filter when multiple selectors are needed.
 
 ## Standards (summary)
@@ -59,7 +59,7 @@ description: >-
 
 ### C) Implement, backfill, commit, report
 
-- Execute **`implement-specs` Workflow steps 3–6** (implement, backfill, commit, report) **entirely from the worktree root**, applying `enhance-existing-features` / `develop-new-features` standards.
+- Execute **`implement-specs` Workflow steps 3–6** (implement, backfill, **submit via `commit-and-push`**, report) **entirely from the worktree root**, applying `enhance-existing-features` / `develop-new-features` standards.
 - In the report, **MUST** include branch name, worktree path, commit hash, tests run, backfilled docs, and an explicit statement that the parent checkout was not modified for implementation files.
   - **Pause →** Am I honoring **implement-specs** step 3–6 **constraints** literally while respecting that all writes happen **only** under this worktree root?
   - **Pause →** If I used Rust `cargo test` filters, did I violate the **single positional filter** rule; how would I split the commands?
@@ -80,6 +80,6 @@ description: >-
 
 ## References
 
-- `implement-specs`: shared lifecycle (read → implement → backfill → commit → report)
+- `implement-specs`: shared lifecycle (read → implement → backfill → **`commit-and-push`** → report)
 - `references/branch-naming.md`: branch naming
 - `enhance-existing-features`, `develop-new-features`: implementation standards

package/merge-conflict-resolver/SKILL.md

@@ -8,14 +8,14 @@ description: Resolve git merge conflicts using deterministic rules that preserve
 ## Dependencies
 
 - Required: none.
-- Conditional: none.
+- Conditional: **`commit-and-push`** when the user expects the resolved tree to be **committed** or **pushed**—**MUST** run that skill for the submission leg instead of bare `git commit` / ad-hoc push when readiness gates apply.
 - Optional: none.
-- Fallback: not applicable.
+- Fallback: If a **gated** submission was requested but **`commit-and-push`** is unavailable, **MUST** stop and report.
 
 ## Standards
 
 - Evidence: Read both parent versions from conflict markers before resolving.
-- Execution: Read conflicts → apply scenario rules → verify with tests → recommit.
+- Execution: Read conflicts → apply scenario rules → verify with tests → recommit via **`commit-and-push`** when persisting to git.
 - Quality: Prefer preserving functionality over keeping either branch's exact changes.
 - Output: Return resolved files with passing verification.
 

package/open-source-pr-workflow/SKILL.md

@@ -7,15 +7,15 @@ description: PR-focused workflow for open-source repositories. Use when the user
 
 ## Dependencies
 
-- Required: none.
+- Required: **`commit-and-push`** before publishing the contribution branch (any remaining changes **MUST** be committed/readiness-checked through that skill; **push** only when the user requested remote update—then continue to PR steps).
 - Conditional: `discover-edge-cases` and `code-simplifier` for code-affecting PRs before opening the PR.
 - Optional: none.
-- Fallback: If a required code-affecting dependency is unavailable, stop and report the missing dependency instead of bypassing the quality gate.
+- Fallback: If **`commit-and-push`** or a **required** code-affecting dependency is unavailable, stop and report the missing dependency instead of bypassing the quality gate.
 
 ## Standards
 
 - Evidence: Assume implementation is already prepared, then verify PR scope, repository constraints, and validation commands from the actual change set.
-- Execution: Create a compliant `codex/{change_type}/{changes}` branch, run the required quality gates for code changes, then draft and open the PR.
+- Execution: Create a compliant branch, run **`commit-and-push`** when the working tree still needs a gated commit, run dependent skills for code changes, then draft and open the PR.
 - Quality: Target the upstream parent repository by default for forks, keep PR content in English unless requested otherwise, and exclude internal workflow details.
 - Output: Produce a review-ready PR body with motivation, engineering rationale, test commands, and any required issue linkage.
 
@@ -47,7 +47,12 @@ Example:
 git checkout -b codex/fix/add-rate-limit-retry
 ```
 
-### 3) Run dependent skills for code-affecting changes
+### 3) Record changes with `commit-and-push`
+
+- If `git status` shows uncommitted work on the PR branch, run **`commit-and-push`** through commit (and **push** when the user explicitly asked to publish the branch remotely) before PR creation—**MUST NOT** bypass readiness/review gates that skill applies.
+- If the tree is already clean with commits present, skip only after confirming there is nothing left to stage.
+
+### 4) Run dependent skills for code-affecting changes
 
 - If the PR includes code changes, run `discover-edge-cases` first to discover unresolved edge-case risks.
 - Resolve any confirmed findings before continuing.
@@ -56,14 +61,14 @@ git checkout -b codex/fix/add-rate-limit-retry
 - Use these skills as internal quality gates only; do not include skill/tool names in PR content.
 - If the PR has no code changes, explicitly note that these two skills were not required in internal notes only.
 
-### 4) Verify existing changes (no feature implementation in this skill)
+### 5) Verify existing changes (no feature implementation in this skill)
 
 - Assume code/documentation changes are already prepared before entering this workflow.
 - Do not add new feature implementation in this skill.
 - After the dependent skills step (when required), run relevant checks (lint/test/build) based on repository conventions.
 - Record exact test commands and outcomes for PR content.
 
-### 5) Prepare PR content (show draft only on request)
+### 6) Prepare PR content (show draft only on request)
 
 - Draft the PR title and full PR body before creating the PR.
 - Keep PR content strictly about the PR itself (motivation, changes, rationale, tests).
@@ -72,7 +77,7 @@ git checkout -b codex/fix/add-rate-limit-retry
 - Show the draft only when the user explicitly asks to review it before creating the PR.
 - If the user asks for draft edits, revise accordingly and get final confirmation before creating the PR.
 
-### 6) Open the PR
+### 7) Open the PR
 
 - Prefer `gh pr create` to open the PR.
 - If the repository is a fork, target the upstream parent repository by default (for example `gh pr create --repo <upstream-owner>/<upstream-repo> --head <fork-owner>:<branch>`).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@laitszkin/apollo-toolkit",
-  "version": "3.9.1",
+  "version": "3.9.3",
   "description": "Apollo Toolkit npm installer for managed skill copying across Codex, OpenClaw, and Trae.",
   "license": "MIT",
   "author": "LaiTszKin",

package/resolve-review-comments/SKILL.md

@@ -5,12 +5,19 @@ description: Read GitHub pull request review comments, analyze each thread, deci
 
 # Resolve Review Comments
 
+## Dependencies
+
+- Required: **`commit-and-push`** for staging adopted fixes, creating the commit, and **pushing** when the user requested a PR branch update—**MUST NOT** substitute bare `git commit` / unverified push for that leg.
+- Conditional: none.
+- Optional: none.
+- Fallback: If **`commit-and-push`** is unavailable when submission is required, **MUST** stop and report.
+
 ## Standards
 
 - Evidence: Read unresolved review threads first and decide adopt versus reject from the actual review content and code context.
-- Execution: Implement only adopted feedback, validate it, push to the same PR branch, and resolve only the threads that were truly addressed.
+- Execution: Implement only adopted feedback, validate it, **`commit-and-push`** on the same PR branch (commit + push when remote update is in scope), and resolve only the threads that were truly addressed.
 - Quality: Keep changes minimal, leave rejected or unclear threads unresolved, and reply with concise technical reasons when feedback is not adopted.
-- Output: Complete the PR feedback loop with updated code, pushed commits, and correctly resolved review threads.
+- Output: Complete the PR feedback loop with updated code, **`commit-and-push`**-verified submission when applicable, and correctly resolved review threads.
 
 ## Prerequisites
 
@@ -25,7 +32,7 @@ description: Read GitHub pull request review comments, analyze each thread, deci
 3. Decide adopt or reject thread-by-thread.
 4. Implement only adopted feedback.
 5. Run relevant tests and checks.
-6. Commit and push to the same PR branch.
+6. **Submit** — Run **`commit-and-push`** on the same PR branch (commit always when there are staged fixes; **push** when updating the remote PR branch is in scope).
 7. Resolve only threads that were truly addressed.
 8. Reply on unresolved/rejected threads with reason.
 
@@ -72,15 +79,14 @@ Track adopted thread IDs in a JSON file:
 - Keep changes minimal and scoped to adopted comments.
 - Reuse existing patterns; avoid unrelated refactors.
 
-## 5) Validate before push
+## 5) Validate before submit
 
 - Run focused tests/lint/build that cover touched behavior.
-- If checks fail, fix before pushing.
+- If checks fail, fix before **`commit-and-push`**.
 
-## 6) Commit and push to same PR
+## 6) Submit on the PR branch
 
-- Create a clear commit describing why feedback was adopted.
-- Push to the PR branch (same branch backing the open PR).
+- Run **`commit-and-push`**: stage adopted fixes, commit with a clear message, **push** to the PR branch when remote update is in scope (same branch backing the open PR).
 
 ## 7) Resolve addressed threads
 

package/review-change-set/README.md

@@ -10,7 +10,7 @@ This skill:
 2. Rejects authorship bias, including confidence in code written earlier in the same conversation.
 3. Looks for architecture-level abstraction opportunities.
 4. Looks for code that can be simplified without changing behavior.
-5. Runs `harden-app-security` as a required adversarial cross-check for code-affecting changes.
+5. Runs `discover-security-issues` as a required adversarial cross-check for code-affecting changes.
 
 ## When to use
 
@@ -27,7 +27,7 @@ Use this skill when the task asks you to:
 - Treat recent edits as untrusted until evidence proves otherwise.
 - Prefer fewer, stronger findings over broad speculative advice.
 - Focus on architecture and simplification, not cosmetic style feedback.
-- Reuse confirmed security findings from `harden-app-security` instead of hand-waving about risk.
+- Reuse confirmed security findings from `discover-security-issues` instead of hand-waving about risk.
 
 ## Example
 
@@ -44,7 +44,7 @@ Expected behavior:
 - changed files are read before conclusions,
 - findings cite exact evidence,
 - architecture issues are prioritized over style comments,
-- security-sensitive changes are cross-checked through `harden-app-security`.
+- security-sensitive changes are cross-checked through `discover-security-issues`.
 
 ## References
 

package/review-change-set/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: review-change-set
-description: Review the current git change set from an unbiased reviewer perspective, identify architecture-level abstraction opportunities and code simplification candidates, and challenge security assumptions through harden-app-security. Use when users ask for a diff review, refactor review, abstraction review, simplification review, or a pre-commit/pre-PR second opinion on current changes.
+description: >-
+  Unbiased **git diff** review: architecture (boundaries, duplication, ownership) then simplification (real deletes/flattening, not churn)—discard conversation bias. Code-affecting changes **MUST** cross-check with **`discover-security-issues`**; integrate only **confirmed** findings—no invented CWE drama.
+  Use for pre-commit/pre-PR review, refactor/abstraction second opinion, “review my branch” **STOP** greenfield feature design from scratch—use planning skills… BAD style-only nits… GOOD evidence + named abstraction target…
 ---
 
 # Review Change Set
@@ -8,92 +10,75 @@ description: Review the current git change set from an unbiased reviewer perspec
 ## Dependencies
 
 - Required: none.
-- Conditional: `harden-app-security` for code-affecting changes before finalizing review conclusions.
+- Conditional: **`discover-security-issues`** for **code-affecting** changes before final conclusions.
 - Optional: none.
-- Fallback: If the required security cross-check is unavailable for a code-affecting scope, stop and report the missing dependency.
+- Fallback: If the security cross-check is **required** but unavailable, **MUST** stop and report.
 
-## Standards
+## Non-negotiables
 
-- Evidence: Read the full active diff plus the minimum dependency chain needed to understand the changed behavior.
-- Execution: Review architecture first, then simplification opportunities, then integrate confirmed security findings.
-- Quality: Judge the change set as an outsider, keep only actionable findings, and avoid inventing concerns the security pass did not confirm.
-- Output: Return review scope, architecture findings, simplification findings, security cross-check results, and residual uncertainty.
+- Read the **full** active change set (staged **and** unstaged when both exist—label which finding hits which).
+- **MUST** discard authorship bias; burden of proof on the code.
+- Prefer **architecture** and **maintainability** over style-only.
+- Abstraction only when it cuts duplication, clarifies ownership, or stabilizes boundaries.
+- Simplification only when behavior-preserving and genuinely simpler—**MUST NOT** shuffle complexity.
+- **MUST** invoke **`discover-security-issues`** on code-affecting scope; **MUST NOT** fabricate security issues not confirmed by that pass.
 
-## Non-negotiable Review Rules
+## Standards (summary)
 
-- Read the full active change set before judging any design choice.
-- Discard authorship bias completely, including changes written earlier in the same conversation by this agent.
-- Judge the diff from a reviewer perspective: the burden of proof is on the code, not on the author's intent.
-- Prefer architecture and maintainability findings over style-only feedback.
-- Recommend abstraction only when it reduces duplication, clarifies ownership, or stabilizes boundaries.
-- Recommend simplification only when it preserves behavior while reducing complexity or ambiguity.
+- **Evidence**: Full diff + minimum context reads to understand behavior.
+- **Execution**: Git state → baseline → architecture → simplification → security integration → report.
+- **Quality**: Actionable, outsider perspective; clear merge of confirmed security results.
+- **Output**: Scope, architecture findings, simplification findings, security cross-check summary, residual uncertainty.
 
 ## Workflow
 
-### 1) Inspect the active git state
+**Chain-of-thought:** **`Pause →`** after each block—no verdicts from partial file reads.
 
-- Run `git status -sb`, `git diff --stat`, and `git diff --cached --stat`.
-- If both staged and unstaged changes exist, review both and label which findings apply to each surface.
-- If there is no active diff, report `No active git change set to review` and stop.
+### 1) Inspect git state
 
-### 2) Build a factual baseline
+- `git status -sb`, `git diff --stat`, `git diff --cached --stat`; cover staged vs unstaged explicitly.
+- No diff → `No active git change set to review` and stop.
+   - **Pause →** Am I about to review **only** unstaged while staged also ships?
 
-- Read every changed file end-to-end.
-- Read the minimum dependency chain needed to understand new helpers, moved logic, interfaces, and callers.
-- Reconstruct actual behavior from code, tests, configuration, and executable evidence only.
-- Ignore earlier planning context unless it is explicitly encoded in the repository.
+### 2) Baseline
 
-### 3) Review architecture first
+- Read every changed file E2E; pull in minimal callers/callees/config to interpret moves and interfaces.
+- Behavior from **code, tests, config, execution**—not from chat memory.
+   - **Pause →** Can I quote **one concrete behavior** change this diff introduces—not intent?
 
-Check whether the diff introduces or preserves problems such as:
+### 3) Architecture first
 
-- duplicated workflows that should live behind one module or helper,
-- cross-layer leakage or ownership confusion,
-- helper placement that hides domain boundaries,
-- repeated condition trees or mapping logic that should be centralized,
-- unstable interfaces or parameter shapes that should be normalized.
+Flag only if evidence-backed: duplicated workflows, cross-layer leakage, wrong helper ownership, repeated condition trees, unstable interfaces.
+Each finding **MUST** name abstraction target **and** why current shape is weaker.
+   - **Pause →** Is this “different style” or a real **boundary** problem?
 
-Keep only findings that name the proposed abstraction target and explain why the current structure is weaker.
+### 4) Simplification second
 
-### 4) Review simplification opportunities second
+Redundant branches/wrappers, deep nesting, duplicated validation, oversize functions, dead compat—**only** if it truly reduces complexity.
+   - **Pause →** Would this refactor just **move** lines between files?
 
-Check whether the diff can be simplified through:
+### 5) Security cross-check
 
-- removing redundant branches, wrappers, or state,
-- flattening deeply nested control flow,
-- collapsing duplicated validation or conversion logic,
-- shrinking overly broad functions into clearer units,
-- deleting dead or no-longer-needed compatibility paths.
+- Run **`discover-security-issues`** on the **same** code-affecting scope.
+- Merge **confirmed** findings that affect safety of this structure; omit unconfirmed noise.
+   - **Pause →** Did I cite **their** severity + repro—or paraphrase fear?
 
-Do not recommend refactors that merely move complexity around.
+### 6) Report
 
-### 5) Run the security cross-check
+1. **Scope** — staged/unstaged; extra context paths read.
+2. **Architecture** — title, evidence (`path:line`), candidate, why weaker.
+3. **Simplification** — title, evidence, candidate, benefit.
+4. **Security cross-check** — confirmed items reused from **`discover-security-issues`**, relevance to this diff.
+5. **Residual uncertainty** — hypotheses / follow-up checks.
 
-- Invoke `harden-app-security` on the same code-affecting scope.
-- Integrate confirmed security findings into the final review when they materially affect the safety of the proposed structure.
-- Do not invent security concerns that the dependency did not confirm.
+If nothing actionable: `No actionable abstraction or simplification finding identified` (security section still reflects cross-check outcome).
 
-### 6) Report only actionable review output
+## Sample hints
 
-Deliver:
+- **Staged only**: User ran `git add -p` → findings tagged **staged** vs **unstaged** separately.
+- **Rename-heavy**: Read old→new path mapping before calling “duplication.”
+- **Tiny diff**: One-file guard clause → architecture section may be empty; security pass still runs if code-affecting.
 
-1. Review scope
-   - staged / unstaged coverage
-   - additional files read for context
-2. Architecture findings
-   - title
-   - evidence (`path:line`)
-   - abstraction candidate
-   - why the current design is weaker
-3. Simplification findings
-   - title
-   - evidence (`path:line`)
-   - simplification candidate
-   - expected benefit
-4. Security cross-check
-   - confirmed findings reused from `harden-app-security`
-   - reason they matter to this diff review
-5. Residual uncertainty
-   - hypotheses or follow-up checks that were not confirmed
+## References
 
-If no actionable issue is found, report `No actionable abstraction or simplification finding identified`.
+- **`discover-security-issues`**: confirmed adversarial findings for code-affecting scope.

package/review-change-set/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Review Change Set"
-  short_description: "Review the active git diff for abstraction and simplification opportunities"
-  default_prompt: "Use $review-change-set to read the active git change set end-to-end, discard any bias toward code written earlier in the conversation, review it like an independent reviewer for architecture-level abstraction and simplification opportunities, and run $harden-app-security as an adversarial cross-check for code-affecting changes."
+  short_description: "Independent diff review for architecture, simplification, and confirmed security cross-checks"
+  default_prompt: "Use $review-change-set to read the active git change set end-to-end, discard any bias toward code written earlier in the conversation, review it like an independent reviewer for architecture-level abstraction and simplification opportunities, and run $discover-security-issues as an adversarial cross-check for code-affecting changes."

package/review-spec-related-changes/README.md

@@ -9,7 +9,7 @@ This skill:
 1. Resolves the governing `docs/plans/...` spec scope from user input or recent repository changes.
 2. Checks whether each business goal and acceptance criterion is actually implemented.
 3. Treats unmet business goals as the most severe review findings.
-4. Runs secondary code-practice review through `review-change-set`, `discover-edge-cases`, and `harden-app-security` for code-affecting scopes.
+4. Runs secondary code-practice review through `review-change-set`, `discover-edge-cases`, and `discover-security-issues` for code-affecting scopes.
 5. Reports business-goal gaps separately from edge-case, security, and maintainability findings.
 
 ## When to use

package/review-spec-related-changes/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review-spec-related-changes
 description: >-
-  Read-only spec compliance versus governing docs/plans: score each business-oriented requirement Met/Partial/Not-met using code/tests/commands—checked `tasks.md` boxes are never sufficient proof; ambiguity between two plausible plan roots halts execution; when runtime code exists, sequentially run **`review-change-set`**, **`discover-edge-cases`**, and **`harden-app-security`** on the same scoped diff afterward.
+  Read-only spec compliance versus governing docs/plans: score each business-oriented requirement Met/Partial/Not-met using code/tests/commands—checked `tasks.md` boxes are never sufficient proof; ambiguity between two plausible plan roots halts execution; when runtime code exists, sequentially run **`review-change-set`**, **`discover-edge-cases`**, and **`discover-security-issues`** on the same scoped diff afterward.
   Use for questions like “does this PR satisfy coordination.md + spec.md R2?” or user pins a `{change}` folder.
   Do not mutate repositories, reorder reports to bury missing goals, skip the tertiary review bundle on code-bearing diffs, or rely on intent without file evidence **BAD**, lead with refactor comments while R1 failing **FORBIDDEN**… GOOD pair every Not-met cite with `spec.md` ref + concrete path:test gap…
 ---
@@ -10,7 +10,7 @@ description: >-
 
 ## Dependencies
 
-- Required: `review-change-set`, `discover-edge-cases`, and `harden-app-security` whenever the scope includes **code-affecting** implementation to assess.
+- Required: `review-change-set`, `discover-edge-cases`, and `discover-security-issues` whenever the scope includes **code-affecting** implementation to assess.
 - Conditional: none.
 - Optional: none.
 - Fallback: If any required dependency is unavailable for a **code-affecting** review, **MUST** stop and report the gap. **MUST NOT** emit a “full pass” verdict without those three passes when code is in scope.
@@ -22,7 +22,7 @@ description: >-
 - **MUST** resolve which spec set governs the change **before** concluding; if multiple candidates fit equally and cannot be disambiguated from repo evidence, **MUST** stop and report ambiguity—**MUST NOT** guess.
 - **MUST** classify each business goal / acceptance item as `Met`, `Partially met`, `Not met`, or `Deferred/N/A` **only** using verifiable evidence (code, tests, commands, traces)—checked boxes in `tasks.md` are **not** proof by themselves.
 - **MUST** treat **unmet or partially met required business goals** as **highest severity**. **MUST NOT** let edge-case, security, or style findings **outrank** those gaps in the reported order or implied priority.
-- **MUST** finish the business-goal verdict **before** invoking secondary skills; **MUST** still run `review-change-set`, `discover-edge-cases`, and `harden-app-security` on the **same** implementation scope when code is involved (after step 1 verdict is written).
+- **MUST** finish the business-goal verdict **before** invoking secondary skills; **MUST** still run `review-change-set`, `discover-edge-cases`, and `discover-security-issues` on the **same** implementation scope when code is involved (after step 1 verdict is written).
 - **MUST NOT** rest conclusions on author intent, branch names, or chat memory unless **repository evidence** agrees.
 - Prefer **fewer confirmed findings** over broad speculation; unproven items belong under **Residual uncertainty**, not as faux defects.
 
@@ -61,7 +61,7 @@ description: >-
    - **Pause →** If I sorted findings by “interesting” instead of business impact, which line would unfairly rise above a missing goal?
    - **Pause →** For each `Partially met`, what single **missing proof** (test, wire-up, error path) am I naming explicitly?
 
-4. **Secondary reviews (code-affecting)** — On the same scope: `review-change-set` (architecture/simplification), `discover-edge-cases` (reproducible edge/observability risks), `harden-app-security` (reproducible security). Keep outputs labeled so they do not read as business-goal substitutions.
+4. **Secondary reviews (code-affecting)** — On the same scope: `review-change-set` (architecture/simplification), `discover-edge-cases` (reproducible edge/observability risks), `discover-security-issues` (reproducible security). Keep outputs labeled so they do not read as business-goal substitutions.
    - **Pause →** Does this secondary finding **force** a business re-score—if yes, did I revise step 3 before publishing?
    - **Pause →** Is the diff scope identical to what I used for business mapping (no silent file creep)?
 

package/review-spec-related-changes/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Review Spec Related Changes"
   short_description: "Review spec-backed changes for business-goal completion and secondary code-practice risks"
-  default_prompt: "Use $review-spec-related-changes to resolve the recent or user-specified spec documents, verify each business goal and acceptance criterion against the related implementation evidence, treat unmet business goals as the most severe findings, and then run $review-change-set, $discover-edge-cases, and $harden-app-security on the same code-affecting scope for secondary code-practice review."
+  default_prompt: "Use $review-spec-related-changes to resolve the recent or user-specified spec documents, verify each business goal and acceptance criterion against the related implementation evidence, treat unmet business goals as the most severe findings, and then run $review-change-set, $discover-edge-cases, and $discover-security-issues on the same code-affecting scope for secondary code-practice review."

package/solve-issues-found-during-review/README.md

@@ -8,7 +8,7 @@ Fix issues discovered during a review pass, proceeding from the highest-severity
 $solve-issues-found-during-review
 ```
 
-Provide a review report (from `review-change-set`, `review-spec-related-changes`, `review-codebases`, `discover-edge-cases`, `harden-app-security`, or any structured review) and this skill will:
+Provide a review report (from `review-change-set`, `review-spec-related-changes`, `review-codebases`, `discover-edge-cases`, `discover-security-issues`, or any structured review) and this skill will:
 
 1. Read and prioritize all findings by severity
 2. Fix each finding from Critical down to Low

package/solve-issues-found-during-review/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: solve-issues-found-during-review
 description: >-
-  Operate strictly from a structured review/issue list containing confirmed findings: close items in descending severity order (Critical before High/Medium/Low), land the smallest corrective diff per finding, run targeted validation after each fix before continuing, forbid speculative polish or unsolicited doc edits unless a finding explicitly requires them, and document Deferred or Could-not-reproduce outcomes with reproducible rationale.
-  Use when prompts reference concrete review outputs (“fix Bugbot findings”, “resolve security audit bullets”) accompanied by reproducible excerpts—STOP if only vague “there were issues yesterday” survives.
-  Bad pattern: refactoring modules while unresolved Critical SSRF persists… Good pattern: `HIGH SSRF src/net/client.rs…` patched, `cargo test net::fetch` green, hashes recorded…
+  From a confirmed finding list: fix in severity order (Critical→Low) with minimal patches, validate after each item, forbid speculative polish; document Deferred/CNR with evidence.
+  Done only when code matches governing specs/plans where they apply and security, edge-case, and other inbound review findings are fixed/verified with nothing material open.
+  Use for concrete review excerpts; STOP if vague. Bad: refactor while Critical SSRF open. Good: minimal patch, tests green, evidence cited.
 ---
 
 # Solve Issues Found During Review
@@ -11,9 +11,9 @@ description: >-
 ## Dependencies
 
 - Required: none (caller **MUST** supply an existing review report or reconstructable finding list).
-- Conditional: `review-change-set` for optional re-validation after **code-affecting** fixes; `systematic-debug` when a fix causes unexpected test or runtime failures.
-- Optional: `discover-edge-cases` / `harden-app-security` when the user or report demands post-fix confirmation on those dimensions.
-- Fallback: If `review-change-set` is unavailable after code fixes, **MUST** still verify via targeted tests and `git diff` (or equivalent) and **MUST** document exactly what was run.
+- Conditional: `review-spec-related-changes` when governing `docs/plans/...`, `spec.md`, `tasks.md`, contracts, or checklists bind the changed behavior—**MUST** satisfy **Completion criteria** §1 before declaring done; `review-change-set` for optional re-validation after **code-affecting** fixes; `systematic-debug` when a fix causes unexpected test or runtime failures; **`commit-and-push`** when the user requests **git commit** and/or **push** to persist fixes—**MUST** hand off that leg to **`commit-and-push`** (not bare `git commit` / ungated push).
+- Conditional (completion gate): **`discover-security-issues`** / **`discover-edge-cases`** when the inbound material includes security or edge-case findings, or when completion requires proving those dimensions clean—rerun or equivalent scoped proof **MUST** show no remaining confirmed in-scope issue (see **Completion criteria** §2).
+- Fallback: If `review-change-set` is unavailable after code fixes, **MUST** still verify via targeted tests and `git diff` (or equivalent) and **MUST** document exactly what was run. If the user requested **commit/push** and **`commit-and-push`** is unavailable, **MUST** stop and report.
 
 ## Non-negotiables
 
@@ -24,12 +24,21 @@ description: >-
 - This skill **defaults to product code**; **MUST NOT** edit specs, docs, or `AGENTS.md`/`CLAUDE.md` unless the **finding text** explicitly requires it.
 - If a finding cannot be reproduced after investigation, **MUST** record `Could not reproduce` with evidence and **MUST** continue the queue without silently dropping the item.
 
+## Completion criteria
+
+Declare this workflow **finished** only when **both** clauses below hold. Partial closure of the finding queue is insufficient.
+
+1. **Specification conformance**: Every behavior touched by fixes **MUST** match the authoritative specification documents (`spec.md`, `tasks.md`, `checklist.md`, `contract.md`, governing `docs/plans/{change}` prose, plus any checklist items the caller names). **MUST** run **`review-spec-related-changes`** (or an equivalent checklist walk tied to cited requirement IDs plus tests/commands) whenever such docs exist or the user points at a plan path; cite **Met** (or repaired **Partial**) outcomes with file/test evidence in the closing report. If the caller asserts **no** binding spec for the scope, **MUST** state that assumption explicitly and anchor compliance to the issue/report text plus passing validation—**MUST NOT** silently invent spec obligations.
+2. **Ancillary reviews fully cleared**: Confirmed findings from **security audits**, **edge-case / hardening reviews**, and any other labeled review streams in the inbound package **MUST** reach **`Fixed`** (or documented **`Could not reproduce`** with reproducible rationale) **with** reruns or scoped proofs that show no remaining reproducible exploit or edge-case failure **in scope**. **MUST NOT** declare completion while Critical / High-class security issues or correctness-class edge regressions remain open. **`Deferred`** is incompatible with declaring completion unless the caller explicitly rescopes (“out of this pass”) **in writing** in the conversation; otherwise **MUST** keep working or stop with a blocker report listing what still fails completion §2.
+
+`Could not reproduce` on a formerly cited line **counts** toward §2 cleared **only if** investigation evidence excludes stale reports; if reproducibility disagrees between spec §1 and a security/edge claim, **priority is correctness and safety**: resolve the conflict before completion.
+
 ## Standards (summary)
 
-- **Evidence**: Confirmed finding → code path → minimal patch → validation artifact.
-- **Execution**: Order by severity; optional parallel module groups only when isolation is real; merge without losing fix intent.
+- **Evidence**: Confirmed finding → code path → minimal patch → validation artifact; closure adds spec traceability and ancillary-review clean signal.
+- **Execution**: Order by severity; optional parallel module groups only when isolation is real; merge without losing fix intent; completion gates §1–§2 after the queue settles.
 - **Quality**: No speculative hardening; conflicts resolved conservatively unless the finding demands an aggressive change.
-- **Output**: Per-finding status, validation proof, final re-validation summary, residual/deferred items with reasons.
+- **Output**: Per-finding status, validation proof, **completion-criteria checklist** (spec + ancillary reviews), final re-validation summary, residual/blockers only when completion is explicitly waived by caller rescope.
 
 ## Workflow
 
@@ -54,13 +63,16 @@ Sort into Critical → High → Medium → Low. Optionally group by **module** o
 ### 3) Full-scope re-validation
 
 After all findings are processed: run relevant tests over touched areas; if code changed and `review-change-set` is available, run it on the post-fix diff; capture `git diff --stat` (or equivalent). **MUST** confirm no confirmed finding remains open without a recorded reason (`Deferred`, `Could not reproduce`, etc.).
+**Before** declaring the engagement complete: apply **Completion criteria**—**(§1)** spec/plan conformance evidence (`review-spec-related-changes` or equivalent cited requirement IDs + commands); **(§2)** reruns or scoped proofs so security / edge-case (and sibling) confirmed issues are **`Fixed`** or evidenced `Could not reproduce`, with nothing Critical/High-class left open unless the caller explicitly rescopes.
    - **Pause →** Would the **same** reviewer still see **actionable proof** closed for each `Fixed`, or did I rationalize failures away?
    - **Pause →** Did my consolidated diff sneak in **bonus** unrelated changes—if yes, peel them back?
+   - **Pause →** Would **§1 + §2** pass an external spot-check—is spec coverage documented and ancillary dimensions clean?
 
 ### 4) Report
 
-Deliver: (1) Summary by severity. (2) Per finding: `Fixed` / `Could not reproduce` / `Deferred` + location + validation evidence. (3) Final re-validation (review tool result if any, tests, diff stat). (4) Residual/deferred with reasons. (5) User-facing next checks before merge (manual QA, integration, etc.).
+Deliver: (1) Summary by severity. (2) Per finding: `Fixed` / `Could not reproduce` / `Deferred` + location + validation evidence. (3) **Completion criteria block**: §1 spec conformance (tool or checklist + requirement IDs + commands); §2 security/edge-case (and other ancillary) closure with rerun evidence or explicit caller rescope for any intentional exception. (4) Final re-validation (review tool result if any, tests, diff stat). (5) Residual/deferred with reasons—if present, state whether completion was declared or blocked. (6) User-facing next checks before merge (manual QA, integration, etc.).
    - **Pause →** Could the user rerun **exactly one** cited command per `Fixed` to trust me—is that cited?
+   - **Pause →** Does the report prove **§1 + §2** without hand-waving?
 
 ## Notes
 

package/version-release/README.md

@@ -34,7 +34,7 @@ When the release includes code changes, `review-change-set` is still a condition
 
 Apply the same rule to every other conditional gate: if its scenario is met during release classification, it becomes blocking before version bumping, tagging, or release publication.
 
-That includes risk-driven review gates such as `discover-edge-cases` and `harden-app-security` whenever the release surface makes them applicable.
+That includes risk-driven review gates such as `discover-edge-cases` and `discover-security-issues` whenever the release surface makes them applicable.
 
 Do not report release completion after only bumping versions or pushing a commit: the matching tag and GitHub release are part of done criteria unless the user explicitly says to skip publication.
 

package/version-release/SKILL.md

@@ -10,7 +10,7 @@ description: >-
 ## Dependencies
 
 - Required: **`commit-and-push`** (shared inspect/classify/readiness/commit/push mechanics); **`submission-readiness-check`** **before** version files, tags, or publication mutate.
-- Conditional: **`archive-specs`** when specs/docs need alignment; **`review-change-set`** (+ **`discover-edge-cases`** / **`harden-app-security`** when risk triggers) on **code-affecting** release scope **before** version churn—blocking while findings open.
+- Conditional: **`archive-specs`** when specs/docs need alignment; **`review-change-set`** (+ **`discover-edge-cases`** / **`discover-security-issues`** when risk triggers) on **code-affecting** release scope **before** version churn—blocking while findings open.
 - Optional: none.
 - Fallback: Missing required skill ⇒ stop and report.
 
@@ -26,7 +26,7 @@ description: >-
 - **MUST** verify **remote** has commit + tag before calling release **done**; **MUST NOT** trust UI git shortcuts.
 - **Done** = version files + changelog section + **pushed** commit + **remote** tag + **published** GitHub release (unless user explicitly skips publication—then say so).
 
-**Repository regression checks:** Before creating release metadata, inspect existing local and remote tags plus any existing GitHub Release for the target version so duplicates are caught early. Do not continue until you can state the current version, the intended next version, and the exact tag name that will be created. **`review-change-set` is required for code-affecting releases**—run `review-change-set` for the same release scope before continuing; treat unresolved review findings as blocking. Any conditional gate whose trigger is confirmed by this classification becomes mandatory before version bumping, tagging, or release publication. Treat every scenario-matched gate as blocking before versioning or release publication. **`discover-edge-cases` and `harden-app-security` are important review gates**—when their scenario is met, treat them as blocking review gates, not optional polish. Never stop after the release commit or tag alone; creating the matching GitHub release is part of done criteria unless the user explicitly says to skip release publication.
+**Repository regression checks:** Before creating release metadata, inspect existing local and remote tags plus any existing GitHub Release for the target version so duplicates are caught early. Do not continue until you can state the current version, the intended next version, and the exact tag name that will be created. **`review-change-set` is required for code-affecting releases**—run `review-change-set` for the same release scope before continuing; treat unresolved review findings as blocking. Any conditional gate whose trigger is confirmed by this classification becomes mandatory before version bumping, tagging, or release publication. Treat every scenario-matched gate as blocking before versioning or release publication. **`discover-edge-cases` and `discover-security-issues` are important review gates**—when their scenario is met, treat them as blocking review gates, not optional polish. Never stop after the release commit or tag alone; creating the matching GitHub release is part of done criteria unless the user explicitly says to skip release publication.
 
 ## Standards (summary)
 

package/version-release/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Version Release"
   short_description: "Prepare a versioned release with bump, changelog, tag, GitHub release, and push"
-  default_prompt: "Use $version-release only for explicit release/version/tag requests, including direct semver wording like patch/minor/major update or requests to trigger release-published automation: inspect the current repository state, read the current version plus existing tag/release state, and inspect root CHANGELOG.md Unreleased content. Treat every conditional gate whose scenario is met as blocking before any version bump, tag, or release step: if the release includes code changes, run $review-change-set; if the reviewed risk profile says edge-case or security review is needed, run $discover-edge-cases and $harden-app-security as blocking gates too; if completed specs should be converted or docs need normalization, ensure $archive-specs runs through $submission-readiness-check; if changelog synchronization is needed, complete it before continuing. Then run any additional required code-quality skills, hand the repository to $submission-readiness-check so completed plan archives, project docs, AGENTS.md/CLAUDE.md, and changelog readiness are settled before any version bump or tag, confirm CHANGELOG.md Unreleased is release-ready, update version files, cut the release directly from CHANGELOG.md Unreleased, create the release commit and matching tag, push commits and tags, and publish the matching GitHub release before reporting success."
+  default_prompt: "Use $version-release only for explicit release/version/tag requests, including direct semver wording like patch/minor/major update or requests to trigger release-published automation: inspect the current repository state, read the current version plus existing tag/release state, and inspect root CHANGELOG.md Unreleased content. Treat every conditional gate whose scenario is met as blocking before any version bump, tag, or release step: if the release includes code changes, run $review-change-set; if the reviewed risk profile says edge-case or security review is needed, run $discover-edge-cases and $discover-security-issues as blocking gates too; if completed specs should be converted or docs need normalization, ensure $archive-specs runs through $submission-readiness-check; if changelog synchronization is needed, complete it before continuing. Then run any additional required code-quality skills, hand the repository to $submission-readiness-check so completed plan archives, project docs, AGENTS.md/CLAUDE.md, and changelog readiness are settled before any version bump or tag, confirm CHANGELOG.md Unreleased is release-ready, update version files, cut the release directly from CHANGELOG.md Unreleased, create the release commit and matching tag, push commits and tags, and publish the matching GitHub release before reporting success."