mcpField
A
always-current-datetime

always-current-datetime

github.com/srinitudeエージェントワークフロー2558 回インストール1 週間前に更新
リポジトリ

always-current-datetime について

always-current-datetimeは、直接のユーザーメッセージごとにローカル時刻の基準を取得し、相対的な日時を解決するスキルです。時刻取得、タイムゾーン処理、曖昧さの確認、返信への時刻表示を定め、リマインダーなどの実行は別の機能に委ねます。

主な機能

  1. 01直接の各ターンで新しい時刻基準を取得
  2. 02タイムゾーン規則に基づく相対日時の解決
  3. 03曖昧な日付表現への確認
  4. 04返信への現在時刻プレフィックス表示
  5. 05時刻取得失敗時の処理規定

活用シーン

  1. 01「明日」などの表現を絶対日付に変換
  2. 02期限や有効期間を含む依頼への対応
  3. 03日付依存の操作前に時刻基準を統一

インストール

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

$npx skills add https://github.com/srinitude/skills --skill always-current-datetime

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

mise.toml
.github/workflows/
ci.yml
assets/
decision-records.json
improvement-contract.json
invocation-receipt-template.json
mise-primitives-catalog.json
mise-primitives.json
primitive-lifecycle.json
response-prefixes.txt
use-case-contract.json
evals/
cases.json
contract.md
evals.json
manifest.json
rubric.md
source-lineage.json
source-mapping.json
speed-budgets.json
trigger-cases.json
trigger-queries.json
examples/
fresh-direct-turn.md
help-command.md
invalid-timezone.md
references/
decisions.md
eval-contract.md
generation-contract.md
resource-and-experiment-design.md
use-case-specificity.md
scripts/
agentic_request_contract.py
check_code_rules.py

詳細

常に最新の日付と時刻

ユーザーからの直接のメッセージごとに、新しいローカル時刻のアンカーを1つ取得します。starting-point を通じて適用し、ユーザーの言葉を変えずに相対的な日付と時刻を解決し、現在の取得時刻を表示される返信に残します。

このスキルで受け付けるコマンドは何ですか?

通常のユーザーからの直接メッセージは refresh として扱います。これらの制御語は、確認とテスト用です。

コマンド結果
helpトリガー、時刻フィールド、タイムゾーンの優先順位、表示される接頭辞、失敗時のルール、アンカーの状態を表示します。
refresh現在の直接メッセージに対して新しいアンカーを1つ取得し、starting-point に紐付けて返信に適用します。

リクエストがどちらのコマンドにも一致しない場合は、refresh を使用します。ユーザーにコマンドを選ぶよう求めてはいけません。

いつ実行しますか?

日付や時刻に関する語句がない場合も含め、ユーザーからの直接メッセージに返信する前に毎回実行します。ツールの結果、システムイベント、またはアシスタントの続きの発言では、新たな時刻取得は開始されません。ターン途中で、ユーザーメッセージを示す正確な範囲外マーカーがある場合は、新たな取得を開始します。

1ターンごとの契約は何ですか?

ユーザーからの最新の直接メッセージを解釈したり、それに基づいて行動したりする前に、次の手順を実行します。

  1. ホストのスキル読み込み機能を使って starting-point を読み込みます。
  2. ホストの読み込み結果から、このスキルの具体的な絶対ディレクトリを読み取ります。
  3. そのディレクトリをプロセスランナーの作業ディレクトリに設定し、同梱スクリプトを正確に1回実行します。
  4. JSON を解析し、references/eval-contract.md に記載されたすべてのフィールドがあることを確認します。
  5. アンカーを非公開の starting-point マップに as_of として追加します。
  6. 日付や時刻に依存するツール呼び出しの前に、時間表現を解決します。
  7. セッション履歴に保存されるよう、実際のアシスタント返信に表示用の日付時刻接頭辞を書き込みます。

作業ディレクトリをそのディレクトリに設定して、macOS または Linux で実行します。

mise run refresh

作業ディレクトリをそのディレクトリに設定して、Windows で実行します。

mise run refresh

