How we run AI agents as permanent residents of our dev workflow with OpenClaw

Storyie is built by a small team. That means any given week involves writing code, reviewing it, fixing CI, writing articles, and handling the long tail of operational tasks — all by the same people. At some point we stopped asking "how do we work faster" and started asking "what can we stop doing ourselves."

This post describes how we integrated OpenClaw into the Storyie development workflow, what seven cron jobs running against our codebase actually looks like day-to-day, and where the boundary between agent work and human judgment still needs to be deliberate.

TL;DR

• OpenClaw keeps a Claude-backed agent resident in the repository, with persistent memory, scheduling, and messaging integrations.
• We run seven scheduled jobs: auto-implementation from GitHub Issues, implementation planning, PR review fixing, article generation, article stats tracking, Reddit monitoring, and git sync.
• The pipeline is: add a plan label → agent researches and writes an implementation plan → label swaps to do-next → agent implements and opens a PR → human reviews → review fixer applies comments automatically.
• Human work shifted from execution to judgment: reading PRs, writing issues, deciding what to build next.

What OpenClaw is

OpenClaw is a framework for running LLM-backed agents as long-lived processes attached to a workspace. The key properties:

• Workspace residence — the agent has file read/write and command execution access to a specific repository
• Messaging integrations — you can talk to the agent via Discord, Telegram, or Signal
• Cron jobs — scheduled tasks the agent runs autonomously
• Sub-agents — parallel task execution spun off from the main session
• Memory — MEMORY.md and directory-based long-term context

The mental model: Claude has fully internalized your codebase and is waiting at the desk 24 hours a day.

Setup

Installation and initial configuration

npm install -g openclaw
openclaw configure

The config file (openclaw.json) associates agents with workspaces:

{
  "agents": {
    "list": [
      {
        "id": "storyie",
        "name": "Storyie Dev",
        "workspace": "/home/ubuntu/dev/storyie"
      }
    ]
  }
}

Workspace instruction files

A handful of files in the project root give the agent its operating context. These load at session start:

Our AGENTS.md looks roughly like this:

## Every Session
1. Read `SOUL.md` — development assistant persona
2. Read `CLAUDE.md` — project-specific coding guidelines
3. Check recent `memory/YYYY-MM-DD.md` for context

## Development Workflow
### Before Committing
pnpm type-check
pnpm lint
pnpm test

### Commit Style
Use Conventional Commits: feat:, fix:, refactor:, chore:

Every cron job picks this up before doing anything, so the agent's understanding of our conventions is never stale.

The seven cron jobs

This is where the real work happens.

1. Issue auto-implementation (do-next worker)

Schedule: every 30 minutes

Any GitHub Issue with a do-next label gets automatically implemented and submitted as a PR.

The sequence:

1. gh issue list --label do-next — find candidates
2. Read the issue body; scan the codebase for context
3. Branch off develop
4. Implement
5. pnpm lint:fix && pnpm type-check && pnpm test
6. Commit → push → open PR
7. Remove the do-next label

In practice: write an issue, attach do-next, and a PR appears within 30 minutes. Review the PR, leave comments if needed — the review fixer handles those automatically (see below).

2. Implementation planner (plan worker)

Schedule: every hour at :30

Issues labelled plan get a deep codebase investigation and a structured implementation plan written into the issue comments.

The output format:

• Affected files and packages
• Design rationale and alignment with existing patterns
• Step-by-step implementation checklist
• Risk flags and gotchas
• Links to relevant existing code with file paths and line numbers
• Rough effort estimate (S / M / L)

When the plan is written, the agent swaps plan for do-next. The pipeline becomes:

[plan label] → agent researches and writes plan
    ↓ label swapped automatically
[do-next label] → agent implements, opens PR
    ↓
[PR review] → human reviews
    ↓ leave comments
[review fixer] → fixes applied automatically

Label an issue and walk away. The rest runs without you.

3. PR review fixer

Schedule: every 15 minutes

For every open PR, the agent checks two things:

1. CI failures — if checks have failed, it reads the logs and pushes a fix commit
2. New review comments — anything posted after the last commit gets addressed

This is the job that changed daily habits most noticeably. Leave a review comment, come back 15 minutes later, find it resolved. No follow-up needed.

4. Technical article generation

Schedule: daily at 22:00 UTC

Based on the Article Schedule in MEMORY.md, the agent generates a technical article by investigating the codebase for concrete examples, then writes and pushes it with published: false. A human reviews before flipping it to published.

5. Article stats tracker

Schedule: daily at 21:00 JST

Fetches engagement metrics (likes, bookmarks) from the Zenn API, updates the stats table in MEMORY.md, and reorders the article queue based on what topics are resonating.

6. Reddit karma scout

Schedule: 3x daily at 08:00, 14:00, and 22:00 JST

Monitors technical subreddits for rising posts and drafts comment suggestions. Light-touch marketing assistance.

7. Git auto-sync

Schedule: every 6 hours

