executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
procore-core-workflow-aImplement a governed Procore RFI lifecycle from read-only discovery through an approved create or update. Use when integrating RFI intake, assignment, response tracking, attachments, or closure without guessing workflow transitions. Trigger with: "automate Procore RFIs", "create a Procore RFI", "sync RFI status".
Independent GitHub snapshot · Automated classification · Original documentation governs
name: procore-core-workflow-a description: >- Implement a governed Procore RFI lifecycle from read-only discovery through an approved create or update. Use when integrating RFI intake, assignment, response tracking, attachments, or closure without guessing workflow transitions. Trigger with: "automate Procore RFIs", "create a Procore RFI", "sync RFI status". allowed-tools: Read, Grep, Write, Edit version: 2.0.0 argument-hint: '[rfi-operation-and-project]' model: inherit effort: high license: MIT author: Jeremy Longshore jeremy@intentsolutions.io tags:
Treat an RFI as a permissioned construction record with project configuration and business transitions, not generic CRUD. Derive fields and allowed actions from the current RFI reference and target project before submitting a mutation.
List or show a representative RFI to confirm response shape, configurable fields, status values, and project access. Follow Link-header pagination for inventory reads.
Capture subject, question, RFI manager, assignees, due-date policy, attachments, and notification choice. Resolve every referenced user or resource inside the same project.
Check required fields against the live endpoint reference and project configuration. Present a sanitized mutation preview and require an identified approver.
Send the documented request only after approval. Record the response ID and status immediately; never infer success from a network timeout.
Read the RFI after each material transition. Drive responses, distribution, acceptance, or closure only through documented endpoints and fields rather than invented status strings.
Store identifiers, before-and-after state hashes, actor, timestamp, and outcome without construction narrative or attachment contents.
RFI calls use an OAuth 2.0 Bearer token and the required company routing context. Effective access comes from the user or DMSA permissions, project membership, and whether the RFI tool is enabled.
Use Read and Grep to inspect endpoint contracts, project configuration, and existing adapters. Use Write or Edit only for the approved adapter, test, mutation manifest, or redacted receipt; do not perform an unapproved RFI mutation.
Return the project, operation, RFI identifier, observed transition, approval reference, and unresolved dependencies.
A field issue becomes an RFI only after the integration resolves the project RFI manager and validates required fields. The service previews the request, records approval, creates once, and reads the returned record before notifying downstream systems.
| Failure | Response |
|---|---|
| Required user is invalid | Resolve membership in the target project; do not substitute another user. |
| 403 or hidden 404 | Check app connection, RFI permissions, project membership, and tool enablement. |
| 422 validation response | Surface the provider error and project field contract; do not strip fields blindly. |
| Mutation outcome is unknown | Reconcile by returned ID or an approved correlation key before retrying. |