Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 47 additions & 19 deletions .github/projects/active/next-issues-execution-plan-2026-05-27.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: "Next Issues Execution Plan"
description: "Prioritised execution plan for the next open issues after label-governance stabilisation closeout."
version: "v1.0.3"
version: "v1.1.0"
last_updated: "2026-05-28"
file_type: "project"
maintainer: "LightSpeed Team"
Expand All @@ -12,35 +12,33 @@ domain: "governance"
stability: "active"
---

## Next Issues Execution Plan (2026-05-27)
## Next Issues Execution Plan (2026-05-28)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add a single H1 before this section to keep heading levels sequential.

This starts at ## without a preceding #, which breaks the required heading structure for Markdown docs.

As per coding guidelines, "**/*.md: Use one H1 per file and keep heading levels sequential".

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/projects/active/next-issues-execution-plan-2026-05-27.md at line 15,
Add a single top-level H1 above the existing "## Next Issues Execution Plan
(2026-05-28)" heading so the file contains one H1 and subsequent headings are
sequential; specifically insert a "# Next Issues Execution Plan (2026-05-28)"
(or a brief equivalent H1 title) immediately before the current "## Next Issues
Execution Plan (2026-05-28)" line to satisfy the "*.md: Use one H1 per file and
keep heading levels sequential" guideline.


## Scope

This plan prioritises the next open `lightspeedwp/.github` issues that are
ready and high-leverage after closing the label governance sequence (`#66`,
`#67`, `#69`, `#95`, `#449`).

Live checks on 2026-05-28: issues `#65`, `#63`, `#62`, and `#64` are closed
(merged via PRs `#452`, `#454`, `#458`, and `#460`). The next open sequence
now starts at `#61`.
Live checks on 2026-05-28: issues `#65`, `#63`, `#62`, `#64`, and `#61` are
closed (merged via PRs `#452`, `#454`, `#458`, `#461`, and `#493`). Follow-up
policy hardening is merged via PR `#463`.

## Prioritised backlog

### Wave 1 - Documentation and workflow execution (start here)
### Wave 1 - immediate execution (in progress)

1. `#61` [Docs/Workflows] Convert spec-only agents into Issues with templates
and project mapping
Link: [#61](https://github.com/lightspeedwp/.github/issues/61)
2. `#52` Update references from `create_issue` to `issue_write` and scan
1. `#52` Update references from `create_issue` to `issue_write` and scan
outdated MCP tools
Link: [#52](https://github.com/lightspeedwp/.github/issues/52)
2. PR closeout + merge confirmation + issue closure for `#52`.

Why this wave first:

- closes the highest-priority remaining docs and workflow hygiene debt
- keeps issue templates, project mapping, and tool references consistent
- clears remaining tooling-reference drift before larger docs and agent waves
- ensures active prompts and specs match current MCP tool naming

### Wave 2 - standards and documentation debt
### Wave 2 - reprioritised backlog (post-#52)

1. `#60` [Docs/Workflows] Pilot telemetry for Tour Operator + document
opt-outs
Expand All @@ -53,14 +51,42 @@ Why this wave first:

Why second:

- preserves momentum after the completed governance and hook hardening work
- keeps broader audits behind targeted workflow and docs fixes
- preserves momentum after #52 tooling alignment
- keeps broader audits ordered behind explicit agent burn-down batches

### Wave 2A - core runtime agent burn-down batch

Issues: `#464`, `#465`, `#466`, `#467`, `#468`, `#469`, `#476`, `#480`,
`#482`.

Focus:

- core runtime agent specs with highest operational leverage
- consistency checks for tool declarations, acceptance criteria, and ownership

### Wave 2B - mode and planning agent batch

Issues: `#470`, `#471`, `#473`, `#475`, `#478`, `#484`, `#486`.

Focus:

- mode/planning behaviour specs and orchestration quality
- remove overlap and tighten spec boundaries before implementation work

### Wave 2C - scaffolds and completion batch

Issues: `#488`, `#490`.

Focus:

- template and test scaffolding completion
- final pass on mapping, labels, and closure evidence

## Execution order and dependencies

1. Execute `#61` before `#52` so template and project mapping conventions are
set before tool-reference sweeps.
2. Defer broader doc audits (`#31`, `#23`) until Wave 1 is merged.
1. Execute and merge `#52` before Wave 2 batch starts.
2. Run Wave 2A -> Wave 2B -> Wave 2C in order.
3. Defer broader doc audits (`#31`, `#23`) until Wave 2A is merged.

## Definition of done per issue

Expand All @@ -71,4 +97,6 @@ Why second:

## Proposed immediate next action

Start with `#61` in a dedicated branch and open the next PR from that issue.
Continue with `#52` merge and issue closure, then open Wave 2A branch for the
core runtime batch (`#464`, `#465`, `#466`, `#467`, `#468`, `#469`, `#476`,
`#480`, `#482`).
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ tools:
"search/codebase",
"search",
"github",
"create_issue",
"issue_write",
"search_issues",
"update_issue",
Comment on lines +9 to 11

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Replace the remaining issue update tool

This prompt still allow-lists update_issue even though the change migrates issue creation to the consolidated MCP tool. I checked the current GitHub MCP issue tool list, where updates are handled by issue_write with method: 'update', and update_issue is no longer listed; in hosts that validate prompt frontmatter tool names exactly, the update-existing path can fail to load or become unavailable. The same stale allow-list entry appears in the other two issue-creation prompts.

Useful? React with 👍 / 👎.

]
Expand All @@ -20,7 +20,7 @@ Create GitHub Issue for the specification at `${file}`.

1. Analyze specification file to extract requirements
2. Check existing issues using `search_issues`
3. Create new issue using `create_issue` or update existing with `update_issue`
3. Create new issue using `issue_write` or update existing with `update_issue`
4. Use `feature_request.yml` template (fallback to default)

## Requirements
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ tools:
"search/codebase",
"search",
"github",
"create_issue",
"issue_write",
"search_issues",
"update_issue",
]
Expand All @@ -20,7 +20,7 @@ Create GitHub Issues for the implementation plan at `${file}`.

