Forem: Nour Mohamed Amine

pi-reviewer Part 2: A Local Review UI That Puts You in Control

Nour Mohamed Amine — Tue, 17 Mar 2026 23:20:20 +0000

In Part 1 I talked about why AI code review falls flat without project context, and how pi-reviewer fixes that by feeding your conventions to the agent before it reads a single line of diff.

This part is about what happens after the review runs.

The problem with "just post a comment"

Most AI review tools finish the job by dumping everything into a GitHub PR comment. You end up with a wall of findings, some useful, some not, and no real way to act on them beyond reading through and manually deciding what to do with each one.

pi-reviewer works differently. After the agent finishes, a browser UI opens where you go through every finding and decide what to do with it before anything gets sent anywhere.

The `--ui` flag

/review --ui
/review --ssh --ui

Once the review is done, a local server starts and your browser opens automatically. No extra setup, no cloud, nothing to configure. The server shuts down as soon as you take an action or close the tab.

What you are looking at

Sidebar is a GitHub-style file tree on the left. Files are grouped by folder, you can collapse and expand folders, and each one shows a comment count badge that adds up from its children. Click a file and the diff jumps to it with a blue border so you always know where you are. Click anywhere else and it deselects.

Syntax highlighting colorizes the diff by language. TypeScript, Python, Go, Rust, Java and more are all supported, using the same token colors as GitHub. The red and green diff backgrounds stay intact, the syntax colors just sit on top.

Split and unified toggle lets you switch between side-by-side and single-column views whenever you want. It applies to all files at once.

Going through the findings

Every comment needs a decision before you can do anything. You have three options:

✅ Accept - include this finding when sending back to the agent
❌ Reject - skip it, do not send it
💬 Discuss - accept it and add your own note that gets sent alongside it

The header shows how many you have decided so far. Save, Send, and Save & Send stay greyed out until everything has a decision. No accidental sends.

As you go through them the cards update visually. Accepted ones get a green tint, rejected ones fade. There is a jump button that skips straight to the next undecided comment so you do not have to scroll around.

What you can do at the end

Once every comment has a decision:

Save writes the full review and your decisions to pi-review.md, no agent call
Send injects the accepted and discussed findings into the agent as a follow-up turn
Save & Send does both

Send and Save & Send only activate if you accepted or discussed at least one finding. There is no point starting an agent turn with nothing to say.

SSH mode

Working on a remote machine? Just add --ssh:

/review --ssh --ui

The agent fetches the diff over SSH, runs the review remotely, and sends the result back. The UI opens locally with the full diff and findings. No second SSH trip needed.

Theme

The dark and light toggle remembers your choice across reviews using ~/.pi/pi-reviewer/config.json. Since the local server picks a random port every time, browser storage would reset on every review, so the preference lives server-side instead.

Try it

pi install https://github.com/zeflq/pi-reviewer

Then inside the pi TUI:

/review --ui

Drop an AGENTS.md or CLAUDE.md at your project root to give the agent context about your conventions. Add a REVIEW.md if you want to be specific about what to flag and what to skip.

The full roadmap is in TODO.md.

pi-reviewer is open source at github.com/zeflq/pi-reviewer

Why AI Code Review Fails Without Project Context

Nour Mohamed Amine — Wed, 11 Mar 2026 04:57:06 +0000

Every AI code review starts the same way.

The bot opens your PR. It scans the diff. It flags a missing try/catch, suggests a more descriptive variable name, and notes that you could memoize that function for performance.

All technically correct. None of it useful.

Because it doesn't know that fetchUser is an intentional naming convention your team enforces. That error handling is delegated to a global boundary. That performance isn't the concern here — correctness is. The bot doesn't know your project. It never did.

This isn't a model problem. It's a context problem.

The fix: context-aware review

That's what pi-reviewer is built around — a GitHub Action and pi TUI extension that brings your project conventions into every review.

Before the agent sees a single line of diff, it reads:

AGENTS.md or CLAUDE.md — your general project conventions: naming rules, architecture decisions, patterns to follow
REVIEW.md — review-specific rules: what to always flag, what to explicitly skip

