一键导入
red
TDD Red Phase - Activate ONE test from the test list and make it fail with explicit predictions
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
TDD Red Phase - Activate ONE test from the test list and make it fail with explicit predictions
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Generates an experiment-overview snapshot of all research questions under research/_archive/. Invoke when a new point-in-time report across all RQs should be produced.
Use this skill to drive a research question (RQ) end-to-end: validate the RQ README, generate a fill batch-plan, start the Docker batch in the background, monitor progress, run aggregation, and propose findings updates. Trigger when the user says "RQ-N voranbringen", "run-rq", "fill RQ-N", "run RQ-N", "Forschungsfrage N starten", or names a specific RQ-N directory in research/.
Re-run the analysis pipeline on all runs matching an RQ, reaggregate metrics, and propose findings updates against the fresh data. Trigger when the user says "reanalyze RQ-N", "reanalyse RQ-N", "Runs neu analysieren", or wants to refresh metrics/findings after a pipeline change (analyze-run.sh fix, adapter added, ESLint config).
TDD Green Phase - Implement minimal code to make the failing test pass
TDD Test List Phase - Create a comprehensive test list covering every example and rule from the specification
Generates an experiment-overview snapshot of all research questions under research/_archive/. Invoke when a new point-in-time report across all RQs should be produced.
| name | red |
| description | TDD Red Phase - Activate ONE test from the test list and make it fail with explicit predictions |
You are now in the Red Phase of TDD. Follow these instructions to activate ONE test and make it fail.
it.todo() to executable testit.todo(): Never have more than one failing testIdentify the next it.todo() and convert it to executable test code:
// Convert from:
it.todo("should return 0 for empty input");
// To:
it("should return 0 for empty input", () => {
expect(calculate("")).toBe(0);
});
Leave all other tests as it.todo().
Before running the test, state your prediction:
Red Phase - Compilation Error Prediction:
- Test: "should return 0 for empty input"
- Expected: Compilation error
- Reason: Function `calculate` doesn't exist yet
- Error: "Cannot find name 'calculate'"
Run pnpm test and verify:
Create minimal function stub (no logic):
export const calculate = (input: string): number => {
return undefined as unknown as number; // Intentionally wrong
};
Before running again, state your prediction:
Red Phase - Runtime Error Prediction:
- Test: "should return 0 for empty input"
- Expected: Runtime assertion error
- Expected value: 0
- Actual value: undefined
- Diff:
Expected: 0
Received: undefined
Run pnpm test and verify:
You MUST output the full Step 7 block verbatim with Correct or Incorrect
chosen for each prediction. Do not abbreviate. Do not collapse the two
prediction lines into one.
Why this format matters: The block is mechanically parsed to compute
predictions_correct_rate. The parser expects two lines matching
(- |Correct|Incorrect) per cycle -- one for the compilation prediction,
one for the runtime prediction. Collapsing them into a single line, summarizing
them as "both correct", or skipping the block entirely drops the predictions
count for this cycle to zero. Format consistency here directly drives a metric
the experiment measures.
Red Phase Complete:
**Test Activated**: "should return 0 for empty input"
**Compilation Prediction**: Cannot find name 'calculate' Correct
**Runtime Prediction**: Expected 0, received undefined Correct
**Result**: Test fails as expected with assertion error
Proceeding to Green phase.
it.todo()If your prediction was wrong:
Prediction Failed:
- Predicted: [what you expected]
- Actual: [what happened]
- Discrepancy: [explanation]
Investigating the discrepancy before proceeding.
After completing Red phase, proceed to Green phase:
Red Phase Complete. Proceeding to Green phase.