Skill

adr-plan

Analyzes tasks, explores codebases with git tools, and generates Architecture Decision Records (ADRs) with ordered implementation steps. For planning non-trivial changes.

Git

Markdown

documentation

git-workflow

Install

npx claudepluginhub nikiforovall/claude-code-rules --plugin handbook-team-stack

Tool Access

This skill is limited to using the following tools:

AgentAskUserQuestionBash(npx adr *)Bash(git diff *)Bash(git log *)Bash(git status *)Bash(ls *)Bash(cat *)ReadGrepGlob

Preview

Analyze a task, explore the codebase, and produce an ADR with concrete implementation steps.

SKILL.md

Similar Skills

cache-components

Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.

cache-components

139.1k

claude-opus-4-5-migration

2 files

Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.

claude-opus-4-5-migration

83.2k

claude-code-plugin-release

1 file

Automates semantic versioning and release workflow for Claude Code plugins: bumps versions in package.json, marketplace.json, plugin.json; verifies builds; creates git tags, GitHub releases, changelogs.

claude-mem

64.7k

Stats

Parent Repo Stars111

Parent Repo Forks18

Last CommitMar 30, 2026

Actions

View Source View Plugin View on GitHub View README

ADR Plan: Task Analysis → Architecture Decision Record

Analyze a task, explore the codebase, and produce an ADR with concrete implementation steps.

Phase 1: Analyze

Read the task description, active plan, or task list
Explore affected areas of the codebase — do it concurrently for independent modules
Map blast radius — search for consumers of functions/types/routes being changed
Identify alternatives worth considering (at least 2)

Do this silently.

Phase 2: Detect ADR Setup

Check if the project has an ADR directory:

ls docs/adr/ || ls adr/ || ls doc/adr/

Found → use existing directory, detect next number from existing files
Not found → run npx adr init en, then proceed

Phase 3: Produce ADR Content

Write the ADR using npx adr new "<title>", then edit the generated file with the following structure:

# ADR-NNNN: [Title]

## Status
Proposed

## Context
[What problem are we solving? What constraints exist?]

## Decision
[What we chose and why]

## Alternatives Considered
| Option | Pros | Cons |
|--------|------|------|
| ... | ... | ... |

## Implementation Steps

### Step 1: [Description]
- **Files:** [files to create/modify]
- **Depends on:** [previous step or "none"]
- **Done when:** [concrete acceptance criteria]

### Step 2: [Description]
...

## Consequences
- [Positive and negative outcomes, tradeoffs accepted]

Guidelines

Steps are ordered by dependency — each step lists what it depends on
Steps are parallelizable when independent — note which steps can run concurrently
Each step has concrete "done when" criteria — no vague outcomes
Alternatives table is honest — include the option you chose and why others lost
Keep it short. 1-2 pages max. No padding.

Phase 4: Present to User

Show the ADR content and the file path. The user may:

Approve → ADR stays as-is
Adjust → edit and re-present
Cancel → delete the file

Important

The ADR is a planning artifact, not documentation for posterity
Steps should map naturally to work units (a team member could own one or more steps)
If the task is too simple for an ADR (single file, obvious fix), say so and skip
Do not write implementation code — this is planning only