@laitszkin/apollo-toolkit 3.9.0 → 3.9.2

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

@@ -1,7 +1,7 @@
 ---
 name: implement-specs-with-subagents
 description: >-
-  Coordinator-only workflow for multispec batches: ingest `coordination.md`/`preparation.md`, run prerequisite work yourself, derive topological phases, launch ≤4 staggered **`implement-specs-with-worktree`** workers (one `{change}` each), **`merge-changes-from-local-branches`** after every phase succeeds, ledger every branch/test/merge—not for solo specs unless user explicitly insists on delegation overload.
+  Coordinator-only workflow for multispec batches: ingest `coordination.md`/`preparation.md`, run prerequisite work yourself, derive topological phases, launch ≤4 staggered **`implement-specs-with-worktree`** workers (one `{change}` each), **`merge-changes-from-local-branches`** after every phase succeeds, ledger every branch/test/merge—not for solo specs unless user explicitly insists on delegation overload. **Multi-phase: do not declare done until every non-blocked spec is merged across all phases** (or pipeline stopped on explicit blocker).
   Wrong tool for one directory without parallel mandate—pick **`implement-specs-with-worktree`** / **`implement-specs`** depending on isolation. Publication/versioning stays outside this orchestration layer unless another skill attaches.
   Ledger sample: `oauth-scope | phase=1 | merged | npm test ✅`. Burst-launching four agents simultaneously—disallowed pacing required…
 ---
@@ -10,7 +10,7 @@ description: >-
 
 ## Dependencies
 
-- Required: `implement-specs-with-worktree` (every implementation subagent **MUST** follow this skill for its assigned directory); `merge-changes-from-local-branches` (phase integration **MUST NOT** skip this between phases).
+- Required: `implement-specs-with-worktree` (every implementation subagent **MUST** follow this skill for its assigned directory); `merge-changes-from-local-branches` (phase integration **MUST NOT** skip this between phases); **`commit-and-push`** (integration-branch **preparation** commits and **any** post-merge submission the user expects on that branch—**MUST NOT** bypass for bare `git commit` / ungated push when this skill owns the branch).
 - Conditional: `generate-spec` if the batch is not implementation-ready; `review-change-set` only when the user asks for post-merge review.
 - Fallback: If independent subagents cannot run, **MUST** report that limitation. Serial `implement-specs-with-worktree` across specs is allowed **only** after the user explicitly approves that fallback.
 