python または py -3 は、インストール済みのインタープリターである場合に限り使用します。スキルディレクトリ用のシェル変数を使ったり、インストール先のパスを推測したりしてはいけません。読み込み結果に具体的なスキルディレクトリが含まれていない場合は、temporal-anchor-unavailable: skill directory missing を報告し、日付や時刻に依存する作業を中止します。架空のタイムスタンプを渡してはいけません。プロセスの結果がユーザーからの最新の直接メッセージより後に発生している場合に限り、アンカーを再利用できます。

ポータブルスクリプトは --timezone <IANA-zone> を受け付け、次に PROFILE_TIMEZONE を確認し、それ以外の場合はシステムのローカル時刻を使用します。明示的な引数はホストが指定するプロファイル設定を表し、環境変数より優先されます。

コマンドが失敗した場合、無効な JSON を返した場合、または必須フィールドが不足している場合は、日付や時刻に依存する作業を中止し、temporal-anchor-unavailable: に続けて短いエラーを報告します。推測したり、以前の日付や時刻を再利用したり、会話開始時のタイムスタンプにフォールバックしたりしてはいけません。

アンカーを starting-point に紐付けるには?

この非公開の構造を追加します。結果マップ全体を公開してはいけません。

as_of: captured_at, date, time, weekday, timezone, zone_abbreviation, utc_offset, source

次の項目に適用します。

  • 結果: 相対的な完了表現を、正確な日付または日付時刻に変換します。
  • 根拠: 現在の観察と、以前に収集した証拠を区別します。
  • 制約: 期限、有効期間、時間的な境界を解決します。
  • 開始経路: 現時点で可能な操作と、後で可能になる操作を区別します。
  • 不明点: 簡潔な質問1つで解消できるまで、曖昧な表現を未解決のままにします。

時制表現はどのように解釈されますか?

  • ユーザーの元の言葉と著作者性を保ちます。
  • 相対表現によって意味や操作が変わる場合は、解決した絶対日付または日時を明示します。
  • 過去の記述は過去のものとして扱い、将来の依頼は将来に向けたものとして扱います。
  • 日付や時刻に依存するツール引数は絶対値に変換し、ツールが対応している場合はタイムゾーンを含めます。
  • next Friday などの表現は、一般的な解釈によって日付が異なる場合、曖昧なものとして扱います。候補となる日付を示し、簡潔な質問を一つ尋ねます。
  • 会話ですでに解釈の慣例が確立されている場合は、尋ねません。
  • 現地時間の午前0時を過ぎたら、時刻を再取得します。会話の経過時間から日付の切り替わりを推測してはいけません。

返信には何が表示されますか?

リソースの利用条件:ここで名前を挙げたパッケージファイルを使う前に、mise run validate を実行してください。

その現地日付での最初のアシスタント返信では、また現地日付が変わった際にも、次の内容で始めます。

NOW: <weekday>, <full date> at <HH:MM:SS> | <zone abbreviation> | UTC<offset>

その日付の通常のユーザー向け返信は、すべて次の内容で始めます。

[YYYY-MM-DD HH:MM:SS <zone abbreviation>] <result or question>

保持されているアシスタントメッセージを確認し、その日のヘッダーがすでに表示されているかどうかを判断します。コンテキストの圧縮によって判断できない場合は、ヘッダーが欠けたり古くなったりするよりも、現在のヘッダーを繰り返し表示してください。対話形式の確認質問では、質問文の中にプレフィックスを付けます。ツール呼び出しや内部メモにはプレフィックスを付けません。

リテラルのテンプレートは assets/response-prefixes.txt にもあります。時刻の取得に失敗した場合は、日付付きプレフィックスの代わりに失敗マーカーを使用します。

再開時の動作は?

再開後またはコンテキスト圧縮後は、保持されている日付や時刻を使用する前に、時刻を再取得します。このスキルの本文が保持されたコンテキストにない場合は、動作する前に再読み込みします。保存された日時プレフィックスが証明するのは、過去のターンのみです。

どの動作例を読めばよいですか?

