Code is a solved problem, software is not. Agents are good at the first, but struggle with the second. So we need to control what they do guide them instead of letting them guest.
This repository also configures its own agents. See what context-engineering tells them →
sudoping01/context-engineering
Skill Claude CodeCodex
Review the diff since a fixed point along two axes, Standards and Spec, with severity-tiered output. Use when the user wants a branch, PR, or work-in-progress change reviewed.
sudoping01/context-engineering
Skill Claude CodeCodex
Shared vocabulary for designing deep modules. Use when designing or improving a module's interface, deciding where a seam goes, or when another skill needs the deep-module vocabulary.
sudoping01/context-engineering
Skill Claude CodeCodex
Maintain a running decision record for the work — decisions, failures, constraints, and open questions discovered while doing it. Use throughout, not as documentation written afterwards.
sudoping01/context-engineering
Skill Claude CodeCodex
Gate before shipping a change to a shared or production environment. Use before merging or deploying anything that reaches real infrastructure or real users.
sudoping01/context-engineering
Skill Claude CodeCodex
Gated diagnosis loop for hard bugs and performance regressions. Use when the user reports something broken, throwing, failing, or slow.
sudoping01/context-engineering
Skill Claude CodeCodex
Build and sharpen the project's domain model. Use when discussing codebase terminology, or editing CONTEXT.md or an ADR.
sudoping01/context-engineering
Skill Claude Code
Install a hard gate blocking destructive git commands (force push, reset --hard, clean -f, branch -D) before an agent can run them. Use once per machine or per project, not per task.
sudoping01/context-engineering
Skill Claude CodeCodex
Interview the user about a plan or design before writing code. Use before any non-trivial implementation, or when the user uses a "grill" trigger phrase.
sudoping01/context-engineering
Skill Claude Code
Scan a codebase for deepening opportunities and propose refactors that turn shallow modules into deep ones. Use for codebase health, not feature work.
sudoping01/context-engineering
Skill Claude CodeCodex
Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check a state model or logic, or explore what a UI should look like, before committing to a real build.
sudoping01/context-engineering
Skill Claude CodeCodex
Version, gate, and verify an actual release, and define the rollback trigger for the window after it ships. Use when cutting a release, not just merging a change.
sudoping01/context-engineering
Skill Claude CodeCodex
Investigate a question against primary sources and capture findings as a cited markdown file. Use when a topic, API, or library needs to be researched before it can be grilled or designed against.
sudoping01/context-engineering
Skill Claude CodeCodex
Resolve an in-progress git merge or rebase conflict. Use mid-conflict, hunk by hunk.
sudoping01/context-engineering
Skill Claude Code
Which skill in this kit fits the current situation. Consult this first when unsure what to run next.
sudoping01/context-engineering
Skill Claude CodeCodex
Test-driven development. Use when building a feature or fixing a bug test-first, or when the user wants a red-green-refactor loop.
sudoping01/context-engineering
Skill Claude Code
Move incoming issues and external PRs through a small state machine so intake stays consistent instead of ad hoc. Use for bug reports and feature requests that arrived raw, not for self-scoped work.
sudoping01/context-engineering
Skill Claude CodeCodex
Interrogate the shape of a system — component boundaries, data flow, consistency, failure behavior under partial failure, capacity, and contracts. Use when a change spans more than one module, process, or service, or introduces a new one.
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: