diff --git a/25/11/1018.py b/25/11/1018.py
new file mode 100644
index 0000000..03f9ccc
--- /dev/null
+++ b/25/11/1018.py
@@ -0,0 +1,8 @@
+class Solution:
+    def prefixesDivBy5(self, nums: List[int]) -> List[bool]:
+        ans = []
+        num = 0
+        for v in nums:
+            num = ((num << 1) + v) % 5
+            ans.append(num == 0)
+        return ans
\ No newline at end of file
diff --git a/25/11/go/1018.go b/25/11/go/1018.go
index d0a7381..4ec61b6 100644
--- a/25/11/go/1018.go
+++ b/25/11/go/1018.go
@@ -1,5 +1,11 @@
 package D
 
 func prefixesDivBy5(nums []int) []bool {
-
+	ans := make([]bool, len(nums))
+	num := 0
+	for i, v := range nums {
+		num = ((num << 1) + v) % 5
+		ans[i] = num == 0
+	}
+	return ans
 }
diff --git a/AGENTS.md b/AGENTS.md
index dbe759b..1fc1345 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,7 +1,6 @@
 # Repository Guidelines
 
 ## Project Structure & Module Organization
-<<<<<<< HEAD
 Daily challenge archives (`23/04`, `24`, `25`) mirror the YYYY/MM problem drops from LeetCode; each subdirectory holds the source for a single prompt. Topic-driven folders (`dataStruct`, `dynamic planning`, `greed`, `else`, `key`, `we`) group reusable headers (`*.h`), Go entry points, and the occasional Python prototype. Shared helpers such as `tools/map.h` plus scratch runners (`main.c`, `main.go`) live in the repo root. Reproducible experiments sit in `test/`, alongside small driver programs (`test/test1.c`, `test/file.c`) and fixture files (`test/example.txt`). Place new assets beside the closest-matching module and keep helper code centralized in `tools/` so every language target can include it via `#include "tools/map.h"`.
 
 ## Build, Test, and Development Commands
@@ -17,33 +16,3 @@ Driver files inside `test/` document how to wire solutions into simple harnesses
 
 ## Commit & Pull Request Guidelines
 Recent commits use numeric messages (`717`, `251116`) that track the corresponding LeetCode id or date. Continue that convention: `<problem-id>[-optional-note]` keeps history scannable. Pull requests should mention the problem link, describe the approach/complexity, list any new tests, and attach screenshots only when visual assets change. Reference related issues or discussions to make triage easy.
-=======
-- Algorithms and data structures live under topic folders such as `dataStruct/`, `dynamic planning/`, `greed/`, `else/`, `key/`, and `we/`; each subfolder holds problem-specific source files.
-- Shared helpers (e.g., custom containers) sit in `tools/` and `tools.h`; include these with `-Itools` when compiling C/C++.
-- Scratch outputs should go to `build/`; `cmake-build-debug/` is IDE-generated and should stay untracked. Tests and small fixtures live in `test/` (see `test/example.txt`).
-- Paths with spaces (e.g., `dynamic planning/`) need quoting in shells: `g++ -std=c++17 "dynamic planning/xxx.cpp"`.
-
-## Build, Test, and Development Commands
-- C++17 compile (recommended by `.clangd`): `g++ -std=c++17 -O2 -Itools <source>.cpp -o build/<name>`; add `-Wall -Wextra` when iterating.
-- C compile: `gcc -O2 -Itools <source>.c -o build/<name>`.
-- Go quick run: `go run main.go`.
-- Example test build & run: `gcc -Itools test/test1.c -o build/test1 && ./build/test1`.
-- Keep binaries inside `build/` and out of version control.
-
-## Coding Style & Naming Conventions
-- Use 4-space indentation; prefer braces on new lines consistently across functions and control blocks.
-- Favor `snake_case` for C helpers and `CamelCase` types for C++ classes/structs; keep filenames descriptive (`heap_top_k.cpp`, `queue_with_two_stack.c`).
-- Rely on standard library containers/algorithms where possible; add brief comments only for non-obvious logic or tricky edge cases.
-- Run code through `clang-format` (C/C++) if available; keep Go files formatted via `gofmt`.
-
-## Testing Guidelines
-- Add minimal repros under `test/` named after the problem (`test_<id>.c`) and keep fixtures small.
-- When adding new logic, provide a tiny driver `main` or test function that exercises edge cases; show expected input/output in comments.
-- Prefer deterministic tests; avoid reading/writing outside the repo except for `build/`.
-
-## Commit & Pull Request Guidelines
-- Commit messages: short, imperative, and scoped (e.g., `add heap merge helper`, `fix queue pop bug`); avoid bundling unrelated fixes.
-- Before opening a PR, summarize the problem solved, approach taken, and key follow-up items; paste the commands you ran (build/test) with outcomes.
-- Do not commit generated binaries, IDE folders (`cmake-build-debug/`), or local artifacts.
-- Link related issues or references when applicable; include screenshots only if the change affects observable output.***
->>>>>>> origin/main