[codex] 后端规范化设计与 PRD/Plan 拆分

.claude/skills/commit/SKILL.md

@@ -10,66 +10,60 @@ description:
 
 ## Goals
 
-- Produce a commit that reflects the actual code changes and the session
-  context.
-- Follow common git conventions (type prefix, short subject, wrapped body).
+- Produce a commit that reflects the actual code changes and the session context.
+- Follow `WORKFLOW.md` and `CLAUDE.md` commit discipline (allowed types and test-first ordering).
 - Include both summary and rationale in the body.
 
+## Allowed commit types
+
+Only these subject prefixes are allowed:
+
+- `test:` — failing tests, fixtures, mocks, acceptance scripts, test-only expectations
+- `impl:` — smallest implementation that makes existing red tests pass
+- `feat:` — user-visible capability or behavior changes (after prior `test:` unless documented as not scriptable)
+- `refactor:` — behavior-preserving cleanup after tests are green
+- `docs:` — documentation, examples, workflow text, acceptance notes
+- `chore:` — CI, configuration, dependency metadata, generated housekeeping
+
+For feature or behavior work, preserve order: `test:` first, then `impl:`/`feat:`, then optional `refactor:`, `docs:`, or `chore:`.
+
+Do not mix unrelated types in one commit. Split by type when practical.
+
 ## Inputs
 
-- Claude session history for intent and rationale.
+- Session history for intent and rationale.
 - `git status`, `git diff`, and `git diff --staged` for actual changes.
-- Repo-specific commit conventions if documented.
+- `WORKFLOW.md`, `CLAUDE.md`, and workpad `Commit Plan` when present.
 
 ## Steps
 
 1. Read session history to identify scope, intent, and rationale.
-2. Inspect the working tree and staged changes (`git status`, `git diff`,
-   `git diff --staged`).
-3. Stage intended changes, including new files (`git add -A`) after confirming
-   scope.
-4. Sanity-check newly added files; if anything looks random or likely ignored
-   (build artifacts, logs, temp files), flag it to the user before committing.
-5. If staging is incomplete or includes unrelated files, fix the index or ask
-   for confirmation.
-6. Choose a conventional type and optional scope that match the change (e.g.,
-   `feat(scope): ...`, `fix(scope): ...`, `refactor(scope): ...`).
-7. Write a subject line in imperative mood, <= 72 characters, no trailing
-   period.
-8. Write a body that includes:
-   - Summary of key changes (what changed).
-   - Rationale and trade-offs (why it changed).
-   - Tests or validation run (or explicit note if not run).
-9. Append a `Co-authored-by` trailer for Claude using `Claude <claude@openai.com>`
-   unless the user explicitly requests a different identity.
-10. Wrap body lines at 72 characters.
-11. Create the commit message with a here-doc or temp file and use
-    `git commit -F <file>` so newlines are literal (avoid `-m` with `\n`).
-12. Commit only when the message matches the staged changes: if the staged diff
-    includes unrelated files or the message describes work that isn't staged,
-    fix the index or revise the message before committing.
+2. Inspect the working tree and staged changes (`git status`, `git diff`, `git diff --staged`).
+3. Stage intended changes (`git add -A`) after confirming scope.
+4. Sanity-check newly added files; flag build artifacts, logs, or temp files before committing.
+5. If staging is incomplete or includes unrelated files, fix the index or ask for confirmation.
+6. Choose the allowed type that matches the staged diff. Do not use `fix:` or scoped conventional types unless documented as an exception.
+7. Write a subject line in imperative mood, <= 72 characters. Format: `<type> <short summary>`.
+8. Write a body with summary, rationale, and tests or validation run (or why not run).
+9. Wrap body lines at 72 characters.
+10. Create the commit message with a here-doc or temp file and use `git commit -F <file>`.
+11. Commit only when the message matches the staged changes.
 
 ## Output
 
-- A single commit created with `git commit` whose message reflects the session.
+- A single commit whose message reflects the session and discipline above.
 
 ## Template
 
-Type and scope are examples only; adjust to fit the repo and changes.
-
 ```
-<type>(<scope>): <short summary>
+<type> <short summary>
 
 Summary:
 - <what changed>
-- <what changed>
 
 Rationale:
 - <why>
-- <why>
 
 Tests:
 - <command or "not run (reason)">
-
-Co-authored-by: Claude <claude@openai.com>
 ```