Markdown links in those files are followed recursively. If your AGENTS.md links to docs/api-conventions.md, that file gets inlined too. The agent sees the full picture, not just the summary.

# Review Guidelines

## Always flag
- `fetch` calls missing `res.ok` check before `.json()`
- API endpoints not versioned under `/api/v1/`
- Functions named `getData`, `doStuff`, or other generic names

## Skip
- Formatting-only changes
- Changes inside `pi-review.md`

That's a REVIEW.md. The agent now knows what your team cares about — not what a generic model thinks good code looks like.

What a context-aware review looks like

Here's what changed after adding project context.

Before: the agent flagged a missing type annotation on an internal helper. Suggested renaming a variable. Noted a console.log left in.

After: it caught an unversioned API endpoint added in the same PR. Flagged a fetch call missing the res.ok check — exactly the rule in REVIEW.md. Skipped the formatting-only change in the generated file, as instructed.

Same model. Same diff. Completely different review.

Severity you control

Not every finding deserves equal weight. pi-reviewer lets you filter by severity — so you can focus on what matters.

- uses: zeflq/pi-reviewer@main
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    pi-api-key: ${{ secrets.PI_API_KEY }}
    min-severity: warn

Set min-severity: warn and the agent skips INFO-level suggestions entirely — both in what it generates and in what gets posted to the PR. You can also trigger a manual review from the GitHub Actions UI and choose the severity level on the fly.

Three tiers: 🔴 CRITICAL for bugs and security issues, 🟡 WARN for logic and type errors, 🔵 INFO for style and suggestions.

Model-agnostic, built on pi mono

pi-reviewer runs on pi — a terminal-based coding agent that sits on top of the pi mono platform. One PI_API_KEY works across all supported models and providers. You pick the model, pi routes the request.

That means you're not locked into a single provider. Swap models without touching your workflow. The review logic stays the same.

It also works over SSH. If your project lives on a remote machine, --ssh mode lets the agent fetch the diff and read your conventions directly on the remote — no local copy needed.

How it compares to Claude Code PR Review

Anthropic recently shipped Code Review — a managed PR review service built into Claude Code. It reads CLAUDE.md and REVIEW.md, runs multiple specialized agents against your full codebase in parallel, and posts inline findings with severity tags. It's genuinely impressive.

But it comes with constraints that may not fit every team.

It's a managed service — runs on Anthropic's infrastructure, requires a GitHub App installation, available on Teams and Enterprise plans only. Reviews average $15–25 each. It's Claude-only, and you don't control where it runs.

pi-reviewer runs in your own CI, costs what your token usage costs, works with any model through pi mono, and needs nothing more than a secret and a workflow file. No GitHub App. No admin approval flow.

And if you want to review locally before you push — without opening a PR at all — the pi TUI extension gives you /review in your terminal.

Both tools read your CLAUDE.md and REVIEW.md. The difference is where they run, what they cost, and how much control you keep.

Set it up once, forget about it

npx github:zeflq/pi-reviewer init

That generates a workflow file. Add your PI_API_KEY secret. Every PR from that point on gets a review that knows your project.

The context files — AGENTS.md, REVIEW.md — live in your repo. Version-controlled, team-editable, evolve with the project. The better you document your conventions, the better the reviews get.

The shift

The insight isn't that AI can review code. It's that AI review without project context is just another linter with better prose.

The review that matters is the one that knows why your codebase looks the way it does — and checks the diff against that, not against some generic idea of good software.

That's the layer that's been missing.

github.com/zeflq/pi-reviewer

Context is everything. Diff without it is just noise.

The Missing Layer: Why Your Coding Agent Needs to Know Your Decisions

Nour Mohamed Amine — Sun, 01 Mar 2026 15:49:29 +0000

Every session with a coding agent starts the same way.

You open a new conversation, and before you can get anything done, you spend 10-20 minutes re-explaining the project. Clean architecture. No Prisma imports in use cases. Domain layer here, infrastructure there. We use this pattern for repositories. Oh, and we decided last week to enforce 85% test coverage on all use cases.

