Issue Campaign

Issue Campaign

An issue campaign is a repeatable solo sequence of exhaustive discovery, issue publication, one unified implementation pull request, and renewed discovery. The main agent owns every phase and spawns no subagent other than the read-only commit early-warning pass that development.md requires for every landed commit.

Use the multi-agent skill and its issue-campaign procedure instead only when the user explicitly asks for a parallel or multi-agent issue campaign.

The user's requested phase boundary controls how far to proceed. Do not infer permission to publish issues, push branches, open pull requests, or merge from an audit-only request.

Apply AGENTS.md's Choose the principled course rule to every admission, disposition, implementation, and review decision.

Read the project, development, and review skills before starting. Use the review skill's Solo Issue Discovery Rounds; issue discovery is independent review, not discussion. Read development.md in full only when implementation is authorized.

Campaign Knowledge Base

Create .wiki/<campaign>/ with a short filesystem-safe campaign name. Preserve any existing campaign directory and reconcile it rather than deleting or assuming a blank slate.

Keep concise, current Markdown documents for:

• repository provenance, architecture, validation ownership, and product boundaries;
• experiments, reproductions, dogfooding, and related issue or pull-request history;
• every raw candidate, its evidence, dependencies, and final disposition, including combinations, splits, rejections, and deferrals with the evidence supporting each decision;
• the published-issue DAG, internal implementation order, the unified cycle pull request, CI and Self-Review iterations, external blockers, and official GitHub createdAt-to-mergedAt cycle timing;
• the exact commit, dependency lock, provisioning command, supported environment contract, and tracked-file census for each discovery round;
• a mandatory coverage matrix that crosses public operations, owners, consumers, declaration spellings and provenance, composition, transform options, input contexts and boundaries, generated artifacts, packaging, CLI, and supported platforms;
• a per-issue consequence matrix and implementation impact record that names every caller, equivalent spelling, provenance, option, context, boundary, artifact, consumer, and platform revalidated by the fix; and
• an integration-command manifest that records and hashes the exact commands, environment, tool versions, triggering change classes, expected artifacts, and clean-consumer setup required before and after each integration-sensitive merge.

Record raw candidates before fact-checking. The knowledge base is the durable place to collect overlapping observations, then combine, split, rewrite, reject, or defer them without losing why.

Give every tracked path and matrix cell a stable ID, and record one row per ID with round, base SHA, matrix hash, path or cell ID, status, evidence, and candidate.

A status is one of four values, and it means something different for a path than for an executable cell:

Reconcile the path census with git ls-files and verify that the matrix covers every public operation and known historical dimension before the round begins. When the round discovers a missing owner, consumer, axis, or interaction, version and re-hash the canonical matrix and execute the added cells.

Reconcile the finished rows against the frozen census and final matrix. Any missing row, UNTESTED, unsupported N/A, or absent evidence makes the round INCOMPLETE.

The knowledge base supports the campaign but is not the final issue body. A published issue must stand alone without access to .wiki.

Discover Issues

Run the review skill's Solo Issue Discovery Rounds over the entire declared campaign scope. That procedure owns the frozen commit, environment contract, tracked-file census, mandatory coverage matrix, and the COMPLETE and INCOMPLETE round states. This section adds only what the campaign itself owns.

Only an explicit user instruction or existing public product contract can exclude a surface or environment. The campaign cannot narrow itself, and an unresolved support-policy question makes the round INCOMPLETE.

Source is only one evidence layer. Exercise real workflows and inspect relevant upstream behavior, history, generated artifacts, consumers, fixtures, public documentation, and closed decisions.

Never combine results from different commits, and never accept a stale, unprovisioned, skipped, contaminated, sampled, or missing-type harness whose tags or declarations collapse to any or unknown as full-round evidence.

Treat the development skill's Forbidden section as an explicit retrospective audit contract, not only a rule for future changes. In every complete round, inspect the current implementation and its history for violations, including code that predates the campaign or passes every test. A verified violation is a meaningful issue candidate. Prove the classification from purpose, control flow, consequence, and history; resemblance or stylistic preference alone is not evidence.

Do not stop after finding enough work for a pull request. Complete the entire scope, adjudicate the full candidate pool, and publish only the surviving issues when authorized.

Every Round Is Full-Scope

Every round re-audits the entire declared scope from scratch against the state it was frozen on. A round is never partitioned: not by package, file, concern, platform, candidate class, validation lane, or pass, not by the areas the last cycle or the last round happened to touch, and not by splitting the scope across rounds so that each one covers a slice. What an earlier round read is never coverage for this one, whether it ran in an earlier cycle against a state a merge has since changed, or earlier in this cycle against the same commit. The review skill's Non-Negotiable Review Law states the same rule for every round and review the campaign runs.