PatrickJS

I use kind mostly out of compiler/TypeScript habit, not because it is objectively better.

In TypeScript, both of these are normal discriminants:

type Route =
  | { type: 'mount'; path: string }
  | { type: 'app'; name: string };

PatrickJS

GitHub-Native npm Preview Packages

This gist is a copyable bundle for repos that want npm for stable releases and GitHub Packages for PR/main preview packages.

TL;DR

• This is not a custom registry. It uses npm for public stable releases and GitHub Packages for private or repo-scoped snapshots.
• Copy the workflow templates into .github/workflows/, add a scoped package name, and configure package auth.
• Every same-repo PR publishes an immutable GitHub Packages version for the PR head SHA and moves a convenient pr-<number> dist-tag.
• Every main push publishes an immutable GitHub Packages snapshot and moves the main dist-tag.

PatrickJS

You are a Codex /goal prompt builder.

Turn the user’s rough task into one clean, executable /goal command for Codex.

Codex Goals are persistent, thread-scoped objectives for long-running work that should continue across turns until a verifiable stopping condition is reached. A good Goal defines the desired outcome, verification surface, constraints, boundaries, iteration policy, and blocked stop condition. 

/goal supports setting an objective with /goal , viewing the current goal with /goal, and lifecycle controls with /goal pause, /goal resume, and /goal clear. Goal objectives must be non-empty and at most 4,000 characters; if the instructions are longer, write the detailed plan into a file and point the Goal at that file. 

Build the Goal using this structure:

PatrickJS

Assume the user’s first message is a rough draft prompt that needs to be rewritten, refined, structured, or optimized for AI tools such as Cursor, ChatGPT, Claude, or coding agents.

Your role:

• Rewrite messy, incomplete, or rambling prompts into clean, high-signal prompts.
• Preserve the user’s actual intent, tone, and technical requirements.
• Improve clarity, structure, formatting, and instruction ordering.
• Remove redundant wording and ambiguity.
• Add missing structure only when it improves execution quality.
• Prefer concise prompts over bloated prompts.
• Keep prompts practical and directly usable.

PatrickJS

name

subagent-worktrees

description

Use when the user explicitly asks for subagents, delegation, parallel agents, or same-turn parallel execution, and the work can be split into bounded independent tasks with disjoint file ownership. Coordinates subagents working in isolated worktrees or branches, then collects their outputs for root-chat review. Prefer this for short, parallelizable implementation or investigation slices, not durable long-running goals that need resumable child chats.

Subagent Worktrees

Overview

Coordinate explicit subagent work across isolated worktrees or branches for bounded parallel tasks. The root chat decomposes the work, assigns disjoint ownership, lets subagents run independently, then reviews and integrates their results.

PatrickJS

name

root-chat-multitask

description

Use when a root Codex chat should manage a long-running or multi-slice coding goal across background chats, existing thread IDs, branches, or worktrees. Best for durable projects that need resumable coordination, child chat steering, progress polling, handoffs, staged integration, or final merge/review by the root chat. Prefer this over subagents for goals that may span hours, days, multiple resumes, usage-budget pauses, or multiple independent implementation slices.

Root Chat Multitask

Overview

Coordinate long-running work from the current root chat while delegating bounded slices to background chats and isolated worktrees. The root chat owns scope, state, child-chat prompts, progress review, integration, and final merge decisions.

PatrickJS

name	architecture-review-plan
description	Use when reviewing software architecture and producing a bounded refactor plan without editing files, especially for repo or module boundaries, folder structure, domain logic placement, layering, or state/lifecycle/side-effect ownership.

Architecture Review Plan

Overview

Review software architecture against the system goal, then produce a concrete refactor plan. This is a review-only skill: inspect, assess, and plan; do not edit files or apply patches.

PatrickJS

name	architecture-refactor-review
description	Use when reviewing software architecture, making a bounded refactor plan, then implementing the plan across repo/module boundaries, folder structure, domain logic placement, layering, or state/lifecycle/side-effect ownership.

Architecture Refactor

Overview

Review, plan, and refactor software architecture against the system goal, with emphasis on file and folder structure, separation of concerns, domain boundaries, layering, and ownership of state, lifecycle, orchestration, caching, retries, and side effects.

PatrickJS

Deeper StyleX integration should look like a compiler feature, not a runtime styling dependency.

The right model is:

tsx source
  -> parse framework graph
  -> parse StyleX calls
  -> validate static style facts
 -> merge styles into chunk/route/component plan

PatrickJS

Review With Engineer Lenses

This gist packages a Codex skill for reviewing developer-facing work through four internal lenses:

• jr-engineer
• sr-engineer
• platform-engineer
• ai-agent

Use it for API changes, API design, technical docs, developer experience, release readiness, and repo-change reviews.