@laitszkin/apollo-toolkit 2.0.0

package/package.json

@@ -0,0 +1,36 @@
+{
+  "name": "@laitszkin/apollo-toolkit",
+  "version": "2.0.0",
+  "description": "Apollo Toolkit npm installer for managed skill linking across Codex, OpenClaw, and Trae.",
+  "license": "MIT",
+  "author": "LaiTszKin",
+  "homepage": "https://github.com/LaiTszKin/apollo-toolkit#readme",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/LaiTszKin/apollo-toolkit.git"
+  },
+  "bugs": {
+    "url": "https://github.com/LaiTszKin/apollo-toolkit/issues"
+  },
+  "type": "commonjs",
+  "bin": {
+    "apollo-toolkit": "bin/apollo-toolkit.js"
+  },
+  "scripts": {
+    "test": "node --test"
+  },
+  "engines": {
+    "node": ">=18.18"
+  },
+  "publishConfig": {
+    "access": "public",
+    "registry": "https://registry.npmjs.org"
+  },
+  "keywords": [
+    "apollo-toolkit",
+    "codex",
+    "skills",
+    "openclaw",
+    "trae"
+  ]
+}

package/record-spending/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: record-spending
+description: Maintain monthly multi-account bookkeeping ledgers in Excel. Use when the user asks to record income, expenses, transfers, deposits, withdrawals, balance changes, account additions, account renames, or monthly asset/liability reviews. Always read ACCOUNT.md first, use the spreadsheet skill to keep one worksheet per account plus a monthly summary sheet, and keep ACCOUNT.md and CHART.md synchronized.
+---
+
+# Record Spending
+
+## Dependencies
+
+- Required: `spreadsheet` for every workbook creation, edit, recalculation, formatting change, and chart update.
+- Conditional: none.
+- Optional: none.
+- Fallback: No alternate workbook-editing path is defined; stay within the `spreadsheet` workflow for ledger changes.
+
+## Standards
+
+- Evidence: Treat `ACCOUNT.md` as the source of truth for account identity and `CHART.md` as the source of truth for recurring chart rules.
+- Execution: Resolve ledger scope, handle account maintenance first, then update the monthly workbook and summary sheet through `spreadsheet`.
+- Quality: Preserve existing naming, formulas, and reconciliation behavior, and record new chart rules or account metadata changes immediately.
+- Output: Report the updated workbook path, changed worksheets, account-registry changes, and chart-rule changes.
+
+## Overview
+
+Track user-named accounts through monthly Excel workbooks and keep the account registry plus chart rules consistent over time. Treat `ACCOUNT.md` as the source of truth for account identity and `CHART.md` as the source of truth for recurring chart and quantified-analysis rules.
+
+## References
+
+Load these only when needed:
+
+- `references/account-format.md`
+- `references/workbook-layout.md`
+
+## Workflow
+
+### 1) Resolve the bookkeeping scope
+
+- Work inside the user-specified ledger directory. If none is given, use the current working directory.
+- Determine the target month from the user's date. If no date is given, default to the current local month.
+- Keep one workbook per month, named `YYYY-MM.xlsx` unless the user already has a different convention. Preserve existing naming conventions.
+- Expect these companion files beside the monthly workbooks:
+  - `ACCOUNT.md`
+  - `CHART.md`
+
+### 2) Read `ACCOUNT.md` before doing anything else
+
+- Always open `ACCOUNT.md` first.
+- Match the user's wording against recorded account names, aliases, and notes.
+- If `ACCOUNT.md` is missing, create it with the structure in `references/account-format.md` before editing any workbook.
+- If the request could refer to multiple accounts and the correct one is not provable from context, ask one targeted clarification question instead of guessing.
+
+### 3) Handle account maintenance first
+
+- When the user adds an account, append it to `ACCOUNT.md` before writing ledger rows.
+- When the user renames an account, update the same account entry in `ACCOUNT.md` and rename the related worksheet in every affected monthly workbook.
+- Preserve historical rows and formulas when renaming; update references instead of recreating data.
+- After every task, re-check whether a new account, alias, or status change was introduced and sync `ACCOUNT.md`.
+
+### 4) Maintain one worksheet per account in the monthly workbook
+
+- Create or update the target monthly workbook through the `spreadsheet` skill.
+- Ensure every tracked account has its own worksheet for that month.
+- Record every balance-changing event on the matching worksheet.
+- Use a consistent transaction table with at least these columns:
+  - `Date`
+  - `Description`
+  - `Category`
+  - `Direction`
+  - `Amount`
+  - `Counterparty Account`
+  - `Running Balance`
+  - `Notes`
+- For transfers between two known accounts, write offsetting rows to both worksheets and keep them reconcilable.
+- Keep totals, balances, and summary values in Excel formulas instead of hardcoded derived numbers.
+
+### 5) Maintain a monthly summary worksheet
+
+- Every monthly workbook must include one summary worksheet. Reuse the existing summary-sheet name if present; otherwise use `Monthly Summary`.
+- The summary worksheet must include:
+  - each account's month-end balance
+  - asset allocation by account
+  - total assets
+  - total liabilities
+  - net assets
+  - month-to-date balance change by account
+  - asset/liability ratios and other quantified metrics defined in `CHART.md`
+- Build the summary with worksheet formulas and cross-sheet references so the workbook stays updateable.
+- If the available data cannot support a requested metric, mark it as unavailable instead of inventing numbers.
+
+### 6) Keep chart rules stable and documented
+
+- Before changing chart behavior, read `CHART.md` if it exists. If it does not exist, create it from the template guidance in `references/workbook-layout.md`.
+- Use the same chart rules every month unless the user explicitly asks to change them.
+- Default monthly charts must include:
+  - an account asset-allocation chart
+  - an assets-vs-liabilities chart
+  - a monthly balance-change trend chart
+- When the user asks for more chart types or more quantified analysis, add them to the workbook and record the new rule in `CHART.md` so later months follow the same standard.
+
+### 7) Validate before finishing
+
+- Confirm the correct month workbook was updated.
+- Confirm the correct account worksheet was updated, created, or renamed.
+- Confirm `ACCOUNT.md` reflects all account additions, renames, aliases, and status changes.
+- Confirm `CHART.md` reflects any new chart or quantified-analysis rule.
+- Recalculate workbook formulas and check for Excel errors through the `spreadsheet` workflow.
+- Report the workbook path, changed worksheets, account-registry updates, and chart-rule updates.
+
+## Guardrails
+
+- Prefer the smallest correct edit; do not redesign an existing ledger if it already satisfies the rules.
+- Preserve user-defined account names, workbook names, and worksheet names whenever possible.
+- Do not create duplicate accounts when an existing alias already matches.
+- If a safe answer depends on a missing amount, date, or account target, ask only for that blocking fact.

