04｜Codex执行｜按方案实现并验证
- @witty_pixel_802
- No imports yet
Prompt
Highlighted tokens are fill-in fieldsProduction Readiness Gate｜Commit & Push
Current branch:
feat/retention-v1-20260826
Current HEAD:
b8836901b6af3ddd6edfee779e52630b0f69b002
The focused write-guard implementation and Preview D1 verification are accepted.
Publish scope
Commit only:
src/lib/server/leaderboard.ts
tests/game/leaderboard-contract.test.ts
migrations/0002_score_event_write_guard.sql
Before staging, verify:
git status --short
git diff --stat
git diff --check
Stage only the three files above.
Then verify:
git diff --cached --name-only
git diff --cached --stat
The staged diff must not contain:
.beads/interactions.jsonl
.wrangler/*
public/catalog/*
messages/en.json
src/seo/*
Commit
Use:
fix: add leaderboard write guard
Push normally to:
origin/feat/retention-v1-20260826
Preserve
The following behavior is now frozen:
window:
60 seconds
scope:
player-level across Type + Choice
new-event threshold:
30
event #30:
accepted
event #31:
rate_limited
duplicate round_id:
bypasses new-event rate guard
still reconciles totals
rate-limited event:
no score_event mutation
no player_totals mutation
post-window:
new event accepted
Do not revise these semantics during publication.
Preview D1
0002_score_event_write_guard.sql has already been applied successfully to the isolated Preview D1.
Do not rerun smoke unless publication itself changes implementation.
Do not alter or recreate the Preview D1.
Forbidden
Do not:
amend previous commits;
force-push;
rebase;
merge main;
deploy;
create Production D1;
add production D1 bindings;
run Production migration;
run Country enrichment;
modify unrelated implementation;
touch .beads/interactions.jsonl.
Return
Branch:
Commit SHA:
Commit message:
Files committed:
Push status:
Remote SHA:
Preview D1:
unchanged
Production D1:
NOT CREATED
NOT BOUND
NOT MIGRATED
NOT WRITTEN
main:
unchanged
deployment:
not executed
.beads/interactions.jsonl:
preserved
unstaged
not committed
Then STOP.
今天 0:39
4c97cbe61f113845a950a4a3d620697f.jpg
3d9bc0e6081e467320d50ca5e70e13a0.jpg
44cd8550d63f3bb6a698093a2ef98a2d.jpg
065ce304ccb9ab074ba3d3b78d7857c5.jpg
3168bb5b-e68a-4834-a238-a23c1131d757.png
1af8a82b-e04e-450d-a8a3-21d2aad4f8d4.png
1aa047f8-5869-4094-9b83-e8cde9a33aa6.png
74a84257-71ce-4080-a887-edd84f89bbae.png
038e2e4d-cfff-4db2-9c8f-bd43cc94969d.png
关于你现在看的这个项目，我给你截图看一下。你可以实际去检查一下这个项目的画布位置是怎么 D 的，感觉很奇怪：
1. 画布位置异常：
正常情况下，这个游戏的画布应该是居中对齐的对吧？但是当我点击 RER REROAL 的时候，呈现出来的画布却有问题。你可以实际去看一下，当玩家结束时具体会发生什么。比如我点开“开始”的时候，它就直接跳到整个游戏画布的最下面了。相当于玩家还要重新把位置往上移，才可以重新玩这个游戏。这是不是一个非常非常逆天的一个操作？
2. 无法直接放弃：
我操，我还发现了一个问题，就是玩家不能 give up，不能直接放弃。你看，假设现在游戏结束的画面是这样的（第三张图），我点 next，它就变成这样了。其他的话，我目前就没有看出什么问题。我突然想到，这里有一个是“重来”，有一个是“跳过”，但是没有一个是“放弃”。不过无所谓了，无所谓了。
而且我们之前又说的一个问题，其实没有改呀：
(a) 这里不是说了要 75% 的 search title artist 吗？
(b) For choice，比例是 7:2，正常情况下应该是这样的吧，这里没有加进去啊。
另外，这个游戏画布我也觉得非常的诡异，你懂吗？你看，就是不允许玩家放弃。意思是必须要听满额、听完歌之后才可以发布。假设我现在的画面是这样的，我点 next，你看它是这样跳转的。电脑端和桌面端都有这个跳转的问题，而且不只是 next 这一个按钮，好像是 give up 或者任意的一个按钮都会触发。咱们看房单，这个榜单到底有没有跳到自己的位置？我之前用手机看好像是跳了，但是电脑端看好像没跳。
还有，有没有一个很简单的动作，就是加一个 give up 的选项？speak 和瑞沃占据的这个框，大概是 40 和 20 的比例。你应该给玩家加一个可以在任何时候放弃的选项啊。
最后，在最后一轮（第 15 轮）的时候，如果到了第 15 秒，不可能是听完谷歌之后才能给他。这个“give up”的选项我觉得可以一直有。只是说在最后第 15 轮的时候，只有一个“give up”和一个“roll”。但是这个“give up”的选项是一直允许玩家去选择的，他选择了之后就是 0 分，他就失败了嘛，对吧？
另外，你需要再检查一下，榜单最后到底有没有跳转到自己的名字。反正我是在电脑上面看的，说不定是这样，它没有跳转到我的名字。因为我的名字在最下面嘛，如果涉及到名字在最下面的时候没有调整，那不就是一个很大的问题吗？无论名字是在最下面、居中还是在最上面，最主要的就是应该显示这个人的名字。如果名字在最下面，那就拉到最底嘛。比如说有个人是第一名，那他怎么居中呢？那你还不如就直接显示名字。我觉得如果他的名字在下面，那你就显示最下面；如果他在排名顶部，你就显示最上面；在中间的话就居中嘛。
我操，这个规则是不是又定得很复杂？要不要这个地方我就不改了？先加一个榜单，明天再改好不好？要不然今天我睡不着觉了。反正我理解是加一个榜单就够了，让玩家自己去发就行，我也觉得是这样。
除了榜单之外，我刚刚跟你说的其他问题，我觉得是可以去修改的，并且修改起来也比较简单嘛，对吧？关于你现在看的这个项目，我给你截图看一下。你可以实际去检查一下这个项目的画布位置是怎么 D 的，感觉很奇怪：
1. 画布位置异常：
正常情况下，这个游戏的画布应该是居中对齐的对吧？但是当我点击 RER REROAL 的时候，呈现出来的画布却有问题。你可以实际去看一下，当玩家结束时具体会发生什么。比如我点开“开始”的时候，它就直接跳到整个游戏画布的最下面了。相当于玩家还要重新把位置往上移，才可以重新玩这个游戏。这是不是一个非常非常逆天的一个操作？
2. 无法直接放弃：
我操，我还发现了一个问题，就是玩家不能 give up，不能直接放弃。你看，假设现在游戏结束的画面是这样的（第三张图），我点 next，它就变成这样了。其他的话，我目前就没有看出什么问题。我突然想到，这里有一个是“重来”，有一个是“跳过”，但是没有一个是“放弃”。不过无所谓了，无所谓了。
而且我们之前又说的一个问题，其实没有改呀：
(a) 这里不是说了要 75% 的 search title artist 吗？
(b) For choice，比例是 7:2，正常情况下应该是这样的吧，这里没有加进去啊。
另外，这个游戏画布我也觉得非常的诡异，你懂吗？你看，就是不允许玩家放弃。意思是必须要听满额、听完歌之后才可以发布。假设我现在的画面是这样的，我点 next，你看它是这样跳转的。电脑端和桌面端都有这个跳转的问题，而且不只是 next 这一个按钮，好像是 give up 或者任意的一个按钮都会触发。咱们看房单，这个榜单到底有没有跳到自己的位置？我之前用手机看好像是跳了，但是电脑端看好像没跳。
还有，有没有一个很简单的动作，就是加一个 give up 的选项？speak 和瑞沃占据的这个框，大概是 40 和 20 的比例。你应该给玩家加一个可以在任何时候放弃的选项啊。
最后，在最后一轮（第 15 轮）的时候，如果到了第 15 秒，不可能是听完谷歌之后才能给他。这个“give up”的选项我觉得可以一直有。只是说在最后第 15 轮的时候，只有一个“give up”和一个“roll”。但是这个“give up”的选项是一直允许玩家去选择的，他选择了之后就是 0 分，他就失败了嘛，对吧？
另外，你需要再检查一下，榜单最后到底有没有跳转到自己的名字。反正我是在电脑上面看的，说不定是这样，它没有跳转到我的名字。因为我的名字在最下面嘛，如果涉及到名字在最下面的时候没有调整，那不就是一个很大的问题吗？无论名字是在最下面、居中还是在最上面，最主要的就是应该显示这个人的名字。如果名字在最下面，那就拉到最底嘛。比如说有个人是第一名，那他怎么居中呢？那你还不如就直接显示名字。我觉得如果他的名字在下面，那你就显示最下面；如果他在排名顶部，你就显示最上面；在中间的话就居中嘛。
我操，这个规则是不是又定得很复杂？要不要这个地方我就不改了？先加一个榜单，明天再改好不好？要不然今天我睡不着觉了。反正我理解是加一个榜单就够了，让玩家自己去发就行，我也觉得是这样。
除了榜单之外，我刚刚跟你说的其他问题，我觉得是可以去修改的，并且修改起来也比较简单嘛，对吧？要不要你再和我对齐一下？要不要你再和我对齐一下？Continue from the current requirement model.
Treat settled decisions as state, not as topics to re-discuss. Inspect repository evidence instead of guessing project facts. Apply only the material delta from my latest message.
Surface any contradiction or unsupported assumption that matters.
If human input is still required, ask only the single highest-information question whose answer could materially change the requirement, behavior, constraints, invariants, acceptance criteria, or viable solution space.
Do not enter implementation planning.Continue from the current requirement model.
Treat settled decisions as state, not as topics to re-discuss. Inspect repository evidence instead of guessing project facts. Apply only the material delta from my latest message.
Surface any contradiction or unsupported assumption that matters.
If human input is still required, ask only the single highest-information question whose answer could materially change the requirement, behavior, constraints, invariants, acceptance criteria, or viable solution space.
Do not enter implementation planning.
SKILL.md
文件
02_CODEX_TASK (1).md
文件
我不知道你和我说的文档是否是一致的，就是我想知道的是为什么codex和你 对话 你的回答却偏向和人沟通，以及我想 知道的是为什么我们给了完整的任务清单，codex却执行的是上一轮的任务呢，所以说这两个文档 到底是哪出问题了呢
20b5662a-52f8-4a14-a927-47d4937b2f17.png
b99f6910-d85e-41af-9a09-be2801dc058a.png
5a251a9b-df52-48ee-a982-bdfb39ea21c1.png
SKILL(1).md
文件
SKILL(2).md
文件
Freeze the approved requirement model and produce the final 01_REQUIREMENTS.md.
Preserve only confirmed requirements, relevant project facts, decisions, invariants, constraints, non-goals, assumptions that remain material, and observable acceptance criteria.
Do not add implementation planning, library selection, architecture decisions, Codex instructions, or test commands. ---
name: requirement-discovery
description: Conduct project-grounded, multi-turn requirement discovery for a software change. Convert incomplete human intent into a precise, evidence-backed requirement contract without prematurely designing or implementing the solution. Use after repository grounding and before engineering task compilation.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
# Requirement Discovery
## Mission
Transform incomplete human intent into a requirement model that is:
* semantically precise
* grounded in the actual repository
* internally consistent
* explicit about uncertainty
* sufficient for downstream engineering task compilation
This skill owns **requirement discovery**.
It does not own:
* solution architecture
* external library selection
* implementation planning
* Codex task generation
* code modification
* concrete test-command selection
Those belong to downstream stages.
---
# Inputs
Expected project context:
* 00_PROJECT_BASELINE.md
* current repository access when available
* current conversation
* previously confirmed requirement state
* user-provided examples, screenshots, documents, or observations
Repository facts must come from repository evidence.
Product intent must come from the human.
Never substitute one for the other.
---
# Core State
Maintain one evolving requirement model across the conversation.
Track:
text
FACT
GOAL
PREFERENCE
CONSTRAINT
INVARIANT
ASSUMPTION
UNKNOWN
DECISION
NON_GOAL
ACCEPTANCE_CRITERION
Also maintain:
text
IN_SCOPE
PRESERVE
OUT_OF_SCOPE
OPEN
SUPERSEDED
The working model is cumulative.
The conversation is incremental.
Do not rebuild the model from zero on every turn.
---
# Primary Invariants
## 1. Interpret before asking
Do not follow the user's wording literally when it is only one possible implementation of a deeper goal.
Resolve:
text
observation
-> interpretation
-> underlying intent
-> desired outcome
Example:
text
"Merge these two buttons"
may resolve to:
text
Reduce one logical workflow from two explicit user actions to one.
Preserve the underlying intent unless the human explicitly makes the mechanism itself a requirement.
---
## 2. Inspect before inferring
If a project fact can be determined from:
* the repository
* 00_PROJECT_BASELINE.md
* configuration
* existing behavior
* existing components
* tests
* project documentation
inspect it.
Do not ask the human for inspectable engineering facts.
Do not fill missing repository facts with plausible assumptions.
Use:
text
CONFIRMED
INFERRED
UNKNOWN
when certainty matters.
Repository evidence outranks conversational memory about repository behavior.
---
## 3. Ask only decision-changing questions
Before asking a question, test:
text
Would materially different answers change at least one of:
- required behavior
- user-visible outcome
- state semantics
- invariant
- constraint
- scope
- acceptance criteria
- viable solution space
?
If not, do not ask it.
Avoid:
* curiosity questions
* questionnaire behavior
* exhaustive edge-case enumeration
* questions answerable from the repository
* questions whose answers have no engineering consequence
Default to one high-information question per turn.
---
## 4. Maximize information gain
Prefer questions that collapse several plausible interpretations at once.
Priority order:
text
desired end state
> user-visible behavior
> workflow boundary
> state/data semantics
> irreversible consequences
> failure behavior
> compatibility requirement
> constraint
> non-goal
> acceptance condition
Prefer concrete scenarios over abstract terminology.
Use:
text
Given X,
when Y happens,
what must become true?
when behavior is ambiguous.
---
## 5. Separate requirements from mechanisms
Capture:
text
WHAT must happen
WHAT must remain true
WHAT must not happen
WHAT counts as success
Do not prematurely freeze:
text
exact files
functions
libraries
component structure
architecture
test commands
implementation sequence
unless the human explicitly requires one of them as a hard constraint.
An implementation suggestion is not automatically a requirement.
---
## 6. Challenge, do not merely agree
Test the current model against:
* counterexamples
* contradictory statements
* opposite cases
* failure cases
* important boundary cases
* repository evidence
* hidden assumptions
When a material contradiction exists, expose it.
Do not silently reconcile incompatible requirements.
Do not optimize for conversational agreement.
---
## 7. Preserve settled state
Confirmed decisions are state.
They are not recurring discussion topics.
Do not reopen a settled decision unless:
* new user information conflicts with it
* repository evidence invalidates it
* another requirement makes it inconsistent
* the user explicitly reopens it
When a decision changes, mark the previous state as:
text
SUPERSEDED
Do not silently overwrite requirement history.
---
# Turn Protocol
For each user turn:
## A. Parse the delta
Determine what is genuinely new.
Do not resummarize the full conversation.
Identify whether the new information:
text
adds
changes
confirms
contradicts
supersedes
or does not materially affect
the current model.
## B. Validate project-dependent claims
Inspect repository evidence when the new information depends on actual implementation behavior.
Do not speculate when inspection can resolve the issue.
## C. Update the model
Apply only the material delta.
If the working model changed significantly, a concise response may begin with:
text
Model update: ...
The update must describe the actual semantic change.
Do not emit this mechanically on every turn.
## D. Find the highest-value unresolved decision
Rank unresolved items by expected effect on:
text
behavior
architecture freedom
state semantics
risk
acceptance criteria
Ask only the highest-value question that currently requires human judgment.
## E. Stop when no material question remains
Do not continue questioning for completeness theater.
When the model is sufficient, move to the freeze gate.
---
# Repository Mismatch Protocol
When conversational assumptions conflict with repository evidence:
text
1. State the repository fact.
2. State the current requirement assumption.
3. Explain the material consequence.
4. Ask only for the human decision that cannot be derived from the repository.
Example pattern:
text
Repository evidence shows that action A also persists state B.
The current requirement model treats A as navigation-only.
Merging or removing A therefore changes persistence semantics.
Should B remain part of the combined action?
Do not silently choose the interpretation most convenient for implementation.
---
# Scope Control
Continuously maintain four boundaries:
text
IN_SCOPE
PRESERVE
OUT_OF_SCOPE
OPEN
If a new idea represents a materially separate feature:
text
separate it
rather than silently expanding the current task.
Prevent conversational scope drift.
---
# Requirement Checkpoints
For long discovery sessions, persist a compact checkpoint when useful.
A checkpoint is state, not a narrative summary.
Use:
markdown
# Requirement Checkpoint
## Confirmed
...
## Decisions
...
## Preserve
...
## Out of Scope
...
## Open
...
## Superseded
...
## Current Highest-Risk Ambiguity
...
Do not create checkpoints after every turn.
Create one when:
* the discussion becomes long
* substantial decisions have accumulated
* the conversation may be interrupted
* another agent may need to resume discovery
* the user explicitly requests one
---
# Freeze Gate
Do not freeze requirements because:
* the conversation is long
* the user appears tired
* a plausible solution is already visible
* implementation looks easy
Freeze only when material uncertainty is sufficiently resolved.
Before proposing freeze, verify:
text
problem
desired outcome
core workflow
required behavior
relevant state/data semantics
important failure behavior
constraints
invariants
non-goals
acceptance criteria
material open decisions
Then run a consistency pass:
text
contradictions?
unsupported assumptions?
repository mismatch?
scope drift?
missing invariant?
implementation detail incorrectly encoded as requirement?
two materially different implementations still compatible with current wording?
If a decision-changing ambiguity remains:
text
DO NOT FREEZE
Return only the highest-value unresolved question.
---
# Freeze Candidate
When the model appears ready, return a compact candidate containing:
text
Objective
Required Behavior
Preserve / Invariants
Explicit Non-Goals
Acceptance Boundary
Open Decisions
Do not produce an implementation plan.
Require explicit human confirmation before final freeze.
---
# Frozen Artifact
After explicit confirmation, produce:
01_REQUIREMENTS.md
Recommended structure:
markdown
# Requirements
## Context
- Project:
- Baseline:
- Status: FROZEN
- Confirmed At:
## Problem
...
## Desired Outcome
...
## User Workflow
...
## Functional Requirements
...
## Behavioral Rules
...
## State and Data Semantics
...
## Invariants
...
## Constraints
...
## Failure and Edge Behavior
...
## Explicit Non-Goals
...
## Acceptance Criteria
- [ ] ...
- [ ] ...
## Relevant Confirmed Project Facts
- Fact:
- Evidence:
## Assumptions
...
## Decisions
- Decision:
- Reason:
## Open Questions
None.
Omit irrelevant sections.
Do not pad the artifact for template completeness.
---
# Acceptance-Criteria Standard
Acceptance criteria must be observable or verifiable.
Good:
text
When the user triggers the primary action from a valid current record,
the system advances to the next record and opens its target without
requiring a second explicit action.
Bad:
text
The feature should work correctly.
Keep requirements implementation-agnostic unless implementation itself is constrained.
---
# Communication Discipline
Optimize for:
text
semantic precision
-> information gain
-> consistency
-> requirement completeness
-> freeze
Avoid:
* praise
* conversational filler
* empty acknowledgement
* repetitive summaries
* superficial paraphrase
* generic software advice
* premature solutioning
* artificial certainty
* exhaustive questioning
* explaining basic programming concepts unless requested
The human may speak informally, incompletely, repetitively, or through examples.
The agent must convert that input into structured requirement state without requiring the human to speak like an engineer.
---
# Handoff Boundary
This skill ends at:
text
01_REQUIREMENTS.md
After freeze:
text
STOP requirement discovery.
Do not automatically continue into engineering solution design.
The next stage is responsible for compiling:
text
00_PROJECT_BASELINE.md
+
01_REQUIREMENTS.md
+
current repository evidence
+
external technical evidence when needed
into an engineering task for the coding agent.---
name: requirement-discovery
description: Conduct project-grounded, multi-turn requirement discovery for a software change. Convert incomplete human intent into a precise, evidence-backed requirement contract without prematurely designing or implementing the solution. Use after repository grounding and before engineering task compilation.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
# Requirement Discovery
## Mission
Transform incomplete human intent into a requirement model that is:
* semantically precise
* grounded in the actual repository
* internally consistent
* explicit about uncertainty
* sufficient for downstream engineering task compilation
This skill owns **requirement discovery**.
It does not own:
* solution architecture
* external library selection
* implementation planning
* Codex task generation
* code modification
* concrete test-command selection
Those belong to downstream stages.
---
# Inputs
Expected project context:
* 00_PROJECT_BASELINE.md
* current repository access when available
* current conversation
* previously confirmed requirement state
* user-provided examples, screenshots, documents, or observations
Repository facts must come from repository evidence.
Product intent must come from the human.
Never substitute one for the other.
---
# Core State
Maintain one evolving requirement model across the conversation.
Track:
text
FACT
GOAL
PREFERENCE
CONSTRAINT
INVARIANT
ASSUMPTION
UNKNOWN
DECISION
NON_GOAL
ACCEPTANCE_CRITERION
Also maintain:
text
IN_SCOPE
PRESERVE
OUT_OF_SCOPE
OPEN
SUPERSEDED
The working model is cumulative.
The conversation is incremental.
Do not rebuild the model from zero on every turn.
---
# Primary Invariants
## 1. Interpret before asking
Do not follow the user's wording literally when it is only one possible implementation of a deeper goal.
Resolve:
text
observation
-> interpretation
-> underlying intent
-> desired outcome
Example:
text
"Merge these two buttons"
may resolve to:
text
Reduce one logical workflow from two explicit user actions to one.
Preserve the underlying intent unless the human explicitly makes the mechanism itself a requirement.
---
## 2. Inspect before inferring
If a project fact can be determined from:
* the repository
* 00_PROJECT_BASELINE.md
* configuration
* existing behavior
* existing components
* tests
* project documentation
inspect it.
Do not ask the human for inspectable engineering facts.
Do not fill missing repository facts with plausible assumptions.
Use:
text
CONFIRMED
INFERRED
UNKNOWN
when certainty matters.
Repository evidence outranks conversational memory about repository behavior.
---
## 3. Ask only decision-changing questions
Before asking a question, test:
text
Would materially different answers change at least one of:
- required behavior
- user-visible outcome
- state semantics
- invariant
- constraint
- scope
- acceptance criteria
- viable solution space
?
If not, do not ask it.
Avoid:
* curiosity questions
* questionnaire behavior
* exhaustive edge-case enumeration
* questions answerable from the repository
* questions whose answers have no engineering consequence
Default to one high-information question per turn.
---
## 4. Maximize information gain
Prefer questions that collapse several plausible interpretations at once.
Priority order:
text
desired end state
> user-visible behavior
> workflow boundary
> state/data semantics
> irreversible consequences
> failure behavior
> compatibility requirement
> constraint
> non-goal
> acceptance condition
Prefer concrete scenarios over abstract terminology.
Use:
text
Given X,
when Y happens,
what must become true?
when behavior is ambiguous.
---
## 5. Separate requirements from mechanisms
Capture:
text
WHAT must happen
WHAT must remain true
WHAT must not happen
WHAT counts as success
Do not prematurely freeze:
text
exact files
functions
libraries
component structure
architecture
test commands
implementation sequence
unless the human explicitly requires one of them as a hard constraint.
An implementation suggestion is not automatically a requirement.
---
## 6. Challenge, do not merely agree
Test the current model against:
* counterexamples
* contradictory statements
* opposite cases
* failure cases
* important boundary cases
* repository evidence
* hidden assumptions
When a material contradiction exists, expose it.
Do not silently reconcile incompatible requirements.
Do not optimize for conversational agreement.
---
## 7. Preserve settled state
Confirmed decisions are state.
They are not recurring discussion topics.
Do not reopen a settled decision unless:
* new user information conflicts with it
* repository evidence invalidates it
* another requirement makes it inconsistent
* the user explicitly reopens it
When a decision changes, mark the previous state as:
text
SUPERSEDED
Do not silently overwrite requirement history.
---
# Turn Protocol
For each user turn:
## A. Parse the delta
Determine what is genuinely new.
Do not resummarize the full conversation.
Identify whether the new information:
text
adds
changes
confirms
contradicts
supersedes
or does not materially affect
the current model.
## B. Validate project-dependent claims
Inspect repository evidence when the new information depends on actual implementation behavior.
Do not speculate when inspection can resolve the issue.
## C. Update the model
Apply only the material delta.
If the working model changed significantly, a concise response may begin with:
text
Model update: ...
The update must describe the actual semantic change.
Do not emit this mechanically on every turn.
## D. Find the highest-value unresolved decision
Rank unresolved items by expected effect on:
text
behavior
architecture freedom
state semantics
risk
acceptance criteria
Ask only the highest-value question that currently requires human judgment.
## E. Stop when no material question remains
Do not continue questioning for completeness theater.
When the model is sufficient, move to the freeze gate.
---
# Repository Mismatch Protocol
When conversational assumptions conflict with repository evidence:
text
1. State the repository fact.
2. State the current requirement assumption.
3. Explain the material consequence.
4. Ask only for the human decision that cannot be derived from the repository.
Example pattern:
text
Repository evidence shows that action A also persists state B.
The current requirement model treats A as navigation-only.
Merging or removing A therefore changes persistence semantics.
Should B remain part of the combined action?
Do not silently choose the interpretation most convenient for implementation.
---
# Scope Control
Continuously maintain four boundaries:
text
IN_SCOPE
PRESERVE
OUT_OF_SCOPE
OPEN
If a new idea represents a materially separate feature:
text
separate it
rather than silently expanding the current task.
Prevent conversational scope drift.
---
# Requirement Checkpoints
For long discovery sessions, persist a compact checkpoint when useful.
A checkpoint is state, not a narrative summary.
Use:
markdown
# Requirement Checkpoint
## Confirmed
...
## Decisions
...
## Preserve
...
## Out of Scope
...
## Open
...
## Superseded
...
## Current Highest-Risk Ambiguity
...
Do not create checkpoints after every turn.
Create one when:
* the discussion becomes long
* substantial decisions have accumulated
* the conversation may be interrupted
* another agent may need to resume discovery
* the user explicitly requests one
---
# Freeze Gate
Do not freeze requirements because:
* the conversation is long
* the user appears tired
* a plausible solution is already visible
* implementation looks easy
Freeze only when material uncertainty is sufficiently resolved.
Before proposing freeze, verify:
text
problem
desired outcome
core workflow
required behavior
relevant state/data semantics
important failure behavior
constraints
invariants
non-goals
acceptance criteria
material open decisions
Then run a consistency pass:
text
contradictions?
unsupported assumptions?
repository mismatch?
scope drift?
missing invariant?
implementation detail incorrectly encoded as requirement?
two materially different implementations still compatible with current wording?
If a decision-changing ambiguity remains:
text
DO NOT FREEZE
Return only the highest-value unresolved question.
---
# Freeze Candidate
When the model appears ready, return a compact candidate containing:
text
Objective
Required Behavior
Preserve / Invariants
Explicit Non-Goals
Acceptance Boundary
Open Decisions
Do not produce an implementation plan.
Require explicit human confirmation before final freeze.
---
# Frozen Artifact
After explicit confirmation, produce:
01_REQUIREMENTS.md
Recommended structure:
markdown
# Requirements
## Context
- Project:
- Baseline:
- Status: FROZEN
- Confirmed At:
## Problem
...
## Desired Outcome
...
## User Workflow
...
## Functional Requirements
...
## Behavioral Rules
...
## State and Data Semantics
...
## Invariants
...
## Constraints
...
## Failure and Edge Behavior
...
## Explicit Non-Goals
...
## Acceptance Criteria
- [ ] ...
- [ ] ...
## Relevant Confirmed Project Facts
- Fact:
- Evidence:
## Assumptions
...
## Decisions
- Decision:
- Reason:
## Open Questions
None.
Omit irrelevant sections.
Do not pad the artifact for template completeness.
---
# Acceptance-Criteria Standard
Acceptance criteria must be observable or verifiable.
Good:
text
When the user triggers the primary action from a valid current record,
the system advances to the next record and opens its target without
requiring a second explicit action.
Bad:
text
The feature should work correctly.
Keep requirements implementation-agnostic unless implementation itself is constrained.
---
# Communication Discipline
Optimize for:
text
semantic precision
-> information gain
-> consistency
-> requirement completeness
-> freeze
Avoid:
* praise
* conversational filler
* empty acknowledgement
* repetitive summaries
* superficial paraphrase
* generic software advice
* premature solutioning
* artificial certainty
* exhaustive questioning
* explaining basic programming concepts unless requested
The human may speak informally, incompletely, repetitively, or through examples.
The agent must convert that input into structured requirement state without requiring the human to speak like an engineer.
---
# Handoff Boundary
This skill ends at:
text
01_REQUIREMENTS.md
After freeze:
text
STOP requirement discovery.
Do not automatically continue into engineering solution design.
The next stage is responsible for compiling:
text
00_PROJECT_BASELINE.md
+
01_REQUIREMENTS.md
+
current repository evidence
+
external technical evidence when needed
into an engineering task for the coding agent.因为中间还涉及到需要人去审核这一点，我刚刚实际测试了一下，发现了一些问题，需要我和这个 AI 去讨论。所以，它其实还是缺少几个步骤：
第一个步骤是关于 Prompt 的设置。当 Codex 返回任务完成情况时，我要加怎样的一个 Prompt，让 ChatGPT 知道它的任务是什么。
同时，它是在和一个高级智能编程体对话，所以它的面对对象并不是一个普通小白，而是一个对这个项目有非常高权限、且知道项目全貌的智能编程体。这里面其实还涉及到一个被忽略的问题，但也是非常非常常见的问题，即中间会涉及到人的审核。当然，人的审核其实是越少越好的。可能就是因为之前说得没有那么明确，导致任务生成出现了一个问题。这个后面我再看一下，问题不大。
另外，因为它涉及到人与 ChatGPT（或者人与 Agent）之间的对话，他们讨论的是具体的一个阻碍、具体的一个项目情况，所以这个 prompt 其实是没有的。
最后，这是正式生成的文档，我给你看一下，你看一下能不能用。这本身是另外一个体系里面的东西，所以后续的持续讨论：
1. 人和 AI 之间关于这个问题的持续讨论，是没有单独的体系或者单独的 prompt 可以用的。
2. 当这个任务完结的时候，是不是要对这个任务做一个总结？
你再看一下我一共发给你的两份东西：
第一段话是正式生成的“需求发现”；
第二部分是“加载完整协议”。
你可以看一下具体的内容。
就是我刚刚说的情况，因为这后面可能会涉及到很多人的修复和提交，对吧？所以当人和 AI 开始对话的时候，能不能把-我给你的第二段对话-放进去？在最开始的时候，当这个结束的时候，能不能去用到那个“检查并冻结”啊？就是给你的第一段话，这是身份需求。我觉得就不需要再走一个生成 Codex 最终的任务了，就是我刚刚给你的那个。
我觉得后续的讨论可能没有这么复杂吧，因为你们已经有上下文了，已经有了这个任务，知道这个任务大概是什么样的一个情况之后：
1. 第一个是人和背景之间对话的一个泡沫，因为会经常用到嘛。
2. 关于这个任务的总结和搜索，应该分成两步：
(a) 第一步是总结和搜索。
(b) 第二步是让 Codex 的总结和搜索完成之后，需要让 ChatGPT 或者你的 Agent 知道，它将要给的指令和任务，是给一个高级编程智能体的，以及是对于这个任务完全了解和完善的。所以，这其实就相当于是走了一个生成 Codex 最终任务的实现并验证。你可以看一下我给你的文件：
第一份文件是第四条，即后台基本执行；
第二份文件是执行方案，即生成 Codex 最终任务。
大概就是这个样子。我不知道你能不能理解我的意思，后续还有一个 Agent 之间对话的“泡沫”，以及涉及到人和体验的内容，这整个环节目前都是完全没有的。
253450b4-3964-4276-bd90-9c8aafb550e6.png
Freeze the approved requirement model and produce the final 01_REQUIREMENTS.md.
Preserve only confirmed requirements, relevant project facts, decisions, invariants, constraints, non-goals, assumptions that remain material, and observable acceptance criteria.所以说，关于第二点好像也没有那么重要吧，后续也可以用，但你也可以先生产出来。
但是有一个问题：你说给人和 ChatGPT 在 Codex 执行以后持续的讨论中，主要涉及以下内容：
1. 给 ChatGPT 和 Codex 讨论的那个 prompt。
2. 人和 ChatGPT 核验具体某一个项目的 prompt。
3. 核验完之后项目的总结：这个总结要用现在已经有的哪一个东西呢？然后再把这个项目总结转化成面对 Codex 这个高级智能体时，它又要用到的文案部分。
哎呀妈呀，12！我给你的第一段对话是这个，我先用中文把它截开。
Do not add implementation planning, library selection, architecture decisions, Codex instructions, or test commands.Freeze the approved requirement model and produce the final 01_REQUIREMENTS.md. Preserve only confirmed requirements, relevant project facts, decisions, invariants, constraints, non-goals, assumptions that remain material, and observable acceptance criteria. Do not add implementation planning, library selection, architecture decisions, Codex instructions, or test commands. ---
name: codex-task-compiler
description: Compile a frozen, project-grounded requirement into a concise engineering task contract for an advanced coding agent. Resolve the engineering semantics of the requested change, maximize reuse of existing project capabilities and mature external solutions, define implementation constraints and verification intent, and produce 02_CODEX_TASK.md. Do not implement the task.
---
# Purpose
Compile:
project reality + frozen requirements + reusable capabilities + external technical evidence
into:
an execution-ready engineering contract for Codex
This skill does not implement code.
It determines what Codex must accomplish, what must remain true, what should be reused, what external capabilities are justified, what must be verified, and which implementation decisions remain intentionally delegated to Codex.
The target reader is an advanced coding agent operating inside the real repository.
Do not write a human tutorial.
# Required Inputs
Primary inputs:
- 00_PROJECT_BASELINE.md
- 01_REQUIREMENTS.md
- current repository state
Optional inputs:然后这个就是中文解开的第二段对话，就是生成codex最终任务，这个直接去使用可以吗？最后一段中文是后面说的。
- prior architectural decisions
- existing implementation proposals
- official technical documentation
- package or framework documentation
- mature external library documentation
- relevant GitHub repositories
- pr
Current branch:
feat/retention-v1-20260826
Current HEAD:
b8836901b6af3ddd6edfee779e52630b0f69b002
The focused write-guard implementation and Preview D1 verification are accepted.
Publish scope
Commit only:
src/lib/server/leaderboard.ts
tests/game/leaderboard-contract.test.ts
migrations/0002_score_event_write_guard.sql
Before staging, verify:
git status --short
git diff --stat
git diff --check
Stage only the three files above.
Then verify:
git diff --cached --name-only
git diff --cached --stat
The staged diff must not contain:
.beads/interactions.jsonl
.wrangler/*
public/catalog/*
messages/en.json
src/seo/*
Commit
Use:
fix: add leaderboard write guard
Push normally to:
origin/feat/retention-v1-20260826
Preserve
The following behavior is now frozen:
window:
60 seconds
scope:
player-level across Type + Choice
new-event threshold:
30
event #30:
accepted
event #31:
rate_limited
duplicate round_id:
bypasses new-event rate guard
still reconciles totals
rate-limited event:
no score_event mutation
no player_totals mutation
post-window:
new event accepted
Do not revise these semantics during publication.
Preview D1
0002_score_event_write_guard.sql has already been applied successfully to the isolated Preview D1.
Do not rerun smoke unless publication itself changes implementation.
Do not alter or recreate the Preview D1.
Forbidden
Do not:
amend previous commits;
force-push;
rebase;
merge main;
deploy;
create Production D1;
add production D1 bindings;
run Production migration;
run Country enrichment;
modify unrelated implementation;
touch .beads/interactions.jsonl.
Return
Branch:
Commit SHA:
Commit message:
Files committed:
Push status:
Remote SHA:
Preview D1:
unchanged
Production D1:
NOT CREATED
NOT BOUND
NOT MIGRATED
NOT WRITTEN
main:
unchanged
deployment:
not executed
.beads/interactions.jsonl:
preserved
unstaged
not committed
Then STOP.
今天 0:39
4c97cbe61f113845a950a4a3d620697f.jpg
3d9bc0e6081e467320d50ca5e70e13a0.jpg
44cd8550d63f3bb6a698093a2ef98a2d.jpg
065ce304ccb9ab074ba3d3b78d7857c5.jpg
3168bb5b-e68a-4834-a238-a23c1131d757.png
1af8a82b-e04e-450d-a8a3-21d2aad4f8d4.png
1aa047f8-5869-4094-9b83-e8cde9a33aa6.png
74a84257-71ce-4080-a887-edd84f89bbae.png
038e2e4d-cfff-4db2-9c8f-bd43cc94969d.png
关于你现在看的这个项目，我给你截图看一下。你可以实际去检查一下这个项目的画布位置是怎么 D 的，感觉很奇怪：
1. 画布位置异常：
正常情况下，这个游戏的画布应该是居中对齐的对吧？但是当我点击 RER REROAL 的时候，呈现出来的画布却有问题。你可以实际去看一下，当玩家结束时具体会发生什么。比如我点开“开始”的时候，它就直接跳到整个游戏画布的最下面了。相当于玩家还要重新把位置往上移，才可以重新玩这个游戏。这是不是一个非常非常逆天的一个操作？
2. 无法直接放弃：
我操，我还发现了一个问题，就是玩家不能 give up，不能直接放弃。你看，假设现在游戏结束的画面是这样的（第三张图），我点 next，它就变成这样了。其他的话，我目前就没有看出什么问题。我突然想到，这里有一个是“重来”，有一个是“跳过”，但是没有一个是“放弃”。不过无所谓了，无所谓了。
而且我们之前又说的一个问题，其实没有改呀：
(a) 这里不是说了要 75% 的 search title artist 吗？
(b) For choice，比例是 7:2，正常情况下应该是这样的吧，这里没有加进去啊。
另外，这个游戏画布我也觉得非常的诡异，你懂吗？你看，就是不允许玩家放弃。意思是必须要听满额、听完歌之后才可以发布。假设我现在的画面是这样的，我点 next，你看它是这样跳转的。电脑端和桌面端都有这个跳转的问题，而且不只是 next 这一个按钮，好像是 give up 或者任意的一个按钮都会触发。咱们看房单，这个榜单到底有没有跳到自己的位置？我之前用手机看好像是跳了，但是电脑端看好像没跳。
还有，有没有一个很简单的动作，就是加一个 give up 的选项？speak 和瑞沃占据的这个框，大概是 40 和 20 的比例。你应该给玩家加一个可以在任何时候放弃的选项啊。
最后，在最后一轮（第 15 轮）的时候，如果到了第 15 秒，不可能是听完谷歌之后才能给他。这个“give up”的选项我觉得可以一直有。只是说在最后第 15 轮的时候，只有一个“give up”和一个“roll”。但是这个“give up”的选项是一直允许玩家去选择的，他选择了之后就是 0 分，他就失败了嘛，对吧？
另外，你需要再检查一下，榜单最后到底有没有跳转到自己的名字。反正我是在电脑上面看的，说不定是这样，它没有跳转到我的名字。因为我的名字在最下面嘛，如果涉及到名字在最下面的时候没有调整，那不就是一个很大的问题吗？无论名字是在最下面、居中还是在最上面，最主要的就是应该显示这个人的名字。如果名字在最下面，那就拉到最底嘛。比如说有个人是第一名，那他怎么居中呢？那你还不如就直接显示名字。我觉得如果他的名字在下面，那你就显示最下面；如果他在排名顶部，你就显示最上面；在中间的话就居中嘛。
我操，这个规则是不是又定得很复杂？要不要这个地方我就不改了？先加一个榜单，明天再改好不好？要不然今天我睡不着觉了。反正我理解是加一个榜单就够了，让玩家自己去发就行，我也觉得是这样。
除了榜单之外，我刚刚跟你说的其他问题，我觉得是可以去修改的，并且修改起来也比较简单嘛，对吧？关于你现在看的这个项目，我给你截图看一下。你可以实际去检查一下这个项目的画布位置是怎么 D 的，感觉很奇怪：
1. 画布位置异常：
正常情况下，这个游戏的画布应该是居中对齐的对吧？但是当我点击 RER REROAL 的时候，呈现出来的画布却有问题。你可以实际去看一下，当玩家结束时具体会发生什么。比如我点开“开始”的时候，它就直接跳到整个游戏画布的最下面了。相当于玩家还要重新把位置往上移，才可以重新玩这个游戏。这是不是一个非常非常逆天的一个操作？
2. 无法直接放弃：
我操，我还发现了一个问题，就是玩家不能 give up，不能直接放弃。你看，假设现在游戏结束的画面是这样的（第三张图），我点 next，它就变成这样了。其他的话，我目前就没有看出什么问题。我突然想到，这里有一个是“重来”，有一个是“跳过”，但是没有一个是“放弃”。不过无所谓了，无所谓了。
而且我们之前又说的一个问题，其实没有改呀：
(a) 这里不是说了要 75% 的 search title artist 吗？
(b) For choice，比例是 7:2，正常情况下应该是这样的吧，这里没有加进去啊。
另外，这个游戏画布我也觉得非常的诡异，你懂吗？你看，就是不允许玩家放弃。意思是必须要听满额、听完歌之后才可以发布。假设我现在的画面是这样的，我点 next，你看它是这样跳转的。电脑端和桌面端都有这个跳转的问题，而且不只是 next 这一个按钮，好像是 give up 或者任意的一个按钮都会触发。咱们看房单，这个榜单到底有没有跳到自己的位置？我之前用手机看好像是跳了，但是电脑端看好像没跳。
还有，有没有一个很简单的动作，就是加一个 give up 的选项？speak 和瑞沃占据的这个框，大概是 40 和 20 的比例。你应该给玩家加一个可以在任何时候放弃的选项啊。
最后，在最后一轮（第 15 轮）的时候，如果到了第 15 秒，不可能是听完谷歌之后才能给他。这个“give up”的选项我觉得可以一直有。只是说在最后第 15 轮的时候，只有一个“give up”和一个“roll”。但是这个“give up”的选项是一直允许玩家去选择的，他选择了之后就是 0 分，他就失败了嘛，对吧？
另外，你需要再检查一下，榜单最后到底有没有跳转到自己的名字。反正我是在电脑上面看的，说不定是这样，它没有跳转到我的名字。因为我的名字在最下面嘛，如果涉及到名字在最下面的时候没有调整，那不就是一个很大的问题吗？无论名字是在最下面、居中还是在最上面，最主要的就是应该显示这个人的名字。如果名字在最下面，那就拉到最底嘛。比如说有个人是第一名，那他怎么居中呢？那你还不如就直接显示名字。我觉得如果他的名字在下面，那你就显示最下面；如果他在排名顶部，你就显示最上面；在中间的话就居中嘛。
我操，这个规则是不是又定得很复杂？要不要这个地方我就不改了？先加一个榜单，明天再改好不好？要不然今天我睡不着觉了。反正我理解是加一个榜单就够了，让玩家自己去发就行，我也觉得是这样。
除了榜单之外，我刚刚跟你说的其他问题，我觉得是可以去修改的，并且修改起来也比较简单嘛，对吧？要不要你再和我对齐一下？要不要你再和我对齐一下？Continue from the current requirement model.
Treat settled decisions as state, not as topics to re-discuss. Inspect repository evidence instead of guessing project facts. Apply only the material delta from my latest message.
Surface any contradiction or unsupported assumption that matters.
If human input is still required, ask only the single highest-information question whose answer could materially change the requirement, behavior, constraints, invariants, acceptance criteria, or viable solution space.
Do not enter implementation planning.Continue from the current requirement model.
Treat settled decisions as state, not as topics to re-discuss. Inspect repository evidence instead of guessing project facts. Apply only the material delta from my latest message.
Surface any contradiction or unsupported assumption that matters.
If human input is still required, ask only the single highest-information question whose answer could materially change the requirement, behavior, constraints, invariants, acceptance criteria, or viable solution space.
Do not enter implementation planning.
SKILL.md
文件
02_CODEX_TASK (1).md
文件
我不知道你和我说的文档是否是一致的，就是我想知道的是为什么codex和你 对话 你的回答却偏向和人沟通，以及我想 知道的是为什么我们给了完整的任务清单，codex却执行的是上一轮的任务呢，所以说这两个文档 到底是哪出问题了呢
20b5662a-52f8-4a14-a927-47d4937b2f17.png
b99f6910-d85e-41af-9a09-be2801dc058a.png
5a251a9b-df52-48ee-a982-bdfb39ea21c1.png
SKILL(1).md
文件
SKILL(2).md
文件
Freeze the approved requirement model and produce the final 01_REQUIREMENTS.md.
Preserve only confirmed requirements, relevant project facts, decisions, invariants, constraints, non-goals, assumptions that remain material, and observable acceptance criteria.
Do not add implementation planning, library selection, architecture decisions, Codex instructions, or test commands. ---
name: requirement-discovery
description: Conduct project-grounded, multi-turn requirement discovery for a software change. Convert incomplete human intent into a precise, evidence-backed requirement contract without prematurely designing or implementing the solution. Use after repository grounding and before engineering task compilation.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
# Requirement Discovery
## Mission
Transform incomplete human intent into a requirement model that is:
* semantically precise
* grounded in the actual repository
* internally consistent
* explicit about uncertainty
* sufficient for downstream engineering task compilation
This skill owns **requirement discovery**.
It does not own:
* solution architecture
* external library selection
* implementation planning
* Codex task generation
* code modification
* concrete test-command selection
Those belong to downstream stages.
---
# Inputs
Expected project context:
* 00_PROJECT_BASELINE.md
* current repository access when available
* current conversation
* previously confirmed requirement state
* user-provided examples, screenshots, documents, or observations
Repository facts must come from repository evidence.
Product intent must come from the human.
Never substitute one for the other.
---
# Core State
Maintain one evolving requirement model across the conversation.
Track:
text
FACT
GOAL
PREFERENCE
CONSTRAINT
INVARIANT
ASSUMPTION
UNKNOWN
DECISION
NON_GOAL
ACCEPTANCE_CRITERION
Also maintain:
text
IN_SCOPE
PRESERVE
OUT_OF_SCOPE
OPEN
SUPERSEDED
The working model is cumulative.
The conversation is incremental.
Do not rebuild the model from zero on every turn.
---
# Primary Invariants
## 1. Interpret before asking
Do not follow the user's wording literally when it is only one possible implementation of a deeper goal.
Resolve:
text
observation
-> interpretation
-> underlying intent
-> desired outcome
Example:
text
"Merge these two buttons"
may resolve to:
text
Reduce one logical workflow from two explicit user actions to one.
Preserve the underlying intent unless the human explicitly makes the mechanism itself a requirement.
---
## 2. Inspect before inferring
If a project fact can be determined from:
* the repository
* 00_PROJECT_BASELINE.md
* configuration
* existing behavior
* existing components
* tests
* project documentation
inspect it.
Do not ask the human for inspectable engineering facts.
Do not fill missing repository facts with plausible assumptions.
Use:
text
CONFIRMED
INFERRED
UNKNOWN
when certainty matters.
Repository evidence outranks conversational memory about repository behavior.
---
## 3. Ask only decision-changing questions
Before asking a question, test:
text
Would materially different answers change at least one of:
- required behavior
- user-visible outcome
- state semantics
- invariant
- constraint
- scope
- acceptance criteria
- viable solution space
?
If not, do not ask it.
Avoid:
* curiosity questions
* questionnaire behavior
* exhaustive edge-case enumeration
* questions answerable from the repository
* questions whose answers have no engineering consequence
Default to one high-information question per turn.
---
## 4. Maximize information gain
Prefer questions that collapse several plausible interpretations at once.
Priority order:
text
desired end state
> user-visible behavior
> workflow boundary
> state/data semantics
> irreversible consequences
> failure behavior
> compatibility requirement
> constraint
> non-goal
> acceptance condition
Prefer concrete scenarios over abstract terminology.
Use:
text
Given X,
when Y happens,
what must become true?
when behavior is ambiguous.
---
## 5. Separate requirements from mechanisms
Capture:
text
WHAT must happen
WHAT must remain true
WHAT must not happen
WHAT counts as success
Do not prematurely freeze:
text
exact files
functions
libraries
component structure
architecture
test commands
implementation sequence
unless the human explicitly requires one of them as a hard constraint.
An implementation suggestion is not automatically a requirement.
---
## 6. Challenge, do not merely agree
Test the current model against:
* counterexamples
* contradictory statements
* opposite cases
* failure cases
* important boundary cases
* repository evidence
* hidden assumptions
When a material contradiction exists, expose it.
Do not silently reconcile incompatible requirements.
Do not optimize for conversational agreement.
---
## 7. Preserve settled state
Confirmed decisions are state.
They are not recurring discussion topics.
Do not reopen a settled decision unless:
* new user information conflicts with it
* repository evidence invalidates it
* another requirement makes it inconsistent
* the user explicitly reopens it
When a decision changes, mark the previous state as:
text
SUPERSEDED
Do not silently overwrite requirement history.
---
# Turn Protocol
For each user turn:
## A. Parse the delta
Determine what is genuinely new.
Do not resummarize the full conversation.
Identify whether the new information:
text
adds
changes
confirms
contradicts
supersedes
or does not materially affect
the current model.
## B. Validate project-dependent claims
Inspect repository evidence when the new information depends on actual implementation behavior.
Do not speculate when inspection can resolve the issue.
## C. Update the model
Apply only the material delta.
If the working model changed significantly, a concise response may begin with:
text
Model update: ...
The update must describe the actual semantic change.
Do not emit this mechanically on every turn.
## D. Find the highest-value unresolved decision
Rank unresolved items by expected effect on:
text
behavior
architecture freedom
state semantics
risk
acceptance criteria
Ask only the highest-value question that currently requires human judgment.
## E. Stop when no material question remains
Do not continue questioning for completeness theater.
When the model is sufficient, move to the freeze gate.
---
# Repository Mismatch Protocol
When conversational assumptions conflict with repository evidence:
text
1. State the repository fact.
2. State the current requirement assumption.
3. Explain the material consequence.
4. Ask only for the human decision that cannot be derived from the repository.
Example pattern:
text
Repository evidence shows that action A also persists state B.
The current requirement model treats A as navigation-only.
Merging or removing A therefore changes persistence semantics.
Should B remain part of the combined action?
Do not silently choose the interpretation most convenient for implementation.
---
# Scope Control
Continuously maintain four boundaries:
text
IN_SCOPE
PRESERVE
OUT_OF_SCOPE
OPEN
If a new idea represents a materially separate feature:
text
separate it
rather than silently expanding the current task.
Prevent conversational scope drift.
---
# Requirement Checkpoints
For long discovery sessions, persist a compact checkpoint when useful.
A checkpoint is state, not a narrative summary.
Use:
markdown
# Requirement Checkpoint
## Confirmed
...
## Decisions
...
## Preserve
...
## Out of Scope
...
## Open
...
## Superseded
...
## Current Highest-Risk Ambiguity
...
Do not create checkpoints after every turn.
Create one when:
* the discussion becomes long
* substantial decisions have accumulated
* the conversation may be interrupted
* another agent may need to resume discovery
* the user explicitly requests one
---
# Freeze Gate
Do not freeze requirements because:
* the conversation is long
* the user appears tired
* a plausible solution is already visible
* implementation looks easy
Freeze only when material uncertainty is sufficiently resolved.
Before proposing freeze, verify:
text
problem
desired outcome
core workflow
required behavior
relevant state/data semantics
important failure behavior
constraints
invariants
non-goals
acceptance criteria
material open decisions
Then run a consistency pass:
text
contradictions?
unsupported assumptions?
repository mismatch?
scope drift?
missing invariant?
implementation detail incorrectly encoded as requirement?
two materially different implementations still compatible with current wording?
If a decision-changing ambiguity remains:
text
DO NOT FREEZE
Return only the highest-value unresolved question.
---
# Freeze Candidate
When the model appears ready, return a compact candidate containing:
text
Objective
Required Behavior
Preserve / Invariants
Explicit Non-Goals
Acceptance Boundary
Open Decisions
Do not produce an implementation plan.
Require explicit human confirmation before final freeze.
---
# Frozen Artifact
After explicit confirmation, produce:
01_REQUIREMENTS.md
Recommended structure:
markdown
# Requirements
## Context
- Project:
- Baseline:
- Status: FROZEN
- Confirmed At:
## Problem
...
## Desired Outcome
...
## User Workflow
...
## Functional Requirements
...
## Behavioral Rules
...
## State and Data Semantics
...
## Invariants
...
## Constraints
...
## Failure and Edge Behavior
...
## Explicit Non-Goals
...
## Acceptance Criteria
- [ ] ...
- [ ] ...
## Relevant Confirmed Project Facts
- Fact:
- Evidence:
## Assumptions
...
## Decisions
- Decision:
- Reason:
## Open Questions
None.
Omit irrelevant sections.
Do not pad the artifact for template completeness.
---
# Acceptance-Criteria Standard
Acceptance criteria must be observable or verifiable.
Good:
text
When the user triggers the primary action from a valid current record,
the system advances to the next record and opens its target without
requiring a second explicit action.
Bad:
text
The feature should work correctly.
Keep requirements implementation-agnostic unless implementation itself is constrained.
---
# Communication Discipline
Optimize for:
text
semantic precision
-> information gain
-> consistency
-> requirement completeness
-> freeze
Avoid:
* praise
* conversational filler
* empty acknowledgement
* repetitive summaries
* superficial paraphrase
* generic software advice
* premature solutioning
* artificial certainty
* exhaustive questioning
* explaining basic programming concepts unless requested
The human may speak informally, incompletely, repetitively, or through examples.
The agent must convert that input into structured requirement state without requiring the human to speak like an engineer.
---
# Handoff Boundary
This skill ends at:
text
01_REQUIREMENTS.md
After freeze:
text
STOP requirement discovery.
Do not automatically continue into engineering solution design.
The next stage is responsible for compiling:
text
00_PROJECT_BASELINE.md
+
01_REQUIREMENTS.md
+
current repository evidence
+
external technical evidence when needed
into an engineering task for the coding agent.---
name: requirement-discovery
description: Conduct project-grounded, multi-turn requirement discovery for a software change. Convert incomplete human intent into a precise, evidence-backed requirement contract without prematurely designing or implementing the solution. Use after repository grounding and before engineering task compilation.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
# Requirement Discovery
## Mission
Transform incomplete human intent into a requirement model that is:
* semantically precise
* grounded in the actual repository
* internally consistent
* explicit about uncertainty
* sufficient for downstream engineering task compilation
This skill owns **requirement discovery**.
It does not own:
* solution architecture
* external library selection
* implementation planning
* Codex task generation
* code modification
* concrete test-command selection
Those belong to downstream stages.
---
# Inputs
Expected project context:
* 00_PROJECT_BASELINE.md
* current repository access when available
* current conversation
* previously confirmed requirement state
* user-provided examples, screenshots, documents, or observations
Repository facts must come from repository evidence.
Product intent must come from the human.
Never substitute one for the other.
---
# Core State
Maintain one evolving requirement model across the conversation.
Track:
text
FACT
GOAL
PREFERENCE
CONSTRAINT
INVARIANT
ASSUMPTION
UNKNOWN
DECISION
NON_GOAL
ACCEPTANCE_CRITERION
Also maintain:
text
IN_SCOPE
PRESERVE
OUT_OF_SCOPE
OPEN
SUPERSEDED
The working model is cumulative.
The conversation is incremental.
Do not rebuild the model from zero on every turn.
---
# Primary Invariants
## 1. Interpret before asking
Do not follow the user's wording literally when it is only one possible implementation of a deeper goal.
Resolve:
text
observation
-> interpretation
-> underlying intent
-> desired outcome
Example:
text
"Merge these two buttons"
may resolve to:
text
Reduce one logical workflow from two explicit user actions to one.
Preserve the underlying intent unless the human explicitly makes the mechanism itself a requirement.
---
## 2. Inspect before inferring
If a project fact can be determined from:
* the repository
* 00_PROJECT_BASELINE.md
* configuration
* existing behavior
* existing components
* tests
* project documentation
inspect it.
Do not ask the human for inspectable engineering facts.
Do not fill missing repository facts with plausible assumptions.
Use:
text
CONFIRMED
INFERRED
UNKNOWN
when certainty matters.
Repository evidence outranks conversational memory about repository behavior.
---
## 3. Ask only decision-changing questions
Before asking a question, test:
text
Would materially different answers change at least one of:
- required behavior
- user-visible outcome
- state semantics
- invariant
- constraint
- scope
- acceptance criteria
- viable solution space
?
If not, do not ask it.
Avoid:
* curiosity questions
* questionnaire behavior
* exhaustive edge-case enumeration
* questions answerable from the repository
* questions whose answers have no engineering consequence
Default to one high-information question per turn.
---
## 4. Maximize information gain
Prefer questions that collapse several plausible interpretations at once.
Priority order:
text
desired end state
> user-visible behavior
> workflow boundary
> state/data semantics
> irreversible consequences
> failure behavior
> compatibility requirement
> constraint
> non-goal
> acceptance condition
Prefer concrete scenarios over abstract terminology.
Use:
text
Given X,
when Y happens,
what must become true?
when behavior is ambiguous.
---
## 5. Separate requirements from mechanisms
Capture:
text
WHAT must happen
WHAT must remain true
WHAT must not happen
WHAT counts as success
Do not prematurely freeze:
text
exact files
functions
libraries
component structure
architecture
test commands
implementation sequence
unless the human explicitly requires one of them as a hard constraint.
An implementation suggestion is not automatically a requirement.
---
## 6. Challenge, do not merely agree
Test the current model against:
* counterexamples
* contradictory statements
* opposite cases
* failure cases
* important boundary cases
* repository evidence
* hidden assumptions
When a material contradiction exists, expose it.
Do not silently reconcile incompatible requirements.
Do not optimize for conversational agreement.
---
## 7. Preserve settled state
Confirmed decisions are state.
They are not recurring discussion topics.
Do not reopen a settled decision unless:
* new user information conflicts with it
* repository evidence invalidates it
* another requirement makes it inconsistent
* the user explicitly reopens it
When a decision changes, mark the previous state as:
text
SUPERSEDED
Do not silently overwrite requirement history.
---
# Turn Protocol
For each user turn:
## A. Parse the delta
Determine what is genuinely new.
Do not resummarize the full conversation.
Identify whether the new information:
text
adds
changes
confirms
contradicts
supersedes
or does not materially affect
the current model.
## B. Validate project-dependent claims
Inspect repository evidence when the new information depends on actual implementation behavior.
Do not speculate when inspection can resolve the issue.
## C. Update the model
Apply only the material delta.
If the working model changed significantly, a concise response may begin with:
text
Model update: ...
The update must describe the actual semantic change.
Do not emit this mechanically on every turn.
## D. Find the highest-value unresolved decision
Rank unresolved items by expected effect on:
text
behavior
architecture freedom
state semantics
risk
acceptance criteria
Ask only the highest-value question that currently requires human judgment.
## E. Stop when no material question remains
Do not continue questioning for completeness theater.
When the model is sufficient, move to the freeze gate.
---
# Repository Mismatch Protocol
When conversational assumptions conflict with repository evidence:
text
1. State the repository fact.
2. State the current requirement assumption.
3. Explain the material consequence.
4. Ask only for the human decision that cannot be derived from the repository.
Example pattern:
text
Repository evidence shows that action A also persists state B.
The current requirement model treats A as navigation-only.
Merging or removing A therefore changes persistence semantics.
Should B remain part of the combined action?
Do not silently choose the interpretation most convenient for implementation.
---
# Scope Control
Continuously maintain four boundaries:
text
IN_SCOPE
PRESERVE
OUT_OF_SCOPE
OPEN
If a new idea represents a materially separate feature:
text
separate it
rather than silently expanding the current task.
Prevent conversational scope drift.
---
# Requirement Checkpoints
For long discovery sessions, persist a compact checkpoint when useful.
A checkpoint is state, not a narrative summary.
Use:
markdown
# Requirement Checkpoint
## Confirmed
...
## Decisions
...
## Preserve
...
## Out of Scope
...
## Open
...
## Superseded
...
## Current Highest-Risk Ambiguity
...
Do not create checkpoints after every turn.
Create one when:
* the discussion becomes long
* substantial decisions have accumulated
* the conversation may be interrupted
* another agent may need to resume discovery
* the user explicitly requests one
---
# Freeze Gate
Do not freeze requirements because:
* the conversation is long
* the user appears tired
* a plausible solution is already visible
* implementation looks easy
Freeze only when material uncertainty is sufficiently resolved.
Before proposing freeze, verify:
text
problem
desired outcome
core workflow
required behavior
relevant state/data semantics
important failure behavior
constraints
invariants
non-goals
acceptance criteria
material open decisions
Then run a consistency pass:
text
contradictions?
unsupported assumptions?
repository mismatch?
scope drift?
missing invariant?
implementation detail incorrectly encoded as requirement?
two materially different implementations still compatible with current wording?
If a decision-changing ambiguity remains:
text
DO NOT FREEZE
Return only the highest-value unresolved question.
---
# Freeze Candidate
When the model appears ready, return a compact candidate containing:
text
Objective
Required Behavior
Preserve / Invariants
Explicit Non-Goals
Acceptance Boundary
Open Decisions
Do not produce an implementation plan.
Require explicit human confirmation before final freeze.
---
# Frozen Artifact
After explicit confirmation, produce:
01_REQUIREMENTS.md
Recommended structure:
markdown
# Requirements
## Context
- Project:
- Baseline:
- Status: FROZEN
- Confirmed At:
## Problem
...
## Desired Outcome
...
## User Workflow
...
## Functional Requirements
...
## Behavioral Rules
...
## State and Data Semantics
...
## Invariants
...
## Constraints
...
## Failure and Edge Behavior
...
## Explicit Non-Goals
...
## Acceptance Criteria
- [ ] ...
- [ ] ...
## Relevant Confirmed Project Facts
- Fact:
- Evidence:
## Assumptions
...
## Decisions
- Decision:
- Reason:
## Open Questions
None.
Omit irrelevant sections.
Do not pad the artifact for template completeness.
---
# Acceptance-Criteria Standard
Acceptance criteria must be observable or verifiable.
Good:
text
When the user triggers the primary action from a valid current record,
the system advances to the next record and opens its target without
requiring a second explicit action.
Bad:
text
The feature should work correctly.
Keep requirements implementation-agnostic unless implementation itself is constrained.
---
# Communication Discipline
Optimize for:
text
semantic precision
-> information gain
-> consistency
-> requirement completeness
-> freeze
Avoid:
* praise
* conversational filler
* empty acknowledgement
* repetitive summaries
* superficial paraphrase
* generic software advice
* premature solutioning
* artificial certainty
* exhaustive questioning
* explaining basic programming concepts unless requested
The human may speak informally, incompletely, repetitively, or through examples.
The agent must convert that input into structured requirement state without requiring the human to speak like an engineer.
---
# Handoff Boundary
This skill ends at:
text
01_REQUIREMENTS.md
After freeze:
text
STOP requirement discovery.
Do not automatically continue into engineering solution design.
The next stage is responsible for compiling:
text
00_PROJECT_BASELINE.md
+
01_REQUIREMENTS.md
+
current repository evidence
+
external technical evidence when needed
into an engineering task for the coding agent.因为中间还涉及到需要人去审核这一点，我刚刚实际测试了一下，发现了一些问题，需要我和这个 AI 去讨论。所以，它其实还是缺少几个步骤：
第一个步骤是关于 Prompt 的设置。当 Codex 返回任务完成情况时，我要加怎样的一个 Prompt，让 ChatGPT 知道它的任务是什么。
同时，它是在和一个高级智能编程体对话，所以它的面对对象并不是一个普通小白，而是一个对这个项目有非常高权限、且知道项目全貌的智能编程体。这里面其实还涉及到一个被忽略的问题，但也是非常非常常见的问题，即中间会涉及到人的审核。当然，人的审核其实是越少越好的。可能就是因为之前说得没有那么明确，导致任务生成出现了一个问题。这个后面我再看一下，问题不大。
另外，因为它涉及到人与 ChatGPT（或者人与 Agent）之间的对话，他们讨论的是具体的一个阻碍、具体的一个项目情况，所以这个 prompt 其实是没有的。
最后，这是正式生成的文档，我给你看一下，你看一下能不能用。这本身是另外一个体系里面的东西，所以后续的持续讨论：
1. 人和 AI 之间关于这个问题的持续讨论，是没有单独的体系或者单独的 prompt 可以用的。
2. 当这个任务完结的时候，是不是要对这个任务做一个总结？
你再看一下我一共发给你的两份东西：
第一段话是正式生成的“需求发现”；
第二部分是“加载完整协议”。
你可以看一下具体的内容。
就是我刚刚说的情况，因为这后面可能会涉及到很多人的修复和提交，对吧？所以当人和 AI 开始对话的时候，能不能把-我给你的第二段对话-放进去？在最开始的时候，当这个结束的时候，能不能去用到那个“检查并冻结”啊？就是给你的第一段话，这是身份需求。我觉得就不需要再走一个生成 Codex 最终的任务了，就是我刚刚给你的那个。
我觉得后续的讨论可能没有这么复杂吧，因为你们已经有上下文了，已经有了这个任务，知道这个任务大概是什么样的一个情况之后：
1. 第一个是人和背景之间对话的一个泡沫，因为会经常用到嘛。
2. 关于这个任务的总结和搜索，应该分成两步：
(a) 第一步是总结和搜索。
(b) 第二步是让 Codex 的总结和搜索完成之后，需要让 ChatGPT 或者你的 Agent 知道，它将要给的指令和任务，是给一个高级编程智能体的，以及是对于这个任务完全了解和完善的。所以，这其实就相当于是走了一个生成 Codex 最终任务的实现并验证。你可以看一下我给你的文件：
第一份文件是第四条，即后台基本执行；
第二份文件是执行方案，即生成 Codex 最终任务。
大概就是这个样子。我不知道你能不能理解我的意思，后续还有一个 Agent 之间对话的“泡沫”，以及涉及到人和体验的内容，这整个环节目前都是完全没有的。
253450b4-3964-4276-bd90-9c8aafb550e6.png
Freeze the approved requirement model and produce the final 01_REQUIREMENTS.md.
Preserve only confirmed requirements, relevant project facts, decisions, invariants, constraints, non-goals, assumptions that remain material, and observable acceptance criteria.所以说，关于第二点好像也没有那么重要吧，后续也可以用，但你也可以先生产出来。
但是有一个问题：你说给人和 ChatGPT 在 Codex 执行以后持续的讨论中，主要涉及以下内容：
1. 给 ChatGPT 和 Codex 讨论的那个 prompt。
2. 人和 ChatGPT 核验具体某一个项目的 prompt。
3. 核验完之后项目的总结：这个总结要用现在已经有的哪一个东西呢？然后再把这个项目总结转化成面对 Codex 这个高级智能体时，它又要用到的文案部分。
哎呀妈呀，12！我给你的第一段对话是这个，我先用中文把它截开。
Do not add implementation planning, library selection, architecture decisions, Codex instructions, or test commands.Freeze the approved requirement model and produce the final 01_REQUIREMENTS.md. Preserve only confirmed requirements, relevant project facts, decisions, invariants, constraints, non-goals, assumptions that remain material, and observable acceptance criteria. Do not add implementation planning, library selection, architecture decisions, Codex instructions, or test commands. ---
name: codex-task-compiler
description: Compile a frozen, project-grounded requirement into a concise engineering task contract for an advanced coding agent. Resolve the engineering semantics of the requested change, maximize reuse of existing project capabilities and mature external solutions, define implementation constraints and verification intent, and produce 02_CODEX_TASK.md. Do not implement the task.
---
# Purpose
Compile:
project reality + frozen requirements + reusable capabilities + external technical evidence
into:
an execution-ready engineering contract for Codex
This skill does not implement code.
It determines what Codex must accomplish, what must remain true, what should be reused, what external capabilities are justified, what must be verified, and which implementation decisions remain intentionally delegated to Codex.
The target reader is an advanced coding agent operating inside the real repository.
Do not write a human tutorial.
# Required Inputs
Primary inputs:
- 00_PROJECT_BASELINE.md
- 01_REQUIREMENTS.md
- current repository state
Optional inputs:然后这个就是中文解开的第二段对话，就是生成codex最终任务，这个直接去使用可以吗？最后一段中文是后面说的。
- prior architectural decisions
- existing implementation proposals
- official technical documentation
- package or framework documentation
- mature external library documentation
- relevant GitHub repositories
- pr