.claude/skills/harness-linear-loop/SKILL.md

@@ -30,10 +30,11 @@ The loop maintains:
 
 ## Flow
 
+0. Open `.claude/skills/harness-quality-gate/SKILL.md` and `.claude/skills/using-superpowers/SKILL.md` before other work.
 1. Fetch the ticket and confirm current status before changing files.
 2. Move `Todo` to `In Progress` only after the workspace is ready.
 3. Create or update `## Claude Workpad` with plan, acceptance criteria, validation checklist, and environment stamp.
-4. After implementation, run `harness-local-server` and `harness-playwright-evidence` when relevant.
+4. After implementation, follow `test-driven-development` and `executing-plans`; run `harness-local-server` and `harness-playwright-evidence` when relevant; finish with `verification-before-completion`.
 5. Attach or link evidence through Linear API when supported; otherwise paste artifact paths and summaries.
 6. Create or update the PR and link it to the ticket.
 7. Sweep PR comments and CI before moving to `Human Review`.

.claude/skills/land/SKILL.md

@@ -32,7 +32,7 @@ description:
 4. Check mergeability and conflicts against main.
 5. If conflicts exist, use the `pull` skill to fetch/merge `origin/main` and
    resolve conflicts, then use the `push` skill to publish the updated branch.
-6. Ensure Claude review comments (if present) are acknowledged and any required
+6. Ensure Codex review comments (if present) are acknowledged and any required
    fixes are handled before merging.
 7. Watch checks until complete.
 8. If checks fail, pull logs, fix the issue, commit with the `commit` skill,
@@ -50,10 +50,10 @@ description:
     - If you are confident you know better than the reviewer, you may proceed
       without asking the user, but reply inline with your rationale.
 13. **Per-comment mode:** For each review comment, choose one of: accept,
