@laitszkin/apollo-toolkit 2.0.0 → 2.1.0

package/AGENTS.md

@@ -40,6 +40,7 @@ This repository enables users to install and run a curated set of reusable agent
 - Users can review the current git change set from an unbiased reviewer perspective to find abstraction opportunities and simplification candidates.
 - Users can process GitHub pull request review comments and resolve addressed threads.
 - Users can perform repository-wide code reviews and publish confirmed findings as GitHub issues.
+- Users can schedule a bounded project runtime window, stop it automatically, and analyze module health from captured logs.
 - Users can add focused observability to opaque workflows through targeted logs, metrics, traces, and tests.
 - Users can debug software systematically by reproducing causes, validating fixes, and testing outcomes.
 - Users can generate 30-60 second short videos directly from text prompts.

package/CHANGELOG.md

@@ -4,6 +4,25 @@ All notable changes to this repository are documented in this file.
 
 ## [Unreleased]
 
+## [v2.1.0] - 2026-03-18
+
+### Added
+- Add `scheduled-runtime-health-check` for bounded project runtime scheduling, automatic shutdown, and delegated log-based module health analysis.
+
+### Changed
+- Align `commit-and-push` and `version-release` workflow guidance, prompts, and supporting docs with the current review and documentation-sync requirements.
+- Tighten release and commit planning-artifact detection to exclude template/reference specs, and require `scheduled-runtime-health-check` to fail closed when future scheduling is unavailable.
+
+## [v2.0.2] - 2026-03-17
+
+### Changed
+- Update the npm Trusted Publishing workflow to use newer GitHub Actions and Node 24, and simplify publish invocation to `npm publish --access public`.
+
+## [v2.0.1] - 2026-03-17
+
+### Fixed
+- Align `specs-to-project-docs`, `commit-and-push`, and `version-release` references with the current `docs/*` documentation layout.
+
 ## [v2.0.0] - 2026-03-17
 
 ### Added

package/README.md

@@ -31,6 +31,7 @@ A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer t
 - resolve-review-comments
 - review-change-set
 - review-codebases
+- scheduled-runtime-health-check
 - specs-to-project-docs
 - systematic-debug
 - text-to-short-video

package/commit-and-push/README.md

@@ -7,9 +7,9 @@ A Codex skill for commit-and-push workflows without release/version operations.
 `commit-and-push` helps agents safely submit local changes by:
 
 1. Inspecting git status and staged state.
-2. Running `specs-to-project-docs` when the current change set contains new completed spec files.
+2. Running `specs-to-project-docs` when the repository contains spec files or existing project docs need normalization.
 3. Running `align-project-documents` and `maintain-project-constraints` before commit.
-4. Running additional dependency skills for code-affecting diffs.
+4. Running additional dependency skills for code-affecting diffs through isolated parallel review subagents when available.
 5. Committing with a concise Conventional Commit message.
 6. Pushing to the current branch.
 
@@ -21,6 +21,6 @@ Use this skill when the user asks to commit/push/submit changes and does **not**
 - tagging
 - release changelog workflows
 
-If the current diff includes new completed specs, convert them into categorized project docs first and let `specs-to-project-docs` remove or archive the superseded spec files.
+If the repository contains spec files, or if existing project docs still use a non-standard layout, normalize them into the categorized `specs-to-project-docs` structure first and let that skill remove or archive superseded spec files when appropriate.
 
 For release workflows, use `version-release`.

package/commit-and-push/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: commit-and-push
-description: "Guide the agent to submit local changes with commit and push only (no versioning). Use when users ask to commit, submit, or push changes without requesting tag/version/release operations. If the current change set includes new completed spec files, run `specs-to-project-docs` before the final commit so project docs are standardized into categorized files and the old specs are removed or archived."
+description: "Guide the agent to submit local changes with commit and push only (no versioning). Use when users ask to commit, submit, or push changes without requesting tag/version/release operations. If the repository contains active planning artifacts or existing project docs do not match the `specs-to-project-docs` structure, run `specs-to-project-docs` before the final commit so project docs are standardized into categorized files and the old specs are removed or archived when appropriate."
 ---
 
 # Commit and Push
@@ -8,15 +8,15 @@ description: "Guide the agent to submit local changes with commit and push only
 ## Dependencies
 
 - Required: `align-project-documents` and `maintain-project-constraints` before the final commit.