The agent nods along — then next session, you do it again.

This isn't a model problem. Claude, GPT, whatever — they're all capable. The problem is context. Specifically, the decisions your team has already made. The agent doesn't know them unless you tell it. Every. Single. Time.

Decisions are the missing layer

When a senior dev joins a project, they don't just read the code. They absorb the why behind it — the constraints, the trade-offs, the rules the team agreed on. That's what makes them productive fast.

A coding agent only gets the code. The decisions live in someone's head, in a Slack thread from 3 months ago, or in a doc nobody reads.

That's the gap pi-project-memory fills.

What it does

pi-project-memory is an extension for pi, a terminal-based coding agent. It gives the agent a persistent, project-local memory — stored as plain markdown files in .pi/project-memory/.

When you make a decision — architecture, tooling, conventions — the extension captures it. Either automatically from your prompt, or with a quick /memory remember. It classifies it: decision, pattern, preference, or gotcha. Next session, it's injected into context before the agent starts. No re-explaining.

Four files. No database. No cloud sync. Just markdown you can read, edit, and commit.

.pi/project-memory/
├── MEMORY.md        ← injected every session
├── decisions.md
├── patterns.md
├── preferences.md
└── gotchas.md

The moment it clicked

A teammate started using pi on our project for the first time. A few minutes in, they messaged: "how does the agent know all this stuff about our architecture?"

It had read the memory files.

We hadn't written an onboarding doc. We hadn't sent them a Notion page or a Slack thread. The agent just... knew — because decisions made across dozens of sessions had been captured as they happened.

That's the shift that surprised us most: the agent became a participant in the project, not just a tool. It doesn't only read from the memory files. It writes to them. When it encounters a decision worth keeping, it proposes saving it. Over time, it builds up a shared understanding of the project alongside the team.

Auto-capture, not manual bookkeeping

The extension works in the background. When you type something that looks like a decision — "we will use clean architecture", "never import Prisma directly in use cases", "all use cases must be tested, 85% coverage" — it classifies it and asks if you want to save it.

High-confidence captures save silently. Mid-confidence ones surface a quick confirmation. You stay in flow.

It also learns from what the agent discovers. Ask it to scan your feature folder structure? If the response contains a structured template, the extension proposes saving that too — so future features follow the same blueprint.

What's next

The extension is open source and early. The next big piece is /memory export — syncing your captured decisions to CLAUDE.md, .cursor/rules, or AGENTS.md, so the memory travels beyond pi sessions and becomes part of the project for every tool and every teammate.

If you're building with pi and tired of re-explaining your architecture every session — try it. And if you want to contribute, the repo is open.

github.com/zeflq/pi-project-memory

Built while building. Decisions captured along the way.

Stop Fighting Context Limits: How Multi-Agent Systems Solved My Development Chaos(Part 1)

Nour Mohamed Amine — Sun, 28 Dec 2025 01:28:26 +0000

Part 1 of 3 | Reading Time: 10 minutes

TL;DR: Single AI agents struggle with context overload and inconsistent quality. Multi-agent systems solve this by splitting work across specialized agents with clear boundaries and explicit handoff contracts. This post explains why and introduces the architecture.

The Problem with Single-Agent Development

I've watched countless development teams hit the same wall with AI-assisted development. They start excited, using Claude or GPT to build features. Then reality sets in.

The Single-Agent Bottleneck

When using a single AI agent for development:

❌ Context overload: The agent tries to handle UX + frontend + backend + database all at once
❌ Inconsistent quality: No specialization leads to generic, one-size-fits-all solutions
❌ Poor integration: No clear handoff points between layers
❌ Architectural drift: No governance over structural decisions
❌ Knowledge dilution: Expert-level code in one area, beginner-level in another

Real example: Ask a single agent to "build a user profile page" and you get:

Generic React components (not following your design system)
API endpoints that don't match your backend patterns
Database queries that bypass your repository layer
Security checks that are inconsistent with your auth strategy

