@laitszkin/apollo-toolkit 2.10.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.

package/CHANGELOG.md

@@ -4,6 +4,17 @@ 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

package/README.md

@@ -14,6 +14,7 @@ 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
@@ -129,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/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).

package/exam-pdf-workflow/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: exam-pdf-workflow
+description: Create, typeset, and grade exam-style PDF deliverables for study workflows. Use when the user asks to read lecture or exam PDFs, generate mock exams, produce matching solution books, render math-heavy content with KaTeX, or grade completed answer-book PDFs into a scored graded PDF.
+---
+
+# Exam PDF Workflow
+
+## Dependencies
+
+- Required: `pdf` for reading source PDFs, rendering deliverables, and final PDF QA.
+- Conditional: `document-vision-reader` when handwritten answers, scanned pages, or layout-sensitive grading require visual inspection instead of raw text extraction.
+- Conditional: `katex` when the output contains mathematical notation that should be rendered instead of left as raw TeX/plain text.
+- Optional: none.
+- Fallback: If `pdf` is unavailable, stop and report the blocked dependency instead of improvising a text-only workflow.
+
+## Standards
+
+- Evidence: Read the actual source PDFs and answer-book pages first, and verify any referenced file path against the filesystem before acting.
+- Execution: Decide the task mode first, extract the needed source content, produce the full deliverable set for that mode, then inspect rendered PDFs before finishing.
+- Quality: Treat solution books, math rendering, layout cleanup, and graded-PDF output as default completion criteria when the task implies them; do not leave raw TeX, ambiguous scoring, or unverified PDF layout behind.
+- Output: Save only the requested final PDFs in the target folder and report the exact output paths plus grading or coverage notes.
+
+## Overview
+
+Use this skill for study-material workflows where PDFs are both the input and the final deliverable. The skill covers source reading, mock-exam authoring, solution generation, math typesetting, handwritten-answer grading, and graded-PDF production.
+
+## Workflow
+
+### 1) Confirm the real input/output paths
+
+- Verify every user-mentioned PDF path on disk before reading it.
+- If the named file is missing but a clearly matching nearby file exists, switch to the real file and state the exact path used.
+- Confirm the target output folder before rendering; create it only when the task requires writing deliverables.
+
+### 2) Choose the task mode
+
+Pick one primary mode, and combine modes when the user asks for a package:
+
+- `source-summary`: read lecture slides, past papers, or error books and extract study notes.
+- `mock-exam`: create a new exam paper modeled on source material or user weaknesses.
+- `solution-book`: produce worked solutions for an exam paper.
+- `grading`: mark a completed answer book and write scores back into a graded PDF.
+- `typesetting-refresh`: improve layout, rebuild formulas with KaTeX, or clean up an existing PDF package.
+
+### 3) Read source materials first
+
+- Use `pdf` to extract the source exam, lecture slides, marking scheme, error book, or answer book.
+- When the source is handwritten, scanned, or visually complex, use `document-vision-reader` so judgments come from the rendered page rather than noisy OCR alone.
+- Base the output on the actual source artifacts; do not invent syllabus scope, notation, or marking rules when the source does not support them.
+
+### 4) Produce the complete deliverable set for the chosen mode
+
+#### `mock-exam`
+
+- Build the paper around the user's weak topics or the patterns visible in the source materials.
+- Match the source paper's structure, tone, and sectioning closely enough to feel familiar without copying it verbatim.
+- Unless the user explicitly says otherwise, also produce a matching `solution-book` as part of the same task.
+
+#### `solution-book`
+
+- Give full working, not answer-only stubs.
+- Keep notation and variable names aligned with the paired exam paper.
+- Use concise marking-friendly steps so the solution can also act as the grading reference.
+
+#### `grading`
+
+- Establish or derive the answer key before assigning scores.
+- Judge each question from the rendered student pages, not from OCR fragments alone when handwriting matters.
+- Write per-question scores and the total score into a new graded PDF rather than only reporting marks in chat.
+- If any page is unreadable or ambiguous, say so explicitly and grade conservatively with a short note.
+
+#### `typesetting-refresh`
+
+- Improve spacing, pagination, headings, and section breaks so the PDF reads like a clean exam handout.
+- Rebuild all mathematical expressions through `katex` when formulas appear.
+- Do not leave raw TeX, ASCII approximations, or partially rendered formulas in the final PDF.
+
+### 5) Render math correctly
+
+- When the output includes formulas, invoke `katex` and render the expressions before PDF export.
+- Use display math for multi-step derivations and dense formulas; use inline math only for short expressions.
+- After rendering, visually verify representative pages so symbols, superscripts, fractions, and brackets display correctly.
+
+### 6) Run PDF visual QA before finishing
+
+- Open the rendered PDFs and inspect representative pages.
+- Always check:
+  - the first page
+  - one page with dense mathematics
+  - one page with longer prose or worked solutions
+  - any page with grading annotations when in `grading` mode
+- Confirm that layout is readable, formulas are fully rendered, page breaks are sensible, and annotations are visible.
+- Revise and re-render if math, spacing, or score overlays are unclear.
+
+## Default completion rules
+
+- If the user asks for a mock exam, default to delivering both the exam PDF and its solution PDF.
+- If the user asks to improve exam formatting and the paper contains formulas, default to KaTeX-rendered math.
+- If the user asks for grading, default to a new graded PDF with visible marks plus a chat summary of per-question scores.
+- If the task is read-only, do not modify files; provide notes only.
+
+## Output rules
+
+- Keep filenames explicit and stable, for example `... Mock Test.pdf`, `... Solution.pdf`, or `..._graded.pdf`.
+- Store outputs in the user-requested folder when one is given; otherwise reuse the source document's nearby study-material folder.
+- Report the exact final PDF paths and any unresolved ambiguity, such as unreadable handwriting or missing marking guidance.

