Turn monthly invoice collection into an AgentUse workflow

Create a production-ready AgentUse workflow for monthly invoice collection in my current project.

Start by checking whether this project already provides an AgentUse CLI or pins an AgentUse package version. If it does, use that project-local version through the project's existing package manager for every AgentUse command so the generated files match its runtime.

If the project does not provide AgentUse, do not modify its dependencies and do not install anything globally yet. Bootstrap the latest stable CLI without installation and load its version-matched built-in authoring guidance with:
- npx -y agentuse@latest skills get core --full
- npx -y agentuse@latest skills get creator --full
- npx -y agentuse@latest skills get tester --full

Continue using the same resolved invocation—either the project-local CLI or npx -y agentuse@latest—for models, doctor, test, session inspection, and the supervised run command.

Do not copy those built-in skills into the project. Inspect the existing project structure, agents, available models, project-installed skills, and actual tool or MCP configuration. If the workflow needs a separate project skill or connector that is unavailable, name the missing dependency and its exact setup requirement; do not silently install an unrelated skill or invent commands, connectors, environment variables, or credentials.

Use AgentUse-native built-in tools and already installed AgentUse skills first. When a capability is still missing, inspect these exact reference pages before configuring or recommending it:
- Spreadsheet and CSV skill: https://www.skills.sh/anthropics/skills/xlsx
- Spreadsheet skill audit: https://www.skills.sh/anthropics/skills/xlsx/security/snyk
- Gmail MCP server: https://developers.google.com/workspace/gmail/api/reference/mcp
- Gmail MCP get_message output: https://developers.google.com/workspace/gmail/api/reference/mcp/tools_list/get_message
- Gmail attachment download API: https://developers.google.com/workspace/gmail/api/reference/rest/v1/users.messages.attachments/get
- Google Drive MCP server: https://developers.google.com/workspace/drive/api/reference/mcp
- Authenticated browser skill: https://www.skills.sh/vercel-labs/agent-browser/agent-browser
- Browser skill audit: https://www.skills.sh/vercel-labs/agent-browser/agent-browser/security/snyk
- AgentUse filesystem tool: https://docs.agentuse.io/reference/builtin-tools#filesystem-tool
- AgentUse MCP tool filtering with disallowedTools: https://docs.agentuse.io/reference/agent-syntax#mcp-servers
- Gmail MCP OAuth setup and scopes: https://developers.google.com/workspace/gmail/api/guides/configure-mcp-server
- Drive MCP OAuth setup and scopes: https://developers.google.com/workspace/drive/api/guides/configure-mcp-server
- Drive MCP file eligibility controls: https://developers.google.com/workspace/drive/api/guides/drive-mcp-server-file-eligibility
- agent-browser security controls: https://github.com/vercel-labs/agent-browser/blob/main/docs/src/app/security/page.mdx

Treat registry audit results as installation inputs, not guarantees. Review the linked findings and source files before installing a Skill. Do not install a Skill with a high-risk or failed audit without explaining the finding and receiving my explicit approval; prefer an existing project capability or a lower-risk alternative when one can complete the same job.

These URLs are authoritative inputs to the setup, not permission to install everything. Never substitute a similarly named package or MCP server. Only install an external skill when no existing AgentUse-native capability satisfies the requirement, explain why it is needed, and preserve the user's approval and credential boundaries.

Before designing the agents, audit the real permission surface of every connection. Record the credential identity, OAuth or token scopes, the actual MCP tools returned by the server, resource-level ACLs or filters, and which boundaries are enforced by AgentUse. Classify each intended boundary as Enforced, Partially enforced, or Instruction-only. Do not describe a Gmail label, Drive folder, browser instruction, or prompt sentence as a security boundary unless the credential, connector, or runtime mechanically enforces it.

For AgentUse MCP connections, use disallowedTools to remove every operation the agent does not need. In particular, evaluate Gmail create_draft, label_*, unlabel_*, and list_drafts, plus Drive create_file and copy_file. Put consequential external actions behind an AgentUse approval gate and prefer a dedicated least-privilege identity or permission-separated worker when a connector exposes broader access than this job requires.

Use this prepared execution contract:
- Workflow: receive statement → normalize transactions → search approved sources → verify matches → bundle invoices and report exceptions.
- Service stack: read the statement through a spreadsheet skill and filesystem access; search Gmail through its MCP server, then retrieve attachment bytes with a narrow read-only wrapper around users.messages.attachments.get because get_message returns attachment IDs and metadata rather than file bytes; search and write Google Drive through an available Drive MCP server; retrieve portal invoices through an authenticated browser skill; write the final bundle through a scoped filesystem tool or Drive MCP connection.
- Transaction input: source_row_id, transaction_date, cardholder, raw_vendor, normalized_vendor, amount, and currency.
- Candidate evidence: candidate_document_id, source_uri, attachment_id when applicable, searches attempted, and the match rationale.
- Reconciliation output: invoice_status, confidence when useful, verified output_path, and exception_owner for ambiguous or missing rows.
- Intended context: search only the Gmail labels, Drive folders, authenticated vendor sessions, and output folder that I provide with my representative statement. Treat these as workflow intent until the permission audit shows how each one is mechanically enforced.
- Match rule: vendor, currency, amount, and billing period must support a match. Keep receipts separate from tax invoices.
- Completion: every source row appears exactly once as matched, receipt_only, ambiguous, or missing, with source evidence or searches attempted.
- Boundaries: never purchase, change billing, delete source material, invent a match, send email, or put credentials in an agent file. Mechanically gate any consequential external write exposed by the chosen tools.

Start from this permission-separated reference architecture:
- monthly-invoice-collector: a thin manager that owns the run and delegates each stage.
- statement-normalizer: reads the statement and emits stable normalized transaction rows.
- invoice-finder: uses Gmail, Drive, and authenticated browser access to return candidate documents with evidence.
- invoice-reconciler: verifies matches, classifies exceptions, and writes the final bundle and report.

Keep this split when the roles need different tools, permissions, models, or independent tests. Collapse it into one agent when the actual environment gives every stage the same safe execution context and the split adds no operational value. Explain the final choice.

Create the .agentuse file or files in the project's established agent directory. Use only tools and skills that actually exist locally. Put narrow filesystem paths in each agent's built-in tool configuration and list unused MCP operations under each server's disallowedTools. If a required connector or enforceable boundary is unavailable, produce a valid scaffold and a precise setup requirement instead of pretending the workflow is operational. Do not enable a schedule; the first run must be supervised.

Run doctor on every file with the resolved AgentUse invocation. Run a full mock test of the end-to-end workflow, inspect the session logs and effect WAL, and fix failures. Test reject and revision branches for every approval gate.

After mock validation, prepare the interactive AgentUse setup step for the user. If AgentUse was bootstrapped through npx, use npx -y agentuse@latest setup. If the project pins AgentUse, use the same project-local invocation with setup. The user must complete provider authentication and connector authorization themselves; never request, print, or store their credentials. Do not make global installation a prerequisite for the supervised run.

At handoff, provide:
1. The final agent architecture and file paths.
2. Required connector and authentication setup.
3. A permission matrix showing identity, token scopes, exposed tools, resource controls, and any instruction-only assumptions.
4. Validation evidence and known limitations.
5. The exact interactive setup command I should run and which authorizations I should expect.
6. The exact command for one supervised run against my representative statement.
7. The review checklist I should complete before scheduling it.
8. Only after the supervised workflow is ready, explain that persistent global installation is optional and useful for recurring runs or AgentUse Serve. If AgentUse was bootstrapped through npx, offer the official global installation command for my detected package manager, but do not run it without my approval.