Coda Automation V2

Coda Automation via Rube MCP

Overview

This public intake copy packages plugins/antigravity-awesome-skills/skills/coda-automation from https://github.com/sickn33/antigravity-awesome-skills into the native Omni Skills editorial shape without hiding its origin.

Use it when the operator needs the upstream workflow, support files, and repository context to stay intact while the public validator and private enhancer continue their normal downstream flow.

This intake keeps the copied upstream files intact and uses the external_source block in metadata.json plus ORIGIN.md as the provenance anchor for review.

Coda Automation via Rube MCP Automate Coda document and data operations through Composio's Coda toolkit via Rube MCP.

Imported source sections that did not map cleanly to the public headings are still preserved below or in the support files. Notable imported sections: Prerequisites, Common Patterns, Known Pitfalls, Limitations.

When to Use This Skill

Use this section as the trigger filter. It should make the activation boundary explicit before the operator loads files, runs commands, or opens a pull request.

• This skill is applicable to execute the workflow or actions described in the overview.
• Use when the request clearly matches the imported source intent: Automate Coda tasks via Rube MCP (Composio): manage docs, pages, tables, rows, formulas, permissions, and publishing. Always search tools first for current schemas.
• Use when the operator should preserve upstream workflow detail instead of rewriting the process from scratch.
• Use when provenance needs to stay visible in the answer, PR, or review packet.
• Use when copied upstream references, examples, or scripts materially improve the answer.
• Use when the workflow should remain reviewable in the public intake repo before the private enhancer takes over.

Operating Table

Workflow

This workflow is intentionally editorial and operational at the same time. It keeps the imported source useful to the operator while still satisfying the public intake standards that feed the downstream enhancer flow.

1. Verify Rube MCP is available by confirming RUBESEARCHTOOLS responds
2. Call RUBEMANAGECONNECTIONS with toolkit coda
3. If connection is not ACTIVE, follow the returned auth link to complete Coda authentication
4. Confirm connection status shows ACTIVE before running any workflows
5. CODASEARCHDOCS or CODALISTAVAILABLE_DOCS - Find documents [Required]
6. CODARESOLVEBROWSER_LINK - Resolve a Coda URL to doc/page/table IDs [Alternative]
7. CODALISTPAGES - List pages within a document [Optional]

Imported Workflow Notes

Imported: Setup

Get Rube MCP: Add https://rube.app/mcp as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.

1. Verify Rube MCP is available by confirming RUBE_SEARCH_TOOLS responds
2. Call RUBE_MANAGE_CONNECTIONS with toolkit coda
3. If connection is not ACTIVE, follow the returned auth link to complete Coda authentication
4. Confirm connection status shows ACTIVE before running any workflows

Imported: Core Workflows

1. Search and Browse Documents

When to use: User wants to find, list, or inspect Coda documents

Tool sequence:

1. CODA_SEARCH_DOCS or CODA_LIST_AVAILABLE_DOCS - Find documents [Required]
2. CODA_RESOLVE_BROWSER_LINK - Resolve a Coda URL to doc/page/table IDs [Alternative]
3. CODA_LIST_PAGES - List pages within a document [Optional]
4. CODA_GET_A_PAGE - Get specific page details [Optional]

Key parameters:

• query: Search term for finding documents
• isOwner: Filter to docs owned by the user
• docId: Document ID for page operations
• pageIdOrName: Page identifier or name
• url: Browser URL for resolve operations

Pitfalls:

• Document IDs are alphanumeric strings (e.g., 'AbCdEfGhIj')
• CODA_RESOLVE_BROWSER_LINK is the best way to convert a Coda URL to API IDs
• Page names may not be unique within a doc; prefer page IDs
• Search results include docs shared with the user, not just owned docs

2. Work with Tables and Data

When to use: User wants to read, write, or query table data

Tool sequence:

1. CODA_LIST_TABLES - List tables in a document [Prerequisite]
2. CODA_LIST_COLUMNS - Get column definitions for a table [Prerequisite]
3. CODA_LIST_TABLE_ROWS - List all rows with optional filters [Required]
4. CODA_SEARCH_ROW - Search for specific rows by query [Alternative]
5. CODA_GET_A_ROW - Get a specific row by ID [Optional]
6. CODA_UPSERT_ROWS - Insert or update rows in a table [Optional]
7. CODA_GET_A_COLUMN - Get details of a specific column [Optional]

