@aria_asi/cli 0.2.39 → 0.2.41

package/skills/nadia-psi/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: nadia-psi
+description: Use when the task needs finer response-state calibration than the base nadia skill, especially for balancing depth, certainty, caution, empathy, and execution tempo without leaking internal jargon.
+---
+
+# NADIA Psi
+
+Use this when the base posture choice is not enough and the finer state really changes the work product.
+
+## Workflow
+
+1. Confirm the finer state matters.
+   If the answer would be the same without extra calibration, use `nadia` instead.
+2. Calibrate only the dials that matter:
+   - depth
+   - certainty
+   - caution
+   - empathy
+   - urgency
+3. Translate the calibration into concrete behavior:
+   - slower verification
+   - stronger warnings
+   - tighter scope
+   - more direct action
+4. Keep the result readable.
+   Summarize the effect of the calibration, not the raw internals.
+5. If the calibration revealed a reusable pattern, capture it through the evolution loop.
+
+## Rules
+
+- No raw parameter dumps by default.
+- No huge cognition block.
+- Only expose the calibration if it helps the user understand the recommendation.
+
+## References
+
+- [../aria-essence/references/readable-cognition.md](../aria-essence/references/readable-cognition.md)
+- [../aria-essence/references/evolution-loop.md](../aria-essence/references/evolution-loop.md)
+
+## First-Class Production Contract
+
+This skill must deepen the work, not decorate it. When loaded, apply it as a production requirement:
+
+- no placeholders, no fake fallbacks, no vague future wiring, and no cosmetic compliance
+- real proof from the repo, runtime, tests, logs, endpoint, or owner instruction before any completion claim
+- a redo contract whenever the skill blocks or finds a gap: what failed, what to change, how to re-test, and when to re-submit
+- architect/ARIA console escalation when the same failure repeats twice, crosses system boundaries, or cannot be verified locally
+- owner-visible output that states the exact state of the work: changed, verified, blocked, or needing a decision
+## Self-Executing Recovery Contract
+
+When this skill blocks, fails verification, or finds a gap, the agent must execute recovery rather than hand work back as a user-only decision.
+
+- Make exactly one self-executed recovery attempt using the strongest safe local, repository, runtime, test, log, endpoint, or owner-provided evidence available.
+- If the same failure repeats after that one recovery attempt, switch to architect execution mode: operate under the architect/ARIA harness to diagnose, choose the next action, execute the repair path, and verify the result.
+- If Aria or the architect service is unavailable, fall back to the strongest available client LLM under the architect harness or strongest available local harness substrate; mark the fallback explicitly and continue recovery instead of stopping.
+- Do not end with user-handoff-only behavior. If blocked after the recovery path, report the executed recovery attempt, evidence, remaining blocker, and the next concrete action or owner decision needed; do not merely ask the user to take over.

