@laitszkin/apollo-toolkit 2.9.0 → 2.11.0

package/AGENTS.md

@@ -24,6 +24,7 @@ This repository enables users to install and run a curated set of reusable agent
 - Users can design and implement new features through a spec-first workflow.
 - Users can generate shared feature spec, task, and checklist planning artifacts for approval-gated workflows.
 - Users can convert text or documents into audio files with subtitle timelines.
+- Users can turn lecture slides, past papers, and answer books into mock exams, worked solutions, study notes, or graded PDFs with KaTeX-rendered math.
 - Users can extend existing features in a brownfield codebase with required tests and approvals.
 - Users can propose product features from an existing codebase and publish accepted proposals.
 - Users can discover reproducible edge-case risks and report prioritized hardening gaps.
@@ -31,7 +32,7 @@ This repository enables users to install and run a curated set of reusable agent
 - Users can run evidence-first application security audits focused on confirmed vulnerabilities.
 - Users can learn new or improved skills from recent Codex conversation history.
 - Users can audit and maintain the skill catalog itself, including dependency classification and shared-skill extraction decisions.
-- Users can summarize mistakes into a learning error book and render it to PDF.
+- Users can summarize mistakes into separate multiple-choice and long-answer error books backed by structured reference files and rendered PDFs.
 - Users can build or review marginfi protocol integrations using official SDK, CLI, protocol, and The Arena documentation.
 - Users can create or maintain `AGENTS.md` so project constraints stay aligned with the repository.
 - Users can turn novel content into a loopable short-form video with generated assets.
@@ -48,6 +49,7 @@ This repository enables users to install and run a curated set of reusable agent
 - Users can build and maintain Solana programs and Rust clients using official Solana development workflows.
 - Users can add focused observability to opaque workflows through targeted logs, metrics, traces, and tests.
 - Users can build against Jupiter's official Solana swap, token, price, lending, trigger, recurring, and portfolio APIs with an evidence-based development guide.
+- Users can render and embed math formulas with KaTeX using official documentation-backed guidance and reusable rendering scripts.
 - 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.
 - Users can prepare and publish versioned releases with changelog and tag workflows.

package/CHANGELOG.md

@@ -4,6 +4,28 @@ All notable changes to this repository are documented in this file.
 
 ## [Unreleased]
 
+## [v2.11.0] - 2026-03-23
+
+### Added
+- Add `exam-pdf-workflow` for turning lecture slides, past papers, and answer books into mock exams, worked solutions, study notes, or graded PDFs with KaTeX-rendered math when needed.
+
+### Changed
+- Update `develop-new-features` and `enhance-existing-features` so approved spec-backed work must continue through all in-scope tasks, applicable checklist items, testing, and backfill before yielding unless scope changes or an external blocker prevents safe completion.
+- Update `generate-spec` to require creating a distinct plan directory when adjacent work is not actually covered by an existing plan set.
+- Update `archive-specs`, `commit-and-push`, and `version-release` to better distinguish completed planning scope from still-active follow-up work before archiving or conversion.
+- Refresh repository skill inventory and project capability docs to include `exam-pdf-workflow` and its `pdf` dependency.
+
+## [v2.10.0] - 2026-03-21
+
+### Added
+- Add `document-vision-reader` for screenshot-based inspection of rendered documents when visible layout matters more than raw extracted text.
+- Add `katex` for rendering and embedding math formulas with official KaTeX guidance and reusable render scripts.
+
+### Changed
+- Rework `learning-error-book` to generate separate multiple-choice and long-answer reference JSON files plus polished PDFs rendered directly from structured data.
+- Update the repository skill inventory and project capability docs to include the new document-vision and KaTeX workflows.
+
+
 ## [v2.9.0] - 2026-03-21
 
 ### Changed

package/README.md

@@ -14,6 +14,8 @@ A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer t
 - develop-new-features
 - discover-edge-cases
 - docs-to-voice
+- exam-pdf-workflow
+- document-vision-reader
 - enhance-existing-features
 - feature-propose
 - financial-research