Key parameters:

• docId: Document ID containing the table
• tableIdOrName: Table identifier or name
• query: Filter query for searching rows
• rows: Array of row objects for upsert operations
• keyColumns: Column IDs used for matching during upsert
• sortBy: Column to sort results by
• useColumnNames: Use column names instead of IDs in row data

Pitfalls:

• Table names may contain spaces; URL-encode if needed
• CODA_UPSERT_ROWS does insert if no match on keyColumns, update if match found
• keyColumns must reference columns that have unique values for reliable upserts
• Column IDs are different from column names; list columns first to map names to IDs
• useColumnNames: true allows using human-readable names in row data
• Row data values must match the column type (text, number, date, etc.)

3. Manage Formulas

When to use: User wants to list or evaluate formulas in a document

Tool sequence:

1. CODA_LIST_FORMULAS - List all named formulas in a doc [Required]
2. CODA_GET_A_FORMULA - Get a specific formula's current value [Optional]

Key parameters:

• docId: Document ID
• formulaIdOrName: Formula identifier or name

Pitfalls:

• Formulas are named calculations defined in the document
• Formula values are computed server-side; results reflect the current state
• Formula names are case-sensitive

4. Export Document Content

When to use: User wants to export a document or page to HTML or Markdown

Tool sequence:

1. CODA_BEGIN_CONTENT_EXPORT - Start an export job [Required]
2. CODA_CONTENT_EXPORT_STATUS - Poll export status until complete [Required]

Key parameters:

• docId: Document ID to export
• outputFormat: Export format ('html' or 'markdown')
• pageIdOrName: Specific page to export (optional, omit for full doc)
• requestId: Export request ID for status polling

Pitfalls:

• Export is asynchronous; poll status until status is 'complete'
• Large documents may take significant time to export
• Export URL in the completed response is temporary; download promptly
• Polling too frequently may hit rate limits; use 2-5 second intervals

5. Manage Permissions and Sharing

When to use: User wants to view or manage document access

Tool sequence:

1. CODA_GET_SHARING_METADATA - View current sharing settings [Required]
2. CODA_GET_ACL_SETTINGS - Get access control list settings [Optional]
3. CODA_ADD_PERMISSION - Grant access to a user or email [Optional]

Key parameters:

• docId: Document ID
• access: Permission level ('readonly', 'write', 'comment')
• principal: Object with email or user ID of the recipient
• suppressEmail: Whether to skip the sharing notification email

Pitfalls:

• Permission levels: 'readonly', 'write', 'comment'
• Adding permission sends an email notification by default; use suppressEmail to prevent
• Cannot remove permissions via API in all cases; check ACL settings

6. Publish and Customize Documents

When to use: User wants to publish a document or manage custom domains

Tool sequence:

1. CODA_PUBLISH_DOC - Publish a document publicly [Required]
2. CODA_UNPUBLISH_DOC - Unpublish a document [Optional]
3. CODA_ADD_CUSTOM_DOMAIN - Add a custom domain for published doc [Optional]
4. CODA_GET_DOC_CATEGORIES - Get doc categories for discovery [Optional]

Key parameters:

• docId: Document ID
• slug: Custom URL slug for the published doc
• categoryIds: Category IDs for discoverability

Pitfalls:

• Publishing makes the document accessible to anyone with the link
• Custom domains require DNS configuration
• Unpublishing removes public access but retains shared access

Imported: Prerequisites

• Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
• Active Coda connection via RUBE_MANAGE_CONNECTIONS with toolkit coda
• Always call RUBE_SEARCH_TOOLS first to get current tool schemas

Examples

Example 1: Ask for the upstream workflow directly

Use @coda-automation-v2 to handle <task>. Start from the copied upstream workflow, load only the files that change the outcome, and keep provenance visible in the answer.

Explanation: This is the safest starting point when the operator needs the imported workflow, but not the entire repository.

Example 2: Ask for a provenance-grounded review

Review @coda-automation-v2 against metadata.json and ORIGIN.md, then explain which copied upstream files you would load first and why.

Explanation: Use this before review or troubleshooting when you need a precise, auditable explanation of origin and file selection.