@@ -19,18 +19,19 @@ description: >-
 - **MUST NOT** delegate until `coordination.md`, when present, explicitly allows parallel implementation—or when absent, until you have verified no contradiction to parallel work.
 - **MUST** enumerate exact in-scope spec directories **before** any subagent starts; **MUST NOT** delegate archived, sibling, or “nearest guess” directories unless the user explicitly includes them.
 - **MUST** verify each delegated directory contains `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, and `design.md` before launch.
-- **MUST** complete, verify, and **commit** documented shared preparation on the integration branch **before** any implementation subagent starts when `preparation.md` exists or specs mandate pre-work; the coordinating agent **MUST NOT** delegate that preparation. Subagents **MUST NOT** start until this branch is clean at the preparation commit (or there is no required preparation).
+- **MUST** complete, verify, and **finalize** documented shared preparation on the integration branch **through `commit-and-push`** before any implementation subagent starts when `preparation.md` exists or specs mandate pre-work; the coordinating agent **MUST NOT** delegate that preparation. Subagents **MUST NOT** start until this branch is clean at the preparation commit (or there is no required preparation).
 - **MUST** build a directed dependency graph from `coordination.md` plus each spec’s `spec.md` / `design.md` (edges: *provider spec must merge before consumer spec*). **MUST** partition specs into phases by topological **layers**: Phase 1 = specs with **no** in-batch prerequisites; for *k* ≥ 2, Phase *k* = specs whose in-batch prerequisites all appear in phases before *k*. **MUST NOT** start phase *k* until phase *k − 1* is fully merged into the integration branch (or you have an explicit user override). If the graph has a cycle, **MUST** stop and report it.
 - **MUST** assign **exactly one** spec directory per implementation subagent; **MUST NOT** assign multiple directories to one implementation subagent.
 - **MUST** cap **active** implementation subagents at **four**; **MUST** start them **one at a time** with confirmation each is running before the next start; **MUST** back off on rate limits (no burst launches). Four is a ceiling, not a quota.
 - **MUST** give each subagent only task-local context (repo root, exact spec path, `coordination.md` path if relevant, instruction to run `implement-specs-with-worktree`, baseline commit when preparation exists, requirement to read the full bundle before edits, worktree isolation, tests, backfill, local commit, and reporting branch/worktree/commit/tests/blockers). **MUST NOT** leak unrelated reasoning or other subagents’ private diffs unless resolving a concrete conflict.
 - After each phase: **MUST** merge every **completed** spec branch from that phase into the integration branch via `merge-changes-from-local-branches` before starting the next phase; **MUST** resolve conflicts using spec contracts as the correctness tie-breaker; **MUST** record merge result in the ledger; if merge is blocked, **MUST** stop the pipeline and report.
+- **Multi-phase completion**: When the planned ledger has **more than one** phase, **MUST** loop steps **5→6→7** until **every** in-scope spec is either **`merged`** on the integration branch or explicitly **`blocked`** with a documented stop (user abort, irresolvable conflict, failed dependency, etc.). **MUST NOT** yield, summarize as “phase complete”, or imply the batch is finished while **any** phase still has a successful, unmerged branch or **`pending`** / **`in_progress`** rows for specs that should run—unless the coordinating agent is halted by a preceding Non-negotiable blocker **and** that halt is stated plainly.
 - Model: If the user names a model, **MUST** use it for implementation subagents when the platform allows; if not supported, **MUST** state that fact and continue only if the default is acceptable to the user’s intent.
 
 ## Standards (summary)
 
 - **Evidence**: Batch read (`coordination.md`, `preparation.md`, every in-scope `spec.md` / `design.md`) before scheduling; ledger stays live.
-- **Execution**: Preparation → dependency graph → phased delegation with merge gates; never skip merges between dependent phases.
+- **Execution**: Preparation → dependency graph → **repeat** (run phase *k* → merge phase *k*) until all phases reconciled on the integration branch; never skip merges between dependent phases; **multi-phase ⇒ no early “done” narrative** until ledger proves full merge-set (or documented blockers).
 - **Quality**: No duplicate delegation; subagents base on the branch that already contains preparation (and prior phases); pause on shared file collisions, batch-wide defects, or rate-limit pressure.
 - **Output**: Concise ledger: per spec → phase, depends-on, subagent id/label, branch/worktree, commit or blocker, tests, merge status.
 
@@ -42,7 +43,7 @@ description: >-
    - **Pause →** Can I quote **verbatim** why each enumerated directory is in scope—not “probably related”?
    - **Pause →** What **exact sentence** from `coordination.md` gates parallel readiness, if any—or what absence did I infer from—and is that justified?
 
-2. **Preparation (blocking when required)** — Coordinating agent executes shared prep only: read tasks/outputs/verification hooks, satisfy scope, run listed checks, **commit** on the integration branch, record prep commit hash in ledger, leave working tree clean. If prep fails, **stop** (no subagents).
+2. **Preparation (blocking when required)** — Coordinating agent executes shared prep only: read tasks/outputs/verification hooks, satisfy scope, run listed checks, **finalize on the integration branch through `commit-and-push`** (push only if the user requested remote update), record prep commit hash in ledger, leave working tree clean. If prep fails, **stop** (no subagents).
    - **Pause →** Am I silently delegating preparation to a **subagent** when the coordinating agent owns it—is that happening?
    - **Pause →** What **commit hash** and **clean-tree** confirmation will subagents inherit as baseline?
 
@@ -62,8 +63,10 @@ description: >-
    - **Pause →** Has **every** successful branch in this phase been merged into the **same** integration branch I will use to **start** phase *k+1*?
    - **Pause →** If a merge conflict touches a **contract** field, which spec’s `contract.md` / `design.md` is the tie-breaker I will apply?
 
-7. **Repeat** — Next phase starts only on the merged integration branch that includes all required predecessors.
+7. **Repeat until batch reconciled** — After step 6, if **any** later phase still has specs not yet run or not yet merged: **MUST** increment *k* and **return to step 5** on the **same** integration branch (now including phase *k* merges). Next phase starts only on that branch. **MUST NOT** end the coordinator run with a “wrapped up” message if the ledger still shows remaining phases or unmerged successful work. **Only** when every in-scope spec is **`merged`** or explicitly **`blocked`** may you treat implementation coordination as **complete** (then optional handoff to submit/review skills per user).
+   - **Pause →** How many phases remain after this merge—is the count **zero**? If not, **immediately** plan step 5 for *k+1*.
    - **Pause →** Before launching phase *k+1*, can I **name** the merge commit or branch state that contains **all** prerequisites for every spec in that phase?
+   - **Pause →** Can I cite **ledger lines** proving **merged** for every non-blocked spec in **every** phase?
 
 ## Out of scope
 

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.0",
+  "version": "3.9.2",
   "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

@@ -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-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).
+- Optional: `discover-edge-cases` / `discover-security-issues` 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. If the user requested **commit/push** and **`commit-and-push`** is unavailable, **MUST** stop and report.
 
 ## Non-negotiables
 

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."