mcpField
L
lens-pro

lens-pro

github.com/venhdev開発1124 回インストール今日更新
リポジトリ

lens-pro について

lens-proは、コンピューターサイエンスとシステム工学の概念でシステムを分析するスキルです。利点とコストを併記し、障害モードや動作上の境界も検討します。

主な機能

  1. 01形式的な工学概念を使用
  2. 02リソースと運用コストを考慮
  3. 03実行時の障害モードを検討
  4. 04劣化経路と境界条件を特定
  5. 05分析を質問の範囲内に限定

活用シーン

  1. 01アーキテクチャ設計のレビュー
  2. 02システムの実行時動作の評価
  3. 03障害事例とトレードオフの特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/venhdev/skills --skill lens-pro

インストール後、Claude Code で/lens-proを入力して読み込まれたか確認します。

詳細

lens-pro — プロフェッショナル向けエンジニアリング解体エンジン

運用上の不変条件

  • 機械的な精密さ:メカニズムは、形式的なコンピューターサイエンスおよびシステムエンジニアリングのプリミティブ(状態機械、メモリモデル、並行処理ロック、I/O 境界)を用いて厳密に定義してください。口語的な比喩、幼稚な単純化、根拠の曖昧な抽象化は禁止します。
  • 銀の弾丸への警戒(コストの計上):すべての利点とあわせて、機械的なコスト(メモリ使用量、p99 レイテンシ、同期オーバーヘッド、運用の複雑さ)を定量化してください。どのようなパターンも、コストがかからない、または常に最適であるかのように示すことは禁止します。
  • 障害を起点とする堅牢化:具体的な実行時の障害モード、性能劣化の経路、境界条件を明らかにしてください。正常系のみの説明は禁止します。
  • コンテキストの分離:進行中のセッションタスクを妨げたり、プロジェクトのスコープを変更したりせず、現在の問い合わせ範囲内に厳密に絞って分析してください。

正規の出力仕様

# Lens [Pro]: <Target Concept / Pattern / Mechanism>

## 1. Architectural Role & Invariant Contract
- **System Classification**: <e.g., Concurrency Primitive | Consensus Protocol | Persistence Pattern | Network Flow Control>
- **Guaranteed Invariant**: <Non-negotiable contract or invariant enforced, e.g., Linearizability, At-least-once delivery, Strict Concurrency Bound>
- **Formal Definition**: <Single-sentence, precise operational definition without colloquialisms or analogies>

## 2. Runtime Mechanics & Execution Path
1. **Ingest & Allocation**: <Resource allocation, queueing strategy, or input dispatch mechanism>
2. **State & Concurrency Boundary**: <State transition, concurrency synchronization (locks, barriers, atomics), or memory mutation>
3. **Settlement & Reclamation**: <State commit, I/O flush, error boundary propagation, or resource reclamation>

## 3. Trade-offs & Adoption
*(Use paired vectors, comparison matrix, or Mermaid diagram [flowchart, sequenceDiagram, stateDiagram, xychart] when state transitions or data flow topologies clarify non-obvious trade-offs)*

- **Gain**: <Primary performance, reliability, or scaling advantage achieved>
- **Cost / Sacrifice**: <Direct engineering cost: p99 latency jitter, memory overhead, concurrency contention, or operational complexity>
- **Adopt When**: <Specific operational scale, concurrency threshold, or technical constraint requiring this pattern>
- **Avoid When**: <Simpler baseline suffices; premature optimization trap>

## 4. Production Failure Modes & Mitigations *(omit for stateless/pure-functional patterns)*
- **<Failure Mode 1, e.g., Cascading Retry Storm / Connection Starvation>**: <Exact failure mechanism under stress> ── **Mitigation**: <Direct architectural safeguard>
- **<Failure Mode 2, e.g., Head-of-Line Blocking / Silent Memory Drift>**: <Exact failure mechanism under stress> ── **Mitigation**: <Direct architectural safeguard>

コメント