-- Conditional: `review-change-set`, `discover-edge-cases`, and `harden-app-security` for code-affecting changes; `specs-to-project-docs` when the current change set includes new completed spec files.
+- Conditional: `review-change-set`, `discover-edge-cases`, and `harden-app-security` for code-affecting changes; `specs-to-project-docs` when the repository contains active planning artifacts or existing project docs need normalization into the standard categorized structure.
 - Optional: none.
 - Fallback: If any required dependency is unavailable, or if `specs-to-project-docs` is required for spec conversion but unavailable, stop and report the missing dependency.
 
 ## Standards
 
 - Evidence: Inspect git state and classify the change set before deciding which quality gates apply.
-- Execution: Run the dependency skills in order, standardize project docs into categorized outputs when new specs are present, preserve staging intent, then commit and push without release steps.
-- Quality: Re-run relevant validation for runtime changes and keep project docs plus agent constraints synchronized before committing.
+- Execution: Run code-review dependency skills as independent parallel subagents when applicable, keep their contexts isolated to reduce review bias, standardize project docs into categorized outputs whenever specs or doc-structure mismatches are present, preserve staging intent, then commit and push without release steps.
+- Quality: Re-run relevant validation for runtime changes and keep project docs plus agent constraints synchronized before committing; treat `specs-to-project-docs` outputs as the canonical project-doc structure when normalization is required.
 - Output: Produce a concise Conventional Commit and push it to the current branch only.
 
 ## Overview
@@ -35,18 +35,19 @@ Load only when needed:
 1. Inspect current state
    - Run `git status -sb`, `git diff --stat`, and `git diff --cached --stat`.
    - Check staged files with `git diff --cached --name-only`.
+   - Inventory repository planning artifacts and project docs, not only staged files, to detect repo specs and non-standard documentation layouts.
 2. Classify changes
    - `code-affecting`: runtime code, tests, build scripts, CI logic, or behavior-changing config.
    - `docs-only`: content updates only (for example README, docs, comments).
-   - `new-specs-present`: the current change set adds or updates completed planning files such as `spec.md`, `tasks.md`, `checklist.md`, or their containing plan directories.
+   - `repo-specs-present`: the repository contains active project planning artifacts such as `spec.md`, `tasks.md`, `checklist.md`, or plan directories that represent unfinished or recently completed work; exclude reference examples, templates, and archived samples that are not live project plans.
+   - `project-doc-structure-mismatch`: existing `README.md` and project docs do not match the categorized structure required by `specs-to-project-docs`.
 3. Run code-affecting dependency skills (when applicable)
-   - Execute `review-change-set` first to challenge architecture and simplification assumptions.
-   - Execute `discover-edge-cases` next to surface unresolved edge-case risks.
-   - Resolve any confirmed findings.
-   - Ensure `harden-app-security` has been executed for the same code-affecting scope as an adversarial quality gate.
+   - Launch `review-change-set`, `discover-edge-cases`, and `harden-app-security` as parallel review subagents for the same code-affecting scope when delegation is available.
+   - Keep each review subagent in an isolated context window; do not reuse the implementation thread as the reviewer context.
+   - Treat every reviewer as independent and unbiased, then consolidate and resolve all confirmed findings before continuing.
    - Re-run relevant tests when runtime logic changes.
-4. Standardize project docs when new specs are present
-   - Execute `specs-to-project-docs` when `new-specs-present` is true and the related implementation scope is already complete enough for documentation consolidation.
+4. Standardize project docs when specs or doc normalization is needed
+   - Execute `specs-to-project-docs` when `repo-specs-present` or `project-doc-structure-mismatch` is true and the related implementation scope is already complete enough for documentation consolidation.
    - Let `specs-to-project-docs` convert the relevant specs into categorized project docs such as `docs/README.md`, `docs/getting-started.md`, `docs/configuration.md`, `docs/architecture.md`, `docs/features.md`, and `docs/developer-guide.md`.
    - Let the skill normalize any existing project docs to the same structure and remove or archive superseded source spec files.
    - If the specs still represent active unfinished work, do not convert them yet; report that the spec files remain active and should not be deleted.
@@ -54,7 +55,7 @@ Load only when needed:
    - Execute `align-project-documents` after spec conversion and code/doc scans are complete.
    - Execute `maintain-project-constraints` immediately before the commit.
 6. Keep docs synchronized when needed
-   - Apply the output from `specs-to-project-docs` when new specs were converted into categorized project docs.
+   - Apply the output from `specs-to-project-docs` when repository specs were converted or existing project docs were normalized into categorized project docs.
    - Apply the output from `align-project-documents` when behavior or usage changed.
    - Apply the output from `maintain-project-constraints` when agent workflow/rules changed.
 7. Commit

package/commit-and-push/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Commit and Push"
   short_description: "Submit local changes with commit and push only"