package/record-spending/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Record Spending"
+  short_description: "Maintain monthly multi-account bookkeeping ledgers in Excel"
+  default_prompt: "Use $record-spending to read ACCOUNT.md first, update the correct month ledger with one worksheet per account plus a monthly summary, keep ACCOUNT.md and CHART.md synchronized, and perform workbook edits through $spreadsheet."

package/record-spending/references/account-format.md

@@ -0,0 +1,33 @@
+# ACCOUNT.md format
+
+Use `ACCOUNT.md` as the canonical account registry.
+
+## Required structure
+
+Start with a short heading and a Markdown table:
+
+```md
+# Accounts
+
+| ID | Name | Class | Currency | Status | Aliases | Notes |
+| --- | --- | --- | --- | --- | --- | --- |
+| cash-wallet | Wallet | asset | HKD | active | cash, pocket money | Daily cash spending |
+| hsbc-card | HSBC Card | liability | HKD | active | card, visa | Main credit card |
+```
+
+## Field rules
+
+- `ID`: stable machine-friendly identifier; keep it unchanged when the display name changes.
+- `Name`: the user-facing account name.
+- `Class`: use at least `asset` or `liability`.
+- `Currency`: keep the currency explicit even if all accounts share one currency.
+- `Status`: use values such as `active`, `closed`, or `archived`.
+- `Aliases`: comma-separated names the user may naturally use in requests.
+- `Notes`: optional disambiguation such as bank, owner, or usage.
+
+## Maintenance rules
+
+- Add new rows when the user creates a new account.
+- Update `Name` and `Aliases` when the user renames an account.
+- Do not create a second row for a rename; keep the same `ID`.
+- If an account is no longer used, change `Status` instead of deleting historical identity.

