DEV Community: Farooq Shabbir

I Built a 24/7 Freelance Operations Agent with OpenClaw — It Runs My Business While I Sleep

Farooq Shabbir — Thu, 23 Apr 2026 11:44:49 +0000

No Python. No Node. Three skill files, one Lobster workflow, and my consultancy now runs on autopilot.

What I Built

A fully autonomous freelance operations agent I call Claw-Ops that handles the three biggest time drains in running a dev consultancy:

Morning dev briefing — PR triage from GitHub, action items pulled from Slack, delivered to Telegram at 8AM
Client status drafting — every Friday, reads merged PRs + closed Linear tickets, writes the weekly update email, sends me the draft to approve with one tap
Inbox zero on follow-ups — detects unanswered client emails older than 48 hours, drafts a polite follow-up, asks me on Telegram whether to send it

Before this: ~9 hours a week on context-switching, manual status writing, and email chasing.
After: I review a Telegram message in the morning and say yes or no.

The Stack

OpenClaw (gateway running on a Mac Mini, always on)
Claude via Anthropic API (the brain)
Telegram (my interface — DMs and one-tap approvals)
Three custom skills + one Lobster workflow (no external services beyond what I already used)

Zero new subscriptions. Zero new dashboards. Everything surfaces in the app I already have open: Telegram.

Skill 1: `pr-morning-digest`

# pr-morning-digest

When triggered (or on schedule), check all GitHub repos accessible via the gh CLI.

Find pull requests that match ANY of these:
- Open more than 24 hours with no review activity
- CI checks failing
- Labeled "urgent" or "blocking"

For each match, output:
- Repo name
- PR title and number
- Current status (awaiting review / CI failing / etc.)
- Direct link

Format as a clean priority list, most urgent first.
Send the result to Telegram.
If nothing matches, send: "All clear — no PRs need attention."

Tools: shell (gh CLI)

Skill 2: `slack-action-extractor`

# slack-action-extractor

When triggered, read the last 100 messages from the #engineering Slack channel
using the Slack CLI or API.

Identify messages that:
- Mention my name or @handle
- Contain task language ("can you", "please", "need you to", "by EOD", "by Friday")
- Are from the last 24 hours

For each identified message:
- Extract the action item in one sentence
- Note who asked and when
- Note any deadline mentioned (or flag as "no deadline specified")

Append results to ~/tasks.md under today's date heading.
If new items were found, send a Telegram summary.
If nothing new, do nothing.

Tools: shell (Slack CLI), file write

Skill 3: `client-status-drafter`

# client-status-drafter

Every Friday at 4PM, do the following:

1. Run `gh pr list --state merged --limit 20` to get this week's merged PRs
2. Read closed Linear tickets from the past 7 days via the Linear CLI
3. From memory, recall the client name and their current project context
4. Draft a plain-English weekly status email:
   - 2-3 sentences on what shipped
   - 1 sentence on what's in progress
   - 1 sentence on anything that needs client input or decision
   - Professional but warm tone — no bullet points, just prose
5. Save draft to ~/drafts/status-{YYYY-MM-DD}.md
6. Send me the draft on Telegram with two options:
   - Reply "send" to send it via Gmail immediately
   - Reply "edit [your changes]" to revise before sending

Tools: shell (gh, linear, gmail CLI), file write, memory read

The Lobster Workflow That Chains Everything

name: claw-ops-daily
schedule: "0 8 * * 1-5"

steps:
  - id: prs
    skill: pr-morning-digest
    output: pr_summary

  - id: slack
    skill: slack-action-extractor
    output: action_items

  - id: brief
    action: telegram_send
    message: |
      Good morning. Here's your briefing:

      **PRs needing attention:**
      {{pr_summary}}

      **New action items from Slack:**
      {{action_items}}

  - id: status_draft
    skill: client-status-drafter
    condition: "day_of_week == friday"
    input:
      context: "{{pr_summary}} {{action_items}}"

The Setup (Reproducible in Under an Hour)

Step 1: Install OpenClaw

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw config set anthropic_api_key=YOUR_KEY

Step 2: Create the skill files

mkdir -p ~/.openclaw/skills
nano ~/.openclaw/skills/pr-morning-digest.md
nano ~/.openclaw/skills/slack-action-extractor.md
nano ~/.openclaw/skills/client-status-drafter.md

