opencode-skills-antigravity 1.0.13 → 1.0.14

package/bundled-skills/project-skill-audit/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: project-skill-audit
+description: Audit a project and recommend the highest-value skills to add or update.
+risk: safe
+source: "Dimillian/Skills (MIT)"
+date_added: "2026-03-25"
+---
+
+# Project Skill Audit
+
+## Overview
+
+Audit the project's real recurring workflows before recommending skills. Prefer evidence from memory, rollout summaries, existing skill folders, and current repo conventions over generic brainstorming.
+
+Recommend updates before new skills when an existing project skill is already close to the needed behavior.
+
+## When to Use
+
+- When the user asks what skills a project needs or which existing skills should be updated.
+- When recommendations should be grounded in project history, memory files, and local conventions.
+
+## Workflow
+
+1. Map the current project surface.
+   Identify the repo root and read the most relevant project guidance first, such as `AGENTS.md`, `README.md`, roadmap/ledger files, and local docs that define workflows or validation expectations.
+
+2. Build the memory/session path first.
+   Resolve the memory base as `$CODEX_HOME` when set, otherwise default to `~/.codex`.
+   Use these locations:
+   - memory index: `$CODEX_HOME/memories/MEMORY.md` or `~/.codex/memories/MEMORY.md`
+   - rollout summaries: `$CODEX_HOME/memories/rollout_summaries/`
+   - raw sessions: `$CODEX_HOME/sessions/` or `~/.codex/sessions/`
+
+3. Read project past sessions in this order.
+   If the runtime prompt already includes a memory summary, start there.
+   Then search `MEMORY.md` for:
+   - repo name
+   - repo basename
+   - current `cwd`
+   - important module or file names
+   Open only the 1-3 most relevant rollout summaries first.
+   Fall back to raw session JSONL only when the summaries are missing the exact evidence you need.
+
+4. Scan existing project-local skills before suggesting anything new.
+   Check these locations relative to the current repo root:
+   - `.agents/skills`
+   - `.codex/skills`
+   - `skills`
+   Read both `SKILL.md` and `agents/openai.yaml` when present.
+
+5. Compare project-local skills against recurring work.
+   Look for repeated patterns in past sessions:
+   - repeated validation sequences
+   - repeated failure shields
+   - recurring ownership boundaries
+   - repeated root-cause categories
+   - workflows that repeatedly require the same repo-specific context
+   If the pattern appears repeatedly and is not already well captured, it is a candidate skill.
+
+6. Separate `new skill` from `update existing skill`.
+   Recommend an update when an existing skill is already the right bucket but has stale triggers, missing guardrails, outdated paths, weak validation instructions, or incomplete scope.
+   Recommend a new skill only when the workflow is distinct enough that stretching an existing skill would make it vague or confusing.
+
+7. Check for overlap with global skills only after reviewing project-local skills.
+   Use `$CODEX_HOME/skills` and `$CODEX_HOME/skills/public` to avoid proposing project-local skills for workflows already solved well by a generic shared skill.
+   Do not reject a project-local skill just because a global skill exists; project-specific guardrails can still justify a local specialization.
+
+## Session Analysis
+
+### 1. Search memory index first
+
+- Search `MEMORY.md` with `rg` using the repo name, basename, and `cwd`.
+- Prefer entries that already cite rollout summaries with the same repo path.
+- Capture:
+  - repeated workflows
+  - validation commands
+  - failure shields
+  - ownership boundaries
+  - milestone or roadmap coupling
+
+### 2. Open targeted rollout summaries
+
+- Open the most relevant summary files under `memories/rollout_summaries/`.
+- Prefer summaries whose filenames, `cwd`, or `keywords` match the current project.
+- Extract:
+  - what the user asked for repeatedly
+  - what steps kept recurring
+  - what broke repeatedly
+  - what commands proved correctness
+  - what project-specific context had to be rediscovered
+
+### 3. Use raw sessions only as a fallback
+
+- Only search `sessions/` JSONL files if rollout summaries are missing a concrete detail.
+- Search by:
+  - exact `cwd`
+  - repo basename
+  - thread ID from a rollout summary
+  - specific file paths or commands
+- Use raw sessions to recover exact prompts, command sequences, diffs, or failure text, not to replace the summary pass.
+
+### 4. Turn session evidence into skill candidates
+
+- A candidate `new skill` should correspond to a repeated workflow, not just a repeated topic.
+- A candidate `skill update` should correspond to a workflow already covered by a local skill whose triggers, guardrails, or validation instructions no longer match the recorded sessions.
+- Prefer concrete evidence such as:
+  - "this validation sequence appeared in 4 sessions"
+  - "this ownership confusion repeated across extractor and runtime fixes"
+  - "the same local script and telemetry probes had to be rediscovered repeatedly"
+
+## Recommendation Rules
+
+- Recommend a new skill when:
+  - the same repo-specific workflow or failure mode appears multiple times across sessions
+  - success depends on project-specific paths, scripts, ownership rules, or validation steps
+  - the workflow benefits from strong defaults or failure shields
+
+- Recommend an update when:
+  - an existing project-local skill already covers most of the need
+  - `SKILL.md` and `agents/openai.yaml` drift from each other
+  - paths, scripts, validation commands, or milestone references are stale
+  - the skill body is too generic to reflect how the project is actually worked on
+
+- Do not recommend a skill when:
+  - the pattern is a one-off bug rather than a reusable workflow
+  - a generic global skill already fits with no meaningful project-specific additions
+  - the workflow has not recurred enough to justify the maintenance cost
+
+## What To Scan
+
+- Past sessions and memory:
+  - memory summary already in context, if any
+  - `$CODEX_HOME/memories/MEMORY.md` or `~/.codex/memories/MEMORY.md`
+  - the 1-3 most relevant rollout summaries for the current repo
+  - raw `$CODEX_HOME/sessions` or `~/.codex/sessions` JSONL files only if summaries are insufficient
+
+- Project-local skill surface:
+  - `./.agents/skills/*/SKILL.md`
+  - `./.agents/skills/*/agents/openai.yaml`
+  - `./.codex/skills/*/SKILL.md`
+  - `./skills/*/SKILL.md`
+
+- Project conventions:
+  - `AGENTS.md`
+  - `README.md`
+  - roadmap, ledger, architecture, or validation docs
+  - current worktree or recent touched areas if needed for context
+
+## Output Expectations
+
+Return a compact audit with:
+
+1. `Existing skills`
+   List the project-local skills found and the main workflow each one covers.
+
+2. `Suggested updates`
+   For each update candidate, include:
+   - skill name
+   - why it is incomplete or stale
+   - the highest-value change to make
+
+3. `Suggested new skills`
+   For each new skill, include:
+   - recommended skill name
+   - why it should exist
+   - what would trigger it
+   - the core workflow it should encode
+
+4. `Priority order`
+   Rank the top recommendations by expected value.
+
+## Naming Guidance
+
+- Prefer short hyphen-case names.
+- Use project prefixes for project-local skills when that improves clarity.
+- Prefer verb-led or action-oriented names over vague nouns.
+
+## Failure Shields
+
+- Do not invent recurring patterns without session or repo evidence.
+- Do not recommend duplicate skills when an update to an existing skill would suffice.
+- Do not rely on a single memory note if the current repo clearly evolved since then.
+- Do not bulk-load all rollout summaries; stay targeted.
+- Do not skip rollout summaries and jump straight to raw sessions unless the summaries are insufficient.
+- Do not recommend skills from themes alone; recommendations should come from repeated procedures, repeated validation flows, or repeated failure modes.
+- Do not confuse a project's current implementation tasks with its reusable skill needs.
+
+## Follow-up
+
+If the user asks to actually create or update one of the recommended skills, switch to [$skill-creator](/Users/dimillian/.codex/skills/.system/skill-creator/SKILL.md) and implement the chosen skill rather than continuing the audit.

