improve-product
Measure released product outcomes and select one evidence-backed next experiment, refinement, expansion, or stop decision.
SKILL.md.claude/skills/improve-product/SKILL.md
GitHub<!-- Generated by mstack from Misbah's Build Like This workflow. Regenerate instead of editing. -->
improve-product
Run Phase 10 with the continuous-improvement skill. The product-manager leads, product-analyst validates measurement, and affected research, test, security, performance, or operations specialists investigate independent signals.
This prompt follows Misbah Khursheed's Build Like This workflow: establish the user outcome and reasoning before generating implementation, then preserve that reasoning in contracts, boundaries, tests, and documentation.
Project identity and sources of truth
The repository where this prompt is installed is the host project being built. Build Like This is the engineering method used to build it, while mstack only installs and reconciles the method's resources. Do not mistake mstack or Build Like This for the host product unless project-owned sources explicitly say this repository develops mstack itself.
Project-owned docs/, decisions, executable code, and tests are the sources of truth. .mstack/templates/ are reference scaffolds that may be copied and adapted into project-owned documents; they are not requirements and do not replace docs/.
Treat the invocation arguments and current repository state as task input. Discover local instructions and relevant product, architecture, decision, contract, and test context before making material assumptions.
Method
- Restate the released hypothesis, target users, scope, baseline/target/window, decision thresholds, guardrails, and residual risks.
- Validate event/metric definitions, data lineage, exposure, baseline comparability, missingness, segment mix, and instrumentation quality before analysis.
- Compare outcome and diagnostic measures by relevant segment alongside user research/support, incidents, reliability, performance, cost, security, and accessibility evidence.
- Distinguish adoption, usability, value, reliability, and measurement failures; state plausible explanations, contradictions, and uncertainty without claiming causality.
- Choose continue/refine/expand/stop and rank opportunities by evidence, user outcome, risk, effort, and learning value.
- Update project-owned product/research/experiment/feature artifacts and define one smallest next experiment or vertical slice with owner, threshold, and review date.
Deliverables
- Outcome review with validated metrics, qualitative/operational evidence, guardrails, segment context, and uncertainty.
- Continue/refine/expand/stop decision with evidence-linked rationale, causal hypotheses, and accepted risks.
- One prioritized next experiment or slice with scope/non-goals, owner, acceptance threshold, verification, and review date.
Constraints
- Do not fabricate telemetry, baselines, causal certainty, user consensus, or statistical significance.
- Do not optimize a proxy while user harm, reliability, security, privacy, accessibility, or cost guardrails regress.
- Do not absorb unrelated cleanup or roadmap ideas without a demonstrated outcome or maintenance need.
Delegation and parallel safety
- For a material lifecycle task, the active lead must delegate at least one bounded specialist lane when subagents are available; prefer two or more concurrent lanes only when their evidence or file ownership is independent.
- The active lead owns acceptance criteria and final integration. Supporting agents must not recursively delegate unless explicitly promoted to lead a named lane.
- Give each delegate distinct inputs, outputs, and ownership. Serialize shared documents, contracts, schemas, migrations, deployments, external writes, and overlapping file edits.
- If subagents are unavailable, perform the named specialist passes sequentially and report the limitation; do not imply parallel verification.
- Delegation does not authorize outreach, paid resources, destructive changes, consequential external writes, or production deployment.
Finish with what changed or was decided, exact verification evidence, remaining risks, and the next decision only if one is genuinely required.
User arguments: $ARGUMENTS