菜单
Give a capable engineer a concise briefing on the critical facts and implications of an effort before it is built or after it is completed. Use when the human explicitly invokes $facts, and never otherwise; do not invoke this skill automatically.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Restate the last message in plain human language, with no jargon.
Vendor skills from a GitHub repository into this repo. Use when asked to import, vendor, list, add, or update skills from another skills repository while preserving provenance and detecting local edits.
Use when given a well-scoped bug fix or small feature ticket from Jira. Investigates the ticket, researches the codebase, proposes a fix, then plans and implements on approval. Lighter alternative to the full deep-work pipeline for tickets that don't need multi-session design discussion.
Use when starting work on a ticket that needs refinement before entering the deep-work pipeline. Reads from Jira, pasted text, or a file, then interactively refines it into a structured ticket.md.
Use when a session is ending and you want to analyze process efficiency. Triggers on requests to review how a session went, evaluate context usage, or identify workflow improvements.
Load this skill before calling the `execute` tool. Teaches the Executor sandbox calling model: discover with `tools.search({ query, limit })`, inspect with `tools.describe.tool({ path })`, list sources with `tools.executor.sources.list({})`, then call the real tool by its full address. Use for SaaS APIs, remote systems, MCP/OpenAPI/GraphQL integrations, and auth/approval-managed actions.
| name | facts |
| description | Give a capable engineer a concise briefing on the critical facts and implications of an effort before it is built or after it is completed. Use when the human explicitly invokes $facts, and never otherwise; do not invoke this skill automatically. |
| disable-model-invocation | true |
What are the most important facts I should know about what we plan to build (or after if already built). Instead of an exhaustive list, list only the most critical things with implications across any existing part of the system or future part - for development but also end use. Assume I am new here, but am a capable engineer: write without any jargon, and with as minimal verbosity as possible (concise but coherent).