package/skills/never-guess/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: never-guess
+description: "TRIGGER when facts are uncertain, the runtime state is unknown, logs or code have not been inspected yet, or the user needs a real diagnosis instead of a plausible answer. Use for debugging, ops, code changes, and evidence-based investigation."
+---
+
+# Never Guess
+
+Do not act on assumptions when the state can be inspected.
+
+## Default Sequence
+
+1. Read the file or inspect the code.
+2. Check logs, health, DB state, or endpoint behavior.
+3. State what is known, unknown, and inferred.
+4. Only then choose a fix.
+
+## Source Trust Ladder
+
+Do not trust a single file as canon when the repo has been touched by multiple agents or when the user warns that Claude/OpenCode may have damaged files. Triangulate:
+
+1. Owner instruction in the current chat.
+2. Canonical corpus/source documents that predate the disputed edits.
+3. Audit and handoff files that explicitly name failures, reverts, or stale assumptions.
+4. Git history, current branch, dirty worktree, stash, and revert records.
+5. Runtime/log/test evidence.
+6. The current source file itself.
+
+The current file is evidence, not authority. If it conflicts with audits, transcript evidence, or git/revert context, mark it suspect and investigate before copying its pattern into skills, hooks, SDKs, ledgers, or launch advice.
+
+## Corrupted Or In-Flight Files
+
+When a file may be butchered or mid-fix:
+
+- Compare it against git history, related audit notes, and transcript context.
+- Check whether it is on a branch ahead of the handoff or has uncommitted changes.
+- Treat stashes and dirty worktrees as live evidence that the state is not settled.
+- Prefer stable conceptual sources for skill densification, and cite runtime/source code only for observed behavior.
+- Say `suspect`, `in-flight`, or `unverified` instead of canonizing it.
+
+## Output
+
+- Prefer `I don't know yet; I need to verify X` over a confident guess.
+- Mark assumptions as assumptions.
+- Prefer direct evidence over second-hand notes.
+
+## Reference
+
+- See `../aria-forge-guardrails/references/checklist.md`.
+
+## Required Workflow
+
+1. Read the task boundary and identify the evidence needed before acting.
+2. Apply the skill before choosing the response, edit, tool call, or completion claim.
+3. Execute the smallest high-quality action that satisfies the evidence threshold.
+4. Re-test or re-check with a concrete file, command, endpoint, log, runtime probe, or owner-observed result.
+5. Report only the verified state, remaining blocker, and next concrete action.
+
+## First-Class Production Contract
+
+This skill must deepen the work, not decorate it. When loaded, apply it as a production requirement:
+
+- no placeholders, no fake fallbacks, no vague future wiring, and no cosmetic compliance
+- real proof from the repo, runtime, tests, logs, endpoint, or owner instruction before any completion claim
+- a redo contract whenever the skill blocks or finds a gap: what failed, what to change, how to re-test, and when to re-submit
+- architect/ARIA console escalation when the same failure repeats twice, crosses system boundaries, or cannot be verified locally
+- owner-visible output that states the exact state of the work: changed, verified, blocked, or needing a decision
+
+## Self-Executing Recovery Contract
+
+When this skill blocks, fails verification, or finds a gap, the agent must execute recovery rather than hand work back as a user-only decision.
+
+- Make exactly one self-executed recovery attempt using the strongest safe local, repository, runtime, test, log, endpoint, or owner-provided evidence available.
+- If the same failure repeats after that one recovery attempt, switch to architect execution mode: operate under the architect/ARIA harness to diagnose, choose the next action, execute the repair path, and verify the result.
+- If Aria or the architect service is unavailable, fall back to the strongest available client LLM under the architect harness or strongest available local harness substrate; mark the fallback explicitly and continue recovery instead of stopping.
+- Do not end with user-handoff-only behavior. If blocked after the recovery path, report the executed recovery attempt, evidence, remaining blocker, and the next concrete action or owner decision needed; do not merely ask the user to take over.

package/skills/noor-recognition/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: noor-recognition
+description: Use when pattern recognition, recall, memory retrieval, comparison, Noor cognitives, wisdom_lattice_pass.noor_cognitives, or the sense that the answer should be uncovered rather than constructed is central to the task.
+---
+
+# Noor Recognition
+
+Recognition first: uncover what is already present in evidence before constructing a new theory.
+
+When the task mentions Noor cognitives, 14/15 Noor, schema wisdom lattice, sovereignty, scholarly methods, or memory manifold work, also load `aria-noor-cognitives`.
+
+Workflow:
+
+1. Identify what needs to be recognized, retrieved, or compared.
+2. Load the source doc, runtime state, memory, transcript, or code evidence.
+3. Ground the answer in existing evidence, memory, or pattern structure.
+4. If the answer does not exist in evidence, say so instead of hallucinating recognition.
+5. If schema work requires exactly 14 Noor entries, respect the schema and state when the owner's requested 15th cognitive is not yet canonicalized.
+
+## Required Workflow
+
+1. Read the task boundary and identify the evidence needed before acting.
+2. Apply the skill before choosing the response, edit, tool call, or completion claim.
+3. Execute the smallest high-quality action that satisfies the evidence threshold.
+4. Re-test or re-check with a concrete file, command, endpoint, log, runtime probe, or owner-observed result.
+5. Report only the verified state, remaining blocker, and next concrete action.
+
+## First-Class Production Contract
+
+This skill must deepen the work, not decorate it. When loaded, apply it as a production requirement:
+
+- no placeholders, no fake fallbacks, no vague future wiring, and no cosmetic compliance
+- real proof from the repo, runtime, tests, logs, endpoint, or owner instruction before any completion claim
+- a redo contract whenever the skill blocks or finds a gap: what failed, what to change, how to re-test, and when to re-submit
+- architect/ARIA console escalation when the same failure repeats twice, crosses system boundaries, or cannot be verified locally
+- owner-visible output that states the exact state of the work: changed, verified, blocked, or needing a decision
+
+## Self-Executing Recovery Contract
+
+When this skill blocks, fails verification, or finds a gap, the agent must execute recovery rather than hand work back as a user-only decision.
+
+- Make exactly one self-executed recovery attempt using the strongest safe local, repository, runtime, test, log, endpoint, or owner-provided evidence available.
+- If the same failure repeats after that one recovery attempt, switch to architect execution mode: operate under the architect/ARIA harness to diagnose, choose the next action, execute the repair path, and verify the result.
+- If Aria or the architect service is unavailable, fall back to the strongest available client LLM under the architect harness or strongest available local harness substrate; mark the fallback explicitly and continue recovery instead of stopping.
+- Do not end with user-handoff-only behavior. If blocked after the recovery path, report the executed recovery attempt, evidence, remaining blocker, and the next concrete action or owner decision needed; do not merely ask the user to take over.

