Skip to content
cccskills
FreePublished on GitHub

run-dev-graph-status

dev-graph node を metadata で検索したいとき、依存・tombstone・completion 状態を副作用なしで確認したいときに使う。

The English summary is being prepared. Showing the original description.

See how to install

Files included (4)

  • SKILL.md12.1 KB
  • prompts/R1-elicit.md2.5 KB
  • prompts/R2-plan.md2.6 KB
  • prompts/R3-status.md3.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Pre-choice usable artifact execution

Purpose & Output Contractの最小の実成果物をmain contextで作成する。effect別のparse/open・secret・irreversible・corrupt guardだけを実行し、現物path・digest・開き方を提示してからaccept-as-is/light/standard/detailedを記録する。accept-as-isはその場でhandoff完了とし、後続sectionを実行しない。

Post-choice selected improvement execution

以下の既存workflow・goal-seek・評価・修正sectionはlight/standard/detailedが記録されてsemantic_evaluator_startedへ遷移した場合だけ実行する。release/exhaustiveは別の明示eventを必要とする。

run-dev-graph-status

Purpose & Output Contract

  • 入力: C24/C11 で read-only 検証済み graph store、scope/filter/tag match mode。
  • 出力: node identity、classification、path、status/closed_at、依存関係、feature/tracker linkage を持つ検索 report。
  • 完了条件: report が graph 実状態と一致し、実行前後の graph/config/content digest が不変で外部副作用0である。

検索と状態表示の行は extract-graph-status.py --repo-root <root> [filter...] だけが作る。script は C24 (resolve-repo-context.py --mode read) で caller root を固定し、一度だけ読んだ graph の bytes を C11 (validate-graph-schema.py の validate) に通し、violation と必須キー欠落が0件のときだけ行を返す。全 filter は AND、同じ filter の繰り返しは OR、--feature は parent_feature か feature_package_id、2つ以上の --tag は --tag-mode any|all を明示する (無ければ exit 2)。各行は graph_node_id/artifact_kind/title/project_id/domain/tags/file_path/status/closed_at/depends_on/dependents/parent_feature/feature_package_id/tracker_binding/issue_linkage/beads_linkage/github_project_linkages を持つ。closed_at は graph の値、dependents は graph 全体の depends_on の逆引きで、LLM が補わない。

script は検索前後の graph/config/content digest を比べ、変化があれば read_only.changed を付けて失敗する。GitHub/Beads command、writer、render、sync の呼び出しは禁止。該当なしは result: empty (exit 0)、schema 不正・root 外 file_path・dangling dependency・必須キー欠落は result: rejected (exit 1、rows 0件) で診断を返す。

ゴールシーク実行

ゴール (Goal)

特定のissue/task/specification/architecture/documentをgraph_node_id/artifact_kind/project_id/domain/status/tagsで検索し、依存関係・close/tombstone状態をread-onlyで確認できる状態になっている

目的・背景 (Why)

特定ノードの検索・状態確認 (要件C11) を独立の読取り専用経路として提供しないと、状態確認のたびに sync/render 相当の重い処理を経由せざるを得ず、副作用のない検索操作が書込みを伴う操作と混同されるリスクがあるため

完了チェックリスト

  • query は許可 filter field と明示 tag match mode だけを持つ
  • extract-graph-status.py が exit0 で validation.status=pass、missing_required_keys と root 外 file_path と dangling dependency が0件である
  • report の status/closed_at/depends_on/dependents/linkage が extract-graph-status.py の rows そのもので、graph snapshot と一致する
  • 該当なしが空 result の成功として返る
  • 実行前後の graph/config/content digest が同一で外部 write が0件である
  • 分離 context の評価役が、report と graph 実状態の一致と実行前後の digest の不変を独立に照合して PASS を返した

通らない経路の checklist 項目 (例: 該当ありの検索での「該当なしが空 result の成功として返る」) は、not_applicable と理由を progress に記録し、完了の判定から外す。

ゴールシークループ