-    clarify, or push back. Reply inline (or in the issue thread for Claude
+    clarify, or push back. Reply inline (or in the issue thread for Codex
     reviews) stating the mode before changing code.
 14. **Reply before change:** Always respond with intended action before pushing
-    code changes (inline for review comments, issue thread for Claude reviews).
+    code changes (inline for review comments, issue thread for Codex reviews).
 
 ## Commands
 
@@ -74,13 +74,13 @@ fi
 
 # Preferred: use the Async Watch Helper below. The manual loop is a fallback
 # when Python cannot run or the helper script is unavailable.
-# Wait for review feedback: Claude reviews arrive as issue comments that start
-# with "## Claude Review — <persona>". Treat them like reviewer feedback: reply
-# with a `[claude]` issue comment acknowledging the findings and whether you're
+# Wait for review feedback: Codex reviews arrive as issue comments that start
+# with "## Codex Review — <persona>". Treat them like reviewer feedback: reply
+# with a `[codex]` issue comment acknowledging the findings and whether you're
 # addressing or deferring them.
 while true; do
   gh api repos/{owner}/{repo}/issues/"$pr_number"/comments \
-    --jq '.[] | select(.body | startswith("## Claude Review")) | .id' | rg -q '.' \
+    --jq '.[] | select(.body | startswith("## Codex Review")) | .id' | rg -q '.' \
     && break
   sleep 10
 done
@@ -127,9 +127,9 @@ Exit codes:
 - If all jobs fail with corrupted pnpm lockfile errors on the merge commit, the
   remediation is to fetch latest `origin/main`, merge, force-push, and rerun CI.
 - If mergeability is `UNKNOWN`, wait and re-check.
-- Do not merge while review comments (human or Claude review) are outstanding.
-- Claude review jobs retry on failure and are non-blocking; use the presence of
-  `## Claude Review — <persona>` issue comments (not job status) as the signal
+- Do not merge while review comments (human or Codex review) are outstanding.
+- Codex review jobs retry on failure and are non-blocking; use the presence of
+  `## Codex Review — <persona>` issue comments (not job status) as the signal
   that review feedback is available.
 - Do not enable auto-merge; this repo has no required checks so auto-merge can
   skip tests.
@@ -139,8 +139,8 @@ Exit codes:
 
 ## Review Handling
 
-- Claude reviews now arrive as issue comments posted by GitHub Actions. They
-  start with `## Claude Review — <persona>` and include the reviewer’s
+- Codex reviews now arrive as issue comments posted by GitHub Actions. They
+  start with `## Codex Review — <persona>` and include the reviewer’s
   methodology + guardrails used. Treat these as feedback that must be
   acknowledged before merge.
 - Human review comments are blocking and must be addressed (responded to and
@@ -160,54 +160,54 @@ Exit codes:
   - Reply to a specific review comment:
     ```
     gh api -X POST /repos/{owner}/{repo}/pulls/<pr_number>/comments \
-      -f body='[claude] <response>' -F in_reply_to=<comment_id>
+      -f body='[codex] <response>' -F in_reply_to=<comment_id>
     ```
 - `in_reply_to` must be the numeric review comment id (e.g., `2710521800`), not
   the GraphQL node id (e.g., `PRRC_...`), and the endpoint must include the PR
   number (`/pulls/<pr_number>/comments`).
 - If GraphQL review reply mutation is forbidden, use REST.
 - A 404 on reply typically means the wrong endpoint (missing PR number) or
   insufficient scope; verify by listing comments first.
-- All GitHub comments generated by this agent must be prefixed with `[claude]`.
-- For Claude review issue comments, reply in the issue thread (not a review
-  thread) with `[claude]` and state whether you will address the feedback now or
+- All GitHub comments generated by this agent must be prefixed with `[codex]`.
+- For Codex review issue comments, reply in the issue thread (not a review
+  thread) with `[codex]` and state whether you will address the feedback now or
   defer it (include rationale).
 - If feedback requires changes:
   - For inline review comments (human), reply with intended fixes
-    (`[claude] ...`) **as an inline reply to the original review comment** using
+    (`[codex] ...`) **as an inline reply to the original review comment** using
     the review comment endpoint and `in_reply_to` (do not use issue comments for
     this).
   - Implement fixes, commit, push.
-  - Reply with the fix details and commit sha (`[claude] ...`) in the same place
-    you acknowledged the feedback (issue comment for Claude reviews, inline reply
+  - Reply with the fix details and commit sha (`[codex] ...`) in the same place
+    you acknowledged the feedback (issue comment for Codex reviews, inline reply
     for review comments).
-  - The land watcher treats Claude review issue comments as unresolved until a
-    newer `[claude]` issue comment is posted acknowledging the findings.
-- Only request a new Claude review when you need a rerun (e.g., after new
+  - The land watcher treats Codex review issue comments as unresolved until a
+    newer `[codex]` issue comment is posted acknowledging the findings.
+- Only request a new Codex review when you need a rerun (e.g., after new
   commits). Do not request one without changes since the last review.
-  - Before requesting a new Claude review, re-run the land watcher and ensure
-    there are zero outstanding review comments (all have `[claude]` inline
+  - Before requesting a new Codex review, re-run the land watcher and ensure
+    there are zero outstanding review comments (all have `[codex]` inline
     replies).
-  - After pushing new commits, the Claude review workflow will rerun on PR
+  - After pushing new commits, the Codex review workflow will rerun on PR
     synchronization (or you can re-run the workflow manually). Post a concise
     root-level summary comment so reviewers have the latest delta:
     ```
-    [claude] Changes since last review:
+    [codex] Changes since last review:
     - <short bullets of deltas>
     Commits: <sha>, <sha>
     Tests: <commands run>
     ```
   - Only request a new review if there is at least one new commit since the
     previous request.
-  - Wait for the next Claude review comment before merging.
+  - Wait for the next Codex review comment before merging.
 
 ## Scope + PR Metadata
 
 - The PR title and description should reflect the full scope of the change, not
   just the most recent fix.
 - If review feedback expands scope, decide whether to include it now or defer
   it. You can accept, defer, or decline feedback. If deferring or declining,
-  call it out in the root-level `[claude]` update with a brief reason (e.g.,
+  call it out in the root-level `[codex]` update with a brief reason (e.g.,
   out-of-scope, conflicts with intent, unnecessary).
 - Correctness issues raised in review comments should be addressed. If you plan
   to defer or decline a correctness concern, validate first and explain why the