package/bundled-skills/project-skill-audit/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Project Skill Audit"
+  short_description: "Audit project sessions and skill coverage"
+  default_prompt: "Use $project-skill-audit to analyze this project and recommend new skills or updates to existing ones."

package/bundled-skills/react-component-performance/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: react-component-performance
+description: Diagnose slow React components and suggest targeted performance fixes.
+risk: safe
+source: "Dimillian/Skills (MIT)"
+date_added: "2026-03-25"
+---
+
+# React Component Performance
+
+## Overview
+
+Identify render hotspots, isolate expensive updates, and apply targeted optimizations without changing UI behavior.
+
+## When to Use
+
+- When the user asks to profile or improve a slow React component.
+- When you need to reduce re-renders, list lag, or expensive render work in React UI.
+
+## Workflow
+
+1. Reproduce or describe the slowdown.
+2. Identify what triggers re-renders (state updates, props churn, effects).
+3. Isolate fast-changing state from heavy subtrees.
+4. Stabilize props and handlers; memoize where it pays off.
+5. Reduce expensive work (computation, DOM size, list length).
+6. **Validate**: open React DevTools Profiler → record the interaction → inspect the Flamegraph for components rendering longer than ~16 ms → compare against a pre-optimization baseline recording.
+
+## Checklist
+
+- Measure: use React DevTools Profiler or log renders; capture baseline.
+- Find churn: identify state updated on a timer, scroll, input, or animation.
+- Split: move ticking state into a child; keep heavy lists static.
+- Memoize: wrap leaf rows with `memo` only when props are stable.
+- Stabilize props: use `useCallback`/`useMemo` for handlers and derived values.
+- Avoid derived work in render: precompute, or compute inside memoized helpers.
+- Control list size: window/virtualize long lists; avoid rendering hidden items.
+- Keys: ensure stable keys; avoid index when order can change.
+- Effects: verify dependency arrays; avoid effects that re-run on every render.
+- Style/layout: watch for expensive layout thrash or large Markdown/diff renders.
+
+## Optimization Patterns
+
+### Isolate ticking state
+
+Move a timer or animation counter into a child so the parent list never re-renders on each tick.
+
+```tsx
+// ❌ Before – entire parent (and list) re-renders every second
+function Dashboard({ items }: { items: Item[] }) {
+  const [tick, setTick] = useState(0);
+  useEffect(() => {
+    const id = setInterval(() => setTick(t => t + 1), 1000);
+    return () => clearInterval(id);
+  }, []);
+  return (
+    <>
+      <Clock tick={tick} />
+      <ExpensiveList items={items} /> {/* re-renders every second */}
+    </>
+  );
+}
+
+// ✅ After – only <Clock> re-renders; list is untouched
+function Clock() {
+  const [tick, setTick] = useState(0);
+  useEffect(() => {
+    const id = setInterval(() => setTick(t => t + 1), 1000);
+    return () => clearInterval(id);
+  }, []);
+  return <span>{tick}s</span>;
+}
+
+function Dashboard({ items }: { items: Item[] }) {
+  return (
+    <>
+      <Clock />
+      <ExpensiveList items={items} />
+    </>
+  );
+}
+```
+
+### Stabilize callbacks with `useCallback` + `memo`
+
+```tsx
+// ❌ Before – new handler reference on every render busts Row memo
+function List({ items }: { items: Item[] }) {
+  const handleClick = (id: string) => console.log(id); // new ref each render
+  return items.map(item => <Row key={item.id} item={item} onClick={handleClick} />);
+}
+
+// ✅ After – stable handler; Row only re-renders when its own item changes
+const Row = memo(({ item, onClick }: RowProps) => (
+  <li onClick={() => onClick(item.id)}>{item.name}</li>
+));
+
+function List({ items }: { items: Item[] }) {
+  const handleClick = useCallback((id: string) => console.log(id), []);
+  return items.map(item => <Row key={item.id} item={item} onClick={handleClick} />);
+}
+```
+
+### Prefer derived data outside render
+
+```tsx
+// ❌ Before – recomputes on every render
+function Summary({ orders }: { orders: Order[] }) {
+  const total = orders.reduce((sum, o) => sum + o.amount, 0); // runs every render
+  return <p>Total: {total}</p>;
+}
+
+// ✅ After – recomputes only when orders changes
+function Summary({ orders }: { orders: Order[] }) {
+  const total = useMemo(() => orders.reduce((sum, o) => sum + o.amount, 0), [orders]);
+  return <p>Total: {total}</p>;
+}
+```
+
+### Additional patterns
+
+- **Split rows**: extract list rows into memoized components with narrow props.
+- **Defer heavy rendering**: lazy-render or collapse expensive content until expanded.
+
+## Profiling Validation Steps
+
+1. Open **React DevTools → Profiler** tab.
+2. Click **Record**, perform the slow interaction, then **Stop**.
+3. Switch to **Flamegraph** view; any bar labeled with a component and time > ~16 ms is a candidate.
+4. Use **Ranked chart** to sort by self render time and target the top offenders.
+5. Apply one optimization at a time, re-record, and compare render counts and durations against the baseline.
+
+## Example Reference
+
+Load `references/examples.md` when the user wants a concrete refactor example.