-  default_prompt: "Use $commit-and-push to inspect the current git state, classify the diff, run required dependency skills ($align-project-documents and $maintain-project-constraints, plus $review-change-set, $discover-edge-cases, and $harden-app-security as quality gates for code-affecting changes), run $specs-to-project-docs when the current change set includes new completed spec files so project docs are standardized into categorized files and old specs are removed or archived, then create a concise Conventional Commit and push to the current branch without any versioning or release steps."
+  default_prompt: "Use $commit-and-push to inspect the current git state, classify the diff, run required dependency skills ($align-project-documents and $maintain-project-constraints, plus $review-change-set, $discover-edge-cases, and $harden-app-security as isolated parallel review subagents for code-affecting changes when available), run $specs-to-project-docs when the repository contains spec files or existing project docs need normalization so project docs are standardized into categorized files and old specs are removed or archived when appropriate, then create a concise Conventional Commit and push to the current branch without any versioning or release steps."

package/fix-github-issues/SKILL.md

@@ -1,27 +1,27 @@
 ---
 name: fix-github-issues
-description: Resolve issues from remote GitHub repositories via GitHub CLI (`gh`), implement and validate fixes locally, then open a pull request through `open-source-pr-workflow` (or `open-pr-workflow` in environments that use that alias). Use when users ask to list remote issues, pick one or more issues to fix, and submit a PR linked to those issues.
+description: Resolve issues from remote GitHub repositories via GitHub CLI (`gh`), implement and validate fixes locally, then either open a pull request through `open-source-pr-workflow` (or `open-pr-workflow` in environments that use that alias) or hand off to `commit-and-push` when the user explicitly wants a direct push. Use when users ask to list remote issues, pick one or more issues to fix, and deliver the result through a linked PR or an explicit direct-push workflow.
 ---
 
 # Fix GitHub Issues
 
 ## Dependencies
 
-- Required: `systematic-debug` for diagnosis and validated fixes, plus `open-source-pr-workflow` (or `open-pr-workflow`) for PR submission.
-- Conditional: none.
+- Required: `systematic-debug` for diagnosis and validated fixes.
+- Conditional: `open-source-pr-workflow` (or `open-pr-workflow`) when the user wants a PR; `commit-and-push` when the user explicitly wants a direct commit/push flow.
 - Optional: none.
-- Fallback: If a required workflow dependency is unavailable, stop and report the blocked handoff instead of improvising a different flow.
+- Fallback: If the required handoff for the user's requested delivery mode is unavailable, stop and report the blocked dependency instead of improvising another release path.
 
 ## Standards
 
 - Evidence: Verify repository context, fetch remote issue details, and derive expected behavior from issue text before coding.
-- Execution: Select the issue, open an isolated worktree by default, fix it through `systematic-debug`, validate locally, then hand off to the PR workflow.
-- Quality: Keep scope limited to the selected issue, capture exact validation commands, and preserve issue linkage in the final PR.
-- Output: Open the PR against the correct repository and clean up the temporary worktree when the work is complete.
+- Execution: Select the issue, open an isolated worktree by default, fix it through `systematic-debug`, validate locally, then hand off to the delivery workflow that matches the user's request.
+- Quality: Keep scope limited to the selected issue, capture exact validation commands, and preserve issue linkage in the final PR or commit message.
+- Output: Finish with either a linked PR or a direct pushed commit, then clean up the temporary worktree when the work is complete.
 
 ## Overview
 
-Use this skill to run an end-to-end issue-fixing loop with `gh`: discover open issues, select a target, implement and test the fix, and delegate PR creation to `open-source-pr-workflow` (or `open-pr-workflow` alias).
+Use this skill to run an end-to-end issue-fixing loop with `gh`: discover open issues, select a target, implement and test the fix, then hand off either to `open-source-pr-workflow` for PR submission or to `commit-and-push` when the user explicitly wants a direct push.
 
 ## Prerequisites
 
@@ -77,16 +77,21 @@ python3 scripts/list_issues.py --limit 50 --state open
 
 ### 7) Open PR via dependency skill
 
-- After code is ready, invoke `open-source-pr-workflow` (or `open-pr-workflow` if that alias exists in the environment).
-- Provide required PR context:
+- If the user explicitly asks to commit and push directly, invoke `commit-and-push` instead of opening a PR.
+- In direct-push mode:
+  - keep the issue number in the commit message or final summary when appropriate
+  - state the exact target branch the user requested
+  - push only after validation is complete
+- Otherwise invoke `open-source-pr-workflow` (or `open-pr-workflow` if that alias exists in the environment).
+- In PR mode, provide:
   - issue number or link
   - motivation and engineering decisions
   - executed test commands and results
-- Include issue-closing reference (for example, `Closes #<issue-number>`).
+- Include issue-closing reference (for example, `Closes #<issue-number>`) whenever a PR is opened.
 
 ### 8) Clean up the temporary worktree after PR creation
 
