Sigil: GitHub Project Issue Loop

• the user provides a GitHub Project view, project number, or issue queue;
• open issues should be assigned to the current operator before implementation;
• the ticket needs refine to understand context, acceptance criteria, and solution shape;
• invoke define/design/plan artifacts should be created based on issue risk and ambiguity;
• task-session should execute the bounded implementation work;
• the final result should be a branch, commit, PR, issue link, verification summary, and project status update.

• GitHub Project URL, project owner, and project number;
• target repository or repository filter;
• issue number, priority filter, status filter, or selection rule;
• authenticated GitHub CLI/app state;
• local checkout path and base branch;
• Arcanum skills available in the repository;
• known upstream callers, downstream consumers, generated mirrors, and dependency boundaries for the target area;
• existing regression tests, expected failing/covering tests, and validation commands;
• user assignment policy, board status policy, and PR target branch;
• validation commands and CI expectations;
• whether the run is dry-run, plan-only, or execution-authorized.

• GitHub CLI/app owns external issue, project, branch, and PR operations.
• refine owns discovery, seed shaping, dispatch, and handoff artifacts.
• invoke owns define, design, plan, and related templates.
• task-session owns bounded implementation execution and local validation.
• domainspec-subagents-strategy or another subagent strategy owns live subagent dispatch governance when research, review, or experiment subagents are required.
• This sigil must not silently bypass human gates required by subagent strategies, branch protection, project policy, or destructive repo operations.

Telemetry should capture:

• project owner/number/view;
• repository and issue number;
• selection reason;
• claim result and board status result;
• lifecycle route used;
• artifact paths created;
• upstream and downstream dependency map status;
• regression tests created, updated, reused, or blocked;
• scope containment result;
• files changed count;
• validation commands and statuses;
• PR URL;
• CI status at final poll;
• blockers and workflow gaps;
• reflection trigger state.

Use templates/usage-telemetry.md as the default JSONL schema. When repository observability is installed, append telemetry to .arcanum/observability/signals/sigil-invocations.jsonl.

Use templates/regression-boundary-map.md when a run needs a durable dependency map or when the issue touches code, UI behavior, generated artifacts, runtime configuration, data contracts, or shared tests.

• Manual trigger: the user asks to improve the issue loop.
• Usage threshold: 5 meaningful executions.
• Output threshold: 10 generated artifacts since the last reflection.
• Gap threshold: 3 related workflow gaps, such as repeated project-field ambiguity or repeated CI polling uncertainty.
• Severe gap: 1 severe workflow gap, such as claiming the wrong issue, mutating the wrong repository, opening a PR against the wrong base, losing user changes, bypassing a required gate, or reporting CI as settled when it is still running.

Reflection must produce a report using templates/reflection-report.md and must name which contract area should change before editing the sigil.

• operate on exactly one issue unless the user explicitly authorizes batch mode;
• show the issue selection reason before mutation when selection was inferred;
• assign or explicitly explain why assignment was blocked;
• keep project status and linked PR state observable;
• read local repo instructions before code mutation;
• create a branch or worktree that protects unrelated local changes;
• map upstream dependencies and downstream dependents before implementation;
• create, update, or explicitly identify focused regression tests before the fix, or record why no meaningful test can be created;
• include containment validation that proves the fix affected only the intended behavior as far as local evidence can show;
• route through refine, invoke, and task-session according to issue risk rather than always using the same depth;
• preserve human gates required by subagent strategy or project policy;
• produce durable artifacts for non-trivial issues;
• run and report validation commands;
• open or update a PR with issue linkage and verification evidence;
• record telemetry or explain why telemetry storage was unavailable.

• processing several issues in one branch without explicit batch authorization;
• choosing a ticket only because it appears first on the board;
• claiming a ticket without checking repository availability and local checkout state;
• treating gh project item-list output as stable without verifying issue state;
• skipping refine when the ticket body points to docs, audits, or acceptance criteria;
• implementing before mapping upstream/downstream dependencies and intended write scope;
• relying only on a broad full suite without a focused regression test or explicit existing-test rationale;
• widening the fix into adjacent behavior just because a nearby test is convenient;
• creating define/design/plan artifacts for trivial issues just to satisfy ritual;
• using Task Session to execute vague or unresolved work;
• opening a PR without local validation evidence;
• marking CI as passed while checks are still running;
• editing generated .agents/skills surfaces instead of canonical sigil sources.

## GitHub Project Issue Loop Result

- Project: <owner/project-number/view-or-url>
- Repository: <owner/name>
- Issue: #<number> <title>
- Selection reason: <reason>
- Claim result: <assigned|already-assigned|blocked>
- Project status: <status|blocked|not-updated>
- Lifecycle route: <refine|invoke-define|invoke-design|invoke-plan|task-session|subagent-review>
- Dependency map: <upstream/downstream summary or artifact path>
- Regression tests: <created|updated|reused|blocked with rationale>
- Scope containment: <pass|flag|block with evidence>
- Artifacts: <paths>
- Branch/commit: <branch> / <sha>
- PR: <url|not-opened>
- Validation: <commands and status>
- CI: <summary at final poll>
- Telemetry: <written path|not written reason>
- Blockers: <none|list>
- Next step: <review|merge|wait-ci|reflect|continue-loop>