Set up with your agent
Use your existing coding agent to prepare repository configuration.
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
Open the repository in your coding agent and provide this prompt together with the configuration reference.
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
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
Follow the quickstart 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.