dot-codex

Review a target app or project's feature specs, proof plans, proof evidence, successful tests, evaluator results, and user corrections to suggest app-specific improvements, new features, proof hardening, and reusable harness lessons without applying changes. Use when Codex should manually analyze whether features, proofs, and successful checks make sense and produce suggestions for the app/project or for dot-codex harness evolution.

Turn an overall app description into a sharper app brief, bootstrap repo-level docs, create a series of features, executable proof packages, and the feature queue. Use for greenfield work when the user has an app idea and wants Codex to initialize the project before returning to feature execution. Use the `research` skill when assumptions need external evidence.

Execute a feature queue, one feature, or a stubborn issue fix through a Codex Goal with explicit PROOF.md verification, evaluator judgment, bounded repair, and queue progress updates. Use when the user asks for autonomous execution, keep-going-until-done behavior, queue completion, or repeated repair after coding-feature-execute or coding-repair.

Evaluate whether a completed feature or issue fix is actually done using a read-only skeptical review of FEATURE.md, PROOF.md, primary proof results, gate results, architecture fit, and anti-gaming risks. This is the done judge, not the test runner. Use after coding-feature-execute, coding-repair, or coding-autonomous-execute before marking work complete.

Implement one feature end-to-end in Codex App using FEATURE.md for desired behavior, PROOF.md for done criteria, existing repo skills, red/green proof-first work, deterministic validation, mandatory backend/frontend/WordPress domain-skill handoff, and bounded repair. Use when a feature contract and proof contract are ready or need to be made ready before delivery.

Review FEATURE_DIR/FEATURE.md and FEATURE_DIR/PROOF.md before non-trivial implementation for ambiguity, edge cases, testability, proof quality, and architecture conflicts without adding framework phases.

Maintain docs/features/status.json as a lightweight machine-readable feature queue for greenfield and brownfield autonomy. Use when creating multiple features, selecting the next feature, marking feature progress, or running coding-autonomous-execute across all features.

Create or update docs/features/{feature-id-slug}/FEATURE.md from a rough or incomplete idea, then use coding-proof-author to create PROOF.md and executable proof artifacts for non-trivial features. Use when the task is feature-spec authoring or refinement.

Create or repair FEATURE_DIR/PROOF.md and executable feature proof artifacts. Use when a feature needs a definition of done, primary proof command, behavioral E2E/API/scenario/regression/migration verification, or when existing proof is vague, weak, missing, static-only, or gameable.

Repair a clear issue or failing check with the smallest effective code change, local runtime evidence, existing feature proof lookup, regression tests, and verification. Use when the user asks to debug/fix an existing problem or repair a concrete proof, gate, typecheck, lint, build, or evaluator failure.

Produce a concise operating brief from the user's Notion Second Brain. Use when the user says SECOND BRAIN | Activity Brief, asks what to focus on, asks for an update on activities, tasks, deals, waiting items, stale work, or ideas.

Capture raw material into the user's Notion Second Brain by classifying it directly as a task, deal, or idea. Use when the user says SECOND BRAIN | Capture Raw Input, asks to log/capture/track a manual note, pasted Granola excerpt, dictated thought, screenshot text, copied snippet, or Codex note.

Inspect external native sources for Notion Second Brain updates without bulk-copying them. Use when the user says SECOND BRAIN | External Sweep, asks Codex to review Gmail, Zotero, Git repos, Granola, Codex work, or other native systems and create concise Notion task, deal, or idea rows.

Read and write the user's Notion Second Brain through the Notion API instead of MCP. Use when the user says SECOND BRAIN | Notion API, asks to read or write SB - Tasks, SB - Deals, or SB - Ideas with local API access, or when the Notion MCP connector is unavailable, indirect, or plan-gated.

Run a weekly review of the user's Notion Second Brain. Use when the user says SECOND BRAIN | Weekly Review, asks for a weekly review, wants stale tasks/deals/ideas reviewed, or wants Codex to summarize open loops.

Prepare local project environments before coding, tests, gates, feature proof commands, dependency/tooling work, or VS Code run-task generation. Use when Codex or another skill needs the shared setup step for Python, React/Node, PHP, Laravel, WordPress, or mixed/unknown stacks, including environment discovery, safe .env handling, whitelist-pattern .gitignore setup, virtualenv/node_modules/vendor setup, validation command selection, and `.vscode/tasks.json` for local dev loops.

Gather external evidence for product, domain, library, or API questions before feature or app planning commits to assumptions. Use when `coding-app-to-features` or `coding-feature-spec` needs grounded facts, official docs, or comparable examples, especially when web search or Context7 is required.

Add raw, dictated, transcribed, or loosely structured material to a user's markdown notes, diary, journal, or second-brain collection. Use when Codex needs to create or append a dated markdown note, choose the proper destination folder by inspecting existing notes, preserve local filename/frontmatter conventions, or turn messy note input into a concise dated entry without inventing facts.

Rewrite text into casual, natural, human-sounding messages for chat, DMs, email snippets, social replies, or spoken-style notes. Use when the user asks to make wording less formal, less polished, more casual, more natural, less verbose, less punctuated, less capitalized, more like phone typing, more like a real person, or similar, regardless of topic.

