You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/workflows/claude.yml
+87-23Lines changed: 87 additions & 23 deletions
Original file line number
Diff line number
Diff line change
@@ -3,9 +3,95 @@ name: Claude code review (Reusable)
3
3
on:
4
4
pull_request:
5
5
types: [ opened, synchronize ]
6
+
inputs:
7
+
review_instructions:
8
+
description: 'Custom instructions for Claude code review'
9
+
required: false
10
+
default: |
11
+
- Convention over Configuration with Functional Purity - This framework/project will be a true integrated system for Data Engineering & Data pipelines - which collectively works with other libraries, but pieces built specifically for each other to Data Engineering that work as one cohesive whole. Framework also must be unified abstraction layer. Framework makes best architectural decisions as well. Wherever applicable Data Engineers interact with APIs & exposed patterns/ layers not the underlying logic which libraries gives us to use.
12
+
- Best scala functional programming design patterns. Best practices of SOLID patterns, creational, structural & behavioral design patterns. Best scala functional programming design patterns - all best possible patterns that suits us & solve problems may be Kleisl etc.
13
+
- We are writing data pipelines. So say goodbye to config/metadata chaos! Let Scala’s type & effect systems co-author them with you. We want to show how we built a contract-first, pluggable platform using Giter8, Refined, Cats Effect, ZIO, Kyo & Caprese ( Kyo & Caprese experimental only) - delivering compile-time guarantees and fiber-safe execution.
14
+
- What if your data platform stopped relying on configuration-driven / metadata-driven and postmortems - and instead enforced correctness, traceability, and effect boundaries at compile time?
15
+
- We want to build a production-ready data pipeline archetype system in Scala. We want to use Giter8 templates to scaffold pipelines that are contract-driven, type-safe, effectful, and pluggable - all enforced through the Scala type system and effect libraries.
16
+
- 📦 Giter8 templates bootstrap consistent, compile-time safe projects • 🛡️ Refined types validate configuration before runtime • ✅ Cats ValidatedNel catches multi-rule violations in DQ checks • 🔌 Type classes enable pluggable validation and ingestion • ⚙️ ZIO Layers and Cats Effect offer fiber-safe orchestration • 🚀 Trait-based runners switch between Spark, Flink, and Kafka • 📊 Data Quality and custom rules enforce data contract quality at runtime • 🧠 Experimental: Kyo - tracks multiple effects via intersection types and Caprese - capture-checking tracks capabilities
17
+
- Use potential & power of Scala ecosystem but not over engineer it.
18
+
- All possible USPs of Scala - Monads, Pattern Matching, Generics, Variance, Type classes, Type class patterns, Self Types, Structural types, F-Bounded Polymorphism, Higher-Kinded Types, Reflections, Lazy Evals, Concurrency with Futures, Implicits. All we need to make best use of yet keeping simplicity by not over engineering it. Apply only where they fit perfectly to solve that bit of problem or make other things relevant & elegant.
19
+
- For project specific types create plenty of type aliases. Create type class patterns etc.
20
+
- Use Zio & Cats-Effect separately because we are providing an option of Effect system. Use cats core as well - Semigroups, Monoids, Monads, Functors, Applicatives, Creative Type class patterns etc.
21
+
- We need to be creative, innovative & something like Wow such a thing can be achieved who'd have never thought about such things in Data Engineering Data Pipelines.
22
+
- No Over Engineering - Keep simplicity, scalable, understandable, adaptable yet creative - We need to be creative, innovative & something like Wow such a thing can be achieved who'd have never thought about such things in Data Engineering Data Pipelines.
23
+
- Code quality and best practices
24
+
- Potential bugs or issues
25
+
- Performance considerations
26
+
- Security concerns
27
+
- Test coverage
28
+
- Documentation clarity
29
+
- Overall maintainability
30
+
- Give revised code of each & every improvement from above points
31
+
- Give revised code of all suggest improvements
32
+
- Give revised improvements in project structure as well
33
+
34
+
6
35
7
36
issue_comment:
8
37
types: [ created ]
38
+
inputs:
39
+
review_instructions:
40
+
description: 'Custom instructions for Claude code review'
41
+
required: false
42
+
default: |
43
+
- Convention over Configuration with Functional Purity - This framework/project will be a true integrated system for Data Engineering & Data pipelines - which collectively works with other libraries, but pieces built specifically for each other to Data Engineering that work as one cohesive whole. Framework also must be unified abstraction layer. Framework makes best architectural decisions as well. Wherever applicable Data Engineers interact with APIs & exposed patterns/ layers not the underlying logic which libraries gives us to use.
44
+
- Best scala functional programming design patterns. Best practices of SOLID patterns, creational, structural & behavioral design patterns. Best scala functional programming design patterns - all best possible patterns that suits us & solve problems may be Kleisl etc.
45
+
- We are writing data pipelines. So say goodbye to config/metadata chaos! Let Scala’s type & effect systems co-author them with you. We want to show how we built a contract-first, pluggable platform using Giter8, Refined, Cats Effect, ZIO, Kyo & Caprese ( Kyo & Caprese experimental only) - delivering compile-time guarantees and fiber-safe execution.
46
+
- What if your data platform stopped relying on configuration-driven / metadata-driven and postmortems - and instead enforced correctness, traceability, and effect boundaries at compile time?
47
+
- We want to build a production-ready data pipeline archetype system in Scala. We want to use Giter8 templates to scaffold pipelines that are contract-driven, type-safe, effectful, and pluggable - all enforced through the Scala type system and effect libraries.
48
+
- 📦 Giter8 templates bootstrap consistent, compile-time safe projects • 🛡️ Refined types validate configuration before runtime • ✅ Cats ValidatedNel catches multi-rule violations in DQ checks • 🔌 Type classes enable pluggable validation and ingestion • ⚙️ ZIO Layers and Cats Effect offer fiber-safe orchestration • 🚀 Trait-based runners switch between Spark, Flink, and Kafka • 📊 Data Quality and custom rules enforce data contract quality at runtime • 🧠 Experimental: Kyo - tracks multiple effects via intersection types and Caprese - capture-checking tracks capabilities
49
+
- Use potential & power of Scala ecosystem but not over engineer it.
50
+
- All possible USPs of Scala - Monads, Pattern Matching, Generics, Variance, Type classes, Type class patterns, Self Types, Structural types, F-Bounded Polymorphism, Higher-Kinded Types, Reflections, Lazy Evals, Concurrency with Futures, Implicits. All we need to make best use of yet keeping simplicity by not over engineering it. Apply only where they fit perfectly to solve that bit of problem or make other things relevant & elegant.
51
+
- For project specific types create plenty of type aliases. Create type class patterns etc.
52
+
- Use Zio & Cats-Effect separately because we are providing an option of Effect system. Use cats core as well - Semigroups, Monoids, Monads, Functors, Applicatives, Creative Type class patterns etc.
53
+
- We need to be creative, innovative & something like Wow such a thing can be achieved who'd have never thought about such things in Data Engineering Data Pipelines.
54
+
- No Over Engineering - Keep simplicity, scalable, understandable, adaptable yet creative - We need to be creative, innovative & something like Wow such a thing can be achieved who'd have never thought about such things in Data Engineering Data Pipelines.
55
+
- Code quality and best practices
56
+
- Potential bugs or issues
57
+
- Performance considerations
58
+
- Security concerns
59
+
- Test coverage
60
+
- Documentation clarity
61
+
- Overall maintainability
62
+
- Give revised code of each & every improvement from above points
63
+
- Give revised code of all suggest improvements
64
+
- Give revised improvements in project structure as well
65
+
66
+
67
+
workflow_dispatch:
68
+
inputs:
69
+
review_instructions:
70
+
description: 'Custom instructions for Claude code review'
71
+
required: false
72
+
default: |
73
+
- Convention over Configuration with Functional Purity - This framework/project will be a true integrated system for Data Engineering & Data pipelines - which collectively works with other libraries, but pieces built specifically for each other to Data Engineering that work as one cohesive whole. Framework also must be unified abstraction layer. Framework makes best architectural decisions as well. Wherever applicable Data Engineers interact with APIs & exposed patterns/ layers not the underlying logic which libraries gives us to use.
74
+
- Best scala functional programming design patterns. Best practices of SOLID patterns, creational, structural & behavioral design patterns. Best scala functional programming design patterns - all best possible patterns that suits us & solve problems may be Kleisl etc.
75
+
- We are writing data pipelines. So say goodbye to config/metadata chaos! Let Scala’s type & effect systems co-author them with you. We want to show how we built a contract-first, pluggable platform using Giter8, Refined, Cats Effect, ZIO, Kyo & Caprese ( Kyo & Caprese experimental only) - delivering compile-time guarantees and fiber-safe execution.
76
+
- What if your data platform stopped relying on configuration-driven / metadata-driven and postmortems - and instead enforced correctness, traceability, and effect boundaries at compile time?
77
+
- We want to build a production-ready data pipeline archetype system in Scala. We want to use Giter8 templates to scaffold pipelines that are contract-driven, type-safe, effectful, and pluggable - all enforced through the Scala type system and effect libraries.
78
+
- 📦 Giter8 templates bootstrap consistent, compile-time safe projects • 🛡️ Refined types validate configuration before runtime • ✅ Cats ValidatedNel catches multi-rule violations in DQ checks • 🔌 Type classes enable pluggable validation and ingestion • ⚙️ ZIO Layers and Cats Effect offer fiber-safe orchestration • 🚀 Trait-based runners switch between Spark, Flink, and Kafka • 📊 Data Quality and custom rules enforce data contract quality at runtime • 🧠 Experimental: Kyo - tracks multiple effects via intersection types and Caprese - capture-checking tracks capabilities
79
+
- Use potential & power of Scala ecosystem but not over engineer it.
80
+
- All possible USPs of Scala - Monads, Pattern Matching, Generics, Variance, Type classes, Type class patterns, Self Types, Structural types, F-Bounded Polymorphism, Higher-Kinded Types, Reflections, Lazy Evals, Concurrency with Futures, Implicits. All we need to make best use of yet keeping simplicity by not over engineering it. Apply only where they fit perfectly to solve that bit of problem or make other things relevant & elegant.
81
+
- For project specific types create plenty of type aliases. Create type class patterns etc.
82
+
- Use Zio & Cats-Effect separately because we are providing an option of Effect system. Use cats core as well - Semigroups, Monoids, Monads, Functors, Applicatives, Creative Type class patterns etc.
83
+
- We need to be creative, innovative & something like Wow such a thing can be achieved who'd have never thought about such things in Data Engineering Data Pipelines.
84
+
- No Over Engineering - Keep simplicity, scalable, understandable, adaptable yet creative - We need to be creative, innovative & something like Wow such a thing can be achieved who'd have never thought about such things in Data Engineering Data Pipelines.
85
+
- Code quality and best practices
86
+
- Potential bugs or issues
87
+
- Performance considerations
88
+
- Security concerns
89
+
- Test coverage
90
+
- Documentation clarity
91
+
- Overall maintainability
92
+
- Give revised code of each & every improvement from above points
93
+
- Give revised code of all suggest improvements
94
+
- Give revised improvements in project structure as well
9
95
10
96
# Prevent multiple Claude reviews for the same PR from running simultaneously
- Convention over Configuration with Functional Purity - This framework/project will be a true integrated system for Data Engineering & Data pipelines - which collectively works with other libraries, but pieces built specifically for each other to Data Engineering that work as one cohesive whole. Framework also must be unified abstraction layer. Framework makes best architectural decisions as well. Wherever applicable Data Engineers interact with APIs & exposed patterns/ layers not the underlying logic which libraries gives us to use.
37
-
- Best scala functional programming design patterns. Best practices of SOLID patterns, creational, structural & behavioral design patterns. Best scala functional programming design patterns - all best possible patterns that suits us & solve problems may be Kleisl etc.
38
-
- We are writing data pipelines. So say goodbye to config/metadata chaos! Let Scala’s type & effect systems co-author them with you. We want to show how we built a contract-first, pluggable platform using Giter8, Refined, Cats Effect, ZIO, Kyo & Caprese ( Kyo & Caprese experimental only) - delivering compile-time guarantees and fiber-safe execution.
39
-
- What if your data platform stopped relying on configuration-driven / metadata-driven and postmortems - and instead enforced correctness, traceability, and effect boundaries at compile time?
40
-
- We want to build a production-ready data pipeline archetype system in Scala. We want to use Giter8 templates to scaffold pipelines that are contract-driven, type-safe, effectful, and pluggable - all enforced through the Scala type system and effect libraries.
41
-
- 📦 Giter8 templates bootstrap consistent, compile-time safe projects • 🛡️ Refined types validate configuration before runtime • ✅ Cats ValidatedNel catches multi-rule violations in DQ checks • 🔌 Type classes enable pluggable validation and ingestion • ⚙️ ZIO Layers and Cats Effect offer fiber-safe orchestration • 🚀 Trait-based runners switch between Spark, Flink, and Kafka • 📊 Data Quality and custom rules enforce data contract quality at runtime • 🧠 Experimental: Kyo - tracks multiple effects via intersection types and Caprese - capture-checking tracks capabilities
42
-
- Use potential & power of Scala ecosystem but not over engineer it.
43
-
- All possible USPs of Scala - Monads, Pattern Matching, Generics, Variance, Type classes, Type class patterns, Self Types, Structural types, F-Bounded Polymorphism, Higher-Kinded Types, Reflections, Lazy Evals, Concurrency with Futures, Implicits. All we need to make best use of yet keeping simplicity by not over engineering it. Apply only where they fit perfectly to solve that bit of problem or make other things relevant & elegant.
44
-
- For project specific types create plenty of type aliases. Create type class patterns etc.
45
-
- Use Zio & Cats-Effect separately because we are providing an option of Effect system. Use cats core as well - Semigroups, Monoids, Monads, Functors, Applicatives, Creative Type class patterns etc.
46
-
- We need to be creative, innovative & something like Wow such a thing can be achieved who'd have never thought about such things in Data Engineering Data Pipelines.
47
-
- No Over Engineering - Keep simplicity, scalable, understandable, adaptable yet creative - We need to be creative, innovative & something like Wow such a thing can be achieved who'd have never thought about such things in Data Engineering Data Pipelines.
48
-
- Code quality and best practices
49
-
- Potential bugs or issues
50
-
- Performance considerations
51
-
- Security concerns
52
-
- Test coverage
53
-
- Documentation clarity
54
-
- Overall maintainability
55
-
- Give revised code of each & every improvement from above points
56
-
- Give revised code of all suggest improvements
57
-
- Give revised improvements in project structure as well
0 commit comments