菜单
The Mileva Method (CRISP) — Phase 5: Prove. Success validation against Phase R baseline metrics, test log review, and AI justification validation. Use after deployment. Triggers on "prove", "phase 5", "validate", "did it work", "success criteria", "measure results", or after go-live.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Generate a beautiful single-file HTML report from the project's docs/ folder. Works after any CRISP phase, after Archaeology, or at sprint close in Execute. Triggers on "generate report", "export docs", "create HTML report", "share docs", or automatically at sprint close in CRISP Execute.
CRISP session manager — detects project state and routes to the right entry point. Use /crisp to start or resume any CRISP engagement. Handles new projects (discovery), existing codebases (archaeology), active sprints (execute), and validation (prove). Reads docs/crisp-state.json to know where you are.
CRISP Execute — Sprint execution loop with change request management, security gates, product gates, and stakeholder reporting. Use after Phase S (Spec) is complete and crisp-state.json shows ready_for_execute: true. Triggers on "start sprint", "begin build", "execute", "sprint 1", "run sprints", or when handed off from crisp-orchestrator.
The Mileva Method (CRISP) — Phase 1: Clarify. Problem definition, eliciting, painkiller test, buy vs build, AI justification gate, Go/No-Go. Use at the start of any AI implementation project. Triggers on "clarify", "phase 1", "start discovery", "define the problem", "what problem are we solving", or at the beginning of a new client engagement.
The Mileva Method (CRISP) — Phase 2: Results. Outcome alignment, stakeholder register, baseline measurement, success metrics, tradeoff negotiation. Use after problem definition is complete. Triggers on "results", "phase 2", "define success", "success metrics", "what does done look like", or after Phase C exit checklist is complete.
The Mileva Method (CRISP) — Phase 3: Investigate. Process mapping for existing or greenfield processes, user journey mapping, UX discovery, project goals, system architecture (integration map + data flow). Use after outcome alignment. Triggers on "investigate", "phase 3", "map the process", "process mapping", "user journey", "as-is process", or after Phase R exit checklist is complete.
| name | phase5-prove |
| description | The Mileva Method (CRISP) — Phase 5: Prove. Success validation against Phase R baseline metrics, test log review, and AI justification validation. Use after deployment. Triggers on "prove", "phase 5", "validate", "did it work", "success criteria", "measure results", or after go-live. |
Present one section, deliverable, or elicitation move at a time. After presenting — stop. Wait for the client to respond. Do not pre-fill and present multiple sections in one message. Do not move to the next step until the client confirms, corrects, or gives a clear go-ahead.
The goal is a conversation, not a document dump. If you've written more than one section without a client response in between — you've gone too far.
Did the needle move?
At the start of Phase P: read
docs/crisp-state.json. Pullphases.R.baselineandphases.R.successTargetas the measurement baseline. Checkphases.S.sprintsto know what was built.At the end of Phase P: update
docs/crisp-state.json:
- Add
"P"tophases.complete- Set
phases.P.completetotrue- Set
phases.P.outcometo"success","partial", or"fail"- Add summary notes to
phases.P.notes
This phase closes the loop back to Phase R. Three questions drive everything.
Pull the baseline and targets from docs/success-metrics.md and measure against them:
Read docs/test-log.md. For every sprint that shipped:
A system where the metrics look good but tests weren't written is a system running on luck. The test log is how you know the difference between "it works" and "it worked that one time we checked."
If the test log has gaps — identify what wasn't verified and decide: is this a risk to the outcome measurement, or is it acceptable to close?
Read docs/problem-statement.md — AI Justification section. The client agreed to custom AI because it could do something off-the-shelf products couldn't.
Ask: did that thing actually materialise?
"We said custom AI was justified because [X]. Did [X] happen? Is the client getting something from this that they couldn't get from Claude.ai at $20/month?"
If yes → close it. If no → document the gap honestly. It's a learning, not a failure — but it should be captured so the next project's justification gate is sharper.
Success → document what worked, close the project, capture learnings.
Partial → identify which metrics hit and which didn't. Was the target unrealistic, or did the solution miss?
Fail → return to Phase R. The problem may have been misdiagnosed, or the success criteria were wrong.
In Serbia, when things go sideways, we make jokes. It's not denial — it's perspective. Balkan humor is the ability to look at a disaster and find the absurdity before you find the culprit. Apply that here. If Phase P says fail, laugh once — then go back to Phase R with fresh eyes. A failed outcome is the most honest piece of data you'll collect in the whole project. The problem was misdiagnosed. Now you know exactly where. That's worth something.
docs/success-metrics.mddocs/test-log.md reviewed — all sprints have entries, no unresolved ❌ failures