achreftlili/architect/adr
architect/adr/SKILL.md
--- name: adr description: Use this skill whenever the architect subagent needs to document an architecture decision, record a technical choice, write an ADR (Architecture Decision Record), or capture why a specific technology, pattern, or approach was selected. Triggers on: "document this decision", "write an ADR", "record why we chose", "architecture decision", "decision record", "capture this trade-off". Always use this skill to produce ADRs — it ensures they are complete, traceable, and usef
$ install --global
skillsauthnpx skillsauth add achreftlili/deep-dev-skills architect/adrInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 25, 2026, 2:48 PM9.9s1 file scanned
SKILL.md
- name:
- adr
- description:
- Use this skill whenever the architect subagent needs to document an architecture decision, record a technical choice, write an ADR (Architecture Decision Record), or capture why a specific technology, pattern, or approach was selected. Triggers on: "document this decision", "write an ADR", "record why we chose", "architecture decision", "decision record", "capture this trade-off". Always use this skill to produce ADRs — it ensures they are complete, traceable, and useful for future engineers.
- category:
- architect
- agent-type:
- architect
ADR — Architecture Decision Record Skill
Purpose
Produce clear, durable records of architecture decisions so future engineers understand not just what was decided, but why, and what was ruled out.
ADR Output Template
Always produce ADRs in this exact format:
ADR-[NUMBER]: [Short Title — max 8 words]
Date: YYYY-MM-DD
Status: Proposed | Accepted | Deprecated | Superseded by ADR-XXX
Deciders: [roles or team names, not personal names]
Tags: [e.g., database, auth, messaging, infra]
Context
What is the situation that forces this decision? Describe:
- The problem or requirement driving the decision
- Current state of the system (if applicable)
- Constraints: technical, business, time, budget
- Any external factors (compliance, team skills, existing contracts)
Write this section so that someone with no prior context understands why a decision was needed.
Decision
State the decision in one clear sentence:
We will [do X] using [Y] because [core reason].
Then elaborate in 2–3 paragraphs if needed.
Alternatives Considered
For each rejected option:
Option: [Name]
- Description: brief explanation
- Pros: what it does well
- Cons: why it was ruled out
- Verdict: rejected because [specific reason]
(Include at least 2 alternatives. If no alternatives were seriously considered, state why.)
Consequences
Positive
- List concrete benefits this decision enables
Negative / Trade-offs
- List concrete costs, limitations, or risks introduced
Neutral / Follow-up Required
- What other decisions does this unlock or constrain?
- What needs to be revisited in [timeframe]?
Validation Criteria
How will we know this decision was correct? Define measurable signals:
- [ ] Criterion 1 (e.g., "p99 latency < 100ms under 10k RPS")
- [ ] Criterion 2
References
- Links to relevant docs, benchmarks, or prior ADRs
ADR Numbering & Lifecycle
- Number ADRs sequentially per project: ADR-001, ADR-002, etc.
- Never delete an ADR — mark it
DeprecatedorSuperseded - When superseding, link both ADRs to each other
- Store in
/docs/adr/in the project repository
Quality Checklist
Before finalizing an ADR, verify:
- [ ] Context explains the why, not just the what
- [ ] At least 2 real alternatives are documented
- [ ] Trade-offs are honest — no decision is purely positive
- [ ] Validation criteria are measurable
- [ ] Status is set correctly
Related Skills
achreftlili/vitest-testing-skill
testing
VerifiedTrustedCommunity
Set up Vitest 2.x with TypeScript for unit and component testing using test/describe/it, vi.fn/vi.mock/vi.spyOn, component testing with Testing Library, coverage (v8/istanbul), workspace config, and snapshot testing.
1SKILL.mdUpdated Apr 25, 2026
achreftlili/pytest-testing-skill
testing
VerifiedTrustedCommunity
Set up pytest 8.x with Python for unit and integration testing using fixtures (scope, autouse, parametrize), async tests (pytest-asyncio), mocking (unittest.mock, pytest-mock), coverage (pytest-cov), conftest.py patterns, and markers.
1SKILL.mdUpdated Apr 25, 2026
achreftlili/playwright-testing-skill
testing
VerifiedTrustedCommunity
Set up Playwright 1.49+ with TypeScript for E2E testing using page object model, fixtures, test.describe/test blocks, assertions, selectors, network mocking, CI configuration, and trace viewer.
1SKILL.mdUpdated Apr 25, 2026
achreftlili/jest-testing-skill
testing
VerifiedTrustedCommunity
Set up Jest 30+ with TypeScript for unit tests, integration tests, mocking (jest.fn, jest.mock, jest.spyOn), coverage configuration, custom matchers, snapshot testing, and setup/teardown patterns.
1SKILL.mdUpdated Apr 25, 2026