Step 3: Create the Lobster workflow

nano ~/.openclaw/workflows/claw-ops-daily.yaml

Step 4: Connect Telegram

openclaw connect telegram
# Follow the QR code flow — takes 90 seconds

Step 5: Start the gateway and test

openclaw start
# Message your Telegram bot: "Run claw-ops-daily now"

Total time from zero to running: 47 minutes.

What Actually Happens in Production

Monday 8:02 AM — Telegram:

Good morning. Here's your briefing:

PRs needing attention:
• [URGENT] backend/api — PR #312 "Fix auth token refresh" — CI failing, open 31hrs
• frontend/dashboard — PR #308 "New onboarding flow" — awaiting review, open 26hrs

New action items from Slack:
• Sarah asked you to look at the deployment config by EOD today
• No deadline: Jordan mentioned the staging DB needs a migration check

Friday 4:03 PM — Telegram:

Draft ready: ~/drafts/status-2026-04-25.md

Preview:
"This week we shipped the auth token refresh fix and the new onboarding
flow, both now live in production. We're currently working through the
staging database migration — expect that wrapped by Tuesday. One thing
we'd love your input on: the API rate limit thresholds for the premium
tier. Happy to jump on a quick call Monday if useful."

Reply "send" to send via Gmail or "edit [changes]" to revise.

I reply "send." Done.

The Result

Task	Before	After
Morning PR triage	25 min manual GitHub scanning	45 sec reading Telegram
Slack action item harvesting	~40 min/day of tab switching	Automated, instant summary
Weekly client status	90 min writing + context gathering	30 sec reviewing + one-tap send
Email follow-up chasing	45 min/week	Zero — agent handles it
Total	~9 hrs/week	~20 min/week

Honest Notes

What worked immediately: The PR digest and Telegram integration were flawless out of the box.

What needed iteration: The client status email tone took two rounds of refinement in agents.md. Adding "Write like a human who has a strong working relationship with this client. Warm, direct, no corporate filler." to the agent personality fixed it completely.

Security note: I run with --sandbox disabled because I need full shell access for the gh and linear CLIs. This is a deliberate choice with understood risk. Start sandboxed, then selectively enable only the tools each skill genuinely needs.

Fork It

All three skill files and the Lobster workflow are in this GitHub Repository:
https://github.com/FarooqShabbir/claw-ops

The entire point of the skills format is that you're not copying code — you're copying intent. Edit the instructions to match your stack, and the agent adapts automatically.

Submitted for the OpenClaw Writing Challenge on DEV — OpenClaw in Action prompt.

OpenClaw Isn't an AI Assistant. It's a New Operating System. Here's the Proof.

Farooq Shabbir — Thu, 23 Apr 2026 11:29:51 +0000

310,000 GitHub stars. A viral car negotiation. A legal filing written while someone slept. None of that is the real story.

Let me make a claim that sounds insane and then prove it:

OpenClaw is not a chatbot. It's not an "AI assistant." It's the first personal operating system where the shell language is English.

Most people install it, hook it to WhatsApp, tell it to summarize their emails, and think: "Oh, this is a smarter Siri." They're using a supercomputer to play Snake. This post exists to fix that.

What Is an Operating System?

Strip the word "computer" of all marketing and get to the substrate:

Hardware does one thing: flip bits. Raw, meaningless, fast.

The OS does one thing: expose hardware capabilities through a stable API so applications don't need to understand the physics of storage or memory. The OS is the contract layer between silicon and software.

Applications implement specific intent on top of that contract.

This three-layer stack is 60 years old and has never fundamentally changed. What has changed is the API language.

Unix (1969): the API is a shell. Intent expressed as typed commands.
Mac/Windows (1984): the API is a GUI. Intent expressed as mouse clicks.
iOS/Android (2007): the API is touch. Intent expressed as gestures.
OpenClaw (2026): the API is natural language. Intent expressed as thought.

That's not a product evolution. That's a paradigm shift in the interface contract.

The Architecture Nobody Explains Properly

Here's what OpenClaw actually is under the hood — three components that, together, do something genuinely new:

1. The Gateway (the kernel)