@@ -22,6 +24,7 @@ A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer t
 - harden-app-security
 - improve-observability
 - jupiter-development
+- katex
 - learn-skill-from-conversations
 - learning-error-book
 - marginfi-development
@@ -127,7 +130,7 @@ The install commands below were checked with the Skills CLI unless otherwise not
 
 | Skill name | Used by | Author / producer | Install command / note |
 | --- | --- | --- | --- |
-| `pdf` | `deep-research-topics`, `financial-research`, `learning-error-book`, `weekly-financial-event-report` | OpenAI (`openai/skills`) | `npx skills add openai/skills@pdf -g -y` |
+| `pdf` | `deep-research-topics`, `exam-pdf-workflow`, `financial-research`, `learning-error-book`, `weekly-financial-event-report` | OpenAI (`openai/skills`) | `npx skills add openai/skills@pdf -g -y` |
 | `doc` | `deep-research-topics` (optional Word output) | OpenAI (`openai/skills`) | `npx skills add openai/skills@doc -g -y` |
 | `slides` | `deep-research-topics` (optional slide output) | OpenAI (`openai/skills`) | `npx skills add openai/skills@slides -g -y` |
 | `spreadsheet` | `record-spending` | OpenAI (`openai/skills`) | `npx skills add openai/skills@spreadsheet -g -y` |

package/archive-specs/SKILL.md

@@ -40,6 +40,7 @@ Convert completed planning artifacts into stable, standardized project documenta
   4. existing docs
 - When specs disagree with the codebase, keep the codebase truth and note the mismatch while updating docs.
 - Merge repeated or overlapping feature descriptions into one stable capability summary.
+- Distinguish between completed scope that should become durable docs and still-active scope that remains planning material for follow-up work.
 
 ### 3) Standardize existing project docs into categorized outputs
 
@@ -91,6 +92,8 @@ Ensure the split project docs cover all of the following:
 - Prefer moving the consumed `spec.md`, `tasks.md`, and `checklist.md` files, or their containing plan directory, into a clearly marked archive path instead of leaving them mixed with active docs.
 - Delete converted spec files only when the repository clearly does not need historical retention.
 - Do not archive or delete any spec file that is still actively needed for unfinished implementation work.
+- Treat a spec file as active when it still records pending gaps, planned later phases, follow-up integration work, or unresolved design decisions for the same change, even if one implementation commit has already shipped.
+- If only part of a plan set is complete, convert or summarize only the truly completed scope and leave the active plan set in place unless the repository has a separate archival convention for partial phases.
 
 ## Working Rules
 
@@ -99,6 +102,7 @@ Ensure the split project docs cover all of the following:
 - Do not copy speculative roadmap items from specs into the main docs as if they already exist.
 - When a section cannot be completed from evidence, keep an explicit `Unknown` or `TBD (missing repository evidence)` marker.
 - The final repository state should not keep both standardized docs and redundant active spec files for the same completed scope.
+- Do not equate "code was committed" with "planning scope is complete"; archive only when the remaining notes no longer guide future implementation.
 
 ## References
 

package/commit-and-push/SKILL.md

@@ -42,6 +42,7 @@ Load only when needed:
    - `repo-specs-present`: the repository contains live project planning artifacts such as `spec.md`, `tasks.md`, `checklist.md`, or plan directories; exclude reference examples, templates, and archived samples.
    - `repo-specs-ready-for-conversion`: the relevant `spec.md`, `tasks.md`, and `checklist.md` have been updated to reflect the actual outcome of the work, and any unchecked task/decision checkbox that is clearly not selected, replaced, deferred, or `N/A` (for example, E2E intentionally not created) does not by itself mean the spec set is unfinished.
    - `project-doc-structure-mismatch`: existing `README.md` and project docs do not match the categorized structure required by `archive-specs`.
