Repository access

Connect a repository when the Task needs a working copy of code or files. Decide separately whether the result must be delivered through a pull request. Repository access, provider actions, and approval of the result are different decisions.

Repository context and pull-request delivery are separate

Every task has one repository picker. Choose No repository required, Project default, or an available repository. The choice and resolved source context are durable, so a later project or workspace default does not silently change existing work. Project default is always available, and choosing it again resolves the project's current setting.

The project separately decides whether repository-backed tasks require pull-request delivery. The Project setting applies to existing and future tasks, but becomes active only while a task has a repository. A task set to No repository required therefore uses ordinary completion review.

When the setting is off, an agent may still link a pull request as optional delivery evidence. There is no pull-request override on the task.

When an Agent discovers that a Task needs source context, it can request repository access. Task Machine checks the task's saved repository choice, blocks only that task, and sends one Repository needed decision to an eligible human in the Inbox. The human can choose an active workspace repository or create one there.

Repository-free work remains valid until the agent makes this explicit request, and task text never triggers it on its own.

Set repository defaults

A Project can supply repository defaults for new Tasks. A Task can explicitly use a repository or declare that one is not required. Existing work keeps its own context, so do not assume changing a Project default rewrites every Task already running.

Complete access and checkout

Add the repository's public key

When you create a repository, Task Machine prepares its repository SSH key and shows the public part to copy. Add that public key at your Git provider before expecting Cloud work to clone or push. Do not paste your personal private key into Chat or a Task.

Give the key a recognizable title. Read-only access is appropriate when the Agent needs source context but should not push changes.

Recover from a checkout or access failure

A repository-access Inbox item keeps the public key, provider instructions, status, and retry action together. If the key is not ready, use Retry key setup. After adding the public key at the provider, use Retry task for Task work or Retry repository for a Chat or rule discovery in that same item.

Rule discovery does not need a Task or Chat behind it. Its recovery item goes to a human who can manage repositories, and retry starts a fresh discovery attempt through the ordinary execution checks.

A checkout failure may instead require correcting the clone URL or access. A retry that cannot be scheduled leaves the item open. Dismissing it does not repair the connection. See Setup and recovery.

Keep Local access and provider actions distinct

Cloud requires Task Machine's repository key. A Local Worker can use the offered repository key alongside the machine's existing SSH setup, or use existing local access when Task Machine has no repository key. A failed or unreachable key request is not treated as permission to fall back silently.

A working copy does not grant provider API capabilities such as pull-request actions. Configure the appropriate Connector and its credentials separately. Use Local execution when you deliberately choose to run on your own machine.

Open a repository

Select a repository in Repositories to open its page. The Rules tab lists the code review rules that internal code review checks. A manager can add a custom rule, turn rules on or off, and run Rule discovery, which reads the repository and proposes rules. Proposed changes appear in that card, where you can approve or reject each one, and in your Inbox. Deciding in either place completes the decision.

Each rule row also shows what happened to its blocking findings in recent reviews: how many the implementing agent fixed and how many it dismissed. A dismissal is the agent's own judgment, so a high share of dismissals is a reason to look at the rule, not proof that it is wrong.

Choose View details in a rule's menu to read its full question, where it applies, where it came from, and its dismissed share.

When the implementing agents keep dismissing a rule's findings across several tasks, Task Machine suggests turning that rule off. The suggestion appears as a change in the repository's rule proposal, in that card and in your Inbox. It shows how many findings were fixed and dismissed and the latest reasons the agents gave. Nothing changes until you approve it, and a rejected suggestion returns only if the rule's question changes.

Proposed additions reach the review only after Task Machine checks the proposer's violating and valid examples. A failed check creates no proposal. Screening passed means the rule distinguished those examples under the current check, not that it has proved correct for every change. Open the badge's explanation for the context. Older or unassessed additions can only be rejected and proposed again.

Rules you add directly in the Rules tab do not go through this proposal screening. Reviewing a proposal still leaves the final decision with you.

The Settings tab holds the repository's name, clone URL, and default branch, its SSH setup, whether it is the workspace default, and archiving. The same actions stay available from each row's menu in Repositories.

Review repository metadata changes

An Agent can propose correcting a repository's name, clone URL, or default branch without changing its accepted metadata while you review. The Inbox proposal keeps the proposer, rationale, changed values, and Approve and Reject actions together. An unset branch uses the provider's default. Approval rechecks the observed repository before applying the candidate, and a later edit closes stale requests as skipped rather than overwriting newer metadata.

Repository updates have an independent Ask first / Automatic setting. Changing metadata never provisions access to a new clone target, changes credentials or SSH setup, selects a global default, or archives the repository. Complete provider access separately when the clone target changes.

Keep coding guidance with the repository

Put instructions for Task Machine runs in TAMA.md, in the repository's working folder. Both Cloud and Local Workers use it instead of AGENTS.md. Keep your interactive coding process in AGENTS.md, for example how you land changes on your own computer, and put the agent's delivery instructions in TAMA.md.

You can share a project guide without copying it into both files. Tell your interactive agent to read the guide from AGENTS.md, and import it into TAMA.md with an @ reference:

# Instructions for Task Machine

@docs/engineering.md

Keep unfinished source in the supplied working folder for the next run.

Task Machine reads imports before the file that names them. Paths resolve from that file's folder and stay inside the run's working folder. If TAMA.md is absent, runs use the existing repository instructions. A broken import stops startup with an error rather than silently using different guidance.

Repository guidance sets coding conventions and required checks. It cannot grant access, authorize deployment, or replace Task Machine's approval and review rules. See CLI commands for the exact file and import behavior.

Preserve the delivery evidence

Agents are instructed to keep repository source changes in Git or the working folder shared by the Task or Chat. Expect available branch, commit, or pull-request links as delivery evidence, rather than an attached repository archive or text checkpoint. A failed check, blocked publication, or ending Run does not permit an attachment handoff.

Screenshots, logs, business deliverables, and patch evidence you explicitly request can still be supporting attachments. They support the decision without replacing source delivery. Repository access still does not require a pull request unless the Task's delivery rules call for one.

Review the exact pull-request revision and the checks that support it. Requested changes should return concrete feedback to the work. Approval can continue into delivery rather than immediately making every Task complete. Keep the Task's result and history as the durable record.

Read Pull requests and delivery when work must produce a reviewed code change.