Merge e0e8b34203 into bc7f7883c8

Update simplify-code/SKILL.md to introduce parallel review sub-agents and reorganize steps. The doc now: recommends determining the smallest diff command, uses repository local instructions to disambiguate patterns, and adds a Step 2 that launches four Codex sub-agents (Reuse, Quality, Efficiency, Clarity) with guidance on prompts, expected outputs, and recommended roles. It also clarifies aggregation of findings, discarding duplicates/conflicts, renumbers subsequent steps (fixing, validation, summary), and tightens wording about applying only high-confidence, behavior-preserving fixes and not staging/committing changes.

README.md

@@ -11,6 +11,15 @@ This repository contains focused, self-contained skills that help with recurring
 Install: place these skill folders under `$CODEX_HOME/skills`
 
 
+### sk
+
+Install via [sk](https://github.com/803/skills-supply), the universal package manager for AI agent skills (supports Claude, Codex, OpenCode, etc...).
+
+```bash
+sk pkg add github Dimillian/Skills
+sk sync
+```
+
 ## Skills
 
 This repo currently includes 11 skills:

macos-menubar-tuist-app/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: macos-menubar-tuist-app
+description: Build, refactor, or review macOS menubar apps that use Tuist and SwiftUI. Use when creating or maintaining LSUIElement menubar utilities, defining Tuist targets/manifests, implementing model-client-store-view architecture, adding script-based launch flows, or validating reliable local build/run behavior without Xcode-first workflows.
+---
+
+# macos-menubar-tuist-app
+
+Build and maintain macOS menubar apps with a Tuist-first workflow and stable launch scripts. Preserve strict architecture boundaries so networking, state, and UI remain testable and predictable.
+
+## Core Rules
+
+- Keep the app menubar-only unless explicitly told otherwise. Use `LSUIElement = true` by default.
+- Keep transport and decoding logic outside views. Do not call networking from SwiftUI view bodies.
+- Keep state transitions in a store layer (`@Observable` or equivalent), not in row/view presentation code.
+- Keep model decoding resilient to API drift: optional fields, safe fallbacks, and defensive parsing.
+- Treat Tuist manifests as the source of truth. Do not rely on hand-edited generated Xcode artifacts.
+- Prefer script-based launch for local iteration when `tuist run` is unreliable for macOS target/device resolution.
+
+## Expected File Shape
+
+Use this placement by default:
+
+- `Project.swift`: app target, settings, resources, `Info.plist` keys
+- `Sources/*Model*.swift`: API/domain models and decoding
+- `Sources/*Client*.swift`: requests, response mapping, transport concerns
+- `Sources/*Store*.swift`: observable state, refresh policy, filtering, caching
+- `Sources/*Menu*View*.swift`: menu composition and top-level UI state
+- `Sources/*Row*View*.swift`: row rendering and lightweight interactions
+- `run-menubar.sh`: canonical local restart/build/launch path
+- `stop-menubar.sh`: explicit stop helper when needed
+
+## Workflow
+
+1. Confirm Tuist ownership
+- Verify `Tuist.swift` and `Project.swift` (or workspace manifests) exist.
+- Read existing run scripts before changing launch behavior.
+
+2. Probe backend behavior before coding assumptions
+- Use `curl` to verify endpoint shape, auth requirements, and pagination behavior.
+- If endpoint ignores `limit/page`, implement full-list handling with local trimming in the store.
+
+3. Implement layers from bottom to top
+- Define/adjust models first.
+- Add or update client request/decoding logic.
+- Update store refresh, filtering, and cache policy.
+- Wire views last.
+
+4. Keep app wiring minimal
+- Keep app entry focused on scene/menu wiring and dependency injection.
+- Avoid embedding business logic in `App` or menu scene declarations.
+
+5. Standardize launch ergonomics
+- Ensure run script restarts an existing instance before relaunching.
+- Ensure run script does not open Xcode as a side effect.
+- Use `tuist generate --no-open` when generation is required.
+
+## Validation Matrix
+
+Run validations after edits:
+
+```bash
+TUIST_SKIP_UPDATE_CHECK=1 tuist build <TargetName> --configuration Debug
+```
+
+If launch workflow changed:
+
+```bash
+./run-menubar.sh
+```
+
+If shell scripts changed:
+
+```bash
+bash -n run-menubar.sh
+bash -n stop-menubar.sh
+./run-menubar.sh
+```
+
+## Failure Patterns and Fix Direction
+
+- `tuist run` cannot resolve the macOS destination:
+Use run/stop scripts as canonical local run path.
+
+- Menu UI is laggy or inconsistent after refresh:
+Move derived state and filtering into the store; keep views render-only.
+
+- API payload changes break decode:
+Relax model decoding with optional fields and defaults, then surface missing data safely in UI.
+
+- Feature asks for quick UI patch:
+Trace root cause in model/client/store before changing row/menu presentation.
+
+## Completion Checklist
+
+- Preserve menubar-only behavior unless explicitly changed.
+- Keep network and state logic out of SwiftUI view bodies.
+- Keep Tuist manifests and run scripts aligned with actual build/run flow.
+- Run the validation matrix for touched areas.
+- Report concrete commands run and outcomes.

macos-menubar-tuist-app/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "macOS Menubar Tuist App"
+  short_description: "Tuist-first macOS menubar app build and maintenance"
+  default_prompt: "Use $macos-menubar-tuist-app to scaffold or refactor a menubar-only macOS app with Tuist, layered state architecture, and script-based run validation."

orchestrate-batch-refactor/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: "orchestrate-batch-refactor"
+description: "Plan and execute large refactor or rewrite efforts efficiently with parallel multi-agent analysis and implementation. Use when a user asks to refactor many files, split workstreams, analyze a target code area, and coordinate sub-agents with clear ownership and dependency-aware execution."
+---
+
+# Orchestrate Batch Refactor
+
+## Overview
+
+Use this skill to run high-throughput refactors safely.
+Analyze scope in parallel, synthesize a single plan, then execute independent work packets with sub-agents.
+
+## Inputs
+
+- Repo path and target scope (paths, modules, or feature area)
+- Goal type: refactor, rewrite, or hybrid
+- Constraints: behavior parity, API stability, deadlines, test requirements
+
+## When to Use Parallelization
+
+- Use this skill for medium/large scope touching many files or subsystems.
+- Skip multi-agent execution for tiny edits or highly coupled single-file work.
+
+## Core Workflow
+
+1. Define scope and success criteria.
+   - List target paths/modules and non-goals.
+   - State behavior constraints (for example: preserve external behavior).
+2. Run parallel analysis first.
+   - Split target scope into analysis lanes.
+   - Spawn `explorer` sub-agents in parallel to analyze each lane.
+   - Ask each agent for: intent map, coupling risks, candidate work packets, required validations.
+3. Build one dependency-aware plan.
+   - Merge explorer output into a single work graph.
+   - Create work packets with clear file ownership and validation commands.
+   - Sequence packets by dependency level; run only independent packets in parallel.
+4. Execute with worker agents.
+   - Spawn one `worker` per independent packet.
+   - Assign explicit ownership (files/responsibility).
+   - Instruct every worker that they are not alone in the codebase and must ignore unrelated edits.
+5. Integrate and verify.
+   - Review packet outputs, resolve overlaps, and run validation gates.
+   - Run targeted tests per packet, then broader suite for integrated scope.
+6. Report and close.
+   - Summarize packet outcomes, key refactors, conflicts resolved, and residual risks.
+
+## Work Packet Rules
+
+- One owner per file per execution wave.
+- No parallel edits on overlapping file sets.
+- Keep packet goals narrow and measurable.
+- Include explicit done criteria and required checks.
+- Prefer behavior-preserving refactors unless user explicitly requests behavior change.
+
+## Planning Contract
+
+Every packet must include:
+
+1. Packet ID and objective.
+2. Owned files.
+3. Dependencies (none or packet IDs).
+4. Risks and invariants to preserve.
+5. Required checks.
+6. Integration notes for main thread.
+
+Use [`references/work-packet-template.md`](references/work-packet-template.md) for the exact shape.
+
+## Agent Prompting Contract
+
+- Use the prompt templates in [`references/agent-prompt-templates.md`](references/agent-prompt-templates.md).
+- Explorer prompts focus on analysis and decomposition.
+- Worker prompts focus on implementation and validation with strict ownership boundaries.
+
+## Safety Guardrails
+
+- Do not start worker execution before plan synthesis is complete.
+- Do not parallelize across unresolved dependencies.
+- Do not claim completion if any required packet check fails.
+- Stop and re-plan when packet boundaries cause repeated merge conflicts.
+
+## Validation Strategy
+
+Run in this order:
+
+1. Packet-level checks (fast and scoped).
+2. Cross-packet integration checks.
+3. Full project safety checks when scope is broad.
+
+Prefer fast feedback loops, but never skip required behavior checks.

orchestrate-batch-refactor/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Batch Refactor Orchestrator"
+  short_description: "Plan and parallelize large refactors safely."
+  default_prompt: "Use $orchestrate-batch-refactor to analyze target scope, plan parallel workstreams, and execute multi-agent refactors safely."

orchestrate-batch-refactor/references/agent-prompt-templates.md

@@ -0,0 +1,53 @@
+# Agent Prompt Templates
+
+Use these templates when spawning sub-agents.
+
+## Explorer Prompt Template
+
+```
+Analyze the target scope and return decomposition guidance only.
+
+Scope:
+- Paths/modules: <fill>
+- Goal: <refactor|rewrite|hybrid>
+- Constraints: <behavior/API/test constraints>
+
+Return:
+1. Intent map (what each area currently does)
+2. Coupling and dependency risks
+3. Candidate work packets with non-overlapping ownership
+4. Validation commands per packet
+5. Recommended execution order
+```
+
+## Worker Prompt Template
+
+```
+You own this packet and are not alone in the codebase.
+Ignore unrelated edits by others and do not touch files outside ownership.
+
+Packet:
+- ID: <fill>
+- Objective: <fill>
+- Owned files: <fill>
+- Dependencies already completed: <fill>
+- Invariants to preserve: <fill>
+- Required checks: <fill>
+
+Execution requirements:
+1. Implement only the packet objective.
+2. Preserve specified invariants and external behavior.
+3. Run required checks and report exact results.
+4. Summarize changed files and any integration notes.
+```
+
+## Main Thread Synthesis Prompt Template
+
+```
+Merge explorer outputs into a single dependency-aware plan.
+Produce:
+1. Packet table with ownership and dependencies
+2. Parallel execution waves (no overlap per wave)
+3. Validation matrix by packet and integration stage
+4. Risk list with mitigation actions
+```

orchestrate-batch-refactor/references/work-packet-template.md

@@ -0,0 +1,31 @@
+# Work Packet Template
+
+Use this template to define each packet before spawning workers.
+
+## Packet
+
+- `id`:
+- `objective`:
+- `mode`: `refactor` | `rewrite` | `hybrid`
+- `owner_agent_type`: `worker`
+- `owned_files`:
+- `dependencies`:
+- `invariants_to_preserve`:
+- `out_of_scope`:
+- `required_checks`:
+- `integration_notes`:
+- `done_criteria`:
+
+## Example
+
+- `id`: `P3`
+- `objective`: "Extract duplicated parsing logic from thread reducers into shared helper"
+- `mode`: `refactor`
+- `owner_agent_type`: `worker`
+- `owned_files`: `src/features/threads/hooks/threadReducer/*.ts`
+- `dependencies`: `P1`
+- `invariants_to_preserve`: "Thread ordering and hidden-thread filtering behavior"
+- `out_of_scope`: "UI rendering components"
+- `required_checks`: `npm run typecheck`, `npm run test -- src/features/threads/hooks`
+- `integration_notes`: "Main thread verifies no overlapping helper names with existing util package"
+- `done_criteria`: "No duplicated parsing block remains; all required checks pass"

simplify-code/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: simplify-code
+description: "Review a git diff or explicit file scope for reuse, code quality, efficiency, clarity, and standards issues, then optionally apply safe Codex-driven fixes. Use when the user asks to \"simplify code\", \"review changed code\", \"check for code reuse\", \"review code quality\", \"review efficiency\", \"simplify changes\", \"clean up code\", \"refactor changes\", or \"run simplify\"."
+---
+
+# 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.
+
+## 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.