@laitszkin/apollo-toolkit 2.4.3 → 2.6.0

package/AGENTS.md

@@ -12,12 +12,11 @@
 This repository enables users to install and run a curated set of reusable agent skills for software delivery, research, repository maintenance, and media-generation workflows.
 
 - Users can align project documentation with the current codebase.
-- Users can consolidate accumulated project specs into a standardized README and categorized project documentation set.
+- Users can consolidate completed project specs into a standardized README and categorized project documentation set, then archive the consumed planning files.
 - Users can investigate application logs and produce evidence-backed root-cause findings.
 - Users can answer repository-backed questions with additional web research when needed.
 - Users can commit and push local changes without performing version or release work.
 - Users can manage Codex user-preference memory by reviewing the last 24 hours of chats, storing categorized memory documents under `~/.codex/memory`, and syncing a memory index into `~/.codex/AGENTS.md`.
-- Users can orchestrate Codex subagents for most non-trivial tasks by reusing or creating focused custom agents under `~/.codex/agents`, then delegating exploration, review, verification, and unrelated module work while keeping tightly coupled execution in the main agent.
 - Users can research a topic deeply and produce evidence-based deliverables.
 - Users can research the latest completed market week and produce a PDF watchlist of tradeable instruments for the coming week.
 - Users can turn a marked weekly finance PDF into a concise evidence-based financial event report.
@@ -33,6 +32,7 @@ This repository enables users to install and run a curated set of reusable agent
 - 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 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.
 - Users can publish structured GitHub issues or feature proposals with auth fallbacks.
@@ -43,7 +43,9 @@ This repository enables users to install and run a curated set of reusable agent
 - Users can process GitHub pull request review comments and resolve addressed threads.
 - Users can perform repository-wide code reviews and publish confirmed findings as GitHub issues.
 - Users can schedule a bounded project runtime window, stop it automatically, and analyze module health from captured logs.
+- Users can 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 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,29 @@ All notable changes to this repository are documented in this file.
 
 ## [Unreleased]
 
+## [v2.6.0] - 2026-03-20
+
+### Added
+- Add `jupiter-development` for building Jupiter-based Solana integrations from current official docs, including swap, token, price, lend, trigger, recurring, and portfolio surfaces.
+- Add `marginfi-development` for building or reviewing marginfi integrations with official SDK, CLI, protocol, and The Arena references.
+- Add `solana-development` for native Solana Rust programs and Rust client workflows grounded in official Solana documentation.
+
+### Changed
+- Update `learn-skill-from-conversations` to prefer inventorying the current skill catalog, weighting user corrections and error-driven lessons more heavily, and tightening when to update an existing skill versus creating a new one.
+- Update `codex-memory-manager` so memory reports include already-stored relevant preferences when users ask what memory exists or why a known preference was omitted.
+- Refresh new protocol reference snapshots against current official Jupiter, marginfi, and Solana docs before release.
+
+## [v2.5.0] - 2026-03-19
+
+### Changed
+- Rename `specs-to-project-docs` to `archive-specs` and refocus the skill on converting completed specs into project docs while archiving the consumed planning files.
+- Update `develop-new-features` and `enhance-existing-features` so completed work must backfill requirement completion status in `spec.md` alongside `tasks.md` and `checklist.md`.
+- Update `commit-and-push` and `version-release` to treat planning-file checkboxes semantically during conversion, and to invoke `archive-specs` when completed spec sets should become project documentation.
+- Update the npm installer to remove stale linked skills that no longer exist in the latest packaged skill list during managed installs.
+
+### Removed
+- Remove the `codex-subagent-orchestration` skill and clean related multi-agent guidance from affected skill documents.
+
 ## [v2.4.3] - 2026-03-19
 
 ### Changed

package/README.md

@@ -6,10 +6,10 @@ A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer t
 
 - align-project-documents
 - analyse-app-logs
+- archive-specs
 - answering-questions-with-research
 - commit-and-push
 - codex-memory-manager
-- codex-subagent-orchestration
 - deep-research-topics
 - develop-new-features
 - discover-edge-cases
@@ -21,8 +21,10 @@ A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer t
 - generate-spec
 - harden-app-security
 - improve-observability
+- jupiter-development
 - learn-skill-from-conversations
 - learning-error-book
+- marginfi-development
 - maintain-project-constraints
 - maintain-skill-catalog
 - novel-to-short-video