+   - Treat a spec set as still active when it documents remaining implementation gaps, follow-up integration work, undecided design work, or deferred tasks that still belong to the same in-flight change.
 3. Run code-affecting dependency skills (when applicable)
    - Run `review-change-set`, `discover-edge-cases`, and `harden-app-security` for the same code-affecting scope when their coverage is needed.
    - Consolidate and resolve all confirmed findings before continuing.
@@ -52,6 +53,7 @@ Load only when needed:
    - Let the skill normalize any existing project docs to the same structure and archive superseded source spec files.
    - Do not treat unchecked task or decision checkboxes alone as blocking unfinished work; read the surrounding notes and requirement status semantically.
    - If the docs still show unresolved implementation scope that is neither completed, intentionally deferred, nor explicitly `N/A`, do not convert them yet; report that the spec files remain active and should not be deleted.
+   - If the current change intentionally ships a partial phase while the same plan set still tracks remaining work, keep that plan set live and skip archival for that scope.
 5. Run pre-commit sync dependencies
    - Execute `align-project-documents` after spec conversion and code/doc scans are complete.
    - Execute `maintain-project-constraints` immediately before the commit.
@@ -70,3 +72,4 @@ Load only when needed:
 - Never run version bump, tag creation, or changelog release steps in this skill.
 - If release/version/tag work is requested, use `version-release` instead.
 - If a new branch is required, follow `references/branch-naming.md`.
+- A pushed implementation can still leave an active spec set behind; commit completion and spec archival are separate decisions.

package/develop-new-features/README.md

@@ -9,6 +9,7 @@ A spec-first feature development skill for new behavior and greenfield work. It
 - Covers unit, regression, property-based, integration, E2E, and adversarial testing based on actual risk.
 - Reuses existing architecture and avoids speculative expansion.
 - Backfills `spec.md`, `tasks.md`, and `checklist.md` after implementation and testing complete.
+- Once approval is granted and implementation starts, finishes all in-scope planned tasks and applicable checklist items before yielding unless the user defers work or an external blocker prevents safe completion.
 
 ## Repository layout
 

package/develop-new-features/SKILL.md

@@ -6,6 +6,9 @@ description: >-
   coding, then implements the approved feature with risk-driven test coverage.
   Use when users ask to design or implement new features, change product
   behavior, request a planning-first process, or ask for a greenfield feature.
+  Once the approved spec set exists and implementation begins, complete all
+  planned tasks and applicable checklist items before yielding unless the user
+  changes scope or an external blocker prevents safe completion.
   Tests must not stop at happy-path validation: for business-logic changes
   require property-based testing unless explicitly `N/A` with reason, design
   adversarial/regression/authorization/idempotency/concurrency coverage where
@@ -25,7 +28,7 @@ description: >-
 ## Standards
 
 - Evidence: Review authoritative docs and the existing codebase before planning or implementation.
-- Execution: Run `generate-spec` for every new feature or product-behavior change, obtain approval, then implement minimally.
+- Execution: Run `generate-spec` for every new feature or product-behavior change, obtain approval, then continue through implementation, testing, and backfill until the approved plan is fully reconciled.
 - Quality: Add risk-based tests with property-based, regression, integration, E2E, adversarial, and rollback coverage when relevant.
 - Output: Keep the approved planning artifacts and the final implementation aligned with actual completion results.
 
@@ -64,6 +67,13 @@ Use a shared spec-generation workflow for all new feature work, then implement t
 - Reuse existing patterns and abstractions when possible.
 - Keep changes focused and avoid speculative scope expansion.
 - Update environment examples only when new inputs are actually required.
+- Once approval is granted and implementation starts, treat every unchecked in-scope item in `tasks.md` and every applicable item in `checklist.md` as required work for this run.
+- Do not stop after a partial implementation, partial test pass, or partial doc backfill when work remains in the approved plan.
+- Only pause before completion if:
+  - the user changes scope or explicitly asks to stop
+  - a new clarification invalidates the approved plan and requires renewed approval
+  - an external blocker (missing credentials, unavailable dependency, access restriction, broken upstream system) prevents safe completion
+- When blocked, record the exact unfinished items and blocker in the plan artifacts before yielding.
 
 ### 5) Testing coverage (required)
 
