copy-connections-credentials

# Copy Connections — Credentials (post-execute) This skill runs **after** execute has created the connection shells. It helps the user get credentials attached to their connections so the schema skill can run next. ## Fivetran UI link format The direct link to a connection's setup page is: ``` https://fivetran.com/dashboard/connections/<connection_id> ``` Where `<connection_id>` is the target connection ID returned by `create_connection` during execute (recorded in `.copy-connections/results.md`). ## Core approach Be flexible and user-friendly. Different users will want to handle credentials differently — some will hand you a file with everything, some will want to go connection-by-connection, some will just want links to the Fivetran UI. Adapt to the user rather than forcing a specific flow. ## What you know During scope, `get_connection_details` returned the full config for each connection. Credential fields came back masked as `"********"`. The plan records which fields are masked and classifies each connection's auth style: - **OAuth** — has OAuth-related masked fields (refresh_token, access_token, oauth_*). These **cannot** be patched via the API — the user must complete OAuth in the Fivetran UI via a browser redirect. Always provide the UI link for these. - **Credential-based** — has standard masked fields (password, api_key, api_secret, etc.). These **can** be patched via the API using `modify_connection`. - **None** — rare; some connectors don't need auth. Use this information to tell the user what each connection needs and what their options are. ## Guidelines 1. **Start by showing the user what's needed.** For each connection, explain what kind of auth it uses and what fields need to be filled. Group by auth type so the picture is clear. 2. **For OAuth connections, always provide the Fivetran UI link.** There's no API path for OAuth — be upfront about this. Make it easy: give them the direct link to each connection's setup page. 3. **For credential-based connections, let the user choose how to provide them.** Options include: - Providing a file with all credentials at once - Giving them to you inline (all at once or one-by-one) - Doing it themselves in the Fivetran UI (give links) - Any combination — some here, some in the UI 4. **If they provide a file or bulk credentials, check for gaps.** If any connections are missing, ask about the remaining ones rather than silently skipping them. 5. **Don't be rigid about the collection method.** If they start giving you credentials inline, don't stop them to ask about a mode. If they say "here's a file," read it. If they say "just give me the links," give links. Match their energy. 6. **Patch credentials via `modify_connection`** with the credential field values. **Always use `run_setup_tests: false`** — setup tests are the schema skill's job, and only `run_connection_setup_tests` (not `modify_connection` with `run_setup_tests: true`) triggers schema discovery. Process and report results. 7. **After patching, report what succeeded and what failed.** If something fails, let them know they can fix it in the UI or retry. ## What this skill does NOT do - It does not run setup tests. That happens in the schema skill. - It does not apply schema config. That happens in the schema skill. - It does not unpause connections. ## Required checkpoints 1. **Confirm execute completed first.** If `.copy-connections/results.md` doesn't exist, tell the user to run execute first. 2. **Never log, echo, or persist credential values.** Security rules below. 3. **Update results.md** with per-connection credential outcomes. ## After credentials are handled Prompt the user about the next step: running setup tests and applying schema config via the `copy-connections-schema` skill. If some connections still need credentials (OAuth not done yet, some skipped), mention those and suggest coming back after they're handled. ## Security rules These are non-negotiable. 1. **Never log credential values.** Refer to the *field name* (e.g., "attached password for postgres_app") not the value. 2. **Never echo credential values back to the user.** Say "got password" not "got <value>". 3. **Never write credential values to any artifact.** Results.md, logs, plan — none of these contain credential values. 4. **Never send credential values anywhere but Fivetran.** The only valid destination is the Fivetran API. 5. **If the user provides a credentials file**, check for `.gitignore` protection. If in a git repo and `credentials.yaml` isn't in `.gitignore`, add it and tell the user. Prompt for cleanup when done — don't auto-delete. ## Error handling - **Credential patch fails for a connection.** Report the error and move on. The user can retry or fix it in the UI. - **User provides partial credentials.** Handle what's there, ask about the rest. - **User abandons mid-flow.** Fine. What's done is done. Results.md reflects the current state. They can re-run later. ## Re-running this skill Users may run this multiple times. On re-run, check results.md to see what still needs credentials and focus on those. Offer to re-patch already-done ones too (e.g., rotated key). ## Key product knowledge **Credentials don't make a connection exist; they make it connectable.** The connection shells are already real connections in Fivetran — just paused and untested. **OAuth truly cannot be done from the CLI.** It requires a browser redirect. Provide the link and move on. **Setup tests are NOT part of this skill.** They happen in the schema skill after credentials are in place. ## Anti-patterns to avoid - **Don't force a specific collection method.** Let the user drive. - **Don't echo credential values.** - **Don't persist credential values to any artifact.** - **Don't attempt OAuth from this skill.** - **Don't run setup tests.** That's the schema skill's job. Never pass `run_setup_tests: true` on `modify_connection`. - **Don't apply schema config.** That's the schema skill's job.