A persistent Node.js process running on your machine. It owns your file system access, shell execution, browser control via CDP, and messaging connectors (WhatsApp, Telegram, Slack, Discord, Signal — 30+ platforms). It never sleeps. It runs cron jobs. It watches for triggers.

~/.openclaw/
├── memory/          # Vector-embedded context (your persistent RAM)
├── skills/          # Installed skill definitions (your installed apps)
├── agents.md        # Your agent's personality, rules, goals (your user config)
└── logs/            # Full audit trail of every action taken

The gateway is the kernel. It's what makes OpenClaw fundamentally different from a chatbot — a chatbot forgets you when you close the tab. The gateway never closes.

2. Memory (the persistent state)

Every conversation, every file it reads, every action it takes gets embedded and stored in ~/.openclaw/memory/. This is not a clever trick — it's the architectural primitive that makes agents possible.

When you message OpenClaw six months from now and say "do the thing I did with the vendor last March," it will find the context. No re-explaining. No re-uploading. It knows you because it remembers living with you.

3. Skills (the apps — and this is the key insight)

A Skill is a Markdown file. That's it. Here's a real one:

# github-pr-reviewer

## Description
Reviews pull requests, checks for common issues, and posts a structured review comment.

## Trigger
When asked to review a PR or given a GitHub PR URL.

## Instructions
1. Fetch the PR diff using the GitHub API
2. Analyze for: security issues, logic errors, naming conventions, missing tests
3. Structure the review as: LGTM / Needs Changes / Critical Issues
4. Post the review comment via GitHub API with your findings

## Tools Required
- shell (for gh CLI commands)
- browser (for reading PR context)

## Example
User: "Review PR #247 in my-org/backend"
Agent: [fetches diff, analyzes, posts structured review to GitHub]

Read that again. There is no code. The skill is an instruction set written in plain English that tells the LLM how to use the tools it already has access to. The model is the runtime. The Markdown is the program.

This is what makes the skills format revolutionary: every developer on Earth is now a software publisher. You don't need to know Python to build a skill. You need to know what you want done and be able to describe it clearly.

What I Built: The Dead-Simple Dev Pipeline That Saves 9 Hours a Week

I run a small dev consultancy. My biggest time drain: context-switching between Slack, GitHub, and client email to stay on top of code reviews, deployments, and status updates.