@@ -88,6 +98,7 @@ Rules:
 
 - Backfill `spec.md`, `tasks.md`, and `checklist.md` through `$generate-spec` workflow after implementation and testing.
 - In `spec.md`, mark each approved requirement with its actual completion state, such as completed, partially completed, deferred, or not implemented, plus brief evidence or rationale where needed.
+- Mark every completed task in `tasks.md`, resolve every applicable checklist item, and explicitly label any remaining item as deferred or blocked with the reason.
 - Report the implemented scope, test execution, and any concrete `N/A` reasons.
 
 ## Working Rules
@@ -96,6 +107,7 @@ Rules:
 - Keep implementation traceable to approved requirement IDs and planned risks.
 - Prefer realism over rigid templates: add or remove test coverage only when the risk profile justifies it.
 - Every planned test should justify a distinct risk; remove shallow duplicates that only prove the code "still runs".
+- If a spec set exists and approval has been granted, do not yield with unfinished in-scope tasks or checklist items unless the user approves a deferment or an external blocker makes completion impossible.
 
 ## References
 

package/develop-new-features/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Develop New Features"
   short_description: "Spec-first feature development that depends on generate-spec"
-  default_prompt: "Use $develop-new-features to design new behavior through a spec-first workflow: review the required external docs, run $generate-spec to create and maintain docs/plans/<date>_<change_name>/{spec.md,tasks.md,checklist.md}, wait for explicit approval, then implement the approved feature with risk-driven tests and backfill spec.md, tasks.md, and checklist.md after execution, including requirement completion status in spec.md."
+  default_prompt: "Use $develop-new-features to design new behavior through a spec-first workflow: review the required external docs, run $generate-spec to create and maintain docs/plans/<date>_<change_name>/{spec.md,tasks.md,checklist.md}, wait for explicit approval, then complete the approved implementation end-to-end with risk-driven tests and full backfill of spec.md, tasks.md, and checklist.md before yielding, unless the user changes scope or an external blocker prevents safe completion."

package/document-vision-reader/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/document-vision-reader/README.md

@@ -0,0 +1,66 @@
+# Document Vision Reader
+
+A visual-reading skill for non-plain-text files that should be checked from their rendered appearance instead of raw text extraction.
+
+## What this skill does
+
+- Creates a temporary screenshot workspace for the target file.
+- Converts or captures the requested pages/regions into temporary images.
+- Reads those images as the evidence source.
+- Answers user requests such as summaries, transcription, field lookup, table extraction, comparison, and translation from the visible content.
+- Cleans up temporary screenshots by default after the answer is prepared.
+
+## Best-fit use cases
+
+- scanned PDFs
+- rendered PDF files
+- rendered PPT/PPTX slides
+- receipts, invoices, and forms
+- slide decks with annotations or visual emphasis
+- documents where highlights, layout, handwriting, or stamps matter
+- spreadsheets where merged cells or formatting affect meaning
+- files whose text extraction is unreliable
+- not plain-text files whose meaning depends on visual rendering
+
+## Repository layout
+
+```text
+.
+├── SKILL.md
+├── README.md
+├── LICENSE
+├── agents/
+│   └── openai.yaml
+└── references/
+    ├── legibility-checklist.md
+    └── rendering-guide.md
+```
+
+## Usage
+
+```text
+Use $document-vision-reader to inspect this non-plain-text file by turning its rendered pages into temporary screenshots, reading the screenshots as images, and answering from the visible content only.
+```
+
+Example requests:
+
+```text
+Use $document-vision-reader to inspect pages 3-5 of this scanned PDF, extract the totals table, and flag any handwritten notes.
+```
+
+```text
+Use $document-vision-reader to capture the rendered slides of this PPTX as temporary screenshots, read them visually, and tell me whether the key metrics on slide 7 match slide 12.
+```
+
+## Output expectations
+
+A good result should include:
+
+1. the direct answer to the user's request
+2. which screenshots/pages were used
+3. any visibility limits or unreadable regions
+4. whether the temporary screenshot directory was removed or preserved
+
+## License
+
+MIT. See `LICENSE`.

