mk-decision-framework
Operational decision frameworks: triage, escalation, case management, billing ops. Use for 'how to handle X cases', 'build triage', 'escalation protocol'.
- License 许可
- MIT
- 最近更新
- 2026-11-12
- Stars
- ★ 16
- Forks
- 3
01 前言 Front Matter
- name
- mk-decision-framework
- description
- Operational decision frameworks: triage, escalation, case management, billing ops. Use for 'how to handle X cases', 'build triage', 'escalation protocol'.
02 资源文件 8
- 参考文档references/communication-patterns.md3.8 KB
- 参考文档references/decision-tree-template.md2.4 KB
- 参考文档references/edge-case-discovery.md2.5 KB
- 参考文档references/escalation-protocol-template.md3.0 KB
- 参考文档references/examples/example-billing-ops.md4.0 KB
- 参考文档references/examples/example-incident-response.md4.8 KB
- 参考文档references/examples/example-returns-triage.md2.9 KB
- 参考文档references/weighted-scoring-guide.md3.5 KB
03 SKILL.md 正文
Decision Framework Builder
Structures expert judgment into repeatable, auditable decision systems for recurring high-stakes choices.
When to Use
Activate when:
- User asks "how should we handle X cases?" or "build triage system"
- Designing escalation protocols or case management workflows
- Billing ops, support, returns, incident response, compliance decisions
- Any domain with classified decision types and routing rules
Phase Anchor
Phase: 1 (Plan) — Produces a decision framework document. Handoff: Developer agent implements the decision logic in code.
Failure Handling
- Domain unclear: Ask user for 3 example cases. Derive taxonomy from examples.
- No domain expert available: Flag output as
needs-expert-input. Mark uncertain classifications explicitly.
Process (7 Steps)
Step 1: Identify Decision Type
Clarify the recurring decision being structured. What is decided? Who decides? How often?
Step 2: Build Classification Taxonomy
Load references/decision-tree-template.md. Map every case type into mutually exclusive categories. Aim for 3-7 top-level buckets — too few collapses distinct cases, too many creates lookup overhead.
Step 3: Define Sequential Decision Rules
Order rules by: Safety > Compliance > Economics > Speed. Never let speed override safety. Document the reasoning for each rule's position in the sequence.
Step 4: Create Weighted Scoring
Load references/weighted-scoring-guide.md. Define 3-5 factors with weights summing to 100%. Calibrate against 3 historical cases.
Step 5: Define Escalation Protocol
Load references/escalation-protocol-template.md. Map 4 escalation levels: Expert → Manager → Director → VP. Each level must have authority scope, timeline, and escalation trigger.
Step 6: Add Communication Templates
Load references/communication-patterns.md. Select tone per relationship state: Routine / Significant / Crisis. Customize placeholders.
Step 7: Document Edge Cases
Load references/edge-case-discovery.md. Collect edge cases from team ("what surprised you?"). Document each as: situation → why obvious approach fails → correct approach.
References
| File | Purpose |
|---|---|
references/decision-tree-template.md |
Domain-agnostic taxonomy + rules template |
references/escalation-protocol-template.md |
4-level escalation with authority/timeline/triggers |
references/weighted-scoring-guide.md |
Multi-factor scoring + calibration method |
references/communication-patterns.md |
3 tones with example templates |
references/edge-case-discovery.md |
Edge case collection and documentation process |
references/examples/example-returns-triage.md |
Worked example: returns processing |
references/examples/example-billing-ops.md |
Worked example: billing operations |
references/examples/example-incident-response.md |
Worked example: security incidents |
Output Format
Produce a decision framework document with:
- Domain Summary — what is being decided, frequency, stakes
- Classification Taxonomy — case types and definitions
- Decision Rules — ordered Safety → Compliance → Economics → Speed
- Scoring Matrix — weighted factors with calibration notes
- Escalation Protocol — 4-level table
- Communication Templates — one per tone
- Edge Case Playbook — 2-3 sentence entries per known exception
Gotchas
- Do not merge case types that have different decision rules — keep taxonomy granular
- Scoring weights must sum to 100%; calibrate on real cases, not hypothetical ones
- Escalation timelines must be specific (hours, not "soon")
- Edge cases are not exceptions to document and ignore — they are the most important cases to get right
04 同仓库更多 Skills
mk-sequential-thinking
Structured step-by-step reasoning before acting, to avoid guessing. For complex debugging, multi-step analysis, hypothesis checks. NOT for being stuck on approach (mk:problem-solving).
mk:fixture-valid
A valid fixture used to verify the skill structure validator.
invalid
暂无简介
mk:sample-skill
Sample skill for fixture purposes — small enough to land below noise floor.
mk-worktree
Manages git worktrees for parallel agent isolation: creates parallel/{name}-{timestamp} branches, merges with conflict detection. NOT for user feature branches (use git worktree directly).
mk-workflow-orchestrator
Auto-invoked 7-phase workflow for complex-feature intent; fasttrack mode for pre-approved specs. NOT for explicit single tasks (mk:cook), green-field builds (mk:autobuild), or simple fixes (mk:fix).