リソースの利用条件:ここで名前を挙げたパッケージファイルを使う前に、mise run validate を実行してください。

  • examples/help-command.md で、完全な help 応答を確認します。
  • examples/fresh-direct-turn.md で、実際の UTC 診断、as_of のバインド、両方の表示プレフィックスを確認します。
  • examples/invalid-timezone.md で、終了コード 2、空の標準出力、失敗マーカー、復旧方法を確認します。

段階的な情報開示

このスキルをテストまたは変更する前に、references/eval-contract.md と evals/cases.json を読みます。パッケージ構造を変更するとき、またはネイティブ版からの系譜を確認するときは、references/generation-contract.md を読みます。時刻に関する動作を変更する前に、mise run test でテストを読み込み、実装を変更した後にそのタスクを再実行します。アクティベーション、動作、登録、タイミングを測定する場合に限り、evals/ の残りのファイルを読み込みます。通常のターンでは、これらのファイルを読み込まないでください。

注意点

  • 直接のメッセージに日付や時刻を示す言葉がなくても、時刻の取得を省略してはいけません。
  • ツールの出力、システムイベント、アシスタントの続きのメッセージを、新たな直接のユーザーメッセージとして扱ってはいけません。
  • 最終的な推論の後に時刻を呼び出したり、1回の直接ターンで2回呼び出したりしてはいけません。
  • 解決後にユーザーの時制表現を書き換えてはいけません。
  • 古い根拠を現在の証拠として提示してはいけません。
  • 曖昧な曜日表現について、一つの意味を黙って選んではいけません。
  • ツール呼び出しや内部メモにプレフィックスを付けてはいけません。
  • 設定されたタイムゾーンが無効な場合に、黙ってフォールバックしてはいけません。
  • 時刻コマンドに未解決のスキルディレクトリ変数を含めてはいけません。
  • いずれかの経路でケースが欠けている場合、以前の契約との同等性を主張してはいけません。

制限事項

このスクリプトは、文章からユーザーの意図するタイムゾーンを推測できません。システムのローカル時間が意図するコンテキストではない場合、ホストは --timezone または PROFILE_TIMEZONE を通じて、明示的な IANA タイムゾーンを指定する必要があります。このスキルは日付と時刻を解決し、ツール用の絶対値の引数を準備できますが、実際のリマインダー、カレンダー、デプロイの操作は、別の機能が担います。

ターンの準備が整う条件

スキルが読み込まれ、最新の直接メッセージの後に新しい時計の呼び出しが1回行われ、必要なすべてのフィールドが生成され、as_of が非公開の starting-point マップにバインドされ、日付や時刻に依存するアクションの前に時間に関する表現が解決され、実際にユーザーに提示する応答に必須の現在の日時プレフィックスが含まれている場合に限り、ターンの準備が整っています。古い、欠落している、重複している、または失敗したアンカーがある場合、時間に関する作業はブロックされます。

ファクトリー実行契約

受け入れられる結果は、直接のターンごとに新しい時計アンカーを1つバインドし、そこから相対的な日付表現を解決することです。現在の時計アンカーの動作は維持しつつ、その最小のオーナーを変更します。

  1. mise run ci で現在のパッケージを凍結し、そのダイジェストを記録します。
  2. mise run domain-research-policy を実行し、現在の時計アンカーのソースと反証を判断します。
  3. 指定された時計アンカー操作に対して mise run refresh を実行します。意味上の選択はモデルに委ねます。
  4. mise run decision-policy、mise run ci、行動評価を実行します。失敗した場合は、最も下位のオーナーに戻ります。
  5. mise run invocation-policy -- <receipt> を実行し、すべてのタスク、またはそのドメイン固有の不使用理由を記録します。
  6. 必要に応じて mise run improvement-policy を実行します。保護対象の次元で後退がない場合に限り、変更する次元を1つにとどめます。

契約の確認が必要な場合に限り、mise run use-case-policy で assets/use-case-contract.json を読み込み、mise run evals で evals/evals.json を読み込みます。

Mise は、繰り返し実行可能な処理、順序、レシート、チェックを担います。モデルは、解釈、因果関係の判断、創造的な作業、およびコードでは提供できない直接的な知覚を担います。権限の欠如、証拠の古さ、またはゲートの失敗があれば停止します。

コメント