package/document-vision-reader/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: document-vision-reader
+description: Convert rendered non-plain-text files into temporary screenshots, inspect those screenshots as images, and answer the user's request from the visible visual output. Use when an agent needs to inspect PDFs, PPT/PPTX decks, scanned documents, forms, spreadsheets, or other files whose rendered appearance matters more than raw text extraction.
+---
+
+# Document Vision Reader
+
+## Dependencies
+
+- Required: none.
+- Conditional: `screenshot` when the host needs OS-level captures; `pdf`, `doc`, `pptx`, or `spreadsheet` when the source file needs format-specific rendering before screenshot capture.
+- Optional: none.
+- Fallback: If the file cannot be rendered or captured safely, ask the user for the relevant screenshots/pages instead of guessing from inaccessible content.
+
+## Standards
+
+- Evidence: Base every conclusion on visible screenshot content only; call out blur, clipping, hidden areas, and unreadable regions explicitly.
+- Execution: Create a temporary screenshot workspace, capture only the pages/regions needed, inspect the images, answer the request, and remove temporary artifacts unless the user asked to keep them.
+- Quality: Prefer legible crops over full-page miniatures, keep screenshot naming deterministic, and verify that every requested page or region was actually reviewed.
+- Output: Return the user-facing answer plus the screenshot coverage used, any visibility limits, and whether temporary files were cleaned up.
+
+## Goal
+
+Use visual reading as the source of truth when the target file is not a plain-text artifact and the rendered appearance matters more than extractable text.
+
+Typical cases:
+
+- scanned PDFs or image-only files
+- PDF reports, statements, and forms
+- PPT/PPTX slides that must be checked as rendered pages
+- forms, receipts, invoices, and reports with layout cues
+- slides or documents where comments, highlights, colors, callouts, or alignment matter
+- spreadsheets where merged cells, visual grouping, or formatting affects interpretation
+- cases where raw text extraction is incomplete, broken, or misleading
+
+Do not use this skill for plain-text files when normal text reading is sufficient.
+
+## Workflow
+
+### 1) Confirm scope and output target
+
+Before capturing anything, determine:
+
+- which file or files must be inspected
+- what the user actually needs (summary, transcription, table extraction, comparison, QA, translation, field lookup, etc.)
+- which pages, slides, sheets, or regions matter most
+- whether the user needs the temporary screenshots returned or only used internally
+
+If the file is long, capture only the requested pages or the smallest range needed to answer correctly.
+
+### 2) Create a temporary screenshot workspace
+
+Create a dedicated temporary directory, for example:
+
+```bash
+TMP_DIR="$(mktemp -d "${TMPDIR:-/tmp}/document-vision-reader.XXXXXX")"
+```
+
+Inside that directory, keep deterministic names such as:
+
+- `page-001.png`
+- `page-002-top.png`
+- `slide-004-notes.png`
+- `sheet-budget-row-01.png`
+
+Do not write temporary screenshots into the user's project unless they explicitly ask for that.
+
+### 3) Render the document into screenshots
+
+Use the most reliable renderer available for the source format.
+
+- PDFs or scans: render requested pages to images first, then inspect those images.
+- DOCX/PPTX/XLSX and similar office files: open a rendered view and capture screenshots from the visual output rather than trusting raw XML/text extraction.
+- Existing images: copy or convert into a readable PNG/JPEG only when needed.
+- Large pages or dense tables: use multiple crops instead of shrinking the entire page until text becomes unreadable.
+
+Prefer format-specific helper skills when they improve rendering fidelity:
+
+- `pdf` for PDF page handling
+- `doc` for Word-like documents
+- `pptx` for slides
+- `spreadsheet` for sheets/tables
+- `screenshot` for OS-level capture when no direct renderer is available
+
+If rendering tooling is missing, stop and ask for the minimal set of screenshots or pages needed.
+
+### 4) Verify screenshot legibility before reading
+
+Check every capture before extracting facts.
+
+- Zoom or recapture if body text is not comfortably readable.
+- Split one dense page into multiple overlapping crops when needed.
+- Keep labels, units, headers, and nearby notes in frame so interpretation stays grounded.
+- If a section is truncated or hidden, do not infer the missing content.
+
+Use `references/legibility-checklist.md` when a page is crowded or the answer depends on small details.
+
+### 5) Read screenshots as images
+
+Read the screenshots with image-capable tools only after the captures are ready.
+
+- Inspect the actual rendered content, not an assumed underlying text layer.
+- Treat handwriting, highlights, annotations, stamps, signatures, and color coding as first-class evidence when visible.
+- For tables, verify row/column alignment from the image before extracting values.
+- For multi-page answers, track which screenshot supports each claim.
+
+When the answer depends on multiple screenshots, reconcile them explicitly instead of paraphrasing from memory.
+
+### 6) Answer the user's request
+
+In the response:
+
+- answer the requested task directly
+- note which screenshots/pages were used
+- call out any uncertain or unreadable sections
+- distinguish visible facts from interpretation
+
+If the user asked for extraction, structure the output so it can be checked against the screenshots.
+
+### 7) Clean up temporary files
+
+After the answer is prepared:
+
+- delete the temporary screenshot directory by default
+- keep it only when the user explicitly wants the screenshots, a reusable artifact, or a debugging trail
+- if cleanup fails, report the leftover path so it can be removed later
+
+## Decision Rules
+
+- Prefer screenshot reading whenever visual layout changes meaning.
+- Prefer this skill for rendered non-plain-text files such as PDF and PPT/PPTX.
+- Do not use this skill when a plain-text source can be read directly without losing meaning.
+- Prefer the smallest sufficient capture set; avoid screenshotting an entire long document when the user only asked about one section.
+- Prefer multiple readable crops over one unreadable full-page image.
+- Never invent text hidden outside the visible capture.
+- If screenshots and extracted text disagree, trust the visible screenshot and mention the mismatch.
+
+## Output Checklist
+
+Before finishing, confirm all of the following:
+
+- the requested pages/regions were actually captured
+- the screenshots were legible enough for the requested task
+- the final answer is grounded in visible content
+- uncertainty or occlusion is disclosed
+- temporary artifacts were deleted or intentionally preserved
+
+## Resources
+
+- `references/rendering-guide.md`: format-by-format screenshot staging guidance.
+- `references/legibility-checklist.md`: quick quality gate for readable visual extraction.