-- Once the PR is opened and no more work is needed in that isolated tree, remove the worktree you created for the fix.
+- Once the PR is opened or the direct push is complete and no more work is needed in that isolated tree, remove the worktree you created for the fix.
 - Also clean up the matching local branch reference if it is no longer needed locally.
 
 ## Included Script

package/fix-github-issues/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Fix GitHub Issues"
-  short_description: "Resolve remote GitHub issues and open linked PRs"
-  default_prompt: "Use $fix-github-issues to verify the target GitHub repository with gh, list and inspect remote issues, create an isolated worktree and compliant branch after issue selection, use $systematic-debug to reproduce and fix the issue with tests, validate the result, open a linked PR through $open-source-pr-workflow, then delete the temporary worktree when PR setup is complete."
+  short_description: "Resolve remote GitHub issues, then open a PR or push directly"
+  default_prompt: "Use $fix-github-issues to verify the target GitHub repository with gh, list and inspect remote issues, create an isolated worktree and compliant branch after issue selection, use $systematic-debug to reproduce and fix the issue with tests, validate the result, then either hand off to $open-source-pr-workflow for a linked PR or to $commit-and-push when the user explicitly wants a direct push, and finally delete the temporary worktree."

package/package.json

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

package/scheduled-runtime-health-check/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 LaiTszKin
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/scheduled-runtime-health-check/README.md

@@ -0,0 +1,96 @@
+# Scheduled Runtime Health Check
+
+An agent skill for scheduled, bounded project runs with post-run health analysis.
+
+This skill helps agents start a project at a chosen time, keep it alive for a fixed observation window, stop it automatically, collect the relevant logs, and summarize module health with evidence-backed findings from `analyse-app-logs`.
+
+## What this skill provides
+
+- A workflow for one-off or recurring runtime health checks.
+- Clear separation between scheduling, runtime observation, shutdown, and diagnosis.
+- A bounded log window so startup, steady-state, and shutdown evidence stay correlated.
+- Module-level health classification: `healthy`, `degraded`, `failed`, or `unknown`.
+- Escalation to `improve-observability` when existing telemetry is insufficient.
+
+## Repository structure
+
+- `SKILL.md`: Main skill definition, workflow, and output format.
+- `agents/openai.yaml`: Agent interface metadata and default prompt.
+- Dependency skill: `analyse-app-logs` for evidence-backed post-run diagnosis.
+
+## Installation
+
+1. Clone this repository.
+2. Copy this folder to your Codex skills directory:
+
+```bash
+mkdir -p "$CODEX_HOME/skills"
+cp -R scheduled-runtime-health-check "$CODEX_HOME/skills/scheduled-runtime-health-check"
+```
+
+## Usage
+
+Invoke the skill in your prompt:
+
+```text
+Use $scheduled-runtime-health-check to start this project at 22:00, keep it running for 6 hours, stop it automatically, and analyze whether the API, worker, and scheduler modules stayed healthy.
+```
+
+Best results come from including:
+
+- workspace path
+- start command
+- stop command or acceptable shutdown method
+- schedule and timezone
+- duration
+- readiness signal
+- relevant log files
+- modules or subsystems to assess
+
+If no trustworthy start command is documented, the agent should derive it from the repository or ask only for that missing command.
+If the user requests a future start time and no reliable scheduler is available, the agent should report that limitation instead of starting the run early.
+
+## Example
+
+### Input prompt
+
+```text
+Use $scheduled-runtime-health-check for this repository.
+
+Workspace: /workspace/my-app
+Start command: docker compose up app worker
+Stop command: docker compose down
+Schedule: 2026-03-18 22:00 Asia/Hong_Kong
+Duration: 6 hours
+Readiness signal: GET http://127.0.0.1:3000/health returns 200
+Logs: docker compose logs, logs/app.log, logs/worker.log
+Modules to assess: api, worker, scheduler
+```
+
+### Expected response shape
+
+```text
+1) Run summary
+- Started at 2026-03-18 22:00 HKT and stopped at 2026-03-19 04:00 HKT after a 6-hour bounded run.
+
+2) Module health
+- api: healthy, served readiness checks and no error bursts were observed.
+- worker: degraded, repeated timeout warnings increased after 01:20 HKT.
+- scheduler: unknown, no positive execution signal was emitted during the window.
+
+3) Confirmed issues
+- Reuse evidence-backed findings from $analyse-app-logs.
+
+4) Potential issues and validation needed
+- Scheduler may not be firing jobs; add a per-job execution log or metric to confirm.
+
+5) Observability gaps
+- Missing correlation IDs between api requests and worker jobs.
+
+6) Automation or scheduler status
+- One bounded scheduled run completed and no further cleanup is required.
+```
+
+## License
+
+MIT. See `LICENSE`.

