Forem: Eli_coding

I Built a GitHub Action That Codes My Todoist Tasks While I Sleep

Eli_coding — Thu, 30 Apr 2026 09:59:06 +0000

I Built a GitHub Action That Reads My Todoist, Codes the Task, and Marks It Done — Every 5 Hours

Yes, 5 hours. No, it's not random. Keep reading.

The Problem With Being a Solo Developer

You know that feeling when you have a perfectly organized Todoist board, a cup of coffee, and absolutely zero motivation to actually open your code editor?

Same.

I'm a frontend engineer building a product on my own. Between my day job, content creation, and pretending I go to the gym, finding focus time to chip away at the backlog is... a challenge.

So I did what any reasonable developer would do: I automated myself out of the problem.

The Idea: An Agent Queue

I created a Todoist project called Agent_Queue. Every time I have a small coding task — a refactor, a new component, a bug fix — I add it as a task with a description detailed enough for an AI to understand it.

Then a GitHub Action wakes up, grabs the highest priority task, hands it to Claude Code, lets it do its thing, commits the result to my dev branch, and marks the task as complete in Todoist.

I wake up in the morning with code written. Sometimes it's great. Sometimes I need to tweak it. But it's a starting point I didn't have to make myself.

Why Every 5 Hours?

Okay, storytime. 🍿

Claude Code uses API tokens under the hood. Those tokens have usage limits — and if you're running Claude Code autonomously on a task, it can be... enthusiastic. Like, "rewrite-your-entire-codebase-because-why-not" enthusiastic.

Running it every 5 hours gives the token usage time to breathe and reset between runs. It also means if something goes wrong (Claude goes rogue, commits chaos, the API hiccups), you only have one task's worth of damage to deal with — not a pile-up of 47 autonomous commits from overnight.

Think of it as: one task, one session, one breath. The 5-hour gap is the coffee break Claude doesn't know it's taking.

Also, Anthropic's rate limits are real. Respect them. Your wallet will thank you.

The Full Workflow

Here's exactly how it works, step by step:

1. The Trigger

on:
  schedule:
    - cron: '0 */5 * * *'  # every 5 hours
  workflow_dispatch:         # or manually, when you're impatient

workflow_dispatch is your emergency override. Sometimes you fix something in Todoist and just want to run it NOW. I use this constantly.

2. Find the Project + Top Task

The action hits the Todoist API, finds the Agent_Queue project by name, fetches all tasks, and sorts by priority. In Todoist's API, P1 = priority 4 (yes, inverted — don't ask, it's just how it is).

