Skip to main content Início Criadores whyzsm tiny-agents harness-accept
harness-accept Acceptance Demo HTML for ship/wait/reject decision — reads stored acceptance_criteria. Triggers: 受け入れ判断, ship/wait/reject, 検収レビュー, acceptance demo. Skip for: implementation, review, release.
Ir para a instalação Skills Marketplace Descubra e explore skills de IA criadas pela comunidade.
Ocupações relacionadas SOC
Baseado na classificação ocupacional SOC
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Mostrar detalhes do prompt Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
npx skills add https://github.com/whyzsm/tiny-agents --skill harness-acceptO comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.
Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.
Baixar Zip Baixando... Explorador de arquivos
3 arquivos Mais deste repositório tech-tmax-backend-architect-team Single-Agent T-MAX Java backend architecture and engineering rule package. Use when Codex must design, implement, review, or diagnose T-MAX backend services involving Java 8, Spring Boot, Kylin, MyBatis XML, TiDB/MySQL, Apollo/Nacos, Feign, AnePageHelper, ResponseResult/DataGridResult, UEP export, Redis, RabbitMQ, or Maven multi-module repositories. Routes one Agent through repository intake, architecture decisions, API/data contracts, implementation diagnosis, quality/security review, and bounded evidence loops while keeping builds, tests, live calls, commits, and pushes as separate authority boundaries.
Create polished consulting-style single-file HTML research reports from messy business notes, screenshots, metrics, and iterative user feedback. Use this skill whenever the user asks for a 咨询风/艾瑞咨询风/研究报告/汇报报告/HTML报告, wants business or AI landing-practice material turned into a management-facing report, asks to add charts/diagrams, or asks to update report metrics and keep the whole HTML report consistent.
harmonyos-app-store-self-check Audit HarmonyOS applications for AppGallery/AGC release readiness, including Huawei UX/HMI controls, system-feature integrations, and performance gates for multi-input interaction, latency, frame rate, content display, memory, and CPU. Use when users ask for 鸿蒙上架自检、应用市场审核、AGC发布前检查、控件/系统特性/人机交互/签名/隐私/权限/截图/性能核对或 release 包门禁, especially for Stage-model projects with module.json5, build-profile.json5, hvigorw, and local-first data constraints.
name harness-accept description Acceptance Demo HTML for ship/wait/reject decision — reads stored acceptance_criteria. Triggers: 受け入れ判断, ship/wait/reject, 検収レビュー, acceptance demo. Skip for: implementation, review, release. description-en Acceptance Demo HTML for ship/wait/reject decision — reads stored acceptance_criteria. Triggers: 受け入れ判断, ship/wait/reject, 検収レビュー, acceptance demo. Skip for: implementation, review, release. description-ja 実装完了直後の受け入れ判断 (ship / wait / reject) 前に Acceptance Demo HTML を生成する。harness-plan-brief が `personal-preference.v1` で書き込んだ acceptance_criteria を `user_request_hash` 経由で取得し、各基準ごとに verified / unverified を表示。`recommendation` を ship / wait / reject の 3 値で算出し、根拠を HTML 上で可視化する。Use when: 受け入れ判断, 受入レビュー, ship/wait/reject 判定, 検収レビュー。Do NOT load for: 実装作業, code review, release。 allowed-tools ["Read","Write","Edit","Bash"] argument-hint [task-description] user-invocable true
harness-accept
非エンジニアの発注者・プロデューサー職向けに、実装完了タスクの受け入れ判断 (ship / wait / reject) を HTML 1 枚 で提示するスキル。
発注者の認知負荷ピーク (3) 受け入れ判断の段階で使う。
Phase 65.1.x (harness-plan-brief) の対構造として動作し、Plan Brief で承認した acceptance_criteria を read 側で取り戻して評価する。
Quick Reference
「Acceptance Demo を作って 」 → このスキル
「受け入れ判断したい 」 → このスキル
「ship/wait/reject 判定 」 → このスキル
責任境界
範囲 このスキルの責務 検索 現プロジェクトのみ (project: <current>, strict_project: true を必ず指定)クロスプロジェクト やらない (Phase 65.3 以降で --cross-project-group <name> flag で opt-in 解放)Plan Brief 連携 user_request_hash を join key として personal-preference.v1 (Phase 65.1.4) を read書き込み やらない (Acceptance 承認後の memory write は accept-record-decision.sh の責務) recommendation 算出 verified / 全 criteria の比率で 0.8 / 0.5 閾値判定。ロジックは scripts/render-html.sh 直前で計算
入力
引数 [task-description] にユーザーの request を渡す (Plan Brief 時と同じ文を使う)。
引数なしの場合は対話形式で受け取る。
出力
出力 パス 形式 Acceptance Demo HTML .claude/state/views/accept-<timestamp>.html単独で開ける HTML (no server, no JS framework) Acceptance context JSON .claude/state/views/accept-<timestamp>.context.jsonacceptance-context.v1 schema
Schema: acceptance-context.v1
{
"schema" : "acceptance-context.v1" ,
"user_request" : "string" ,
"user_request_hash"
:
"sha256 hex (Plan Brief 側の personal-preference.v1 と join)"
,
"demo_artifacts"
:
[
{
"kind"
:
"video|screenshot|text"
,
"path"
:
"string"
}
]
,
"verified_criteria"
:
[
{
"name"
:
"string"
,
"passed"
:
true
,
"evidence"
:
"string"
}
]
,
"tdd_verified"
:
"yes|no|not-required|skip:<reason>"
,
"unverified_caveats"
:
[
"string"
]
,
"past_issue_patterns"
:
[
{
"pattern_id"
:
"P5"
,
"title"
:
"string"
,
"verified_in_current_task"
:
true
}
]
,
"recommendation"
:
"ship|wait|reject"
,
"recommendation_evidence"
:
[
"string"
]
,
"project"
:
"string"
,
"generated_at"
:
"ISO8601"
}
Recommendation 算出ロジック verified_count = count of verified_criteria where passed=true
total_criteria = count of verified_criteria
ratio = verified_count / total_criteria (total=0 のときは 0)
ratio >= 0.8 → "ship"
ratio >= 0.5 → "wait"
ratio < 0.5 → "reject"
total = 0 → "reject" (criteria 0 件は判定不能、安全側 reject)
評価根拠は recommendation_evidence に literal な数値で残す。
例: "verified 4 件 / 全 5 件 (80%) → ship 閾値以上"
Execution Flow スキル起動時、Claude は以下の手順で動作する。
Step 1: project name と user_request_hash を解決 PROJECT_NAME="$(basename "$(git rev-parse --show-toplevel) " ) "
USER_REQUEST_HASH="$(printf '%s' "$USER_REQUEST " | sha256sum | awk '{print $1}') "
PROJECT_NAME が空 (git 外) の場合は current をデフォルトに使う。
Step 2: harness-mem を project-only で検索し、Plan Brief 側 record を取得 (default) 引数に --cross-project-group <name> flag がない 場合 (default behavior):
mcp__harness__harness_mem_search を以下のパラメータで呼び出す:
project: <PROJECT_NAME>
strict_project: true
tags: ["personal-preference", "plan-brief-approval"]
limit: 10
重要 : project パラメータは必須 。strict_project: true を指定し、cross-project な検索は絶対に行わない 。
取得した record を data.user_request_hash == <USER_REQUEST_HASH> でフィルタし、最も新しい 1 件を選ぶ。
これが Plan Brief 時の承認内容 (chosen_option / acceptance_criteria 等) を保持している。
Step 2 (alt): cross-project search (Phase 65.3.5 opt-in) 引数に --cross-project-group <name> flag がある 場合のみ、横断 group 内の他プロジェクトでの
類似 plan-brief-approval / acceptance-decision 履歴を取得する (D43 Option α):
MEMBERS_JSON="$(bash scripts/load-cross-project-groups.sh --group "<name>" 2>/dev/null) " || {
echo "ERROR: cross-project group not found: <name>" >&2
exit 1
}
MEMBERS_JSON が [] の場合は default の単一 project search に fallback。
MEMBERS_JSON が非空の場合、各 member project ごとに MCP search を 1 回発行:
for each project in MEMBERS_JSON:
mcp__harness__harness_mem_search(
project: <member>,
strict_project: true,
tags: ["personal-preference", "plan-brief-approval"],
limit: 10
)
結果を client 側でマージし、data.user_request_hash == <USER_REQUEST_HASH> でフィルタ。
hash 一致は基本的に同一 user request 由来のため複数 project での重複は稀だが、念のため id 単位で dedupe。
cross-project 由来の record を採用すると過去他案件の chosen_option / acceptance_criteria が混入する
可能性があるため、HTML 出力時は --with-redaction flag を必ず使用
bash scripts/render-html.sh --template accept ... --with-redaction
詳細は .claude/rules/cross-repo-handoff.md の「Phase 65.3 実装決定事項 (D43)」を参照。
Step 3: 過去の問題パターンを取得 (Phase 65.2.2 委譲) bash scripts/accept-past-issues.sh --project "$PROJECT_NAME " --task "$USER_REQUEST " > "$PAST_ISSUES_JSON "
このスクリプトは patterns.md (P1-P33) と過去の acceptance-context.v1 record を semantic search し、
最大 3 件の past-issue.v1 を返す。各々 verified_in_current_task: bool 付き。
Step 4: verified_criteria を組み立てる Plan Brief 時の acceptance_criteria 各項目について、現タスクの状態を評価する。
ユーザー (もしくは Claude) が「verify した evidence」を提示し、evidence 文字列を埋める。
evidence が空文字列の場合、HTML 上で警告表示される (DoD c)。
TDD が必要な task では、Acceptance Demo に TDD verified: yes|no の 1 行を必ず出す。
TDD 不要または skip の場合は TDD verified: not-required または TDD verified: skip:<reason> と表示する。
yes にできるのは .claude/state/tdd-red-log/<task-id>.jsonl の Red 証跡、または literal failing test output が確認できる時だけ。
Step 5: recommendation を算出する 上記「Recommendation 算出ロジック」に従って ship / wait / reject を決定する。
Step 6: HTML を生成する scripts/render-html.sh (Phase 65.1.1) を templates/html/accept.html.template で呼ぶ:
bash scripts/render-html.sh \
--template accept \
--data "$CONTEXT_JSON " \
--out "$HTML_OUT "
Step 7: ブラウザで自動 open する scripts/plan-brief-open.sh (Phase 65.1.2 で導入された 汎用 OS dispatcher ) を再利用:
bash scripts/plan-brief-open.sh "$HTML_OUT "
注 : スクリプト名に「plan-brief」が入っているが、実体は OS 別 browser open dispatcher で kind 中立。
Phase 65.1.2 で先に導入されたため historical name。Layer 3 (HTML 直前最終 scan) 等の他用途でも再利用される。
BROWSER=true の env が設定されている場合 (CI 環境)、open は skip され printf で path だけ出力する。
Step 8: ユーザー判断待ち 「ship / wait / reject の recommendation を採用するか、override するか」を確認する。
判断後の memory write は別スキル (accept-record-decision.sh、Phase 65.2.3) の責務。
失敗時の挙動 失敗 挙動 mcp__harness__harness_mem_search 不達警告を表示し、verified_criteria を空配列で続行 (recommendation = reject) Plan Brief 側 record が見つからない warning を出し、verified_criteria を空配列で続行 git rev-parse --show-toplevel 失敗PROJECT_NAME=current で続行accept-past-issues.sh 失敗past_issue_patterns: [] で続行 (best-effort)render-html.sh 失敗エラーを stderr に出力し exit 1
Related
harness-plan-brief (Phase 65.1.2) — 計画段階の対構造スキル。本スキルは Plan Brief 時の personal-preference.v1 を user_request_hash で join して readscripts/accept-past-issues.sh (Phase 65.2.2) — 過去の問題パターン取得 (read side)scripts/accept-record-decision.sh (Phase 65.2.3) — 承認 memory write (acceptance-decision.v1)scripts/render-html.sh (Phase 65.1.1) — HTML テンプレートエンジンscripts/plan-brief-open.sh (Phase 65.1.2) — 汎用 OS browser dispatcherharness-progress skill (Phase 65.4.1) — 進行管理スキル (3 surface のうち真ん中) 