package/scheduled-runtime-health-check/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: scheduled-runtime-health-check
+description: Coordinate a scheduled, bounded project run that starts automatically, stays up for a fixed observation window, stops cleanly, and delegates log-based health analysis to analyse-app-logs. Use when users want timed project startups, post-run health checks across modules, and a report of confirmed issues and potential risks.
+---
+
+# Scheduled Runtime Health Check
+
+## Dependencies
+
+- Required: `analyse-app-logs` for bounded post-run log analysis.
+- Conditional: `improve-observability` when current logs cannot prove module health or root cause.
+- Optional: `open-github-issue` indirectly through `analyse-app-logs` when confirmed issues should be published.
+- Fallback: If no scheduler or automation capability is available for the requested future start time, stop and report that scheduling could not be created; only run immediately when the user explicitly allows an immediate bounded observation instead of a timed start.
+
+## Standards
+
+- Evidence: Anchor every conclusion to the scheduled window, startup/shutdown timestamps, captured logs, and concrete module signals.
+- Execution: Collect the run contract, choose a scheduling mechanism, capture logs, run for a bounded window, stop cleanly, then delegate the review to `analyse-app-logs`.
+- Quality: Keep scheduling and shutdown deterministic, separate confirmed findings from hypotheses, and mark each module healthy/degraded/failed/unknown with reasons.
+- Output: Return the run configuration, module health by area, confirmed issues, potential issues, observability gaps, and automation or scheduler status.
+
+## Overview
+
+Use this skill when the user wants an agent to:
+
+- start a project at a specific time
+- keep it running for a fixed window such as 6 hours
+- stop it automatically at the end of that window
+- collect logs from startup through shutdown
+- assess whether key modules behaved normally
+- identify confirmed problems and potential risks from the observed run
+
+This skill is an orchestration layer. It owns the schedule, bounded runtime, log capture, and module-level health summary. It delegates deep log diagnosis to `analyse-app-logs`.
+
+## Core principles
+
+- Prefer one bounded observation window over open-ended monitoring.
+- Treat startup, steady-state, and shutdown as part of the same investigation.
+- Do not call a module healthy unless there is at least one positive signal for it.
+- Separate scheduler failures, boot failures, runtime failures, and shutdown failures.
+- If logs cannot support a health judgment, mark the module as `unknown` instead of guessing.
+
+## Required workflow
+
+1. Define the run contract
+   - Confirm or derive the workspace, start command, stop method, schedule, duration, readiness signal, log locations, and modules to assess.
+   - Derive commands from trustworthy sources first: `package.json`, `Makefile`, `docker-compose.yml`, `Procfile`, scripts, or project docs.
+   - If no trustworthy start command or stop method can be found, stop and ask only for the missing command rather than guessing.
+2. Choose the scheduling mechanism
+   - Prefer the host's native automation or scheduled-task system when available.
+   - Prefer a single scheduled execution that performs start -> observe -> stop -> analyze so the log window is exact.
+   - If the platform cannot hold a long-running scheduled task, use paired start/stop jobs and record both task identifiers.
+   - If the user requested a future start time and no reliable scheduler is available, fail closed and report the scheduling limitation instead of starting early.
+3. Prepare bounded log capture
+   - Create a dedicated run folder for the window and record absolute start time, intended end time, timezone, cwd, command, and PID or job identifier.
+   - Capture stdout and stderr for the started process, plus any existing app log files that matter for diagnosis.
+   - Keep startup, runtime, and shutdown evidence in the same run record.
+4. Start and verify readiness
+   - Launch the project at the scheduled time.
+   - Wait for a concrete readiness signal such as a health endpoint, listening-port log, worker boot line, or queue-consumer ready message.
+   - If readiness never arrives, stop the run, preserve logs, and analyze the failed startup window.
+5. Observe during the bounded window
+   - Track crashes, restarts, retry storms, timeout bursts, stuck jobs, resource pressure, and repeated warnings.
+   - For each requested module or subsystem, gather at least one positive signal and any degradation signal in the same window.
+   - If the user did not list modules explicitly, infer the major runtime modules from the repository structure and runtime processes.
+6. Stop cleanly at the end of the window
+   - Use the project's normal shutdown path first.
+   - If graceful stop fails, escalate deterministically and record the exact stop sequence and timestamps.
+   - Treat abnormal shutdown behavior as a health signal, not just an operational detail.
+7. Delegate bounded log analysis
+   - Invoke `analyse-app-logs` on only the captured runtime window.
+   - Pass the service or module names, environment, timezone, run folder, relevant log files, and the exact start/end boundaries.
+   - Reuse its confirmed issues, hypotheses, and monitoring improvements instead of rewriting a separate incident workflow.
+8. Produce the runtime health report
+   - Summarize the schedule that was executed, whether readiness succeeded, how long the project stayed healthy, and how shutdown behaved.
+   - Classify each module as `healthy`, `degraded`, `failed`, or `unknown` with concrete evidence.
+   - Separate already observed issues from potential risks that need more telemetry or a longer run to confirm.
+
+## Scheduling rules
+
+- Use the user's locale timezone when configuring scheduled tasks.
+- Name scheduled jobs clearly so the user can recognize start, stop, and analysis ownership.
+- Prefer recurring schedules only when the user explicitly wants repeated health checks; otherwise create a one-off bounded run.
+- If the host provides agent automations, use them before inventing project-local scheduling files.
+- If native automation is unavailable, prefer the smallest reliable OS-level scheduling method already present on the machine.
+- If the request depends on a future start time and no reliable scheduling method exists, do not silently convert the request into an immediate run.
+
+## Health classification rubric
+
+- `healthy`: positive startup signal, expected runtime behavior, and no material degradation in the chosen window.
+- `degraded`: module stays up but shows retries, warnings, latency spikes, partial failures, or other recurring stress signals.
+- `failed`: boot failure, repeated crash, readiness failure, fatal error loop, or inability to perform its core responsibility.
+- `unknown`: logs or probes do not provide enough evidence to justify a health call.
+
+Absence of errors alone is not enough for `healthy`.
+
+## Output format
+
+Use this structure in responses:
+
+1. Run summary
+   - Workspace, schedule, actual start/end timestamps, duration, readiness result, shutdown result, and log locations.
+2. Module health
+   - One entry per module with status (`healthy` / `degraded` / `failed` / `unknown`) and evidence.
+3. Confirmed issues
+   - Reuse evidence-backed findings from `analyse-app-logs`.
+4. Potential issues and validation needed
+   - Risks that appeared in the run but need more evidence.
+5. Observability gaps
+   - Missing logs, metrics, probes, or correlation IDs that blocked diagnosis.
+6. Automation or scheduler status
+   - Created task identifiers, execution status, and whether future cleanup is needed.
+
+## Guardrails
+
+- Do not let the project continue running past the agreed window unless the user explicitly asks.
+- Do not claim steady-state health from startup-only evidence.
+- Keep the run folder and scheduler metadata so the investigation can be reproduced.
+- If current logs are too weak to judge module health, recommend `improve-observability` instead of stretching the evidence.

