菜单
Use when reviewing DISCOVER artefacts (triage reports, sprint proposals) for completeness, prioritization quality, and duplicate handling. Contains gate definitions G1-G6 and scoring rubric for the backlog-discoverer-reviewer lenses.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when running mutation testing, killing mutants, verifying test quality, checking mutation score, or analyzing survivors after the test baseline is green
Use when selecting architecture patterns for a new feature, performing Event Modeling, defining bounded contexts, choosing DDD tactical patterns, evaluating pattern fitness, or understanding how patterns compose. Covers Event Modeling methodology, DDD strategic design, DDD tactical patterns, Clean Architecture, CQRS, and Event Sourcing.
Use when reviewing DESIGN artefacts (event models, ADRs, component diagrams, context maps, interface contracts) for quality, DDD compliance, architectural correctness, and prohibition of negative or baseline-restating ADRs. Contains gate definitions and scoring rubric for the solution-architect-reviewer lenses.
Use whenever an agent must run a toolchain command (build, test, mutation) and needs the concrete invocation. Resolves build/test/mutation commands from the detected stack so no agent hardcodes `dotnet test`, `dotnet build`, or any toolchain command. Loaded by acceptance-designer and software-engineer.
Use this skill BEFORE drafting any agentic primitive module (skill, persona scoping file, scope-attached rule file, orchestrator workflow) or when refactoring an existing one. Activate whenever the task asks to design, restructure, or critique an agentic module across any agent harness (Claude Code, Copilot, Cursor, OpenCode, Codex). This skill drives an 8-step disciplined design process whose output is mermaid diagrams + an interface sketch + a persisted plan that the calling thread (or a coder persona it loads) then turns into natural-language modules. Do not skip to natural-language drafting before the design artifacts exist.
Use when documenting architecture decisions as ADRs, evaluating trade-offs between alternatives, or managing the lifecycle of existing decisions. Covers ADR template, status transitions, consequence analysis, and quality criteria.
基于 SOC 职业分类
| name | discovery-review-criteria |
| description | Use when reviewing DISCOVER artefacts (triage reports, sprint proposals) for completeness, prioritization quality, and duplicate handling. Contains gate definitions G1-G6 and scoring rubric for the backlog-discoverer-reviewer lenses. |
Formal gate definitions and verdict rubric for the backlog-discoverer-reviewer. Applied across 3 lenses with 6 gates (G1–G6).
| Lens | Gates | What it checks |
|---|---|---|
| Completeness | G1, G2 | Was the discovery thorough? Were important issues missed? |
| Prioritization | G3, G4 | Is prioritization coherent and the sprint realistic? |
| Duplicate Detection | G5, G6 | Are duplicates correctly identified and linked? |
| ID | Definition | Pass Condition | Severity |
|---|---|---|---|
| G1 | Both supported discovery modes were considered, and the triage report explicitly documents selected/skipped reason for each mode with dedicated lines. | The report contains both lines: `User-assigned: selected | skipped — andSearch-based: selected |
| G2 | No P0 or P1 issues exist in the repository but are absent from the triage report. Verify by sampling: query for label:priority/P0,priority/P1 is:open is:issue sort:created-desc, take top 5, check each appears in the triage report. | Zero critical issues absent from triage. | BLOCKER |
| ID | Definition | Pass Condition | Severity |
|---|---|---|---|
| G3 | All P0 issues have a written justification in the Notes field. P1–P3 follows descending business value order. No priority inversions (a P2 that is clearly more urgent than a P1 in the same domain). | No priority inversions. All P0 justified. | HIGH |
| G4 | Sprint proposal respects declared capacity. Total effort ≤ effective capacity (team-days × 0.7) for non-P0 issues. No P2/P3 issue occupies a sprint slot while a P0/P1 issue is excluded. XL issues are not in the sprint. | Capacity respected; XL issues excluded. | HIGH |
| ID | Definition | Pass Condition | Severity |
|---|---|---|---|
| G5 | No two issues in the triage report describe the same problem (normalized title similarity > 80%). Normalize: lowercase, remove stop words, sort words alphabetically, compare overlap ratio. | Zero undetected exact or near-duplicate pairs. | HIGH |
| G6 | All issue pairs with 40–80% normalized title similarity are noted in the "Duplicates Detected" section with a recommendation (merge, link, or keep separate). | All similar pairs flagged with recommendation. | MEDIUM |
Discovery is considered sufficient when:
Completeness is not about finding every issue — it is about ensuring critical issues are not hidden.
For single-issue (user-assigned) runs, this exact skipped rationale is recommended and should pass G1:
Search-based: skipped — single user-assigned issue; no milestone or batch target.
| Rule | Description |
|---|---|
| P0 always in sprint | Every P0 issue must appear in the sprint proposal, even if over capacity |
| P0 justification required | Every P0 issue must have a written justification in the Notes field |
| No P3 before P1 | A P3 issue cannot be in the sprint if any P1 issue is excluded |
| P2 after all P1 | Sprint fills P1 before P2 unless P1 is already covered |
| XL never in sprint | XL issues must be split — they cannot enter DISCUSS as-is |
| No priority inversion | A P2 issue with more urgency than a P1 in the same domain = G3 fail |
| Level | Similarity | Action Required |
|---|---|---|
| EXACT | > 95% | One issue must be labeled status/duplicate and linked to the original |
| NEAR | 80–95% | Recommendation to merge. Both issues linked. Documented in triage. |
| RELATED | 40–80% | Flagged in triage as "related". Recommendation documented. No merge required. |
| DIFFERENT | < 40% | No action required |
G5 threshold: > 80% = must flag (covers both EXACT and NEAR) G6 threshold: 40–80% = should flag (covers RELATED)
| Rule | Applies To |
|---|---|
| P0 overrides capacity | P0 issues enter sprint regardless of effective capacity |
| Effective capacity = team-days × 0.7 | Applies to P1/P2/P3 issues |
| Over-capacity P0 must be documented | Triage report must note "P0 override" |
| XL exclusion is absolute | No XL issue enters sprint — G4 fail if present |
| P2/P3 after all P1 | P2/P3 issues fill remaining capacity after all P1s |
| Condition | Verdict |
|---|---|
| G2 fails (BLOCKER: P0/P1 missing from triage) | rejected |
| G1 fails (HIGH: modes not covered) | changes_requested |
| G3 fails (HIGH: priority inversions or missing P0 justification) | changes_requested |
| G4 fails (HIGH: capacity violated or XL in sprint) | changes_requested |
| G5 fails (HIGH: undetected near-duplicates) | changes_requested |
| G6 fails only (MEDIUM: related pairs not flagged) | changes_requested |
| All gates pass | approved |
