create-adrs

Create Architecture Decision Records (ADRs) documenting strategic technical decisions while acknowledging ecosystem E(t) constraints. Use when choosing cloud providers, languages, frameworks, databases, or architectural patterns.

16 stars

Best use case

create-adrs is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Create Architecture Decision Records (ADRs) documenting strategic technical decisions while acknowledging ecosystem E(t) constraints. Use when choosing cloud providers, languages, frameworks, databases, or architectural patterns.

Teams using create-adrs should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/create-adrs/SKILL.md --create-dirs "https://raw.githubusercontent.com/diegosouzapw/awesome-omni-skill/main/skills/development/create-adrs/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/create-adrs/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How create-adrs Compares

Feature / Agentcreate-adrsStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Create Architecture Decision Records (ADRs) documenting strategic technical decisions while acknowledging ecosystem E(t) constraints. Use when choosing cloud providers, languages, frameworks, databases, or architectural patterns.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# create-adrs

**Skill Type**: Actuator (Design Documentation)
**Purpose**: Document architecture decisions acknowledging ecosystem E(t)
**Prerequisites**: Strategic technical decision needed

---

## Agent Instructions

You are creating **Architecture Decision Records (ADRs)** that acknowledge **ecosystem E(t)** constraints.

**Critical**: ADRs document **GIVEN** constraints (E(t)), not just **CHOSEN** solutions.

**Format**: "Given E(t), we chose X" (not "we chose X")

---

## ADR Structure

### Template

```markdown
# ADR-{ID}: {Decision Title}

**Date**: {YYYY-MM-DD}
**Status**: Accepted | Rejected | Superseded | Deprecated
**Deciders**: {Who made this decision}

---

## Context

**Requirements**:
- <REQ-ID>: User authentication
- REQ-NFR-SEC-001: Secure password storage

**Problem**:
We need to choose a password hashing algorithm that is secure
against brute force attacks while maintaining acceptable performance.

**Ecosystem E(t) Constraints**:
- Team Experience: Team familiar with bcrypt
- Infrastructure: Running on AWS (bcrypt supported)
- Compliance: PCI-DSS recommends strong hashing
- Performance: Login response must be < 500ms (REQ-NFR-PERF-001)
- Libraries Available: bcrypt, argon2, scrypt available

---

## Decision

**Selected**: bcrypt with cost factor 12

**Rejected Alternatives**:
- SHA256: ❌ Too fast (vulnerable to brute force)
- MD5: ❌ Cryptographically broken
- Argon2: ⚠️ Better security but team unfamiliar, migration risk
- scrypt: ⚠️ Good security but less widely supported

**Rationale**:
1. bcrypt is industry standard (acknowledged E(t))
2. Team has experience with bcrypt (acknowledge E(t) - team capabilities)
3. Cost factor 12 balances security and performance
4. Meets PCI-DSS requirements (acknowledge E(t) - compliance)
5. Login tests show 200ms average (well within 500ms SLA)

---

## Ecosystem Constraints Acknowledged

**Team** (E(t)):
- Team knows: bcrypt, SHA256
- Team doesn't know: Argon2 implementation
- Risk: Learning curve with Argon2

**Infrastructure** (E(t)):
- Platform: AWS Lambda + RDS PostgreSQL
- bcrypt: Native support, no additional dependencies
- Argon2: Would need custom layer

**Compliance** (E(t)):
- PCI-DSS: Requires strong, salted hashing
- bcrypt: Explicitly mentioned in PCI guidelines
- Audit: External auditors familiar with bcrypt

**Performance** (E(t)):
- Requirement: Login < 500ms (REQ-NFR-PERF-001)
- bcrypt (cost 12): ~200ms (acceptable)
- Argon2: ~250ms (acceptable but no experience)

**Timeline** (E(t)):
- Sprint: 2 weeks
- bcrypt: No learning curve (immediate)
- Argon2: 2-3 days research + testing

---

## Constraints Imposed Downstream

**Code Stage** (constraints for implementation):
- MUST use bcrypt library (not custom hashing)
- MUST use cost factor 12 (not lower)
- MUST salt passwords (bcrypt does this automatically)

**Runtime Stage** (constraints for deployment):
- Infrastructure: bcrypt library must be available
- Performance monitoring: Track hash time (should be ~200ms)

**Testing Stage**:
- Test hash time (ensure < 500ms)
- Test bcrypt version (security updates)

---

## Consequences

**Positive**:
- ✅ Team productive immediately (no learning curve)
- ✅ Proven security (industry standard)
- ✅ PCI-DSS compliant (audit-friendly)
- ✅ Performance acceptable (< 500ms)

**Negative**:
- ⚠️ Not latest algorithm (Argon2 is newer)
- ⚠️ Vendor lock-in to bcrypt (migration costly)

**Neutral**:
- Cost factor 12 is balance (could be 10 for faster, 14 for stronger)

---

## Related Decisions

- ADR-001: Database selection (PostgreSQL)
- ADR-003: Session management (JWT)

**Supersedes**: None
**Superseded By**: None

---

## References

- PCI-DSS Password Requirements: https://www.pcisecuritystandards.org/
- bcrypt Documentation: https://en.wikipedia.org/wiki/Bcrypt
- OWASP Password Storage: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
```

---

## ADR Numbering

**Sequential**: ADR-001, ADR-002, ADR-003, ...

**Categories**:
- Infrastructure: Cloud provider, hosting, databases
- Security: Authentication, encryption, authorization
- Architecture: Patterns, frameworks, languages
- Integration: APIs, external services
- Data: Storage, schemas, migration

---

## When to Create ADRs