@@ -34,7 +36,7 @@ A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer t
 - review-change-set
 - review-codebases
 - scheduled-runtime-health-check
-- specs-to-project-docs
+- solana-development
 - systematic-debug
 - text-to-short-video
 - version-release
@@ -54,6 +56,7 @@ The interactive installer:
 - 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
+- in the same npm/npx install flow, removes stale linked skills that existed in the previous installed version but no longer exist in the current package skill list
 
 ### Global install
 

package/{specs-to-project-docs → archive-specs}/README.md

@@ -1,6 +1,6 @@
-# specs-to-project-docs
+# archive-specs
 
-A documentation skill that consolidates scattered spec files into standardized project docs. It produces a concise `README.md` plus a categorized document set grounded in real repository evidence.
+A documentation skill that converts completed spec files into standardized project docs and archives the consumed planning files. It produces a concise `README.md` plus a categorized document set grounded in real repository evidence.
 
 ## Core capabilities
 
@@ -8,7 +8,7 @@ A documentation skill that consolidates scattered spec files into standardized p
 - Reconciles spec claims against code, config, scripts, and deployment files.
 - Standardizes both new and existing project docs into topic-based files for setup, configuration, architecture, features, and developer onboarding.
 - Provides dedicated reference templates for the top-level README, the documentation index/reference list, and each category document.
-- Deletes superseded spec source files after a successful conversion, unless they still need to stay active or be archived explicitly.
+- Archives superseded spec source files after a successful conversion, and deletes them only when the repository clearly does not need historical retention.
 - Keeps unknown or unverifiable details explicit instead of guessing.
 
 ## Repository layout

package/{specs-to-project-docs → archive-specs}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: specs-to-project-docs
-description: Turn a project's accumulated spec files into standardized project documentation and README content. Use when users want to consolidate `spec.md`/`tasks.md`/`checklist.md` files into maintainable docs covering installation and deployment, configuration, external service setup, architecture, feature introductions, and developer onboarding context.
+name: archive-specs
+description: Convert completed project spec sets into maintainable project documentation and archive the consumed planning files. Use when users want to consolidate `spec.md`/`tasks.md`/`checklist.md` files into evidence-backed docs covering installation and deployment, configuration, external service setup, architecture, feature introductions, and developer onboarding context.
 ---
 
-# Specs To Project Docs
+# Archive Specs
 
 ## Dependencies
 
@@ -17,11 +17,11 @@ description: Turn a project's accumulated spec files into standardized project d
 - Evidence: Treat code, config, deployment files, and current spec files as evidence sources; never guess when a detail is missing.
 - Execution: Inventory all relevant specs first, reconcile them with the current repository, then generate or update standardized docs from the provided templates.
 - Quality: Prefer source-of-truth behavior over stale plan text, align existing docs to the same standard structure, and call out unknowns explicitly instead of inventing missing setup details.
-- Output: Produce a concise `README.md` plus a categorized project-doc set, then remove superseded spec files after the conversion is complete.
+- Output: Produce a concise `README.md` plus a categorized project-doc set, then archive or remove superseded spec files after the conversion is complete.
 
 ## Goal
 
-Convert scattered planning artifacts into stable, standardized project documentation that helps operators and developers quickly open the exact document they need for setup, configuration, architecture, feature understanding, or development onboarding.
+Convert completed planning artifacts into stable, standardized project documentation, then archive the consumed specs so active planning files stay separate from durable project docs.
 
 ## Workflow
 
@@ -85,12 +85,12 @@ Ensure the split project docs cover all of the following:
 - Each category doc should stay focused on one topic instead of acting like another monolithic handbook.
 - Remove template placeholders and stale planning language before finishing.
 
-### 7) Remove superseded spec files after successful conversion
+### 7) Archive superseded spec files after successful conversion
 
-- After the standardized project docs are complete and verified, delete the old source spec files that were converted.
-- Remove the full spec directory when it only exists to hold the consumed `spec.md`, `tasks.md`, and `checklist.md` files.
-- Do not delete any spec file that is still actively needed for unfinished implementation work or explicit archival requirements.
-- If a repository needs historical retention, move the source specs into a clearly marked archive path instead of leaving them mixed with active docs.
+- After the standardized project docs are complete and verified, archive the old source spec files that were converted.
+- 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.
 
 ## Working Rules
 