- name: Fetch top priority task from Todoist
  id: todoist
  env:
    TODOIST_API_KEY: ${{ secrets.TODOIST_API_KEY }}
    TODOIST_PROJECT_NAME: 'Agent_Queue'
  run: |
    PROJECTS=$(curl -s \
      -H "Authorization: Bearer $TODOIST_API_KEY" \
      https://api.todoist.com/api/v1/projects)

    PROJECT_ID=$(echo "$PROJECTS" | python3 -c "
    import json, sys, os
    data = json.load(sys.stdin)
    name = os.environ['TODOIST_PROJECT_NAME']
    match = next((p for p in data if p['name'] == name), None)
    print(match['id'] if match else '')
    ")

I use inline Python to parse the JSON — no extra dependencies, no setup. It's a bit cursed but it works beautifully.

3. Run Claude Code

This is the magic step. Claude Code runs in the terminal, reads the full codebase, and executes the task prompt autonomously.

- name: Install Claude Code
  run: npm install -g @anthropic-ai/claude-code

- name: Run Claude Code on task
  env:
    ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
    TASK_PROMPT: ${{ steps.todoist.outputs.task_prompt }}
  run: |
    echo "$TASK_PROMPT" | claude -p \
      --dangerously-skip-permissions \
      --max-turns 10 \
      --output-format stream-json \
      --verbose 2>&1 | tee claude-output.log

A few flags worth calling out:

--dangerously-skip-permissions — Claude Code normally asks for confirmation before doing things. In CI there's no one to confirm, so we skip it. Use this with respect.
--max-turns 10 — puts a hard limit on how many back-and-forth steps Claude takes. Prevents infinite loops.
--output-format stream-json — logs everything as JSON stream so you can actually debug what happened.

4. Commit to Dev

- name: Commit any changes Claude made
  run: |
    git config user.name "Claude Agent"
    git config user.email "claude-agent@users.noreply.github.com"
    git add -A
    if git diff --staged --quiet; then
      echo "No file changes to commit."
    else
      git commit -m "chore: agent task - ${{ steps.todoist.outputs.task_content }}"
      git push
    fi

If Claude made no file changes (maybe the task was already done, or it was a read-only task), the workflow exits cleanly. No empty commits.

5. Mark the Task Done in Todoist

- name: Mark task as complete in Todoist
  if: steps.todoist.outputs.task_found == 'true' && success()
  env:
    TODOIST_API_KEY: ${{ secrets.TODOIST_API_KEY }}
    TASK_ID: ${{ steps.todoist.outputs.task_id }}
  run: |
    curl -s -X POST \
      -H "Authorization: Bearer $TODOIST_API_KEY" \
      -H "Content-Type: application/json" \
      "https://api.todoist.com/api/v1/tasks/$TASK_ID/close"

The success() condition is important — the task only gets marked as done if everything before it succeeded. If Claude crashed, or the push failed, the task stays open and will be picked up again next cycle.

GitHub Secrets You Need

Go to your repo → Settings → Secrets and variables → Actions and add:

Secret	Where to get it
`TODOIST_API_KEY`	Todoist → Settings → Integrations → Developer
`ANTHROPIC_API_KEY`	console.anthropic.com

Does It Work With Other Task Tools?

Yes — and this is the part I love. The GitHub Actions structure is completely generic. All you need is a task tool with a REST API that can:

List tasks (with some priority or ordering)
Close/complete a task by ID

So you can swap Todoist for:

Linear — great for teams, has a beautiful API
Jira — enterprise-friendly, more verbose but works
Asana — same concept, different endpoints
Notion — databases as task lists, totally doable
GitHub Issues — meta as it gets, but it works

The only thing you change is the curl commands in the fetch and close steps. Everything else — the Claude Code runner, the git commit, the cron schedule — stays identical.

Tips From Running This for a Few Weeks

Write detailed task descriptions. The task content becomes the prompt for Claude Code. "Fix bug" will get you nowhere. "The login page throws a TypeError when the user submits an empty email — fix the null check in AuthForm.tsx" will get you a working fix.

Use the task description field, not just the title. My workflow uses the description as the full prompt if it exists, falling back to the title. Give Claude context — file names, expected behaviour, what you've already tried.

Start with small tasks. Don't throw "refactor the entire auth module" at it on day one. Start with "add a missing aria-label to the submit button in LoginForm.tsx". Build trust with the agent before giving it the keys to the kingdom.

Review before merging. This commits to dev, not main. Always review what Claude produced before merging. It's usually good, sometimes great, occasionally baffling.

The Vibe

I built this because I believe the best tools are the ones that work while you sleep. Not in a "hustle culture" way — in a "your computer can do repetitive things so your brain doesn't have to" way.

My Todoist board is now also my team standup. I write the task, the agent picks it up, and when I sit down in the morning there's a commit waiting for me to review. It's a weird and delightful workflow and I'm fully here for it.

Full YAML

The complete workflow file is below. Drop it in .github/workflows/todoist-sync.yml and you're good to go.

name: Agent Queue Runner

on:
  schedule:
    - cron: '0 */5 * * *'
  workflow_dispatch:

jobs:
  run-agent-task:
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      - name: Checkout repo
        uses: actions/checkout@v4
        with:
          ref: dev

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '24'

      - name: Fetch top priority task from Todoist
        id: todoist
        env:
          TODOIST_API_KEY: ${{ secrets.TODOIST_API_KEY }}
          TODOIST_PROJECT_NAME: 'Agent_Queue'
        run: |
          PROJECTS=$(curl -s \
            -H "Authorization: Bearer $TODOIST_API_KEY" \
            -H "Content-Type: application/json" \
            https://api.todoist.com/api/v1/projects)

          if [ -z "$PROJECTS" ]; then
            echo "Empty response from Todoist API."
            exit 1
          fi

          PROJECT_ID=$(echo "$PROJECTS" | python3 -c "
          import json, sys, os
          data = json.load(sys.stdin)
          projects = data.get('results', data) if isinstance(data, dict) else data
          name = os.environ['TODOIST_PROJECT_NAME']
          match = next((p for p in projects if p['name'] == name), None)
          print(match['id'] if match else '')
          ")

          if [ -z "$PROJECT_ID" ]; then
            echo "Project not found."
            echo "task_found=false" >> $GITHUB_OUTPUT
            exit 0
          fi

          TASKS=$(curl -s \
            -H "Authorization: Bearer $TODOIST_API_KEY" \
            -H "Content-Type: application/json" \
            "https://api.todoist.com/api/v1/tasks?project_id=$PROJECT_ID")

          TASK_JSON=$(echo "$TASKS" | python3 -c "
          import json, sys
          data = json.load(sys.stdin)
          tasks = data.get('results', data) if isinstance(data, dict) else data
          if not tasks:
              print('')
              exit()
          tasks.sort(key=lambda t: t.get('priority', 1), reverse=True)
          t = tasks[0]
          prompt = t.get('description', '').strip() or t['content']
          print(json.dumps({'id': t['id'], 'content': t['content'], 'prompt': prompt}))
          ")

          if [ -z "$TASK_JSON" ]; then
            echo "No tasks found."
            echo "task_found=false" >> $GITHUB_OUTPUT
            exit 0
          fi

          TASK_ID=$(echo "$TASK_JSON" | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")
          TASK_CONTENT=$(echo "$TASK_JSON" | python3 -c "import json,sys; print(json.load(sys.stdin)['content'])")
          TASK_PROMPT=$(echo "$TASK_JSON" | python3 -c "import json,sys; print(json.load(sys.stdin)['prompt'])")

          echo "task_found=true" >> $GITHUB_OUTPUT
          echo "task_id=$TASK_ID" >> $GITHUB_OUTPUT
          echo "task_content<<EOF" >> $GITHUB_OUTPUT
          echo "$TASK_CONTENT" >> $GITHUB_OUTPUT
          echo "EOF" >> $GITHUB_OUTPUT
          echo "task_prompt<<EOF" >> $GITHUB_OUTPUT
          echo "$TASK_PROMPT" >> $GITHUB_OUTPUT
          echo "EOF" >> $GITHUB_OUTPUT

      - name: Install Claude Code
        if: steps.todoist.outputs.task_found == 'true'
        run: npm install -g @anthropic-ai/claude-code

      - name: Run Claude Code on task
        if: steps.todoist.outputs.task_found == 'true'
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          TASK_PROMPT: ${{ steps.todoist.outputs.task_prompt }}
        run: |
          echo "$TASK_PROMPT" | claude -p \
            --dangerously-skip-permissions \
            --max-turns 10 \
            --output-format stream-json \
            --verbose 2>&1 | tee claude-output.log

      - name: Commit any changes Claude made
        if: steps.todoist.outputs.task_found == 'true'
        run: |
          git config user.name "Claude Agent"
          git config user.email "claude-agent@users.noreply.github.com"
          git add -A
          if git diff --staged --quiet; then
            echo "No changes to commit."
          else
            git commit -m "chore: agent task - ${{ steps.todoist.outputs.task_content }}"
            git push
          fi

      - name: Mark task as complete in Todoist
        if: steps.todoist.outputs.task_found == 'true' && success()
        env:
          TODOIST_API_KEY: ${{ secrets.TODOIST_API_KEY }}
          TASK_ID: ${{ steps.todoist.outputs.task_id }}
        run: |
          curl -s -X POST \
            -H "Authorization: Bearer $TODOIST_API_KEY" \
            -H "Content-Type: application/json" \
            "https://api.todoist.com/api/v1/tasks/$TASK_ID/close"
          echo "Task marked complete."

If you build this or adapt it for Linear/Jira/Notion, let me know in the comments — I'd love to see what variations people come up with.

Follow me on DEV @eli_coding and Instagram @eli_coding for more of this kind of thing.

I Keep Telling Claude the Same Things. So He Started Writing Them Down Himself.

Eli_coding — Fri, 10 Apr 2026 11:24:23 +0000

A small moment that changed how I think about AI coding tools.

If you've used Claude Code for more than a week, you know the pattern.

You tell it something. It does it. Next session — gone. You tell it again. It does it. Next session — gone again.

For me, it was always the same three things:

"Keep components dumb. Logic goes in services."
"Use constants instead of string literals."
"Every new service or helper needs a unit test."

I said these things so many times they started to feel like a ritual. Open Claude, remind Claude, work, close Claude, repeat.

Then one day I was watching the terminal output — and I saw something I didn't expect.

What happened

I was working on a mid-sized Angular project — forms, validators, lazy-loaded modules, the usual stuff.

I'd just corrected Claude again on the dumb components rule. Nothing unusual. But instead of just applying the fix and moving on, I watched the terminal and noticed Claude was still running.

It was writing files.

Not code files. Not component files. Its own internal files.

Right there in the console output, I could see it creating memory.md, then feedback_dumb_components.md, then feedback_unit_tests.md — one by one.

I hadn't asked for any of this.

The files it created

Claude Code had built its own memory index and a set of structured feedback files — one for each rule it had learned from our sessions together.

Here's the actual memory.md it wrote:

# Memory Index
- [Project: Users Management](project_users_management.md) 
  — Angular frontend for Users Management; tabs, forms, validators
- [Feedback: OnPush + forms](feedback_onpush_forms.md) 
  — How to correctly update OnPush components when reactive form state changes
- [Feedback: No inline styles](feedback_no_inline_styles.md) 
  — Never use style attribute in HTML; always use scss files
- [Feedback: Dumb components + constants](feedback_dumb_components.md) 
  — Components must be dumb/agnostic; logic in services/helpers; always use constants
- [Feedback: Unit tests required](feedback_unit_tests.md) 
  — Every new service, helper, or util file must have a .spec.ts unit test file

And here's what it wrote inside feedback_dumb_components.md:

name: Dumb components + constants rule
type: feedback

Components should be dumb and agnostic — they bind signals/inputs from services 
and delegate all logic elsewhere. Business logic, form orchestration, and state 
management belong in services or helper functions, not in component classes.

Never use string literals in TypeScript code where a constant exists or can be created.

Why: User explicitly requested this as a project rule.

How to apply:
- Move any non-trivial logic (subscriptions, form manipulation, state derivation) 
  into a service or helper.
- Before writing a string like 'address', 'postalCode', etc., check if a constant 
  already exists. If not, create one.
- Components should only: inject services, expose signals/computed for the template, 
  and forward events.

And feedback_unit_tests.md:

name: Unit tests required for services, helpers, and utils
type: feedback

Whenever a new service, helper, or utility file is created, a unit test file 
(.spec.ts) must also be created for it.

Why: User explicitly requested this as a project rule.

How to apply: After writing a new .service.ts, helper.ts, or utils.ts file, 
immediately create the corresponding .spec.ts file with at minimum a basic 
test suite skeleton covering the main logic.

It didn't just remember the rules. It documented why they exist and how to apply them. Like a junior dev writing up notes after a code review — except nobody told it to.

Why this moment stuck with me

Watching it happen in real time in the terminal was different from finding files afterwards.

I saw Claude finish applying my correction, then immediately pivot to: "I should make sure I don't repeat this mistake." And then it built a system to prevent that.

That's not autocomplete. That's not even a smart assistant. That's something closer to a collaborator that takes feedback seriously.

We talk a lot about prompting — how to write better instructions, how to get better output. But what Claude did here is different. It turned my feedback into its own system, without being asked.

What changed in my workflow after this

Since seeing this happen, I've started being more deliberate about corrections. When Claude makes a mistake I've seen before, instead of just fixing it in the moment, I now say:

"This is a pattern I always want you to follow. Make sure you remember this."

And it does. It updates its own memory files.

The result is that my sessions now build on each other instead of starting from zero. The tool gets more useful the longer I work with it — which is exactly what you want from any collaborator.

The honest take

Claude Code still makes mistakes. It still occasionally ignores its own memory. It's not perfect.

But watching it write those files in real time made me realize I'd been thinking about AI tools the wrong way. I was treating each session as isolated.

Claude was treating them as a relationship.

One of us was doing it right.

10 years of Angular. Now learning from my own tools.

Follow @eli_coding on Instagram for weekly posts on Angular, AI and real engineering.

I've Been a Frontend Engineer for 10 Years. Here's How Claude Changed My Workflow in 30 Days.

Eli_coding — Tue, 07 Apr 2026 18:02:38 +0000

A practical, honest account from an Angular developer who was skeptical — and then wasn't.

I'll be upfront: I was one of those engineers who rolled my eyes at AI coding tools.

"It hallucinates," I'd say. "It writes mediocre code." "I can do this faster myself."

10 years of Angular, TypeScript, RxJS, and hard-won debugging instincts will do that to you. You build confidence in your own way of working, and anything that disrupts it feels like noise.

Then I gave Claude a real chance. Not a toy project. My actual work.

This is what I found.

What I was building

I was working on a mid-sized Angular 17 app — signals, standalone components, the whole modern stack. The task: a complex data table with filtering, sorting, inline editing, and real-time updates via WebSockets.

The kind of component that takes a full day to get right, and another day to test properly.

I decided to treat Claude as a pairing partner for the whole thing, from architecture to final polish.

The part that surprised me most: it's not about autocomplete

Before this experiment, I thought of AI coding tools as fancy autocomplete. Type a function signature, get a suggestion, accept or reject.

That's not what Claude is.

The real shift was using it as a thinking partner — before writing a single line of code.

I described the component requirements in plain language and asked: "What are the tradeoffs between using a single datasource with BehaviorSubject vs leveraging Angular Signals with computed state here?"

The answer was genuinely useful. Not because it was magic, but because it forced me to articulate my problem clearly — and then gave me a structured way to think through it. Like a good code review, before the code exists.

Concrete example: the filter logic

Here's a real case. I needed to combine three independent filters — search text, status dropdown, and a date range — into a single reactive stream that the table datasource consumes.

My first instinct was something like this:

// My initial rough sketch
filterByText(items: Item[], text: string): Item[] {
  return items.filter(i => i.name.toLowerCase().includes(text.toLowerCase()));
}

I described the full requirement to Claude and asked for an approach using Angular Signals. It proposed this structure:

export class DataTableComponent {
  private items = signal<Item[]>([]);

  searchText = signal('');
  statusFilter = signal<Status | null>(null);
  dateRange = signal<{ start: Date; end: Date } | null>(null);

  filteredItems = computed(() => {
    const search = this.searchText().toLowerCase();
    const status = this.statusFilter();
    const range = this.dateRange();

    return this.items().filter(item => {
      const matchesSearch = !search || item.name.toLowerCase().includes(search);
      const matchesStatus = !status || item.status === status;
      const matchesDate =
        !range ||
        (item.createdAt >= range.start && item.createdAt <= range.end);

      return matchesSearch && matchesStatus && matchesDate;
    });
  });
}

Honestly? This is close to what I would have written. But it took me 4 minutes instead of 25.

Where it saved me the most time

1. Boilerplate I hate writing

Unit test stubs. Interface definitions from API response shapes. Error handling wrappers. I started pasting in API JSON responses and asking Claude to generate the TypeScript interface. Three seconds. Done.

2. Explaining why something is broken

I'd paste a broken piece of code and describe the symptom — not ask for a fix, just ask for an explanation. The process of getting a structured explanation helped me spot the bug myself, faster than if I'd just stared at the code.

3. Writing tests for things I'd already built

Claude is excellent at generating a first pass of describe/it blocks from a component's public API. They're not perfect, but they're a solid 70% starting point.

Where it still falls short

It doesn't know your codebase. Without context, suggestions can be technically correct but architecturally wrong for your project.

It can be confidently wrong. Especially with Angular-specific APIs that changed in recent versions. Always verify anything touching the framework internals.

It doesn't replace judgment. That's still on me.

What actually changed in my workflow

Three habits I've kept after 30 days:

Before writing a component, I describe it to Claude and ask for an architecture sketch — not code, just the approach.
After writing a function, I paste it in and ask: "What edge cases am I not handling?"
For any PR I'm unsure about, I ask Claude to review it before I submit.

The honest summary

I'm faster. Not 10x — that's marketing speak. But meaningfully faster on the tasks that used to drain me.

If you're an experienced frontend engineer who's been skeptical — I was too. Give it a real 30-day trial on actual work, not toy examples. That's where the value shows up.

Follow me on Instagram @eli_coding for weekly posts on Angular, AI and real engineering.