azcodr 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/skills/agentic-architect/SKILL.md +118 -0
- package/.agents/skills/agentic-architect/references/agents_md_template.md +59 -0
- package/.agents/skills/agentic-architect/references/refinement_workflow.md +32 -0
- package/.agents/skills/agentic-architect/references/skill_architecture_inquiry.md +63 -0
- package/.agents/skills/agentic-architect/references/skill_template.md +55 -0
- package/.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh +163 -0
- package/.agents/skills/clean-code-refactor/SKILL.md +91 -0
- package/.agents/skills/clean-code-refactor/references/clean_code_smells.md +27 -0
- package/.agents/skills/clean-code-refactor/references/design_patterns_ts.md +65 -0
- package/.agents/skills/compliance-audit/SKILL.md +120 -0
- package/.agents/skills/compliance-audit/references/owasp_top10_controls.md +16 -0
- package/.agents/skills/compliance-audit/references/soc2_iso_controls.md +28 -0
- package/.agents/skills/lets-build/SKILL.md +164 -0
- package/.agents/skills/lets-build/references/architecture_interview_matrix.md +188 -0
- package/.agents/skills/lets-build/references/hexagonal_bootstrap_scaffolds.md +113 -0
- package/.agents/skills/lets-build/references/project_readme_template.md +79 -0
- package/.agents/skills/lets-build/scripts/bootstrap_workspace.sh +68 -0
- package/.agents/skills/merge-ai/SKILL.md +90 -0
- package/.agents/skills/merge-ai/scripts/audit_divergence.sh +108 -0
- package/.agents/skills/merge-ai/scripts/resolve_repo.sh +177 -0
- package/.agents/skills/product-analyst/SKILL.md +143 -0
- package/.agents/skills/product-analyst/references/backlog_ordering_techniques.md +107 -0
- package/.agents/skills/product-analyst/references/gherkin_patterns.md +46 -0
- package/.agents/skills/product-analyst/references/invest_checklist.md +38 -0
- package/.agents/skills/product-analyst/references/okr_alignment_guide.md +76 -0
- package/.agents/skills/product-analyst/references/smart_tasks.md +59 -0
- package/.agents/skills/relentless-questioner/SKILL.md +120 -0
- package/.agents/skills/relentless-questioner/references/adaptive_question_trees.md +84 -0
- package/.gitignore +20 -0
- package/AGENTS.md +119 -0
- package/LICENSE +21 -0
- package/README.md +184 -0
- package/bin/azcodr.js +151 -0
- package/docs/knowledge/dos_and_donts.md +540 -0
- package/docs/knowledge/issue_log.md +25 -0
- package/docs/knowledge/knowledge_graph.md +188 -0
- package/docs/knowledge/lessons_learned.md +107 -0
- package/docs/knowledge/ubiquitous_language.md +23 -0
- package/docs/rules/accessibility.md +31 -0
- package/docs/rules/advanced_api_patterns.md +104 -0
- package/docs/rules/agentic_configuration.md +168 -0
- package/docs/rules/api_versioning.md +128 -0
- package/docs/rules/application_security.md +23 -0
- package/docs/rules/architecture_decision_records.md +42 -0
- package/docs/rules/authentication.md +76 -0
- package/docs/rules/authorization.md +75 -0
- package/docs/rules/caching.md +52 -0
- package/docs/rules/clean_code.md +25 -0
- package/docs/rules/cloud_native.md +43 -0
- package/docs/rules/compliance.md +25 -0
- package/docs/rules/container_infrastructure.md +32 -0
- package/docs/rules/continuous_deployment.md +24 -0
- package/docs/rules/continuous_integration.md +20 -0
- package/docs/rules/continuous_learning.md +29 -0
- package/docs/rules/database_integrity.md +88 -0
- package/docs/rules/database_migrations.md +41 -0
- package/docs/rules/database_operations.md +27 -0
- package/docs/rules/database_performance.md +44 -0
- package/docs/rules/database_transactions.md +81 -0
- package/docs/rules/design_patterns.md +40 -0
- package/docs/rules/devsecops.md +33 -0
- package/docs/rules/domain_driven_design.md +84 -0
- package/docs/rules/domain_expertise.md +42 -0
- package/docs/rules/error_handling.md +39 -0
- package/docs/rules/feature_flags.md +42 -0
- package/docs/rules/gof_design_patterns_reference.md +70 -0
- package/docs/rules/multitenancy_isolation.md +86 -0
- package/docs/rules/product_ownership.md +150 -0
- package/docs/rules/project_management.md +66 -0
- package/docs/rules/react.md +88 -0
- package/docs/rules/relentless_questioning.md +48 -0
- package/docs/rules/requirements_engineering.md +113 -0
- package/docs/rules/rest_api_conventions.md +62 -0
- package/docs/rules/server_driven_ui.md +71 -0
- package/docs/rules/tenant_dynamic_schemas.md +88 -0
- package/docs/rules/tenant_pluggable_logic.md +59 -0
- package/docs/rules/test_driven_development.md +106 -0
- package/docs/rules/test_isolation.md +26 -0
- package/docs/rules/transactional_email.md +20 -0
- package/docs/rules/typescript.md +55 -0
- package/docs/rules/ui_navigation.md +20 -0
- package/docs/rules/ui_ux_architecture.md +168 -0
- package/docs/rules/upstream_synchronization.md +66 -0
- package/docs/rules/workflow_state_machines.md +118 -0
- package/docs/rules/workspace_isolation.md +25 -0
- package/lib/index.js +5 -0
- package/lib/scaffold.js +177 -0
- package/memory.md +262 -0
- package/package.json +49 -0
|
@@ -0,0 +1,118 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: agentic-architect
|
|
3
|
+
description: Use when creating, modularizing, auditing, or updating agentic configuration files, including AGENTS.md, CLAUDE.md, rule documentation files, or skills under .agents/skills/ following the progressive disclosure architecture. Do not use for writing application business logic.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Agentic Architect Skill
|
|
7
|
+
|
|
8
|
+
> **Core Philosophy:** Eliminate context bloat and model degradation through progressive disclosure, lean entrypoints, strict skill front matter, automated symlink parity, and relentless questioning during skill architecture.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## 1. When to Use This Skill
|
|
13
|
+
- Auditing existing `AGENTS.md` or `CLAUDE.md` files for token bloat or giant bullet lists.
|
|
14
|
+
- Decoupling large domain sections (testing, database, auth, UI) into modular rule files.
|
|
15
|
+
- Authoring new specialized skills under `.agents/skills/` using relentless questioning.
|
|
16
|
+
- Establishing harness parity across different AI coding environments via symlinks.
|
|
17
|
+
- Implementing the continuous refinement loop to update skills based on AI mistakes.
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
## 2. Step-by-Step Execution Workflow
|
|
22
|
+
|
|
23
|
+
### Step 1: Relentless Skill Architecture Inquiry (Question Everything)
|
|
24
|
+
Before writing a single line of a skill or rule, execute the **7 Core Inquiry Branches**:
|
|
25
|
+
1. **Placement & Scope:** Does this belong in root `AGENTS.md` (all prompts), nested `AGENTS.md` (one package), a continuous rule in `docs/rules/`, or an on-demand skill in `.agents/skills/`?
|
|
26
|
+
2. **Trigger Boundaries:** What is the exact user intent? What is the explicit imperative trigger (`Use when...`) and the anti-triggers (`Do NOT use for...`)?
|
|
27
|
+
3. **Domain Ground Truth:** Have all generic textbook tutorials been purged? Is this grounded in verified codebase evidence?
|
|
28
|
+
4. **Gotchas & Anti-Patterns:** What exact mistakes has the AI repeatedly made in this domain that must be forbidden?
|
|
29
|
+
5. **Determinism vs. LLM:** Can brittle tasks be converted into deterministic scripts under `scripts/`?
|
|
30
|
+
6. **Progressive Bloat:** Is `SKILL.md` strictly under 500 lines, offloading deep manuals to `references/` and templates to `assets/`?
|
|
31
|
+
7. **Verification & Proof:** What structured response template and self-validation checklist will prove success?
|
|
32
|
+
*Rule:* If any branch is unanswered or ambiguous, **STOP and ask the user** (or inspect workspace files). Never fill gaps with assumptions.
|
|
33
|
+
|
|
34
|
+
### Step 2: Audit Existing Agent Configuration
|
|
35
|
+
Inspect current agent files and measure their token and line footprint:
|
|
36
|
+
- File length > 120–150 lines in root `AGENTS.md`.
|
|
37
|
+
- Giant bullet lists accumulated from past one-off bugs.
|
|
38
|
+
- Human onboarding guides (cloning instructions, dev machine setup).
|
|
39
|
+
- Framework-specific deep tutorials that only apply to a minority of tasks.
|
|
40
|
+
- Deep, fragile file paths that rot over time.
|
|
41
|
+
|
|
42
|
+
### Step 3: Decouple Domain Directives into Modular Rules
|
|
43
|
+
Extract continuous technical requirements into dedicated markdown files under `docs/rules/`:
|
|
44
|
+
- `docs/rules/clean_code.md` (Clean Code, Pragmatic Programmer, CQS, SLAP)
|
|
45
|
+
- `docs/rules/cloud_native.md` (12-Factor 2026, OpenTelemetry, API-first)
|
|
46
|
+
- `docs/rules/compliance.md` (SOC 2 Type II, ISO 27001, GDPR)
|
|
47
|
+
- `docs/rules/continuous_integration.md` (Shift-left pipelines, trunk-based CI)
|
|
48
|
+
- `docs/rules/requirements_engineering.md` (INVEST user stories, Gherkin criteria)
|
|
49
|
+
|
|
50
|
+
### Step 4: Streamline Root AGENTS.md
|
|
51
|
+
Refactor root `AGENTS.md` to be strictly bounded:
|
|
52
|
+
1. **Mission Statement & Open-Source Mandate:** 1–2 sentences defining project domain, purpose, and 100% open-source requirement.
|
|
53
|
+
2. **Runtime & Scripts:** Declared package manager (Node 24 / npm 11) and core scripts.
|
|
54
|
+
3. **Core Operating Framework:** Zero-Assumption Rule, Relentless Questioning Loop, 5-stage lifecycle, action boundaries.
|
|
55
|
+
4. **Progressive Disclosure Index:** Markdown table mapping each domain to its `docs/rules/*.md` file.
|
|
56
|
+
|
|
57
|
+
### Step 5: Author Specialized Skills via Progressive Disclosure
|
|
58
|
+
When a task is complex, multi-step, or specialized, encapsulate it into `.agents/skills/<skill-name>/`:
|
|
59
|
+
1. **Front Matter:**
|
|
60
|
+
- `name`: kebab-case identifier.
|
|
61
|
+
- `description`: < 1024 characters. Must start with imperative `Use when...` defining exact trigger conditions and when NOT to use.
|
|
62
|
+
2. **Body:**
|
|
63
|
+
- Keep under 500 lines.
|
|
64
|
+
- Ground in verified project experience, not general documentation the AI already knows.
|
|
65
|
+
- Include a mandatory **"Gotchas & What NOT to Do"** section.
|
|
66
|
+
- Provide structured output templates.
|
|
67
|
+
3. **Progressive Subdirectories:**
|
|
68
|
+
- `references/`: Reference docs loaded only on demand.
|
|
69
|
+
- `scripts/`: Deterministic code (bash/node) to prevent stochastic AI divergence.
|
|
70
|
+
- `assets/`: Static templates, lookup tables, and schemas.
|
|
71
|
+
|
|
72
|
+
### Step 6: Enforce Harness Parity via Symlinks
|
|
73
|
+
Prevent divergence between Claude Code, standard AGENTS.md, and legacy tooling:
|
|
74
|
+
```bash
|
|
75
|
+
ln -sf AGENTS.md CLAUDE.md
|
|
76
|
+
ln -sf AGENTS.md agents.md
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
### Step 7: Apply the Continuous Refinement Loop
|
|
80
|
+
1. Save the initial raw AI output draft.
|
|
81
|
+
2. Produce the human-adjusted gold standard version.
|
|
82
|
+
3. Diff the two versions to identify repeated flaws or stylistic divergence.
|
|
83
|
+
4. Update the skill's "What NOT to Do" section with concrete negative examples.
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## 3. Gotchas & What NOT to Do
|
|
88
|
+
|
|
89
|
+
- **DO NOT** guess what a skill should do. Run the Relentless Skill Architecture Inquiry first.
|
|
90
|
+
- **DO NOT** let root `AGENTS.md` exceed 120–150 lines. Every extra token degrades LLM attention.
|
|
91
|
+
- **DO NOT** write passive skill descriptions like `"Tanstack query documentation"`. Use `"Use when implementing Tanstack Query caches..."`.
|
|
92
|
+
- **DO NOT** include human "Getting Started" guides. Agents already have the workspace open.
|
|
93
|
+
- **DO NOT** hardcode individual file paths that change frequently. Reference architectural layers instead.
|
|
94
|
+
- **DO NOT** duplicate content across `CLAUDE.md` and `AGENTS.md`. Always use symbolic links.
|
|
95
|
+
- **DO NOT** add preemptive rules before the agent has actually made the mistake. Ground additions in real experience.
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
## 4. Verification Checklist
|
|
100
|
+
|
|
101
|
+
Before finalizing any agent configuration update, verify:
|
|
102
|
+
- [ ] Relentless Skill Architecture Inquiry completed for all 7 branches.
|
|
103
|
+
- [ ] Root `AGENTS.md` is under 120 lines and loads within minimal tokens.
|
|
104
|
+
- [ ] Specialized domain instructions are decoupled into `docs/rules/`.
|
|
105
|
+
- [ ] Progressive disclosure table in `AGENTS.md` contains valid, clickable markdown links.
|
|
106
|
+
- [ ] All skills have front matter with `name` and imperative `description` starting with `Use when...`.
|
|
107
|
+
- [ ] All skills are under 500 lines or offload sub-content to `references/`.
|
|
108
|
+
- [ ] Every skill contains a "Gotchas & What NOT to Do" section.
|
|
109
|
+
- [ ] Symlinks (`CLAUDE.md`, `agents.md`) resolve to `AGENTS.md`.
|
|
110
|
+
|
|
111
|
+
---
|
|
112
|
+
|
|
113
|
+
## 5. Subdirectories & Progressive Resources
|
|
114
|
+
- [references/skill_architecture_inquiry.md](./references/skill_architecture_inquiry.md): The interactive 7-branch relentless questioning guide for skills.
|
|
115
|
+
- [references/agents_md_template.md](./references/agents_md_template.md): Boilerplate template for lean root and nested `AGENTS.md` files.
|
|
116
|
+
- [references/skill_template.md](./references/skill_template.md): Boilerplate template for authoring production-grade `SKILL.md` files.
|
|
117
|
+
- [references/refinement_workflow.md](./references/refinement_workflow.md): Step-by-step guide for capturing AI draft diffs against human edits to update skills.
|
|
118
|
+
- [scripts/validate_agentic_configs.sh](./scripts/validate_agentic_configs.sh): Deterministic Bash script validating front matter, line ceilings, link health, and symlink parity.
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# Root & Nested AGENTS.md Template
|
|
2
|
+
|
|
3
|
+
Use this template when bootstrapping or restructuring an `AGENTS.md` file according to the progressive disclosure architecture.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
```markdown
|
|
8
|
+
# AGENTS.md
|
|
9
|
+
|
|
10
|
+
> **[Workspace / Package Name] Directives**
|
|
11
|
+
> **Rule Zero:** Assume nothing. Every action must be grounded in verified evidence from this workspace or direct instructions from the user.
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## 1. Project Overview & Environment
|
|
16
|
+
- **Purpose:** [1–2 sentences explaining what this project does and its core domain].
|
|
17
|
+
- **Runtime & Tools:** [e.g. Node 24 / npm 11, package manager, key global scripts].
|
|
18
|
+
- **High-Level Layout:**
|
|
19
|
+
- `apps/` — [High-level package boundaries].
|
|
20
|
+
- `packages/` — [Shared libraries/utilities].
|
|
21
|
+
- `docs/rules/` — [Modular progressive disclosure rules].
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## 2. Core Operating Framework
|
|
26
|
+
- **Ground Truth Only:** A statement is only true if proven by a file, command output, or direct user instruction.
|
|
27
|
+
- **Relentless Questioning Loop:** Before acting, answer:
|
|
28
|
+
1. What is current state?
|
|
29
|
+
2. What is exact goal?
|
|
30
|
+
3. What tools are available?
|
|
31
|
+
4. What could break?
|
|
32
|
+
5. How will we prove it works?
|
|
33
|
+
- **Execution Stages:** `DISCOVER` ➔ `INTERROGATE` ➔ `PLAN` ➔ `EXECUTE` ➔ `VERIFY`.
|
|
34
|
+
- **Action Boundaries:**
|
|
35
|
+
- **ALWAYS:** Read before editing; verify commands before running; verify results with evidence.
|
|
36
|
+
- **ASK FIRST:** Adding dependencies, deleting files, modifying DB schemas or existing tests.
|
|
37
|
+
- **NEVER:** Guess paths or flags; silently ignore errors; import external assumptions.
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## 3. Progressive Disclosure Rules
|
|
42
|
+
|
|
43
|
+
Read these specialized rule files on demand when performing relevant tasks:
|
|
44
|
+
|
|
45
|
+
| Domain | Rule Reference File | When to Consult |
|
|
46
|
+
|---|---|---|
|
|
47
|
+
| **Testing** | [docs/rules/test_driven_development.md](../../../../docs/rules/test_driven_development.md) | Writing acceptance/unit tests, coverage checks. |
|
|
48
|
+
| **Multi-Tenancy** | [docs/rules/multitenancy_isolation.md](../../../../docs/rules/multitenancy_isolation.md) | Tenant context resolution, PostgreSQL RLS. |
|
|
49
|
+
| **Database** | [docs/rules/database_transactions.md](../../../../docs/rules/database_transactions.md) | ACID transactions, outbox pattern, atomicity. |
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## 4. Harness Parity
|
|
54
|
+
Keep `AGENTS.md`, `CLAUDE.md`, and `agents.md` in sync via filesystem symlinks:
|
|
55
|
+
```bash
|
|
56
|
+
ln -sf AGENTS.md CLAUDE.md
|
|
57
|
+
ln -sf AGENTS.md agents.md
|
|
58
|
+
```
|
|
59
|
+
```
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# Continuous Skill & Rule Refinement Workflow
|
|
2
|
+
|
|
3
|
+
> **Purpose:** Iteratively improve AI code output by harvesting manual developer edits and converting recurring mistakes into explicit skill rules.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## The 4-Step Refinement Loop
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
1. AI Draft Generated ──► 2. Human Manual Edit ──► 3. Extract Gaps & Anti-Patterns ──► 4. Update Skill
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
### 1. Capture Raw Output
|
|
14
|
+
When prompting the AI to execute a complex task (e.g. drafting an article, building a complex form, scaffolding an endpoint), retain the raw generated output before making edits.
|
|
15
|
+
|
|
16
|
+
### 2. Perform Gold-Standard Edits
|
|
17
|
+
Manually modify the generated file to match production quality:
|
|
18
|
+
- Adjust architectural choices.
|
|
19
|
+
- Fix styling, accessibility, or type annotations.
|
|
20
|
+
- Correct API response shapes or error handling.
|
|
21
|
+
|
|
22
|
+
### 3. Analyze the Diff
|
|
23
|
+
Compare the initial AI draft against the final human version:
|
|
24
|
+
- What did the AI assume that was incorrect?
|
|
25
|
+
- What repetitive boilerplate did the AI miss?
|
|
26
|
+
- What unnecessary packages, methods, or complex patterns did it introduce?
|
|
27
|
+
|
|
28
|
+
### 4. Feed Back into the Skill
|
|
29
|
+
Update the relevant skill or rule file:
|
|
30
|
+
- Add positive examples under the workflow section.
|
|
31
|
+
- **Crucial:** Add explicit negative rules in the **"Gotchas & What NOT to Do"** section (e.g. *"DO NOT use window.confirm; use @radix-ui/react-alert-dialog"*).
|
|
32
|
+
- If a step failed due to non-deterministic CLI flags, write an executable helper script under `scripts/`.
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
# Relentless Skill Architecture Inquiry Guide
|
|
2
|
+
|
|
3
|
+
> **Core Rule:** Never assume what a skill needs. Relentlessly interrogate all 7 branches before authoring or modifying any `SKILL.md`.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## The 7 Core Inquiry Branches
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
[Skill Request / Idea]
|
|
11
|
+
│
|
|
12
|
+
▼
|
|
13
|
+
[Branch 1: Placement & Scope]
|
|
14
|
+
├─ All prompts repository-wide? ─────────► Root AGENTS.md
|
|
15
|
+
├─ One monorepo package only? ──────────► Nested package AGENTS.md
|
|
16
|
+
├─ Continuous domain coding rule? ──────► docs/rules/*.md
|
|
17
|
+
└─ Specialized on-demand workflow? ─────► .agents/skills/<name>/
|
|
18
|
+
│
|
|
19
|
+
▼
|
|
20
|
+
[Branch 2: Trigger Intent & Anti-Triggers]
|
|
21
|
+
├─ What explicit user request triggers this?
|
|
22
|
+
├─ Imperative phrasing: 'Use when the user wants to...' (< 1024 chars)
|
|
23
|
+
└─ Negative boundaries: 'Do NOT use for...'
|
|
24
|
+
│
|
|
25
|
+
▼
|
|
26
|
+
[Branch 3: Domain Ground Truth (Purge Fluff)]
|
|
27
|
+
├─ What does the LLM already know from pre-training? (PURGE)
|
|
28
|
+
└─ What is strictly proprietary/unique to this repository? (KEEP)
|
|
29
|
+
│
|
|
30
|
+
▼
|
|
31
|
+
[Branch 4: Anti-Patterns & Gotchas (What NOT to Do)]
|
|
32
|
+
├─ What mistakes has the AI actually made in past attempts?
|
|
33
|
+
└─ Formulate 3–5 explicit negative constraints ('DO NOT...')
|
|
34
|
+
│
|
|
35
|
+
▼
|
|
36
|
+
[Branch 5: Determinism vs. Stochastic LLM]
|
|
37
|
+
├─ Are there brittle command lines or JSON formatting steps?
|
|
38
|
+
└─ Should these be deterministic helper scripts in scripts/?
|
|
39
|
+
│
|
|
40
|
+
▼
|
|
41
|
+
[Branch 6: Progressive Disclosure (< 500 Lines)]
|
|
42
|
+
├─ Is SKILL.md under 500 lines?
|
|
43
|
+
├─ Are deep manuals offloaded to references/?
|
|
44
|
+
└─ Are static schemas or templates offloaded to assets/?
|
|
45
|
+
│
|
|
46
|
+
▼
|
|
47
|
+
[Branch 7: Verification & Feedback Loop]
|
|
48
|
+
├─ What structured output format proves success?
|
|
49
|
+
├─ What self-validation checklist must be satisfied?
|
|
50
|
+
└─ How will diffs between AI drafts and human edits be harvested?
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
---
|
|
54
|
+
|
|
55
|
+
## Inquiry Interview Template
|
|
56
|
+
|
|
57
|
+
When asking the user or interrogating the workspace, use this questionnaire:
|
|
58
|
+
|
|
59
|
+
1. **Scope:** Is this workflow continuous (applies whenever writing code in this domain) or episodic (triggered only on explicit request)?
|
|
60
|
+
2. **Triggers:** When should the AI automatically reach for this skill? What tasks should it actively *refuse* to use this skill for?
|
|
61
|
+
3. **Pitfalls:** What has the AI historically messed up when doing this task (e.g. hallucinating dependencies, using wrong flags, creating leaky abstractions)?
|
|
62
|
+
4. **Determinism:** Are there shell commands or formatting rules that should be guaranteed with a script rather than left to LLM chance?
|
|
63
|
+
5. **Output Standard:** What does the ideal, gold-standard output look like?
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
# Progressive Disclosure Skill Template
|
|
2
|
+
|
|
3
|
+
Use this template when creating new skills under `.agents/skills/<skill-name>/SKILL.md`.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
```markdown
|
|
8
|
+
---
|
|
9
|
+
name: <skill-name>
|
|
10
|
+
description: Use when [clear trigger conditions, e.g. implementing authentication, generating emails, running migrations]. Do not use for [explicit boundaries, e.g. general bug fixes or frontend styling].
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# [Skill Title]
|
|
14
|
+
|
|
15
|
+
> **Purpose:** [Brief 1–2 sentence summary of what this skill achieves].
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## 1. Trigger Conditions
|
|
20
|
+
- When the user explicitly requests: `[Examples]`
|
|
21
|
+
- When performing tasks involving: `[File patterns or domains]`
|
|
22
|
+
- **Do NOT trigger when:** `[Negative conditions]`
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## 2. Core Workflow Steps
|
|
27
|
+
1. **[Step 1: Discover & Validate]**: Inspect current state before modifying code.
|
|
28
|
+
2. **[Step 2: Execute Core Logic]**: Follow established patterns.
|
|
29
|
+
3. **[Step 3: Self-Check & Verify]**: Run test commands or validation scripts.
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## 3. Gotchas & What NOT to Do
|
|
34
|
+
- **DO NOT** [Specific common AI mistake #1].
|
|
35
|
+
- **DO NOT** [Specific common AI mistake #2].
|
|
36
|
+
- **DO NOT** [Specific common AI mistake #3].
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## 4. Structured Output Template
|
|
41
|
+
Provide consistent formatting for results:
|
|
42
|
+
```markdown
|
|
43
|
+
### Summary of Changes
|
|
44
|
+
- **Action**: ...
|
|
45
|
+
- **Files Affected**: ...
|
|
46
|
+
- **Verification Evidence**: ...
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
51
|
+
## 5. Subdirectories & Progressive Resources
|
|
52
|
+
- Deep reference documentation: `references/`
|
|
53
|
+
- Deterministic helper scripts: `scripts/`
|
|
54
|
+
- Static schemas or mock assets: `assets/`
|
|
55
|
+
```
|
|
@@ -0,0 +1,163 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# ==============================================================================
|
|
3
|
+
# validate_agentic_configs.sh
|
|
4
|
+
# Deterministic Validator for Agentic Files, Rules, and Skills
|
|
5
|
+
# ==============================================================================
|
|
6
|
+
|
|
7
|
+
set -euo pipefail
|
|
8
|
+
|
|
9
|
+
WORKSPACE_ROOT="${1:-$(pwd)}"
|
|
10
|
+
ERRORS=0
|
|
11
|
+
WARNINGS=0
|
|
12
|
+
|
|
13
|
+
echo "🔍 Validating Agentic Architecture in: ${WORKSPACE_ROOT}"
|
|
14
|
+
echo "--------------------------------------------------------------"
|
|
15
|
+
|
|
16
|
+
# Helper print functions
|
|
17
|
+
log_pass() { echo " ✅ $1"; }
|
|
18
|
+
log_warn() { echo " ⚠️ $1"; WARNINGS=$((WARNINGS + 1)); }
|
|
19
|
+
log_fail() { echo " ❌ $1"; ERRORS=$((ERRORS + 1)); }
|
|
20
|
+
|
|
21
|
+
# 1. Root AGENTS.md & Symlinks Verification
|
|
22
|
+
echo "1. Checking Root Configuration & Symlinks..."
|
|
23
|
+
AGENTS_FILE="${WORKSPACE_ROOT}/AGENTS.md"
|
|
24
|
+
if [[ ! -f "${AGENTS_FILE}" ]]; then
|
|
25
|
+
log_fail "Missing root AGENTS.md at ${AGENTS_FILE}"
|
|
26
|
+
else
|
|
27
|
+
log_pass "AGENTS.md exists."
|
|
28
|
+
|
|
29
|
+
LINE_COUNT=$(wc -l < "${AGENTS_FILE}")
|
|
30
|
+
if [[ ${LINE_COUNT} -le 120 ]]; then
|
|
31
|
+
log_pass "AGENTS.md line count is lean: ${LINE_COUNT} lines (<= 120)."
|
|
32
|
+
elif [[ ${LINE_COUNT} -le 150 ]]; then
|
|
33
|
+
log_warn "AGENTS.md line count is getting large: ${LINE_COUNT} lines (warn > 120)."
|
|
34
|
+
else
|
|
35
|
+
log_fail "AGENTS.md exceeds maximum line limit: ${LINE_COUNT} lines (max 150)."
|
|
36
|
+
fi
|
|
37
|
+
fi
|
|
38
|
+
|
|
39
|
+
# Check CLAUDE.md symlink
|
|
40
|
+
CLAUDE_FILE="${WORKSPACE_ROOT}/CLAUDE.md"
|
|
41
|
+
if [[ -L "${CLAUDE_FILE}" ]]; then
|
|
42
|
+
TARGET=$(readlink "${CLAUDE_FILE}")
|
|
43
|
+
if [[ "${TARGET}" == "AGENTS.md" ]]; then
|
|
44
|
+
log_pass "CLAUDE.md is a valid symlink to AGENTS.md."
|
|
45
|
+
else
|
|
46
|
+
log_fail "CLAUDE.md points to '${TARGET}' instead of 'AGENTS.md'."
|
|
47
|
+
fi
|
|
48
|
+
else
|
|
49
|
+
log_fail "CLAUDE.md is not a symbolic link."
|
|
50
|
+
fi
|
|
51
|
+
|
|
52
|
+
# Check agents.md symlink
|
|
53
|
+
AGENTS_LOWER="${WORKSPACE_ROOT}/agents.md"
|
|
54
|
+
if [[ -L "${AGENTS_LOWER}" ]]; then
|
|
55
|
+
TARGET=$(readlink "${AGENTS_LOWER}")
|
|
56
|
+
if [[ "${TARGET}" == "AGENTS.md" ]]; then
|
|
57
|
+
log_pass "agents.md is a valid symlink to AGENTS.md."
|
|
58
|
+
else
|
|
59
|
+
log_fail "agents.md points to '${TARGET}' instead of 'AGENTS.md'."
|
|
60
|
+
fi
|
|
61
|
+
else
|
|
62
|
+
log_fail "agents.md is not a symbolic link."
|
|
63
|
+
fi
|
|
64
|
+
|
|
65
|
+
# 2. Checking Progressive Disclosure Rules (docs/rules)
|
|
66
|
+
echo ""
|
|
67
|
+
echo "2. Checking Progressive Disclosure Rules..."
|
|
68
|
+
RULES_DIR="${WORKSPACE_ROOT}/docs/rules"
|
|
69
|
+
if [[ ! -d "${RULES_DIR}" ]]; then
|
|
70
|
+
log_fail "Missing docs/rules directory at ${RULES_DIR}"
|
|
71
|
+
else
|
|
72
|
+
RULE_COUNT=0
|
|
73
|
+
for rule_file in "${RULES_DIR}"/*.md; do
|
|
74
|
+
[[ -e "${rule_file}" ]] || continue
|
|
75
|
+
RULE_COUNT=$((RULE_COUNT + 1))
|
|
76
|
+
RULE_NAME=$(basename "${rule_file}")
|
|
77
|
+
|
|
78
|
+
# Check for title
|
|
79
|
+
if ! grep -q "^# " "${rule_file}"; then
|
|
80
|
+
log_fail "Rule ${RULE_NAME} missing H1 header (# Title)"
|
|
81
|
+
fi
|
|
82
|
+
|
|
83
|
+
# Check for Core Mandate blockquote
|
|
84
|
+
if ! grep -q "^> \*\*Core Mandate:\*\*" "${rule_file}"; then
|
|
85
|
+
log_warn "Rule ${RULE_NAME} missing standardized '> **Core Mandate:**' summary"
|
|
86
|
+
fi
|
|
87
|
+
done
|
|
88
|
+
log_pass "Validated ${RULE_COUNT} modular rule files in docs/rules/."
|
|
89
|
+
fi
|
|
90
|
+
|
|
91
|
+
# 3. Checking Skills Architecture (.agents/skills)
|
|
92
|
+
echo ""
|
|
93
|
+
echo "3. Checking Specialized Skills (.agents/skills)..."
|
|
94
|
+
SKILLS_DIR="${WORKSPACE_ROOT}/.agents/skills"
|
|
95
|
+
if [[ ! -d "${SKILLS_DIR}" ]]; then
|
|
96
|
+
log_fail "Missing .agents/skills directory at ${SKILLS_DIR}"
|
|
97
|
+
else
|
|
98
|
+
SKILL_COUNT=0
|
|
99
|
+
for skill_folder in "${SKILLS_DIR}"/*; do
|
|
100
|
+
[[ -d "${skill_folder}" ]] || continue
|
|
101
|
+
SKILL_NAME=$(basename "${skill_folder}")
|
|
102
|
+
SKILL_FILE="${skill_folder}/SKILL.md"
|
|
103
|
+
SKILL_COUNT=$((SKILL_COUNT + 1))
|
|
104
|
+
|
|
105
|
+
if [[ ! -f "${SKILL_FILE}" ]]; then
|
|
106
|
+
log_fail "Skill '${SKILL_NAME}' missing SKILL.md"
|
|
107
|
+
continue
|
|
108
|
+
fi
|
|
109
|
+
|
|
110
|
+
# Check front matter existence
|
|
111
|
+
if ! head -n 1 "${SKILL_FILE}" | grep -q "^---"; then
|
|
112
|
+
log_fail "Skill '${SKILL_NAME}' missing opening front matter delimiter (---)"
|
|
113
|
+
continue
|
|
114
|
+
fi
|
|
115
|
+
|
|
116
|
+
# Check name field in front matter
|
|
117
|
+
if ! grep -E "^name:[[:space:]]*${SKILL_NAME}" "${SKILL_FILE}" > /dev/null; then
|
|
118
|
+
log_fail "Skill '${SKILL_NAME}' front matter 'name:' does not match directory name"
|
|
119
|
+
fi
|
|
120
|
+
|
|
121
|
+
# Check description
|
|
122
|
+
DESC=$(grep -E "^description:" "${SKILL_FILE}" | sed -E 's/^description:[[:space:]]*//' || true)
|
|
123
|
+
if [[ -z "${DESC}" ]]; then
|
|
124
|
+
log_fail "Skill '${SKILL_NAME}' missing front matter 'description:'"
|
|
125
|
+
else
|
|
126
|
+
# Check imperative phrasing
|
|
127
|
+
if [[ ! "${DESC}" =~ ^Use[[:space:]]when ]]; then
|
|
128
|
+
log_warn "Skill '${SKILL_NAME}' description should start with imperative 'Use when...'"
|
|
129
|
+
fi
|
|
130
|
+
|
|
131
|
+
# Check character length (< 1024)
|
|
132
|
+
CHAR_LEN=${#DESC}
|
|
133
|
+
if [[ ${CHAR_LEN} -gt 1024 ]]; then
|
|
134
|
+
log_fail "Skill '${SKILL_NAME}' description exceeds 1024 chars (${CHAR_LEN} chars)"
|
|
135
|
+
fi
|
|
136
|
+
fi
|
|
137
|
+
|
|
138
|
+
# Check body length (< 500 lines)
|
|
139
|
+
SKILL_LINES=$(wc -l < "${SKILL_FILE}")
|
|
140
|
+
if [[ ${SKILL_LINES} -gt 500 ]]; then
|
|
141
|
+
log_warn "Skill '${SKILL_NAME}' exceeds 500 lines (${SKILL_LINES} lines). Offload details to references/."
|
|
142
|
+
else
|
|
143
|
+
log_pass "Skill '${SKILL_NAME}': ${SKILL_LINES} lines, description valid (${#DESC} chars)."
|
|
144
|
+
fi
|
|
145
|
+
|
|
146
|
+
# Check for Gotchas / What NOT to do section
|
|
147
|
+
if ! grep -qi "What NOT to do" "${SKILL_FILE}" && ! grep -qi "Gotchas" "${SKILL_FILE}"; then
|
|
148
|
+
log_warn "Skill '${SKILL_NAME}' missing mandatory 'Gotchas & What NOT to Do' section"
|
|
149
|
+
fi
|
|
150
|
+
done
|
|
151
|
+
log_pass "Validated ${SKILL_COUNT} skills in .agents/skills/."
|
|
152
|
+
fi
|
|
153
|
+
|
|
154
|
+
# 4. Summary Output
|
|
155
|
+
echo ""
|
|
156
|
+
echo "--------------------------------------------------------------"
|
|
157
|
+
if [[ ${ERRORS} -eq 0 ]]; then
|
|
158
|
+
echo "🎉 SUCCESS: All agentic configurations are valid and healthy! (${WARNINGS} warnings)"
|
|
159
|
+
exit 0
|
|
160
|
+
else
|
|
161
|
+
echo "🚨 FAILURE: Found ${ERRORS} error(s) and ${WARNINGS} warning(s) in agentic configurations."
|
|
162
|
+
exit 1
|
|
163
|
+
fi
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: clean-code-refactor
|
|
3
|
+
description: Use when refactoring existing code to comply with Clean Code, SOLID principles, Pragmatic Programmer practices, or modern design patterns (Strategy, Adapter, Repository, Result pattern). Do not use when merely creating a new feature from scratch, fixing a minor typo, or writing initial tests.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Clean Code & Design Patterns Refactoring Skill
|
|
7
|
+
|
|
8
|
+
> **Core Purpose:** Transform messy, coupled, or rigid code into clean, expressive, and maintainable TypeScript implementations adhering to Robert C. Martin's Clean Code, The Pragmatic Programmer, and modern Gang of Four patterns without altering external behavior.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## 1. When to Use This Skill
|
|
13
|
+
- During the **REFACTOR** stage of the Outside-In TDD double loop (after tests are green).
|
|
14
|
+
- Resolving code smells: long functions (> 30 lines), large classes, excessive parameter lists (> 3 args), primitive obsession, duplicate domain knowledge.
|
|
15
|
+
- Decoupling 3rd-party dependencies using the **Adapter Pattern**.
|
|
16
|
+
- Replacing complex conditional logic (`switch`/`if-else` cascades) with the **Strategy Pattern**.
|
|
17
|
+
- Eliminating untyped exception throwing with the **Result / Either Pattern**.
|
|
18
|
+
- Removing dead or commented-out code to restore readability.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## 2. Step-by-Step Refactoring Workflow
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
1. Verify Green Tests ──► 2. Identify Code Smells ──► 3. Select Design Pattern ──► 4. Atomic Surgical Edit ──► 5. Verify 100% Green
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
### Step 1: Establish the Test Safety Net
|
|
29
|
+
- Never refactor without passing tests.
|
|
30
|
+
- Confirm all existing unit and acceptance tests pass: `npm run test` or `npm run coverage`.
|
|
31
|
+
- If coverage is missing or incomplete, write tests *before* touching production code.
|
|
32
|
+
|
|
33
|
+
### Step 2: Identify Specific Code Smells
|
|
34
|
+
Target concrete flaws:
|
|
35
|
+
- **Long Method / Violating Single Responsibility**: Extract smaller private helper functions (SLAP principle).
|
|
36
|
+
- **Coupling to 3rd-Party SDK**: Wrap SDK calls inside an application-owned interface (Adapter pattern).
|
|
37
|
+
- **Duplicated Domain Rules**: Consolidate business logic into a single authoritative value object or service (DRY).
|
|
38
|
+
- **Leaky Exceptions**: Convert error throwing across controller/service boundaries into typed `Result<T, E>` unions.
|
|
39
|
+
|
|
40
|
+
### Step 3: Apply the Appropriate Pattern
|
|
41
|
+
- **Adapter**: Define an interface `IEmailAdapter` or `IPaymentAdapter`. Create an implementation wrapping the open-source library.
|
|
42
|
+
- **Strategy**: Define a strategy interface `ITenantPolicy`. Inject the appropriate strategy based on tenant configuration.
|
|
43
|
+
- **Factory**: Centralize instantiation of complex collaborator graphs.
|
|
44
|
+
- **Repository / Data Mapper**: Decouple domain entities from direct ORM queries.
|
|
45
|
+
|
|
46
|
+
### Step 4: Execute Atomic Surgical Edits
|
|
47
|
+
- Make one micro-refactor at a time (e.g. rename a method, extract a class).
|
|
48
|
+
- Maintain existing naming conventions and strict TypeScript types.
|
|
49
|
+
- Ensure zero lint or type errors: `npm run lint && npm run typecheck`.
|
|
50
|
+
|
|
51
|
+
### Step 5: Verify Continuous Green State
|
|
52
|
+
- Run tests after every single atomic change: `npm run coverage`.
|
|
53
|
+
- Ensure coverage remains at **100.00%**.
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## 3. Gotchas & What NOT to Do
|
|
58
|
+
|
|
59
|
+
- **DO NOT** change external functional behavior while refactoring. Refactoring is strictly structural.
|
|
60
|
+
- **DO NOT** refactor without automated tests. A green test suite is non-negotiable.
|
|
61
|
+
- **DO NOT** introduce over-engineering or speculative design patterns for simple, stable code (YAGNI).
|
|
62
|
+
- **DO NOT** mock external 3rd-party types directly in tests; always mock application-owned adapter interfaces.
|
|
63
|
+
- **DO NOT** leave commented-out blocks of old code behind. Clean up completely.
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
## 4. Structured Output Template
|
|
68
|
+
|
|
69
|
+
```markdown
|
|
70
|
+
### Clean Code Refactoring Summary: [Module / Class Name]
|
|
71
|
+
|
|
72
|
+
1. **Code Smells Identified**:
|
|
73
|
+
- [Smell 1: e.g. Long method in UserController violating Single Responsibility]
|
|
74
|
+
- [Smell 2: e.g. Direct coupling to external Stripe SDK in domain service]
|
|
75
|
+
|
|
76
|
+
2. **Refactoring Steps & Patterns Applied**:
|
|
77
|
+
- Applied **Adapter Pattern**: Extracted `IPaymentAdapter` to isolate Stripe SDK.
|
|
78
|
+
- Applied **SLAP & Extract Function**: Decomposed 60-line handler into three 15-line functions.
|
|
79
|
+
- Applied **Result Pattern**: Replaced generic `throw Error` with typed `Result<Order, OrderError>`.
|
|
80
|
+
|
|
81
|
+
3. **Verification Evidence**:
|
|
82
|
+
- Tests Status: PASS (100.00% statement, branch, and function coverage preserved)
|
|
83
|
+
- Linter Status: PASS (0 ESLint warnings)
|
|
84
|
+
- Typecheck: PASS (0 TypeScript errors)
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## 5. Subdirectories & Progressive Resources
|
|
90
|
+
- [references/clean_code_smells.md](./references/clean_code_smells.md): Catalog of code smells and their refactoring cures.
|
|
91
|
+
- [references/design_patterns_ts.md](./references/design_patterns_ts.md): Production TypeScript implementations of Adapter, Strategy, and Result patterns.
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# Code Smells & Refactoring Cures Reference
|
|
2
|
+
|
|
3
|
+
Catalog of common code smells and their remedies in modern TypeScript codebases.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Bloated Functions (> 25–30 Lines)
|
|
8
|
+
- **Smell**: A single function performs input parsing, business calculation, database persistence, and response formatting.
|
|
9
|
+
- **Cure**: Apply *Extract Function* and *Single Level of Abstraction (SLAP)*. Group lower-level details into descriptive helper functions.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 2. Deep Conditional Nesting (Arrow Anti-Pattern)
|
|
14
|
+
- **Smell**: 3+ levels of nested `if / else` blocks checking permissions, status, and input validity.
|
|
15
|
+
- **Cure**: Apply *Guard Clauses* (Return Early) or the *Strategy Pattern* for polymorphic behavior.
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## 3. Direct 3rd-Party Coupling
|
|
20
|
+
- **Smell**: Domain controllers directly importing external SDKs (e.g. `import Stripe from 'stripe'`).
|
|
21
|
+
- **Cure**: Apply the *Adapter Pattern*. Define an interface `IPaymentGateway` owned by the domain. Create an infrastructure adapter implementing the interface.
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## 4. Primitive Obsession & Long Parameter Lists (> 3 Parameters)
|
|
26
|
+
- **Smell**: Methods taking 6 primitive strings and numbers (`createUser(first, last, email, role, phone, tenantId)`).
|
|
27
|
+
- **Cure**: Bundle related fields into a strongly typed DTO or Zod schema (`CreateUserInput`).
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
# Modern Design Patterns in TypeScript Reference
|
|
2
|
+
|
|
3
|
+
Production implementations of essential design patterns in full-stack TypeScript.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Adapter Pattern (Dependency Isolation)
|
|
8
|
+
|
|
9
|
+
```typescript
|
|
10
|
+
// 1. Domain Interface (Owned by the application)
|
|
11
|
+
export interface IEmailAdapter {
|
|
12
|
+
send(to: string, subject: string, html: string): Promise<Result<void, Error>>;
|
|
13
|
+
}
|
|
14
|
+
|
|
15
|
+
// 2. Open-Source Infrastructure Implementation (e.g. Mailpit/Nodemailer)
|
|
16
|
+
export class NodemailerEmailAdapter implements IEmailAdapter {
|
|
17
|
+
constructor(private readonly transporter: nodemailer.Transporter) {}
|
|
18
|
+
|
|
19
|
+
async send(to: string, subject: string, html: string): Promise<Result<void, Error>> {
|
|
20
|
+
try {
|
|
21
|
+
await this.transporter.sendMail({ to, subject, html });
|
|
22
|
+
return { success: true, value: undefined };
|
|
23
|
+
} catch (error) {
|
|
24
|
+
return { success: false, error: error as Error };
|
|
25
|
+
}
|
|
26
|
+
}
|
|
27
|
+
}
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## 2. Strategy Pattern (Runtime Policy Swapping)
|
|
33
|
+
|
|
34
|
+
```typescript
|
|
35
|
+
// 1. Strategy Contract
|
|
36
|
+
export interface ITenantPricingStrategy {
|
|
37
|
+
calculateMonthlyRate(activeSeats: number): number;
|
|
38
|
+
}
|
|
39
|
+
|
|
40
|
+
// 2. Concrete Strategies
|
|
41
|
+
export class StandardPricingStrategy implements ITenantPricingStrategy {
|
|
42
|
+
calculateMonthlyRate(activeSeats: number): number {
|
|
43
|
+
return activeSeats * 15;
|
|
44
|
+
}
|
|
45
|
+
}
|
|
46
|
+
|
|
47
|
+
export class EnterprisePricingStrategy implements ITenantPricingStrategy {
|
|
48
|
+
calculateMonthlyRate(activeSeats: number): number {
|
|
49
|
+
return activeSeats * 10 + 500; // Flat base fee
|
|
50
|
+
}
|
|
51
|
+
}
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## 3. Result / Either Pattern (Type-Safe Errors)
|
|
57
|
+
|
|
58
|
+
```typescript
|
|
59
|
+
export type Result<T, E = Error> =
|
|
60
|
+
| { success: true; value: T }
|
|
61
|
+
| { success: false; error: E };
|
|
62
|
+
|
|
63
|
+
export const Ok = <T>(value: T): Result<T, never> => ({ success: true, value });
|
|
64
|
+
export const Err = <E>(error: E): Result<never, E> => ({ success: false, error });
|
|
65
|
+
```
|