Overnight Factory

Set up an AI agent as an Overnight Software Factory operator. Use when configuring an OpenClaw agent to autonomously handle support tickets end-to-end: recei...

Security Scan

The skill's stated purpose (autonomous ticket → PR pipeline) matches what the instructions do, but the SKILL.md secretly requires and writes sensitive credentials, modifies global git config, and asks the agent to bypass permission controls — these are coherent with the feature but disproportionate and potentially risky.

Purpose & Capability

The instructions legitimately need GitHub and email access for the ticket-to-PR flow, but the registry metadata declares no required env vars or credentials while the SKILL.md explicitly instructs creating .env with GITHUB_TOKEN, EMAIL_USER, and EMAIL_PASSWORD and persisting the token to ~/.git-credentials. This mismatch between declared requirements and actual instructions is a material incoherence.

Instruction Scope

Runtime instructions perform wide-reaching actions: logging into IMAP (with plaintext password), cloning repos and pushing branches using an embedded token, writing to memory/ and workspace files, and configuring global git credentials. They also call out running Claude with --dangerously-skip-permissions and spawning autonomous subagents. These steps go beyond a narrow helper script and include altering user environment and bypassing agent permission checks.

Install Mechanism

This is instruction-only with no install spec or downloaded code, so there is no installer risk from external archives or package downloads.

Credentials

The skill asks the operator to create and store high-privilege secrets (GITHUB_TOKEN, EMAIL_PASSWORD) and to embed the GitHub token in ~/.git-credentials (global, plaintext). Although the token+email creds are necessary for the described functionality, requiring global credential storage and not declaring these envs in the skill metadata is disproportionate and increases blast radius. The SKILL.md also expects access to a Claude binary with an option that skips permissions checks, which elevates risk.

Persistence & Privilege

The skill's workflow creates a cron job that autonomously runs every 15 minutes and spawns subagents to act (open PRs, push commits). While always:false (no forced inclusion), the instructions intentionally establish ongoing autonomous behavior and modify global git config (~/.git-credentials), which changes system-wide user state — this combination increases persistent privilege and potential for unintended side effects.

What to consider before installing

This skill appears to implement the ticket→PR automation it advertises, but exercise caution before installing. Key concerns: - The skill metadata lists no required env vars, but the instructions require GITHUB_TOKEN, EMAIL_USER, and EMAIL_PASSWORD — confirm what secrets you must provide. - The SKILL.md tells you to store your GitHub token in ~/.git-credentials and set global git user/email. That persists a token in plaintext and affects all git activity on the machine; prefer a least-privilege approach (repo-scoped deploy keys or fine-scoped personal access tokens) and avoid writing tokens to global files. - It instructs running Claude Code with --dangerously-skip-permissions, which disables local permission checks. Avoid this or understand exactly what permissions are being bypassed. - The cron + subagent design gives the skill ongoing autonomous power to clone repos, commit, push, and open PRs. Test everything in a limited/staging environment and use a bot account with minimal scopes (only the repos and actions it truly needs). Rotate tokens regularly and monitor audit logs. - Before going live, verify exactly which files the skill will write (memory/, workspace/, ~/.git-credentials) and consider isolating the agent on a dedicated account or container. If you want to proceed: create a constrained bot account with minimal scopes, avoid storing tokens in global git files, don't use --dangerously-skip-permissions, and run the cron in a controlled/staging environment first.

Configure this agent as an autonomous ticket-to-PR operator. Human reviews PRs; agent handles everything else.

Architecture

TinyDesk/support system
  → GitHub issue (assigned to bot account)
  → Email notification to agent inbox
       ↓
  Cron job (every 15min, isolated session)
  ├─ Email check: detect assignment emails
  ├─ GitHub poll: catch missed emails (safety net)
  └─ Dispatch: spawn subagent per ticket
            ↓
       Subagent (Claude Code)
       ├─ Analyze issue + screenshots
       ├─ Explore codebase
       ├─ Post analysis comment on issue
       ├─ Implement fix (branch → commit → push)
       └─ Open PR → notify human

Setup Steps

1. Identity & Credentials

Create workspace files: IDENTITY.md, USER.md (who you're helping), SOUL.md.

Add .env to workspace:

GITHUB_TOKEN=ghp_...
EMAIL_USER=[e-mail]
EMAIL_PASSWORD=...

Configure git:

git config --global user.name "Your Bot Name"
git config --global user.email "[e-mail]"
echo "https://bot-username:${GITHUB_TOKEN}@github.com" > ~/.git-credentials
git config --global credential.helper store

2. Verify Claude Code

/path/to/claude --version
/path/to/claude -p --dangerously-skip-permissions --output-format text "echo hello"

Note the exact path — you'll need it.

3. Create the Cron Job

openclaw cron add \
  --name "email-check" \
  --every 15m \
  --session isolated \
  --announce \
  --to <YOUR-TELEGRAM-CHAT-ID> \      # explicit ID, NOT --channel last
  --timeout-seconds 120 \
  --description "Check email + GitHub for ticket assignments" \
  --message "$(cat /path/to/cron-prompt.txt)"

See references/cron-prompt.md for the full prompt template.

4. Keep HEARTBEAT.md Lightweight

The cron handles email. Heartbeat should only contain tasks that need main-session context (e.g., PR monitoring).

Critical Rules

Cron delivery: Always use --to <explicit-chat-id>. Never --channel last — it doesn't resolve in isolated sessions.

Cron timeout: Keep the prompt fast. Check email → spawn subagents → log → exit. Never wait for subagents inline. 120s is enough.

Error backoff: After 5+ consecutive errors the cron backs off exponentially. Delete and recreate to reset: openclaw cron delete <id> && openclaw cron add ...

Fire-and-forget: Subagents don't reliably call back to Telegram. Have the cron itself announce dispatches in its own reply (the cron reply is what gets delivered).

Validation Checklist

Before going live:

• Send test email to support address — cron picks it up within 15 min
• Cron dispatch reply arrives on Telegram
• Subagent opens a real branch + PR
• Assign a GitHub issue to bot manually — GitHub poll catches it
• lastDelivered: false on empty runs is expected (HEARTBEAT_OK is silent by design)

Debugging

# Check cron status
openclaw cron list --json | jq '.jobs[0].state'

# Key fields to check:
# lastRunStatus: "ok" or "error"
# consecutiveErrors: should be 0
# lastDelivered: false on empty runs is normal; false on ticket-dispatch runs is a bug
# lastDeliveryStatus: "not-delivered" = delivery config wrong

# Check recent logs
tail -20 memory/heartbeat-log.jsonl

# Check inbox directly
python3 -c "
import imaplib, ssl
ctx = ssl.create_default_context()
M = imaplib.IMAP4_SSL('imap.ionos.com', 993, ssl_context=ctx)
M.login('[e-mail]', 'password')
M.select('INBOX')
print('Unread:', len(M.search(None, 'UNSEEN')[1][0].split()))
M.logout()
"

Reference Files

• references/cron-prompt.md — full cron job prompt template with email check + GitHub poll
• references/ticket-pipeline.md — how to instruct subagents to handle tickets end-to-end
• references/lessons-learned.md — real failure modes and fixes from production use