package/document-vision-reader/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Document Vision Reader"
+  short_description: "Read rendered PDF/PPT-like files through temporary screenshots"
+  default_prompt: "Use $document-vision-reader when I need to inspect a non-plain-text rendered file such as PDF or PPT/PPTX, create temporary screenshots for the relevant pages or regions, inspect those screenshots as images instead of trusting raw text extraction, answer from visible content only, and clean up the temporary screenshot workspace unless I ask to keep it."

package/document-vision-reader/references/legibility-checklist.md

@@ -0,0 +1,13 @@
+# Legibility Checklist
+
+Before answering from screenshots, confirm:
+
+- text is readable without guessing
+- important numbers and decimal places are visible
+- row and column boundaries are clear for tables
+- annotations, highlights, stamps, and signatures are not clipped
+- the capture includes enough surrounding context to interpret the target content
+- overlapping crops cover any area split across captures
+- page or slide identity is trackable from the filename or nearby context
+
+If any item fails, recapture before answering.

package/document-vision-reader/references/rendering-guide.md

@@ -0,0 +1,37 @@
+# Rendering Guide
+
+Use the smallest reliable rendering path that preserves what the user needs to inspect.
+
+## PDF or scanned document
+
+- Capture only the requested pages first.
+- If a full page becomes unreadable when scaled down, split it into overlapping crops.
+- Preserve headers, footers, totals, and marginal notes when they affect interpretation.
+
+## DOCX or rich-text document
+
+- Read from a rendered page view, not raw XML text.
+- Preserve comments, highlights, tracked-style decorations, and side notes when visible.
+- Capture section-by-section when the page is text dense.
+
+## PPTX or slide deck
+
+- Capture slide canvases at a readable scale.
+- Include presenter notes only if the user asks for them or they are needed to answer.
+- When diagrams are dense, take one full-slide capture plus zoomed crops for detailed regions.
+
+## Spreadsheet
+
+- Keep row labels, column headers, and units visible in the same capture.
+- Use overlapping viewport captures for wide tables.
+- If color coding or conditional formatting matters, mention it explicitly in the answer.
+
+## Existing image file
+
+- Reuse the original image when it is already readable.
+- Convert only when the target tool requires a different format.
+
+## General fallback
+
+- If no reliable renderer is available, ask the user for the specific screenshots needed.
+- Do not claim coverage for pages or regions that were never captured.