package/bundled-skills/react-component-performance/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "React Component Performance"
+  short_description: "Profile and fix React render issues"
+  default_prompt: "Use $react-component-performance to analyze and improve this React component's rendering performance."

package/bundled-skills/react-component-performance/references/examples.md

@@ -0,0 +1,88 @@
+# Examples
+
+## Isolate a ticking timer from a long list
+
+**Scenario:** A message list re-renders every second because a timer (`elapsedMs`) lives in the parent component. This causes visible jank on large lists.
+
+**Goal:** Keep UI identical but limit re-renders to the timer area.
+
+**Before (problematic pattern):**
+
+```tsx
+function Messages({ items, isThinking, processingStartedAt }) {
+  const [elapsedMs, setElapsedMs] = useState(0);
+
+  useEffect(() => {
+    if (!isThinking || !processingStartedAt) {
+      setElapsedMs(0);
+      return;
+    }
+    setElapsedMs(Date.now() - processingStartedAt);
+    const interval = window.setInterval(() => {
+      setElapsedMs(Date.now() - processingStartedAt);
+    }, 1000);
+    return () => window.clearInterval(interval);
+  }, [isThinking, processingStartedAt]);
+
+  return (
+    <div>
+      {items.map((item) => (
+        <MessageRow key={item.id} item={item} />
+      ))}
+      <div>{formatDurationMs(elapsedMs)}</div>
+    </div>
+  );
+}
+```
+
+**After (isolated ticking state):**
+
+```tsx
+type WorkingIndicatorProps = {
+  isThinking: boolean;
+  processingStartedAt?: number | null;
+};
+
+const WorkingIndicator = memo(function WorkingIndicator({
+  isThinking,
+  processingStartedAt = null,
+}: WorkingIndicatorProps) {
+  const [elapsedMs, setElapsedMs] = useState(0);
+
+  useEffect(() => {
+    if (!isThinking || !processingStartedAt) {
+      setElapsedMs(0);
+      return;
+    }
+    setElapsedMs(Date.now() - processingStartedAt);
+    const interval = window.setInterval(() => {
+      setElapsedMs(Date.now() - processingStartedAt);
+    }, 1000);
+    return () => window.clearInterval(interval);
+  }, [isThinking, processingStartedAt]);
+
+  return <div>{formatDurationMs(elapsedMs)}</div>;
+});
+
+function Messages({ items, isThinking, processingStartedAt }) {
+  return (
+    <div>
+      {items.map((item) => (
+        <MessageRow key={item.id} item={item} />
+      ))}
+      <WorkingIndicator
+        isThinking={isThinking}
+        processingStartedAt={processingStartedAt}
+      />
+    </div>
+  );
+}
+```
+
+**Why it helps:** Only the `WorkingIndicator` subtree re-renders every second. The list remains stable unless its props change.
+
+**Optional follow-ups:**
+
+- Wrap `MessageRow` in `memo` if props are stable.
+- Use `useCallback` for handlers passed to rows to avoid re-render churn.
+- Consider list virtualization if the list is very large.

