dayfinggg
UserProduction engineering and design skills for OpenAI Codex.
Categories
Indexed Skills (28)
design-project-architecture
Design, assess, or evolve the structure and architecture of new and existing software projects. Use when creating a project, adding or extracting a subsystem, reorganizing modules or directories, clarifying ownership and dependency boundaries, reducing architectural debt, or making components easier to understand, operate, replace, remove, test, and extend; skip isolated changes that do not affect structure or boundaries.
design-ui-ux
Design, implement, or review modern UI/UX for web, mobile, and desktop products. Use when creating or redesigning interfaces, screens, flows, components, design systems, responsive behavior, accessibility, public-web content structure or SEO-aware presentation, or when polishing an existing UI. Preserve product and platform constraints and reject generic AI-generated aesthetics. Skip backend-only changes and frontend work with no visual, content, interaction, or discoverability impact.
spec-to-tasks
Create an evidence-backed implementation plan or decompose an approved specification into executable work with dependencies, decision points, acceptance criteria, and validation evidence. Use when the user asks for a plan or when work spans multiple substantive actions, components, migrations, risks, or independently verifiable stages; skip simple one-step changes.
change-dependencies
Change external libraries, frameworks, SDKs, runtimes, compilers, or build tools with verified compatibility and bounded scope. Use when an authorized change adds, upgrades, downgrades, replaces, or removes a dependency, including CVE remediation. Do not use for internal imports, inventory or advice only, or wholesale stack replacement.
code-review
Review a branch, pull request, commit range, or working-tree diff for actionable correctness, regression, security, performance, and test risks. Use for explicit code or PR review and independent pre-merge quality gates. Do not use when there is no change set to inspect or the task is only to implement a known fix.
codebase-design
Design or improve a known module boundary, interface, seam, dependency, or test surface. Use when implementing a new module, restructuring identified coupling, choosing an interface, or improving concrete testability. Do not use for broad architecture discovery, arbitrary file splitting, formatting, or speculative abstraction.
design-interface
Design, implement, redesign, or visually review production-quality websites, apps, dashboards, flows, pages, and UI components. Use when visual direction, usability, responsive behavior, accessibility, interaction states, information hierarchy, or design-system fit materially affect the result, especially when extending an existing product without breaking its visual language. Do not use for backend-only work, mechanical CSS edits with no design judgment, or non-interface artifacts.
diagnosing-bugs
Use only when a defect's root cause is unknown and requires reproducible investigation, such as a regression, crash, flaky failure, or performance problem. Do not use for an obvious local correction, ordinary feature work, or architecture review; use this instead of TDD until the cause is proven.
handoff
Create a compact, secret-safe continuation brief for another Codex task or engineer. Use only when the user explicitly asks to hand off, compact, transfer, pause and resume, or continue substantial work elsewhere. Do not use for normal final reports, short tasks, or automatic status updates.
improve-codebase-architecture
Audit a codebase for evidence-backed architectural friction and rank bounded improvement candidates before implementation. Use when the user requests an architecture health review or repeated change difficulty spans modules and the boundary is not yet known. Do not use when the interface or refactor is already selected; use codebase-design instead.
migrate-contracts-safely
Evolve a live API, database schema, event, stored format, configuration format, or provider contract while old and new states must coexist. Use for staged compatibility or production-data migrations. Do not use for private atomic refactors, greenfield contracts, one-off repairs, readiness review, or destructive execution without explicit authorization.
plan-task
Create an evidence-grounded, decision-complete implementation plan at the smallest useful level of detail. Use when the user explicitly asks to plan, scope, or break down a complex change, or when unresolved product or architecture decisions block safe implementation. Do not use for obvious one-step work, ordinary explanations, execution of an approved plan, or multi-session ticket creation.
prototype
Build a disposable runnable experiment that resolves one material uncertainty about behavior, state, integration, or interface design. Use when the user requests a prototype, spike, proof of concept, or alternatives, or explicitly authorizes an experiment needed for a decision. Do not use for production delivery, plan-only work, or questions established by existing evidence.
research
Research external, niche, disputed, version-sensitive, or recently changed technical facts using authoritative primary sources and explicit evidence. Use when the user asks to research, compare, verify, or cite, or when an implementation materially depends on current external behavior. Do not use when the repository or a stable fact fully answers the question.
resolving-merge-conflicts
Resolve conflicts in an active Git merge, rebase, cherry-pick, or revert by preserving compatible intent from both sides. Use when Git reports unmerged paths or the user asks to resolve current conflicts. Do not use for ordinary branch comparison, starting integration, rewriting history without conflicts, or aborting unless explicitly requested.
review-production-readiness
Assess and improve go-live readiness for a service, API, worker, migration, infrastructure change, or release. Use for explicit readiness decisions or changes that materially affect capacity, external failures, observability, recovery, deployment, or production data. Do not use for routine implementation, local libraries, ordinary code review, or active incident response.
to-spec
Turn settled requirements, an approved plan, a prototype result, or an issue into a durable implementation-independent specification with testable acceptance criteria and explicit scope. Use when the user asks for a specification, PRD, requirements document, or stable multi-session artifact. Do not use while material product decisions remain unresolved or for simple one-step work.
to-tickets
Break an approved plan, specification, or settled conversation into independently verifiable vertical-slice tasks with acceptance criteria and blocking dependencies. Use when the user asks for tickets, issues, a backlog, or work units for multiple sessions or agents. Do not use before requirements are settled, for simple single-session work, or to publish externally without authorization.
change-review
Review a branch, pull request, commit range, or working-tree diff on two axes: repository standards and the originating requirements. Use for explicit code or PR review, independent pre-merge quality gates, and checking an implementation against its specification. Do not use when there is no change set to inspect or the task is only to implement a known fix.
delegate-work
Delegate bounded work to Codex subagents and coordinate their results with explicit ownership, evidence, and stopping conditions. Use when the user explicitly asks for agents, subagents, delegation, parallel work, or an agent team, or when an applicable repository instruction explicitly requires delegation. Do not use merely because a task is large; keep tightly coupled, sequential, or overlapping work in the main task.
tdd
Develop observable behavior test-first through a verified red-green-refactor cycle. Use for features, bug fixes, regressions, public contracts, and integration behavior when the user requests TDD or repository policy requires it; skip research, prose-only work, disposable spikes, and changes with no testable behavior.
clarify-and-specify
Convert ambiguous, high-impact, or multi-stage requests into an approved specification before implementation. Use when material product, behavior, scope, interface, migration, or acceptance decisions are unresolved; skip small requests whose intended outcome is already explicit.
diagnose-root-cause
Reproduce and isolate the root cause of bugs, regressions, flaky behavior, failures, or unexpected performance. Use when the cause is uncertain and evidence must distinguish symptoms from causes; do not use for straightforward changes with a known cause.
domain-modeling
Discover and refine ubiquitous language, business rules, invariants, ownership, bounded contexts, and justified domain patterns. Use for domain-rich features, conflicting terminology, unclear consistency boundaries, legacy model extraction, or explicit DDD requests; skip simple CRUD, utilities, styling, and generic architecture cleanup.
implement-and-verify
Implement an approved specification, ticket, or explicit production change and prove its acceptance criteria. Use for scoped coding work that requires repository inspection, current technical documentation, complete implementation, and proportionate validation; do not use for review-only requests.
learn-from-history
Derive reviewable agent-skill candidates from repeated successful sessions, corrections, traces, or operational histories. Use when a workflow has recurred and the user wants to preserve evidence-backed procedural knowledge; never install or activate candidates without human approval.
research-current-sources
Research current or time-sensitive claims using authoritative primary sources and dated evidence. Use when a request asks for latest information, exact citations, recent documentation, rules, prices, versions, people, recommendations, or verification of a claim that may have changed.
review-changes
Review a diff, pull request, patch, or completed implementation for material defects and unmet requirements. Use when the user asks for code review, implementation review, risk assessment, or pre-merge validation; remain read-only unless fixes are explicitly requested.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.