with one click
ask-codex
ask codex for solving complex problems
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
ask codex for solving complex problems
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | ask-codex |
| description | ask codex for solving complex problems |
Codex is an AI-powered CLI tool that can help with complex debugging, code analysis, and technical questions. When you encounter difficult problems that would benefit from a second perspective or deep analysis, use Codex.
Codex works best with a file-based input/output pattern:
Write your question and all relevant context to /tmp/question.txt:
Write to /tmp/question.txt:
- Clear problem statement
- The specific error or symptom
- The relevant code (full functions, not snippets)
- What you've already tried
- Specific questions you want answered
Example structure:
I have a [component] that fails with [specific error].
Here is the full function:
```c
[paste complete code]
Key observations:
Can you identify:
Please write a detailed analysis to /tmp/reply.txt
### Step 2: Invoke Codex
Use this command pattern:
```bash
cat /tmp/question.txt | codex exec -o /tmp/reply.txt --full-auto
Flags:
exec: Non-interactive execution mode (required for CLI use)-o /tmp/reply.txt: Write output to this file--full-auto: Run autonomously without promptsRead /tmp/reply.txt
Codex will provide detailed analysis. Evaluate its suggestions critically - it may identify real bugs but can occasionally misinterpret specifications.
# 1. Create the question
Write /tmp/question.txt with:
- Problem: "Progressive JPEG decoder fails at block 1477 with Huffman error"
- Code: [full AC refinement function]
- Questions: "Identify bugs in EOB handling, ZRL handling, run counting"
# 2. Invoke Codex
cat /tmp/question.txt | codex exec -o /tmp/reply.txt --full-auto
# 3. Read and apply
Read /tmp/reply.txt
# Codex identified 12 potential bugs with detailed explanations
# Evaluate each, verify against spec, apply fixes
Provide complete code: Don't truncate functions. Codex needs full context.
Be specific: "Why does this fail?" is worse than "Why does Huffman decoding fail after processing 1477 blocks in AC refinement scan?"
Include the spec: If debugging against a standard (JPEG, PNG, etc.), mention the relevant spec sections.
Verify suggestions: Codex is helpful but not infallible. In one session, it incorrectly identified the EOB run formula as buggy when it was actually correct. Always verify against authoritative sources.
Iterate if needed: If the first response doesn't solve the problem, create a new question.txt with additional context from what you learned.
"stdin is not a terminal": Use codex exec not bare codex
No output: Check that -o flag has a valid path
Timeout: For very complex questions, Codex may take time. The --full-auto flag helps avoid interactive prompts that would block.
For shorter questions:
echo "Explain the JPEG progressive AC refinement algorithm" | codex exec --full-auto
But for debugging, the file-based pattern is better because you can refine the question and keep a record.
Remote control tmux sessions for interactive CLIs by sending keystrokes and scraping output.
Review a codebase, PR, or module for requirement fidelity, clean architecture quality, and production robustness. Verifies the change actually implements the stated requirement/user goal before checking structure, distinguishing design-level defects (right code, wrong product) from behavior bugs. Detects cross-layer business logic mixing, dependency direction violations, SOLID problems, module depth issues, information leakage, and KISS/over-engineering smells. Reports findings prioritized with SRE-style severity levels (P0-P3).
Practical guidance for writing, refactoring, and reviewing friendly Go code that is simple, idiomatic, and maintainable. Use whenever working with Go (.go) files, designing Go packages or APIs, structuring a new Go project, reviewing Go code, or refactoring Go modules. Also use when the user mentions goroutines, channels, context, error wrapping, interfaces, go.mod, package layout (cmd/internal/pkg), or Go project structure. Even if the user doesn't say "Go" explicitly, trigger this skill when the context involves .go files or go.mod/go.sum.
Validate and lint Agent Skill SKILL.md files and diagnose why a skill fails to load. Use whenever the user wants to check if a skill's frontmatter is valid, find out why a skill "vanished" or is not discovered, lint a single skill, or scan an entire skills directory before committing. Triggers on requests like "validate my skill", "why isn't my skill loading", "check the SKILL.md format", "lint my skills", "diagnose this frontmatter", or any request to verify skill name and description rules. Make sure to use this skill whenever a skill is unexpectedly missing from the available-skills list, since the usual cause is a silent frontmatter parse error rather than a discovery problem.
Write a grounded design/implementation doc for existing code, author a forward-looking design doc before code exists, or apply the embedded principles/checklist to review any design doc. Use whenever the user wants to understand, document, or reverse-engineer how a system, feature, or subsystem is architected (e.g. "how does X work in this repo", "document the Y subsystem", "reverse-engineer Z", "explain the design of W"), or wants to plan and write a new design doc before implementation (e.g. "write a design doc for X", "draft a design for this feature", "I need a design doc to coordinate this work"), or wants design-doc writing principles and a review checklist. Triggers on requests to analyze/document a system's internals, plan a new system's design, or review a design doc for completeness. Output follows a house format: prose + ASCII/Unicode/mermaid flowcharts, a key-file index, behavioral contracts, and a BDD scenario table, validated against checklist.md.
Guide a reverse-engineering proof-of-concept on a macOS crackme / license-check binary, for learning and interview preparation. Use this whenever the user is analyzing a app's authorization / license-gating module and wants to reconstruct its gating model, call chain, architecture differences (arm64 / x86_64 / universal Mach-O), and validate a minimal binary patch with LLDB and code signing. Trigger on mentions of crackme, license-check PoC, Mach-O / IDA / LLDB / objc_msgSend analysis, "find the gating branch", patch validation, universal binary slices, keygen-me vs patch-me, or CTF-style binary patching — even when the user does not say the word "skill".