Persist durable user corrections and preferences across sessions through a repo-tracked plain-text `feedback.log`. Use when starting a session that should honor prior reusable feedback, or when the user gives durable guidance about workflow, formatting, style, tooling, review expectations, or communication that should apply again later.
Plan commits for all dirty git changes in the current repository. Use when I say `commit-plan`, `commit plan`, `plan to commit all dirty`, `group my dirty changes into commits`, or ask for a safe commit plan without actually committing. Do not use when I explicitly want you to commit or push immediately, rewrite history, or work outside git.
Use this skill when the user wants logo design, brand identity, visual direction, color palette selection, typography pairing, SVG logo concepts, favicon creation, Open Graph assets, or a lightweight brand guide for a product, app, website, startup, or repo. Do not use this skill for general UI implementation unless the task is specifically about brand identity or visual language.
Use when I explicitly want the current intended dirty git worktree committed and pushed now, including requests like `commit dirty`, `commit all dirty`, `commit and push this`, or `ship these changes`, after verifying scope and running the minimum relevant checks. Do not use for commit planning only, history rewrites, force-pushes, or ambiguous mixed diffs.
Commit and push only the git changes dirtied during the current Codex session, while leaving pre-existing dirty work from other sessions uncommitted. Use when I say `commit-session`, `commit session`, `ship this session`, `commit only this Codex session`, or explicitly ask to avoid committing pre-existing or other-session dirty changes. Do not use for commit planning only, all-dirty shipping, history rewrites, or cases where session scope cannot be proven from Codex logs.
Use when handling commit or push requests, refreshing the root README, or changing repo behavior that can make the root README stale, especially when the README needs to sell the repo clearly to recruiters before setup details take over
Use when initializing a LeetCode Python problem from a same-name `.txt` prompt dump and `.py` stub, especially when the goal is to scaffold a local runner and unittest coverage without generating the solution itself.
Use when work in this repo introduces a concrete manual verification step, changes the expected outcome of an existing manual check, or exposes an obvious gap in the shared smoke-test checklist.