package/scheduled-runtime-health-check/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Scheduled Runtime Health Check"
+  short_description: "Schedule a bounded project run, then assess module health from captured logs."
+  default_prompt: "Use $scheduled-runtime-health-check to schedule a bounded project run, capture logs from startup through shutdown, classify module health across the requested subsystems, and delegate evidence-based post-run diagnosis to $analyse-app-logs."

package/version-release/README.md

@@ -7,8 +7,8 @@ A Codex skill for explicit release workflows: code/documentation alignment, vers
 `version-release` helps agents perform release work in a repeatable flow:
 
 1. Inspect the release scope from git history.
-2. Run quality gates for code-affecting changes.
-3. Run `specs-to-project-docs` when the release scope contains new completed spec files.
+2. Run quality gates for code-affecting changes through isolated parallel review subagents when available.
+3. Run `specs-to-project-docs` when the repository contains spec files or existing project docs need normalization.
 4. Align project code and categorized project docs.
 5. Resolve version and tag details.
 6. Update version files and changelog.
@@ -23,6 +23,6 @@ Use this skill only when the user explicitly asks for:
 - version bumping
 - tag creation/publishing
 
-If the release includes new completed specs, convert them into categorized project docs first and let `specs-to-project-docs` remove or archive the superseded spec files.
+If the repository contains spec files, or if existing project docs still use a mixed or non-standard layout, normalize them into the categorized `specs-to-project-docs` structure first and let that skill remove or archive superseded spec files when appropriate.
 
 If the user only wants commit + push, use `commit-and-push`.

package/version-release/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: version-release
-description: "Guide the agent to prepare and publish a versioned release (version bump, changelog, tag, and push). Use only when users explicitly request version/tag/release work. If the release scope includes new completed spec files, run `specs-to-project-docs` before finalizing the release so project docs are standardized into categorized files and the old specs are removed or archived."
+description: "Guide the agent to prepare and publish a versioned release (version bump, changelog, tag, and push). Use only when users explicitly request version/tag/release work. If the repository contains active planning artifacts or existing project docs do not match the `specs-to-project-docs` structure, run `specs-to-project-docs` before finalizing the release so project docs are standardized into categorized files and the old specs are removed or archived when appropriate."
 ---
 
 # Version Release
