diff --git a/rules/S8213/go/metadata.json b/rules/S8213/go/metadata.json
new file mode 100644
index 00000000000..220d24a72ad
--- /dev/null
+++ b/rules/S8213/go/metadata.json
@@ -0,0 +1,27 @@
+{
+  "title": "Package imports should be consistent and avoid redundancy",
+  "type": "CODE_SMELL",
+  "status": "ready",
+  "remediation": {
+    "func": "Constant/Issue",
+    "constantCost": "2 min"
+  },
+  "tags": [
+    "convention",
+    "imports"
+  ],
+  "defaultSeverity": "Minor",
+  "ruleSpecification": "RSPEC-8213",
+  "sqKey": "S8213",
+  "scope": "All",
+  "defaultQualityProfiles": [
+    "Sonar way"
+  ],
+  "quickfix": "unknown",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "CONVENTIONAL"
+  }
+}
diff --git a/rules/S8213/go/rule.adoc b/rules/S8213/go/rule.adoc
new file mode 100644
index 00000000000..659eb75af6a
--- /dev/null
+++ b/rules/S8213/go/rule.adoc
@@ -0,0 +1,55 @@
+This is an issue when the same Go package is imported multiple times (both directly and with an alias) or when code uses the full package name instead of a defined alias.
+
+== Why is this an issue?
+
+Importing the same package multiple times creates redundancy and confusion about which import to use. When a package is imported both with and without an alias, it's unclear which approach developers should follow throughout the codebase.
+
+Inconsistent usage of import aliases further compounds this problem. If an alias is defined for a package, using the full package name in some places and the alias in others makes the code harder to read and maintain.
+
+This inconsistency can lead to:
+
+* Confusion about which import style to use
+* Potential naming conflicts if the same package is referenced differently
+* Reduced code readability and maintainability
+* Unnecessary cognitive load when reading the code
+
+Go's import system is designed to be explicit and clear. Following consistent import patterns helps maintain this clarity.
+
+=== What is the potential impact?
+
+This issue primarily affects code maintainability and readability. While not a security concern, inconsistent imports can lead to developer confusion, increased cognitive load when reading code, and potential maintenance issues when refactoring or updating dependencies.
+
+== How to fix it
+
+Remove redundant imports and keep only the aliased version when a package is imported both directly and with an alias.
+
+=== Code examples
+
+==== Noncompliant code example
+
+[source,go,diff-id=1,diff-type=noncompliant]
+----
+import (
+    "cloud.google.com/go/pubsub/v2"
+    "cloud.google.com/go/pubsub/v2/apiv1/pubsubpb" // Noncompliant
+    pb "cloud.google.com/go/pubsub/v2/apiv1/pubsubpb"
+)
+----
+
+==== Compliant solution
+
+[source,go,diff-id=1,diff-type=compliant]
+----
+import (
+    "cloud.google.com/go/pubsub/v2"
+    pb "cloud.google.com/go/pubsub/v2/apiv1/pubsubpb"
+)
+----
+
+== Resources
+
+=== Documentation
+
+ * Go Language Specification - Import declarations - https://golang.org/ref/spec#Import_declarations[Official Go specification for import declarations and package aliases]
+
+ * Effective Go - Package names - https://golang.org/doc/effective_go#package-names[Best practices for Go package naming and imports]
diff --git a/rules/S8213/metadata.json b/rules/S8213/metadata.json
new file mode 100644
index 00000000000..2c63c085104
--- /dev/null
+++ b/rules/S8213/metadata.json
@@ -0,0 +1,2 @@
+{
+}