[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CAC5HAAJZ414SFGTP6JZF4":3,"skill-same:01M6CAC5HAAJZ414SFGTP6JZF4":98},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":6,"ownerHtmlUrl":67,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":68,"install":69,"resources":82},"01M6CAC5HAAJZ414SFGTP6JZF4","codex-coding-workflow",null,"Codex-based workflow for substantive repo work under ~\u002Fcode\u002F. Use this when Aaron asks for Codex or when the compatibility-only OpenCode workflow is unavailable, unprovisioned, or unsuitable.","adnichols\u002Fai-configs","adnichols","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F493746?v=4","01M6C33VRY9WF6XWYPT1AFA7JJ","Aaron Nichols","01M6C33VWTNKGRM92E9G643V4W",5,"MIT","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fprofiles\u002Fnerd\u002Fskills\u002Fproductivity\u002Fcodex-coding-workflow\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"codex","workflow","coding","codex coding workflow","github","pr","code","pull","hermes","hermes agent","work","repo","pi","use","only","opencode","2026-11-10 10:12:30",false,"---\nname: codex-coding-workflow\ndescription: \"Codex-based workflow for substantive repo work under ~\u002Fcode\u002F. Use this when Aaron asks for Codex or when the compatibility-only OpenCode workflow is unavailable, unprovisioned, or unsuitable.\"\nversion: 0.1.1\nauthor: Hermes Agent\nlicense: MIT\nmetadata:\n  hermes:\n    tags: [codex, coding-workflow, aaron, github, pull-request]\n    related_skills: [codex, claude-code, pi-coding-workflow, github-pr-workflow]\n---\n\n# Codex Coding Workflow\n\nUse this when Aaron explicitly asks for Codex, when the compatibility-only OpenCode workflow is unavailable or not independently provisioned, or when comparing implementations. Before routing to `hermes-opencode-linear-build`, verify its command and both helper scripts exist under `~\u002F.config\u002Fopencode`; otherwise use this maintained Codex workflow or the maintained Pi workflow.\n\nIt preserves the proven Pi workflow discipline, but drives implementation through OpenAI Codex CLI instead of Pi.\n\n## Non-negotiable rule\n\nFor repositories under `~\u002Fcode\u002F`, Hermes must not directly edit repo files with `patch`, `write_file`, ad-hoc shell rewriting, or equivalent tools. Codex must be the implementer for all repo edits — code, tests, scripts, docs, configs, and release automation — unless Aaron directly authorizes bypassing Codex for that specific edit. Hermes may inspect, plan, verify, run small focused validation commands, commit\u002Fpush, operate GitHub, and report results, but repo mutations go through Codex.\n\n## Preconditions\n\n- Load the `codex` skill too, and use its current CLI guidance.\n- In this workflow, Codex is the primary implementer. Plans and code changes must receive exactly one read-only review from the active harness's configured `reviewer` subagent before advancing. For OpenCode this is `cliproxyapi\u002Fgpt-5.6-terra` at medium reasoning effort; do not add a separate Codex or Claude Code review leg.\n- Run from a git repository under `~\u002Fcode\u002F` unless Aaron gives another path.\n- Read repo instructions first: `AGENTS.md`, `CLAUDE.md`, `.cursorrules`, planning docs, `TESTING.md`, product-intent docs, PR\u002Fcommit guidance.\n- Prefer repo conventions over this generic workflow when they conflict.\n- Codex CLI is available as `codex`; current verified CLI supports `codex exec`, `-C\u002F--cd`, `-s\u002F--sandbox`, `--output-last-message`, and `codex review --base\u002F--uncommitted`.\n\n## Core principles\n\n- Preserve stage separation: planning, review, integration, plan commit, implementation, validation, PM review, code review, PR, post-PR follow-up.\n- Do not let planning mutate production code. Plan-only runs may write\u002Fupdate the canonical plan file, but should not change app\u002Flibrary\u002Fsource files.\n- Use `codex exec` for non-interactive work. For repo-local autonomous edits prefer `-s workspace-write`; avoid `danger-full-access` or `--dangerously-bypass-approvals-and-sandbox` unless Aaron explicitly accepts the risk.\n- Use exactly one fresh, read-only active-harness `reviewer` subagent for every plan or code-review gate. Do not let review passes edit files, run verification, or start a separate Codex or Claude Code review process.\n- Hermes remains responsible for verifying filesystem\u002Fgit\u002FPR state. Do not trust Codex's or Claude's claims without checking files, git status, test output, and PR\u002Fcheck state.\n- Run verification as small, focused commands with one clear purpose each. Do not bundle unrelated validation, git inspection, release checks, and quoting-heavy shell snippets into a giant combined command; if a command hits quoting trouble or times out, split it into simpler probes.\n- Before PR, the repo's full validation bar must pass; targeted tests alone are not enough.\n- Before PR, review the result like a product manager and like a code reviewer.\n\n## Canonical stages\n\n### 0. Gather repo context\n\nInspect the repo for guidance and determine:\n- branch base and naming convention\n- canonical plan location\u002Fformat\n- validation commands and smoke suites\n- product intent \u002F acceptance criteria source\n- PR template and evidence requirements\n\n### 1. Create the branch before planning\n\nCreate the work branch first so the reviewed plan and implementation share one auditable branch.\n\n```bash\ngit switch -c \u003Cbranch-name>\n```\n\n### 2. Plan-only Codex run\n\nAsk Codex to read the task and repo guidance, then create\u002Fupdate only the plan artifact.\n\n```bash\ncodex exec -C \u003Crepo> -s workspace-write '\nRead the task and repo guidance, then create or update the canonical execution plan at \u003Cplan path>.\nDo not change production code, tests, configs, or docs outside the plan artifact in this phase.\nInclude repo-specific validation steps, product-intent linkage, assumptions, risks, and acceptance criteria.\n'\n```\n\nVerify the plan exists and review `git diff` to ensure only plan files changed.\n\n### 3. Review the plan with the active-harness reviewer subagent\n\nRun exactly one configured active-harness `reviewer` subagent pass. This is a hard gate: the reviewer must explicitly return `EXECUTION_READY` before implementation. For OpenCode, invoke the configured `reviewer` subagent (`cliproxyapi\u002Fgpt-5.6-terra`, medium effort) with a read-only plan-review packet and write its result to `\u002Ftmp\u002Fplan-review.md`. Do not start a separate Codex or Claude Code review process.\n\nThe packet must ask the reviewer to inspect `\u003Cplan path>` against the task, repository guidance, product intent, acceptance criteria, edge cases, sequencing, validation requirements, evidence requirements, and PR\u002Frebase requirements. It must prohibit edits and executable verification. The reviewer returns exactly `EXECUTION_READY` or `NOT_READY`; `NOT_READY` includes concrete blockers, gaps, ambiguities, missing validation\u002Fevidence, and required plan changes.\n\nHermes must inspect the one returned artifact before proceeding. If the reviewer returns `NOT_READY`, integrate the feedback and rerun the same reviewer only on the updated plan.\n\n### 4. Integrate plan feedback\n\n```bash\ncodex exec -C \u003Crepo> -s workspace-write '\nIntegrate the active-harness reviewer feedback from \u002Ftmp\u002Fplan-review.md into \u003Cplan path>.\nDo not make implementation changes. Keep the plan execution-ready and aligned with repo conventions.\n'\n```\n\nVerify the plan diff again. If the reviewer returned `NOT_READY` or material blockers, rerun the same plan-review pass after integration and do not proceed until it returns `EXECUTION_READY`.\n\n### 5. Commit the reviewed plan\n\nCommit the reviewed\u002Fintegrated plan before implementation.\n\n```bash\ngit status --short\ngit add \u003Cplan path>\ngit commit -m \"plan: \u003Cconcise task>\"\n```\n\nFollow repo commit conventions when present.\n\n### 6. Plan-stage PM review\n\nRun a fresh read-only Codex pass that pressure-tests the plan as product work, not just code work.\n\n```bash\ncodex exec -C \u003Crepo> -s read-only --output-last-message \u002Ftmp\u002Fcodex-pm-plan.md '\nPerform a plan-stage PM review of \u003Cplan path>. Judge functional outcome, product intent, assumptions, edge cases, risks, and tradeoffs. Return required plan changes, if any. Do not edit files.\n'\n```\n\nIf it finds material gaps, integrate and commit the updated plan, then rerun the active-harness plan review if the PM feedback changed scope, sequencing, validation, acceptance criteria, or evidence requirements. Do not implement until the reviewer still finds the latest plan `EXECUTION_READY`.\n\n### 7. Execute the plan with Codex\n\nFor short tasks, run foreground only after the active-harness plan reviewer returned `EXECUTION_READY` and the plan-stage PM review is acceptable. For longer tasks, run background with `notify_on_complete=true` and monitor with `process`.\n\n```bash\ncodex exec -C \u003Crepo> -s workspace-write '\nExecute the approved plan in \u003Cplan path>. Continue until the plan is complete unless you hit a real blocker.\nFollow repo conventions. Run targeted validation as you work. Do not open a PR.\n'\n```\n\nIf Codex stops early, inspect state and send a continuation prompt rather than assuming completion.\n\n### 8. Validate fully\n\nRun the repo's documented validation bar from `TESTING.md`, `AGENTS.md`, package scripts, and smoke-test docs. Fix failures before PR. If the repo defines smoke tests, they are required pre-PR.\n\nFor user-visible UI or desktop\u002FmacOS changes, capture visual evidence before PR: screenshots at minimum and video when practical. When the OpenCode workflow skill is available, its `scripts\u002Fpr_evidence.py` helper can package evidence under `docs\u002Fpr-evidence\u002F\u003Cslug>\u002F` and generate PR-ready Markdown. If desktop video capture is blocked by macOS TCC\u002FScreen Recording permissions or missing ffmpeg, document that limitation and include still images rather than skipping visual validation entirely.\n\n### 9. Implementation-stage PM review\n\n```bash\ncodex exec -C \u003Crepo> -s read-only --output-last-message \u002Ftmp\u002Fcodex-pm-implementation.md '\nPerform an implementation-stage PM review. Compare the current branch against \u003Cplan path> and product intent. Identify functional gaps, missed edge cases, UX regressions, or acceptance-criteria failures. Do not edit files.\n'\n```\n\nIf this review requires changes, run a Codex implementation follow-up, then rerun impacted validation. Cap repeated PM-review\u002Fre-execution loops at 3 before pausing for Aaron.\n\n### 10. Full code reviews before PR\n\nRun exactly one active-harness `reviewer` subagent code review before PR. Keep it read-only and capture its findings. Do not add a separate Codex or Claude Code review leg.\n\nInvoke the configured active-harness `reviewer` subagent with a read-only packet covering the current branch diff against `\u003Cbase-branch>`, the plan, the scope contract, and verification evidence. For OpenCode, use `cliproxyapi\u002Fgpt-5.6-terra` at medium effort. Ask it to report prioritized findings with file\u002Fline references where possible, and prohibit edits and executable verification. Save the result as `\u002Ftmp\u002Fcode-review.md`.\n\nTreat findings from the reviewer as real work. Fix in-scope issues, rerun impacted validation, and run one targeted rereview limited to those findings and resulting edits. If the reviewer is unavailable, note the blocking infrastructure failure; do not silently substitute an external Codex or Claude Code review.\n\n### 11. Open ready-for-review PR\n\nOnly after:\n- the plan is complete\n- the active-harness reviewer subagent returned `EXECUTION_READY` for the latest material plan version\n- full validation and smoke tests pass\n- PM\u002Fproduct review is acceptable\n- active-harness reviewer-subagent code-review findings are addressed\n- visual\u002Fuser-flow evidence is captured if relevant\n- the branch has been rebased onto the latest intended target branch and conflicts are resolved\n- the tree is clean except intentional committed changes\n\nBefore opening the PR:\n\n```bash\ngit fetch origin \u003Cbase-branch>\ngit rebase origin\u002F\u003Cbase-branch>\ngit status --short\ngit merge-base --is-ancestor origin\u002F\u003Cbase-branch> HEAD\n```\n\nIf rebase creates conflicts, resolve through Codex, rerun impacted validation\u002Freviews, refresh visual evidence if behavior changed, and only then open the PR.\n\nCreate a ready PR following repo template. Do not open as draft unless Aaron asks.\n\n### 12. Post-PR follow-up\n\nAfter PR creation:\n- wait for GitHub checks at least once\n- inspect comments\u002Freviews\u002Ffailing checks\n- address at least one pass of feedback\n- confirm mergeability\n- if conflicts exist, rebase onto the intended base, resolve, push, and re-check\n\nThe workflow is not complete at \"PR opened\"; it completes after one feedback\u002Fcheck cycle and mergeability confirmation.\n\n## Minimal prompt snippets\n\nPlan-only:\n```text\nCreate\u002Fupdate only \u003Cplan path>. Do not change production code in this phase.\n```\n\nContinuation:\n```text\nContinue executing the approved plan from the current repo state. Finish remaining work unless you hit a real blocker.\n```\n\nFix review findings:\n```text\nAddress the PM\u002Fcode review findings, keep scope aligned with \u003Cplan path>, and rerun the impacted validation commands.\n```\n\n## Open refinement items\n\nThis is an initial Codex adaptation of the Pi workflow. Refine after real runs, especially around:\n- whether Aaron wants visible tmux panes for Codex like he did for Pi\n- whether to build a `codex_workflow_ctl.py` controller analogous to `pi_workflow_ctl.py`\n- preferred model\u002Fprofile flags for Codex and Claude Code on Aaron's machines\n- repo-specific automation for Linear state sync and PR evidence capture\n","# Codex Coding Workflow\n\nUse this when Aaron explicitly asks for Codex, when the compatibility-only OpenCode workflow is unavailable or not independently provisioned, or when comparing implementations. Before routing to `hermes-opencode-linear-build`, verify its command and both helper scripts exist under `~\u002F.config\u002Fopencode`; otherwise use this maintained Codex workflow or the maintained Pi workflow.\n\nIt preserves the proven Pi workflow discipline, but drives implementation through OpenAI Codex CLI instead of Pi.\n\n## Non-negotiable rule\n\nFor repositories under `~\u002Fcode\u002F`, Hermes must not directly edit repo files with `patch`, `write_file`, ad-hoc shell rewriting, or equivalent tools. Codex must be the implementer for all repo edits — code, tests, scripts, docs, configs, and release automation — unless Aaron directly authorizes bypassing Codex for that specific edit. Hermes may inspect, plan, verify, run small focused validation commands, commit\u002Fpush, operate GitHub, and report results, but repo mutations go through Codex.\n\n## Preconditions\n\n- Load the `codex` skill too, and use its current CLI guidance.\n- In this workflow, Codex is the primary implementer. Plans and code changes must receive exactly one read-only review from the active harness's configured `reviewer` subagent before advancing. For OpenCode this is `cliproxyapi\u002Fgpt-5.6-terra` at medium reasoning effort; do not add a separate Codex or Claude Code review leg.\n- Run from a git repository under `~\u002Fcode\u002F` unless Aaron gives another path.\n- Read repo instructions first: `AGENTS.md`, `CLAUDE.md`, `.cursorrules`, planning docs, `TESTING.md`, product-intent docs, PR\u002Fcommit guidance.\n- Prefer repo conventions over this generic workflow when they conflict.\n- Codex CLI is available as `codex`; current verified CLI supports `codex exec`, `-C\u002F--cd`, `-s\u002F--sandbox`, `--output-last-message`, and `codex review --base\u002F--uncommitted`.\n\n## Core principles\n\n- Preserve stage separation: planning, review, integration, plan commit, implementation, validation, PM review, code review, PR, post-PR follow-up.\n- Do not let planning mutate production code. Plan-only runs may write\u002Fupdate the canonical plan file, but should not change app\u002Flibrary\u002Fsource files.\n- Use `codex exec` for non-interactive work. For repo-local autonomous edits prefer `-s workspace-write`; avoid `danger-full-access` or `--dangerously-bypass-approvals-and-sandbox` unless Aaron explicitly accepts the risk.\n- Use exactly one fresh, read-only active-harness `reviewer` subagent for every plan or code-review gate. Do not let review passes edit files, run verification, or start a separate Codex or Claude Code review process.\n- Hermes remains responsible for verifying filesystem\u002Fgit\u002FPR state. Do not trust Codex's or Claude's claims without checking files, git status, test output, and PR\u002Fcheck state.\n- Run verification as small, focused commands with one clear purpose each. Do not bundle unrelated validation, git inspection, release checks, and quoting-heavy shell snippets into a giant combined command; if a command hits quoting trouble or times out, split it into simpler probes.\n- Before PR, the repo's full validation bar must pass; targeted tests alone are not enough.\n- Before PR, review the result like a product manager and like a code reviewer.\n\n## Canonical stages\n\n### 0. Gather repo context\n\nInspect the repo for guidance and determine:\n- branch base and naming convention\n- canonical plan location\u002Fformat\n- validation commands and smoke suites\n- product intent \u002F acceptance criteria source\n- PR template and evidence requirements\n\n### 1. Create the branch before planning\n\nCreate the work branch first so the reviewed plan and implementation share one auditable branch.\n\n```bash\ngit switch -c \u003Cbranch-name>\n```\n\n### 2. Plan-only Codex run\n\nAsk Codex to read the task and repo guidance, then create\u002Fupdate only the plan artifact.\n\n```bash\ncodex exec -C \u003Crepo> -s workspace-write '\nRead the task and repo guidance, then create or update the canonical execution plan at \u003Cplan path>.\nDo not change production code, tests, configs, or docs outside the plan artifact in this phase.\nInclude repo-specific validation steps, product-intent linkage, assumptions, risks, and acceptance criteria.\n'\n```\n\nVerify the plan exists and review `git diff` to ensure only plan files changed.\n\n### 3. Review the plan with the active-harness reviewer subagent\n\nRun exactly one configured active-harness `reviewer` subagent pass. This is a hard gate: the reviewer must explicitly return `EXECUTION_READY` before implementation. For OpenCode, invoke the configured `reviewer` subagent (`cliproxyapi\u002Fgpt-5.6-terra`, medium effort) with a read-only plan-review packet and write its result to `\u002Ftmp\u002Fplan-review.md`. Do not start a separate Codex or Claude Code review process.\n\nThe packet must ask the reviewer to inspect `\u003Cplan path>` against the task, repository guidance, product intent, acceptance criteria, edge cases, sequencing, validation requirements, evidence requirements, and PR\u002Frebase requirements. It must prohibit edits and executable verification. The reviewer returns exactly `EXECUTION_READY` or `NOT_READY`; `NOT_READY` includes concrete blockers, gaps, ambiguities, missing validation\u002Fevidence, and required plan changes.\n\nHermes must inspect the one returned artifact before proceeding. If the reviewer returns `NOT_READY`, integrate the feedback and rerun the same reviewer only on the updated plan.\n\n### 4. Integrate plan feedback\n\n```bash\ncodex exec -C \u003Crepo> -s workspace-write '\nIntegrate the active-harness reviewer feedback from \u002Ftmp\u002Fplan-review.md into \u003Cplan path>.\nDo not make implementation changes. Keep the plan execution-ready and aligned with repo conventions.\n'\n```\n\nVerify the plan diff again. If the reviewer returned `NOT_READY` or material blockers, rerun the same plan-review pass after integration and do not proceed until it returns `EXECUTION_READY`.\n\n### 5. Commit the reviewed plan\n\nCommit the reviewed\u002Fintegrated plan before implementation.\n\n```bash\ngit status --short\ngit add \u003Cplan path>\ngit commit -m \"plan: \u003Cconcise task>\"\n```\n\nFollow repo commit conventions when present.\n\n### 6. Plan-stage PM review\n\nRun a fresh read-only Codex pass that pressure-tests the plan as product work, not just code work.\n\n```bash\ncodex exec -C \u003Crepo> -s read-only --output-last-message \u002Ftmp\u002Fcodex-pm-plan.md '\nPerform a plan-stage PM review of \u003Cplan path>. Judge functional outcome, product intent, assumptions, edge cases, risks, and tradeoffs. Return required plan changes, if any. Do not edit files.\n'\n```\n\nIf it finds material gaps, integrate and commit the updated plan, then rerun the active-harness plan review if the PM feedback changed scope, sequencing, validation, acceptance criteria, or evidence requirements. Do not implement until the reviewer still finds the latest plan `EXECUTION_READY`.\n\n### 7. Execute the plan with Codex\n\nFor short tasks, run foreground only after the active-harness plan reviewer returned `EXECUTION_READY` and the plan-stage PM review is acceptable. For longer tasks, run background with `notify_on_complete=true` and monitor with `process`.\n\n```bash\ncodex exec -C \u003Crepo> -s workspace-write '\nExecute the approved plan in \u003Cplan path>. Continue until the plan is complete unless you hit a real blocker.\nFollow repo conventions. Run targeted validation as you work. Do not open a PR.\n'\n```\n\nIf Codex stops early, inspect state and send a continuation prompt rather than assuming completion.\n\n### 8. Validate fully\n\nRun the repo's documented validation bar from `TESTING.md`, `AGENTS.md`, package scripts, and smoke-test docs. Fix failures before PR. If the repo defines smoke tests, they are required pre-PR.\n\nFor user-visible UI or desktop\u002FmacOS changes, capture visual evidence before PR: screenshots at minimum and video when practical. When the OpenCode workflow skill is available, its `scripts\u002Fpr_evidence.py` helper can package evidence under `docs\u002Fpr-evidence\u002F\u003Cslug>\u002F` and generate PR-ready Markdown. If desktop video capture is blocked by macOS TCC\u002FScreen Recording permissions or missing ffmpeg, document that limitation and include still images rather than skipping visual validation entirely.\n\n### 9. Implementation-stage PM review\n\n```bash\ncodex exec -C \u003Crepo> -s read-only --output-last-message \u002Ftmp\u002Fcodex-pm-implementation.md '\nPerform an implementation-stage PM review. Compare the current branch against \u003Cplan path> and product intent. Identify functional gaps, missed edge cases, UX regressions, or acceptance-criteria failures. Do not edit files.\n'\n```\n\nIf this review requires changes, run a Codex implementation follow-up, then rerun impacted validation. Cap repeated PM-review\u002Fre-execution loops at 3 before pausing for Aaron.\n\n### 10. Full code reviews before PR\n\nRun exactly one active-harness `reviewer` subagent code review before PR. Keep it read-only and capture its findings. Do not add a separate Codex or Claude Code review leg.\n\nInvoke the configured active-harness `reviewer` subagent with a read-only packet covering the current branch diff against `\u003Cbase-branch>`, the plan, the scope contract, and verification evidence. For OpenCode, use `cliproxyapi\u002Fgpt-5.6-terra` at medium effort. Ask it to report prioritized findings with file\u002Fline references where possible, and prohibit edits and executable verification. Save the result as `\u002Ftmp\u002Fcode-review.md`.\n\nTreat findings from the reviewer as real work. Fix in-scope issues, rerun impacted validation, and run one targeted rereview limited to those findings and resulting edits. If the reviewer is unavailable, note the blocking infrastructure failure; do not silently substitute an external Codex or Claude Code review.\n\n### 11. Open ready-for-review PR\n\nOnly after:\n- the plan is complete\n- the active-harness reviewer subagent returned `EXECUTION_READY` for the latest material plan version\n- full validation and smoke tests pass\n- PM\u002Fproduct review is acceptable\n- active-harness reviewer-subagent code-review findings are addressed\n- visual\u002Fuser-flow evidence is captured if relevant\n- the branch has been rebased onto the latest intended target branch and conflicts are resolved\n- the tree is clean except intentional committed changes\n\nBefore opening the PR:\n\n```bash\ngit fetch origin \u003Cbase-branch>\ngit rebase origin\u002F\u003Cbase-branch>\ngit status --short\ngit merge-base --is-ancestor origin\u002F\u003Cbase-branch> HEAD\n```\n\nIf rebase creates conflicts, resolve through Codex, rerun impacted validation\u002Freviews, refresh visual evidence if behavior changed, and only then open the PR.\n\nCreate a ready PR following repo template. Do not open as draft unless Aaron asks.\n\n### 12. Post-PR follow-up\n\nAfter PR creation:\n- wait for GitHub checks at least once\n- inspect comments\u002Freviews\u002Ffailing checks\n- address at least one pass of feedback\n- confirm mergeability\n- if conflicts exist, rebase onto the intended base, resolve, push, and re-check\n\nThe workflow is not complete at \"PR opened\"; it completes after one feedback\u002Fcheck cycle and mergeability confirmation.\n\n## Minimal prompt snippets\n\nPlan-only:\n```text\nCreate\u002Fupdate only \u003Cplan path>. Do not change production code in this phase.\n```\n\nContinuation:\n```text\nContinue executing the approved plan from the current repo state. Finish remaining work unless you hit a real blocker.\n```\n\nFix review findings:\n```text\nAddress the PM\u002Fcode review findings, keep scope aligned with \u003Cplan path>, and rerun the impacted validation commands.\n```\n\n## Open refinement items\n\nThis is an initial Codex adaptation of the Pi workflow. Refine after real runs, especially around:\n- whether Aaron wants visible tmux panes for Codex like he did for Pi\n- whether to build a `codex_workflow_ctl.py` controller analogous to `pi_workflow_ctl.py`\n- preferred model\u002Fprofile flags for Codex and Claude Code on Aaron's machines\n- repo-specific automation for Linear state sync and PR evidence capture\n",{"name":5,"author":50,"license":15,"version":51,"metadata":52,"description":7},"Hermes Agent","0.1.1",{"hermes":53},{"tags":54,"related_skills":58},[29,55,56,33,57],"coding-workflow","aaron","pull-request",[29,59,60,61],"claude-code","pi-coding-workflow","github-pr-workflow","main","64e2fc9afa7bb3da1138eb73399144d0e7e73e9d","_hermes\u002Fdefault\u002Fprofiles\u002Fnerd\u002Fskills\u002Fproductivity\u002Fcodex-coding-workflow",4,"https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs","https:\u002F\u002Fgithub.com\u002Fadnichols","2026-11-06 00:28:38",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add adnichols\u002Fai-configs --skill codex-coding-workflow",{"tool":75,"command":76},"bunx","bunx skills add adnichols\u002Fai-configs --skill codex-coding-workflow",{"tool":78,"command":79},"pnpm","pnpm dlx skills add adnichols\u002Fai-configs --skill codex-coding-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fprofiles\u002Fnerd\u002Fskills\u002Fproductivity\u002Fcodex-coding-workflow\u002FSKILL.md",true,[83,88,94],{"path":84,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"LICENSE","许可证",1067,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fashrafiucse-flow-security\u002FLICENSE",{"path":89,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":93},"SOURCE.md","REFERENCE","参考文档",370,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fashrafiucse-flow-security\u002FSOURCE.md",{"path":95,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":96,"sourceHtmlUrl":97},"TRUST.auto.yaml",2075,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fashrafiucse-flow-security\u002FTRUST.auto.yaml",[99,118,145,169,180,196],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":45},"01M6CB7RN791P5RRRCJWWC7DAR","blocked-page-recovery","Use when a fetch fails: 403\u002F429, paywall, WAF, bot wall.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fweb\u002Fblocked-page-recovery\u002FSKILL.md",[],[106,107,108,109,110,42,111,38,37,112,113,114,115,116,117],"recovery","page","blocked page recovery","bot","fallback","fetch","Citations","waf","windows","research","linux","macos",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":131,"publishedAt":45},"01M6CB7NQY2VVYCQJ1QBXACQF4","writing-plans","Use when creating or updating executable software plans. Keep plans as local files unless the user explicitly asks to register them in Doct.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fwriting-plans\u002FSKILL.md",[124,127,128],{"categoryNo":125,"categoryName":126,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":129,"categoryName":130,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[132,133,134,135,30,136,137,138,139,140,141,142,42,143,38,37,144],"writing","writing plans","documentation","test","design","user","development","planning","files","implementation","html","ops","plan",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":160,"publishedAt":45},"01M6CB7JME246KZQHP73Z2STDF","test-driven-development","TDD: enforce RED-GREEN-REFACTOR, tests before code.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Ftest-driven-development\u002FSKILL.md",[151,154,157],{"categoryNo":152,"categoryName":153,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":155,"categoryName":156,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":158,"categoryName":159,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务",[135,138,161,162,163,38,37,164,144,165,35,166,117,167,116,168,114],"test driven development","red-green-refactor","superpowers","quality","refactor","debugging","tdd","testing",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":176,"publishedAt":45},"01M6CB7FQ407KQTD4Z9VAWKY54","systematic-debugging","4-phase root cause debugging: understand bugs before fixing.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fsystematic-debugging\u002FSKILL.md",[175],{"categoryNo":155,"categoryName":156,"taxonomyType":21,"taxonomyTypeDesc":22},[166,177,138,163,38,37,178,144,179,114,135,116,117],"systematic debugging","troubleshooting","investigation",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":189,"publishedAt":45},"01M6CB7D57MK88HE5YPZHKH68Q","spike","Throwaway experiments to validate an idea before build.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fspike\u002FSKILL.md",[186],{"categoryNo":187,"categoryName":188,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[182,114,190,191,115,192,116,117,193,194,195,38,37,144,139],"validate","experiments","prototype","feasibility","sketch","experiment",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":204,"publishedAt":45},"01M6CB7APAQ37YE5YE1MAAFT42","simplify-code","Parallel 3-agent cleanup of recent code changes.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fsimplify-code\u002FSKILL.md",[202,203],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[205,206,35,207,38,37,208,144,165,209,210,211,138,114,135,116,212,117],"simplify code","simplify","subagent","parallel","code-review","delegation","cleanup","review"]