ワンクリックでManusで任意のスキルを実行

decision

スター7

フォーク1

更新日2026年7月19日 21:10

Log an architectural decision (ADR) so the reasoning survives across sessions. Use right after you pick a library, a pattern, or a trade-off. Takes 30 seconds while it's fresh. Prevents "why did we do it this way?" re-debates months later. Also retrieves past decisions with `/decision list` or `/decision <topic>`. TRIGGER — suggest this skill (even without /decision prefix) when the user: picks between options ("X or Y?", "should we use A vs B", "choosing between"), asks "why did we pick X?", "why are we using Y?", "why did we choose", wants to document a trade-off, mentions "architectural decision", "ADR", "tech choice", accepts a trade-off ("going with X despite the downside of Y"), or **acts on a structural finding from a 🏛 architecture audit** (e.g. splitting a god-module, breaking a dependency cycle) — the *why* of the restructure should outlive the review. SKIP — for trivial picks with no trade-off (e.g. picking a variable name).

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

AbudiHadi

AbudiHadi/coderv

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Log or Retrieve a Decision

ADRs preserve why you chose X over Y. Without them, the next session (or the next person) re-debates it from scratch.

Step 1 — Check the file exists

ls docs/DECISIONS.md 2>/dev/null

If missing: create it with this template:

# Decision Log (ADRs)

> Every architectural / library / pattern / scope decision that will be second-guessed later.
> Newest at top. Never delete — if a decision is reversed, add a new ADR that supersedes the old one.

---

Step 2 — Read the argument

Argument = `list`

Read docs/DECISIONS.md. Extract every ## ADR-NNN: heading. Output:

ADR log (N total)

Accepted:
- ADR-001: <title> — YYYY-MM-DD
- ADR-003: <title> — YYYY-MM-DD

Superseded:
- ADR-002: <title> — superseded by ADR-005

Argument = a topic (e.g. "auth", "database")

Grep docs/DECISIONS.md for the term. Return matching ADRs with their Decision + Consequences summarised.

Argument = a title (log a new one)

Find the highest existing ADR number. New one is ADR-(N+1).
Ask the user — one terse prompt:

📋 Logging **ADR-NNN: <your title>** at the top of `docs/DECISIONS.md`.

**Tell me, in your own words:**
- 🎯 **Problem:** what forced this?
- ✅ **What you picked:** one sentence.
- 🤔 **What you considered:** 2+ alternatives + why they lost.
- ⚖️ **Trade-off:** what does this cost? what would reverse it?
- 🙋 **Decider(s):**

*Stuck on the format? Say "example" and I'll show one.*

Write the ADR at the top of docs/DECISIONS.md (newest first):

## ADR-NNN: <Title>

**Date:** YYYY-MM-DD
**Status:** accepted
**Decider(s):** <name(s)>

### Context
<from user>

### Decision
<from user>

### Alternatives considered
- **<Option A>** (chosen) — <reason>
- **<Option B>** — <why rejected>
- **<Option C>** — <why rejected>

### Consequences
- Positive: <…>
- Trade-off: <…>
- Revisit if: <condition that would make us reconsider>

If this decision supersedes an older one:
- Add "Supersedes ADR-MMM" to the new ADR.
- Edit the old ADR: change Status: accepted → Status: superseded by ADR-NNN (YYYY-MM-DD).
- Never delete the old ADR.

Output

📋 **ADR-NNN: <title>** logged at top of `docs/DECISIONS.md` (status: accepted).

👉 **My recommendation:** <one line — usually "keep going" unless this decision blocks something>.

このリポジトリの他の Skills

同じリポジトリ

before

AbudiHadi/coderv

Pre-code checklist that reads the relevant docs, greps prior art, checks past decisions, states a plan, and waits for approval. Runs automatically before any non-trivial code change so the dev never has to remember what to read. Skips itself for tiny / exploratory edits. This is the core discipline skill — it prevents Claude from diving in without context. TRIGGER — suggest this skill (even without /before prefix) when the user asks to: "add <feature>", "build <feature>", "implement <X>", "refactor <X>", "rewrite <X>", "rename <X>", "integrate <service>", "migrate <X>", "port <X>", "extract <X>", "set up <X>", "wire up <X>". Also when they say "take your time", "think about this", or touch a module for the first time this session. SKIP — when the user says "quick fix", "just", "small change", "tiny edit", "typo", when they're undoing something from earlier in this same session, or when the task is documentation-only.