@@ -8,15 +8,15 @@ description: "Guide the agent to prepare and publish a versioned release (versio
 ## Dependencies
 
 - Required: none.
-- Conditional: `review-change-set`, `discover-edge-cases`, and `harden-app-security` for code-affecting releases before metadata edits and the final commit; `specs-to-project-docs` when the release scope includes new completed spec files.
+- Conditional: `review-change-set`, `discover-edge-cases`, and `harden-app-security` for code-affecting releases before metadata edits and the final commit; `specs-to-project-docs` when the repository contains active planning artifacts or existing project docs need normalization into the standard categorized structure.
 - Optional: none.
 - Fallback: If a required release dependency is unavailable for a code-affecting scope, or if `specs-to-project-docs` is required for spec conversion but unavailable, stop and report the missing dependency.
 
 ## Standards
 
 - Evidence: Inspect the active change set and the release range before touching version files, tags, or changelog entries.
-- Execution: Use this workflow only for explicit release intent, run the required quality gates, standardize project docs into categorized files when new specs are present, then update versions, docs, commit, tag, and push.
-- Quality: Never guess versions, align user-facing docs with actual code, and convert completed planning docs into standardized categorized project docs before the release is published.
+- Execution: Use this workflow only for explicit release intent, run the required quality gates through independent parallel review subagents when applicable, standardize project docs into categorized files whenever specs or doc-structure mismatches are present, then update versions, docs, commit, tag, and push.
+- Quality: Never guess versions, align user-facing docs with actual code, convert completed planning docs into standardized categorized project docs before the release is published, and treat the `specs-to-project-docs` structure as the release-ready documentation format.
 - Output: Produce a versioned release commit and tag with synchronized changelog and relevant repository documentation.
 
 ## Overview
@@ -44,22 +44,25 @@ Load only when needed:
 1. Inspect current changes
    - Run `git status -sb`, `git diff --stat`, and `git diff --cached --stat`.
    - Check staged files with `git diff --cached --name-only`.
+   - Inventory repository planning artifacts and project docs, not only staged files, to detect repo specs and non-standard documentation layouts.
 2. Confirm release intent
    - Use this skill only when the user explicitly requests version/tag/release work.
    - If no release intent is present, use `commit-and-push` instead.
 3. Classify changes and run dependencies when required
    - `code-affecting`: runtime code, tests, build scripts, CI logic, or behavior-changing config.
    - `docs-only`: documentation/content updates only.
-   - `new-specs-present`: the current change set or release range adds or updates completed planning files such as `spec.md`, `tasks.md`, `checklist.md`, or their containing plan directories.
-   - For code-affecting changes, run `review-change-set` to challenge architecture and simplification assumptions in the active change set.
-   - For code-affecting changes, run `discover-edge-cases` and resolve any confirmed findings.
-   - For code-affecting changes, ensure `harden-app-security` has been executed for the same scope as an adversarial quality gate.
+   - `repo-specs-present`: the repository contains active project planning artifacts such as `spec.md`, `tasks.md`, `checklist.md`, or plan directories that represent unfinished or recently completed work; exclude reference examples, templates, and archived samples that are not live project plans.
+   - `project-doc-structure-mismatch`: existing `README.md` and project docs do not match the categorized structure required by `specs-to-project-docs`.
+   - For code-affecting changes, launch `review-change-set`, `discover-edge-cases`, and `harden-app-security` as parallel review subagents for the same release scope when delegation is available.
+   - Keep each review subagent in an isolated context window; do not reuse the implementation thread as the reviewer context.
+   - Treat every reviewer as independent and unbiased, then consolidate all confirmed findings before continuing.
+   - Resolve all confirmed findings before changing version files, tags, or release metadata.
 4. Identify release range
    - Find latest version tag with `git describe --tags --abbrev=0` (fallback to `git tag --list`).
    - If no tags exist, use initial commit from `git rev-list --max-parents=0 HEAD`.
    - Review `git log --oneline <range>` and `git diff --stat <range>`.
-5. Standardize project docs when new specs are in scope
-   - Execute `specs-to-project-docs` when `new-specs-present` is true and the related implementation scope is complete enough for documentation consolidation.
+5. Standardize project docs when specs or doc normalization is needed
+   - Execute `specs-to-project-docs` when `repo-specs-present` or `project-doc-structure-mismatch` is true and the related implementation scope is complete enough for documentation consolidation.
    - Let `specs-to-project-docs` convert the relevant specs into categorized project docs such as `docs/README.md`, `docs/getting-started.md`, `docs/configuration.md`, `docs/architecture.md`, `docs/features.md`, and `docs/developer-guide.md`.
    - Let the skill normalize any existing project docs to the same structure and remove or archive superseded source spec files.
    - If the specs still represent active unfinished work, do not convert them yet; report that the spec files remain active and should not be deleted.