package/enhance-existing-features/README.md

@@ -9,6 +9,7 @@ A brownfield feature-extension skill: map dependencies first, decide whether sha
 - Requires explicit approval before coding when specs are generated.
 - Still requires meaningful tests even when specs are skipped.
 - Keeps brownfield changes focused and traceable.
+- When specs exist and are approved, finishes all in-scope planned tasks and applicable checklist items before yielding unless the user defers work or an external blocker prevents safe completion.
 
 ## Repository layout
 

package/enhance-existing-features/SKILL.md

@@ -5,7 +5,10 @@ description: >-
   the codebase first, then decide from the user's requested change whether
   specs (`spec.md`/`tasks.md`/`checklist.md`) are required before coding. When
   specs are required, depend on `generate-spec` for the shared planning,
-  clarification, approval, and backfill workflow. Even when specs are not
+  clarification, approval, and backfill workflow. If a spec set exists and is
+  approved, complete all planned tasks and applicable checklist items before
+  yielding unless the user changes scope or an external blocker prevents safe
+  completion. Even when specs are not
   required, still add and run related tests for
   unit/property-based/user-critical integration chain/E2E coverage. Tests must
   not stop at happy-path validation: for business-logic changes require
@@ -27,7 +30,7 @@ description: >-
 ## Standards
 
 - Evidence: Explore the existing codebase first and verify the latest authoritative docs for the involved stack or integrations.
-- Execution: Decide whether specs are required from the actual change surface, run `generate-spec` when needed, then implement minimally.
+- Execution: Decide whether specs are required from the actual change surface, run `generate-spec` when needed, then continue through implementation, testing, and backfill until the active scope is fully reconciled.
 - Quality: Add risk-based tests with property-based, regression, integration, E2E, adversarial, and rollback coverage when relevant.
 - Output: Keep implementation and any planning artifacts traceable, updated, and aligned with actual completion results.
 
@@ -62,6 +65,7 @@ If triggered:
 - After implementation and testing, update the same plan set so `spec.md` reflects requirement completion status in addition to task and checklist progress.
 - If users answer clarification questions, update the planning docs and obtain explicit approval again before implementation.
 - Do not modify implementation code before approval.
+- Once approval is granted, do not stop with unchecked in-scope items remaining in `tasks.md` or applicable unchecked items in `checklist.md` unless the user explicitly defers them or an external blocker prevents safe completion.
 
 If not triggered:
 - Continue directly with the same downstream workflow below.
@@ -79,6 +83,13 @@ If not triggered:
 - Keep changes focused and minimal; preserve current behavior unless required.
 - Follow project conventions (naming, linting, formatting, configuration).
 - Update environment examples only when new inputs are required.
