一键导入
llm-capability-matching
Use when assigning development tasks to different LLMs or estimating costs for multi-agent work.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when assigning development tasks to different LLMs or estimating costs for multi-agent work.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Enhanced planning system combining UltraPlan's 6-phase pipeline with Clear Thought's 11 structured thinking frameworks. Takes a plain-English idea and produces a complete, AI-executable implementation plan with rigorous thinking at every phase.
Use when defining API endpoints, designing request/response schemas, or establishing API contracts during framework planning.
Use when documenting architectural decisions, comparing technology options, or recording rationale for framework choices.
Use when selecting architecture patterns (MVC, hexagonal, clean, microservices) for a new project.
Use when creating or updating blueprint files in .framework-blueprints/ directory.
Use when designing CI/CD pipelines or creating GitHub Actions / GitLab CI configuration.
基于 SOC 职业分类
| name | llm-capability-matching |
| description | Use when assigning development tasks to different LLMs or estimating costs for multi-agent work. |
| allowed-tools | Read, Write, WebSearch |
Assign tasks to the most suitable LLMs based on live research, user budget, and task requirements.
Do NOT rely on hardcoded model scores. Models and pricing change frequently. Always use WebSearch to verify current capabilities before making assignments. See
references/llm-strengths.mdfor the full decision protocol.
Which LLMs/tools do you have available?
What's your budget constraint? (none / moderate / tight)
For EACH LLM the user mentions:
WebSearch: "[Model Name] capabilities benchmarks pricing [current year]"
Verify from official sources:
Present findings WITH source URLs. Never guess.
| Category | Prioritize | Avoid |
|---|---|---|
| Architecture & system design | Strongest reasoning model | Fast/cheap models |
| Backend implementation | Good code + fast iteration | Overkill reasoning |
| Frontend / UI | Vision-capable, UI-aware | Code-only models |
| Testing | Thorough + cost-effective | Expensive flagship |
| Documentation | Large context + clear writing | Small context |
| DevOps / CI/CD | Broad knowledge | Narrow specialists |
| Refactoring | Code-focused, pattern-aware | Conversational models |
| Constraint | Strategy |
|---|---|
| Budget limited | Use cheaper models for bulk, flagship for architecture only |
| Time critical | Use fastest-responding models |
| Quality critical | Use flagship for all phases |
| Large codebase | Prioritize largest context window |
| Single developer | Skip Phase 4; use one model for everything |
| Agent ID | LLM | Tasks | Est. Cost | Rationale |
|----------|-----|-------|-----------|-----------|
| [ID] | [Model - verified] | [Tasks] | [Est - from live pricing] | [Why this model - with source] |
| Task Type | Est. Input | Est. Output |
|---|---|---|
| Architecture design | 5,000 | 3,000 |
| API endpoint (each) | 2,000 | 1,500 |
| React component | 3,000 | 2,000 |
| Unit test file | 1,500 | 2,000 |
| Integration test | 3,000 | 2,500 |
| Documentation page | 2,000 | 3,000 |
| Refactor module | 4,000 | 3,000 |
Total Cost = Sum(task_input_tokens * input_price + task_output_tokens * output_price)
| Scenario | Recommendation |
|---|---|
| > 50K tokens expected | Split into phases |
| Context loss risk | Checkpoint every 20K |
| Multiple modules | One session per module |
| Complex dependencies | Sequential sessions |