@@ -67,6 +70,7 @@ Load only when needed:
    - Compare release range changes with user-facing docs and operational docs to ensure they match actual code behavior.
    - Required alignment targets include project docs such as `README.md`, usage/setup docs, API docs, deployment/runbook docs, and release notes sources when present.
    - After `specs-to-project-docs` runs, treat the categorized outputs as the canonical project-doc structure.
+   - If existing project docs are present but still use a mixed or non-standard layout, normalize them into the same categorized structure before version bumping or tagging.
    - If mismatches are found, update the relevant project docs before version bumping/tagging.
 7. Decide version and tag format
    - Read existing version files (for example `project.toml`, `package.json`, or repo-specific version files).

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, and push"
-  default_prompt: "Use $version-release only for explicit release/version/tag requests: inspect the release scope, and for code-affecting changes run $review-change-set, $discover-edge-cases, and $harden-app-security as quality gates, run $specs-to-project-docs when the release scope includes new completed spec files so project docs are standardized into categorized files and old specs are removed or archived, align user-facing docs with real behavior, update version files and CHANGELOG, create the release commit and tag, and push both commits and tags."
+  default_prompt: "Use $version-release only for explicit release/version/tag requests: inspect the release scope, and for code-affecting changes run $review-change-set, $discover-edge-cases, and $harden-app-security as isolated parallel review subagents when available, run $specs-to-project-docs when the repository contains spec files or existing project docs need normalization so project docs are standardized into categorized files and old specs are removed or archived when appropriate, align user-facing docs with real behavior, update version files and CHANGELOG, create the release commit and tag, and push both commits and tags."

package/weekly-financial-event-report/SKILL.md

@@ -15,8 +15,8 @@ description: Read a user-specified PDF that marks the week's key financial event
 ## Standards
 
 - Evidence: Research only events explicitly marked in the source PDF plus clearly material breaking developments, and verify claims with current authoritative sources.
-- Execution: Read the PDF first, lock the research window, research each marked event, then hand the final briefing to `pdf` for rendering and QA.
-- Quality: Keep the report concise, Chinese-compatible, and explicit about source-versus-breaking events, conflicts, uncertainty, and PDF font safety.
+- Execution: Read the PDF first, lock the research window, research each marked event, then hand the final briefing to `pdf` for rendering and QA with deterministic table-safe layout rules when needed.
+- Quality: Keep the report concise, Chinese-compatible, explicit about source-versus-breaking events, conflicts, uncertainty, PDF font safety, and long-text table legibility.
 - Output: Save only the final standardized PDF under the month folder using the financial-event-report naming scheme.
 
 ## Overview
@@ -135,10 +135,16 @@ Do not guess any input that materially changes the research window or report sco
 - Do not assume `PingFang` is available on every macOS host.
 - If the active `pdf` workflow already has a verified Chinese-safe default on the current machine, reuse that verified default instead of overriding it.
 - Avoid emoji and uncommon glyphs that often break during rendering.
+- When the report includes tables, timelines, or matrix-style summaries with long phrases:
+  - require wrapped paragraph cells rather than single-line text rendering
+  - require width-constrained columns and row heights that expand with content
+  - require padding and font sizes that keep dense Chinese text readable
+  - prefer a deterministic renderer script when the default markdown-to-PDF path cannot guarantee those layout rules
 
 ### 7) Delegate rendering and PDF QA to the `pdf` skill
 
 - Hand the completed report content and font requirements to the `pdf` skill for rendering.
+- If custom table or timeline layout is needed, require the `pdf` skill to keep that renderer as a reusable local script instead of relying on one-off inline code.
 - Require the `pdf` skill to open the rendered PDF locally before finishing.
 - Require the `pdf` skill to capture temporary screenshots from the rendered PDF before considering the report complete.
 - Require the `pdf` skill to inspect at least:
@@ -151,6 +157,8 @@ Do not guess any input that materially changes the research window or report sco
   - headings and body text are visually balanced
   - line wrapping is readable
   - tables remain legible
+  - long table cells do not overlap adjacent text
+  - row heights and timeline blocks expand enough to fit wrapped content
 - Treat those screenshots as temporary QA artifacts only.
 - If the output fails visual QA, revise the content or PDF requirements and call the `pdf` skill again.
 - After the final PDF passes QA, require the `pdf` skill to delete all temporary screenshots before finishing.