mcpField
A
archeology

archeology

github.com/jimweller生産性25 回インストール
リポジトリ

archeology について

Archeology は、残された証拠から経緯を再構成し、質問に答えるスキルです。Jira、Confluence、Slack から調査を始め、証拠が示す他の情報源を追跡して、引用付きのタイムラインを .llmtmp/timeline.md に作成します。

主な機能

  1. 01指定された質問に沿った調査範囲の設定
  2. 02Jira、Confluence、Slack の並行調査
  3. 03証拠を手掛かりに他の情報源を追跡
  4. 04節目を整理し、矛盾と制約を記録

活用シーン

  1. 01プロジェクトの決定や変更の経緯を追跡
  2. 02複数システムの記録を使ったインシデント調査
  3. 03異なる情報源における出来事の説明を照合

インストール

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

$npx skills add https://github.com/jimweller/clanker-skills --skill archeology

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

詳細

STARTER_CHARACTER = 🏺

考古学

現存する証拠から何が起きたのかを再構成し、その記録に基づいて質問に回答します。

成果物は .llmtmp/timeline.md です。作業メモは .llmtmp/ の下に保存します。依頼されない限り、ほかには何も書きません。

入力

引数は 1 つ以上の質問で、? で区切ります。質問に Q1 から Qn まで番号を付け、その番号を実行全体で維持します。引数がない場合は、少なくとも 1 つ質問するよう求め、質問が届くまで停止します。明示されていない質問について調査してはいけません。

情報源

これらはラベルであり、指示ではありません。環境が提供する任意のツールを使って各情報源にアクセスしてください。

Jira、Confluence、Slack を起点とします。ほかの情報源は、証拠が示す場合にアクセスします。 使用する情報源を尋ねてはいけません。

  • 課題トラッカーとポートフォリオボード
  • Wiki、設計文書、意思決定記録
  • チャット
  • メール、カレンダー、会議記録
  • ソースリポジトリ:コミット、プルリクエスト、レビュアー、ブランチポリシー、パイプライン、リリース
  • コードそのもの
  • クラウドのランタイム状態
  • コストと請求
  • ログ、トレース、モニター、インシデント履歴
  • コード品質とスキャン履歴
  • 用語集と用語レジストリ
  • エージェントのメモリとセッションのトランスクリプト
  • 外部文書、ベンダー資料、ウェブ

手順

  1. 質問を整理します。 各質問を言い換えます。質問全体が対象とする期間を示します。対象範囲、つまり誰についての記録であり、誰についての記録ではないかを明示します。
  2. 起点の情報源を調査します。 Jira、Confluence、Slack をそれぞれ担当するサブエージェントを 1 つずつ、並行して 3 つ起動します。それぞれに質問、対象、期間、引用形式、以下の証拠ルールを伝えます。この 3 つから、以降の調査に必要な識別子をすべて取得します。それぞれ、日付と引用付きの調査結果に加えて、確認した識別子(プロジェクトキー、エピックキー、スペースキー、ページ ID、チャンネル ID、リポジトリ名、環境名、記録に出てくるその他すべてのシステム)を返します。
  3. 証拠をたどります。 各ラウンドで、新たに調査する対象を特定します。チケットにリポジトリが記載されていれば、ページにダッシュボードが記載されていれば、メッセージにインシデントやメールボックスが記載されていれば、それぞれを追跡します。新たに名前が挙がった情報源ごとにサブエージェントを 1 つ起動して並行調査し、新しい情報が見つからないラウンドになるまで続けます。追跡する価値があるか判断し、価値があれば追跡します。使用する情報源を尋ねたり、起点の情報源だけで調査を終えたりしてはいけません。何も見つからなかったエージェントは、実行したクエリと結果が空だったことを報告します。これは、そのクエリの範囲内で不在を示す証拠となります。
  4. マイルストーンをまとめます。 返された調査結果を 1 つの時系列にまとめます。名前付きのフェーズに分割します。質問に関係するすべての項目に [Qn] を付けます。
  5. 矛盾を解決します。 情報源の主張と成果物が食い違う場合は、両方を残し、それぞれがどちらなのかを明記します。成果物同士が食い違う場合は、両方を残し、不一致を明記します。
  6. レポートを作成します。 以下のサンプルに従います。毎回、同じ見出し、同じ順序で作成します。
  7. 手法を記録します。 すべてのアクセス境界、拒否、結果上限、未検証の主張を記録します。アクセスした情報源と、記録から存在が示されたものの今回アクセスできなかった情報源を明記します。

レポートのサンプル

毎回、以下の形式で作成します。同じ見出し、同じ順序、同じ項目形式にします。

# <Subject>: Evidence Timeline