package/record-spending/references/workbook-layout.md

@@ -0,0 +1,84 @@
+# Monthly workbook and CHART.md rules
+
+Use one workbook per month and keep the layout stable across months.
+
+## Monthly workbook
+
+- Default filename: `YYYY-MM.xlsx`
+- Required worksheets:
+  - one worksheet per account
+  - one summary worksheet, preferably `Monthly Summary`
+
+## Account worksheet layout
+
+Use a single transaction table with these minimum columns:
+
+| Date | Description | Category | Direction | Amount | Counterparty Account | Running Balance | Notes |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+
+Recommended rules:
+
+- `Direction` should make inflow/outflow explicit.
+- `Running Balance` should be formula-driven whenever prior rows exist.
+- For transfers, use the same date, description, and amount on both related account sheets.
+
+## Summary worksheet requirements
+
+The summary worksheet should expose these metrics for the target month:
+
+- month-end balance for every account
+- total assets
+- total liabilities
+- net assets
+- account-level allocation percentages
+- month-to-date balance change by account
+- quantified ratios defined in `CHART.md`
+
+## Default charts
+
+Unless `CHART.md` says otherwise, create and maintain these charts every month:
+
+1. Asset allocation by account
+   - Type: pie or doughnut chart
+   - Basis: month-end balances for `asset` accounts
+2. Assets vs liabilities
+   - Type: clustered column or stacked column chart
+   - Basis: total assets, total liabilities, net assets
+3. Monthly balance trend
+   - Type: line chart
+   - Basis: chronological balance movement for the month
+
+## CHART.md template
+
+Create `CHART.md` when it is missing. Use a structure like this:
+
+```md
+# Chart Rules
+
+## Default charts
+
+1. Asset allocation by account
+   - Type: doughnut
+   - Source: month-end balances of asset accounts
+2. Assets vs liabilities
+   - Type: clustered column
+   - Source: total assets, total liabilities, net assets
+3. Monthly balance trend
+   - Type: line
+   - Source: daily or transaction-order running balances
+
+## Quantified analysis
+
+- Total assets
+- Total liabilities
+- Net assets
+- Debt-to-asset ratio
+- Largest-account concentration
+- Month-to-date change by account
+```
+
+## Extending chart rules
+
+- When the user requests a new chart, add the same rule to `CHART.md`.
+- When the user requests new quantified analysis, record the metric name and source logic in `CHART.md`.
+- Keep future months aligned with the latest `CHART.md` rules unless the user explicitly overrides them.

