@bgicli/bgicli 2.2.8 → 2.2.10

package/data/skills/openai-develop-web-game/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: "develop-web-game"
+description: "Use when Codex is building or iterating on a web game (HTML/JS) and needs a reliable development + testing loop: implement small changes, run a Playwright-based test script with short input bursts and intentional pauses, inspect screenshots/text, and review console errors with render_game_to_text."
+---
+
+
+# Develop Web Game
+
+Build games in small steps and validate every change. Treat each iteration as: implement → act → pause → observe → adjust.
+
+## Skill paths (set once)
+
+```bash
+export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
+export WEB_GAME_CLIENT="$CODEX_HOME/skills/develop-web-game/scripts/web_game_playwright_client.js"
+export WEB_GAME_ACTIONS="$CODEX_HOME/skills/develop-web-game/references/action_payloads.json"
+```
+
+User-scoped skills install under `$CODEX_HOME/skills` (default: `~/.codex/skills`).
+
+## Workflow
+
+1. **Pick a goal.** Define a single feature or behavior to implement.
+2. **Implement small.** Make the smallest change that moves the game forward.
+3. **Ensure integration points.** Provide a single canvas and `window.render_game_to_text` so the test loop can read state.
+4. **Add `window.advanceTime(ms)`.** Strongly prefer a deterministic step hook so the Playwright script can advance frames reliably; without it, automated tests can be flaky.
+5. **Initialize progress.md.** If `progress.md` exists, read it first and confirm the original user prompt is recorded at the top (prefix with `Original prompt:`). Also note any TODOs and suggestions left by the previous agent. If missing, create it and write `Original prompt: <prompt>` at the top before appending updates.
+6. **Verify Playwright availability.** Ensure `playwright` is available (local dependency or global install). If unsure, check `npx` first.
+7. **Run the Playwright test script.** You must run `$WEB_GAME_CLIENT` after each meaningful change; do not invent a new client unless required.
+8. **Use the payload reference.** Base actions on `$WEB_GAME_ACTIONS` to avoid guessing keys.
+9. **Inspect state.** Capture screenshots and text state after each burst.
+10. **Inspect screenshots.** Open the latest screenshot, verify expected visuals, fix any issues, and rerun the script. Repeat until correct.
+11. **Verify controls and state (multi-step focus).** Exhaustively exercise all important interactions. For each, think through the full multi-step sequence it implies (cause → intermediate states → outcome) and verify the entire chain works end-to-end. Confirm `render_game_to_text` reflects the same state shown on screen. If anything is off, fix and rerun.
+    Examples of important interactions: move, jump, shoot/attack, interact/use, select/confirm/cancel in menus, pause/resume, restart, and any special abilities or puzzle actions defined by the request. Multi-step examples: shooting an enemy should reduce its health; when health reaches 0 it should disappear and update the score; collecting a key should unlock a door and allow level progression.
+12. **Check errors.** Review console errors and fix the first new issue before continuing.
+13. **Reset between scenarios.** Avoid cross-test state when validating distinct features.
+14. **Iterate with small deltas.** Change one variable at a time (frames, inputs, timing, positions), then repeat steps 7–13 until stable.
+
+Example command (actions required):
+```
+node "$WEB_GAME_CLIENT" --url http://localhost:5173 --actions-file "$WEB_GAME_ACTIONS" --click-selector "#start-btn" --iterations 3 --pause-ms 250
+```
+
+Example actions (inline JSON):
+```json
+{
+  "steps": [
+    { "buttons": ["left_mouse_button"], "frames": 2, "mouse_x": 120, "mouse_y": 80 },
+    { "buttons": [], "frames": 6 },
+    { "buttons": ["right"], "frames": 8 },
+    { "buttons": ["space"], "frames": 4 }
+  ]
+}
+```
+
+## Test Checklist
+
+Test any new features added for the request and any areas your logic changes could affect. Identify issues, fix them, and re-run the tests to confirm they’re resolved.
+
+Examples of things to test:
+- Primary movement/interaction inputs (e.g., move, jump, shoot, confirm/select).
+- Win/lose or success/fail transitions.
+- Score/health/resource changes.
+- Boundary conditions (collisions, walls, screen edges).
+- Menu/pause/start flow if present.
+- Any special actions tied to the request (powerups, combos, abilities, puzzles, timers).
+
+## Test Artifacts to Review
+
+- Latest screenshots from the Playwright run.
+- Latest `render_game_to_text` JSON output.
+- Console error logs (fix the first new error before continuing).
+You must actually open and visually inspect the latest screenshots after running the Playwright script, not just generate them. Ensure everything that should be visible on screen is actually visible. Go beyond the start screen and capture gameplay screenshots that cover all newly added features. Treat the screenshots as the source of truth; if something is missing, it is missing in the build. If you suspect a headless/WebGL capture issue, rerun the Playwright script in headed mode and re-check. Fix and rerun in a tight loop until the screenshots and text state look correct. Once fixes are verified, re-test all important interactions and controls, confirm they work, and ensure your changes did not introduce regressions. If they did, fix them and rerun everything in a loop until interactions, text state, and controls all work as expected. Be exhaustive in testing controls; broken games are not acceptable.
+
+## Core Game Guidelines
+
+### Canvas + Layout
+- Prefer a single canvas centered in the window.
+
+### Visuals
+- Keep on-screen text minimal; show controls on a start/menu screen rather than overlaying them during play.
+- Avoid overly dark scenes unless the design calls for it. Make key elements easy to see.
+- Draw the background on the canvas itself instead of relying on CSS backgrounds.
+
+### Text State Output (render_game_to_text)
+Expose a `window.render_game_to_text` function that returns a concise JSON string representing the current game state. The text should include enough information to play the game without visuals.
+
+Minimal pattern:
+```js
+function renderGameToText() {
+  const payload = {
+    mode: state.mode,
+    player: { x: state.player.x, y: state.player.y, r: state.player.r },
+    entities: state.entities.map((e) => ({ x: e.x, y: e.y, r: e.r })),
+    score: state.score,
+  };
+  return JSON.stringify(payload);
+}
+window.render_game_to_text = renderGameToText;
+```
+
+Keep the payload succinct and biased toward on-screen/interactive elements. Prefer current, visible entities over full history.
+Include a clear coordinate system note (origin and axis directions), and encode all player-relevant state: player position/velocity, active obstacles/enemies, collectibles, timers/cooldowns, score, and any mode/state flags needed to make correct decisions. Avoid large histories; only include what's currently relevant and visible.
+
+### Time Stepping Hook
+Provide a deterministic time-stepping hook so the Playwright client can advance the game in controlled increments. Expose `window.advanceTime(ms)` (or a thin wrapper that forwards to your game update loop) and have the game loop use it when present.
+The Playwright test script uses this hook to step frames deterministically during automated testing.
+
+Minimal pattern:
+```js
+window.advanceTime = (ms) => {
+  const steps = Math.max(1, Math.round(ms / (1000 / 60)));
+  for (let i = 0; i < steps; i++) update(1 / 60);
+  render();
+};
+```
+
+### Fullscreen Toggle
+- Use a single key (prefer `f`) to toggle fullscreen on/off.
+- Allow `Esc` to exit fullscreen.
+- When fullscreen toggles, resize the canvas/rendering so visuals and input mapping stay correct.
+
+## Progress Tracking
+
+Create a `progress.md` file if it doesn't exist, and append TODOs, notes, gotchas, and loose ends as you go so another agent can pick up seamlessly.
+If a `progress.md` file already exists, read it first, including the original user prompt at the top (you may be continuing another agent's work). Do not overwrite the original prompt; preserve it.
+Update `progress.md` after each meaningful chunk of work (feature added, bug found, test run, or decision made).
+At the end of your work, leave TODOs and suggestions for the next agent in `progress.md`.
+
+## Playwright Prerequisites
+
+- Prefer a local `playwright` dependency if the project already has it.
+- If unsure whether Playwright is available, check for `npx`:
+  ```
+  command -v npx >/dev/null 2>&1
+  ```
+- If `npx` is missing, install Node/npm and then install Playwright globally:
+  ```
+  npm install -g @playwright/mcp@latest
+  ```
+- Do not switch to `@playwright/test` unless explicitly asked; stick to the client script.
+
+## Scripts
+
+- `$WEB_GAME_CLIENT` (installed default: `$CODEX_HOME/skills/develop-web-game/scripts/web_game_playwright_client.js`) — Playwright-based action loop with virtual-time stepping, screenshot capture, and console error buffering. You must pass an action burst via `--actions-file`, `--actions-json`, or `--click`.
+
+## References
+
+- `$WEB_GAME_ACTIONS` (installed default: `$CODEX_HOME/skills/develop-web-game/references/action_payloads.json`) — example action payloads (keyboard + mouse, per-frame capture). Use these to build your burst.

package/data/skills/openai-doc/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: "doc"
+description: "Use when the task involves reading, creating, or editing `.docx` documents, especially when formatting or layout fidelity matters; prefer `python-docx` plus the bundled `scripts/render_docx.py` for visual checks."
+---
+
+
+# DOCX Skill
+
+## When to use
+- Read or review DOCX content where layout matters (tables, diagrams, pagination).
+- Create or edit DOCX files with professional formatting.
+- Validate visual layout before delivery.
+
+## Workflow
+1. Prefer visual review (layout, tables, diagrams).
+   - If `soffice` and `pdftoppm` are available, convert DOCX -> PDF -> PNGs.
+   - Or use `scripts/render_docx.py` (requires `pdf2image` and Poppler).
+   - If these tools are missing, install them or ask the user to review rendered pages locally.
+2. Use `python-docx` for edits and structured creation (headings, styles, tables, lists).
+3. After each meaningful change, re-render and inspect the pages.
+4. If visual review is not possible, extract text with `python-docx` as a fallback and call out layout risk.
+5. Keep intermediate outputs organized and clean up after final approval.
+
+## Temp and output conventions
+- Use `tmp/docs/` for intermediate files; delete when done.
+- Write final artifacts under `output/doc/` when working in this repo.
+- Keep filenames stable and descriptive.
+
+## Dependencies (install if missing)
+Prefer `uv` for dependency management.
+
+Python packages:
+```
+uv pip install python-docx pdf2image
+```
+If `uv` is unavailable:
+```
+python3 -m pip install python-docx pdf2image
+```
+System tools (for rendering):
+```
+# macOS (Homebrew)
+brew install libreoffice poppler
+
+# Ubuntu/Debian
+sudo apt-get install -y libreoffice poppler-utils
+```
+
+If installation isn't possible in this environment, tell the user which dependency is missing and how to install it locally.
+
+## Environment
+No required environment variables.
+
+## Rendering commands
+DOCX -> PDF:
+```
+soffice -env:UserInstallation=file:///tmp/lo_profile_$$ --headless --convert-to pdf --outdir $OUTDIR $INPUT_DOCX
+```
+
+PDF -> PNGs:
+```
+pdftoppm -png $OUTDIR/$BASENAME.pdf $OUTDIR/$BASENAME
+```
+
+Bundled helper:
+```
+python3 scripts/render_docx.py /path/to/file.docx --output_dir /tmp/docx_pages
+```
+
+## Quality expectations
+- Deliver a client-ready document: consistent typography, spacing, margins, and clear hierarchy.
+- Avoid formatting defects: clipped/overlapping text, broken tables, unreadable characters, or default-template styling.
+- Charts, tables, and visuals must be legible in rendered pages with correct alignment.
+- Use ASCII hyphens only. Avoid U+2011 (non-breaking hyphen) and other Unicode dashes.
+- Citations and references must be human-readable; never leave tool tokens or placeholder strings.
+
+## Final checks
+- Re-render and inspect every page at 100% zoom before final delivery.
+- Fix any spacing, alignment, or pagination issues and repeat the render loop.
+- Confirm there are no leftovers (temp files, duplicate renders) unless the user asks to keep them.

package/data/skills/openai-figma/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: figma
+description: Use the Figma MCP server to fetch design context, screenshots, variables, and assets from Figma, and to translate Figma nodes into production code. Trigger when a task involves Figma URLs, node IDs, design-to-code implementation, or Figma MCP setup and troubleshooting.
+---
+
+# Figma MCP
+
+Use the Figma MCP server for Figma-driven implementation. For setup and debugging details (env vars, config, verification), see `references/figma-mcp-config.md`.
+
+## Figma MCP Integration Rules
+These rules define how to translate Figma inputs into code for this project and must be followed for every Figma-driven change.
+
+### Required flow (do not skip)
+1. Run get_design_context first to fetch the structured representation for the exact node(s).
+2. If the response is too large or truncated, run get_metadata to get the high-level node map and then re-fetch only the required node(s) with get_design_context.
+3. Run get_screenshot for a visual reference of the node variant being implemented.
+4. Only after you have both get_design_context and get_screenshot, download any assets needed and start implementation.
+5. Translate the output (usually React + Tailwind) into this project's conventions, styles and framework. Reuse the project's color tokens, components, and typography wherever possible.
+6. Validate against Figma for 1:1 look and behavior before marking complete.
+
+### Implementation rules
+- Treat the Figma MCP output (React + Tailwind) as a representation of design and behavior, not as final code style.
+- Replace Tailwind utility classes with the project's preferred utilities/design-system tokens when applicable.
+- Reuse existing components (e.g., buttons, inputs, typography, icon wrappers) instead of duplicating functionality.
+- Use the project's color system, typography scale, and spacing tokens consistently.
+- Respect existing routing, state management, and data-fetch patterns already adopted in the repo.
+- Strive for 1:1 visual parity with the Figma design. When conflicts arise, prefer design-system tokens and adjust spacing or sizes minimally to match visuals.
+- Validate the final UI against the Figma screenshot for both look and behavior.
+
+### Asset handling
+- The Figma MCP Server provides an assets endpoint which can serve image and SVG assets.
+- IMPORTANT: If the Figma MCP Server returns a localhost source for an image or an SVG, use that image or SVG source directly.
+- IMPORTANT: DO NOT import/add new icon packages, all the assets should be in the Figma payload.
+- IMPORTANT: do NOT use or create placeholders if a localhost source is provided.
+
+### Link-based prompting
+- The server is link-based: copy the Figma frame/layer link and give that URL to the MCP client when asking for implementation help.
+- The client cannot browse the URL but extracts the node ID from the link; always ensure the link points to the exact node/variant you want.
+
+## References
+- `references/figma-mcp-config.md` — setup, verification, troubleshooting, and link-based usage reminders.
+- `references/figma-tools-and-prompts.md` — tool catalog and prompt patterns for selecting frameworks/components and fetching metadata.

package/data/skills/openai-figma-implement-design/SKILL.md

@@ -0,0 +1,264 @@
+---
+name: "figma-implement-design"
+description: "Translate Figma nodes into production-ready code with 1:1 visual fidelity using the Figma MCP workflow (design context, screenshots, assets, and project-convention translation). Trigger when the user provides Figma URLs or node IDs, or asks to implement designs or components that must match Figma specs. Requires a working Figma MCP server connection."
+---
+
+
+# Implement Design
+
+## Overview
+
+This skill provides a structured workflow for translating Figma designs into production-ready code with pixel-perfect accuracy. It ensures consistent integration with the Figma MCP server, proper use of design tokens, and 1:1 visual parity with designs.
+
+## Prerequisites
+
+- Figma MCP server must be connected and accessible
+- User must provide a Figma URL in the format: `https://figma.com/design/:fileKey/:fileName?node-id=1-2`
+  - `:fileKey` is the file key
+  - `1-2` is the node ID (the specific component or frame to implement)
+- **OR** when using `figma-desktop` MCP: User can select a node directly in the Figma desktop app (no URL required)
+- Project should have an established design system or component library (preferred)
+
+## Required Workflow
+
+**Follow these steps in order. Do not skip steps.**
+
+### Step 0: Set up Figma MCP (if not already configured)
+
+If any MCP call fails because Figma MCP is not connected, pause and set it up:
+
+1. Add the Figma MCP:
+   - `codex mcp add figma --url https://mcp.figma.com/mcp`
+2. Enable remote MCP client:
+   - Set `[features].rmcp_client = true` in `config.toml` **or** run `codex --enable rmcp_client`
+3. Log in with OAuth:
+   - `codex mcp login figma`
+
+After successful login, the user will have to restart codex. You should finish your answer and tell them so when they try again they can continue with Step 1.
+
+### Step 1: Get Node ID
+
+#### Option A: Parse from Figma URL
+
+When the user provides a Figma URL, extract the file key and node ID to pass as arguments to MCP tools.
+
+**URL format:** `https://figma.com/design/:fileKey/:fileName?node-id=1-2`
+
+**Extract:**
+
+- **File key:** `:fileKey` (the segment after `/design/`)
+- **Node ID:** `1-2` (the value of the `node-id` query parameter)
+
+**Note:** When using the local desktop MCP (`figma-desktop`), `fileKey` is not passed as a parameter to tool calls. The server automatically uses the currently open file, so only `nodeId` is needed.
+
+**Example:**
+
+- URL: `https://figma.com/design/kL9xQn2VwM8pYrTb4ZcHjF/DesignSystem?node-id=42-15`
+- File key: `kL9xQn2VwM8pYrTb4ZcHjF`
+- Node ID: `42-15`
+
+#### Option B: Use Current Selection from Figma Desktop App (figma-desktop MCP only)
+
+When using the `figma-desktop` MCP and the user has NOT provided a URL, the tools automatically use the currently selected node from the open Figma file in the desktop app.
+
+**Note:** Selection-based prompting only works with the `figma-desktop` MCP server. The remote server requires a link to a frame or layer to extract context. The user must have the Figma desktop app open with a node selected.
+
+### Step 2: Fetch Design Context
+
+Run `get_design_context` with the extracted file key and node ID.
+
+```
+get_design_context(fileKey=":fileKey", nodeId="1-2")
+```
+
+This provides the structured data including:
+
+- Layout properties (Auto Layout, constraints, sizing)
+- Typography specifications
+- Color values and design tokens
+- Component structure and variants
+- Spacing and padding values
+
+**If the response is too large or truncated:**
+
+1. Run `get_metadata(fileKey=":fileKey", nodeId="1-2")` to get the high-level node map
+2. Identify the specific child nodes needed from the metadata
+3. Fetch individual child nodes with `get_design_context(fileKey=":fileKey", nodeId=":childNodeId")`
+
+### Step 3: Capture Visual Reference
+
+Run `get_screenshot` with the same file key and node ID for a visual reference.
+
+```
+get_screenshot(fileKey=":fileKey", nodeId="1-2")
+```
+
+This screenshot serves as the source of truth for visual validation. Keep it accessible throughout implementation.
+
+### Step 4: Download Required Assets
+
+Download any assets (images, icons, SVGs) returned by the Figma MCP server.
+
+**IMPORTANT:** Follow these asset rules:
+
+- If the Figma MCP server returns a `localhost` source for an image or SVG, use that source directly
+- DO NOT import or add new icon packages - all assets should come from the Figma payload
+- DO NOT use or create placeholders if a `localhost` source is provided
+- Assets are served through the Figma MCP server's built-in assets endpoint
+
+### Step 5: Translate to Project Conventions
+
+Translate the Figma output into this project's framework, styles, and conventions.
+
+**Key principles:**
+
+- Treat the Figma MCP output (typically React + Tailwind) as a representation of design and behavior, not as final code style
+- Replace Tailwind utility classes with the project's preferred utilities or design system tokens
+- Reuse existing components (buttons, inputs, typography, icon wrappers) instead of duplicating functionality
+- Use the project's color system, typography scale, and spacing tokens consistently
+- Respect existing routing, state management, and data-fetch patterns
+
+### Step 6: Achieve 1:1 Visual Parity
+
+Strive for pixel-perfect visual parity with the Figma design.
+
+**Guidelines:**
+
+- Prioritize Figma fidelity to match designs exactly
+- Avoid hardcoded values - use design tokens from Figma where available
+- When conflicts arise between design system tokens and Figma specs, prefer design system tokens but adjust spacing or sizes minimally to match visuals
+- Follow WCAG requirements for accessibility
+- Add component documentation as needed
+
+### Step 7: Validate Against Figma
+
+Before marking complete, validate the final UI against the Figma screenshot.
+
+**Validation checklist:**
+
+- [ ] Layout matches (spacing, alignment, sizing)
+- [ ] Typography matches (font, size, weight, line height)
+- [ ] Colors match exactly
+- [ ] Interactive states work as designed (hover, active, disabled)
+- [ ] Responsive behavior follows Figma constraints
+- [ ] Assets render correctly
+- [ ] Accessibility standards met
+
+## Implementation Rules
+
+### Component Organization
+
+- Place UI components in the project's designated design system directory
+- Follow the project's component naming conventions
+- Avoid inline styles unless truly necessary for dynamic values
+
+### Design System Integration
+
+- ALWAYS use components from the project's design system when possible
+- Map Figma design tokens to project design tokens
+- When a matching component exists, extend it rather than creating a new one
+- Document any new components added to the design system
+
+### Code Quality
+
+- Avoid hardcoded values - extract to constants or design tokens
+- Keep components composable and reusable
+- Add TypeScript types for component props
+- Include JSDoc comments for exported components
+
+## Examples
+
+### Example 1: Implementing a Button Component
+
+User says: "Implement this Figma button component: https://figma.com/design/kL9xQn2VwM8pYrTb4ZcHjF/DesignSystem?node-id=42-15"
+
+**Actions:**
+
+1. Parse URL to extract fileKey=`kL9xQn2VwM8pYrTb4ZcHjF` and nodeId=`42-15`
+2. Run `get_design_context(fileKey="kL9xQn2VwM8pYrTb4ZcHjF", nodeId="42-15")`
+3. Run `get_screenshot(fileKey="kL9xQn2VwM8pYrTb4ZcHjF", nodeId="42-15")` for visual reference
+4. Download any button icons from the assets endpoint
+5. Check if project has existing button component
+6. If yes, extend it with new variant; if no, create new component using project conventions
+7. Map Figma colors to project design tokens (e.g., `primary-500`, `primary-hover`)
+8. Validate against screenshot for padding, border radius, typography
+
+**Result:** Button component matching Figma design, integrated with project design system.
+
+### Example 2: Building a Dashboard Layout
+
+User says: "Build this dashboard: https://figma.com/design/pR8mNv5KqXzGwY2JtCfL4D/Dashboard?node-id=10-5"
+
+**Actions:**
+
+1. Parse URL to extract fileKey=`pR8mNv5KqXzGwY2JtCfL4D` and nodeId=`10-5`
+2. Run `get_metadata(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId="10-5")` to understand the page structure
+3. Identify main sections from metadata (header, sidebar, content area, cards) and their child node IDs
+4. Run `get_design_context(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId=":childNodeId")` for each major section
+5. Run `get_screenshot(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId="10-5")` for the full page
+6. Download all assets (logos, icons, charts)
+7. Build layout using project's layout primitives
+8. Implement each section using existing components where possible
+9. Validate responsive behavior against Figma constraints
+
+**Result:** Complete dashboard matching Figma design with responsive layout.
+
+## Best Practices
+
+### Always Start with Context
+
+Never implement based on assumptions. Always fetch `get_design_context` and `get_screenshot` first.
+
+### Incremental Validation
+
+Validate frequently during implementation, not just at the end. This catches issues early.
+
+### Document Deviations
+
+If you must deviate from the Figma design (e.g., for accessibility or technical constraints), document why in code comments.
+
+### Reuse Over Recreation
+
+Always check for existing components before creating new ones. Consistency across the codebase is more important than exact Figma replication.
+
+### Design System First
+
+When in doubt, prefer the project's design system patterns over literal Figma translation.
+
+## Common Issues and Solutions
+
+### Issue: Figma output is truncated
+
+**Cause:** The design is too complex or has too many nested layers to return in a single response.
+**Solution:** Use `get_metadata` to get the node structure, then fetch specific nodes individually with `get_design_context`.
+
+### Issue: Design doesn't match after implementation
+
+**Cause:** Visual discrepancies between the implemented code and the original Figma design.
+**Solution:** Compare side-by-side with the screenshot from Step 3. Check spacing, colors, and typography values in the design context data.
+
+### Issue: Assets not loading
+
+**Cause:** The Figma MCP server's assets endpoint is not accessible or the URLs are being modified.
+**Solution:** Verify the Figma MCP server's assets endpoint is accessible. The server serves assets at `localhost` URLs. Use these directly without modification.
+
+### Issue: Design token values differ from Figma
+
+**Cause:** The project's design system tokens have different values than those specified in the Figma design.
+**Solution:** When project tokens differ from Figma values, prefer project tokens for consistency but adjust spacing/sizing to maintain visual fidelity.
+
+## Understanding Design Implementation
+
+The Figma implementation workflow establishes a reliable process for translating designs to code:
+
+**For designers:** Confidence that implementations will match their designs with pixel-perfect accuracy.
+**For developers:** A structured approach that eliminates guesswork and reduces back-and-forth revisions.
+**For teams:** Consistent, high-quality implementations that maintain design system integrity.
+
+By following this workflow, you ensure that every Figma design is implemented with the same level of care and attention to detail.
+
+## Additional Resources
+
+- [Figma MCP Server Documentation](https://developers.figma.com/docs/figma-mcp-server/)
+- [Figma MCP Server Tools and Prompts](https://developers.figma.com/docs/figma-mcp-server/tools-and-prompts/)
+- [Figma Variables and Design Tokens](https://help.figma.com/hc/en-us/articles/15339657135383-Guide-to-variables-in-Figma)

package/data/skills/openai-gh-address-comments/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: gh-address-comments
+description: Help address review/issue comments on the open GitHub PR for the current branch using gh CLI; verify gh auth first and prompt the user to authenticate if not logged in.
+metadata:
+  short-description: Address comments in a GitHub PR review
+---
+
+# PR Comment Handler
+
+Guide to find the open PR for the current branch and address its comments with gh CLI. Run all `gh` commands with elevated network access.
+
+Prereq: ensure `gh` is authenticated (for example, run `gh auth login` once), then run `gh auth status` with escalated permissions (include workflow/repo scopes) so `gh` commands succeed. If sandboxing blocks `gh auth status`, rerun it with `sandbox_permissions=require_escalated`.
+
+## 1) Inspect comments needing attention
+- Run scripts/fetch_comments.py which will print out all the comments and review threads on the PR
+
+## 2) Ask the user for clarification
+- Number all the review threads and comments and provide a short summary of what would be required to apply a fix for it
+- Ask the user which numbered comments should be addressed
+
+## 3) If user chooses comments
+- Apply fixes for the selected comments
+
+Notes:
+- If gh hits auth/rate issues mid-run, prompt the user to re-authenticate with `gh auth login`, then retry.

package/data/skills/openai-gh-fix-ci/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: "gh-fix-ci"
+description: "Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL."
+---
+
+
+# Gh Pr Checks Plan Fix
+
+## Overview
+
+Use gh to locate failing PR checks, fetch GitHub Actions logs for actionable failures, summarize the failure snippet, then propose a fix plan and implement after explicit approval.
+- If a plan-oriented skill (for example `create-plan`) is available, use it; otherwise draft a concise plan inline and request approval before implementing.
+
+Prereq: authenticate with the standard GitHub CLI once (for example, run `gh auth login`), then confirm with `gh auth status` (repo + workflow scopes are typically required).
+
+## Inputs
+
+- `repo`: path inside the repo (default `.`)
+- `pr`: PR number or URL (optional; defaults to current branch PR)
+- `gh` authentication for the repo host
+
+## Quick start
+
+- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"`
+- Add `--json` if you want machine-friendly output for summarization.
+
+## Workflow
+
+1. Verify gh authentication.
+   - Run `gh auth status` in the repo.
+   - If unauthenticated, ask the user to run `gh auth login` (ensuring repo + workflow scopes) before proceeding.
+2. Resolve the PR.
+   - Prefer the current branch PR: `gh pr view --json number,url`.
+   - If the user provides a PR number or URL, use that directly.
+3. Inspect failing checks (GitHub Actions only).
+   - Preferred: run the bundled script (handles gh field drift and job-log fallbacks):
+     - `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"`
+     - Add `--json` for machine-friendly output.
+   - Manual fallback:
+     - `gh pr checks <pr> --json name,state,bucket,link,startedAt,completedAt,workflow`
+       - If a field is rejected, rerun with the available fields reported by `gh`.
+     - For each failing check, extract the run id from `detailsUrl` and run:
+       - `gh run view <run_id> --json name,workflowName,conclusion,status,url,event,headBranch,headSha`
+       - `gh run view <run_id> --log`
+     - If the run log says it is still in progress, fetch job logs directly:
+       - `gh api "/repos/<owner>/<repo>/actions/jobs/<job_id>/logs" > "<path>"`
+4. Scope non-GitHub Actions checks.
+   - If `detailsUrl` is not a GitHub Actions run, label it as external and only report the URL.
+   - Do not attempt Buildkite or other providers; keep the workflow lean.
+5. Summarize failures for the user.
+   - Provide the failing check name, run URL (if any), and a concise log snippet.
+   - Call out missing logs explicitly.
+6. Create a plan.
+   - Use the `create-plan` skill to draft a concise plan and request approval.
+7. Implement after approval.
+   - Apply the approved plan, summarize diffs/tests, and ask about opening a PR.
+8. Recheck status.
+   - After changes, suggest re-running the relevant tests and `gh pr checks` to confirm.
+
+## Bundled Resources
+
+### scripts/inspect_pr_checks.py
+
+Fetch failing PR checks, pull GitHub Actions logs, and extract a failure snippet. Exits non-zero when failures remain so it can be used in automation.
+
+Usage examples:
+- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "123"`
+- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "https://github.com/org/repo/pull/123" --json`
+- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --max-lines 200 --context 40`