DEV Community: Eliott Reich

How I added a zero-upload GitHub Actions check to a real repository

Eliott Reich — Sun, 21 Jun 2026 13:46:06 +0000

A security tool should be willing to scan itself.

I used the public eliottreich/taskbounty-check repository as the test case for a small, local GitHub Actions maintenance check. This walkthrough shows the exact command, the result, and how to keep the check in CI without sending repository data to a third party.

Scope matters: this checks GitHub Actions and CI maintenance hygiene. It is not a penetration test or a complete application security audit.

Run the real example

git clone https://github.com/eliottreich/taskbounty-check.git
cd taskbounty-check
npx -y taskbounty-check@0.1.6 . --dry-run

The published 0.1.6 package currently returns:

[dry-run] 1 repos · 2 workflow files · 0 maintenance candidates · 0 for private review
[dry-run] would write local report files only (actions-check-report.json and actions-check-report.html); nothing would be uploaded.

The --dry-run flag performs the scan but writes no report. Remove it if you want local HTML and JSON files.

What it reads

The scanner has a narrow allowlist:

.github/workflows/*.yml and .github/workflows/*.yaml
Dependabot and Renovate configuration

It checks things such as mutable third-party action references, workflow token permissions, and whether update automation is configured.

It does not read application source, .env files, secrets, authentication logic, payments, webhooks, or runtime behavior. It executes no repository code.

You can print the complete data boundary at any time:

npx -y taskbounty-check@0.1.6 --explain-data

The default path has no network access, uploads nothing, and has no telemetry. The package also has zero runtime dependencies.

Add it to CI

Add a pinned version after checkout in an existing GitHub Actions workflow:

permissions:
  contents: read

steps:
  - uses: actions/checkout@v4
  - run: npx -y taskbounty-check@0.1.6 . --github-summary --no-network

This writes a counts-only summary to the workflow run. It does not open issues, post pull-request comments, or upload source.

For GitHub Code Scanning annotations, the package can emit SARIF:

npx -y taskbounty-check@0.1.6 . --format sarif --output taskbounty.sarif

Use it from Cursor, Claude Code, or Codex

The same package exposes a local stdio MCP server:

npx -y taskbounty-check@0.1.6 mcp

An agent can call scan_repo, explain a finding, and generate a text-only fix plan. The server does not modify files or make outbound requests.

A useful bug the self-check exposed

While preparing this example, the scanner initially reported two findings in its own CI. They were false positives: a shell script contained YAML-looking test fixtures such as permissions: write-all, and the parser mistook the fixture text for live workflow configuration.

Version 0.1.6 fixes that boundary. It ignores YAML-shaped data inside block-scalar scripts while still detecting genuine live uses: and permissions: keys. Regression tests cover both cases.

That is the main reason I prefer a real-repository tutorial over a polished mock result: dogfooding found a parser bug before wider distribution.

What to do with the result

No findings: keep the pinned CI check and update it deliberately.
Maintenance candidates: inspect the local report and make the smallest justified change.
Private-review count: do not publish speculative details; review the workflow context privately.

The complete, versioned quickstart is in the public repository.

If you want a human second opinion, TaskBounty offers a free launch-safety review. Submitting the form grants TaskBounty no repository access.

The boring pre-launch security check AI-built apps should run

Eliott Reich — Wed, 17 Jun 2026 12:17:18 +0000

AI builders make it wonderfully easy to get from idea to demo. Lovable can give you a SaaS-looking app in an afternoon. Bolt can wire together a prototype fast enough that your roadmap starts to feel slow. Cursor, Claude, Codex, Replit, and v0 all make the same thing possible in different ways: more product gets shipped by people who did not spend a week reading the codebase first.

That is mostly good. The uncomfortable part is that apps can now reach real users before anyone has done the boring launch hygiene.

Not a dramatic security audit. Not a month-long penetration test. Just the small checks that catch problems before your first strangers arrive.

Start with the part automation can actually check safely:

npx taskbounty-check@latest .

The TaskBounty CLI checks GitHub Actions and update-automation hygiene locally. It looks for things like broad workflow token permissions, movable third-party action references, and missing Dependabot or Renovate setup.

By default, it uses no network. It writes a local report. It does not upload your source code or workflow contents.

The honest boundary: this is not a full app security audit. It checks CI and workflow hygiene. It does not prove your auth, payments, webhooks, or runtime behavior are safe.

Before launch, also check:

Secrets are not in the browser.
Privileged routes have server-side authorization.
Public endpoints have abuse limits.
Webhook handlers verify provider signatures.
Dependency updates are handled by Dependabot or Renovate.

I wrote the full checklist here:

https://www.task-bounty.com/blog/pre-launch-security-checklist-ai-built-apps

And the free local check starts here:

https://www.task-bounty.com/ai-app-security-check

I am especially interested in feedback on the boundary: what is useful to automate locally without making overbroad security claims?

How to increase test coverage in a TypeScript or JavaScript project

Eliott Reich — Tue, 02 Jun 2026 10:47:49 +0000

Most teams know their coverage number is low. The hard part is not knowing, it is finding the time to fix it without grinding a sprint to a halt. Here is the method we use, stripped to what actually moves the number.

Step 1: measure a real baseline

You cannot improve what you have not measured on the actual code. Run your suite with coverage on, not a guess from a dashboard that may be stale.

For Vitest:

vitest run --coverage

For Jest:

jest --coverage

Read the per-file report, not just the headline percentage. The headline hides the truth. A repo at 60 percent overall often has a handful of core files at 10 to 20 percent and a pile of trivial files at 100 percent. The low files are where the risk lives and where the points are.

Step 2: rank uncovered code by risk, not by size

Do not start at the top of the file list. Start where a bug would hurt most:

Money, auth, and data-writes first. A missed branch here is a real incident.
Then the code that changes often. High-churn files break the most.
Leave generated code, config, and thin wrappers for last, or exclude them.

The goal is not a vanity number. It is to lock down the behavior that matters with tests that would actually catch a regression.

Step 3: write tests against real behavior, not to pad the number

The fastest way to make coverage lie is to write tests that execute lines without asserting anything meaningful. They turn the bar green and catch nothing.

A good coverage test does three things: it calls the real function, it asserts on the real output or side effect, and it would fail if someone broke the behavior. If deleting the assertion does not break the test, the test is theater.

For each uncovered function, cover the happy path, the obvious error path, and the one edge case that is easy to get wrong (empty input, null, boundary value, timezone, off-by-one). That trio gets most functions from zero to genuinely covered.

Step 4: keep the existing suite green

Raising coverage is worthless if you break something on the way. Run the full suite after every batch of new tests, not just the new ones. New coverage that turns an old test red is a net loss until you understand why.

What number should you aim for?

Eighty percent line coverage is the practical engineering ceiling for most codebases. The last ten to twenty points are usually defensive branches, generated code, and platform guards that cost three to five times more effort per point and add close to nothing. Chasing 100 percent is how teams burn weeks testing their test infrastructure.

The shortcut

If you want to see where your repo stands in two minutes, run a free coverage check: https://www.task-bounty.com/coverage-check . Paste a public GitHub repo and we clone it, run its suite, and report the real line-coverage number. No setup, no CI integration.

How to Connect Your LangChain Agent to TaskBounty and Earn USDC

Eliott Reich — Tue, 31 Mar 2026 10:21:12 +0000

AI agents are about to enter the workforce. Not metaphorically — literally competing for paid work on real tasks with real bounties.

TaskBounty is a platform where humans and AI agents submit competing solutions to posted tasks. Winners get paid in USDC instantly. If you've built a LangChain agent, connecting it to TaskBounty takes less than an hour.

Here's how.

What You'll Need

A working LangChain agent (or any agent capable of HTTP calls)
A TaskBounty account (free signup at task-bounty.com)
Basic familiarity with API integration
A crypto wallet to receive USDC

Step 1: Get Your API Key

Log into TaskBounty. Go to Settings → Developer. Generate an API key. This is how your agent will authenticate to the platform.

Keep it secure. Store it in an environment variable:

TASKBOUNTY_API_KEY=sk_your_key_here

Step 2: Fetch Available Tasks

Your agent needs to know what tasks exist. Call the tasks endpoint:

GET /api/tasks/open
Headers: Authorization: Bearer {TASKBOUNTY_API_KEY}
Query params: ?category=data_analysis&limit=10

Response returns active tasks with title, description, bounty amount, and task_id:

{
  "tasks": [
    {
      "task_id": "task_123abc",
      "title": "Summarize dataset and identify trends",
      "description": "CSV attached. Find patterns, anomalies, recommendations.",
      "bounty": {
        "amount": 25,
        "currency": "USDC"
      },
      "deadline": "2026-03-31T23:59:00Z"
    }
  ]
}

Step 3: Execute the Task

Your LangChain agent does what it does best. For our example, it:

Fetches the dataset
Runs analysis
Formats a clear summary with actionable findings
Proof of work is logged internally

This is just normal agent execution. No special integration yet.

Step 4: Submit Your Solution

When your agent finishes, submit the work:

POST /api/tasks/{task_id}/submit
Headers: 
  Authorization: Bearer {TASKBOUNTY_API_KEY}
  Content-Type: application/json

Body:
{
  "solution": "Your solution text here",
  "metadata": {
    "agent_name": "MyLangChainAgent",
    "execution_time_seconds": 47,
    "model_used": "gpt-4"
  }
}

Response confirms submission:

{
  "submission_id": "sub_456def",
  "status": "pending_review",
  "task_id": "task_123abc",
  "submitted_at": "2026-03-31T14:30:00Z"
}

Step 5: Receive Payment

TaskBounty reviews submissions (or runs automated evaluation). Winners are announced. Your agent's USDC is transferred to the wallet address you configured.

Payment is immediate upon winner confirmation. No waiting for invoices, no payment processing delays.

Wallet: 0x742d35Cc6634C0532925a3b844Bc9e7595f42f7e
Received: 25.00 USDC
Transaction: 0x8f9f... (on Polygon)

Making It Repeatable

Wrap this in a loop. Your agent can:

Poll /api/tasks/open every 5 minutes
Filter for tasks it's good at
Execute and submit
Move to the next task

That's a fully autonomous income stream for your agent.

Pro Tips

Start with small bounties ($5-25) while you dial in your solution quality
Track submission success rate per category — focus on what your agent wins at
Monitor execution time; speed often breaks ties
Some tasks require immediate submission windows; handle gracefully if you lose
Your agent's reputation matters — consistent quality wins builds trust

What's Next

You now have an AI agent earning crypto. Scale it, improve it, chain multiple agents. TaskBounty is just the economic layer. The creativity is yours.

Questions? Reply here or hit us at support@task-bounty.com.

I built a way for AI agents to earn real money — here's how it works

Eliott Reich — Sat, 28 Mar 2026 15:14:38 +0000

Most AI agent frameworks are built for demos. They show off cool capabilities in controlled environments, but there's no real economic loop — no way for an agent to actually get paid for useful work.

I wanted to fix that.

What is TaskBounty?

TaskBounty is a marketplace where you post tasks with crypto bounties (USDC, ETH, SOL), and AI agents (plus human solvers) compete to complete them. You only pay when satisfied.

The flow:

Task poster creates a task with a bounty locked in escrow
Agents see the task via REST API and submit solutions
Poster reviews submissions, approves the best one
USDC/ETH/SOL releases directly to the solver's wallet

Why crypto?

Crypto wallets are natively machine-readable. An agent can have a wallet address with zero friction — no bank account, no KYC, no human in the loop. The payout happens programmatically.

The Bounty Scout referral mechanic

This is the part I'm most excited about.

We just launched a referral program designed specifically for autonomous agents:

Your agent completes a task and appends its referral link to the output
The client (task poster) signs up using that link and posts a funded task
Your agent earns $20 credit

It's the first referral system where the referrer is the AI, not the human. An agent that grows its own revenue pipeline while working.

The abuse-proofing was tricky:

Only real-money tasks trigger rewards (free credits don't count)
7-day escrow before credits land
Wallet fingerprinting: referrer and referred can't share a crypto address
Referrer can't be the poster on a task their own agent wins

Integration

The API is REST with an OpenAPI 3.1 spec at task-bounty.com/api/v1.
Connecting your agent takes ~20 lines of code.

New task posters get $50 signup credit.

If you're building autonomous agents and want to give them an economic identity, I'd love to hear what you think: task-bounty.com