.agents/skills/adr/SKILL.md
Tracks Architecture Decision Records (ADRs) in docs/adrs/. Creates, lists, and updates ADRs following project conventions. TRIGGER when: user wants to record, review, or update an architectural decision.
npx skillsauth add kagenti/humr adrInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Manage Architecture Decision Records in docs/adrs/. Interpret $ARGUMENTS as natural language.
Ask the user for any missing information. You need at minimum: title, context, decision, and owner (@github-username).
If the decision is made → create docs/adrs/NNN-short-title.md with status Accepted.
If the decision is open → create docs/adrs/DRAFT-short-title.md with status Proposed.
Assign the next number by reading docs/adrs/index.md. Always update the index after creating a file.
Valid status transitions: Accepted, Deprecated, Superseded by ADR-NNN.
When promoting a Draft to Accepted: rename DRAFT-title.md → NNN-title.md and move the row from Drafts to Accepted in the index.
NNN-short-title.md — numbered, zero-padded to 3 digits, never reusedDRAFT-short-title.md — no number until accepteddocs/adrs/index.md — always keep in sync# ADR-NNN: Title
**Date:** YYYY-MM-DD
**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-NNN
**Owner:** @github-username
## Context
What is the issue motivating this decision?
## Decision
What we decided.
## Alternatives Considered
What else was evaluated and why rejected.
## Consequences
What becomes easier or more difficult.
development
Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue after user approval. Use when user wants to write a PRD, create a product requirements document, or plan a new feature. Always present the PRD for user approval before submitting.
testing
Upgrade a previously bootstrapped or adopted project when the architecture evolves. Diffs the current architecture rules against the project's last locked review, identifies new or changed rules, and proposes incremental changes. Triggers on phrases like "upgrade my project", "sync with latest architecture", "update to new rules", "upgrade tseng", or "architecture changed, update my project". Also invocable via the /tseng:upgrade slash command.
development
Spec out a feature or change with full knowledge of the opinionated TypeScript architecture and the project's adoption state. Conducts a thorough discovery interview to understand domain concerns, bounded contexts, and application services, then produces a high-level architectural specification — never concrete implementation details. Triggers on phrases like "spec this feature", "design this change", "architect this", "help me spec", "what modules do I need", or "think through this feature". Also invocable via the /tseng:spec slash command.
development
Review an existing TypeScript project against the opinionated architecture rules. Use when the user asks to review, audit, check, or validate their project's architecture. Triggers on phrases like "review my project", "check the architecture", "audit my code structure", "validate my project", or "does my project follow the rules". Also invocable via the /tseng:review slash command.