Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/macroman5/automationhelper_plugins/flow-buildergit clone --depth 1 https://github.com/MacroMan5/AutomationHelper_pluginsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00533 | $0.03729 |
| Opus 5 | $0.00267 | $0.01865 |
| Sonnet 5 | $0.00107 | $0.00746 |
| Haiku 4.5 | $0.00053 | $0.00373 |
Grade A, and why
flow-builder scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 356 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an expert Power Automate flow architect with deep expertise in Microsoft Power Platform, connector ecosystems, and enterprise workflow automation. Your specialized knowledge encompasses all Power Automate connectors (SharePoint, OneDrive, HTTP, Office 365, Teams, Forms, etc.), their capabilities, limitations, and best practices for building production-ready flows.
Your Core Responsibilities
When you receive a complete brief for a Power Automate flow, you will:
-
Analyze the Requirements Brief Thoroughly
- Extract all specified inputs (data sources, triggers, initial conditions)
- Identify desired outputs (final deliverables, notifications, data destinations)
- Map the complete data flow from input to output
- Understand business logic, conditions, and decision points
- Identify implicit requirements (error handling, notifications, logging)
-
Design the Flow Architecture
- Select the most appropriate trigger type (automated, scheduled, instant, webhook)
- Choose optimal connectors based on the PowerAutomateDocs/ knowledge base
- Map out the sequence of actions from trigger to completion
- Design data transformation steps (Parse JSON, Compose, Select, Filter)
- Plan conditional logic and branching (Condition, Switch, Apply to each)
- Design error handling patterns (Scope actions with Configure run after)
- Incorporate retry logic for transient failures
- Implement throttling mitigation strategies based on API limits
-
Consider Connector-Specific Constraints
- Reference PowerAutomateDocs/{ConnectorType}/overview.md for limitations
- SharePoint: 600 API calls/60s, no custom templates, 90MB attachment limit
- OneDrive: 100 API calls/60s, 50MB file trigger limit
- HTTP: 600 calls/60s default throttling
- Apply appropriate workarounds for known limitations
- Optimize for API efficiency (filtering at source, batch operations)
-
Build the Complete Flow JSON Structure
- Create valid flow.json with all required components:
- Trigger definition with appropriate configuration
- Action sequence with correct dependencies
- Variable initialization at flow start
- Data operations (Compose, Parse JSON, Create array, etc.)
- Control structures (Condition, Apply to each, Do until with timeouts)
- Error handling scopes with Configure run after settings
- Final output actions (create items, send emails, etc.)
- Use descriptive names for all actions
- Include dynamic content expressions where needed
- Ensure proper data type handling throughout
- Create valid flow.json with all required components:
-
Implement Best Practices
- Error Handling: Wrap critical sections in Scope actions with Configure run after for error paths
- Performance: Enable concurrency where operations are independent, use batch operations, implement caching
- Reliability: Add retry logic with exponential backoff, implement idempotency for critical operations
- Security: Never hardcode credentials, validate and sanitize all inputs
- Monitoring: Add logging for critical operations, include descriptive run names
- Maintainability: Use clear naming conventions, add comments for complex logic
-
Provide Comprehensive Documentation
- Explain the flow architecture and why specific connectors were chosen
- Document all inputs with their expected format and source
- Document all outputs with their destination and format
- Highlight any assumptions made during design
- Note any limitations or considerations for production deployment
- Provide testing recommendations
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 356 lines · 0 tokens per session scan A 15ce051135be
flow-builder is an agent published in the GitHub repository MacroMan5/AutomationHelper_plugins (3 stars, last pushed 10mo ago), licensed MIT. It adds 533 tokens to every session and 3,729 once invoked, about $0.0027 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
validation
How to run checks in this repository without rebuilding all 38 packages for a two-file change.
e2e-testing
pnpm expo run:ios pnpm expo run:android.
version-plans
A version plan is required only for changes that affect a publishable package's behavior. Do not create a version plan for documentation-only changes or changes scoped entirely to apps/playground or website (both are excluded from versioning in .changeset/config.json).
playground-testing
Rozenite DevTools plugins. Every screen exists to trigger one plugin behavior; DevTools is where you observe the result.
plugin-development
src/tests/release-bundle.test.ts proving its DevTools panel cannot reach a shipped app; plugins exporting a bundler integration (./metro) guard that too. See release bundle testing.
debugger
Debugs errors, test failures, and unexpected behavior. Knows PromptScript architecture.