+- If specs exist, treat every unchecked in-scope task and applicable checklist item as part of the required deliverable for this run.
+- Do not stop after partial code changes, partial tests, or partial backfill when approved planned work remains.
+- Only pause before completion if:
+  - the user changes scope or explicitly asks to stop
+  - new clarification requires plan updates and renewed approval
+  - an external blocker (missing credentials, unavailable dependency, access restriction, broken upstream system) prevents safe completion
+- When blocked, record the exact unfinished items and blocker in the spec set before yielding.
 
 ### 5) Testing coverage (required with or without specs)
 
@@ -103,6 +114,7 @@ Rules:
 
 - If specs were used, backfill `spec.md`, `tasks.md`, and `checklist.md` through `$generate-spec` workflow based on actual completion and test outcomes.
 - In `spec.md`, mark each relevant requirement with its actual completion state, such as completed, partially completed, deferred, or not implemented, plus brief evidence or rationale where needed.
+- If specs were used, mark every completed task in `tasks.md`, resolve every applicable checklist item, and explicitly label any remaining item as deferred or blocked with the reason.
 - If specs were not used, provide a concise execution summary including test IDs/results, regression coverage, mock scenario coverage, adversarial coverage, and any `N/A` reasons.
 
 ## Working Rules
@@ -112,6 +124,7 @@ Rules:
 - Maintain traceability between requirements, tasks, and tests when specs are present.
 - Treat checklists as living artifacts: adjust items to match real change scope.
 - Every planned test should justify a distinct risk; remove shallow duplicates that only prove the code "still runs".
+- If a spec set exists and approval has been granted, do not yield with unfinished in-scope tasks or checklist items unless the user approves a deferment or an external blocker makes completion impossible.
 
 ## References
 

package/enhance-existing-features/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "enhance-existing-features"
   short_description: "Extend brownfield features with conditional generate-spec planning and risk-driven tests"
-  default_prompt: "Use $enhance-existing-features to extend a brownfield feature: map the affected code and dependencies first, decide whether the change is high complexity / critical module / cross-module, run $generate-spec when specs are required, wait for explicit approval before coding, and always add risk-driven tests plus clear N/A reasons when a category truly does not apply, then backfill spec.md, tasks.md, and checklist.md when a spec set exists, including requirement completion status in spec.md."
+  default_prompt: "Use $enhance-existing-features to extend a brownfield feature: map the affected code and dependencies first, decide whether the change is high complexity / critical module / cross-module, run $generate-spec when specs are required, wait for explicit approval before coding, and always add risk-driven tests plus clear N/A reasons when a category truly does not apply; if a spec set exists, finish the approved tasks and applicable checklist items and backfill spec.md, tasks.md, and checklist.md before yielding unless the user changes scope or an external blocker prevents safe completion."

package/exam-pdf-workflow/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/exam-pdf-workflow/README.md

@@ -0,0 +1,38 @@
+# Exam PDF Workflow Skill
+
+## Brief Introduction
+
+An agent skill for study-material workflows that read source PDFs, generate mock exams and worked solutions, render math with KaTeX, and grade completed answer-book PDFs into scored graded PDFs.
+
+## Problems this skill solves
+
+Use this skill when:
+
+- lecture slides, past papers, or error books need to be turned into study notes or a new mock exam
+- an exam PDF needs a matching solution book by default
+- math-heavy PDFs need clean KaTeX-rendered formulas instead of raw TeX/plain text
+- handwritten or scanned answer books need visual grading and a graded PDF output
+- an existing exam PDF package needs layout cleanup before delivery
+
+## Invocation rule
+
+Invoke this skill when the request involves exam-style PDFs, question books, answer books, lecture-slide study packs, grading, or math-heavy educational PDF generation.
+
+## Core method
+
+1. Verify the real source and output paths.
+2. Read the source PDFs and choose the task mode.
+3. Produce the full deliverable set for that mode.
+4. Render formulas with KaTeX when math appears.
+5. Visually inspect the final PDFs before finishing.
+
+## Typical deliverables
+
+- Mock exam PDF
+- Worked solution PDF
+- Graded answer-book PDF
+- Study-note summary extracted from lecture/exam PDFs
+
+## License
+
+This project is licensed under the [MIT License](LICENSE).