u/Low-Possibility9122

Looking for Android/iOS testers for Health Connector Toolbox, a free health-data API explorer

Looking for Android/iOS testers for Health Connector Toolbox, a free health-data API explorer

Hi everyone!

I'm the author of health_connector, an open-source Flutter SDK that gives you a single API for both Android Health Connect and Apple HealthKit - so you write your health-data code once instead of twice.

I'm now preparing Health Connector Toolbox, a free app that lets you explore the SDK on a real device - request permissions, read and write records, and see what each platform actually returns - without cloning the repo or setting up a dev environment.

What I'm looking for:

  • Android: join the closed test and stay opted in for 14 days (Google Play requires this before production release - you don't need to open the app daily)
  • iOS: join via TestFlight
  • Feedback on the app and on the SDK's capabilities
  • Suggestions for developer tools that are missing

The app is free, with no ads and no account required.

If you're interested, comment or DM me and I'll send an invite. Thanks a lot in advance!

u/Low-Possibility9122 — 1 day ago
▲ 2 r/AI_developers+1 crossposts

Agent skill plugins have a dependency-management gap

Suppose you publish two agent skills:

    skills/
    ├── skill_a  ← depends on skill_b
    └── skill_b

This creates two problems:

  1. Users can install an incomplete skill. Installers often show a flat list without dependency information, so someone may install skill_a without skill_b.
  2. Authors can break dependencies silently. If skill_b is renamed, archived, or deleted, skill_a may still contain outdated/invalid instructions pointing to it.

Can we trust humans or AI agents to keep every hardcoded reference synchronized? In my experience, no.

So I built an open-source agent plugin compiler:

plugin manifest + skill sources
              ↓
           compiler
              ↓
skills/ + Claude and Codex plugin manifests

The compiler:

  • validates missing, circular, and invalid skill dependencies;
  • embeds required skills inside the skills that need them;
  • generates standard plugin output for Claude and Codex automatically;

If both skills are public, skill_b remains independently installable while also being embedded into skill_a:

skills/
├── skill_a/              # `skil_a` is self-contained
|   ├── SKILL.md
|   └── refernces/
|       └── skills/
|           └── skill_b/
└── skill_b

But sometimes skill_b is only a reusable building block and should not be exposed to users. Authors can mark it as internal in the plugin.yml manifest file, so result will be:

skills/
└── skill_a/
    ├── SKILL.md
    └── skills/
        └── skill_b/
            └── SKILL.md

In both cases, users can install skill_a by itself and get everything it needs. The difference is whether skill_b is also published as a standalone skill.

The project is MIT-licensed and currently an early npm prerelease. I’d appreciate feedback.

GitHub: https://github.com/fam-tung-lam/ptlam-agent-plugin-compiler

NPM: https://www.npmjs.com/package/@fam-tung-lam/ptlam-agent-plugin-compiler/v/0.1.0-alpha.2

u/Low-Possibility9122 — 11 days ago