frontmatter の goal_seek.engine: inline / fork: subagent / max_loops: 5 を実行契約とする。固定手順は使わず、未達 checklist と担当 prompts/*.md からその周回の操作を都度生成する。内ループは各周回で完了チェックリストと inner criterion (IN1) を検証する。outer criterion (OUT1 の live-trial、OUT2 の受入テスト) と content-review は内ループの完了判定に含めず、内ループが完了した後の外ループで最大 feedback_contract.max_iterations=3 周で評価する。

ゴールシーク配線

  • 開始時に C24 resolve-repo-context.py --mode read の JSON receipt を得て、repo_root が content_roots.repository の realpath と一致する場合だけ DEV_GRAPH_ROOT=<receipt.repo_root> に固定する。cwd から再解決しない。
  • 元のゴールを $DEV_GRAPH_ROOT/eval-log/run-dev-graph-status-goal-spec.json へ、各 checklist の status/evidence を $DEV_GRAPH_ROOT/eval-log/run-dev-graph-status-progress.json へ記録する。
  • 未達 responsibility を担当する prompts/<R-id>.md を読み、Agent で分離 context に fork する。ユーザー判断が必要な境界だけ AskUserQuestion を使う。
  • semantic_evaluator_started に入ったら、未達の有無にかかわらず、少なくとも1回 Agent で分離 context の評価役を起動する。評価役には report、graph の path、実行前の graph/config/content digest を渡す。評価役は extract-graph-status.py の rows と graph snapshot から report の status/closed_at/depends_on/dependents/linkage が graph の実状態と一致するかを、また実行後の digest を測り直して実行前と同じかを、独立に照合して verdict と根拠を返す。評価役も read-only で、graph/config/content を書かない。main context の自己照合では代えない。verdict は progress に記録する。
  • 各周回末に $DEV_GRAPH_ROOT/eval-log/run-dev-graph-status-intermediate.jsonl へ original_goal、original_goal_hash、current_goal_snapshot、delta_from_original、merged_directive_for_next、drift_signal を append-only で記録する。次周回は直前の merged_directive_for_next を必須入力にする。
  • 5周到達時に未達が残れば完了扱いせず、progress と blocker を親へ handoff する。内ループは、not_applicable を除く全 checklist と inner criterion (IN1) が PASS のときだけ完了する。skill の完了は、そのうえで外ループの outer criterion (OUT1・OUT2) と content-review も PASS になったときとする。

ゴールシーク検証

各周回後に次の検査を実行し、中間成果物の欠落・goal drift・hash 不一致を fail-closed にする。

python3 - "$DEV_GRAPH_ROOT/eval-log/run-dev-graph-status-goal-spec.json" "$DEV_GRAPH_ROOT/eval-log/run-dev-graph-status-intermediate.jsonl" <<'PY'
import hashlib, json, sys
goal = json.load(open(sys.argv[1], encoding='utf-8'))
rows = [json.loads(line) for line in open(sys.argv[2], encoding='utf-8') if line.strip()]
required_keys = {'original_goal','original_goal_hash','current_goal_snapshot','delta_from_original','merged_directive_for_next','drift_signal'}
expected = hashlib.sha256(goal['original_goal'].encode('utf-8')).hexdigest()
assert rows, 'intermediate.jsonl is empty'
for row in rows:
    assert required_keys <= row.keys(), required_keys - row.keys()
    assert row['original_goal'] == goal['original_goal']
    assert row['original_goal_hash'] == expected
PY

Criteria acceptance

  • criteria:IN1: extract-graph-status.pyのrowsに必須キー欠落が0件(missing_required_keysが空)で、検索/状態表示がgraphの実状態と一致する。scriptはvalidate-graph-schema.py(C11)と同じ検証を中で通し、validation.status=passのときだけ行を返す。
  • criteria:OUT1: reportのstatus/closed_at/依存関係はgraphの実状態と一致する。
  • criteria:OUT2: 実行前後のdigestを比較し、graph/content/GitHubの副作用0件を保証する。

Gotchas

  • filter 間は OR に緩めず、全て AND で適用する。複数 tag は指定された match mode に従う。
  • node 本文から status を推測せず、extract-graph-status.py の rows にある status/closed_at をそのまま報告する。
  • 該当なしは空 result の成功とし、schema 不正や dangling dependency と混同しない。
  • writer、sync、render、GitHub/Beads command を呼び出さない。

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 19, 2026

Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 19, 2026

run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 19, 2026

確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 19, 2026

生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 19, 2026

Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。

The English summary is being prepared. Showing the original description.

daishiman/harness-dev10Updated Oct 19, 2026

See all skills by daishiman

Report a problem with this skill