Make WPs

VibeForge — Queue Next Work Packages from Backlog (Tasks → WPs)

Generate and enqueue the next Work Package(s) in the per-idea board:

• docs/​forge/​ideas/<IDEA_ID>/​latest/​work_packages.md

From the canonical backlog:

• docs/​forge/​ideas/<IDEA_ID>/​latest/​tasks.md

This command ONLY selects tasks and appends WP entries; it must never modify the backlog tasks.

---

Invocation

Call with an idea folder id first:

• /​into-wps <IDEA_ID> [filters...]

Examples:

• /​into-wps IDEA-0003_my-idea → enqueue 1 WP (default)
• /​into-wps IDEA-0003_my-idea 3 → enqueue up to 3 new WPs
• /​into-wps IDEA-0003_my-idea MVP → only queue tasks with release_target: MVP
• /​into-wps IDEA-0003_my-idea EPIC-003 → only queue tasks under an epic
• /​into-wps IDEA-0003_my-idea FEAT-014 → only queue tasks under a feature
• /​into-wps IDEA-0003_my-idea WP-0007 → force-create next WP id starting at WP-0007 (rare)

Argument parsing rules (best-effort):

• $1 = IDEA_REF (required)
• Remaining tokens in $ARGUMENTS may include:
  • a count N (integer)
  • a release filter MVP|V1|Full|Later
  • EPIC-### and/​or FEAT-### filters
  • a forced starting id WP-####

If IDEA_REF is missing, STOP and ask the user to provide it.

---

Resolve IDEA_ID (required)

Before using any paths, resolve the idea folder:

• Call vf.resolve_idea_id with idea_ref = $1
• Store the returned idea_id as IDEA_ID
• Use IDEA_ID for all paths, YAML headers, and run log entries

---

Inputs (Auto)

Per-idea WP board (target):

• docs/​forge/​ideas/<IDEA_ID>/​latest/​work_packages.md (create if missing)

Idea backlog (canonical):

• docs/​forge/​ideas/<IDEA_ID>/​latest/​tasks.md (required)

Optional Inputs (Auto if present)

For better titles/​context (do not derive tasks from these):

• docs/​forge/​ideas/<IDEA_ID>/​latest/​features_backlog.md (preferred; fallback to features.md if backlog missing)
• docs/​forge/​ideas/<IDEA_ID>/​latest/​features.md (fallback if backlog missing)
• docs/​forge/​ideas/<IDEA_ID>/​latest/​epics_backlog.md (preferred; fallback to epics.md if backlog missing)
• docs/​forge/​ideas/<IDEA_ID>/​latest/​epics.md (fallback if backlog missing)
• docs/​forge/​ideas/<IDEA_ID>/​latest/​concept_summary.md

---

Output (Auto)

Append WP entries into:

• docs/​forge/​ideas/<IDEA_ID>/​latest/​work_packages.md

No other files are modified by this command.

If you cannot write to the file directly, output the exact text block(s) that should be appended.

---

Step 0 — Read context and compute queue state

1. Open docs/​forge/​ideas/<IDEA_ID>/​latest/​work_packages.md and parse existing WPs:

