Product Planner

Product Planner

One invocation takes an idea to a sprint plan by chaining four existing skills, unedited, in a fixed order. Each member owns its workflow, questions, approval gates and commits; this skill only decides which members run, hands each its input, and never repeats a stage whose file exists. Member detail stays in references/ to protect the context budget.

idea-validator → idea.md + validate.md → prd-generator → prd.md → [brand-name-checker] → tad-generator → tad.md → tasks-generator → tasks.md

When to Use

• "Take this idea all the way to a task list" / "plan this product end to end".
• "Validate this idea and write the PRD, then stop" (partial range).
• "Continue my project in <folder>" when some of the files already exist (resume).

Single-document requests go to the member directly: prd-generator, idea-validator, tad-generator or tasks-generator.

Terms

• PROJECT_DIR: the absolute path of the project folder. Resolve it with PROJECT_DIR="$(cd "$PROJECT_DIR" && pwd)"; if the cd fails, ask for the path.
• Range: the stages this run invokes, from the start stage to the end stage.
• Member report: the Final Report each member prints last. Its Result: line starts with COMPLETE, PARTIAL or BLOCKED; its Evidence: line carries the commit hash and GitHub links.
• Status: this skill's own COMPLETE, PARTIAL or BLOCKED, chosen by the rules in Final Report.

Stages

Per-member gates, push behavior, existing-file modes and stop conditions: references/member-contracts.md. Read it before the first member runs.

Dependency Preflight (mandatory)

This skill invokes the five skills declared in frontmatter dependencies. Run this at Workflow step 4, after the range is fixed and before any member writes a file:

if command -v asm >/dev/null && asm deps --help >/dev/null 2>&1; then
  asm deps discover product-planner --json || echo "discover failed; acquire still runs" >&2
  echo "pp_mode=lease"
else
  echo "asm deps unavailable: npm install -g agent-skill-manager@latest" >&2
  echo "pp_mode=installed"
fi
printf 'pp_session=%s\n' "product-planner-$(date +%s)-$$"   # record it; reuse it verbatim

1. With pp_mode=lease, run asm deps acquire <member> --session <pp_session> --json for each chain member in range, in Stages order. Record each returned skillMdPath.
2. With pp_mode=installed, check each chain member in range with test -f "$HOME/.claude/skills/<member>/SKILL.md" || test -f "$HOME/.agents/skills/<member>/SKILL.md". Record the path that exists.
3. If any chain member fails step 1 or 2, print one line per missing member, Missing skill: <member> — install: asm install github:luongnv89/skills:skills/<member> -p claude --yes, then stop before any file is written. The status is BLOCKED. Never imitate a member inline.
4. Check brand-name-checker the same way only when the user opts into the brand check. If it is missing, skip the brand check and list the skip under Uncertainty:. This miss is fail-soft.
5. Release in finally. If any acquire ran, run asm deps release --session <pp_session> --json once at every terminal outcome, stops included, before the Final Report. List a failed release under Uncertainty:.

Chain members in range are acquired at preflight, not at their stage: the range fixes that each one runs, and a miss found at stage 3 would leave a half-built plan. The brand check is an optional branch, so it is acquired only when reached.

Repo Sync Before Edits (mandatory)

The members write files into PROJECT_DIR. Run this once at Workflow step 5, before the first member. The sync target is PROJECT_DIR, or the ideas root when stage 1 has not created the folder yet.

1. Run repo="$(git -C "<sync target>" rev-parse --show-toplevel)". If it fails, skip the sync and record sync: skipped (not a git repo).
2. Run git -C "$repo" remote get-url origin. If it fails, skip steps 3–6 and record sync: skipped (no origin).
3. Run branch="$(git -C "$repo" rev-parse --abbrev-ref HEAD)". If it prints HEAD, skip steps 4–6 and record sync: skipped (detached HEAD).
4. Run git -C "$repo" status --porcelain. If the output is empty, run git -C "$repo" fetch origin && git -C "$repo" pull --rebase origin "$branch".
5. If the output is not empty, run git -C "$repo" stash push -u -m "product-planner pre-sync", then the same fetch and pull, then git -C "$repo" stash pop.
6. If the rebase conflicts, run git -C "$repo" rebase --abort, then git -C "$repo" stash pop when step 5 stashed. If the stash pop conflicts, leave the stash in place. In both cases stop and ask the user how to continue; with no answer, the status is BLOCKED.

Each member still runs its own sync; do not skip or suppress it. This skill commits nothing itself.

Workflow

Run these steps in order. Do not invoke any member before step 6. A stop at any step still runs the preflight release (when an acquire ran) and step 7.

1. Resolve the project and detect artifacts

1. Resolve PROJECT_DIR the way the members do: path in $ARGUMENTS → folder echoed earlier in this session → IDEAS_ROOT → ~/.config/ideas-root.txt → legacy ~/.openclaw/ideas-root.txt → ask. A fresh idea with no folder yet has no PROJECT_DIR until stage 1 creates one.
2. If several folders are plausible, list them and ask. Never pick silently.
3. Make PROJECT_DIR absolute (see Terms).
4. Check which of idea.md, validate.md, prd.md, tad.md, tasks.md exist and show the table:

Found in <PROJECT_DIR>:
  idea.md      √  validate.md  √ (Verdict: Build it)
  prd.md       √  tad.md       ×  tasks.md  ×
Resume point: tad-generator (stage 3)

The furthest existing artifact sets the default start: the stage after it. A gap behind it is reported, never backfilled unless the user asks.

2. Pick the range

• Start = the stage after the furthest artifact, unless the user names an earlier one.
• End = tasks-generator by default, or the stop point the user names ("just validate + PRD" → end at stage 2; "up to the architecture" → end at stage 3).
• Brand check runs only when the user asks for it or accepts the offer made after prd.md exists.
• Dedup rule: invoke a member only for a missing artifact, or when the user explicitly asks to regenerate that file. Members switch into modify/backup mode when their file exists, so an unrequested call is never harmless. When prd.md is regenerated, flag existing tad.md and tasks.md as possibly stale; do not regenerate them on your own.
• State the plan in one line ("Running stages 3–4; reusing idea.md, validate.md, prd.md") before step 3.

3. Verdict gate

Applies only when prd-generator is in the range and validate.md exists. Read the verdict:

1. Find the ## Quick Verdict heading in validate.md and take the first non-empty line after it.
2. Strip the surrounding ** and spaces.
3. Match the leading token only: Build it, Maybe or Skip it. Ignore trailing text such as (rule 2); the rule and rationale live under ## Why.
4. If no token matches, or the heading is missing, show the line and ask whether to continue. Without a yes, stop.

Then act on the verdict:

• Build it → continue.
• Maybe → show the top concerns from validate.md, then continue.
• Skip it → stop the chain and report the verdict with its ## Why rationale. Continue only if the user explicitly overrides ("build it anyway"). Record the override for the Final Report.

prd-generator also asks before writing a PRD for a Skip it verdict. To avoid asking twice, pass the user's override with the folder: <PROJECT_DIR> (user already confirmed a PRD despite the Skip it verdict: "<user's words>"). If prd-generator still asks, relay its question unchanged; never answer it. When the range starts after stage 2, show the verdict in the table and skip the gate.

4. Preflight

Run the Dependency Preflight for the members in range.

5. Sync

Run Repo Sync Before Edits.