원클릭으로 Manus에서 모든 스킬 실행

design

스타3

포크0

업데이트2026년 7월 18일 03:09

要件が確定した後、実装に入る前に、構造選択・I/O 境界・依存方向・外部制約を**会話 / 一時ファイル**で検討するスキル。設計ドキュメントを永続化することは目的としない — コードを読めばわかる範囲は書かず、**コードを読んでもわからない外部要因・制約・選択肢と却下理由のみ ADR に蒸留**する (ADR 化は `adr-writer` の責務)。設計の検討内容は temp scratchpad (`<work-dir>/design-scratch.md` 等、配布先で gitignore 推奨) に書き、PR マージ後は破棄。要件 → 実装の間、`pr-review-respond` で VALID_DEFER を新規 issue 化する時、「設計どうする」「アーキ考えて」「どこに置く」「依存方向は」「I/O 境界どこ」「先にデザインして」のような要請、いずれでも必ず起動すること。本スキルは設計の **検討と決定の蒸留** までで、実装・テスト・ADR 文面化は別スキルに渡す。詳細仕様の永続化や spec ファイル化は意図的にしない。

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

kanade0404

kanade0404/resume

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

관련 직업SOC

SOC 직업 분류 기준

소프트웨어 개발자컴퓨터 및 수학직·SOC 15-1252

파일 탐색기

3 개 파일

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	design
description	要件が確定した後、実装に入る前に、構造選択・I/O 境界・依存方向・外部制約を会話 / 一時ファイルで検討するスキル。設計ドキュメントを永続化することは目的としない — コードを読めばわかる範囲は書かず、コードを読んでもわからない外部要因・制約・選択肢と却下理由のみ ADR に蒸留する (ADR 化は `adr-writer` の責務)。設計の検討内容は temp scratchpad (`<work-dir>/design-scratch.md` 等、配布先で gitignore 推奨) に書き、PR マージ後は破棄。要件 → 実装の間、`pr-review-respond` で VALID_DEFER を新規 issue 化する時、「設計どうする」「アーキ考えて」「どこに置く」「依存方向は」「I/O 境界どこ」「先にデザインして」のような要請、いずれでも必ず起動すること。本スキルは設計の検討と決定の蒸留までで、実装・テスト・ADR 文面化は別スキルに渡す。詳細仕様の永続化や spec ファイル化は意図的にしない。
claudecode	{"allowed-tools":["Read","Write","Edit","Bash","Task"]}

Design

規律: コードを読めばわかる設計を文書に残さない。残すのは コードを読んでもわからないもの (外部制約・却下した選択肢・トレードオフの根拠) のみ、それも adr-writer 経由で ADR に蒸留する。

設計ドキュメントを長期保管しない理由：

実装と乖離する (rot)
読み手は結局コードを読む (二度手間)
「決定の理由」だけがコードから読めず、それは ADR のスコープ

本スキルは 検討の場 を temp に確保し、決定を ADR に渡し、過程は破棄するワークフローを駆動する。

いつ起動するか

要件が確定した直後 (requirements / requirements-review が PASS)
pr-review-respond で VALID_DEFER を新規 issue / 別 PR に切る時の方針メモ
既存コードに大きく手を入れる前 (アーキへの影響範囲が読めない時)
ユーザに「設計」「アーキ」「どこに置く」「I/O 境界」「依存方向」「責務」と聞かれた時

逆に 起動しない:

設計上の選択がほぼ自明な小修正 (typo / 1 関数の振る舞い修正)
リファクタのみで構造を増やさない (tidy-first の領域)
既に ADR が存在する領域への追従実装

ワークフロー

Step 1 — Scratchpad の準備

<work-dir>/design-scratch.md を作る。配置先の指針：

配布先プロジェクトに .gitignore で design-scratch.md / *.scratch.md / z/**/scratch.md を追加 (本スキルは推奨提示まで、自動編集はしない)
既存の sengoku 流 z/{task}/{session}/ パターンがあればそこを使う

Step 2 — 検討項目チェックリスト

scratchpad に以下を 1 項目ずつ書く。書けない項目があるならそれが論点:

境界 (Boundaries): 入出力は何か / 外部 (DB / API / 他サービス) との接点はどこか / 同期 or 非同期 / batch or stream
依存方向 (Direction of Dependencies): 安定したものに依存する / domain → infra ではなく infra → domain にしない / 循環参照を作らない
責務 (Responsibilities): この変更で増える module / class / function は何の責務か / 既存責務との重複は無いか
可逆性 (Reversibility): この設計選択は後で変えられるか / one-way door か two-way door か (Bezos の表現)
外部制約 (External Constraints): コードからは読めない事実 — 法令・SLA・他チームとの API 契約・本番運用上の理由・パフォーマンス予算
テスタビリティ (Testability): 純関数として抽出できるか / I/O は薄い shell に押し出せるか / test double 不要で書けるか
代替案 (Alternatives): 採用案以外に検討した選択肢を最低 2 つ / 各却下理由を 1 行

Step 3 — 検討の進め方

Single-pass で書ききらない。書きながら却下案を増やす。3 案以上比較できないなら検討が浅い。

迷ったら投げる質問：

「これを 1 年後に削除するとしたら何箇所変更が必要か」 (一way door 度の指標)
「これがコードから読めるか」 (Yes なら ADR にしない)
「既存コードのどの慣例と一致するか / 矛盾するか」 (慣例と矛盾するなら ADR 必須)
「この決定の前提となる外部要因は何か」 (前提が変われば再考する trigger)

Step 4 — ADR 化判定

検討が固まったら adr-writer を呼ぶ (Task tool 経由)。adr-writer 側が「ADR に値するか」を 1 次判定する。判定基準は当該スキル参照。

ADR に値しないと判定された場合は、何も永続化しない。scratchpad は PR マージ後に破棄。

Step 5 — design-review への引き渡し

scratchpad と (生成された場合は) ADR ドラフトをセットで design-review に渡す。レビュアー subagent が severity 三分類で findings を返す。

Critical が残っているなら Step 2 に戻る。Important 以下は次の実装フェーズに引き継ぎ可能。

Step 6 — Scratchpad の破棄計画

PR マージ後に scratchpad を削除する旨を PR description に明記する (約束を残す)。例：

## Scratchpad
- z/<task>/<session>/design-scratch.md (post-merge: delete)
- ADR added: docs/adr/0042-... .md (persistent)

出力フォーマット

ユーザへの最終報告：

## Design

### Scratchpad
- Path: <work-dir>/design-scratch.md (temp, gitignored)

### 採用案
<1-3 行で要約>

### 却下案 (理由)
- <案 A>: <却下理由 1 行>
- <案 B>: <却下理由 1 行>

### ADR 化判定
- 値する / 値しない (理由 1 行)
- (値する場合) ADR draft → adr-writer に dispatch 済 → docs/adr/<NNNN>-<slug>.md

### Review
- design-review findings: Critical=<n> / Important=<n> / Minor=<n>
- Critical 残: <あれば一覧 / なければ "なし">

### 次の手
- 実装へ (`tdd` / 直接編集) / Critical 解消のため再設計

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

本セクションは成果物ベースで境界を定義する (動詞ではなく出力物で語る)。

出力する成果物

design-scratch.md (temp ファイル 1 つ) — 採用案 + 却下案最低 2 個 + 却下理由を含む
adr-writer への dispatch 入力 (該当時のみ、ADR 候補のネタ)
design-review への dispatch 入力
ユーザ向け Design レポート (Scratchpad path / 採用 / 却下 / ADR 化判定 / Review findings / 次の手の固定構造)

出力しない成果物

永続化された spec.md / design.md: 設計仕様の長期保管ファイルは作らない。
実装コード / テストコード: 検討までで止める。実装は tdd / 直接編集の出力。
ADR の本文文字列: adr-writer が出す。本スキルは ADR 候補のネタを渡すまで。
要件文書の修正: 要件側の曖昧さは requirements / requirements-review に戻す。
大規模な ER 図 / シーケンス図: 図はコードと乖離する。必要なら ADR の Context に短い記述として埋め込む程度。
scratchpad の削除コミット: PR マージ後の scratchpad 削除は人間 / 後続スキル (clean_gone 系) の責任、本スキルからは出さない。

既知の限界

「コードを読めばわかる」の境界が主観: 慣例的な構造選択は ADR 不要だが、慣例から外れる選択は ADR 必須。境界判定は人間判断に委ねる。
Solo dev 前提: 複数人レビューを前提にしない。チーム導入時は Mob Elaboration 的な検討儀式が別途必要 (AI-DLC 参照)。
scratchpad の gitignore 設定は提案のみ: .gitignore を自動編集しない。プロジェクト規約の更新は別経路。
検討の深さは時間予算依存: Step 2 のチェックリスト全項目を書ききるのは大規模設計のときのみ。小設計では「境界 / 依存方向 / 代替案」3 項目だけ書いて先に進めて良い。