Codex 工程類 Use Case 技能。涵蓋投影片生成、PR 審查、 程式碼庫上手、API 遷移等工作流。觸發條件：當需要使用 Codex 進行程式碼審查、文件生成、程式碼庫導覽、API 升級時啟用。
工程類是 Codex Use Cases 中最豐富的分類，包含 4 個 use case， 覆蓋從簡報自動生成到 API 遷移的廣泛場景。
本分類包含：
| 步驟 | 動作 | 說明 |
|---|---|---|
| 1 | 檢查現有簡報 | 若更新現有 deck，先讀取結構 |
| 2 | 規劃內容 | 大綱、敘事結構 |
| 3 | 生成視覺素材 | 使用 $imagegen |
| 4 | 建構 deck | PptxGenJS 可編輯格式 |
| 5 | 逐頁審查 | 視覺確認 |
Role: You are a presentation designer creating professional slide decks.
Context: Creating a {{deck_type}} presentation about "{{topic}}" with {{slide_count}} slides.
Task:
1. If updating an existing deck:
- Read the source file and identify the current structure.
- Note the design system (colors, fonts, layout patterns).
2. Plan the narrative:
- Outline slide structure: title → problem → solution → evidence → CTA.
- Write speaker notes for each slide.
3. Generate visual assets:
- Use $imagegen for hero images, diagrams, icons.
- Ensure consistent style across all generated assets.
4. Build the deck:
- Use PptxGenJS for editable .pptx output.
- Apply consistent typography: title (32pt), subtitle (24pt), body (18pt).
- Use a 3-color palette maximum + neutrals.
5. Review every slide — check alignment, text overflow, image quality.
Constraints:
- Maximum 6 bullet points per slide, 8 words per bullet.
- Every slide must have a clear takeaway.
- Charts/graphs must have labeled axes and legends.
- Minimum font size: 14pt.
Output Format:
- `presentation.pptx` — editable PowerPoint file.
- `slides_preview/` — PNG exports of each slide for quick review.
- `speaker_notes.md` — all speaker notes in one document.
Self-Verification:
Export each slide as PNG and visually review.
Confirm: no text overflow, consistent styling, all images render.
| 步驟 | 動作 | 說明 |
|---|---|---|
| 1 | 在 PR 中 @codex | 觸發自動審查 |
| 2 | 安全審查 | 檢查 OWASP Top 10 |
| 3 | 測試審查 | 缺失覆蓋、寬鬆斷言 |
| 4 | 行為變更 | API 合約、效能、錯誤處理 |
| 5 | 自動修復 | @codex fix it |
@codex Review this PR with the following focus areas:
1. **Security** (P0 — must fix before merge):
- SQL injection, XSS, CSRF vulnerabilities
- Hardcoded secrets or credentials
- Authentication/authorization bypass risks
2. **Testing** (P1 — should fix):
- Missing test coverage for new code paths
- Edge cases not covered by existing tests
- Test assertions that are too loose
3. **Behavior Changes** (P1 — needs discussion):
- Breaking API contract changes
- Performance regressions (O(n) → O(n²))
- Silently changed error handling
4. **Code Quality** (Informational):
- Dead code or unused imports
- Naming clarity and consistency
- Unnecessary complexity
Format each finding as:
- **[P0/P1/Info] file:line** — description + suggested fix
# Review Guidelines
Classify every comment as one of:
- P0 — Security or correctness issue; must fix before merge
- P1 — Missing test or risky behavior change
- Informational — Style, naming, minor improvement
Always explain the risk, not just the rule it violates.
If unsure about a change, surface it as a question, not a demand.
@codex fix it 會套用所有建議的修復| 步驟 | 動作 | 說明 |
|---|---|---|
| 1 | 指定系統區域 | 明確想了解的範圍 |
| 2 | 請求流程追蹤 | 從入口到資料層 |
| 3 | 模組所有權 | 誰負責什麼 |
| 4 | 驗證點 | 數據在哪裡被驗證 |
| 5 | 陷阱清單 | 修改前須知 |
| 6 | 推薦閱讀 | 接下來該看的檔案 |
Role: You are a senior engineer onboarding a new team member to this codebase.
Context: Explaining how {{system_area}} works in this project.
Task:
1. Request Flow Trace:
- Starting from the entry point (HTTP handler / event listener / CLI command).
- Trace through middleware, validation, business logic, data access.
- Show the complete happy-path flow with file:line references.
2. Module Ownership Map:
- Which directories/files own which responsibilities.
- Key interfaces and contracts between modules.
- External dependencies (databases, APIs, message queues).
3. Data Validation Points:
- Where input is first validated.
- Where business rules are enforced.
- Where data is sanitized before storage.
4. Gotchas & Tribal Knowledge:
- Non-obvious side effects or implicit dependencies.
- Performance-sensitive code paths.
- Areas with tech debt or known issues.
5. Next Steps:
- Top 5 files to read first (with brief reason for each).
- Key tests to run to verify understanding.
- Related documentation or ADRs.
Output Format: Markdown with sections for each task area.
| 步驟 | 動作 | 說明 |
|---|---|---|
| 1 | 清點 | 盤點現有模型、端點、SDK 版本 |
| 2 | 規劃 | 最小遷移路徑 |
| 3 | 執行 | 更新模型、prompt、工具 schema |
| 4 | 驗證 | 測試套件 + 品質對比 |
Role: You are an API migration specialist upgrading OpenAI integrations.
Context: Migrating this project from {{current_model}} to {{target_model}}.
Task:
1. Inventory (do NOT change code yet):
- List all files using OpenAI APIs with: model name, endpoint, SDK version.
- Map tool/function definitions and their schemas.
- Document current prompt patterns and response parsing logic.
- Output: `migration_inventory.md`.
2. Migration Plan:
- Fetch latest model guidance using $openai-docs skill.
- Identify breaking changes: API shape, model behavior, token limits.
- Propose the minimal migration path.
- Output: `migration_plan.md` with risk assessment.
3. Execute Migration (after plan approval):
- Update model references.
- Adapt prompts per latest model prompt guidance.
- Update tool schemas if API format changed.
- Preserve all existing behavior unless migration requires changes.
4. Validate:
- Run existing test suite — all tests must pass.
- Compare output quality on 3 representative inputs.
- Check token usage and latency changes.
Output: migration_inventory.md, migration_plan.md, migration_report.md.
可以。常見組合：
所有工程團隊都適用。QA 團隊特別適合 github-code-reviews。
| 技術 | 用途 | 相關 Use Case |
|---|---|---|
| PptxGenJS | 投影片生成 | generate-slide-decks |
| GitHub | PR 審查 | github-code-reviews |
| OpenAI API | API 整合 | api-integration-migrations |
| $openai-docs | 文件查閱 | api-integration-migrations |