Pm Workflow Planning

PM Workflow Planning

Turn one messy business process into a confirmed workflow and a Skill proposal. This is an experiment: keep the run to planning artifacts. Execute the business process, edit stable skills/, or promote a draft only after an explicit user request.

When to use

• A business owner can describe the work but not an agent-ready process.
• A team needs roles, handoffs, evidence, exceptions, and acceptance criteria clarified before building Skills.
• A live-research workflow needs explicit source-access and browser-evidence gates.

When NOT to use

• Reviewing a finished Skill: use skill-self-check.
• Performing the proposed workflow immediately.
• Gathering private personal data, bypassing access controls, or storing client secrets in this repository.
• Combining several unrelated processes in one interview.

Check axes

• Process scope and intended decision.
• Appropriate selection of L/S/V/R business-experience modules.
• Measurable target, formula, threshold, owner, and scoring version when L is selected.
• Runtime capability and evidence access.
• Source fitness (S1–S3) and verification strength (V0–V3).
• Roles, handoffs, approvals, and exceptions.
• Completion criteria and evidence produced by each step.
• Machine-readable run/evidence records when R is selected or an existing log is reused.
• Automation boundary and human decision ownership.
• Skill proposal contract and promotion gate.

Operating contract

1. Ask one question at a time and wait for the answer.
2. For every decision question, give a recommended answer, the reason, and the main alternative. Let the user confirm or correct it.
3. Look up discoverable facts with available tools instead of asking the user. Treat business goals, risk tolerance, ownership, and approval as user decisions.
4. Record unsupported or inaccessible facts as unknown — blocker. Keep gaps open until evidence replaces model memory or “industry common sense.”
5. Draft the Skill proposal only after the user confirms the workflow summary.

Inputs

• One target process.
• Company/industry lens.
• Desired business outcome or failure to prevent.
• Known systems, roles, source restrictions, and approval boundaries.

Done when: the target process is named narrowly enough to interview, or the first one-question prompt is ready.

Process

Pass 0 — Scope and module-selection gate

Name the process and its intended decision or deliverable.

Read references/operational-data-contract.md. Judge L/S/V/R applicability. If the decision is clear from the process, select modules and explain why. If it is unclear, ask one question with a recommended selection and wait.

Use N/A — <reason> for skipped modules. Skipping a module with a clear reason is not a defect and must not be converted into a self-check finding.

Done when: L/S/V/R each has Y, N, or Ask user, with a reason.

Pass 1 — Conditional measurable goal gate

When L is selected, require the user to confirm metric, formula, unit, direction, owner, L1/L2/L3 thresholds, allowed action, and score_rule_version. Propose numeric defaults when helpful, then wait for confirmation. Keep business value L separate from verification strength V.

When L is skipped, write a qualitative completion criterion and the N/A reason.

Done when: L rules are reproducible, or L is explicitly N/A.

Pass 2 — Conditional source and capability gate

When S or V is selected for live web research, read references/browser-evidence.md. Test and record whether the current environment can access each required source. Start Google, LinkedIn, company websites, registries, and browser capabilities in the not tested state.

When S is selected, create the source register. Assign S1/S2/S3 by claim fitness, not prestige. Google search remains S1 discovery until the underlying source is opened.

Done when: selected source/verification modules have their contracts, or S/V is explicitly N/A.

Pass 3 — Interview one branch at a time

Follow INTERVIEW.md. Resolve 5W2H cells in dependency order:

1. What and Why.
2. Who and approval.
3. Trigger, deadline, and handoffs.
4. Systems, evidence, exceptions, and volume.

For each question:

1. Ask one question.
2. Provide a recommended answer based on confirmed context.
3. Explain what would change the recommendation.
4. Wait for confirmation or correction.

Done when: each 5W2H cell is concrete or has an explicit blocker, owner, and follow-up time.

Pass 4 — Build the workflow

Copy WORKFLOW-CANVAS.template.md. For every step, name:

• trigger and input;
• responsible role and approval;
• action and system/tool;
• selected metric/source/evidence/record fields, if applicable;
• completion criterion;
• exception and escalation path.

Read the workflow back to the user. Continue only after explicit confirmation.

Done when: the user confirms the workflow and every step has evidence plus a completion criterion.

Pass 5 — Propose Skills

Copy SKILL-PROPOSAL.template.md. Separate:

• reusable generic discipline;
• company-specific policy or data;
• live tool/integration requirements;
• selected L/S/V/R rules and artifacts; N/A reasons for skipped modules;
• work that must remain a human decision;
• build, reuse, or buy choices.

Split independently triggered roles or materially different permissions into separate Skills instead of a large all-in-one Skill.

Done when: each proposed Skill has WHAT, WHEN, When NOT, inputs, outputs, check axes, a run-bound exit, and only the applicable L/S/V/R contracts.

Pass 6 — Draft and hand off

Only after the user confirms the proposal:

1. Draft the approved Skill in the requested location.
2. Run skill-self-check.
3. Keep the draft experimental until the ship floor passes and a real, anonymized pilot has been recorded.

Done when: the proposal is handed off, blockers are explicit, and no unapproved execution or promotion occurred.

Rationalizations and required advice

Verification

• One target process was used.
• L/S/V/R applicability was judged or asked once with a recommendation.
• Skipped modules have an N/A reason and are not treated as defects.
• If L is selected, metrics, formulas, thresholds, owner, and version are confirmed.
• If L and V are selected, business value and verification strength remain separate.
• Questions were asked one at a time with recommendations.
• Facts were looked up; decisions were confirmed by the user.
• Live-source capabilities were tested rather than assumed.
• If S is selected, each source has a claim-specific S grade and runtime status.
• Official-site claims have browser screenshots, URLs, and capture times.
• Blocked sources are explicit; no login/CAPTCHA/access control was bypassed.
• Every workflow step has role, evidence, exception, and Done when.
• If R is selected, the selected records or equivalent existing system fields are defined.
• The user confirmed the workflow before a Skill proposal was drafted.
• The proposal separates automated work from human decisions.

Example

Use examples/customer-background-investigation/PROCESS-BRIEF.example.md to see the full path from a foreign-trade background-investigation request to a workflow, proposal, and draft Skill.