Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/pacificstudio/openase/commitnpx skills add PacificStudio/openase --skill commitgit clone --depth 1 https://github.com/PacificStudio/openaseWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00036 | $0.00591 |
| Opus 5 | $0.00018 | $0.00296 |
| Sonnet 5 | $0.00007 | $0.00118 |
| Haiku 4.5 | $0.00004 | $0.00059 |
Grade A, and why
commit scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to commit — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Commit
Goals
- Produce a commit that reflects the actual code changes and the session context.
- Follow common git conventions (type prefix, short subject, wrapped body).
- Include both summary and rationale in the body.
Inputs
- Codex session history for intent and rationale.
git status,git diff, andgit diff --stagedfor actual changes.- Repo-specific commit conventions if documented.
Steps
- Read session history to identify scope, intent, and rationale.
- Inspect the working tree and staged changes (
git status,git diff,git diff --staged). - Stage intended changes, including new files (
git add -A) after confirming scope. - Sanity-check newly added files; if anything looks random or likely ignored (build artifacts, logs, temp files), flag it to the user before committing.
- If staging is incomplete or includes unrelated files, fix the index or ask for confirmation.
- Choose a conventional type and optional scope that match the change (e.g.,
feat(scope): ...,fix(scope): ...,refactor(scope): ...). - Write a subject line in imperative mood, <= 72 characters, no trailing period.
- Write a body that includes:
- Summary of key changes (what changed).
- Rationale and trade-offs (why it changed).
- Tests or validation run (or explicit note if not run).
- Append a
Co-authored-bytrailer for Codex usingCodex <[email protected]>unless the user explicitly requests a different identity. - Wrap body lines at 72 characters.
- Create the commit message with a here-doc or temp file and use
git commit -F <file>so newlines are literal (avoid-mwith\n). - Commit only when the message matches the staged changes: if the staged diff includes unrelated files or the message describes work that isn't staged, fix the index or revise the message before committing.
Output
- A single commit created with
git commitwhose message reflects the session.
Template
Type and scope are examples only; adjust to fit the repo and changes.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 76 lines · 36 tokens per session scan A 60788c28cdc1
commit is a skill published in the GitHub repository PacificStudio/openase (265 stars, last pushed 23d ago), licensed Apache-2.0. It adds 36 tokens to every session and 591 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to commit, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
aisee:init
初始化、审计并优化 OpenSpec/Aisee 项目配置。仅适用于已使用或准备接入 OpenSpec 的项目;用于创建或修复 AGENTS.md、openspec/project.md、aisee/memory/、最小 Aisee docs 目录,并在当前支持的 Codex hook target 下安装项目级 hooks;检查 hook 机制兼容性、OpenSpec 状态机、baseline 迁移入口与项目技术架构边界。触发词包括 aisee:init、aisee-init、初始化项目配置、优化 AGENTS.md、配置 Codex hooks、OpenSpec 配置审计。.
aisee:srs
通过结构化对话充分澄清软件类业务需求,并生成规划级详细的需求规格说明书(SRS)。当用户想写需求文档、澄清产品范围、整理业务目标/用户角色/业务能力/业务流程/业务规则/权限/非目标,或为 aisee:change-plan 准备稳定输入时使用。适用于 App、小程序、Web、桌面软件、后端/API 服务、CLI 工具、定时任务/异步任务等软件项目。SRS 应写到足够支持后续拆 change 和编写 change 内容,但不要写成接口设计、数据库设计、技术方案、视觉设计、硬件架构、固件设计或开发任务。.
hw:change-plan
将已确认的硬件 SRS、整体架构、工程事实和模块文档映射为可独立交付的 OpenSpec changes。用于规划硬件/嵌入式项目的 change 边界、依赖顺序、并行关系、aisee-device-spec-driven schema、source-map seed 和 /opsx:new 命令;不重新做需求、不重新做整体架构、不写实现代码。触发词包括“硬件change拆分”“硬件实施计划”“拆OpenSpec change”“source-map seed”“hw:change-plan”。.
hw:init
硬件工程初始化辅助技能。用于在 initialize-hardware-project OpenSpec change 的实现阶段,按 hw:architecture 确认的模板创建或校验工程目录、厂商库位置、Core + Function 结构、项目结构契约、时钟契约和存储/型号契约;也可在前期以 scan-existing 只读模式扫描已有 CubeMX/Keil/IAR/CMake/vendor SDK 工程事实。不得作为主流程节点绕过 OpenSpec 创建/修改工程。触发词包括“hw:init”“工程骨架”“项目目录模板”“Core+Function”“scan-existing”“generate-skeleton”。.
aisee:change-author
按当前 schema 的模板,为单个已确认 OpenSpec change 详细生成或补全文档。用于任何 schema 下的 schema-aware authoring:逐文档写清目标、范围、行为、约束、风险、验证和实施顺序,减少开发、评审和验证阶段的误解与漏项。不拆 change 边界、不重新选择 schema、不写代码;只处理 schema 声明的文档并保持跨文档一致。.
aisee:change-plan
将已确认需求、轻量修复、技术调研或项目事实映射为可独立交付的 OpenSpec changes,并为每个 change 选择合适 schema。用于规划 change 边界、依赖顺序、并行关系和 /opsx:new 命令;不重新做业务模块划分,不重新生成需求,不默认套用 app schema。.