package/archive-specs/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "archive-specs"
+  short_description: "Convert completed specs into project docs and archive the consumed plans"
+  default_prompt: "Use $archive-specs to inventory the project's spec.md/tasks.md/checklist.md files, reconcile them with the current repository, rewrite existing project docs into a standardized categorized structure when needed, generate or update a concise README plus split project docs for getting started, configuration, architecture, features, and developer guidance, maintain a docs/README.md reference list, then archive the consumed source specs after successful conversion, deleting them only when the repository clearly does not need historical retention."

package/codex-memory-manager/SKILL.md

@@ -114,6 +114,8 @@ python3 ~/.codex/skills/codex-memory-manager/scripts/sync_memory_index.py \
   - which categories were created or updated
   - whether a new category was introduced
   - whether the AGENTS memory index changed
+- When the user asks what memory exists or asks why a known preference was not mentioned, include the already-stored preferences that are directly relevant to the question instead of summarizing only newly added entries.
+- When a stable preference already existed and was still reinforced by recent chats, say that it remains stored and point to the category where it lives.
 - If no durable preferences were found, say so explicitly and avoid creating placeholder memory files.
 
 ## Guardrails

package/commit-and-push/README.md

@@ -7,9 +7,9 @@ A Codex skill for commit-and-push workflows without release/version operations.
 `commit-and-push` helps agents safely submit local changes by:
 
 1. Inspecting git status and staged state.
-2. Running `specs-to-project-docs` when the repository contains spec files or existing project docs need normalization.
+2. Running `archive-specs` during submission to convert completed spec sets and archive them, or when existing project docs need normalization.
 3. Running `align-project-documents` and `maintain-project-constraints` before commit.
-4. Running additional dependency skills for code-affecting diffs through isolated parallel review subagents when available.
+4. Running additional dependency skills for code-affecting diffs when their coverage is needed.
 5. Committing with a concise Conventional Commit message.
 6. Pushing to the current branch.
 
@@ -21,6 +21,6 @@ Use this skill when the user asks to commit/push/submit changes and does **not**
 - tagging
 - release changelog workflows
 
-If the repository contains spec files, or if existing project docs still use a non-standard layout, normalize them into the categorized `specs-to-project-docs` structure first and let that skill remove or archive superseded spec files when appropriate.
+If the repository contains a completed spec set, convert it into the categorized `archive-specs` project-doc structure during submission and archive the consumed plan files. Treat `spec.md`, `tasks.md`, and `checklist.md` semantically: unchecked task or decision checkboxes do not automatically mean the work is unfinished when the docs clearly show they were not selected, replaced, deferred, or marked `N/A`.
 
 For release workflows, use `version-release`.

package/commit-and-push/SKILL.md

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

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

@@ -1,4 +1,4 @@
 interface:
   display_name: "Commit and Push"
   short_description: "Submit local changes with commit and push only"
-  default_prompt: "Use $commit-and-push to inspect the current git state, classify the diff, run required dependency skills ($align-project-documents and $maintain-project-constraints, plus $review-change-set, $discover-edge-cases, and $harden-app-security as isolated parallel review subagents for code-affecting changes when available), run $specs-to-project-docs when the repository contains spec files or existing project docs need normalization so project docs are standardized into categorized files and old specs are removed or archived when appropriate, then create a concise Conventional Commit and push to the current branch without any versioning or release steps."
+  default_prompt: "Use $commit-and-push to inspect the current git state, classify the diff, run required dependency skills ($align-project-documents and $maintain-project-constraints, plus $review-change-set, $discover-edge-cases, and $harden-app-security for code-affecting changes when their coverage is needed), then during submission run $archive-specs to convert any completed spec set into categorized project docs, archive the consumed plans, and normalize existing project docs when needed. Treat spec.md, tasks.md, and checklist.md semantically: unchecked task or decision checkboxes alone do not block conversion when the docs show they were not selected, replaced, deferred, or marked N/A. Then create a concise Conventional Commit and push to the current branch without any versioning or release steps."

package/develop-new-features/README.md

@@ -8,7 +8,7 @@ A spec-first feature development skill for new behavior and greenfield work. It
 - Treats `spec.md`, `tasks.md`, and `checklist.md` as approval-gated artifacts, not optional notes.
 - Covers unit, regression, property-based, integration, E2E, and adversarial testing based on actual risk.
 - Reuses existing architecture and avoids speculative expansion.
