accountable-engineerin…
Use explicit human checkpoints for architecture, security, rollout, or operational decisions.
Record architecture decisions with ADRs — captures why, alternatives considered, and consequences
$ npx -y skills add jellydn/my-ai-tools --skill adr --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/adrContext preview
The summary Claude sees to decide when to auto-load this skill.
Record architecture decisions with ADRs — captures why, alternatives considered, and consequences
name: adr description: "Record architecture decisions with ADRs — captures why, alternatives considered, and consequences" license: MIT compatibility: cline, claude, opencode, amp, codex, gemini, cursor, pi hint: Use when managing architecture decisions, creating ADRs, or tracking architectural choices user-invocable: true metadata: audience: all workflow: documentation
Provides a unified interface for managing Architecture Decision Records.
`/adr <ACTION> [ARGUMENTS]`
Architecture Decision Records (ADRs) are short documents that capture important architectural decisions made during project development. They help teams:
Each ADR typically contains:
A template is available at `$SKILL_PATH/templates/adr-template.md`:
# [NUMBER]. [TITLE] Date: [DATE] ## Status [Proposed | Accepted | Deprecated | Superseded by [ADR-NUMBER]] ## Context [Describe the context and problem statement] ## Decision [Describe the decision and solution] ## Consequences ### Positive - [Positive outcome 1] - [Positive outcome 2] ### Negative - [Negative outcome 1] - [Risk or trade-off]
Common ADR locations to check:
/adr new "Use PostgreSQL for primary database"
/adr list
/adr search "database"
/adr view 5
Portable, source-controlled configuration for AI coding assistants. my-ai-tools installs one consistent set of agent guidelines, skills, commands, hooks, MCP servers, and tool settings across supported AI coding assistants.
Use explicit human checkpoints for architecture, security, rollout, or operational decisions.
Use when monitoring an open GitHub PR for CI failures, review feedback, mergeability, and safe retries or fixes.
Inspect history and architecture for hidden constraints before risky cross-cutting changes.
Build an interactive report or experiment when the user asks to explore model capabilities.
Audit a diff for structural maintainability and unnecessary complexity.
Review a branch, PR, or worktree diff for repository conventions and stated intent.