new-adr
Scaffold a new Architecture Decision Record, auto-numbered from existing ADRs, with context pre-filled from recent git history and CHANGELOG.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Scaffold a new Architecture Decision Record, auto-numbered from existing ADRs, with context pre-filled from recent git history and CHANGELOG.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | new-adr |
| description | Scaffold a new Architecture Decision Record, auto-numbered from existing ADRs, with context pre-filled from recent git history and CHANGELOG. |
| argument-hint | [decision-name e.g. use-singletons-for-services] |
Scaffold a numbered ADR at docs/adrs/ with context pre-filled from the current session's work.
Decision name: $ARGUMENTS (required — becomes the slug and title)
List docs/adrs/ and find the highest-numbered ADR file:
ls docs/adrs/ | grep -E '^[0-9]+-' | sort -n | tail -5
Extract the highest number (e.g., 009-self-documenting-code.md → 9). Next ADR = 9 + 1 = 010.
Zero-pad to 3 digits: 010, 011, etc.
Run these to pre-fill the Context section:
# Recent decisions/changes for context
git log --oneline -10
# Current session's work
git diff --name-only HEAD 2>/dev/null | head -20
# Latest CHANGELOG entry (first 30 lines)
head -30 CHANGELOG.md
Read docs/adrs/000-template.md to verify the exact heading/formatting style. Do NOT guess — DOTS ADRs use inline bold fields (**Status**:, **Date**:) not separate headings.
Write to docs/adrs/[NNN]-[decision-name].md using this exact format (matching existing ADRs):
# ADR-[NNN]: [Human-Readable Title from $ARGUMENTS]
**Status**: Proposed
**Date**: [today's date YYYY-MM-DD]
**Priority**: Standard
## Context
[2-4 sentences describing the problem or situation that motivated this decision.
Pre-fill with context from: git log themes, CHANGELOG entry, changed files.]
## Decision
[TBD — describe the chosen approach in 1-3 sentences once decided]
## Consequences
### Positive
- [TBD]
### Negative
- [TBD]
### Neutral
- [TBD]
## Alternatives Considered
### Alternative 1: [Name]
- **Pros**:
- **Cons**:
- **Why rejected**:
## Examples
### Good (Follows This ADR)
```csharp
// Example of code that follows this ADR
// Example of code that violates this ADR
[How to apply this ADR to existing code, if applicable]
## Step 5: Report
Print: `Created docs/adrs/[NNN]-[decision-name].md`
Remind the user to:
1. Fill in the Decision and Consequences sections
2. Add code examples (Good/Bad)
3. Update `docs/adrs/README.md` with the new entry
4. Set `**Priority**: Mandatory` if this is a NEVER-VIOLATE rule
Author a culture's armor items and swap troop equipment rosters via the generator + validation pipeline. Use when adding/revamping armor. Enforces the canonical-folder + cover-attribute rules.
Give DOTS lords lore-driven skill values and traits via the DOTS SkillSet system. Use when a canonical lord has wrong stats or a culture roster needs a balance pass.
Author or revamp a DOTS culture's armor set, troop tree, and recruitment wiring end-to-end. Use for new cultures or troop-tree revamps. Follows docs/ai-includes/new-culture-authoring.md.
Use when reviewing an external repo or article to adopt practices into DOTS — security-vet first, map novel vs duplicative, port (never install), review, commit your changes.
Structured 4-phase self-debug for failing agent runs (looping, drifting, burning tokens). Capture, diagnose, contained recovery, report. Complements /investigate (which is for code bugs); this skill is for harness/agent failures.
Incrementally fix dotnet build errors with minimal diffs, one error at a time