codex-skills

Plugin codex-skills from marketplace skills in ghafarallahi/SKILLS. Commands read from the repo's manifest — 1 month ago.

Skills (18)

• ci-verify

  Run the checks that the pipeline runs, before you push. Read the checks from the CI configuration. Run them against the commit that you will push. Divide new failures from failures that exist already. Use before a push or a pull request, when CI fails, or for "will this pass CI".

• code-comments

  Write comments that give the reason and the constraint that the code cannot show. Update a comment in the same commit as the code. Use when you add or review comments, when you write a docstring for a public interface, or when you decide if code needs an explanation.

• codex-check

  Send the work to the Codex CLI for an independent review before you report the work as complete. Use after a file change, after a command that is not trivial, and before you say that a task is done. Also use for "/codex-check", "codex check", "confirm with codex", "have codex verify".

• commit-message

  Write a commit message from the staged diff. Use an imperative subject and a body that gives the reason. Do not write a claim that you cannot support. Use when you commit, for "write a commit message", "commit this", or when you correct a message.

• context-budget

  Read the smallest amount of data that answers the question. Search before you read. Do not read a file two times. Use when a task needs many files, when a repository is large, or when the user asks to reduce token use.

• design-decision

  Before code with a structural choice, write the decision - the alternatives, the trade-offs, and the constraint that decides. Surface it to the user before you code. Use before a new feature, a new integration, a new library, a new data model, or a new protocol, and for "which approach", "how should

• manager

  Manage a project as the coordinator model. Divide the work into small tasks. Send each task to the least expensive model that can do it correctly. Verify each result yourself, then notify the user when the whole is ready for their final test. Use for each project or feature with more than one part,

• minimal-code

  Write the least code that does the task correctly. Use what exists before you write new code - the project, the standard library, the platform. Mark each intentional limit with a ceiling comment. Use when you write, design, or review code, select a library or dependency, and for "simplest solution",

• pr-description

  Write a pull request description for the reviewer. Give the reason, the location to start reading, the verification, and the work that is not in the request. Use when you open a pull request, write a pull request body, or summarize a branch.

• refactor

  Change the structure of code and keep the behavior. Get a test that passes before you start. Keep the tests passing between each step. Do not put a refactor and a correction in one commit. Use for "refactor", "clean up", "restructure", "extract", "simplify", "remove duplication".

• release

  Release a version safely. Know the content, select the version number correctly, sequence the migrations so that you can reverse them, set the stop conditions before you start, and verify the result in production. Use when you make a release, a tag, a changelog, a migration, or a deployment.

• review-changes

  Review a diff for defects that cause a failure: incorrect results, data loss, security faults, and race conditions. Verify each finding against the code before you report it. Use for "review this", "review my changes", "is this correct", or before a pull request.

• root-cause

  Find the line where the behavior of the code and your model of the code become different. Then correct the cause, not the symptom. Use when code fails, stops, or gives a different result each time, and for "debug this", "why does this fail".

• security-audit

  Examine code that you have permission to examine. Look at the trust boundaries, the injection points, the authorization, the secrets, and the dependencies. Report each finding with an attack path. Use for "is this safe", "any vulnerabilities here", "check this for security issues".

• target

  Divide a task into small steps. Ask all the questions in one group. Then do all the steps to the end with no interruption. Use for "/target", "go to the end", "run it to the end", "do not stop and ask me", "do the whole thing".

• verify-api

  Verify an interface against the installed system before you write a call to it. Read the lock file, the installed declarations, or the tool's help output. Do not write a call from memory. Use before you use a library, a framework, a CLI flag, or an HTTP route, and after a dependency update.

• write-docs

  Write documentation that a reader can use. Run each command before you write it. Give the limits. Update the text in the same commit as the change. Use when you write or update a README, a guide, a reference, a changelog, or a docstring.

• write-tests

  Write a test that finds the defect. Show that the test fails against the incorrect code first. Use when you add a test, for "write a test for this", "add coverage", "is this tested", or after you correct a defect that had no test.

Hooks (2)

• PostToolUse

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/record-edit.sh"

• Stop

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/codex-review.sh"

Similar plugins