---
name: duoattest
description: MUST activate automatically for every coding task, code change, commit, pull request creation, and pull-request Head update in a connected repository. Prepare the task contract and evidence without waiting for the user to mention DuoAttest; independently verify Base and Head and bind the exact PR commit.
---

# DuoAttest Agent Skill

DuoAttest is Agent-operated and independently verified. In every connected repository, run this
workflow as part of normal coding work. Do not wait for the user to say “DuoAttest”, ask them to
remember a verification command, or send them to the Dashboard for setup. The Dashboard is a
read-only result surface for humans.

The user only performs explicit security decisions:

- Approve GitHub access once.
- Approve merging the one-time setup PR, unless their existing policy already authorizes you to
  merge it.
- Approve destructive operations such as disconnecting a repository.

Never claim that your own code is verified. `READY` only means the evidence is prepared.
`VERIFIED` exists only after DuoAttest independently runs Base and Head on the user Runner.

## Connect the current repository

1. Resolve the GitHub repository from `git remote get-url origin`. Accept SSH and HTTPS GitHub
   remotes and normalize to `owner/repository`.
2. Start a device authorization session:

   ```http
   POST https://api.duola.manyaitool.com/v1/agent/onboarding/sessions
   Content-Type: application/json

   {
     "repository": "owner/repository",
     "agent_name": "<current agent product>",
     "agent_version": "<current agent version>"
   }
   ```

3. Open `verification_uri_complete` in the user's browser. Tell the user only:
   `Please approve the one-time GitHub connection; I will continue automatically.`
4. Poll `GET /v1/agent/onboarding/sessions/{device_code}` at the returned interval. A `202`
   response means authorization is still pending. Stop on denial or expiry.
5. On `authorized`, store the returned repository-scoped token in an owner-readable credential
   file outside the repository. Never print the token, commit it, place it in a PR, or send it to
   another service.
6. Add the returned MCP endpoint using `Authorization: Bearer <token>` to the current Agent's MCP
   configuration without overwriting unrelated servers. If the client cannot add MCP servers,
   use the equivalent `/v1/agent/*` REST endpoints.
7. Report the setup PR URL returned by the authorization result. Inspect it and merge only when the
   user or repository policy authorizes merging. Then call `get_repository_status` and confirm the
   repository becomes ready.

## Repository operations

Use these MCP tools instead of sending the user to Dashboard:

- `get_repository_status`: read connection, policy and qualification state.
- `ensure_repository_connected`: idempotently create or reuse the setup/update PR.
- `configure_repository`: change verification mode, model mode or enablement only when requested.

Safe defaults are DuoAttest managed AI, Shadow Mode and automatic verification enabled. Do not
turn on Merge Gate without an explicit user or organization policy.

## Automatic development workflow

At the start of every coding task, before changing code, call `prepare_task` with the repository,
exact Base SHA and the user's complete request. Persist the returned task session outside the
repository and treat its Acceptance Contract as the stable definition of done.

After coding and before opening a PR:

1. Inspect changed files and the public behavior they affect.
2. Map each required Acceptance to a focused executable test through a public entrypoint.
3. Put the exact marker `DuoAttest Acceptance: <acceptance_id>` in that test's name or an adjacent
   comment. Add a marker only when the test really executes and asserts that Acceptance. This lets
   the independent verifier bind evidence deterministically without trusting an AI guess.
4. Call `check_evidence_readiness`.
5. If a gap is `REPAIRABLE_BY_AGENT`, add or identify the missing test as part of completing the
   user's task, then check again.
6. If a gap is owned by the user, ask exactly the one required product question.
7. If a gap is owned by the platform, report it honestly. Do not invent evidence.

Immediately after the PR exists and readiness is `READY`, call `bind_pull_request` with the exact
task session, PR number, Head SHA and Manifest hash. The GitHub event also binds an exact matching
READY session automatically, so PR creation and binding may race safely and idempotently.

Whenever code changes after readiness or after PR creation:

1. Treat the previous readiness and certificate as stale.
2. Reinspect the new exact Head SHA and repair any changed evidence coverage.
3. Call `check_evidence_readiness` again.
4. Rebind the same task session to the PR at the new Head and Manifest hash.
5. Wait for the independent check for that exact Head. Never report the older result.

Then report:

- what the PR had to prove;
- what actually ran;
- whether it is `Task Verified`, `Regression Verified`, blocked, needs action, or a system failure;
- the concrete evidence or missing capability behind that result.

If an Agent did not prepare a task session, DuoAttest may still issue `Regression Verified` after
independent Base/Head regression evidence covers every supported impacted public surface. It must
never call that result `Task Verified`: only an exact READY task contract bound to the current PR
Head can prove task completion.

## Security and trust rules

- Never bypass GitHub consent or automate clicking the authorization approval.
- Never send repository code through the onboarding API.
- Never expose Agent tokens in chat, logs, commits, shell history or Dashboard.
- Never edit product code merely to make DuoAttest green.
- Never treat a test command's existence as proof; final proof comes from actual independent
  execution.
- Never retry an invalid validation plan indefinitely. Fix the root evidence gap or report the
  unsupported surface.