• WP ids
• Status (Queued, In Progress, Blocked, Done, etc.)
• Referenced Task IDs (TASK-###) if present
• Any explicit dependencies and verify commands

If the file does not exist, treat as empty and create it with a minimal header:

# Work Packages — <IDEA_ID>

(append new WPs below)

1. Compute:

• Next WP id = (max existing WP number + 1), unless a forced starting id is provided
• Task IDs already referenced by any existing WP (any status) to avoid duplicates

1. If there are already 4+ WPs with status Queued, STOP and report:

• “Queue is already full; execute or plan queued WPs first.”
• List the currently queued WP ids.

---

Step 1 — Read and index the backlog (tasks.md)

1. Open docs/​forge/​ideas/<IDEA_ID>/​latest/​tasks.md.
2. Parse the canonical YAML block at the top (preferred). If missing, fall back to parsing the Markdown rendering.
3. Build an in-memory list of tasks with fields (best-effort):

• task_id (TASK-001)
• feature_id (FEAT-014)
• epic_id (EPIC-003)
• title
• description
• release_target (MVP/​V1/​Full/​Later)
• priority (P0/​P1/​P2)
• estimate (S/​M/​L)
• dependencies (task ids, if present)
• tags (backend/​frontend/​infra/​qa/​etc., if present)

1. Apply optional filters from remaining args:

• Release filter: MVP/​V1/​Full/​Later
• Epic filter: EPIC-###
• Feature filter: FEAT-###

If the backlog file is missing, STOP and report the expected path.

---

Step 2 — Find eligible candidate tasks

Eligible tasks are tasks that:

• exist in tasks.md
• are NOT already referenced by any existing WP
• are not obviously blocked by missing dependencies (best-effort)

Preference order (unless filters override):

1. release_target: MVP first, then V1, then Full, then Later
2. Within a release target:
   • priority P0 → P1 → P2
   • group by epic_id then feature_id
   • smaller estimates first (S then M then L), unless dependency chains require ordering

Dependency-aware selection (best-effort):

• If a task lists dependencies that are not already in any WP (any status) and not included in the current WP batch, treat it as blocked and skip.
• If dependencies are missing/​unknown, be conservative: pick fewer tasks per WP.

If no eligible tasks are found, STOP and report why.

---

Step 3 — Form appropriately sized Work Packages (WP batching heuristics)

Goal: small, focused WPs.

Default WP sizing targets:

• 3–8 tasks per WP (bias toward smaller counts unless tasks are tiny)
• Total effort per WP ~ 1–3 days (best-effort)
  • Heuristic points: S=1, M=2, L=4; aim for 4–8 points per WP

Batching heuristics (priority order):

1. Keep WPs within the same feature_id when possible.
2. If a feature is too large, allow spanning within the same epic_id, but keep it tight.
3. Prefer related tasks only if they share the same epic/​feature (IDs alone are not a guarantee).
4. Avoid mixing unrelated tags (e.g., deep infra + UI polish) unless tasks are explicitly coupled.
5. Stop early if you hit a task that clearly depends on missing prerequisites.
6. If uncertain, create smaller WPs.

When a count N is provided:

• Repeat batching up to N times, removing selected tasks from the candidate pool each time.

---

Step 4 — Draft WP metadata

For each WP batch selected:

1. WP Title (short, readable):

• Prefer: <EPIC title> — <Feature title> (slice) if features_backlog.md/epics_backlog.md are available (fallback to features.md/epics.md if backlog missing)
• Otherwise: derive from dominant feature_id/epic_id + common tags
• Keep it human-scannable

1. Goal sentence:

• Outcome-oriented: what completing the WP enables.

1. WP Task list:

• List included Task IDs and task titles.

1. Plan Doc path (reference only; created later by a planning command):

• docs/​forge/​ideas/<IDEA_ID>/​planning/​WPP-0001-WP-XXXX_TASK-AAA-BBB_<short_slug>.md
  • WPP-0001 is an incrementing plan-doc id local to the idea (best-effort).
  • TASK-AAA-BBB = numeric range (min/​max) of included tasks
  • Slug: short + stable (e.g., orchestration_api_slice, ui_control_panel_basics)

1. Status:

• Queued

1. Dependencies (best-effort):

• If tasks depend on other tasks not already covered by any WP (any status) and not included in this WP, list them at WP level.
• Otherwise: None

1. Verify commands (best-effort defaults):

• Default: pytest
• If clearly frontend-only: include npm test or minimal build if known
• If unclear: keep only pytest

1. Traceability:

• Include Idea-ID: <IDEA_ID> in the WP entry so WPs are traceable back to the idea.

---

Step 5 — Append to work_packages.md

Append each new WP section at the end.

Recommended WP entry format:

## WP-XXXX — <Title>

- Status: Queued
- Idea-ID: <IDEA_ID>
- Release: MVP|V1|Full|Later
- Tasks:
  - TASK-001 — <title>
  - TASK-002 — <title>
- Goal: <goal sentence>
- Dependencies: None | WP-XXXX | TASK-YYY
- Plan Doc: docs/​forge/​ideas/<IDEA_ID>/​planning/​WPP-0001-WP-XXXX_TASK-AAA-BBB_<slug>.md
- Verify: pytest (and any extras)

---

Step 6 — Output next actions

Print:

• New WP id(s) and tasks selected
• Plan Doc path(s)
• Suggested next step (e.g., “Run your WP planning command for WP-XXXX”)

---

Non-negotiable Rules

• Never modify or rewrite the canonical backlog in docs/​forge/​ideas/<IDEA_ID>/​latest/​tasks.md.
• Never enqueue tasks already referenced by any existing WP (any status).
• Keep WPs small and focused; default to 1 WP if no count is provided.
• Do NOT mark tasks complete here.
• Prefer conservative batching when dependencies are unclear.
• Do not invent tasks; only select tasks that exist in tasks.md.