owner/repository in the request still wins.
Working branch
By default daoco reads the repository’s default branch and opens pull requests against it. If your deployed content lives on a different branch, such as a release branch, choose it as the working branch on the connection card. daoco then reads files from that branch, creates new branches from it, and targets it with pull requests. A branch named in the request still wins. GitHub’s code search only covers the default branch. When a working branch is set, daoco lists directories on that branch instead of relying on search, so files that exist only there are still found. The working branch belongs to the default repository. Any other repository you name in a request uses its own GitHub default branch instead. Update the working branch whenever your release branch changes.Approval and access
Reads can run without approval. Unless the connection is set to Never ask, every GitHub write requires approval in chat, even when the brand works autonomously or the request comes from a recurring task. Approval applies to one named tool and its hash-bound input. Approving an issue write does not approve a merge, deletion, workflow run, or any later call. To stop being asked, open the GitHub connection’s access settings and choose Never ask. daoco then creates issues, branches, commits, and pull requests on that connection without an approval card, including from recurring tasks. Deleting something still asks every time. A code or content change is one write. daoco proposes it as a single pull request: when approval is required, the card shows the repository, the base branch, the new branch name, the pull request title, every file with its size, and the description. Approving it creates the branch, commits those exact files, and opens the pull request in one step, and daoco replies with the pull request link so a reviewer can merge it. When approval is required, changing any of those details needs a new approval. One pull request carries at most 20 files; a larger change has to be split. The app can read repository metadata and contents, search code, and list issues and pull requests. It can create issues, branches, file commits, and pull requests only after daoco’s write-approval gate accepts that exact call. Changes made before disconnecting remain in GitHub. Disconnecting removes daoco’s access; it does not undo issues, branches, commits, pull requests, comments, or other completed actions.Content and article pull requests
daoco has an internal GitHub workflow for repository-backed content. It first reads comparable files to learn the repository’s directory, filename, front matter, image, and formatting conventions. It then proposes one pull request that carries the new branch, the full file contents, and the pull request title and description, and asks for a single approval unless the connection is set to Never ask. If a new article needs a publication date such aspublishedAt, and neither your request nor the saved article supplies one, daoco uses the current date in your timezone, or UTC when no timezone is available. It follows the repository’s date format and notes the default in the pull request description without asking a separate date question. Explicit dates and existing publication dates are preserved. The default does not change the article’s draft or published status or publish it to your site.
After the pull request opens, daoco links the saved article to that repository file and branch, so the article shows PR open until the pull request merges. daoco then reads the file on the deploy branch and the public page on its own: a match on the branch shows Merged, not live yet, and it keeps checking until the live page matches and shows Published. Check now in Website > Pages or the article panel (or “is it live yet?” in chat) checks right away. See Articles.
If a later step inside that write fails, daoco reports the branch and the files already committed instead of guessing whether GitHub applied the call or deleting anything automatically.
Content that cannot be authored safely from repository evidence becomes an issue for a maintainer. This includes application code, shared templates, schema markup, redirects, build configuration, and changes that depend on product or engineering judgment.
Permissions
The GitHub App requests repository metadata read access plus read and write access for contents, issues, and pull requests. GitHub limits each installation to the repositories selected during setup. daoco briefly exchanges GitHub’s user-authorization code to verify that the installer can access the installation, then discards that user token. Repository work always uses short-lived installation tokens; daoco does not store a personal access token or broad account OAuth token. An organization owner may need to approve the installation request. If GitHub records a request instead of an installation, daoco reports that state and does not create a connection until an owner approves it. If the card later says the connection is missing its installation details, choose Reconnect and run the install again.Connect GitHub
1
Open GitHub in Connections
Open Connections -> Integrations -> Work & Knowledge and choose GitHub.
2
Choose Connect
Choose Connect. GitHub opens its authorization page for the daoco App. Approve it. daoco uses that identity only to check which installations you can reach, then discards the token.
3
Choose an owner and repositories
If you have not installed the app yet, GitHub takes you to the installation page. Pick your personal account or an organization, then grant all repositories or select the repositories daoco should use. GitHub returns you to daoco automatically.
4
Set the default
Open the ⋯ menu on the connected GitHub card and choose Default repository. Pick the repository daoco should use when a request does not name one. If deployed content lives on a release branch, pick it as the working branch in the same dialog, then choose Save default.
5
Verify from chat
Ask daoco to read a file from the default repository.
Example requests
- “Read the existing articles in this repository, then open a PR for the approved draft.”
- “Open GitHub issues for the SEO findings that need engineering work.”
- “Review the open pull requests touching the marketing site.”