@windyroad/itil 3.4.0 → 3.5.0-preview.1376

package/.claude-plugin/plugin.json

@@ -486,5 +486,5 @@
     }
   },
   "name": "wr-itil",
-  "version": "3.4.0"
+  "version": "3.5.0"
 }

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "wr-itil",
-  "version": "3.4.0",
+  "version": "3.5.0",
   "description": "ITIL problem-management workflows for AI coding agents",
   "author": {
     "name": "Windy Road Technology",

package/README.md

@@ -103,6 +103,7 @@ require the new package. New users can install planning without ITIL.
 | Skill | Purpose | Maturity |
 | ------- | --------- | --- |
 | `/wr-itil:outcome-led-planning` | Compatibility entrypoint for the standalone planning workflow; remains usable without installing planning | Experimental |
+| `/wr-itil:setup-github-tracking` | Configure missing selected GitHub tracking for the planning compatibility workflow | Experimental |
 | `/wr-itil:manage-problem` | Create, update, and close problem tickets through the Open → Known Error → Verifying → Closed lifecycle | Alpha |
 | `/wr-itil:capture-problem` | Foreground-lightweight aside-invocation variant of `manage-problem` (per the "Governance skill invocation patterns — foreground + background with deferred-question resumption" architecture rule background-capture pattern + the "Problem 078: Assistant does not offer to capture a problem ticket when the user delivers strong-signal correction" problem capture-on-correction) — drafts a ticket scaffold without losing the operational thread when a problem signal surfaces mid-conversation | Experimental |
 | `/wr-itil:work-problem` | Pick the highest-WSJF actionable ticket and work it to completion | Experimental |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/itil",
-  "version": "3.4.0",
+  "version": "3.5.0-preview.1376",
   "description": "ITIL-aligned IT service management for Claude Code and Codex",
   "bin": {
     "windyroad-itil": "./bin/install.mjs"

package/skills/outcome-led-planning/SKILL.md

@@ -30,7 +30,7 @@ Keep the confirmed objective as the reference point throughout delivery. Ordinar
 
 After confirming the SMART outcome, read [project tracking and shared contributions](references/project-tracking.md). Both planning and `contribute` read the same project configuration, defaulting to `.agents/planning.json`. Reuse a saved or explicit choice. When none exists, ask one question: **GitHub Issues or Local?** Wait, save the answer, read it back, and reuse it across sessions. Preserve unrelated configuration and honor explicit changes; do not silently replace malformed or unsupported settings.
 
-Local mode needs no GitHub account or Project. When GitHub is selected, read [the GitHub coordination protocol](references/github-coordination.md) before planning or tracker mutations; use its [bootstrap instructions](references/github-coordination.md#bootstrap-github-tracking) for missing selected setup. Project fields and views apply only to selected or required Projects. Configuration grants no access, messaging or automation authority.
+Local mode needs no GitHub account or Project. When GitHub is selected, read [the GitHub coordination protocol](references/github-coordination.md) before planning or tracker mutations. Invoke the installed [setup-github-tracking skill](../setup-github-tracking/SKILL.md) when selected setup is missing or incomplete; reuse verified complete setup. Project fields and views apply only to selected or required Projects. Configuration grants no access, messaging or automation authority.
 
 ## Build the current plan
 

package/skills/outcome-led-planning/references/github-coordination.md

@@ -12,67 +12,15 @@ Before creation, search existing open and closed issues and read likely matches.
 
 ## Bootstrap GitHub tracking
 
-Inspect before changing setup: the chosen repository/owner, authenticated actor,
-permissions, planning configuration, linked Project, labels or issue types,
-fields/options, saved views and relevant built-in workflows. Reuse equivalent
-existing mappings and custom organization; names alone do not establish that
-something is missing. Preserve IDs, existing options, labels, colours, layouts
-and user-saved filters. Setup intent grants no new credentials, owner scope or
-public visibility. Use supported APIs/CLI or an authorized browser, not guessed
-view mutations or new access grants.
-
-Project fields and views apply **only when Project tracking is selected or
-repository-required**. Reuse the configured Project; create one only when that
-choice requires it, none exists and existing authority permits it. GitHub
-Issues-only and conversation/local tracking need no Project, views or fields.
-Once selected or required, Project setup and updates are part of delivery.
-Optional describes the choice to use a Project, not permission to skip that
-choice after it is made. Complete missing applicable setup at the first work
-checkpoint using available authorized tools. A default unfiltered View 1 is not
-equivalent to the three kind-specific views below. If setup cannot be completed,
-record the exact missing settings and next recovery action on the existing
-increment; keep setup incomplete until its saved state is verified.
-For shared Project tracking, reuse the same project-declared configuration
-(default `.agents/planning.json`), following the shared project-tracking
-preservation rules. Create or update only needed settings: `version: 1`, `backend: github`,
-`github.repository`, `github.projectUrl` and `contributors` entries mapping each
-actual contributor's `agent` and responsible `human`. Derive identities and URLs
-from verified context; store no tokens or connection identifiers. Agent and human
-may be the same account. Record different semantic mappings in existing project
-guidance/configuration, not another registry.
-
-Create only missing essentials, using these defaults when no equivalent mapping
-is established:
-
-- **Record kinds:** `kind:outcome`, `kind:increment`, `kind:task` labels. Reuse an
-  existing equivalent issue-type/label mapping; do not migrate organization issue
-  types or add a duplicate Kind field merely to follow this convention.
-- **Increment horizons:** `horizon:now`, `horizon:next`, `horizon:later` labels,
-  mirrored by the Horizon field. Each open planned increment has one horizon;
-  outcomes/tasks have none. Clear completed/superseded increments' active horizons.
-- **Status:** single-select Ready, In progress, Blocked, Reviewing, Done. An
-  established equivalent such as Todo for Ready is valid. Add missing semantic
-  options without replacing existing option IDs or unrelated configured values.
-- **Horizon:** single-select Now, Next, Later; **Agent:** text containing the exact
-  distinct agent/session or Unclaimed. Reuse native Title, Assignees, Parent
-  issue, Sub-issues progress and Linked pull requests fields. Add no default
-  priority, estimate, iteration or date fields without an outcome-specific need.
-
-Create a saved view only when its equivalent is missing. These are **new-Project
-defaults**, not instructions to reset existing saved layouts or filters:
-
-1. **Outcomes:** table, filter `label:kind:outcome`; show Title, Status, Assignees,
-   Agent and Sub-issues progress.
-2. **Increments:** table, filter `label:kind:increment`; group by Horizon
-   ordered Now/Next/Later; show Title, Parent issue, Horizon, Status, Assignees,
-   Agent, Linked pull requests and Sub-issues progress. Retain closed increments
-   without an active Horizon so delivery history remains accessible.
-3. **Tasks:** board, filter `label:kind:task`; use Status columns and show Title,
-   Assignees, Agent, Parent issue and Linked pull requests on cards as available.
-
-Preserve existing custom views and access to closed/history records. Show
-hierarchy only where it does not leak unrelated record kinds into a filtered
-view; inspect actual visible items. No mandatory roadmap or per-agent view.
+When GitHub tracking is selected and its applicable setup is missing or incomplete,
+invoke the installed [setup-github-tracking skill](../../setup-github-tracking/SKILL.md).
+Reuse verified complete setup. Local needs no GitHub setup; Issues-only needs no
+Project. The setup skill preserves the same project configuration, authority,
+equivalent mappings and real records. A selected Project remains a delivery
+obligation; unavailable settings stay precisely pending rather than claimed complete.
+Ongoing issue creation and work checkpoints below still apply after setup.
+
+## Apply real issue tracking
 
 Apply each real issue's correct kind marker and explicitly add it to the selected
 Project when creating it. Set native parent/sub-issue and genuine blocked-by
@@ -82,30 +30,6 @@ membership alone does not satisfy a saved kind filter. Verify both, then check
 that the legitimate record appears in its intended view. Do not create dummy
 issues to test setup or add an auto-add workflow in place of explicit membership.
 
-Inspect relevant existing built-in automation for effects conflicting with
-verified closure or manual ownership. Do not silently disable/replace it, enable
-auto-close/archive or add recurring jobs/GitHub Actions merely for bootstrap.
-
-Save changed layouts, filters, grouping and visible fields, then reopen the view
-or read its persisted configuration. Verify the Project link, semantic
-fields/options, view names/layouts/filters/grouping/columns and the first real
-issues' kind, membership and native relationships when those issues exist.
-A temporary unsaved view,
-accepted API request or empty item list does not prove setup. A second pass
-reuses complete setup and creates nothing. If permission or tooling cannot
-configure or inspect a specific setting, record that exact gap and pending mirror;
-preserve issue-side truth and continue useful authorized work. Do not claim a
-view property that was not inspected or block all work on an optional mirror.
-
-Use GitHub's current controls for [managing and saving views][github-views],
-[table fields/grouping][github-table], [board columns/cards][github-board] and
-[view filters][github-filters].
-
-[github-views]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/managing-your-views
-[github-table]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-table-layout
-[github-board]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-board-layout
-[github-filters]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/filtering-projects
-
 ## Outcome → increment → task
 
 Use three linked issue levels, without introducing an epic or story tier:

package/skills/outcome-led-planning/references/project-tracking.md

@@ -30,7 +30,7 @@ Optional `contributors` mappings may identify an agent account and responsible h
 
 **Local:** use the existing conversation or agreed local plan/artifact for the confirmed outcome, current Now revision, owners, contributions, dependencies and evidence. Shared local work uses its agreed records and authorized channel. It needs no GitHub accounts, issues, labels, Project, fields or views. If no contributor is available, continue useful authorized solo work without inventing helpers.
 
-**GitHub:** read [the GitHub coordination protocol](github-coordination.md) before planning, claims or issue/Project mutations. Issues carry outcome → increment → task; an optional selected Project mirrors them. Bootstrap only missing selected setup, preserve equivalent existing configuration and verify actual saved results. Backend choice grants no authentication, access, messaging, public visibility or recurring automation authority.
+**GitHub:** read [the GitHub coordination protocol](github-coordination.md) before planning, claims or issue/Project mutations. Issues carry outcome → increment → task; an optional selected Project mirrors them. For missing or incomplete selected setup, invoke the installed [setup-github-tracking skill](../../setup-github-tracking/SKILL.md); reuse verified complete setup, preserve equivalent existing configuration and verify actual saved results. Backend choice grants no authentication, access, messaging, public visibility or recurring automation authority.
 
 ## Expose useful contributions without reserving the backlog
 

package/skills/setup-github-tracking/SKILL.md

@@ -0,0 +1,110 @@
+---
+# Generated by scripts/sync-planning-skill.mjs; edit packages/planning instead.
+name: wr-itil:setup-github-tracking
+description: "Configure missing GitHub issue tracking and selected Project fields and views for outcome-led planning. Use when GitHub tracking is selected and setup is missing or incomplete, or when explicitly asked to repair that setup; reuse complete setup and bypass Local mode."
+---
+
+# Set up GitHub tracking
+
+Make the selected tracking setup usable for the existing outcome. This skill configures tracking; it does not establish a new objective, create an executable delivery plan or claim ownership of the outcome.
+
+Read [shared project tracking](../outcome-led-planning/references/project-tracking.md) and the existing project instructions. Reuse the project-declared configuration path and saved choice. If Local is selected, return without GitHub setup. If no backend choice is established, leave that decision to the calling planning/contribute workflow; do not silently select GitHub. Reuse verified complete setup without reconfiguration or repeat questions. For missing selected setup, inspect current state and change only what is needed within existing authority. Ask one focused question and wait only when a genuinely missing setup fact cannot be established from context or authorized inspection.
+
+## Configure missing selected setup
+
+Inspect before changing setup: the chosen repository/owner, authenticated actor,
+permissions, planning configuration, linked Project, labels or issue types,
+fields/options, saved views and relevant built-in workflows. Reuse equivalent
+existing mappings and custom organization; names alone do not establish that
+something is missing. Preserve IDs, existing options, labels, colours, layouts
+and user-saved filters. Setup intent grants no new credentials, owner scope or
+public visibility. Use supported APIs/CLI or an authorized browser, not guessed
+view mutations or new access grants.
+
+Project fields and views apply **only when Project tracking is selected or
+repository-required**. Reuse the configured Project; create one only when that
+choice requires it, none exists and existing authority permits it. GitHub
+Issues-only and conversation/local tracking need no Project, views or fields.
+Once selected or required, Project setup and updates are part of delivery.
+Optional describes the choice to use a Project, not permission to skip that
+choice after it is made. Complete missing applicable setup at the first work
+checkpoint using available authorized tools. A default unfiltered View 1 is not
+equivalent to the three kind-specific views below. If setup cannot be completed,
+record the exact missing settings and next recovery action on the existing
+increment; keep setup incomplete until its saved state is verified.
+For shared Project tracking, reuse the same project-declared configuration
+(default `.agents/planning.json`), following the shared project-tracking
+preservation rules. Create or update only needed settings: `version: 1`, `backend: github`,
+`github.repository`, `github.projectUrl` and `contributors` entries mapping each
+actual contributor's `agent` and responsible `human`. Derive identities and URLs
+from verified context; store no tokens or connection identifiers. Agent and human
+may be the same account. Record different semantic mappings in existing project
+guidance/configuration, not another registry.
+
+Create only missing essentials, using these defaults when no equivalent mapping
+is established:
+
+- **Record kinds:** `kind:outcome`, `kind:increment`, `kind:task` labels. Reuse an
+  existing equivalent issue-type/label mapping; do not migrate organization issue
+  types or add a duplicate Kind field merely to follow this convention.
+- **Increment horizons:** `horizon:now`, `horizon:next`, `horizon:later` labels,
+  mirrored by the Horizon field. Each open planned increment has one horizon;
+  outcomes/tasks have none. Clear completed/superseded increments' active horizons.
+- **Status:** single-select Ready, In progress, Blocked, Reviewing, Done. An
+  established equivalent such as Todo for Ready is valid. Add missing semantic
+  options without replacing existing option IDs or unrelated configured values.
+- **Horizon:** single-select Now, Next, Later; **Agent:** text containing the exact
+  distinct agent/session or Unclaimed. Reuse native Title, Assignees, Parent
+  issue, Sub-issues progress and Linked pull requests fields. Add no default
+  priority, estimate, iteration or date fields without an outcome-specific need.
+
+Create a saved view only when its equivalent is missing. These are **new-Project
+defaults**, not instructions to reset existing saved layouts or filters:
+
+1. **Outcomes:** table, filter `label:kind:outcome`; show Title, Status, Assignees,
+   Agent and Sub-issues progress.
+2. **Increments:** table, filter `label:kind:increment`; group by Horizon
+   ordered Now/Next/Later; show Title, Parent issue, Horizon, Status, Assignees,
+   Agent, Linked pull requests and Sub-issues progress. Retain closed increments
+   without an active Horizon so delivery history remains accessible. Enable
+   **Show hierarchy**, save the view and reopen it to verify hierarchy remains On.
+   The increment kind filter selects roots; related task children are expected
+   hierarchy content and must remain accessible under their increment.
+3. **Tasks:** board, filter `label:kind:task`; use Status columns and show Title,
+   Assignees, Agent, Parent issue and Linked pull requests on cards as available.
+
+Preserve existing custom views and access to closed/history records. Increments
+hierarchy MUST be On, including equivalent existing views. Inspect real increment
+roots and their legitimate related children; exclude unrelated roots rather than
+disabling hierarchy to hide task children. No mandatory roadmap or per-agent view.
+
+For existing real issues, verify kind, explicit Project membership, native relationships and applicable fields as described in the [ongoing issue protocol](../outcome-led-planning/references/github-coordination.md#apply-real-issue-tracking). New issues follow that same protocol throughout delivery. Do not create dummy issues to test setup.
+
+Inspect relevant existing built-in automation for effects conflicting with
+verified closure or manual ownership. Do not silently disable/replace it, enable
+auto-close/archive or add recurring jobs/GitHub Actions merely for bootstrap.
+
+Save changed layouts, filters, grouping and visible fields, then reopen the view
+or read its persisted configuration. Verify the Project link, semantic
+fields/options, view names/layouts/filters/grouping/columns, persisted Increments
+hierarchy On and the first real
+issues' kind, membership and native relationships when those issues exist.
+A temporary unsaved view,
+accepted API request or empty item list does not prove setup. A second pass
+reuses complete setup and creates nothing. If permission or tooling cannot
+configure or inspect a specific setting, record that exact gap and pending mirror;
+preserve issue-side truth and continue useful authorized work. Do not claim a
+view property that was not inspected or block all work on an optional mirror.
+
+Use GitHub's current controls for [managing and saving views][github-views],
+[table fields/grouping][github-table], [board columns/cards][github-board] and
+[view filters][github-filters].
+
+[github-views]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/managing-your-views
+[github-table]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-table-layout
+[github-board]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-board-layout
+[github-filters]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/filtering-projects
+
+## Return to the current work
+
+Read back saved configuration and changed provider state before reporting what is complete. Return the actual repository/selected Project, reused or changed settings and any precise unresolved operation to the caller in its existing plan or discussion. Do not create another report, config, plan, task backlog or recurring process. Keep incomplete settings explicit and continue useful work under the existing coordination and authority rules; never claim an uninspected view property. Subsequent issue creation and work checkpoints remain governed by the [GitHub coordination protocol](../outcome-led-planning/references/github-coordination.md).

package/skills/setup-github-tracking/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Set up GitHub Tracking"
+  short_description: "Configure selected issue tracking and Project views"

package/skills-codex/outcome-led-planning/SKILL.md

@@ -39,7 +39,7 @@ Keep the confirmed objective as the reference point throughout delivery. Ordinar
 
 After confirming the SMART outcome, read [project tracking and shared contributions](references/project-tracking.md). Both planning and `contribute` read the same project configuration, defaulting to `.agents/planning.json`. Reuse a saved or explicit choice. When none exists, ask one question: **GitHub Issues or Local?** Wait, save the answer, read it back, and reuse it across sessions. Preserve unrelated configuration and honor explicit changes; do not silently replace malformed or unsupported settings.
 
-Local mode needs no GitHub account or Project. When GitHub is selected, read [the GitHub coordination protocol](references/github-coordination.md) before planning or tracker mutations; use its [bootstrap instructions](references/github-coordination.md#bootstrap-github-tracking) for missing selected setup. Project fields and views apply only to selected or required Projects. Configuration grants no access, messaging or automation authority.
+Local mode needs no GitHub account or Project. When GitHub is selected, read [the GitHub coordination protocol](references/github-coordination.md) before planning or tracker mutations. Invoke the installed [setup-github-tracking skill](../setup-github-tracking/SKILL.md) when selected setup is missing or incomplete; reuse verified complete setup. Project fields and views apply only to selected or required Projects. Configuration grants no access, messaging or automation authority.
 
 ## Build the current plan
 

package/skills-codex/outcome-led-planning/references/github-coordination.md

@@ -12,67 +12,15 @@ Before creation, search existing open and closed issues and read likely matches.
 
 ## Bootstrap GitHub tracking
 
-Inspect before changing setup: the chosen repository/owner, authenticated actor,
-permissions, planning configuration, linked Project, labels or issue types,
-fields/options, saved views and relevant built-in workflows. Reuse equivalent
-existing mappings and custom organization; names alone do not establish that
-something is missing. Preserve IDs, existing options, labels, colours, layouts
-and user-saved filters. Setup intent grants no new credentials, owner scope or
-public visibility. Use supported APIs/CLI or an authorized browser, not guessed
-view mutations or new access grants.
-
-Project fields and views apply **only when Project tracking is selected or
-repository-required**. Reuse the configured Project; create one only when that
-choice requires it, none exists and existing authority permits it. GitHub
-Issues-only and conversation/local tracking need no Project, views or fields.
-Once selected or required, Project setup and updates are part of delivery.
-Optional describes the choice to use a Project, not permission to skip that
-choice after it is made. Complete missing applicable setup at the first work
-checkpoint using available authorized tools. A default unfiltered View 1 is not
-equivalent to the three kind-specific views below. If setup cannot be completed,
-record the exact missing settings and next recovery action on the existing
-increment; keep setup incomplete until its saved state is verified.
-For shared Project tracking, reuse the same project-declared configuration
-(default `.agents/planning.json`), following the shared project-tracking
-preservation rules. Create or update only needed settings: `version: 1`, `backend: github`,
-`github.repository`, `github.projectUrl` and `contributors` entries mapping each
-actual contributor's `agent` and responsible `human`. Derive identities and URLs
-from verified context; store no tokens or connection identifiers. Agent and human
-may be the same account. Record different semantic mappings in existing project
-guidance/configuration, not another registry.
-
-Create only missing essentials, using these defaults when no equivalent mapping
-is established:
-
-- **Record kinds:** `kind:outcome`, `kind:increment`, `kind:task` labels. Reuse an
-  existing equivalent issue-type/label mapping; do not migrate organization issue
-  types or add a duplicate Kind field merely to follow this convention.
-- **Increment horizons:** `horizon:now`, `horizon:next`, `horizon:later` labels,
-  mirrored by the Horizon field. Each open planned increment has one horizon;
-  outcomes/tasks have none. Clear completed/superseded increments' active horizons.
-- **Status:** single-select Ready, In progress, Blocked, Reviewing, Done. An
-  established equivalent such as Todo for Ready is valid. Add missing semantic
-  options without replacing existing option IDs or unrelated configured values.
-- **Horizon:** single-select Now, Next, Later; **Agent:** text containing the exact
-  distinct agent/session or Unclaimed. Reuse native Title, Assignees, Parent
-  issue, Sub-issues progress and Linked pull requests fields. Add no default
-  priority, estimate, iteration or date fields without an outcome-specific need.
-
-Create a saved view only when its equivalent is missing. These are **new-Project
-defaults**, not instructions to reset existing saved layouts or filters:
-
-1. **Outcomes:** table, filter `label:kind:outcome`; show Title, Status, Assignees,
-   Agent and Sub-issues progress.
-2. **Increments:** table, filter `label:kind:increment`; group by Horizon
-   ordered Now/Next/Later; show Title, Parent issue, Horizon, Status, Assignees,
-   Agent, Linked pull requests and Sub-issues progress. Retain closed increments
-   without an active Horizon so delivery history remains accessible.
-3. **Tasks:** board, filter `label:kind:task`; use Status columns and show Title,
-   Assignees, Agent, Parent issue and Linked pull requests on cards as available.
-
-Preserve existing custom views and access to closed/history records. Show
-hierarchy only where it does not leak unrelated record kinds into a filtered
-view; inspect actual visible items. No mandatory roadmap or per-agent view.
+When GitHub tracking is selected and its applicable setup is missing or incomplete,
+invoke the installed [setup-github-tracking skill](../../setup-github-tracking/SKILL.md).
+Reuse verified complete setup. Local needs no GitHub setup; Issues-only needs no
+Project. The setup skill preserves the same project configuration, authority,
+equivalent mappings and real records. A selected Project remains a delivery
+obligation; unavailable settings stay precisely pending rather than claimed complete.
+Ongoing issue creation and work checkpoints below still apply after setup.
+
+## Apply real issue tracking
 
 Apply each real issue's correct kind marker and explicitly add it to the selected
 Project when creating it. Set native parent/sub-issue and genuine blocked-by
@@ -82,30 +30,6 @@ membership alone does not satisfy a saved kind filter. Verify both, then check
 that the legitimate record appears in its intended view. Do not create dummy
 issues to test setup or add an auto-add workflow in place of explicit membership.
 
-Inspect relevant existing built-in automation for effects conflicting with
-verified closure or manual ownership. Do not silently disable/replace it, enable
-auto-close/archive or add recurring jobs/GitHub Actions merely for bootstrap.
-
-Save changed layouts, filters, grouping and visible fields, then reopen the view
-or read its persisted configuration. Verify the Project link, semantic
-fields/options, view names/layouts/filters/grouping/columns and the first real
-issues' kind, membership and native relationships when those issues exist.
-A temporary unsaved view,
-accepted API request or empty item list does not prove setup. A second pass
-reuses complete setup and creates nothing. If permission or tooling cannot
-configure or inspect a specific setting, record that exact gap and pending mirror;
-preserve issue-side truth and continue useful authorized work. Do not claim a
-view property that was not inspected or block all work on an optional mirror.
-
-Use GitHub's current controls for [managing and saving views][github-views],
-[table fields/grouping][github-table], [board columns/cards][github-board] and
-[view filters][github-filters].
-
-[github-views]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/managing-your-views
-[github-table]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-table-layout
-[github-board]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-board-layout
-[github-filters]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/filtering-projects
-
 ## Outcome → increment → task
 
 Use three linked issue levels, without introducing an epic or story tier:

package/skills-codex/outcome-led-planning/references/project-tracking.md

@@ -30,7 +30,7 @@ Optional `contributors` mappings may identify an agent account and responsible h
 
 **Local:** use the existing conversation or agreed local plan/artifact for the confirmed outcome, current Now revision, owners, contributions, dependencies and evidence. Shared local work uses its agreed records and authorized channel. It needs no GitHub accounts, issues, labels, Project, fields or views. If no contributor is available, continue useful authorized solo work without inventing helpers.
 
-**GitHub:** read [the GitHub coordination protocol](github-coordination.md) before planning, claims or issue/Project mutations. Issues carry outcome → increment → task; an optional selected Project mirrors them. Bootstrap only missing selected setup, preserve equivalent existing configuration and verify actual saved results. Backend choice grants no authentication, access, messaging, public visibility or recurring automation authority.
+**GitHub:** read [the GitHub coordination protocol](github-coordination.md) before planning, claims or issue/Project mutations. Issues carry outcome → increment → task; an optional selected Project mirrors them. For missing or incomplete selected setup, invoke the installed [setup-github-tracking skill](../../setup-github-tracking/SKILL.md); reuse verified complete setup, preserve equivalent existing configuration and verify actual saved results. Backend choice grants no authentication, access, messaging, public visibility or recurring automation authority.
 
 ## Expose useful contributions without reserving the backlog
 

package/skills-codex/setup-github-tracking/SKILL.md

@@ -0,0 +1,119 @@
+---
+# Generated by scripts/sync-planning-skill.mjs; edit packages/planning instead.
+name: setup-github-tracking
+description: "Configure missing GitHub issue tracking and selected Project fields and views for outcome-led planning. Use when GitHub tracking is selected and setup is missing or incomplete, or when explicitly asked to repair that setup; reuse complete setup and bypass Local mode."
+---
+
+<!-- Generated from the runtime-neutral skill source. Do not edit. -->
+
+> Codex runtime note: use `request_user_input` only where this contract
+> explicitly requires a human decision. Resolve `<itil-plugin-root>` from
+> this installed `SKILL.md`: it is two directories above the skill
+> directory. Run bundled commands from `<itil-plugin-root>/bin/`; do not
+> search the adopter repository or rely on those commands being on `PATH`.
+
+
+# Set up GitHub tracking
+
+Make the selected tracking setup usable for the existing outcome. This skill configures tracking; it does not establish a new objective, create an executable delivery plan or claim ownership of the outcome.
+
+Read [shared project tracking](../outcome-led-planning/references/project-tracking.md) and the existing project instructions. Reuse the project-declared configuration path and saved choice. If Local is selected, return without GitHub setup. If no backend choice is established, leave that decision to the calling planning/contribute workflow; do not silently select GitHub. Reuse verified complete setup without reconfiguration or repeat questions. For missing selected setup, inspect current state and change only what is needed within existing authority. Ask one focused question and wait only when a genuinely missing setup fact cannot be established from context or authorized inspection.
+
+## Configure missing selected setup
+
+Inspect before changing setup: the chosen repository/owner, authenticated actor,
+permissions, planning configuration, linked Project, labels or issue types,
+fields/options, saved views and relevant built-in workflows. Reuse equivalent
+existing mappings and custom organization; names alone do not establish that
+something is missing. Preserve IDs, existing options, labels, colours, layouts
+and user-saved filters. Setup intent grants no new credentials, owner scope or
+public visibility. Use supported APIs/CLI or an authorized browser, not guessed
+view mutations or new access grants.
+
+Project fields and views apply **only when Project tracking is selected or
+repository-required**. Reuse the configured Project; create one only when that
+choice requires it, none exists and existing authority permits it. GitHub
+Issues-only and conversation/local tracking need no Project, views or fields.
+Once selected or required, Project setup and updates are part of delivery.
+Optional describes the choice to use a Project, not permission to skip that
+choice after it is made. Complete missing applicable setup at the first work
+checkpoint using available authorized tools. A default unfiltered View 1 is not
+equivalent to the three kind-specific views below. If setup cannot be completed,
+record the exact missing settings and next recovery action on the existing
+increment; keep setup incomplete until its saved state is verified.
+For shared Project tracking, reuse the same project-declared configuration
+(default `.agents/planning.json`), following the shared project-tracking
+preservation rules. Create or update only needed settings: `version: 1`, `backend: github`,
+`github.repository`, `github.projectUrl` and `contributors` entries mapping each
+actual contributor's `agent` and responsible `human`. Derive identities and URLs
+from verified context; store no tokens or connection identifiers. Agent and human
+may be the same account. Record different semantic mappings in existing project
+guidance/configuration, not another registry.
+
+Create only missing essentials, using these defaults when no equivalent mapping
+is established:
+
+- **Record kinds:** `kind:outcome`, `kind:increment`, `kind:task` labels. Reuse an
+  existing equivalent issue-type/label mapping; do not migrate organization issue
+  types or add a duplicate Kind field merely to follow this convention.
+- **Increment horizons:** `horizon:now`, `horizon:next`, `horizon:later` labels,
+  mirrored by the Horizon field. Each open planned increment has one horizon;
+  outcomes/tasks have none. Clear completed/superseded increments' active horizons.
+- **Status:** single-select Ready, In progress, Blocked, Reviewing, Done. An
+  established equivalent such as Todo for Ready is valid. Add missing semantic
+  options without replacing existing option IDs or unrelated configured values.
+- **Horizon:** single-select Now, Next, Later; **Agent:** text containing the exact
+  distinct agent/session or Unclaimed. Reuse native Title, Assignees, Parent
+  issue, Sub-issues progress and Linked pull requests fields. Add no default
+  priority, estimate, iteration or date fields without an outcome-specific need.
+
+Create a saved view only when its equivalent is missing. These are **new-Project
+defaults**, not instructions to reset existing saved layouts or filters:
+
+1. **Outcomes:** table, filter `label:kind:outcome`; show Title, Status, Assignees,
+   Agent and Sub-issues progress.
+2. **Increments:** table, filter `label:kind:increment`; group by Horizon
+   ordered Now/Next/Later; show Title, Parent issue, Horizon, Status, Assignees,
+   Agent, Linked pull requests and Sub-issues progress. Retain closed increments
+   without an active Horizon so delivery history remains accessible. Enable
+   **Show hierarchy**, save the view and reopen it to verify hierarchy remains On.
+   The increment kind filter selects roots; related task children are expected
+   hierarchy content and must remain accessible under their increment.
+3. **Tasks:** board, filter `label:kind:task`; use Status columns and show Title,
+   Assignees, Agent, Parent issue and Linked pull requests on cards as available.
+
+Preserve existing custom views and access to closed/history records. Increments
+hierarchy MUST be On, including equivalent existing views. Inspect real increment
+roots and their legitimate related children; exclude unrelated roots rather than
+disabling hierarchy to hide task children. No mandatory roadmap or per-agent view.
+
+For existing real issues, verify kind, explicit Project membership, native relationships and applicable fields as described in the [ongoing issue protocol](../outcome-led-planning/references/github-coordination.md#apply-real-issue-tracking). New issues follow that same protocol throughout delivery. Do not create dummy issues to test setup.
+
+Inspect relevant existing built-in automation for effects conflicting with
+verified closure or manual ownership. Do not silently disable/replace it, enable
+auto-close/archive or add recurring jobs/GitHub Actions merely for bootstrap.
+
+Save changed layouts, filters, grouping and visible fields, then reopen the view
+or read its persisted configuration. Verify the Project link, semantic
+fields/options, view names/layouts/filters/grouping/columns, persisted Increments
+hierarchy On and the first real
+issues' kind, membership and native relationships when those issues exist.
+A temporary unsaved view,
+accepted API request or empty item list does not prove setup. A second pass
+reuses complete setup and creates nothing. If permission or tooling cannot
+configure or inspect a specific setting, record that exact gap and pending mirror;
+preserve issue-side truth and continue useful authorized work. Do not claim a
+view property that was not inspected or block all work on an optional mirror.
+
+Use GitHub's current controls for [managing and saving views][github-views],
+[table fields/grouping][github-table], [board columns/cards][github-board] and
+[view filters][github-filters].
+
+[github-views]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/managing-your-views
+[github-table]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-table-layout
+[github-board]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-board-layout
+[github-filters]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/filtering-projects
+
+## Return to the current work
+
+Read back saved configuration and changed provider state before reporting what is complete. Return the actual repository/selected Project, reused or changed settings and any precise unresolved operation to the caller in its existing plan or discussion. Do not create another report, config, plan, task backlog or recurring process. Keep incomplete settings explicit and continue useful work under the existing coordination and authority rules; never claim an uninspected view property. Subsequent issue creation and work checkpoints remain governed by the [GitHub coordination protocol](../outcome-led-planning/references/github-coordination.md).

package/skills-codex/setup-github-tracking/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Set up GitHub Tracking"
+  short_description: "Configure selected issue tracking and Project views"