@laitszkin/apollo-toolkit 2.1.0 → 2.2.0

package/CHANGELOG.md

@@ -4,6 +4,24 @@ All notable changes to this repository are documented in this file.
 
 ## [Unreleased]
 
+## [v2.2.0] - 2026-03-18
+
+### Added
+- Add a branded Apollo Toolkit installer welcome screen with staged terminal reveal content before target selection.
+
+### Changed
+- Update the interactive installer banner and selection screen to present clearer Apollo Toolkit branding and setup guidance.
+- Require `version-release` to create and publish a matching GitHub release after pushing the release tag, and document release-triggered publish workflow verification.
+
+## [v2.1.1] - 2026-03-18
+
+### Added
+- Allow `fix-github-issues` to hand off validated issue fixes either to `open-source-pr-workflow` for PR submission or to `commit-and-push` for explicit direct-push delivery.
+
+### Changed
+- Align `fix-github-issues` metadata and agent prompt wording with the new direct-push delivery path.
+- Strengthen `weekly-financial-event-report` PDF handoff requirements for long-text table layout, reusable renderers, and visual QA checks.
+
 ## [v2.1.0] - 2026-03-18
 
 ### Added

package/README.md

@@ -48,7 +48,7 @@ npx @laitszkin/apollo-toolkit
 ```
 
 The interactive installer:
-- shows an `Apollo Toolkit` terminal screen
+- shows a branded `Apollo Toolkit` terminal welcome screen with a short staged reveal
 - installs a managed copy into `~/.apollo-toolkit`
 - lets you multi-select `codex`, `openclaw`, `trae`, or `all`
 - creates symlinks from `~/.apollo-toolkit/<skill>` into each selected target

package/lib/cli.js

@@ -17,10 +17,23 @@ const TARGET_OPTIONS = [
   { id: 'trae', label: 'Trae', description: '~/.trae/skills' },
 ];
 
+const WORDMARK_LINES = [
+  '    _                _ _        _____           _ _    _ _   ',
+  '   / \\\\   _ __   ___ | | | ___  |_   _|__   ___ | | | _(_) |_ ',
+  "  / _ \\\\ | '_ \\\\ / _ \\\\| | |/ _ \\\\   | |/ _ \\\\ / _ \\\\| | |/ / | __|",
+  ' / ___ \\\\| |_) | (_) | | | (_) |  | | (_) | (_) | |   <| | |_ ',
+  '/_/   \\\\_\\\\ .__/ \\\\___/|_|_|\\\\___/   |_|\\\\___/ \\\\___/|_|_|\\\\_\\\\_|\\\\__|',
+  '         |_|                                                      ',
+];
+
 function supportsColor(stream, env = process.env) {
   return Boolean(stream && stream.isTTY && !env.NO_COLOR);
 }
 
+function supportsAnimation(stream, env = process.env) {
+  return Boolean(stream && stream.isTTY && !env.CI && env.APOLLO_TOOLKIT_NO_ANIMATION !== '1');
+}
+
 function color(text, code, enabled) {
   if (!enabled) {
     return text;
@@ -29,23 +42,73 @@ function color(text, code, enabled) {
   return `\u001b[${code}m${text}\u001b[0m`;
 }
 
+function sleep(ms) {
+  return new Promise((resolve) => setTimeout(resolve, ms));
+}
+
+function buildWordmark({ colorEnabled }) {
+  return WORDMARK_LINES.map((line) => color(line, '1;36', colorEnabled)).join('\n');
+}
+
 function buildBanner({ version, colorEnabled }) {
-  const lines = [
-    '+------------------------------------------+',
-    '|              Apollo Toolkit              |',
-    '|      npm installer and skill linker      |',
-    '+------------------------------------------+',
-    `Version ${version}`,
-  ];
-
-  return lines
-    .map((line, index) => {
-      if (index <= 2) {
-        return color(line, '1;36', colorEnabled);
-      }
-      return color(line, '2', colorEnabled);
-    })
-    .join('\n');
+  return [
+    buildWordmark({ colorEnabled }),
+    color('Apollo Toolkit', '1', colorEnabled),
+    color('Install curated skills for Codex, OpenClaw, and Trae', '2', colorEnabled),
+    color(`Version ${version}`, '1;33', colorEnabled),
+  ].join('\n');
+}
+
+function buildWelcomeScreen({ version, colorEnabled, stage = 4 }) {
+  const lines = [buildBanner({ version, colorEnabled })];
+
+  if (stage >= 1) {
+    lines.push(
+      '',
+      'This setup will configure:',
+      `  ${color('*', '1;33', colorEnabled)} A managed Apollo Toolkit home in ${color('~/.apollo-toolkit', '1', colorEnabled)}`,
+      `  ${color('*', '1;33', colorEnabled)} Symlinked skill folders for your selected targets`,
+      `  ${color('*', '1;33', colorEnabled)} A clean install flow with target-aware linking`,
+    );
+  }
+
+  if (stage >= 2) {
+    lines.push(
+      '',
+      'Quick start after setup:',
+      `  ${color('npx @laitszkin/apollo-toolkit codex', '1;33', colorEnabled)}`,
+      `  ${color('apollo-toolkit all', '1;33', colorEnabled)}`,
+    );
+  }
+
+  if (stage >= 3) {
+    lines.push(
+      '',
+      color('Supported targets:', '2', colorEnabled),
+      `  ${color('Codex', '1', colorEnabled)}     ~/.codex/skills`,
+      `  ${color('OpenClaw', '1', colorEnabled)}  ~/.openclaw/workspace*/skills`,
+      `  ${color('Trae', '1', colorEnabled)}      ~/.trae/skills`,
+    );
+  }
+
+  if (stage >= 4) {
+    lines.push('', color('Launching target selector...', '1;36', colorEnabled));
+  }
+
+  return lines.join('\n');
+}
+
+async function animateWelcomeScreen({ output, version, env }) {
+  if (!supportsAnimation(output, env)) {
+    return;
+  }
+
+  const colorEnabled = supportsColor(output, env);
+  for (const stage of [0, 1, 2, 3, 4]) {
+    clearScreen(output);
+    output.write(`${buildWelcomeScreen({ version, colorEnabled, stage })}\n`);
+    await sleep(stage === 0 ? 120 : 160);
+  }
 }
 
 function buildHelpText({ version, colorEnabled }) {
@@ -116,8 +179,8 @@ function renderSelectionScreen({ output, version, cursor, selected, message, env
   clearScreen(output);
   output.write(`${buildBanner({ version, colorEnabled })}\n\n`);
   output.write('Choose where Apollo Toolkit should create symlinked skills.\n');
-  output.write('Use Up/Down (or j/k) to move, Space to toggle, Enter to continue.\n');
-  output.write('Press a to toggle all, q to cancel.\n\n');
+  output.write(`${color('Use Up/Down', '1;33', colorEnabled)} (or ${color('j/k', '1;33', colorEnabled)}) to move, ${color('Space', '1;33', colorEnabled)} to toggle, ${color('Enter', '1;33', colorEnabled)} to continue.\n`);
+  output.write(`Press ${color('a', '1;33', colorEnabled)} to toggle all, ${color('q', '1;33', colorEnabled)} to cancel.\n\n`);
 
   TARGET_OPTIONS.forEach((option, index) => {
     const isFocused = index === cursor;
@@ -141,6 +204,8 @@ async function promptForModes({ stdin, stdout, version, env }) {
     throw new Error('Interactive install requires a TTY. Re-run with targets like `codex`, `openclaw`, `trae`, or `all`.');
   }
 
+  await animateWelcomeScreen({ output: stdout, version, env });
+
   return new Promise((resolve, reject) => {
     let cursor = 0;
     let message = '';
@@ -331,6 +396,7 @@ async function run(argv, context = {}) {
 
 module.exports = {
   buildBanner,
+  buildWelcomeScreen,
   buildHelpText,
   parseArguments,
   promptForModes,

package/package.json

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

package/version-release/README.md

@@ -1,6 +1,6 @@
 # version-release
 
-A Codex skill for explicit release workflows: code/documentation alignment, version bump, changelog update, tagging, and push.
+A Codex skill for explicit release workflows: code/documentation alignment, version bump, changelog update, tagging, GitHub release publication, and push.
 
 ## What this skill does
 
@@ -8,12 +8,13 @@ A Codex skill for explicit release workflows: code/documentation alignment, vers
 
 1. Inspect the release scope from git history.
 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.
+3. Run `specs-to-project-docs` when the repository contains active planning artifacts 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.
 7. Commit release metadata.
 8. Create and push the release tag.
+9. Publish the matching GitHub release and verify any release-triggered automation.
 
 ## Scope
 
@@ -22,7 +23,8 @@ Use this skill only when the user explicitly asks for:
 - release preparation
 - version bumping
 - tag creation/publishing
+- GitHub release publication
 
-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 repository contains active planning artifacts, 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 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."
+description: "Guide the agent to prepare and publish a versioned release (version bump, changelog, tag, GitHub release, 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
@@ -15,9 +15,9 @@ description: "Guide the agent to prepare and publish a versioned release (versio
 ## 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 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.
+- 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, push, and publish the GitHub release.
 - 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.
+- Output: Produce a versioned release commit and tag, publish a matching GitHub release, and keep changelog plus relevant repository documentation synchronized.
 
 ## Overview
 
@@ -27,7 +27,7 @@ Run a standardized release workflow for versioned delivery:
 - align project code and standardized categorized project documentation
 - bump version files
 - update changelog and relevant docs
-- commit, tag, and push
+- commit, tag, push, and publish the GitHub release
 
 ## References
 
@@ -89,7 +89,13 @@ Load only when needed:
    - Create a release-oriented commit message (for example `chore(release): bump version and update changelog`) when applicable.
    - Create the version tag locally after commit.
 11. Push
-   - Push commit(s) and the release tag to the current branch.
+   - Push commit(s) and the release tag to the current branch before publishing the GitHub release when the hosting platform requires the tag to exist remotely.
+12. Publish the GitHub release
+   - Create a non-draft GitHub release that matches the pushed version tag.
+   - Use the release notes from the new `CHANGELOG.md` entry unless the repository has a stronger established release-note source.
+   - If the repository has publish automation triggered by `release.published`, ensure the GitHub release is actually published rather than left as a draft.
+   - Prefer `gh release create <tag>` or the repository's existing release tool when available.
+   - Confirm the GitHub release URL and any triggered publish workflow status in the final report.
 
 ## Notes
 

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 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."
+  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: 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 active planning artifacts 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, push commits and tags, then publish the matching GitHub release and confirm any triggered publish workflow."