package/exam-pdf-workflow/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Exam PDF Workflow"
+  short_description: "Create, typeset, and grade exam PDFs with math rendering."
+  default_prompt: "Use $exam-pdf-workflow to read exam PDFs, generate mock exams and worked solutions, render math with KaTeX, or grade completed answer-book PDFs into a graded PDF."

package/generate-spec/SKILL.md

@@ -30,6 +30,9 @@ Own the shared planning-doc lifecycle for feature work so other skills can reuse
 - Confirm the target workspace root, feature name, and a kebab-case `change_name`.
 - Review only the code, configuration, and external docs needed to understand the requested behavior.
 - Record the references that should appear in `spec.md`.
+- Inspect existing `docs/plans/` directories before deciding whether to edit an existing plan set.
+- Reuse an existing plan set only when it clearly matches the same requested issue/change scope.
+- If the requested work is adjacent to, but not actually covered by, an existing plan set, create a new directory instead of overwriting the neighboring one.
 
 ### 2) Generate the planning files
 
@@ -73,6 +76,7 @@ Own the shared planning-doc lifecycle for feature work so other skills can reuse
 - Review whether `spec.md`, `tasks.md`, and `checklist.md` must be updated.
 - After any clarification-driven update, obtain explicit approval on the updated spec set again.
 - Do not modify implementation code before approval.
+- When clarification reveals the work is a different issue or materially different scope than the current plan set, stop editing that plan set and generate a new one with a distinct `change_name`.
 
 ### 7) Backfill after implementation and testing
 
@@ -87,6 +91,7 @@ Own the shared planning-doc lifecycle for feature work so other skills can reuse
 - Prefer realistic coverage over boilerplate: add or remove checklist items based on actual risk.
 - Use kebab-case for `change_name`; avoid spaces and special characters.
 - Path rule: `scripts/...` and `references/...` in this file always mean paths under the current skill folder, not the target project root.
+- Never overwrite a nearby issue's plan set just because the technical area overlaps; shared modules are not sufficient evidence that the scope is the same.
 
 ## References
 

package/package.json

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