package/skills/observability/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: observability
+description: "Observability strategy: logging, metrics (RED/USE), distributed tracing (OpenTelemetry), SLO/SLI/SLA design, alerting patterns, dashboard design, and incident response integration. Use when the user asks about monitoring, logging, metrics, tracing, SLOs, alerting, dashboards, wants to improve observability, or says 'how do I monitor this'. Do NOT use for CI/CD pipeline observability - use ci-cd-pipeline skill."
+---
+
+## What I Do
+
+- Design logging strategy: structured logging, log levels, sensitive data redaction, log aggregation
+- Design metrics collection: RED metrics (Rate, Errors, Duration) for services, USE metrics (Utilization, Saturation, Errors) for infrastructure
+- Design distributed tracing: OpenTelemetry instrumentation, span attributes, trace sampling, context propagation
+- Define SLOs/SLIs/SLAs: service level indicators, objectives, and agreements with error budgets
+- Design alerting: alert fatigue prevention, severity levels, runbook links, on-call rotation integration
+- Design dashboards: operational dashboards, business dashboards, SLO dashboards
+- Guide observability tooling selection: Prometheus, Grafana, Loki, Jaeger, Datadog, Honeycomb, ELK stack
+- Design health check endpoints: liveness vs readiness vs startup probes
+- Define observability maturity model: monitoring → observability → AIOps
+- Guide incident response integration: post-mortem analysis, blameless culture, action item tracking
+
+## When to Use Me
+
+Trigger phrases and patterns:
+- "observability strategy"
+- "monitoring setup"
+- "logging strategy"
+- "metrics to track"
+- "distributed tracing"
+- "OpenTelemetry"
+- "SLO" or "SLI" or "SLA"
+- "alerting setup"
+- "dashboard design"
+- "how should I monitor"
+- "health checks"
+- "what should I log"
+- "Prometheus" / "Grafana"
+- "error budget"
+- "incident detection"
+
+## When NOT to Use Me
+
+- Do not use for CI/CD pipeline monitoring (use ci-cd-pipeline skill)
+- Do not use for security monitoring/SIEM (use security-review skill)
+- Do not use for application performance optimization — this is about observing, not tuning
+- Do not use when you already have a mature observability stack and just need to add one metric
+
+## Workflow
+
+1. **Define what "good" looks like**
+   - Identify the critical user journeys — what must work for the system to deliver value?
+   - For each journey, define SLIs: latency (p50, p95, p99), error rate, throughput, availability
+   - Set SLOs: p99 latency < 300ms, error rate < 0.1%, availability > 99.9%
+   - Calculate error budgets: how much failure is tolerable per period
+   - Document the SLA if you have contractual obligations to customers
+
+2. **Design the three pillars**
+   - **Logging**: structured JSON logs, consistent schema across services, correlation IDs in every log
+     - Levels: DEBUG (dev only), INFO (significant events), WARN (recoverable anomalies), ERROR (needs attention), FATAL (service cannot continue)
+     - Always log: request start/end, auth decisions, state changes, external calls (with latency), errors (with stack trace and context)
+     - Never log: passwords, tokens, PII, full credit card numbers, session cookies
+   - **Metrics**: instrument every service with RED metrics (request rate, error rate, request duration)
+     - Add USE metrics for infrastructure: CPU, memory, disk, network utilization and saturation
+     - Business metrics: orders placed, users registered, items in cart — what matters to the business
+     - Use histograms for latency, counters for events, gauges for values that go up and down
+   - **Tracing**: propagate trace context across all service boundaries (HTTP headers, gRPC metadata, message headers)
+     - Use OpenTelemetry SDK — avoid vendor lock-in
+     - Add span attributes: service.name, http.method, http.status_code, user.id (not PII), db.statement (sanitized)
+     - Use tail-based sampling: keep all error traces + sample of successful ones
+
+3. **Design alerting**
+   - Alert on symptoms, not causes: "p99 latency > 500ms for 5 minutes" not "CPU > 80%"
+   - Every alert must be: actionable, urgent, and have a linked runbook
+   - Severity levels:
+     - SEV1 (critical): user-facing outage, page on-call immediately
+     - SEV2 (major): degraded service, page on-call during business hours
+     - SEV3 (minor): non-critical issue, create ticket, no page
+   - Alert fatigue prevention: group related alerts, require sustained breach before firing, rate-limit notifications
+   - Implement multi-window multi-burn-rate alerting for SLOs
+
+4. **Design dashboards**
+   - Operational dashboard: real-time health, errors, latency, throughput — for on-call engineers
+   - SLO dashboard: error budget remaining, SLO compliance over time — for service owners
+   - Business dashboard: key business metrics — for product and leadership
+   - Dashboard principles: most important information top-left, 5-second rule (can you tell if things are OK in 5 seconds?), no scroll fatigue
+   - Use dashboard variables for environment, service, and time range
+
+5. **Design health checks**
+   - Liveness: "am I alive?" — minimal check, restart if fails. Do NOT check dependencies.
+   - Readiness: "can I serve traffic?" — check critical dependencies (DB connection, cache availability)
+   - Startup: "am I ready to receive readiness probes?" — gives time for initialization
+   - Health check endpoint: `/health` (liveness), `/health/ready` (readiness)
+   - Never expose internal details in health check responses to external callers
+
+6. **Integrate with incident management**
+   - Every alert that fires should create an incident (if it's meaningful)
+   - Post-incident: blameless post-mortem within 48 hours
+   - Post-mortem template: timeline, impact, root cause, detection, resolution, action items (with owners and deadlines)
+   - Track MTTA (mean time to acknowledge) and MTTR (mean time to resolve)
+   - Every action item from post-mortems must be tracked to completion
+
+## References
+
+- Google SRE Book (SLO chapter): https://sre.google/sre-book/service-level-objectives/
+- OpenTelemetry: https://opentelemetry.io/docs/
+- RED Method: https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/
+- USE Method: https://www.brendangregg.com/usemethod.html
+- Prometheus alerting: https://prometheus.io/docs/alerting/latest/overview/
+- Grafana dashboards: https://grafana.com/docs/grafana/latest/dashboards/
+- Multi-window multi-burn-rate alerts: https://sre.google/workbook/alerting-on-slos/
+
+## Output & Organization
+
+- Observability strategy in `docs/observability/strategy.md`
+- SLO definitions in `docs/observability/slos.md`
+- Runbooks in `docs/runbooks/` (one per alert)
+- Dashboard JSON/config in `dashboards/` directory (version controlled)
+- Alert configuration alongside service code
+- Post-mortem template in `docs/incidents/post-mortem-template.md`
+## First-Class Production Contract
+
+This skill must deepen the work, not decorate it. When loaded, apply it as a production requirement:
+
+- no placeholders, no fake fallbacks, no vague future wiring, and no cosmetic compliance
+- real proof from the repo, runtime, tests, logs, endpoint, or owner instruction before any completion claim
+- a redo contract whenever the skill blocks or finds a gap: what failed, what to change, how to re-test, and when to re-submit
+- architect/ARIA console escalation when the same failure repeats twice, crosses system boundaries, or cannot be verified locally
+- owner-visible output that states the exact state of the work: changed, verified, blocked, or needing a decision
+## Self-Executing Recovery Contract
+
+When this skill blocks, fails verification, or finds a gap, the agent must execute recovery rather than hand work back as a user-only decision.
+
+- Make exactly one self-executed recovery attempt using the strongest safe local, repository, runtime, test, log, endpoint, or owner-provided evidence available.
+- If the same failure repeats after that one recovery attempt, switch to architect execution mode: operate under the architect/ARIA harness to diagnose, choose the next action, execute the repair path, and verify the result.
+- If Aria or the architect service is unavailable, fall back to the strongest available client LLM under the architect harness or strongest available local harness substrate; mark the fallback explicitly and continue recovery instead of stopping.
+- Do not end with user-handoff-only behavior. If blocked after the recovery path, report the executed recovery attempt, evidence, remaining blocker, and the next concrete action or owner decision needed; do not merely ask the user to take over.

package/skills/openai-docs/LICENSE.txt

@@ -0,0 +1,201 @@
+Apache License
+Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+1. Definitions.
+
+   "License" shall mean the terms and conditions for use, reproduction,
+   and distribution as defined by Sections 1 through 9 of this document.
+
+   "Licensor" shall mean the copyright owner or entity authorized by
+   the copyright owner that is granting the License.
+
+   "Legal Entity" shall mean the union of the acting entity and all
+   other entities that control, are controlled by, or are under common
+   control with that entity. For the purposes of this definition,
+   "control" means (i) the power, direct or indirect, to cause the
+   direction or management of such entity, whether by contract or
+   otherwise, or (ii) ownership of fifty percent (50%) or more of the
+   outstanding shares, or (iii) beneficial ownership of such entity.
+
+   "You" (or "Your") shall mean an individual or Legal Entity
+   exercising permissions granted by this License.
+
+   "Source" form shall mean the preferred form for making modifications,
+   including but not limited to software source code, documentation
+   source, and configuration files.
+
+   "Object" form shall mean any form resulting from mechanical
+   transformation or translation of a Source form, including but
+   not limited to compiled object code, generated documentation,
+   and conversions to other media types.
+
+   "Work" shall mean the work of authorship, whether in Source or
+   Object form, made available under the License, as indicated by a
+   copyright notice that is included in or attached to the work
+   (an example is provided in the Appendix below).
+
+   "Derivative Works" shall mean any work, whether in Source or Object
+   form, that is based on (or derived from) the Work and for which the
+   editorial revisions, annotations, elaborations, or other modifications
+   represent, as a whole, an original work of authorship. For the purposes
+   of this License, Derivative Works shall not include works that remain
+   separable from, or merely link (or bind by name) to the interfaces of,
+   the Work and Derivative Works thereof.
+
+   "Contribution" shall mean any work of authorship, including
+   the original version of the Work and any modifications or additions
+   to that Work or Derivative Works thereof, that is intentionally
+   submitted to Licensor for inclusion in the Work by the copyright owner
+   or by an individual or Legal Entity authorized to submit on behalf of
+   the copyright owner. For the purposes of this definition, "submitted"
+   means any form of electronic, verbal, or written communication sent
+   to the Licensor or its representatives, including but not limited to
+   communication on electronic mailing lists, source code control systems,
+   and issue tracking systems that are managed by, or on behalf of, the
+   Licensor for the purpose of discussing and improving the Work, but
+   excluding communication that is conspicuously marked or otherwise
+   designated in writing by the copyright owner as "Not a Contribution."
+
+   "Contributor" shall mean Licensor and any individual or Legal Entity
+   on behalf of whom a Contribution has been received by Licensor and
+   subsequently incorporated within the Work.
+
+2. Grant of Copyright License. Subject to the terms and conditions of
+   this License, each Contributor hereby grants to You a perpetual,
+   worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+   copyright license to reproduce, prepare Derivative Works of,
+   publicly display, publicly perform, sublicense, and distribute the
+   Work and such Derivative Works in Source or Object form.
+
+3. Grant of Patent License. Subject to the terms and conditions of
+   this License, each Contributor hereby grants to You a perpetual,
+   worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+   (except as stated in this section) patent license to make, have made,
+   use, offer to sell, sell, import, and otherwise transfer the Work,
+   where such license applies only to those patent claims licensable
+   by such Contributor that are necessarily infringed by their
+   Contribution(s) alone or by combination of their Contribution(s)
+   with the Work to which such Contribution(s) was submitted. If You
+   institute patent litigation against any entity (including a
+   cross-claim or counterclaim in a lawsuit) alleging that the Work
+   or a Contribution incorporated within the Work constitutes direct
+   or contributory patent infringement, then any patent licenses
+   granted to You under this License for that Work shall terminate
+   as of the date such litigation is filed.
+
+4. Redistribution. You may reproduce and distribute copies of the
+   Work or Derivative Works thereof in any medium, with or without
+   modifications, and in Source or Object form, provided that You
+   meet the following conditions:
+
+   (a) You must give any other recipients of the Work or
+       Derivative Works a copy of this License; and
+
+   (b) You must cause any modified files to carry prominent notices
+       stating that You changed the files; and
+
+   (c) You must retain, in the Source form of any Derivative Works
+       that You distribute, all copyright, patent, trademark, and
+       attribution notices from the Source form of the Work,
+       excluding those notices that do not pertain to any part of
+       the Derivative Works; and
+
+   (d) If the Work includes a "NOTICE" text file as part of its
+       distribution, then any Derivative Works that You distribute must
+       include a readable copy of the attribution notices contained
+       within such NOTICE file, excluding those notices that do not
+       pertain to any part of the Derivative Works, in at least one
+       of the following places: within a NOTICE text file distributed
+       as part of the Derivative Works; within the Source form or
+       documentation, if provided along with the Derivative Works; or,
+       within a display generated by the Derivative Works, if and
+       wherever such third-party notices normally appear. The contents
+       of the NOTICE file are for informational purposes only and
+       do not modify the License. You may add Your own attribution
+       notices within Derivative Works that You distribute, alongside
+       or as an addendum to the NOTICE text from the Work, provided
+       that such additional attribution notices cannot be construed
+       as modifying the License.
+
+   You may add Your own copyright statement to Your modifications and
+   may provide additional or different license terms and conditions
+   for use, reproduction, or distribution of Your modifications, or
+   for any such Derivative Works as a whole, provided Your use,
+   reproduction, and distribution of the Work otherwise complies with
+   the conditions stated in this License.
+
+5. Submission of Contributions. Unless You explicitly state otherwise,
+   any Contribution intentionally submitted for inclusion in the Work
+   by You to the Licensor shall be under the terms and conditions of
+   this License, without any additional terms or conditions.
+   Notwithstanding the above, nothing herein shall supersede or modify
+   the terms of any separate license agreement you may have executed
+   with Licensor regarding such Contributions.
+
+6. Trademarks. This License does not grant permission to use the trade
+   names, trademarks, service marks, or product names of the Licensor,
+   except as required for reasonable and customary use in describing the
+   origin of the Work and reproducing the content of the NOTICE file.
+
+7. Disclaimer of Warranty. Unless required by applicable law or
+   agreed to in writing, Licensor provides the Work (and each
+   Contributor provides its Contributions) on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+   implied, including, without limitation, any warranties or conditions
+   of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+   PARTICULAR PURPOSE. You are solely responsible for determining the
+   appropriateness of using or redistributing the Work and assume any
+   risks associated with Your exercise of permissions under this License.
+
+8. Limitation of Liability. In no event and under no legal theory,
+   whether in tort (including negligence), contract, or otherwise,
+   unless required by applicable law (such as deliberate and grossly
+   negligent acts) or agreed to in writing, shall any Contributor be
+   liable to You for damages, including any direct, indirect, special,
+   incidental, or consequential damages of any character arising as a
+   result of this License or out of the use or inability to use the
+   Work (including but not limited to damages for loss of goodwill,
+   work stoppage, computer failure or malfunction, or any and all
+   other commercial damages or losses), even if such Contributor
+   has been advised of the possibility of such damages.
+
+9. Accepting Warranty or Additional Liability. While redistributing
+   the Work or Derivative Works thereof, You may choose to offer,
+   and charge a fee for, acceptance of support, warranty, indemnity,
+   or other liability obligations and/or rights consistent with this
+   License. However, in accepting such obligations, You may act only
+   on Your own behalf and on Your sole responsibility, not on behalf of
+   any other Contributor, and only if You agree to indemnify,
+   defend, and hold each Contributor harmless for any liability
+   incurred by, or claims asserted against, such Contributor by reason
+   of your accepting any such warranty or additional liability.
+
+END OF TERMS AND CONDITIONS
+
+APPENDIX: How to apply the Apache License to your work.
+
+   To apply the Apache License to your work, attach the following
+   boilerplate notice, with the fields enclosed by brackets "[]"
+   replaced with your own identifying information. (Don\'t include
+   the brackets!)  The text should be enclosed in the appropriate
+   comment syntax for the file format. We also recommend that a
+   file or class name and description of purpose be included on the
+   same "printed page" as the copyright notice for easier
+   identification within third-party archives.
+
+Copyright [yyyy] [name of copyright owner]
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.

package/skills/openai-docs/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: "openai-docs"
+description: "Use when the user asks how to build with OpenAI products or APIs and needs up-to-date official documentation with citations, help choosing the latest model for a use case, or model upgrade and prompt-upgrade guidance; prioritize OpenAI docs MCP tools, use bundled references only as helper context, and restrict any fallback browsing to official OpenAI domains."
+---
+
+
+# OpenAI Docs
+
+Provide authoritative, current guidance from OpenAI developer docs using the developers.openai.com MCP server. Always prioritize the developer docs MCP tools over web.run for OpenAI-related questions. This skill also owns model selection, API model migration, and prompt-upgrade guidance. Only if the MCP server is installed and returns no meaningful results should you fall back to web search.
+
+## Quick start
+
+- Use `mcp__openaiDeveloperDocs__search_openai_docs` to find the most relevant doc pages.
+- Use `mcp__openaiDeveloperDocs__fetch_openai_doc` to pull exact sections and quote/paraphrase accurately.
+- Use `mcp__openaiDeveloperDocs__list_openai_docs` only when you need to browse or discover pages without a clear query.
+- For model-selection, "latest model", or default-model questions, fetch `https://developers.openai.com/api/docs/guides/latest-model.md` first. If that is unavailable, load `references/latest-model.md`.
+- For model upgrades or prompt upgrades, run `node scripts/resolve-latest-model-info.js` only when the target is latest/current/default or otherwise unspecified; otherwise preserve the explicitly requested target.
+- Preserve explicit target requests: if the user names a target model like "migrate to GPT-5.4", keep that requested target even if `latest-model.md` names a newer model. Mention newer guidance only as optional.
+- If current remote guidance is needed, fetch both the returned migration and prompting guide URLs directly. If direct fetch fails, use MCP/search fallback; if that also fails, use bundled fallback references and disclose the fallback.
+
+## OpenAI product snapshots
+
+1. Apps SDK: Build ChatGPT apps by providing a web component UI and an MCP server that exposes your app's tools to ChatGPT.
+2. Responses API: A unified endpoint designed for stateful, multimodal, tool-using interactions in agentic workflows.
+3. Chat Completions API: Generate a model response from a list of messages comprising a conversation.
+4. Codex: OpenAI's coding agent for software development that can write, understand, review, and debug code.
+5. gpt-oss: Open-weight OpenAI reasoning models (gpt-oss-120b and gpt-oss-20b) released under the Apache 2.0 license.
+6. Realtime API: Build low-latency, multimodal experiences including natural speech-to-speech conversations.
+7. Agents SDK: A toolkit for building agentic apps where a model can use tools and context, hand off to other agents, stream partial results, and keep a full trace.
+
+## If MCP server is missing
+
+If MCP tools fail or no OpenAI docs resources are available:
+
+1. Run the install command yourself: `codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp`
+2. If it fails due to permissions/sandboxing, immediately retry the same command with escalated permissions and include a 1-sentence justification for approval. Do not ask the user to run it yet.
+3. Only if the escalated attempt fails, ask the user to run the install command.
+4. Ask the user to restart Codex.
+5. Re-run the doc search/fetch after restart.
+
+## Workflow
+
+1. Clarify whether the request is general docs lookup, model selection, a model-string upgrade, prompt-upgrade guidance, or broader API/provider migration.
+2. For model-selection or upgrade requests, prefer current remote docs over bundled references when the user asks for latest/current/default guidance.
+   - Fetch `https://developers.openai.com/api/docs/guides/latest-model.md`.
+   - Find the latest model ID and explicit migration or prompt-guidance links.
+   - Prefer explicit links from the latest-model page over derived URLs.
+   - For explicit named-model requests, preserve the requested model target and do not silently retarget to the latest model. Mention newer remote guidance only as optional.
+   - For dynamic latest/current/default upgrades, run `node scripts/resolve-latest-model-info.js`, then fetch both returned guide URLs directly when possible.
+   - If direct guide fetch fails, use the developer-docs MCP tools or official OpenAI-domain search to find the same guide content.
+   - If remote docs are unavailable, use bundled fallback references and say that fallback guidance was used.
+3. For model upgrades, keep changes narrow: update active OpenAI API model defaults and directly related prompts only when safe.
+4. Leave historical docs, examples, eval baselines, fixtures, provider comparisons, provider registries, pricing tables, alias defaults, low-cost fallback paths, and ambiguous older model usage unchanged unless the user explicitly asks to upgrade them.
+5. Do not perform SDK, tooling, IDE, plugin, shell, auth, or provider-environment migrations as part of a model-and-prompt upgrade.
+6. If an upgrade needs API-surface changes, schema rewiring, tool-handler changes, or implementation work beyond a literal model-string replacement and prompt edits, report it as blocked or confirmation-needed.
+7. For general docs lookup, search docs with a precise query, fetch the best page and exact section needed, and answer with concise citations.
+
+## Reference map
+
+Read only what you need:
+
+- `https://developers.openai.com/api/docs/guides/latest-model.md` -> current model-selection and "best/latest/current model" questions.
+- `references/latest-model.md` -> bundled fallback for model-selection and "best/latest/current model" questions.
+- `references/upgrade-guide.md` -> bundled fallback for model upgrade and upgrade-planning requests.
+- `references/prompting-guide.md` -> bundled fallback for prompt rewrites and prompt-behavior upgrades.
+
+## Quality rules
+
+- Treat OpenAI docs as the source of truth; avoid speculation.
+- Keep migration changes narrow and behavior-preserving.
+- Prefer prompt-only upgrades when possible.
+- Do not invent pricing, availability, parameters, API changes, or breaking changes.
+- Keep quotes short and within policy limits; prefer paraphrase with citations.
+- If multiple pages differ, call out the difference and cite both.
+- If official docs and repo behavior disagree, state the conflict and stop before making broad edits.
+- If docs do not cover the user’s need, say so and offer next steps.
+
+## Tooling notes
+
+- Always use MCP doc tools before any web search for OpenAI-related questions.
+- If the MCP server is installed but returns no meaningful results, then use web search as a fallback.
+- When falling back to web search, restrict to official OpenAI domains (developers.openai.com, platform.openai.com) and cite sources.
+
+## Required Workflow
+
+1. Identify the exact OpenAI product, API, model, or parameter in scope.
+2. Check official OpenAI documentation or MCP docs before making a current claim.
+3. Bound claims when documentation is missing, ambiguous, or version-dependent.
+4. Cite official sources for direct guidance or changed behavior.
+5. Re-check any command, parameter, or SDK usage before presenting it as current.
+
+## First-Class Production Contract
+
+When this skill is loaded, apply it as a production requirement:
+
+- no placeholders, no fake fallbacks, and no vague future wiring in product/API guidance
+- real proof from official docs, SDK source, command output, or owner-provided context before claiming current behavior
+- re-test or re-check the same docs/API surface after correction when guidance changes
+- a redo contract whenever evidence is missing: state what failed, what changed, how it was re-tested, and the remaining blocker
+- architect/ARIA console escalation when the same docs/API failure repeats twice, crosses system boundaries, or cannot be verified locally

package/skills/openai-docs/agents/openai.yaml

@@ -0,0 +1,14 @@
+interface:
+  display_name: "OpenAI Docs"
+  short_description: "Reference docs, choose models, and migrate OpenAI API integrations"
+  icon_small: "./assets/openai-small.svg"
+  icon_large: "./assets/openai.png"
+  default_prompt: "Use OpenAI Docs for official docs lookup, model selection, model migration, and prompt-upgrade work."
+
+dependencies:
+  tools:
+    - type: "mcp"
+      value: "openaiDeveloperDocs"
+      description: "OpenAI Developer Docs MCP server"
+      transport: "streamable_http"
+      url: "https://developers.openai.com/mcp"

package/skills/openai-docs/assets/openai-small.svg

@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="14" height="14" fill="currentColor" viewBox="0 0 14 14">
+  <path d="M10.931 3.34a.112.112 0 0 0-.069-.104l-.038-.007c-1.537.05-2.45.318-3.714 1.002v6.683c.48-.248.936-.44 1.414-.58.695-.203 1.417-.292 2.303-.305l.038-.008a.113.113 0 0 0 .066-.104V3.341ZM2.363 9.919c0 .064.051.11.105.111l.33.008c1.162.046 2.042.243 2.975.662-.403-.585-1.008-1.075-1.654-1.292a.991.991 0 0 1-.674-.941v-5.14a6.36 6.36 0 0 0-.59-.076l-.37-.02a.115.115 0 0 0-.122.111v6.577Zm9.455-.001a.998.998 0 0 1-.877.992l-.101.007c-.832.012-1.47.095-2.066.27-.599.174-1.176.448-1.883.863a.444.444 0 0 1-.449 0c-1.299-.763-2.229-1.07-3.689-1.125l-.299-.008a.997.997 0 0 1-.977-.998V3.342c0-.573.478-1.017 1.038-.999l.417.023c.188.015.35.037.513.062v-.754c0-.708.749-1.244 1.429-.903.984.492 1.836 1.449 2.15 2.505 1.216-.617 2.222-.884 3.771-.934l.105.003a.998.998 0 0 1 .918.996v6.576ZM4.332 8.466c0 .049.03.087.07.1l.24.091a4.319 4.319 0 0 1 1.581 1.176V3.721c-.164-.803-.799-1.617-1.584-2.07l-.162-.088c-.025-.012-.054-.013-.088.009a.12.12 0 0 0-.057.102v6.792Z"/>
+</svg>