dayfinggg
UserDrop-in Agent Skills, subagents, output styles, hooks & config templates for Claude Code (~/.claude) and OpenAI Codex CLI (~/.codex). Copy, restart, done.
Categories
Indexed Skills (16)
change-dependencies
Add, upgrade, downgrade, replace, or remove external libraries, frameworks, SDKs, runtimes, compilers, build tools, or transitive dependencies with bounded scope and verified compatibility. Use when an authorized repository change modifies an external dependency or version, including CVE remediation and framework or runtime migration. Do not use for internal module imports, dependency inventory or upgrade advice without an authorized change, or replacing the whole technology stack.
code-review
Review a branch, pull request, commit range, or working-tree diff for correctness, regressions, security, performance, repository standards, and fidelity to the originating requirements. Use when the user asks for code review, diff review, PR review, pre-merge inspection, validation of changes since a fixed point, or after a substantive implementation needs its final quality gate. Do not use when there is no code change to inspect or when the request is only to implement an already reviewed fix.
codebase-design
Design and improve module boundaries, interfaces, seams, dependencies, and test surfaces so code remains cohesive, understandable, and easy to change. Use when planning or implementing a new module, restructuring coupled code, choosing an interface, improving testability, or reviewing concrete architectural friction. Do not use for formatting, arbitrary file splitting, speculative abstraction, or broad architecture work without an identified change or problem.
design-interface
Design, implement, redesign, or visually review distinctive production-quality digital interfaces. Use for websites, landing pages, web or mobile apps, dashboards, product surfaces, components, and other UI work where visual direction, usability, responsive behavior, accessibility, interaction states, or design-system quality materially affect the result. Do not use for backend-only work, purely mechanical styling changes, or non-interface artifacts with their own dedicated skill.
diagnosing-bugs
Diagnose and fix difficult defects, regressions, intermittent failures, crashes, and performance problems through a reproducible evidence loop. Use when software is broken, failing, flaky, unexpectedly slow, or when the user asks to debug, diagnose, find a root cause, or repair a non-obvious bug. Do not use for obvious local corrections, feature development without a defect, or speculative architecture review.
handoff
Create a compact, secret-safe continuation brief that lets a fresh Codex task or another engineer resume work without reopening settled decisions. Use only when the user explicitly asks to hand off, compact, transfer, pause and resume, or continue substantial work in a new task or session. Do not use for ordinary final reports, short tasks, or automatic progress updates.
improve-codebase-architecture
Assess a codebase for evidence-backed architectural improvements and rank bounded candidates before implementation. Use for an architecture audit or health review, to locate structural bottlenecks, or when repeated change friction spans multiple modules and the boundary to change has not yet been chosen. Do not use for a known interface or seam, an ordinary diff review, or planning or implementing an already selected refactor.
migrate-contracts-safely
Evolve a live external or persisted contract, such as an API, database schema, event or message format, stored or configuration format, externally consumed interface, or production provider boundary, without breaking consumers or data. Use to design or implement a staged compatibility migration when old and new states must coexist, a schema or format migration transforms production data, or producers and consumers cannot change atomically. Do not use for private atomic refactors, greenfield contracts, one-off data repairs, go or no-go rollout reviews, or destructive production execution without explicit authorization.
plan-task
Create evidence-grounded, decision-complete implementation plans for complex coding and technical tasks. Use when the user asks to plan, scope, design an approach, break down a multi-step change, prepare an implementation plan, or when material ambiguity and dependencies should be resolved before coding. Do not use for simple single-step work, ordinary explanations, or execution of an already approved and complete plan.
prototype
Build a disposable, runnable experiment that answers one material design question about behavior, state, integration feasibility, or user interface. Use when the user explicitly requests a prototype, spike, proof of concept, or UI alternatives, or when an authorized implementation task contains an important question that inspection cannot resolve safely. Do not use during plan-only work without explicit permission, for production delivery, or when documentation and existing code already establish the answer.
research
Research technical questions, APIs, libraries, standards, security guidance, compatibility, and current product behavior using authoritative primary sources and explicit evidence. Use when a task depends on external, niche, disputed, version-sensitive, or recently changed facts, or when the user asks to research, compare, verify, or cite technical information. Do not use when the answer is established entirely by the local repository or a simple stable fact.
resolving-merge-conflicts
Resolve conflicts in an in-progress Git merge, rebase, cherry-pick, or revert by reconstructing the intent of both sides and preserving compatible behavior. Use when Git reports unmerged paths or the user asks to inspect or resolve merge conflicts. Do not use for ordinary branch comparison, starting a new integration operation, rewriting history without conflicts, or aborting an operation unless the user explicitly requests it.
review-production-readiness
Review and improve the operational readiness of a service, API, worker, migration, infrastructure change, or release for production rollout. Use when the user asks for a go-live or readiness decision, or when delivering a new production service, public launch, deployment-path change, high-risk data migration, or change that materially affects capacity, external-service failure modes, observability, or recovery. Do not use for local-only libraries, routine implementation or code review without a rollout-readiness objective, contract-migration design, or active incident response.
tdd
Implement features and bug fixes test-first through verified red-green-refactor cycles, one observable behavior at a time. Use when the user requests TDD or red-green-refactor, when a concrete behavior has an appropriate automated test surface, or when a regression must be locked down before a fix. Do not use for exploratory prototypes, generated artifacts, purely mechanical changes, or repositories where introducing tests would exceed the requested scope.
to-spec
Turn an agreed conversation, plan, prototype result, or issue into a durable, implementation-independent specification with testable requirements and explicit scope. Use when the user asks for a specification, PRD, requirements document, acceptance criteria, or a stable artifact for multi-session implementation. Do not use while material product decisions remain unresolved, for a simple one-step change, or to publish externally without explicit authorization.
to-tickets
Break an approved plan, specification, or substantial conversation into independently verifiable vertical-slice tasks with acceptance criteria and explicit blocking dependencies. Use when the user asks to create tickets, issues, implementation tasks, a dependency-aware backlog, or work units for multiple sessions or agents. Do not use before requirements are settled, for a simple single-session change, or to publish or modify an external tracker without explicit authorization.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.