Pushes agent-generated changes — memory updates, config edits — back to develop so nothing the agent learns is lost between sessions.

ASC CLI for App Store automation

OpenClaw pairs well with ASC CLI, which exposes App Store Connect operations as shell commands. Giving the agent access to ASC lets us automate ASO work that would otherwise require clicking through the App Store Connect UI.

What ASC CLI covers

# List apps
asc apps list

# Read metadata for a specific version
asc app-info get --app "APP_ID" --version "1.9" --platform IOS

# Update What's New text
asc app-info set --app "APP_ID" --locale "en-US" \
  --whats-new "Bug fixes and performance improvements"

# Download all localization metadata
asc localizations download --version "VERSION_ID" --path "./localizations"

# Manage search keywords
asc localizations search-keywords list --localization-id "LOC_ID"

# Upload screenshots
asc screenshots upload --version-localization "LOC_ID" \
  --path "./screenshots" --device-type "IPHONE_69"

# Pull sales analytics
asc analytics sales --vendor "VENDOR_ID" --type SALES \
  --subtype SUMMARY --frequency DAILY --date "2026-02-17"

Closing the ASO feedback loop

With an agent running ASC commands on a schedule, the optimization cycle becomes continuous:

Weekly analytics pull

asc analytics request --app "APP_ID" --access-type ONGOING
asc analytics download --request-id "REQ_ID" --instance-id "INST_ID"

Localization sync

# Download → agent improves → upload
asc localizations download --version "VERSION_ID" --path "./aso/localizations"
# agent edits files...
asc localizations upload --version "VERSION_ID" --path "./aso/localizations"

Keyword updates

asc localizations search-keywords list --localization-id "LOC_ID"

If impressions are low, revisit keywords. If conversion is low, revisit screenshots and description. The agent can track both signals and propose changes; a human approves before anything goes live.

Screenshot automation (experimental)

ASC CLI also supports end-to-end screenshot capture and upload:

# Capture from simulator
asc screenshots capture --bundle-id "com.diary.story-write" --name home

# Add device frame
asc screenshots frame --input ./screenshots/raw/home.png --device iphone-air

# Run a full screenshot plan
asc screenshots run --plan .asc/screenshots.json

No more manually recapturing screenshots after every update.

Memory

The agent persists long-term context in MEMORY.md. A representative excerpt:

## Preferences
- After addressing PR review comments, resolve the corresponding review conversation

## Zenn Article Stats
Last updated: 2026-02-17
| slug | title | ❤️ | 🔖 |
|------|-------|---:|---:|
| ai-bot-users-diary-app | AI bot users diary app... | 2 | 0 |

## Article Schedule
### Next Topics (priority order)
1. OpenClaw / AI agent integration
2. Image upload — S3 presigned URLs
3. Auth flow — Supabase Auth

This means context from last week's decisions is available today without any manual recap. The agent knows what we worked on, what we decided, and what is next.

How the workflow actually changed

Before OpenClaw:

Write issue → design it yourself → implement it yourself → review it yourself
  → fix CI manually → merge → write an article (maybe, someday)

After OpenClaw:

Write issue, add label → implementation plan appears → PR appears
  → leave review comments → comments addressed → merge
  → articles generated daily → review and publish

The shift is from execution to judgment. We spend more time reading PRs and deciding what to build than writing code. That is a meaningful change in how the day feels.

Costs and guardrails

API costs

Every cron job is written to exit early with a HEARTBEAT_OK signal if there is nothing to do. Most runs cost nearly nothing. We review spend weekly and tune cron frequency if a particular job starts running more than expected.

Quality

Agent-written code always gets a human review. Type checks and lint pass automatically, but architectural decisions and user-facing behavior still need a person's eye. The bar for merging is unchanged — the review just happens after the agent does the first pass.

Security

Three hard rules, encoded in AGENTS.md:

• No access to .env.keys or other credential files
• External sends (email, social posts) require explicit human approval
• Security-sensitive code changes (auth, billing) get flagged for review, not silently committed

Takeaways

• The plan → do-next → PR pipeline works because each step has a clear input and output. Labels are the handoff mechanism between the agent's jobs and human attention.
• The review fixer is the most day-to-day-useful job. It removes the friction of follow-up — you leave a comment and it is handled.
• Early-exit discipline keeps costs predictable. If a cron job does nothing, it should say so and stop immediately.
• The agent does not replace judgment. What to build, how to evaluate quality beyond the linter, what to do about security — those stay with the humans. What changes is that the execution between "decided" and "done" no longer requires the same people.

Related Posts

• Building a Monorepo with pnpm and TypeScript — workspace conventions this workflow runs inside
• AI-driven development with SpecKit — another angle on AI-assisted development at Storyie
• Building a Cross-Platform Mobile App with Expo — the broader Expo and mobile context

Try Storyie

Storyie is the diary app this workflow builds. Write on the web at storyie.com or on iOS — your entries sync across both, same content, same formatting, same custom node types.