I built three skills and wired them together with a Lobster workflow (OpenClaw's YAML orchestration engine):

Skill 1: pr-morning-digest

# pr-morning-digest
Every morning at 8AM, check all GitHub repos I have access to.
Find PRs that:
- Have been open more than 24 hours without review
- Have failing CI
- Are tagged as urgent
Format them as a priority-ordered list and send to Telegram.

Skill 2: slack-action-extractor

# slack-action-extractor
When triggered, scan the last 50 messages in #engineering Slack channel.
Identify messages directed at me or mentioning my name.
Extract action items and deadlines.
Add them to my local tasks.md file.

Skill 3: client-status-drafter

# client-status-drafter
Every Friday at 4PM:
1. Read this week's merged PRs from GitHub
2. Read closed tickets from Linear
3. Draft a plain-English client status email
4. Save draft to ~/drafts/client-status-{date}.md and send me the preview on Telegram

The Lobster workflow that chains them:

name: dev-ops-daily
schedule: "0 8 * * 1-5"
steps:
  - skill: pr-morning-digest
    output: pr_list
  - skill: slack-action-extractor
    output: action_items
  - condition: friday
    skill: client-status-drafter
    input:
      context: "{{pr_list}} {{action_items}}"

Total setup time: 47 minutes including reading the docs.

Estimated time saved per week: ~9 hours of context-switching, manual status compilation, and PR triage.

I did not write a single line of Python. I wrote instructions.

The Part Nobody Wants to Admit: It's Also a Security Nightmare

I won't write a press release. So here's the honest section.

CVE-2026-25253 is real. The OpenClaw gateway has a documented vulnerability where malformed skill files on ClawHub can inject arbitrary instructions into the agent's context — essentially prompt injection at the OS level. This isn't theoretical. The OpenClaw team has patched the specific vector, but the class of attack remains: ClawHub lets any developer publish a skill, and the trust model is "read the source before you install."

That's like npm in 2016. We know how that played out.

Three things you must do before trusting OpenClaw with anything sensitive:

Run in sandboxed mode. The --sandbox flag prevents shell execution and limits file access to a designated directory. For most automations, you don't need full system access.
Audit every skill before installing. Skills are Markdown — read them. It takes 90 seconds. If a skill asks for tool access it doesn't need (a weather skill asking for shell access is a red flag), reject it.
Never store credentials in plain text in agents.md. Use environment variables. OpenClaw supports ${ENV_VAR} interpolation in agents.md specifically for this reason.

The ClawHub ecosystem will mature — security-check skills, community auditing, automated vulnerability scanning are all in active development. But today, treat ClawHub like you'd treat an unverified PPA: useful, powerful, and something you approach with your eyes open.

The Deeper Implication

Here's what I think is actually happening, and why it matters beyond the automation wins:

For 50 years, software has had a one-way relationship with users. Developers write programs; users run them. The expertise asymmetry was structural — you couldn't build your own tools without years of education.

OpenClaw collapses that asymmetry.

When a non-developer writes a skill file that automates their mortgage application follow-ups, or a healthcare worker builds a patient note summarizer, or a teacher creates an assignment feedback pipeline — they're not "using AI." They're building software. The runtime just happens to speak English.

This is what the PC moment actually was: not "computers are now smaller," but "the power to create with computers is now personal." OpenClaw is that moment applied to agency. The power to automate, to delegate, to build running systems — that's now personal.

The skills format is the spreadsheet of the agent era. And just like the spreadsheet, most of its eventual users haven't been born yet.

Start Here, Not There

# macOS / Linux (one-liner installer)
curl -fsSL https://openclaw.ai/install.sh | bash

# Configure your LLM key
openclaw config set anthropic_api_key=YOUR_KEY

# Start the gateway
openclaw start

# Connect your messaging app — then send:
# "What can you do?"

That last message will give you the real answer. Not the marketing one. The actual answer of what's sitting on your machine, waiting.

Submitted for the OpenClaw Writing Challenge on DEV — Wealth of Knowledge prompt.

The Internet Got Its HTTP Moment Again — And Nobody's Talking About It

Farooq Shabbir — Thu, 23 Apr 2026 11:09:22 +0000

Google Cloud NEXT '26 dropped 50+ announcements. The one that changes everything isn't the shiny AI model. It's a protocol.

Everyone came to Google Cloud NEXT '26 for the model war — Gemini 3.1, the Apple-Gemini bombshell, TPU 8t connecting 134,000 chips into a single Virgo fabric. Those headlines are real. But buried beneath the flash is the announcement that defines how software is actually built in 2027 and beyond:

Agent2Agent (A2A) protocol v1.0 is in production at 150 organizations. The Linux Foundation now governs it. And it's already baked into six major frameworks.

That's not a product announcement. That's infrastructure. And infrastructure is where all the leverage lives.

Why Multi-Agent Systems Have Been Broken

Let's strip the marketing away.

An agent is just a loop: observe → reason → act → repeat. The moment you need two agents to collaborate — a procurement agent handing off to a finance agent, a customer service bot escalating to a specialist — you hit a fundamental problem:

How do they talk?

Today, most "multi-agent" systems are secretly monoliths. They use shared memory, shared queues, or vendor-specific SDKs that chain agents together within one platform. It works until you need your Salesforce Agentforce bot to hand a task to your ServiceNow agent. Then you write glue code. Then you maintain it. Then you regret your life choices.

This is the exact same problem the internet solved in the 1990s. Before HTTP, every web server talked a different language. After HTTP: one protocol, universal interoperability, an explosion of innovation. A2A is making the same move for agents.

What A2A v1.0 Actually Delivers

1. Agent Cards — The DNS of the Agent World

Every A2A-compliant agent publishes an Agent Card: a JSON manifest served at /.well-known/agent.json that declares what the agent can do, what inputs it accepts, what auth schemes it supports, and how to reach it.

{
  "name": "Procurement Agent",
  "version": "1.2.0",
  "capabilities": ["create_purchase_order", "check_vendor_status", "approve_spend"],
  "input_schema": {
    "type": "object",
    "properties": {
      "vendor_id": { "type": "string" },
      "amount_usd": { "type": "number" }
    }
  },
  "auth": { "schemes": ["oauth2", "api_key"] },
  "endpoint": "https://procurement-agent.acme.com/a2a"
}

This is discovery. This is what lets a general-purpose orchestrator find and call a specialist agent without prior integration work. It's DNS + OpenAPI, applied to agents.

2. Task Lifecycle — State That Survives Handoffs

A2A defines a standard task state machine: submitted → working → input-required → completed/failed/cancelled. Real enterprise tasks take minutes to hours, not milliseconds. A2A task state lives in the protocol, not in one vendor's database — so it survives network interruptions, agent restarts, and platform migrations.

3. Streaming & Push Notifications

A2A supports Server-Sent Events for streaming task updates. Long-running agents push incremental progress back to the orchestrator without polling. For a research agent crawling documents for 20 minutes, this isn't a nice-to-have. It's the difference between a system that works and one that times out.

The Code That Matters

Here's a minimal A2A agent server using the new ADK v1.0 (Python, stable release):

from google.adk.agents import LlmAgent
from google.adk.a2a import A2AServer, AgentCard, Capability

card = AgentCard(
    name="inventory-checker",
    version="1.0.0",
    capabilities=[
        Capability(
            name="check_stock",
            description="Returns current inventory level for a given SKU",
            input_schema={"sku": "string"},
            output_schema={"quantity": "integer", "warehouse": "string"}
        )
    ]
)

agent = LlmAgent(
    model="gemini-3-flash",
    system_prompt="You check inventory. Be precise and fast.",
    tools=[check_inventory_db]
)

server = A2AServer(agent=agent, card=card, port=8080)
server.start()
# → GET  /.well-known/agent.json   (Agent Card discovery)
# → POST /a2a/tasks/send           (Task endpoint)

And calling it from an orchestrator:

from google.adk.a2a import A2AClient

client = A2AClient()

# Auto-fetches the Agent Card
inventory_agent = await client.discover("https://inventory.acme.com")

# Send a task
task = await inventory_agent.send_task({
    "capability": "check_stock",
    "input": {"sku": "WIDGET-42"}
})

# Stream progress in real time
async for update in task.stream():
    print(f"Status: {update.status} | {update.message}")

result = await task.result()
print(f"Stock: {result['quantity']} units at {result['warehouse']}")

This runs cross-platform. The inventory agent could be on Agent Engine. The orchestrator could be LangGraph, CrewAI, or AutoGen. A2A bridges them without custom serialization or SDK lock-in.

The Ecosystem Play Is Already Working

The number that should get your attention: 150 organizations in production — not pilot.

Google announced A2A at Google I/O 2025 with 50 partners on paper. Twelve months later, it's in live production at 150 organizations, and governance has moved to the Linux Foundation's Agentic AI Foundation. That last detail is critical — it signals A2A is not a Google product anymore. It's an industry standard in the making, the same way the Linux Foundation stewards Kubernetes, OpenTelemetry, and gRPC.

Native A2A support now ships in:

Google's ADK (Python, Go, Java, TypeScript — all stable v1.0)
LangGraph
CrewAI
LlamaIndex Agents
Microsoft Semantic Kernel
AutoGen

When Microsoft's framework supports your protocol, you've won the framework war before it started.

My Honest Critique: What's Still Missing

I'm not here to write a press release. So let me be direct.

1. Security model is immature.
A2A supports OAuth2 and API keys — table stakes. But there's no standard for capability scoping, no canonical way to say "this orchestrator can call check_stock but not approve_spend." In enterprise environments, this granular authorization matters enormously. Today you implement it yourself.

2. Agent Card versioning is undefined.
What happens when an agent upgrades from v1.0.0 to v2.0.0 and changes a capability schema? A2A has no deprecation protocol, no capability negotiation, no backward-compatibility guarantees baked in. Every integration team will solve this differently until a standard emerges.

3. Observability is an afterthought.
There's no standard tracing header in A2A requests — no X-A2A-Trace-ID spec. When a task flows through five agents across three platforms and breaks, you're currently stitching together vendor-specific logs to reconstruct what happened. OpenTelemetry support is on the roadmap. It can't come fast enough.

These aren't dealbreakers. HTTP 1.0 didn't have keep-alive. It evolved. A2A will too. But go in clear-eyed.

Why This Is the Most Underrated Announcement of NEXT '26

Everyone will write about Gemini 3.2's expanded context window. Everyone will write about TPU 8t (Sunfish) and the Virgo Network connecting over a million chips into a single logical training cluster. Those are real stories.

But here's the thing about infrastructure: the network effects compound silently until they're obvious.

TCP/IP didn't make the front page when it shipped. Neither did HTTP. They became the substrate on which everything else ran. A2A — now stable, governed by a neutral foundation, adopted across competing frameworks — is positioning itself as the substrate for multi-agent systems.

The developers who understand it now, who build A2A-compliant agents and orchestrators that can discover any A2A endpoint, are the ones with a durable advantage as the agentic era matures. Not because Google said so in a keynote. Because 150 production deployments and Linux Foundation governance are the kind of signals that don't reverse.

What to Do This Week

Read the A2A spec: google.github.io/A2A — clean, short, worth 20 minutes.
Install ADK v1.0: pip install google-adk — stable, production-ready.
Expose your next agent with an Agent Card. Treat it like a README.md: required, not optional.
Watch the Developer Keynote (April 23, 10:30 AM PT) — live A2A cross-platform interop demos.

The agentic era isn't coming. It's here. And now it has a protocol.

Posted as part of the Google Cloud NEXT '26 Writing Challenge on DEV.

Go ahead. Don't miss out this opportunity.

Farooq Shabbir — Tue, 17 Mar 2026 07:13:07 +0000

Jess Lee for The DEV Team

Mar 4

Join the Notion MCP Challenge: $1,500 in Prizes!

#notionchallenge #devchallenge #mcp #ai

197

Comments 38

3 min read

I Built a DevOps Simulator to Practice Kubernetes Debugging

Farooq Shabbir — Wed, 11 Mar 2026 11:18:12 +0000

Most DevOps tutorials have a problem.

They explain things like this:

“Here is what CrashLoopBackOff means.”
“Here is how to fix it.”

But real DevOps work doesn’t look like that.

Real incidents look like this:

kubectl get pods
kubectl logs api
kubectl describe pod api
kubectl get services

You investigate.
You read logs.
You try commands.
You guess.
You debug.

So I built a small DevOps Learning Simulator where you practice debugging Kubernetes incidents like you would in a real environment.

The Idea

Instead of reading solutions, you interactively investigate problems using real commands from Kubernetes.

You run commands such as:

kubectl get pods
kubectl logs <pod>
kubectl describe pod <pod>
kubectl get services
kubectl describe service <service>
kubectl get endpoints

Then you try to find the root cause of the incident.

Example Incident

You start the simulator and run:

kubectl get pods --show-labels

Output:

NAME                          READY STATUS             RESTARTS AGE LABELS
api-deployment-7d4f8b9c       0/1   CrashLoopBackOff        8 36m -
nginx-deployment-5f6g7h8i     1/1   Running                 0 5m app=nginx

You investigate logs:

kubectl logs api-deployment

Then describe the pod:

kubectl describe pod api-deployment

Eventually, you discover the issue:

A missing ConfigMap caused the container to crash.

The simulator then checks your answer and gives feedback.

Current Scenarios

Version 1 includes several common production incidents:

• CrashLoopBackOff caused by missing configuration
• OOMKilled due to incorrect memory limits
• DNS / service selector mismatch

These are problems engineers regularly see when working with Kubernetes.

Why I Built This

Many developers learn DevOps tools but never practice debugging real incidents.

They know commands but haven’t used them in a realistic investigation.

This project aims to address that by providing a safe environment for troubleshooting practice.

Think of it like a flight simulator for DevOps engineers.

Try It

You can try it here:

GitHub Repository

https://github.com/FarooqShabbir/devops_simulator

Run it locally:

git clone https://github.com/FarooqShabbir/devops_simulator.git
cd devops_simulator
python devops_simulator.py

Then start investigating incidents.

Future Plans

Some ideas for future versions:

• CI/CD pipeline failures
• Infrastructure drift debugging
• Network policy issues
• Multi-service production incidents

If you have ideas or want to contribute, feel free to open an issue or pull request.

Feedback

I would love to hear from other DevOps engineers:

What incidents would you add to a DevOps debugging simulator?