2026-07-247

coderv

AbudiHadi/coderv

The front door. One command for any request — "build X", "there's a bug in Y", "wrapping up", or just bare `coderv` with no words — it discovers what to do, classifies the request, checks the project's state (docs freshness, unfinished handoffs, dirty git), assembles the right pipeline of toolkit skills (/lint → /before → work → verify → /ship → /session), shows it once, and runs the whole chain on a single yes. Bare `coderv` auto-scans and proposes the most likely next task; a confusing request triggers a read-only scout to find the real target before acting; code changes are always verified (the flow is driven and observed) before shipping. The user never has to remember which skill comes next. TRIGGER — suggest this skill (even without /coderv prefix) when the user starts a work request without naming any skill: "I'd like to build", "I want to add", "there's a bug", "something is broken", "can we change", "let's work on", "new feature", "fix this", "improve X" — especially at the start of a session or whe

2026-07-247

lint

AbudiHadi/coderv

Audit a project's docs for contradictions, stale claims, dead references, and rot — the health check that keeps CLAUDE.md + docs/ honest. Docs that lie are worse than no docs: agents and humans act on them. Run it every ~5 sessions, before a release, or whenever docs feel "off". TRIGGER — suggest this skill (even without /lint prefix) when the user says: "lint the docs", "audit the docs", "are the docs up to date?", "do the docs match the code?", "docs are lying", "doc rot", "check for contradictions", "is there a gap in the docs?", "stale docs", "clean up the docs", "docs health check", "verify the docs". SKIP — when the user wants to GENERATE fresh docs (that's /docify), edit one specific doc by hand, or is mid-task with uncommitted work (lint after shipping, not during).

2026-07-247

ship

AbudiHadi/coderv

Pre-commit checklist. Reads the diff, offers to update docs itself (not just ask you), validates citations in docs haven't gone stale, drafts a why-focused commit message. Runs before every commit that touches multiple files. TRIGGER — suggest this skill (even without /ship prefix) when the user says: "commit", "git commit", "commit this", "push it", "push this", "push up", "create a commit", "make a commit", "ready to ship", "I'm done", "all done", "wrap up this change", "finalize", "let's commit", "commit and push", "ready to merge", "draft commit message", "write commit message". SKIP — when the user is only asking about git status without intent to commit (e.g. "what changed?", "show me the diff").

2026-07-247

session

AbudiHadi/coderv

Write a session handoff note so the next session (you or a teammate) picks up cleanly — no more "what was I doing again?" on Monday morning. Use at end of session. Use `/session last` at the start of a session to read the previous handoff. TRIGGER (end-of-session) — suggest this skill (even without /session prefix) when the user says: "I'm done for today", "done for the day", "wrap up", "wrapping up", "see you tomorrow", "see you next week", "stopping here", "pausing here", "leaving it here", "continue later", "tomorrow-me", "taking a break", "lunch break", "end of day", "EOD". TRIGGER (start-of-session) — suggest `/session last` when the user says: "where did I leave off?", "what was I doing?", "pick up where I left off", "what's next?", "status?", "what was last?", "continue from yesterday", "remind me what we were doing". SKIP — in the middle of active work with no break in sight.

2026-07-207

docify

AbudiHadi/coderv

Generate a professional docs/ folder from an existing codebase. Scans the project, detects the stack, and writes CLAUDE.md + architecture.md + api.md + components.md + database.md + integrations.md + overview.md — all grounded in file+line citations so docs never lie. Preserves custom CLAUDE.md rules when it already exists. TRIGGER — suggest this skill (even without /docify prefix) when the user says the words "docs", "doc", "documentation", "readme", "README" — OR any of these phrases: "write docs", "write documentation", "create docs", "generate docs", "make docs", "make a doc", "make a full docs", "need docs", "no docs exist", "this project has no README", "document this project", "explain the codebase", "document what we have", "make docs for X", "I need docs", "our docs are outdated", "fresh docs", "bootstrap docs", "docs are missing", "docs outdated". SKIP — when the user wants to edit ONE specific existing doc file by hand ("fix a typo in api.md", "add a line to architecture.md"), OR when "docs" mean