This is a working document. Each milestone carries a slug, a link, and its supporting evidence.
Amend as new evidence arrives. Last updated YYYY-MM-DD.

Sources so far: <system>, <system>, and <system>.

## Executive summary

<The answer to every question, in prose, for a reader who reads nothing else. Sequence and
measured state. Three to six paragraphs.>

## Summary

<Narrative for a leadership audience. Every figure traces to a section below.>

<Closing paragraph naming what this summary does not assert and which figures are bounded.>

## Purpose

<N> open questions drive this timeline. Entries are tagged `[Q1]` through `[Qn]` where they bear
on one.

**Q1. <Question>?** <What the record establishes.> <What stays open.>

**Q2. <Question>?** <What the record establishes.> <What stays open.>

## Acronyms

Expansions marked **(dict)** come from a terminology registry. Expansions marked **(meta)** come
from project or space metadata. Expansions marked **(record)** are established by artifacts in
this timeline. Unverified entries say so.

| Term | Expansion | Meaning here |
| ---- | --------- | ------------ |
| <ABC> | <Expansion> (dict) | <What it refers to in this record> |
| <XYZ> | <Expansion> (record) | <What it refers to in this record> |

## Cast

| Person | Role | Established by |
| ------ | ---- | -------------- |
| <Name> | <Role> | <Artifact and link> |

## Milestones

### Phase 0: <Name>, <start> to <end>

**YYYY-MM-DD. <Headline>** `[Q1]`
[<ABC-123>](url) | [<Page title>](url)
<Evidence. Quote the source verbatim where the wording carries the claim.>

**YYYY-MM-DD HH:MM TZ. <Headline>**
[<Chat>](permalink)
<Name>: "<verbatim quote>" <What the quote establishes.>

### Phase 1: <Name>, <start> to <end>, <count> <units>

<Entries in date order.>

## <System> record

<One section per system: repo facts, issue-tracker record, runtime state, documentation record,
consumer record, cost. Sub-sections as the evidence requires.>

| <Metric> | <Value> | Source |
| -------- | ------- | ------ |
| <Metric> | <Value> | <Query or link> |

## Findings

1. <One claim, carrying the figure that supports it.>
2. <One claim, carrying the figure that supports it.>

## Open questions

1. <Question.> <What would settle it.>
2. <Question.> <What would settle it.>

## Method

<Every claim above is one of three kinds. Name them: a quoted source is a claim by its author on
that date, a system record is an artifact, a live query result is state observed on that date.
Where a claim and an artifact disagree, both appear.>

- <Query provenance: tool, host, credential, and date for each system.>
- <Result caps, and how counts were taken above the expected row count.>
- <Denials, recorded rather than worked around.>
- <Sources the record named that this run never reached.>
- <What stays unverified.>

証拠ルール

  • すべての主張に、システム、識別子、URL を引用として付けます。
  • 情報源の主張と成果物は異なります。課題がクローズされたとするメールは主張です。課題の遷移記録は成果物です。記述がどちらに基づくのかを明示します。
  • 矛盾を記録します。黙って解消してはいけません。
  • 未検証の記述には、その場で未検証であることを示すラベルを付けます。
  • 拒否されたクエリは拒否として記録します。回避してはいけません。
  • 秘密の値を出力してはいけません。値をそのまま出さずに比較し、分類します。
  • すべてのクエリは読み取り専用です。書き込み、削除、再起動の操作は禁止です。
  • エージェントのメモリとトランスクリプトは、独立した証拠ではありません。
  • すべての件数に結果上限を記載し、予想される行数を上回る上限で件数を取得します。
  • すべての件数の範囲を、それを取得した認証情報に限定します。

フレーミングのルール

  • 評価せず、説明してください。「何が依頼されたか」は質問です。「その依頼が適切だったかどうか」 は判断です。
  • 特徴づけはすべて、発言者の言葉をそのまま引用して帰属を明示するか、削除してください。
  • 読者を判断へ誘導するような収束表現で、情報源を結び付けないでください。
  • 絶対的な表現は、検索対象に限定し、どのような検索を行ったかを明記してください。
  • 定価、予測、推定値は、それぞれの性質が分かるように表記してください。
  • clanker-prose プラグインの代筆ルールが適用されます。読者は人間の同僚です。

書式

  • 日付は ISO 形式にしてください。情報源にタイムゾーンの記載がある場合は、そのタイムゾーンを明記してください。
  • 本文は 95 文字以内で折り返してください。
  • 表はコンパクトにしてください。パイプの内側には半角スペースを 1 つ入れ、区切り線のダッシュ数は見出しの文字数に合わせてください。
  • 成果物に md-lint や prettier を実行しないでください。どちらもこの文書の書式を崩します。

コメント