메뉴
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).
