This document defines how we use GitHub Issues and related planning features. It is the reference for agents working with our issues and for skills that perform GitHub planning or backlog management.

The operating procedures belong in the relevant skills. This standard defines the objects, relationships, metadata, and requirements those skills must follow.

Our organizational structure:

Project
└── Milestone
    └── Epic
        └── User story
            └── Delivery task

Milestone consistency is mandatory: an epic, all its stories, and all their delivery tasks must share the epic’s milestone. Work intended for a different milestone must be organized under a separate epic for that milestone. The earlier cross-milestone exception is removed.

A standalone bug or maintenance issue may have no parent when there is no meaningful epic or story. It must still have its Project membership and the appropriate type:bug or type:chore label, plus other applicable metadata. Selected delivery work must have a milestone. Missing parentage does not exempt an issue from classification.

Every issue must contain:

Before execution, the issue must identify its responsible assignee and applicable Project. Parent, milestone, iteration, and blocking relationships must be present where relevant.

Implementation pull requests and commits must be linked as they become available.

All work must have a ticket. The ticket defines bounded work and records its results; it does not independently authorize unrelated work or external actions.

The following taxonomy is the draft baseline. Adoption must account for existing labels rather than create an overlapping taxonomy. Publishing the standard does not itself relabel existing issues.

The epic marker describes an issue’s level in the hierarchy. Work type describes its primary purpose. An epic may therefore carry both epic and a work-type label.

Priority expresses the relative importance of delivering work.

Priority does not eliminate dependency, readiness, or authorization requirements. It does not establish an exact ordering between issues with the same value.

Severity expresses the impact of a defect.

Severity does not automatically set priority or authorize interruption, emergency changes, or expanded scope.

• Labels must have clear descriptions and consistent names.
• Labels with different names must not duplicate the same meaning.
• Colors must support readability; color alone must not convey meaning.
• New labels must address a recurring classification need that existing labels cannot represent.
• Ordinary issue creation must use the established taxonomy rather than invent a parallel one.
• Changes to the taxonomy must identify how existing labels and affected issues will be handled.
• Label removal must account for the classification information that would be lost.

Each planning attribute must have one authoritative location. For example, priority belongs in the Priority field and workflow state belongs in Status; separately maintained labels must not compete with those values.

Board state must reflect actual work rather than an intended next action.

Blocked work retains its current workflow state and carries the appropriate impediment label. The issue must identify the blocking cause, related dependency where applicable, and what is needed to unblock it.

A closed issue marked not planned is not completed delivery and must not be represented as Done. Reports must distinguish completed work from work that was declined, cancelled, or closed as a duplicate.

A parent issue is complete only when its own outcome and acceptance criteria are satisfied. Closed children alone do not establish parent completion.

For example, this acceptance criterion fails:

Issues have appropriate metadata.

This passes:

Every epic has the epic label and exactly one approved work-type label. Its stories and delivery tasks have the same milestone as the epic. The reviewer reports any missing or conflicting assignments.

A required finding must identify:

• The requirement that was not met.
• The observed deviation.
• The correction needed.

The review result is Pass when applicable requirements are satisfied or covered by valid exceptions. It is Changes required when unresolved noncompliance remains.

Optional improvements and reviewer preferences are not blocking requirements.

Skills derived from this standard must use these requirements as evaluation criteria. Evaluations must cover both compliant behavior and relevant failures, including incomplete metadata, incorrect relationships, unauthorized changes, and premature completion.

An exception is a bounded, approved departure from a specific requirement. It is justified when following that requirement would not reasonably serve the actual work and an alternative is necessary.

The exception record must identify:

• The affected requirement.
• The reason for the departure.
• The alternative and its consequences.
• The affected scope.
• The approving authority.
• Its duration or ending condition.
• How normal compliance will resume, where applicable.

The owner or an explicitly designated exception authority must approve the departure before it is used. Agents cannot approve their own exceptions.

The affected issue must link to the approval. An exception applies only to its recorded scope and duration; previous exceptions do not establish standing permission.

This exception mechanism cannot override STOP instructions, security restrictions, or external-action authorization requirements.

GitHub issues hold current work, status, acceptance records, useful decisions, verification results, and remaining blockers. They must not become per-turn diaries.

Ticket-owned implementation plans live in the Wiki. The owning issue links to the plan and its reviewed revision rather than duplicating its full text.

The Wiki is canonical for development standards, product specifications, and architecture decisions. Code, assets, and documentation that must match the implementation remain repository-owned.

This document is the authoritative reference for how we use GitHub Issues and related planning features. Relevant skills define the operating procedures and reference these requirements rather than maintaining competing definitions.

Publishing or revising this standard does not itself restructure the backlog, modify Project configuration, or migrate labels.