The agent isn't bad—it's just doing too much.

The Multi-Agent Solution

What if instead of one generalist, you had a team of specialists?

The Core Insight

Good software teams have specialists. You don't ask your UX designer to write database migrations. You don't ask your backend engineer to design user flows.

Multi-agent systems apply the same principle to AI development.

What You Get

A well-designed multi-agent system provides:

✅ Clear separation of concerns: Each agent is a domain expert
✅ Consistent quality: Specialists produce better work than generalists
✅ Explicit contracts: Handoffs force clarity at boundaries
✅ Architectural governance: A coordinating agent enforces coherence
✅ Scalable complexity: Add agents as your needs grow

The Three-Layer Architecture

Here's the complete model:

┌─────────────────────────────────────────────────────┐
│  Layer 1: Orchestration (brain-agent)               │
│  • Slices work into small chunks                    │
│  • Routes to appropriate specialists                │
│  • Enforces architectural decisions (ADRs)          │
│  • Validates integration between agents             │
└─────────────────────────────────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────────┐
│  Layer 2: Specialist Agents                         │
│  • ux-agent: User experience & interaction flows    │
│  • react-agent: UI components & client state        │
│  • next-agent: Routing & server/client boundaries   │
│  • backend-agent: APIs, validation & persistence    │
│  • [Your custom agents as needed...]                │
└─────────────────────────────────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────────┐
│  Layer 3: Shared Foundation                         │
│  • conventions.md: Generic dev principles (KISS)    │
│  • project-rules/: YOUR architecture patterns       │
│  • ADR registry: Documented decisions               │
└─────────────────────────────────────────────────────┘

Layer 1: The Brain Agent (Orchestrator)

Think of this as your tech lead. It:

Takes user requests and breaks them into small, shippable slices (1-2 hours each)
Routes each slice to the right specialist
Enforces architectural decisions through ADRs (Architecture Decision Records)
Ensures all the pieces integrate properly

Example workflow:

User: "Build a user profile page"

brain-agent:
  SLC-001 → ux-agent: Design profile layout and states
  SLC-002 → react-agent: Build ProfilePage component
  SLC-003 → backend-agent: Create GET /api/users/:id endpoint
  SLC-004 → next-agent: Wire route and data fetching

Layer 2: Specialist Agents

Each specialist owns a specific domain:

ux-agent

Owns: User flows, wireframes, interaction patterns, accessibility
Delivers: UI specs with states, variants, and acceptance criteria

react-agent

Owns: React components, hooks, UI state management, forms
Delivers: Clean, warning-free React code following modern patterns

next-agent (or framework-specific agent)

Owns: Routing, layouts, server/client boundaries, metadata
Delivers: Route scaffolding and integration wiring

backend-agent

Owns: API design, DTOs, persistence, validation, auth boundaries
Delivers: Endpoints, database changes, error handling

You can add more: testing-agent, deployment-agent, data-agent, etc.

Layer 3: Shared Foundation

This is where consistency lives:

conventions.md - Generic principles that work anywhere:

KISS (Keep It Simple)
SOLID principles
YAGNI (You Aren't Gonna Need It)
Small, incremental work
Explicit contracts over assumptions

project-rules/ - YOUR specific patterns:

01-architecture.md: Your chosen architecture (feature-first? clean architecture?)
02-tech-stack.md: Your frameworks, libraries, naming conventions
03-security.md: Your auth strategy, multi-tenancy rules
etc.

ADR registry - Documented decisions:

Why did we choose this pattern?
What alternatives did we consider?
What are the trade-offs?

Key Principles

1. Feature Slicing, Not Layer Slicing

Bad (layer slicing):

Week 1: Build all database models
Week 2: Build all API endpoints
Week 3: Build all UI components
Week 4: Integration (surprise! nothing works together)

Good (feature slicing):

SLC-001 (2 hours): Complete user login
  - Model + API + UI + Integration = ✅ Working feature

SLC-002 (2 hours): Complete profile view
  - Model + API + UI + Integration = ✅ Working feature

Each slice is:

XS: 1-2 hours (single component/endpoint)
S: 0.5-1 day (full feature with integration)
Fully integrated or explicitly marked as incomplete

2. Explicit Contracts Over Implicit Assumptions

Every handoff between agents has a contract:

### HANDOFF
From: backend-agent
To: react-agent
Slice-ID: SLC-042

Public contract:
- Endpoint: POST /api/users
- Request: { name: string, email: string }
- Response: { id: string, name: string, email: string }
- Errors: 400 (validation), 409 (duplicate), 500 (server)

Edge cases handled:
- Duplicate email → 409 with message
- Invalid email format → 400 with field errors
- Missing required field → 400 with field errors

How to test:
1. POST valid data → expect 201
2. POST duplicate email → expect 409
3. POST invalid email → expect 400

No assumptions. No "I think it returns...". Crystal clear.

3. Governance Without Bureaucracy

The Problem: Too much governance = bureaucracy, too little = chaos

The Solution: ADRs (Architecture Decision Records) only for structural decisions

Requires ADR (blocks work until approved):

Changes affecting >2 features
New architectural patterns
Changes to shared contracts
Security implications

No ADR needed (agent proceeds):

Local implementation details
Single-feature changes
Following existing patterns

This keeps you moving fast while preventing architectural disasters.

Why This Works

Real-World Comparison

Before (single agent):

Me: "Add user authentication"

Agent:
  *Generates generic JWT setup*
  *Creates basic auth middleware*
  *Makes questionable security choices*
  *No integration with existing patterns*

Result: 6 hours debugging, 3 hours refactoring

After (multi-agent):

Me: "Add user authentication"

brain-agent: *Checks for architectural decision needed*
  → "This affects multiple features. Creating ADR for approval."

ADR-003: Authentication Strategy
  - NextAuth.js v5 with session strategy
  - Middleware for route protection
  - Follows existing patterns in rules/03-security.md

User: *Approves*

brain-agent:
  SLC-010 → backend-agent: Set up NextAuth with providers
  SLC-011 → next-agent: Add auth middleware to routes
  SLC-012 → react-agent: Create login/logout UI
  SLC-013 → backend-agent: Add auth to protected endpoints

Result: Each slice takes 1-2 hours, fully integrated, follows patterns

The Benefits

Quality: Each agent is an expert in their domain
Consistency: All agents follow the same conventions + your project rules
Integration: Explicit handoffs prevent "works on my machine" moments
Scalability: Add agents as complexity grows
Maintainability: Clear boundaries make code easier to understand
Auditability: Slice IDs and handoffs create a paper trail

Is This For You?

This approach works best when:

✅ You're building a non-trivial application (not just a landing page)
✅ You have architectural patterns you want to enforce
✅ You need consistency across your codebase
✅ Multiple people (or AI agents) are contributing
✅ You want quality that matches your standards

This might be overkill if:

❌ You're building a simple prototype
❌ You have no architectural preferences
❌ You're okay with inconsistent patterns
❌ Speed > quality for your use case

What's Next

In Part 2, I'll show you exactly how to build this system:

File structure and organization
How to write agent specifications
Creating your brain-agent
Setting up conventions and project rules
Real implementation examples

Coming soon: Part 2: Building Your First Multi-Agent System

Try It Yourself

Want to experiment with this concept?

5-Minute Exercise:

Pick a feature in your current project
Write down which agents would own which parts
Define the contract between them

Example:

Feature: User profile edit

ux-agent:
  - Profile edit form states (idle, editing, saving, error)

react-agent:
  - ProfileEditForm component with validation

backend-agent:
  - PATCH /api/users/:id endpoint
  - Validation logic

Contract:
  - Request: { name?: string, bio?: string }
  - Response: Updated user object
  - Errors: 400 (validation), 401 (unauthorized), 404 (not found)

Notice how much clearer the boundaries become?

About This Series:

Part 1: Why Multi-Agent Systems (you are here)
Part 2: Building Your First Multi-Agent System (coming soon)
Part 3: Production Best Practices & Pitfalls (coming soon)

GitHub Template: [https://github.com/zeflq/multi-agent-system-framework]

Questions or thoughts? Drop them in the comments. I'd love to hear about your experiences with AI-assisted development.

Last Updated: 2025-12-28

3 Game Changing Ways React’s New `` Component Will Change How You Code

Nour Mohamed Amine — Sun, 07 Dec 2025 17:10:26 +0000

If you’ve been building React apps for a while, you know the classic pattern by heart:

isVisible && <MyComponent />

It’s simple, it works… and it comes with a really annoying downside: every time the component hides, its entire state gets wiped out.
Counters reset. Inputs lose their text. Cached data disappears.
We’ve all just accepted this as “how React works.”

Well, not anymore.

React’s new <Activity> component finally fixes this pain point but what most developers don’t realize is that preserving state is just the beginning. <Activity> quietly unlocks two extremely powerful performance techniques that weren’t possible before.

Let’s break down the three ways this new primitive is about to reshape the way you think about React starting with the obvious win and ending with two next-level optimizations that will make you look like a performance wizard.

1. Stop Losing Component State Every Time You Toggle Visibility

For years, hiding a component meant unmounting it. And unmounting meant losing everything inside it.

Your form? ➡️ Blank again.

Your counter? ➡️ Back to zero.

Your fetched data? ➡️ See you later.

<Activity> changes that. It lets you control visibility without unmounting the component.

import { Activity } from 'react';

function MyTogglableComponent({ isVisible }) {
  const mode = isVisible ? 'visible' : 'hidden';

  return (
    <Activity mode={mode}>
      <Counter />
    </Activity>
  );
}

When mode="hidden", your component:

stays mounted
keeps all its internal state
keeps user input
remembers everything

But here’s the clever part: side effects pause.

So while your component is “sleeping,” React won’t rerun effects or keep subscriptions active. When you make it visible again, it wakes up exactly where it left off.

This alone solves a decade old annoyance. But the next two features are where things get really interesting.

2. Preload Data Before Your User Even Asks For It

Think about a modal, a tab, or a panel that fetches data using Suspense. Normally, the fetch only begins when the user opens it. And then… they wait.

Now imagine wrapping that same component in an <Activity mode="hidden"> from the start.

What happens?

React goes:

“Okay, let me finish the important stuff first.

Then, when I have some idle time, I’ll go ahead and pre-render this hidden component.”

And during that pre-render?

Your data fetching kicks off early.

By the time the user clicks the button to reveal it, the data is often already loaded.

No spinner.

No delay.

Just instant UI.

This is a massive UX upgrade for anything you expect the user will eventually open:

modals
secondary tabs
expandable panels
sidebar content

You’re basically time traveling your loading state.

3. Make Your App Feel Faster With Smarter Hydration

If you’re building with something like Next.js, hydration is a big deal. It’s what makes your server rendered HTML come alive in the browser.

But hydration has a problem:

One slow component can block your whole page from becoming interactive.

For example, a heavy comments section at the bottom of a blog post can delay your entire page even the text at the top that should be usable immediately.

Wrapping low priority sections in <Activity> changes the game.

<Activity>
  <Comments />
</Activity>

Even without any props, this tells React:

“Hey, treat this as a separate hydration task.

Focus on the important stuff first.”

The result:

Your main UI becomes interactive much faster
Lower priority content hydrates later, during browser idle time
Users feel like the page loads instantly, even if a big component is still hydrating in the background

Profilers show two distinct hydration waves:

primary content first, secondary content later.

That’s a huge win for perceived performance.

Final Thoughts: `<Activity>` Is More Than a Component,It’s a New Rendering Primitive

<Activity> isn’t just a nicer way of hiding components.

It gives you fine grained control over:

when components mount
when they hydrate
when they fetch data
when they render
and when they pause side effects

State preservation is the obvious benefit but the real power comes from the performance patterns it enables.

So take a look at your own app:

Where are you re-fetching data unnecessarily?
Where could users benefit from instant modal loads?
What heavy components slow down hydration?

Because with a little strategic wrapping, <Activity> might be the biggest performance upgrade your React app gets this year.

How I Cut Docker Build Time in Half Using Savepoints — And Built a CLI Tool in Go

Nour Mohamed Amine — Wed, 30 Apr 2025 01:50:56 +0000

“Do I really have to rebuild from scratch… again?”

That was the thought that finally pushed me over the edge.

🚨 The Problem: Rebuilding the Unchanged

If you’ve ever worked with a long Dockerfile in CI/CD, you know this pain:

You touch a line at the bottom
Docker cache misses (because the base layers are invalidated)
CI rebuilds everything — apt update, npm ci, go mod download... the works

⏱️ Time wasted.
💰 Resources burned.
⚠️ Productivity gone.

Caching helps, but it's finicky across CI environments and can break easily.

What I wanted was intentional, semantic checkpoints in my Dockerfile.

💡 The Idea: Savepoints as Named Build Layers

So I built Dockpoint — a CLI that turns your Dockerfile into an intelligent, incrementally buildable script.

With Dockpoint, you annotate your Dockerfile like this:

# savepoint: base
FROM node:20

# savepoint: deps
COPY package*.json ./
RUN npm ci

# savepoint: app
COPY . .
CMD ["node", "index.js"]

Each # savepoint: name becomes a named layer that Dockpoint can build, tag, reuse, or skip in CI pipelines.

🔧 Want to build only up to the `deps` step?

dockpoint build-savepoint deps -t docker.io/your/app:deps

📦 Want to build all steps and push them as incremental images?

dockpoint build-savepoint -t docker.io/your/app:1.0.0 --push

✨ The Magic: Content-Based Tagging (Using Hashing)

Dockpoint doesn’t rely on Docker’s fragile cache alone.

It hashes the Dockerfile lines used for each savepoint and creates a tag like:

docker.io/your/app:deps-14f95d20

This means:

If your deps block changes → new tag
If it hasn’t changed → Dockpoint skips building and reuses the layer

✅ Your CI/CD becomes fast, predictable, and cache-safe

🛠️ The Architecture (A Clean Go CLI)

Yes — I built this in Go (my first Go project).

Dockpoint is written using:

🧼 Clean Architecture (application, domain, infrastructure)
🐍 Cobra for CLI
📦 GoReleaser for packaging (multi-arch, Homebrew-ready)
🤖 GitHub Actions for CI
📊 Codecov for coverage tracking

🚀 One Command. Smart Layers.

Dockpoint gives you a smarter docker build:

dockpoint build-savepoint app -t docker.io/you/app:1.0.0

Tags each savepoint with its hash
Pushes final image cleanly
Reuses existing layers when possible
Speeds up your pipeline

🎯 Why I Built This (And Why You Might Need It)

This started with a single itch:

“Why are we rebuilding what didn’t change?”

Now Dockpoint has:

✅ Deterministic layer tagging
🔍 Savepoint validation
🌐 Cross-platform support
🧪 A clean, tested CLI written from scratch

If you’re tired of Dockerfiles being dumb scripts with no structure,

Dockpoint gives you structure — without changing Docker at all.

📥 Try Dockpoint

Check it out:

GitHub: https://github.com/zeflq/dockpoint

🧪 Install

# Homebrew (coming soon)
brew install zeflq/tap/dockpoint

# Or use GitHub Releases
curl -Lo dockpoint https://github.com/zeflq/dockpoint/releases/latest/download/dockpoint_linux_amd64.tar.gz
tar -xzf dockpoint_linux_amd64.tar.gz
chmod +x dockpoint
./dockpoint --help

❤️ Final Thought

This is my first Go project — and it made me fall in love with the language.

It’s fast, easy to compile, cross-platform, and perfect for tools like this.

If Dockpoint saves you even one build cycle, it’s worth it.

And if you want to help me polish v1.1 — PRs are welcome!