package/resolve-review-comments/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: resolve-review-comments
+description: Read GitHub pull request review comments, analyze each thread, decide whether to adopt feedback, implement adopted changes, push updates to the same PR branch, and resolve addressed review threads. Use when users ask to process PR review feedback by PR number or current branch context.
+---
+
+# Resolve Review Comments
+
+## Dependencies
+
+- Required: none.
+- Conditional: none.
+- Optional: none.
+- Fallback: not applicable.
+
+## 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.
+- 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.
+
+## Overview
+
+Use this skill to run an end-to-end GitHub PR review loop: collect review threads, decide adopt/reject per comment, apply accepted feedback, push commits to the same PR branch, and resolve only addressed threads.
+
+## Prerequisites
+
+- Ensure `gh` is installed and authenticated (`gh auth status`).
+- Ensure the current directory is a git repository with the target PR branch checked out.
+- Ensure the branch can be pushed to the PR source remote.
+
+## Workflow
+
+1. Identify target PR.
+2. Read unresolved review threads.
+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.
+7. Resolve only threads that were truly addressed.
+8. Reply on unresolved/rejected threads with reason.
+
+## 1) Identify target PR
+
+- If user provides PR number, use it directly.
+- If user does not provide PR number, infer from current branch context.
+
+```bash
+python3 scripts/review_threads.py list --repo <owner>/<repo> --pr <number>
+python3 scripts/review_threads.py list
+```
+
+## 2) Read unresolved review threads
+
+Use table view for quick scan, then JSON when you need full details.
+
+```bash
+python3 scripts/review_threads.py list --pr <number> --state unresolved --output table
+python3 scripts/review_threads.py list --pr <number> --state unresolved --output json > /tmp/pr_threads.json
+```
+
+The JSON output contains `thread_id`, `path`, `line`, and comment bodies for decision and resolution.
+
+## 3) Decide adopt vs reject
+
+Use the decision rubric in `references/adoption-criteria.md`.
+
+- Adopt when correctness, security, reliability, or maintainability clearly improves.
+- Reject when suggestion is incorrect, out of scope, duplicate, or conflicts with requirements.
+- If uncertain, keep thread unresolved and ask for clarification instead of guessing.
+
+Track adopted thread IDs in a JSON file:
+
+```json
+{
+  "adopted_thread_ids": ["THREAD_ID_1", "THREAD_ID_2"]
+}
+```
+
+## 4) Implement adopted feedback
+
+- Edit only necessary files.
+- Keep changes minimal and scoped to adopted comments.
+- Reuse existing patterns; avoid unrelated refactors.
+
+## 5) Validate before push
+
+- Run focused tests/lint/build that cover touched behavior.
+- If checks fail, fix before pushing.
+
+## 6) Commit and push to same PR
+
+- Create a clear commit describing why feedback was adopted.
+- Push to the PR branch (same branch backing the open PR).
+
+## 7) Resolve addressed threads
+
+Resolve only threads you actually addressed in code.
+
+```bash
+python3 scripts/review_threads.py resolve --pr <number> --thread-id-file adopted_threads.json
+```
+
+Optional preview without mutating GitHub state:
+
+```bash
+python3 scripts/review_threads.py resolve --pr <number> --thread-id-file adopted_threads.json --dry-run
+```
+
+## 8) Handle non-adopted comments
+
+- Keep thread unresolved.
+- Reply with a concise technical reason and, if needed, a proposed follow-up.
+- Never resolve rejected or unhandled feedback threads.
+
+## Scripts
+
+### `scripts/review_threads.py`
+
+- `list`: fetch PR review threads via GitHub GraphQL (`gh api graphql`), supports repo/PR inference.
+- `resolve`: resolve selected review threads by thread IDs.
+- Supports thread IDs from flags, JSON files, or `--all-unresolved`.

package/resolve-review-comments/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Resolve Review Comments"
+  short_description: "Adopt PR feedback and resolve comments fast"
+  default_prompt: "Use $resolve-review-comments to process GitHub PR review comments, apply accepted feedback, and resolve addressed threads."

package/resolve-review-comments/references/adoption-criteria.md

@@ -0,0 +1,23 @@
+# Adoption Criteria
+
+Use this checklist before adopting a review comment.
+
+## Adopt
+
+- Fixes a correctness bug or prevents regression.
+- Closes a security, privacy, or data-integrity risk.
+- Improves reliability, error handling, or test coverage.
+- Clarifies intent with low-cost maintainability improvement.
+
+## Usually reject
+
+- Outside the agreed PR scope.
+- Contradicts product requirements or architecture decisions.
+- Duplicates a handled comment or stale context.
+- Requires large refactor not justified by current PR goal.
+
+## Borderline comments
+
+- Prefer smallest safe change.
+- Ask reviewer for clarification when acceptance criteria are unclear.
+- Keep unresolved until change is implemented and verified.