一键在 Manus 中运行任何 Skill

feature-loop

星标3

分支0

更新时间2026年7月18日 03:09

1 つの変更要求を、受け入れ条件の確定から実装・出荷・PR 決着の監視・ハーネス自己改善まで一気通貫で回す最上位オーケストレータスキル。入口で要求の複雑さを**観測可能な決定表**で判定し、明確で小さければ受け入れ条件を 1 ショット確認して即実装へ、曖昧/大きければ `grill-with-docs` で詰める。以降 `tdd`/`tidy-first` で実装 → `shipping` で品質ゲート〜CI〜レビュー対応を merge-ready まで収束 → `pr-monitor` で merge/close を監視 → 決着で `retro` が自己改善提案、と各段を fresh subagent / skill に委譲する。本スキルはコードを書かず、段の順序と handoff と決定表の告知だけを main で持つ。「最初から最後まで回して」「受け入れ条件決めて実装して PR 決着まで面倒見て」「feature を頭から ship・監視・振り返りまで」、さらに口語の丸投げ「これ実装したいんだけど全部やっといて」「あとは丸ごとまかせる」のような、1 つの変更要求を実装＋後工程まで委任する意図で必ず起動する。設計だけ・実装だけ・出荷だけ・監視だけ・振り返りだけの単機能要請、および「バグ直して」「このタイポ直して」のような単発修正は該当する個別 skill (`grill-with-docs` / `tdd` / `shipping` / `pr-monitor` / `retro`) を名指しで使い、本スキルは起動しない。PR の merge 操作はせず、決着 (merge/close) を監視で待つ。

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

kanade0404

kanade0404/resume

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

相关职业SOC

基于 SOC 职业分类

软件开发工程师计算机与数学类职业·SOC 15-1252

文件资源管理器

4 个文件

SKILL.md

readonly

同仓库更多 Skills

同仓库

career-grilling

kanade0404/resume