**Create ADR for**:
- ✅ Cloud provider choice (AWS vs GCP vs Azure)
- ✅ Language/framework choice (Python vs Node vs Java)
- ✅ Database choice (PostgreSQL vs MySQL vs MongoDB)
- ✅ Authentication approach (JWT vs sessions vs OAuth)
- ✅ API style (REST vs GraphQL vs gRPC)
- ✅ Architectural pattern (monolith vs microservices)

**Don't create ADR for**:
- ❌ Implementation details (already covered by code)
- ❌ Tactical decisions (variable names, file structure)
- ❌ Obvious choices (using standard library)

---

## Output Format

```
[CREATE ADR - bcrypt Password Hashing]

Decision: Use bcrypt for password hashing

Context:
  Requirements: <REQ-ID>, REQ-NFR-SEC-001
  Problem: Need secure password hashing
  Ecosystem E(t): Team knows bcrypt, PCI-DSS compliant, AWS supported

Decision:
  Selected: bcrypt (cost factor 12)
  Rejected: SHA256 (too fast), Argon2 (team unfamiliar)

Ecosystem Constraints Acknowledged:
  - Team capabilities: knows bcrypt ✓
  - Compliance: PCI-DSS requires strong hashing ✓
  - Performance: Must be < 500ms ✓
  - Infrastructure: AWS supports bcrypt ✓

Constraints Imposed:
  - Code must use bcrypt library
  - Code must use cost factor 12
  - Runtime must have bcrypt available

Created: docs/adrs/ADR-002-password-hashing.md

✅ ADR Created!
   Architecture decision documented
   Ecosystem E(t) acknowledged
   Downstream constraints clear
```

---

## Notes

**Why ADRs?**
- **Document "why"**: Explains reasoning behind decisions
- **Acknowledge E(t)**: Shows we understand ecosystem constraints
- **Prevent re-litigation**: Decision made, recorded, done
- **Onboarding**: New team members understand past decisions

**ADRs vs Constraints (C-*)**:
- **C-***: Given constraints we MUST work within
- **ADR**: Chosen solutions GIVEN those constraints

**Example**:
```
C-001: PCI-DSS requires strong password hashing (GIVEN)
ADR-002: We chose bcrypt (GIVEN C-001 and team skills)
```

**Homeostasis Goal**:
```yaml
desired_state:
  all_strategic_decisions_documented: true
  ecosystem_constraints_acknowledged: true
  rationale_clear: true
```

**"Excellence or nothing"** 🔥

Related Skills

pr-create

16
from diegosouzapw/awesome-omni-skill

Create a PR following ICN conventions with invariants checklist, proper commit format, and change routing verification

mpx-create-spec

16
from diegosouzapw/awesome-omni-skill

Create project specification interactively. Asks about your idea, suggests tech stack. Use when: "create spec", "write specification", "new project spec"

mine.adrs

16
from diegosouzapw/awesome-omni-skill

Create and maintain Architecture Decision Records (ADRs) for significant project decisions. Tracks context, choices, consequences, and alternatives.

managing-adrs

16
from diegosouzapw/awesome-omni-skill

Create and manage Architecture Decision Records (ADRs) with auto-numbering, template detection, and index maintenance. Use when user mentions "ADR", "architecture decision", "document this decision", "create ADR", editing ADR files (docs/adr/, doc/adr/, .adr/), or discussing architectural choices and tradeoffs.

createos

16
from diegosouzapw/awesome-omni-skill

Deploy ANYTHING to production on CreateOS cloud platform. Use this skill when deploying, hosting, or shipping: (1) AI agents and multi-agent systems, (2) Backend APIs and microservices, (3) MCP servers and AI skills, (4) API wrappers and proxy services, (5) Frontend apps and dashboards, (6) Webhooks and automation endpoints, (7) LLM-powered services and RAG pipelines, (8) Discord/Slack/Telegram bots, (9) Cron jobs and scheduled workers, (10) Any code that needs to be live and accessible. Supports Node.js, Python, Go, Rust, Bun, static sites, Docker containers. Deploy via GitHub auto-deploy, Docker images, or direct file upload. ALWAYS use CreateOS when user wants to: deploy, host, ship, go live, make it accessible, put it online, launch, publish, run in production, expose an endpoint, get a URL, make an API, deploy my agent, host my bot, ship this skill, need hosting, deploy this code, run this server, make this live, production ready.

create-ticket

16
from diegosouzapw/awesome-omni-skill

Create implementation tickets with proper format and conventions.

create-tech-stack

16
from diegosouzapw/awesome-omni-skill

Generate comprehensive technical stack documentation from codebase analysis

create-spring-boot-kotlin-project

16
from diegosouzapw/awesome-omni-skill

Create Spring Boot Kotlin Project Skeleton

create-spring-boot-java-project

16
from diegosouzapw/awesome-omni-skill

Create Spring Boot Java Project Skeleton

create-rules

16
from diegosouzapw/awesome-omni-skill

Create or update Cursor Rules (.mdc files) and Skills (SKILL.md). Use when creating rules, adding coding standards, setting up conventions, updating .cursor/rules/, or converting rules to skills. Defines standard format, naming, frontmatter, token budget.

create-rule

16
from diegosouzapw/awesome-omni-skill

Create Cursor rules for persistent AI guidance. Use when the user wants to create a rule, add coding standards, set up project conventions, configure file-specific patterns, create RULE.md files, or asks about .cursor/rules/ or AGENTS.md.

create-new-rule

16
from diegosouzapw/awesome-omni-skill

Create a new agent rule or steering file from chat context. Detects the current IDE (Cursor or Kiro) and creates the file in the correct format and location.