Create concise, grounded showcase recaps from Codex chat work, including Codex skills used, serious technical outcomes, work snapshot summaries, and optional real screenshots or chat snapshot references. Start by capturing the current Codex desktop app when screenshot tooling is available. Use when the user wants to show how they use Codex, summarize a completed Codex session, write a proof-of-work post, or package a Codex chat into a polished public or semi-public narrative.

Review the architecture of a specific codebase component with a state-of-the-art deep-dive method: analyze architectural, logical, and implementation choices to identify weaknesses, flaws, limitations, and performance bottlenecks. Use when precise, evidence-based component assessment is requested before refactoring or scaling decisions.

Stage selected local changes and create a local Conventional Commit with a clear subject and compact body. Use when the user wants to commit, stage and commit, create a local commit, or draft a commit message for staged, unstaged, or recent changes. Never push.

Compare an existing architecture/solution against a specific reference and decide KEEP, PARTIAL ADOPT, or REPLACE with explicit migration steps. Use only when both current-state material and a concrete reference are provided.

Audit the current git checkout for critical hardcoded secrets with GitGuardian ggmcp. Use when the user asks Codex to scan local tracked, staged, modified, or untracked non-ignored files for leaked credentials, API keys, tokens, passwords, private keys, or other critical secrets before commit, publish, deploy, or handoff.

Implement, bootstrap, or refactor user-facing React/Next.js UI with strong layout, interaction, and visual quality while preserving repo conventions. Use for frontend surface changes, greenfield frontend skeleton creation, missing frontend/app setup, or new React/Next.js app work even when no existing frontend is detected. Do not use for backend-only or infrastructure tasks.

Diagnose operational bugs and runtime issues using read-only checks across local files and processes, virtualenvs, Docker, PostgreSQL/psql, Azure CLI, AKS/Kubernetes via kubectl, and Azure Static Web Apps. Use when the user asks to investigate outages, failing deployments, bad pods, missing logs, container problems, database connectivity issues, or unclear local-versus-cloud regressions.

Implement or bootstrap backend API/application changes with clear route/service/domain boundaries and pytest coverage. Use for backend-focused tasks, greenfield API layer creation, missing backend/app setup, API endpoints, routes, service logic, data persistence, FastAPI/service-layer projects, or Python application code even when no existing backend is detected.

Implement, bootstrap, or maintain WordPress plugins, themes, full-site installs, and Bedrock-style applications with a forced greenfield wordpress/app, wordpress/deployments, and wordpress/pipelines structure, WordPress-safe boundaries, and appropriate PHP/JS tests. Use when a task mentions WordPress, wp-content, plugins, themes, Bedrock, wp-cli, Gutenberg blocks, WooCommerce extensions, or WordPress-specific PHP code.

Create, edit, amend, restyle, and validate presentation decks implemented as standalone HTML/CSS/JavaScript files. Use when Codex needs to build or revise browser-native slide decks, keynote-style HTML presentations, scroll-snap decks, speaker/demo decks, or presentation-like HTML artifacts using the bundled thariqs.github.io reference patterns.

Write and revise direct, useful website content that demonstrates technical competence without assuming specialist readers. Use when Codex needs to draft or edit technical blog posts, engineering essays, service pages, project writeups, founder notes, newsletter pieces, or website copy that should sound specific, clear, evidence-based, and human instead of generic AI prose.

Product-agnostic LinkedIn content management converted from the Claude LinkedIn Content Manager plugin. Use when Codex needs to initialize a LinkedIn content knowledge base, analyze a profile or posts, define LinkedIn strategy, generate topics, research topics, craft LinkedIn posts, build campaign calendars, review campaign results, or maintain a LinkedIn content learning loop for any product, project, sector, or personal brand using user-provided context from text or files.

Build product-agnostic GTM signal context files for signal detection. Use when Codex needs to turn user-provided text or files into a normalized `signal-context.md` containing product context, sector context, ICP, competitors, alternatives, pain points, trigger events, disqualification rules, signal criteria, search seeds, and engagement constraints for use by the prospecting-signal-detector skill.

Product-agnostic GTM signal detection workflow converted from the Claude Signal Detector plugin. Use when Codex needs to scan LinkedIn, Reddit, or industry discussions for buying signals for any product, project, sector, or ICP; classify opportunities from user-provided signal criteria; maintain signals-database.json; generate signal reports; draft engagement actions; or safely execute LinkedIn engagement with explicit approval.

Safely pull the local Codex configuration checkout from https://github.com/marcocello/dot-codex. Use when the user asks to pull, update, refresh, or get the latest dot-codex repo, Codex skills, scripts, AGENTS.md discipline, or local Codex configuration from marcocello/dot-codex.

Use when building or fixing Laravel features, including routes, controllers, requests, models, policies, jobs, queues, APIs, admin flows, migrations, and PHPUnit or Pest coverage.

Review a full codebase for verbosity, tangled responsibilities, weak module boundaries, and readability debt; produce prioritized improvements that make code lean and clear for humans. Use when users ask for maintainability audits, code simplification, structure review, refactor planning, or “make this codebase cleaner/less intertwined.”

Use when working on plain PHP or framework-light PHP projects that need maintenance, debugging, runtime audits, Composer dependency review, PHP version compatibility checks, incremental refactors, or safe upgrade planning.