1. Analyze plan file to identify phases
2. Check existing issues using `search_issues`
3. Create new issue per phase using `create_issue` or update existing with `update_issue`
3. Create new issue per phase using `issue_write` or update existing with `update_issue`
4. Use `feature_request.yml` or `chore_request.yml` templates (fallback to default)

## Requirements
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ tools:
"search/codebase",
"search",
"github",
"create_issue",
"issue_write",
"search_issues",
"update_issue",
]
Expand All @@ -21,7 +21,7 @@ Create GitHub Issues for unimplemented requirements in the specification at `${f
1. Analyze specification file to extract all requirements
2. Check codebase implementation status for each requirement
3. Search existing issues using `search_issues` to avoid duplicates
4. Create new issue per unimplemented requirement using `create_issue`
4. Create new issue per unimplemented requirement using `issue_write`
5. Use `feature_request.yml` template (fallback to default)

## Requirements
Expand Down
2 changes: 1 addition & 1 deletion .github/prompts/my-issues.prompt.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ tools:
[
"githubRepo",
"github",
"get_issue",
"issue_read",
"get_issue_comments",
Comment on lines +7 to 8

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Replace the stale issue comments tool

This swaps get_issue to issue_read but leaves get_issue_comments in the prompt allow-list. The current GitHub MCP issue tools consolidate comment reads into issue_read with the get_comments method, so environments that exact-check prompt tool names can reject this prompt or leave the comment-count workflow without the declared read tool.

Useful? React with 👍 / 👎.

"get_me",
"list_issues",
Expand Down
12 changes: 12 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0

### Documentation

- Closed issue `#64` with merged PR `#461` (canonical `ai/*` source
consolidation) and follow-up governance hardening merged via PR `#463`
(`meta:no-changelog` policy and validation guardrails).
- Updated active next-issues execution planning with a formal Wave 2
reprioritisation and explicit burn-down batches for spec-only agent tasks
`#464`-`#490`.
- Added spec-only agent issue conversion tracking under `#61`, including
canonical issue mapping and duplicate cleanup notes.
- Added Husky pre-push contributor guidance and aligned local development docs
Expand All @@ -22,6 +28,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
label-governance policy config, and documented #95 decision gating for
destructive cleanup.

### Changed

- Replaced stale MCP tool references for issue creation and lookup across
agent/prompt specs (`create_issue` -> `issue_write`, `get_issue` ->
`issue_read`) as part of issue `#52` alignment.

## [0.4.0] - 2026-05-27

### Documentation
Expand Down
4 changes: 2 additions & 2 deletions agents/mode-prd.agent.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,9 +11,9 @@ tools:
"githubRepo",
"search",
"add_issue_comment",
"create_issue",
"issue_write",
"update_issue",
"get_issue",
"issue_read",
Comment on lines +14 to +16

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Update the agent-tools validator allowlist for issue_write/issue_read.

These new tool names are not in scripts/validation/validate-agents.js (validTools), so this config can be flagged as Unknown tool during validation.

Suggested fix
--- a/scripts/validation/validate-agents.js
+++ b/scripts/validation/validate-agents.js
@@
   const validTools = [
@@
     "todo",
     "todowrite",
+    "issue_write",
+    "issue_read",
   ];
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@agents/mode-prd.agent.md` around lines 14 - 16, Add the new tool names
"issue_write" and "issue_read" to the validator allowlist by updating the
validTools array in scripts/validation/validate-agents.js so the agent config
entries ("issue_write", "update_issue", "issue_read") are recognized; locate the
validTools symbol in that file and append these two strings to the list
(preserving formatting and any existing sorting conventions) so validation no
longer flags them as Unknown tool.

"search_issues",
]
metadata:
Expand Down
Loading