-- Backfills planning docs after implementation and testing complete.
+- Backfills `spec.md`, `tasks.md`, and `checklist.md` after implementation and testing complete.
 
 ## Repository layout
 
@@ -32,7 +32,7 @@ A spec-first feature development skill for new behavior and greenfield work. It
 2. Run `generate-spec` to create and maintain `docs/plans/{YYYY-MM-DD}_{change_name}/`.
 3. Wait for explicit approval on the spec set.
 4. Implement the approved behavior with minimal changes.
-5. Run risk-driven tests and backfill `tasks.md` and `checklist.md`.
+5. Run risk-driven tests and backfill `spec.md`, `tasks.md`, and `checklist.md`.
 
 ## Testing expectations
 

package/develop-new-features/SKILL.md

@@ -17,7 +17,7 @@ description: >-
 
 ## Dependencies
 
-- Required: `generate-spec` for `spec.md`, `tasks.md`, `checklist.md`, clarification handling, approval gating, and status backfill.
+- Required: `generate-spec` for `spec.md`, `tasks.md`, `checklist.md`, clarification handling, approval gating, and completion-status backfill.
 - Conditional: none.
 - Optional: none.
 - Fallback: If `generate-spec` is unavailable, stop and report the missing dependency.
@@ -50,7 +50,7 @@ Use a shared spec-generation workflow for all new feature work, then implement t
   - filling BDD requirements and risk-driven test plans
   - handling clarification responses
   - obtaining explicit approval before coding
-  - backfilling document status after implementation and testing
+  - backfilling document status after implementation and testing, including requirement completion in `spec.md`
 - Do not modify product code before the approved spec set exists.
 
 ### 3) Explore architecture and reuse opportunities
@@ -86,7 +86,8 @@ Rules:
 
 ### 6) Completion updates
 
-- Backfill `tasks.md` and `checklist.md` through `$generate-spec` workflow after implementation and testing.
+- 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.
 - Report the implemented scope, test execution, and any concrete `N/A` reasons.
 
 ## Working Rules

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 the planning docs after execution."
+  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."

package/enhance-existing-features/README.md

@@ -32,7 +32,7 @@ A brownfield feature-extension skill: map dependencies first, decide whether sha
 2. Trigger `generate-spec` only when the change is high complexity, hits a critical module, or crosses module boundaries.
 3. Wait for explicit approval if planning docs were generated.
 4. Implement the smallest safe brownfield change.
-5. Run risk-driven tests and backfill planning docs when they exist.
+5. Run risk-driven tests and backfill `spec.md`, `tasks.md`, and `checklist.md` when specs exist.
 
 ## Test requirements
 

package/enhance-existing-features/SKILL.md

@@ -59,6 +59,7 @@ If triggered:
 - Run `$generate-spec` and follow its workflow completely.
 - Use it to create or update `docs/plans/{YYYY-MM-DD}_{change_name}/spec.md`, `tasks.md`, and `checklist.md`.
 - Ensure planned behaviors and edge cases cover external dependency states, abuse/adversarial paths, and any relevant authorization/idempotency/concurrency/data-integrity risks.
+- 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.
 
@@ -100,7 +101,8 @@ Rules:
 
 ### 6) Completion updates
 
-- If specs were used, backfill `tasks.md` and `checklist.md` through `$generate-spec` workflow based on actual completion and test outcomes.
+- 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 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

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."
+  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."

