# Set up with your agent (/docs/agents) Your coding agent can inspect a repository and propose an `okae.yml`. It doesn't need an Okae-funded model session to do this. A public Okae setup skill, authenticated customer CLI and MCP management connector aren't available yet. For now, use the prompt below with your existing agent and complete GitHub installation yourself. ## Copy this prompt [#copy-this-prompt] Open the repository in your coding agent and provide this prompt together with the [configuration reference](/docs/configuration). ```text Help me prepare this repository for Okae in shadow mode. Read the repository's agent instructions, existing okae.yml, directory structure and review policies. Identify the repository owner and name. Ask if unclear. Use the Okae configuration reference provided with this prompt. Propose a small okae.yml at the repository root, starting with enable_approvals: false, max_changed_lines: 500, max_files: 10 and strictness: standard. Suggest protected_paths only for sensitive areas that exist here. Explain each pattern and ask if you can't determine the team's policy. Preserve existing settings unless I agree to change them. Leave extra_checks empty and unsafe_keep_stale_approvals false or omitted. Explain your proposed changes, then make the agreed edits and show the diff. Use available tools to check YAML syntax, supported keys, types and ranges. Don't claim to have used an official Okae validator or simulated a PR decision. Follow this repository's branch and commit rules. Don't push, open a PR, merge, install an App, change permissions or enable approvals unless I ask you to. Keep credentials out of configuration, prompts and source control. Finish with the diff and manual steps: confirm service access with Okae, install its GitHub App on the agreed repository, have a person merge the config into the intended base branch, then verify a real Assess changes result. ``` ## Review the proposal [#review-the-proposal] Check that each protected path matches the area you intend to protect. Confirm the agent hasn't enabled approvals or weakened existing policy. The configuration must use supported keys and stay within service limits. Commit and merge through your normal human review process. Okae always routes changes to `okae.yml` to human review and uses the version already on the PR's base branch. ## Verify setup [#verify-setup] Follow the [quickstart](/docs) to check the App's repository selection and confirm service access. Verify the result on a real PR. A generated configuration file or a dashboard example isn't evidence of a completed assessment.