Interviews the user relentlessly to build career self-knowledge for a job change, career profile work, or negotiation prep. Grounds every question first in the private Obsidian vault (profile/*.md, prior grill logs, grill-ledger.md) and this repo's docs/resume-update-plan.md / docs/action-plan.md gaps, then extracts concrete episodes, chained "why" reasoning, blind spots against the user's own written record, and a decision journal with mandatory confidence follow-ups. Extends the grilling one-question-at-a-time engine; never uses selection-style dialog tools (AskUserQuestion). Use for career or job-change consultation, career grilling, resume grilling, or filling profile/*.md stubs — trigger phrases include "キャリア壁打ち", "キャリア相談", "転職相談", "経歴の壁打ち", "career grilling", "career interview", "profileを埋めたい", "暗黙知を掘り出して". Writes nothing to the private vault without prior /add-dir, and never writes compensation figures, employer/target-company names, or reasons for leaving into this public repository.

2026-07-193

adr-writer

kanade0404/resume

設計検討から出てきた決定について「これは ADR (Architecture Decision Record) に値するか」を判定し、値する場合のみ [adr-tools](https://github.com/npryce/adr-tools) の `adr new` コマンドで Michael Nygard 形式の ADR を生成するスキル。**コードを読めばわかる決定は ADR にしない**。値する基準は (1) 将来「なぜこうした?」と疑問になりうる (2) 容易に変更できない one-way door (3) 別の選択肢があり却下したのいずれか。番号採番・slug 生成・テンプレ展開・supersede リンクの相互更新は全て `adr new` / `adr new -s` / `adr new -l` に委譲する。`design` Step 4 から呼ばれる主経路、設計判断を残したい時、「これ ADR にして」「決定記録残して」「architecture decision」「設計判断のドキュメント」のような要請、いずれでも必ず起動すること。本スキルは ADR 単体の生成と判定までで、設計検討自体や実装には関与しない。詳細仕様や API ドキュメントの代わりに ADR を使うことは推奨しない (ADR は「決定」の記録、「使い方」のドキュメントではない)。adr-tools が未インストールの場合は導入手順を提示し、勝手に install しない。

2026-07-183

ci-self-heal

kanade0404/resume

PR 作成後・push 後の CI が失敗した際に、ログから root cause を特定し、修正コミットを当てて再 push する自己修復ループを駆動するスキル。**root cause 不明なまま再試行しない** (NO FIXES WITHOUT ROOT CAUSE)。3 連続失敗で停止し、architecture を疑ってユーザに escalate (3-failure architecture gate)。`pr-review-respond` Phase E から呼ばれる主経路、`gh pr create` 直後で CI が回り始めた時、CI が赤になった時、「CI 直して」「ビルド失敗してる」「テストが落ちてる on CI」「pipeline 緑にして」のような要請、いずれでも必ず起動すること。本スキルは CI ログ取得 → root cause 仮説 → 修正 → 再 push → 再 watch のループ駆動と、停止判断を担う。修正コード自体は呼出側スキル (`tdd` / `tidy-first` / `code-review`) を経由する。flaky / 環境問題と判定したら retry-to-green は禁止 — 原因分類してユーザに返す。

2026-07-183

code-review

kanade0404/resume

実装が完了した後・PR 作成前に、変更差分を白紙の subagent にレビューさせて Critical / Important / Minor の三分類で findings を返すゲート用スキル。観点は spec 準拠、責務逸脱、依存方向違反、null/error handling、命名、test coverage、副作用混入、unused code、performative comment / dead code 残し、AI 生成パターン (self-consistent assertion 等は `test-review` 参照)。実装直後・「コードレビューして」「PR 出す前にチェック」「実装見て」「これで OK?」「マージ前確認」のような要請、`pr-review-respond` での修正完了直後、いずれでも必ず起動すること。本スキルは subagent によるセルフ・コードレビューで、CodeRabbit / Devin / 人間レビュアーの代替ではなく **PR 起票前のセーフティネット**。findings は実装者 (= 本スキル呼出側) に返り、修正後に `verify-done` を経て PR 起票へ。subagent には書き手の前提知識を持ち込ませない。

2026-07-183

commit

kanade0404/resume

git commit を「観測 → ガード → 明示パス staging → ファイル経由メッセージ → 検証」の固定順で作る skill。`git add -A` / `git add .` / heredoc を使わないため、permission / hook で汎用コマンドが拒否される環境でもブロックされずに完走する。「commit して」「コミット作って」「この変更コミットしといて」「stage して commit」「きりのいいところで commit 切って」「一区切りだから記録して」のような要請、および tdd / tidy-first / shipping の各サイクル終端の commit 作成で必ず起動すること。commit までが責務 — push・PR 作成は `shipping`(検証ループ付き)または `commit-commands:commit-push-pr` に、リリースタグは RELEASING.md の手順に、structural / behavioral の分割判断は `tidy-first` に渡す。履歴書き換え (amend / rebase / squash / reset / revert) と commit 取り消しは範囲外 — 新規 commit を作る要請だけを扱う。

2026-07-183

design-review

kanade0404/resume

ソフトウェア設計の成果物（ADR、ドメインモデル、モジュール構造、アーキテクチャ提案、設計差分、`software-design` skill の提案）を、書き手バイアスのない別エージェントに白紙で読ませて構造化された指摘を返すレビュー専用スキル。philosophy of software design (Ousterhout)、immutable data model (kawasima)、TM法 (佐藤正美)、関数型プログラミング、DDD (Vlad Khononov)、TDD (Kent Beck)、Railway Oriented Programming (Scott Wlaschin)、Fundamentals of Software Architecture、xUnit Test Patterns、CQRS、Event Sourcing、ADR (Nygard)、Secure by Design の 13 レンズを checklist で当てる。「設計レビューして」「ADR レビューして」「設計で抜け落ちている観点ない?」「別エージェントで読み直して」「設計の最終チェック」「この提案で行く?」「集約境界これで OK?」「Result への置き換え、抜けない?」「Secure by Design 観点で監査して」「ADR の Negative consequences 薄い」のような要請、`software-design` の Proposal/ADR 最終確認、PR の設計関連ドキュメント / コード境界の妥当性確認、設計セッション後の「セルフレビューでない外部視点」が必要な場面で必ず起動する。Agent ツールで subagent を dispatch して評価し、書き手（同セッションの主エージェント）にレビューさせない。テスト本体のレビューは `test-review`、調査は `research-practices`、Skill 本体の作成・トリガ調整は `skill-builder` 担当のため、それらの目的が明確な依頼ではこのスキルを起動しない。実装を書き換える作業（コード修正、リファクタリング実施、lint 違反対応）は範囲外で、本スキルは「読んで指摘する」レビュー専用である。

2026-07-183

name	feature-loop
description	1 つの変更要求を、受け入れ条件の確定から実装・出荷・PR 決着の監視・ハーネス自己改善まで一気通貫で回す最上位オーケストレータスキル。入口で要求の複雑さを観測可能な決定表で判定し、明確で小さければ受け入れ条件を 1 ショット確認して即実装へ、曖昧/大きければ `grill-with-docs` で詰める。以降 `tdd`/`tidy-first` で実装 → `shipping` で品質ゲート〜CI〜レビュー対応を merge-ready まで収束 → `pr-monitor` で merge/close を監視 → 決着で `retro` が自己改善提案、と各段を fresh subagent / skill に委譲する。本スキルはコードを書かず、段の順序と handoff と決定表の告知だけを main で持つ。「最初から最後まで回して」「受け入れ条件決めて実装して PR 決着まで面倒見て」「feature を頭から ship・監視・振り返りまで」、さらに口語の丸投げ「これ実装したいんだけど全部やっといて」「あとは丸ごとまかせる」のような、1 つの変更要求を実装＋後工程まで委任する意図で必ず起動する。設計だけ・実装だけ・出荷だけ・監視だけ・振り返りだけの単機能要請、および「バグ直して」「このタイポ直して」のような単発修正は該当する個別 skill (`grill-with-docs` / `tdd` / `shipping` / `pr-monitor` / `retro`) を名指しで使い、本スキルは起動しない。PR の merge 操作はせず、決着 (merge/close) を監視で待つ。
allowed-tools	["Read","Task","Skill","AskUserQuestion","Bash(git status )","Bash(git rev-parse )","Bash(git branch )","Bash(gh pr view )"]

feature-loop — 入口から PR 決着・自己改善までの最上位ループ

構成原則: 各段は個別 skill / fresh subagent に委譲する。本スキル (orchestrator) は main に残り、段の順序・handoff・決定表の告知だけを持つ。コードは書かない (shipping と同じ規律)。 停止しない条件: PR は merge しない。shipping は merge-ready で止め、pr-monitor が決着を待ち、retro は提案のみ。各段の停止/escalation はその skill の規律に従う。

パイプライン

intake (決定表)         implement            ship                 monitor            improve
heavy: grill-with-docs  tdd / tidy-first  →  shipping          →  pr-monitor      →  retro
light: 受け入れ条件1shot                     (simplify→review      (merge/close 監視)   (決着で起動)
                                              →verify→PR→CI→…)

いつ起動するか

「最初から最後まで回して」「受け入れ条件決めて実装して PR 決着まで」「feature を頭から ship・監視・振り返りまで」
口語の丸投げ「これ実装したいんだけど全部やっといて」「あとは丸ごとまかせる」(実装＋後工程まで含む委任の意図)
1 つの変更を end-to-end で委任したいとき

逆に 起動しない (名指しで個別 skill へ):

要求	渡す先
設計・要件詰めだけ	`grill-with-docs`
実装だけ	`tdd` / `tidy-first`
出荷 (review〜CI〜PR) だけ	`shipping`
PR 決着の監視だけ	`pr-monitor`
振り返りだけ	`retro`

Step 1 — intake: heavy / light を決定表で判定し告知

要求と現状 (受け入れ条件の有無、未確定点、影響範囲) を観測し、決定表で経路を選ぶ。判定は隠さず「観測したシグナル → 選んだ行」を 1 行で告知してから進む (緩和後の規約 = 明示・観測可能な分岐、Conditional workflow pattern)。

観測シグナル (全て満たす)	経路
受け入れ条件が明示済みかつ未確定点 0 かつ影響 ≤ 1 モジュールかつ ADR 級の設計判断なし	light
上記のいずれかを欠く	heavy

heavy: Skill(grill-with-docs) を起動し、受け入れ条件・用語・既存設計との整合を詰める。完了後 Step 2 へ。
light: 受け入れ条件を 1 ショットで明文化し (AskUserQuestion で 1 回だけ確認)、合意できたら Step 2 へ。

ユーザは告知された経路を override 可 (「heavy で」「light で」)。override されたらその経路に従う。

Step 2 — implement: tdd / tidy-first

受け入れ条件を満たす実装を、変更種別でルーティングして fresh subagent に出す:

変更種別	dispatch 先
振る舞いが変わる (新機能 / バグ修正 / 仕様変更)	`tdd` (RED→GREEN)
構造のみ (rename / extract / dead code 削除)	`tidy-first`

GREEN になったら Step 3 へ。未 GREEN / WIP のまま先へ進めない。

Step 3 — ship: shipping

Skill(shipping) に handoff。shipping が Phase 1a simplify → 1b code-review → verify-done → PR materialize → CI 緑化 (ci-self-heal) + 自動レビュー対応 (pr-review-respond) の収束ループ → 最終 verify-done を回し、merge-ready で停止する。

shipping verdict	次の手
SHIPPED (merge-ready)	PR 番号を確保して Step 4 へ
BLOCKED / ESCALATED	パイプライン中断。shipping の handback を添えてユーザに返す (Critical 対処・architecture 再考は上流)

Step 4 — monitor: pr-monitor → retro

Skill(pr-monitor) を起動し、Step 3 の PR 番号を渡す。pr-monitor が merge/close まで監視し、決着を検出したら retro を自動起動する。feature-loop の handoff はここで完了 — 以降は pr-monitor / retro が駆動する。

出力フォーマット

# feature-loop: <要求 1 行> → PR #<n>

## Pipeline
- intake: <light / heavy (grill-with-docs)>  ← 決定表: <満たした/欠けたシグナル>
- implement: <tdd / tidy-first> → GREEN
- ship: shipping → <SHIPPED merge-ready / BLOCKED / ESCALATED>
- monitor: pr-monitor 起動 (<cron / ScheduleWakeup / 手動>) → 決着で retro

## Verdict
- <HANDED_OFF (pr-monitor 監視中) / BLOCKED / ESCALATED>
- Next: <merge 待ち (retro は決着で自動) / Critical 対処 / 設計戻し …>

各段 skill の本体出力 (grill QA / findings / cycle ledger) は再掲しない。handback / verdict だけ載せる。

出力する成果物 / 出力しない成果物

出力する成果物

Pipeline ログ (intake 経路 + 決定表のどの行か + 各段の verdict)
段間の handoff 観測 (GREEN 到達 / PR 番号 / shipping verdict)
Verdict 1 行 (HANDED_OFF / BLOCKED / ESCALATED + Next)

出力しない成果物

実装コード・修正差分: 本スキルは書かない。tdd / tidy-first / shipping 配下の subagent が出す。
各段 skill の本体出力の再掲: grill の QA、code-review findings、cycle ledger は各 skill が持つ。本スキルは handback 参照のみ。
PR の merge / close 操作: 決着は人間/別自動化。pr-monitor が事実を待つ。
隠れた intake 分岐: 経路判定は必ず告知する。黙って heavy/light を切り替えない。
個別段の単独実行: 単機能要請は個別 skill へ。本スキルは end-to-end 委任のときだけ。

既知の限界

single PR / single feature 前提: 1 ループ 1 PR。複数並走は想定しない。
長期監視は環境依存: Step 4 の長期 (日単位) 監視は /schedule (cron) を要する。無ければ pr-monitor が ScheduleWakeup / 手動にフォールバックする。
マルチモデル未検証: trigger eval は本セッションのモデルのみ。