Connect the workflow through three acceptance points
A museum wants to improve offline downloads for its audio guide. Operations sees complaints that visitors reach a gallery and cannot listen, but the PM cannot tell whether the download entry is hard to find, the transfer fails or visitors misunderstand completion. Use synthetic comments, de-identified interview excerpts and a practice event CSV to rebuild research, decisions and delivery. The aim is to delegate bounded preparation and checking while keeping evidence, judgment and execution ownership traceable.
Do not begin by handing an entire PM role to an agent. Map feedback collection, synthesis, data inspection, option selection, requirements, task breakdown and reporting. For every node specify input, output, owner and failure conditions. Start with a stable format that can be sampled manually. A later stage may consume an earlier artifact only after it passes acceptance. This teaching scenario does not claim access to a real museum system or measured release outcomes.
Research: retain provenance in comments and interviews
Start with an explicitly authorized comment export rather than assuming permission to log into platforms, bypass restrictions or scrape at scale. Assign source identifiers, retain time range and language, and remove names, contact information and identifying details. Define deduplication: repeated exports of the same record may be merged, but similar statements from different people remain separate observations. Describe sampling and missing channels as limitations.
Ask the agent to classify entry-point confusion, interrupted downloads, unclear completion and other issues, allowing multiple themes per record. Require supporting identifiers and counterexamples. A synthetic comment saying that playback was expected to work offline supports a question about understanding; it does not establish a network-service defect. Audit classifications before deciding what to investigate. Theme frequency describes the supplied sample, not the proportion of all museum visitors.
Handle interviews separately: distinguish the statement, situation, observed behavior, inferred cause and open question. Break a request for offline functionality into when preparation happens, how completion is recognized, what is expected without a connection and what happens when storage is insufficient. Comments describe outcomes while interviews can reveal processes. Keep contradictions and investigate them instead of removing counterevidence to create a tidy story. Deliver an evidence table, theme summary, gaps and follow-up questions.
Decisions: establish which data is actually available
When data spans systems, inventory the system, owner, exportable fields, time range and authorization state. Record inaccessible sources and request approved aggregate exports rather than connecting new accounts or expanding access. Create a data dictionary defining event meaning, timezone, version, deduplication key and missing-value semantics. A blank value is not automatically a failure, and test devices must not be mixed with real usage.
Use Exploratory Data Analysis for a bounded profile of an authorized local CSV, including aggregate fields, missingness and anomaly risks. Core CLIs require Python 3.11 or later; the full optional environment has additional requirements. Read the pinned SKILL.md for exact formats and dependencies. Bound the data root and output directory, preserve inputs, avoid identifying raw records and never silently remove observations. This step does not automatically build a production dashboard, test experimental significance or establish causation.
Write implementable metric definitions. For download completion rate, the denominator might be valid tasks starting in a specified version and observation period, and the numerator those tasks with a confirmed completion event. Define repeated starts, completions after midnight, missing telemetry and version transitions. Check a hand-countable synthetic fixture before asking the data owner to confirm the rule. A dashboard specification should state metrics, filters, refresh cadence, latency and ownership. A mock chart is not evidence of a connected system.
Experiments: separate description, hypotheses and decisions
If a practice fixture shows ten starts and six completions for A, and ten starts and eight completions for B, report the observed 60% and 80% alongside the tiny, synthetic sample limitation. That does not prove that a new entry point caused an improvement or establish statistical significance. Before a real experiment, define allocation units, the primary metric, observation window, exclusions, guardrails and stopping conditions, and have the responsible statistical reviewer confirm the method.
The agent prepares data questions, alternative explanations and discussion material. The PM and relevant owners decide the next action. Here the next step tests whether visible progress and completion states reduce confusion, while a full playback-service rewrite stays outside scope. Record evidence identifiers, alternatives, constraints and a review date. If product behavior cannot be distinguished from instrumentation failure, improve observability before making a business conclusion.
Delivery: decompose approved requirements and dependencies
After scope agreement, ask for tasks containing a requirement identifier, deliverable, owner, dependencies and acceptance conditions. D1 establishes state definitions; D2 implements progress and failure messages after D1 is agreed; D3 checks success, failure, cancellation and offline fixtures; D4 is the owner's pilot decision. Labeling everything high priority does not resolve dependencies. Explain ordering through risk and blocking relationships.
Make examples observable: an unfinished download must not appear available offline; completed cached content should work in the defined disconnected practice environment; insufficient storage should produce an explanation and a recovery route. Separate test devices from visitors, and state cleanup and rollback scope. An agent can prepare tasks and test instructions, but this article does not claim to have built a player, executed disconnected-device tests or released a version.
Reporting: generate from evidence, then inspect and deliver
The English source also describes a pipeline that retrieves business-system data, produces a report and exports Word. Split this into acquisition, definition checks, drafting, export and delivery, verifying access and outcomes independently. Without a verified connector, use an approved local export. A written report does not demonstrate that the agent logged into a system or sent anything to a team.
Report only supported states: what finished, which acceptance record supports it, what remains blocked, who owns the blocker and what is planned next. Keep plans separate from accomplishments and retain failures. At the drafting step, Writing Guidelines can inspect technical phrasing and structure. Provide the target document and access to its linked handbook, adapting recommendations to the team's language and style. It does not verify delivery facts, acquire system data or export Word documents.
If Word is required, use a suitable exporter, reopen the output and inspect headings, tables, evidence links and pagination. Before distribution, confirm the intended recipients and content scope. Track generated, opened-and-checked and not-yet-sent artifacts separately instead of using one completed label for every step.
Skills, team adoption and FAQ
Before a target skill installation, check whether SkillPI Skill Finder is available and use its official setup instructions if missing. Match the task and inspect source, version, license and prerequisites. The open-source PM Skills project supplies staged methods and examples that inform input/output design; it is not presented here as a verified SkillPI association. Validate invocation and tool prerequisites separately in each host, using the official Codex skills documentation for Codex behavior.
How do you avoid making the workflow slower? Record correction time, rework, useful findings and actual charges for comparable tasks. Do not assume a fixed week-three payoff. How should a team adopt it? Share de-identified fixtures, task cards, versions and acceptance rules, then have a second person reproduce the workflow and explain differences instead of merely distributing installation commands.
Does the PM role disappear? This design places responsibility in problem definition, evidence quality, tradeoffs and acceptance while assigning bounded organization and checking to the agent. What if the catalog has no matching skill? Keep a workable manual or scripted step and record the gap. When a new skill appears, rerun the same fixture before updating the association. Judge automation by traceable artifacts and outcomes rather than unsupported installation totals or speed claims.