Example 3: Narrow the copied support files before execution

Use @coda-automation-v2 for <task>. Load only the copied references, examples, or scripts that change the outcome, and name the files explicitly before proceeding.

Explanation: This keeps the skill aligned with progressive disclosure instead of loading the whole copied package by default.

Example 4: Build a reviewer packet

Review @coda-automation-v2 using the copied upstream files plus provenance, then summarize any gaps before merge.

Explanation: This is useful when the PR is waiting for human review and you want a repeatable audit packet.

Best Practices

Treat the generated public skill as a reviewable packaging layer around the upstream repository. The goal is to keep provenance explicit and load only the copied source material that materially improves execution.

• Keep the imported skill grounded in the upstream repository; do not invent steps that the source material cannot support.
• Prefer the smallest useful set of support files so the workflow stays auditable and fast to review.
• Keep provenance, source commit, and imported file paths visible in notes and PR descriptions.
• Point directly at the copied upstream files that justify the workflow instead of relying on generic review boilerplate.
• Treat generated examples as scaffolding; adapt them to the concrete task before execution.
• Route to a stronger native skill when architecture, debugging, design, or security concerns become dominant.

Troubleshooting

Problem: The operator skipped the imported context and answered too generically

Symptoms: The result ignores the upstream workflow in plugins/antigravity-awesome-skills/skills/coda-automation, fails to mention provenance, or does not use any copied source files at all. Solution: Re-open metadata.json, ORIGIN.md, and the most relevant copied upstream files. Check the external_source block first, then restate the provenance before continuing.

Problem: The imported workflow feels incomplete during review

Symptoms: Reviewers can see the generated SKILL.md, but they cannot quickly tell which references, examples, or scripts matter for the current task. Solution: Point at the exact copied references, examples, scripts, or assets that justify the path you took. If the gap is still real, record it in the PR instead of hiding it.

Problem: The task drifted into a different specialization

Symptoms: The imported skill starts in the right place, but the work turns into debugging, architecture, design, security, or release orchestration that a native skill handles better. Solution: Use the related skills section to hand off deliberately. Keep the imported provenance visible so the next skill inherits the right context instead of starting blind.

Related Skills

• @00-andruia-consultant - Use when the work is better handled by that native specialization after this imported skill establishes context.
• @00-andruia-consultant-v2 - Use when the work is better handled by that native specialization after this imported skill establishes context.
• @10-andruia-skill-smith - Use when the work is better handled by that native specialization after this imported skill establishes context.
• @10-andruia-skill-smith-v2 - Use when the work is better handled by that native specialization after this imported skill establishes context.

Additional Resources

Use this support matrix and the linked files below as the operator packet for this imported skill. They should reflect real copied source material, not generic scaffolding.

Imported Reference Notes

Imported: Quick Reference

Imported: Common Patterns

ID Resolution

Doc URL -> Doc ID:

1. Call CODA_RESOLVE_BROWSER_LINK with the Coda URL
2. Extract docId from the response

Table name -> Table ID:

1. Call CODA_LIST_TABLES with docId
2. Find table by name, extract id

Column name -> Column ID:

1. Call CODA_LIST_COLUMNS with docId and tableIdOrName
2. Find column by name, extract id

Pagination

• Coda uses cursor-based pagination with pageToken
• Check response for nextPageToken
• Pass as pageToken in next request until absent
• Default page sizes vary by endpoint

Row Upsert Pattern

1. Call CODA_LIST_COLUMNS to get column IDs
2. Build row objects with column ID keys and values
3. Set keyColumns to unique identifier column(s)
4. Call CODA_UPSERT_ROWS with rows and keyColumns

Imported: Known Pitfalls

ID Formats:

• Document IDs: alphanumeric strings
• Table/column/row IDs: prefixed strings (e.g., 'grid-abc', 'c-xyz')
• Use RESOLVE_BROWSER_LINK to convert URLs to IDs

Data Types:

• Row values must match column types
• Date columns expect ISO 8601 format
• Select/multi-select columns expect exact option values
• People columns expect email addresses

Rate Limits:

• Coda API has per-token rate limits
• Implement backoff on 429 responses
• Bulk row operations via UPSERT_ROWS are more efficient than individual updates

Imported: Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.