2026-07-197

name	decision
description	Log an architectural decision (ADR) so the reasoning survives across sessions. Use right after you pick a library, a pattern, or a trade-off. Takes 30 seconds while it's fresh. Prevents "why did we do it this way?" re-debates months later. Also retrieves past decisions with `/decision list` or `/decision <topic>`. TRIGGER — suggest this skill (even without /decision prefix) when the user: picks between options ("X or Y?", "should we use A vs B", "choosing between"), asks "why did we pick X?", "why are we using Y?", "why did we choose", wants to document a trade-off, mentions "architectural decision", "ADR", "tech choice", accepts a trade-off ("going with X despite the downside of Y"), or acts on a structural finding from a 🏛 architecture audit (e.g. splitting a god-module, breaking a dependency cycle) — the why of the restructure should outlive the review. SKIP — for trivial picks with no trade-off (e.g. picking a variable name).
user-invocable	true
argument-hint	[title to log new ADR \| 'list' \| topic to search]

Log or Retrieve a Decision

ADRs preserve why you chose X over Y. Without them, the next session (or the next person) re-debates it from scratch.

Step 1 — Check the file exists

ls docs/DECISIONS.md 2>/dev/null

If missing: create it with this template:

# Decision Log (ADRs)

> Every architectural / library / pattern / scope decision that will be second-guessed later.
> Newest at top. Never delete — if a decision is reversed, add a new ADR that supersedes the old one.

---

Step 2 — Read the argument

Argument = `list`

Read docs/DECISIONS.md. Extract every ## ADR-NNN: heading. Output:

ADR log (N total)

Accepted:
- ADR-001: <title> — YYYY-MM-DD
- ADR-003: <title> — YYYY-MM-DD

Superseded:
- ADR-002: <title> — superseded by ADR-005

Argument = a topic (e.g. "auth", "database")

Grep docs/DECISIONS.md for the term. Return matching ADRs with their Decision + Consequences summarised.

Argument = a title (log a new one)

Find the highest existing ADR number. New one is ADR-(N+1).
Ask the user — one terse prompt:

📋 Logging **ADR-NNN: <your title>** at the top of `docs/DECISIONS.md`.

**Tell me, in your own words:**
- 🎯 **Problem:** what forced this?
- ✅ **What you picked:** one sentence.
- 🤔 **What you considered:** 2+ alternatives + why they lost.
- ⚖️ **Trade-off:** what does this cost? what would reverse it?
- 🙋 **Decider(s):**

*Stuck on the format? Say "example" and I'll show one.*

Write the ADR at the top of docs/DECISIONS.md (newest first):

## ADR-NNN: <Title>

**Date:** YYYY-MM-DD
**Status:** accepted
**Decider(s):** <name(s)>

### Context
<from user>

### Decision
<from user>

### Alternatives considered
- **<Option A>** (chosen) — <reason>
- **<Option B>** — <why rejected>
- **<Option C>** — <why rejected>

### Consequences
- Positive: <…>
- Trade-off: <…>
- Revisit if: <condition that would make us reconsider>

If this decision supersedes an older one:
- Add "Supersedes ADR-MMM" to the new ADR.
- Edit the old ADR: change Status: accepted → Status: superseded by ADR-NNN (YYYY-MM-DD).
- Never delete the old ADR.

Output

📋 **ADR-NNN: <title>** logged at top of `docs/DECISIONS.md` (status: accepted).

👉 **My recommendation:** <one line — usually "keep going" unless this decision blocks something>.

decision

Log or Retrieve a Decision

Step 1 — Check the file exists

Step 2 — Read the argument

Argument = list

Argument = a topic (e.g. "auth", "database")

Argument = a title (log a new one)

Output

このリポジトリの他の Skills

このリポジトリの他の Skills

Log or Retrieve a Decision

Step 1 — Check the file exists

Step 2 — Read the argument

Argument = list

Argument = a topic (e.g. "auth", "database")

Argument = a title (log a new one)

Output

Argument = `list`

Argument = `list`