Codex Review

Use this skill when you need a second perspective on work in progress. Codex excels at identifying gaps in reasoning, missing requirements, architectural concerns, and flawed assumptions - especially early in the planning process when issues are cheapest to fix.

When to Use

Invoke this skill when the user wants an external perspective, especially during early phases:

• Brainstorming sessions - validating ideas and approaches
• Requirements gathering - checking for gaps or contradictions
• Design documents - reviewing architecture and technical decisions
• Implementation plans - validating approach before writing code
• Occasionally: reviewing code or diffs when explicitly requested

How to Invoke Codex

Codex runs in non-interactive mode via codex exec. Pass all content directly via stdin.

Command template:

printf "%s" "$CONTENT_TO_REVIEW" | codex exec \
  -m "gpt-5.1-codex-max" \
  -c 'model_reasoning_effort="high"' \
  -s read-only \
  -

The - at the end tells Codex to read the prompt from stdin. Use printf "%s" instead of echo to safely handle content with backslashes or leading dashes.

Preparing the Content

Before invoking Codex, gather all relevant context into a single prompt. Codex has no access to the filesystem or any context beyond what you provide.

Important: Strip sensitive data (API keys, tokens, credentials, secrets) from content before sending to Codex. If the context is unclear or you need specific fo

…(truncated)

Working with Git

Quick reference for common Git operations used in development workflows.

Detecting Git

Check if the project uses Git:

test -d .git && echo "git" || echo "not git"

Viewing the Log

Show recent commits:

git log --oneline -10

Show log with graph:

git log --oneline --graph --all -10

Show specific commit:

git log -1 <commit-sha>

Find commits by message:

git log --oneline --grep="keyword"

Viewing Diffs

See uncommitted changes:

git diff

See staged changes:

git diff --cached

Diff between commits:

git diff <base-sha>..<head-sha>

Diff stats:

git diff --stat <base-sha>..<head-sha>

Show what changed in a commit:

git show <commit-sha>

Getting Commit References

Current commit SHA:

git rev-parse HEAD

Parent commit SHA:

git rev-parse HEAD~1

Branch’s remote tracking commit:

git rev-parse origin/main

Relative references:

• HEAD - current commit
• HEAD~1 or HEAD^ - parent commit
• HEAD~2 - grandparent commit
• origin/main - remote branch tip

Making Commits

Stage and commit:

git add <files>
git commit -m "commit message"

Commit all tracked changes:

git commit -am "commit message"

Stage specific hunks interactively:

git add -p

Modifying Commit Descriptions

**Amend last commit

…(truncated)

Working with Jujutsu (jj)

Quick reference for common Jujutsu operations used in development workflows.

Jujutsu is a Git-compatible VCS that eliminates staging and treats your working directory as an actual commit that continuously updates.

Detecting Jujutsu

Check if the project uses jj:

test -d .jj && echo "jj" || echo "not jj"

Key Concepts

• @ - Your current working copy (like Git’s HEAD)
• @- - Parent of working copy (like Git’s HEAD~1)
• No staging area - Changes are automatically recorded
• Change IDs - Stable identifiers that survive rebases
• Commit IDs - Traditional hashes compatible with Git

Recommended Workflow

The jj way:

1. Make edits to files
2. Run jj new to create a new commit (repeat for every logical change)
3. After a series of commits, go back and review with jj log
4. Add meaningful descriptions with jj describe <change-id> -m "description"
5. Squash related commits together with jj squash

This workflow creates fine-grained history as you work, then lets you organize it meaningfully afterward.

Viewing the Log

Show recent commits:

jj log -r @~10..@

Show full log:

jj log

Show specific commit:

jj show <change-id>

Show log with more detail:

jj log --stat

Viewing Diffs

See current changes:

jj diff

Diff specific commit:

jj diff -r <change-id>

Diff between two commits:

jj diff

...(truncated)

</details>

### working-with-sqlite

> Preferences and tricks for working with SQLite databases

<details>
<summary>View skill definition</summary>

You're already an expert in SQL, and especially SQLite. Here are our preferences:

PRAGMA journal_mode = WAL; PRAGMA busy_timeout = 5000; PRAGMA synchronous = NORMAL; PRAGMA cache_size = 1000000000; PRAGMA foreign_keys = true; PRAGMA temp_store = memory;

Also:

  - Use `BEGIN IMMEDIATE` transactions.
  - Use `STRICT` tables.


When creating tables with lots of data:
1. create table,
2. insert rows in large transactions, with 10s of thousands of rows a time,
3. then create indices at the end.
4. `ANALYZE` and `VACUUM` if necessary

Use read-only connections when appropriate:
```python
conn = sqlite3.connect('file:database.db?mode=ro', uri=True)