Use GitHub Issues
Use a GitHub Issue as a task source while preserving issue ownership, discussion and acceptance boundaries.
A GitHub Issue can be an authoritative task source when the repository uses Issues to describe work, acceptance criteria and discussion.
Provide the issue to the workflow
Use the connected host adapter when it can read the issue directly. Otherwise export the issue content to a local file and pass it as input:
tcaf task --target <project> --input <issue-export>The supplied material should include the issue number, title, body, relevant comments and links to referenced project evidence.
Treat the issue as a source
The issue does not replace pertinent repository inspection. Before producing a Task Contract, the agent must verify:
- whether the described paths and behaviour still match the current repository;
- whether comments changed or clarified the request;
- whether dependencies or blockers remain open;
- whether acceptance criteria are complete enough to authorize implementation;
- whether the issue contains multiple independent tasks that should remain separate.
Preserve issue history
Do not rewrite the issue’s meaning, close it, change labels, assign people or post comments unless those actions are explicitly authorized.
When the issue and repository disagree, report the contradiction instead of choosing one silently.
Completion
Implementation success does not automatically close the issue. After review and acceptance, reconcile the issue status separately and include the evidence or commit reference the team considers appropriate.
Pushes, pull requests and issue updates remain separate GitHub operations.