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/security-scannpx skills add PacificStudio/openase --skill security-scangit 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.00021 | $0.00687 |
| Opus 5 | $0.00010 | $0.00344 |
| Sonnet 5 | $0.00004 | $0.00137 |
| Haiku 4.5 | $0.00002 | $0.00069 |
Grade A, and why
security-scan 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.
How it starts
The opening of the file, as written. The whole thing — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Security Scan
Overview
Conduct a security-focused review of the code or change set. Map trust boundaries first, then inspect how untrusted input, credentials, permissions, dependencies, and deployment defaults are handled.
When To Use
- After adding or changing authentication or authorization logic.
- After adding new API endpoints, uploads, background jobs, or external integrations.
- Before production deployment.
- When the change handles untrusted input, secrets, tokens, files, or network calls.
- When the user explicitly requests a security review or audit.
Review Workflow
-
Map the attack surface.
- Entry points, user-controlled input, file access, network access, storage boundaries, and privileged operations.
-
Review authentication and authorization.
- Authentication bypasses.
- Missing authorization checks.
- Confused trust boundaries between user, service, and admin actions.
-
Review input handling and injection surfaces.
- SQL, NoSQL, shell, template, and path injection.
- XSS and unsafe HTML rendering.
- SSRF, open redirects, and unsafe outbound requests.
-
Review secrets and cryptography.
- Hardcoded keys, tokens, passwords, or connection strings.
- Weak password hashing or unsafe token generation.
- Sensitive data exposure in logs, errors, or client payloads.
-
Review dependency and configuration risk.
- Known vulnerable dependencies.
- Overly permissive defaults.
- Missing secure headers, unsafe CORS, or weak production settings.
-
Review detection and recovery.
- Are important security-relevant failures logged?
- Would an operator be able to detect abuse or investigate an incident?
-
Report severity-rated findings with remediation guidance.
CRITICAL: exploitable issue or active secret exposure; block deployment.HIGH: serious vulnerability or major trust-boundary weakness; fix before release.MEDIUM: meaningful hardening gap or partial control failure.LOW: defense-in-depth improvement or cleanup.
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 · 81 lines · 21 tokens per session scan A 63138340a990
security-scan is a skill published in the GitHub repository PacificStudio/openase (265 stars, last pushed 24d ago), licensed Apache-2.0. It adds 21 tokens to every session and 687 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
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 内容,但不要写成接口设计、数据库设计、技术方案、视觉设计、硬件架构、固件设计或开发任务。.
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。.
aisee:image-object
对象级图片处理与素材提取工作流。用于从单张图片中分离对象、基于图片提取素材、去背景、生成或修正 mask、点选/框选分割、透明切图、导出带背景/圆角/padding 的素材变体、背景修补、生成图层包和维护单图 source.json workspace 时触发。不要用于参考图生成、StyleSpec、全局视觉规范、Figma 写入或前端实现。.
aisee:reflect
复盘当前会话并把可复用经验沉淀为项目内可审查资产。用于会话结束复盘、总结“这次学到了什么”、提炼团队约定、发现可转成新 skill 的重复流程、审查现有 skill 的缺口、记录 workflow fix,或用户明确说 reflect、aisee:reflect、aisee-reflect、复盘、沉淀、保存经验、转成技能、优化技能、总结本次协作时触发。长会话中如果出现多轮纠错、重复工具链、稳定偏好或可复用流程,也应主动建议使用本技能。.