package/bundled-skills/simplify-code/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: simplify-code
+description: "Review a diff for clarity and safe simplifications, then optionally apply low-risk fixes."
+risk: safe
+source: "Dimillian/Skills (MIT)"
+date_added: "2026-03-25"
+---
+
+# Simplify Code
+
+Review changed code for reuse, quality, efficiency, and clarity issues. Use Codex sub-agents to review in parallel, then optionally apply only high-confidence, behavior-preserving fixes.
+
+## When to Use
+
+- When the user asks to simplify, clean up, refactor, or review changed code.
+- When you want high-confidence, behavior-preserving improvements on a scoped diff.
+
+## Modes
+
+Choose the mode from the user's request:
+
+- `review-only`: user asks to review, audit, or check the changes
+- `safe-fixes`: user asks to simplify, clean up, or refactor the changes
+- `fix-and-validate`: same as `safe-fixes`, but also run the smallest relevant validation after edits
+
+If the user does not specify, default to:
+
+- `review-only` for "review", "audit", or "check"
+- `safe-fixes` for "simplify", "clean up", or "refactor"
+
+## Step 1: Determine the Scope and Diff Command
+
+Prefer this scope order:
+
+1. Files or paths explicitly named by the user
+2. Current git changes
+3. Files edited earlier in the current Codex turn
+4. Most recently modified tracked files, only if the user asked for a review but there is no diff
+
+If there is no clear scope, stop and say so briefly.
+
+When using git changes, determine the smallest correct diff command based on the repo state:
+
+- unstaged work: `git diff`
+- staged work: `git diff --cached`
+- branch or commit comparison explicitly requested by the user: use that exact diff target
+- mixed staged and unstaged work: review both
+
+Do not assume `git diff HEAD` is the right default when a smaller diff is available.
+
+Before reviewing standards or applying fixes, read the repo's local instruction files and relevant project docs for the touched area. Prefer the closest applicable guidance, such as:
+
+- `AGENTS.md`
+- repo workflow docs
+- architecture or style docs for the touched module
+
+Use those instructions to distinguish real issues from intentional local patterns.
+
+## Step 2: Launch Four Review Sub-Agents in Parallel
+
+Use Codex sub-agents when the scope is large enough for parallel review to help. For a tiny diff or one very small file, it is acceptable to review locally instead.
+
+When spawning sub-agents:
+
+- give each sub-agent the same scope
+- tell each sub-agent to inspect only its assigned review role
+- ask for concise, structured findings only
+- ask each sub-agent to report file, line or symbol, problem, recommended fix, and confidence
+
+Use four review roles.
+
+### Sub-Agent 1: Code Reuse Review
+
+Review the changes for reuse opportunities:
+
+1. Search for existing helpers, utilities, or shared abstractions that already solve the same problem.
+2. Flag duplicated functions or near-duplicate logic introduced in the change.
+3. Flag inline logic that should call an existing helper instead of re-implementing it.
+
+Recommended sub-agent role: `explorer` for broad codebase lookup, or `reviewer` if a stronger review pass is more useful than wide search.
+
+### Sub-Agent 2: Code Quality Review
+
+Review the same changes for code quality issues:
+
+1. Redundant state, cached values, or derived values stored unnecessarily
+2. Parameter sprawl caused by threading new arguments through existing call chains
+3. Copy-paste with slight variation that should become a shared abstraction
+4. Leaky abstractions or ownership violations across module boundaries
+5. Stringly-typed values where existing typed contracts, enums, or constants already exist
+
+Recommended sub-agent role: `reviewer`
+
+### Sub-Agent 3: Efficiency Review
+
+Review the same changes for efficiency issues:
+
+1. Repeated work, duplicate reads, duplicate API calls, or unnecessary recomputation
+2. Sequential work that could safely run concurrently
+3. New work added to startup, render, request, or other hot paths without clear need
+4. Pre-checks for existence when the operation itself can be attempted directly and errors handled
+5. Memory growth, missing cleanup, or listener/subscription leaks
+6. Overly broad reads or scans when the code only needs a subset
+
+Recommended sub-agent role: `reviewer`
+
+### Sub-Agent 4: Clarity and Standards Review
+
+Review the same changes for clarity, local standards, and balance:
+
+1. Violations of local project conventions or module patterns
+2. Unnecessary complexity, deep nesting, weak names, or redundant comments
+3. Overly compact or clever code that reduces readability
+4. Over-simplification that collapses separate concerns into one unclear unit
+5. Dead code, dead abstractions, or indirection without value
+
+Recommended sub-agent role: `reviewer`
+
+Only report issues that materially improve maintainability, correctness, or cost. Do not churn code just to make it look different.
+
+## Step 3: Aggregate Findings
+
+Wait for all review sub-agents to complete, then merge their findings.
+
+Normalize findings into this shape:
+
+1. File and line or nearest symbol
+2. Category: reuse, quality, efficiency, or clarity
+3. Why it is a problem
+4. Recommended fix
+5. Confidence: high, medium, or low
+
+Discard weak, duplicative, or instruction-conflicting findings before editing.
+
+## Step 4: Fix Issues Carefully
+
+In `review-only` mode, stop after reporting findings.
+
+In `safe-fixes` or `fix-and-validate` mode:
+
+- Apply only high-confidence, behavior-preserving fixes
+- Skip subjective refactors that need product or architectural judgment
+- Preserve local patterns when they are intentional or instruction-backed
+- Keep edits scoped to the reviewed files unless a small adjacent change is required to complete the fix correctly
+
+Prefer fixes like:
+
+- replacing duplicated code with an existing helper
+- removing redundant state or dead code
+- simplifying control flow without changing behavior
+- narrowing overly broad operations
+- renaming unclear locals when the scope is contained
+
+Do not stage, commit, or push changes as part of this skill.
+
+## Step 5: Validate When Required
+
+In `fix-and-validate` mode, run the smallest relevant validation for the touched scope after edits.
+
+Examples:
+
+- targeted tests for the touched module
+- typecheck or compile for the touched target
+- formatter or lint check if that is the project's real safety gate
+
+Prefer fast, scoped validation over full-suite runs unless the change breadth justifies more.
+
+If validation is skipped because the user asked not to run it, say so explicitly.
+
+## Step 6: Summarize Outcome
+
+Close with a brief result:
+
+- what was reviewed
+- what was fixed, if anything
+- what was intentionally left alone
+- whether validation ran
+
+If the code is already clean for this rubric, say that directly instead of manufacturing edits.

package/bundled-skills/snowflake-development/SKILL.md

@@ -11,6 +11,11 @@ date_added: "2026-03-24"
 
 You are a Snowflake development expert. Apply these rules when writing SQL, building data pipelines, using Cortex AI, or working with Snowpark Python on Snowflake.
 
+## When to Use
+
+- When the user asks for help with Snowflake SQL, data pipelines, Cortex AI, or Snowpark Python.
+- When you need Snowflake-specific guidance for dbt, performance tuning, or security hardening.
+
 ## SQL Best Practices
 
 ### Naming and Style