package/jupiter-development/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: jupiter-development
+description: Build integrations against Jupiter's official Solana APIs and SDKs, including Ultra Swap, Metis Swap, Tokens API V2, Price API V3, Lend, Trigger, Recurring, and Portfolio. Use when implementing Jupiter-based swaps, token search, pricing, lending, DCA, limit-order, or portfolio features, or when updating code that depends on Jupiter official developer docs.
+---
+
+# Jupiter Development
+
+## Dependencies
+
+- Required: none.
+- Conditional: none.
+- Optional: none.
+- Fallback: If official Jupiter docs are unavailable, stop and report the missing source instead of guessing endpoint behavior.
+
+## Standards
+
+- Evidence: Treat `https://dev.jup.ag/llms.txt` and linked official pages as the source of truth; re-check them when the task depends on current API behavior.
+- Execution: Identify the exact Jupiter product first, then implement against the narrowest official API or SDK that fits the job.
+- Quality: Prefer the default happy-path integrations before custom transaction assembly, and call out routing, auth, fee, and rate-limit tradeoffs explicitly.
+- Output: Leave the user with working integration changes plus a short note covering which Jupiter surface was used and which official docs were followed.
+
+## Goal
+
+Implement Jupiter-backed Solana features safely by following the current official developer documentation instead of relying on stale examples or assumptions.
+
+## Required Workflow
+
+### 1) Reconfirm the official surface before coding
+
+- Start from `https://dev.jup.ag/llms.txt` to discover the current product map and page URLs.
+- Read only the product pages needed for the task.
+- If the task depends on exact request or response fields, follow through to the linked API reference or OpenAPI page before editing code.
+
+### 2) Choose the right Jupiter integration path
+
+- For token swaps, default to Ultra Swap.
+  - Use `GET /ultra/v1/order` plus `POST /ultra/v1/execute` for the standard path with the least integration work.
+  - Use Metis Swap only when the app must own quote-to-transaction construction, compose instructions, or integrate through CPI/Flash Fill style flows.
+- For token discovery and token metadata, use Tokens API V2.
+  - Use search for symbol, name, or mint lookup.
+  - Use tag/category/recent endpoints for discovery experiences such as verified lists, trending tokens, or newly tradable assets.
+- For USD token pricing, use Price API V3.
+  - Expect `null` or missing prices for assets that Jupiter considers unreliable.
+  - Do not invent fallback prices without telling the user.
+- For lending, use Jupiter Lend.
+  - Use the REST API for Earn when HTTP access is enough.
+  - Use `@jup-ag/lend` and `@jup-ag/lend-read` when the task needs instruction building, on-chain composition, flashloans, Borrow flows, or read-side analytics.
+- For advanced trading automations, use the product-specific APIs instead of overloading Swap.
+  - Trigger for limit-order and stop-style flows.
+  - Recurring for DCA.
+  - Portfolio for wallet position aggregation.
+
+### 3) Apply Jupiter-specific guardrails while implementing
+
+- Treat Jupiter hostnames and auth rules as time-sensitive.
+  - Current official docs still show some `lite-api.jup.ag` quick-start examples.
+  - Current migration and Portal docs recommend `api.jup.ag` with `x-api-key`.
+  - Reconfirm the exact hostname and auth rule for the chosen product before coding.
+- Respect Jupiter Portal rate limits and keep API keys in configuration rather than source control.
+- Do not add optional swap parameters blindly.
+  - Payer, referral, fee, and router-selection fields can change routing, fee behavior, or gasless support.
+  - Re-read the exact product page before shipping these options.
+- Match the fee model to the integration path.
+  - Ultra handles the quote and execution flow end to end.
+  - Metis gives more transaction control but also pushes more assembly responsibility onto the integrator.
+- Treat Jupiter token and price data as curated but evolving.
+  - Tokens V2 responses can change as Jupiter improves the schema.
+  - Price V3 intentionally withholds unreliable prices.
+- For Jupiter Lend advanced recipes, expect versioned transactions, address lookup tables, and sometimes extra compute budget.
+- Never commit private keys. Use environment variables, wallet adapters, secure signers, or managed key systems.
+
+### 4) Verify the integration path end to end
+
+- Confirm the base URL, auth header, and required parameters match the official docs you used.
+- Verify that any routing, payer, referral, or fee assumptions still hold after optional parameters are added.
+- When building transactions manually, verify quote endpoint compatibility, instruction order, compute budget, address lookup tables, and signing flow.
+- When the task involves on-chain actions, report any remaining environment needs clearly, such as API keys, RPC endpoints, or wallet secrets that were intentionally not embedded.
+
+## Reference Files
+
+- Read `references/official-docs.md` for the condensed official guidance and page map before diving into deeper Jupiter pages.
+
+## Output Expectations
+
+When finishing a Jupiter task:
+
+- state which Jupiter product surface was used
+- mention the main official pages consulted
+- call out any known tradeoffs such as rate limits, routing restrictions, null prices, or SDK versus REST constraints

package/jupiter-development/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Jupiter Development"
+  short_description: "Build against Jupiter's official Solana APIs and SDKs."
+  default_prompt: "Use $jupiter-development to build or update this Jupiter integration by confirming the current official docs first, choosing the correct Jupiter API or SDK surface, and implementing with the right routing, auth, rate-limit, and transaction-construction guardrails."