Choose a skill by the artifact you need
A community repair service is considering a booking page for drop-off appointments. The PM needs a competitor comparison, a scoped PRD and a traceable view of user feedback. This example uses fictional services and synthetic records to show how to choose capabilities. Installation counts, a PM-sounding name and attractive prose do not replace checks of purpose, source and output.
Write a selection card first: where the work is stuck, which materials are available, what output is required, which systems are outside scope and how completion will be checked. Use a skill only at the step it supports. Competitor research, editorial review and interface implementation are different jobs. This guide does not repeat unverified download figures or turn the original list's names into invented SkillPI links.
Competitor analysis: build a decision-backed comparison
Define the questions before collecting features: can visitors see available slots, can staff close a day, and what happens to duplicate submissions? Compare tools Alpha and Beta with the existing phone process, clearly labeling practice options as fictional. For real research, retain official help pages or authorized trial observations with date, region, version and evidence identifiers. Missing documentation is not proof of a missing capability; flexible booking in marketing copy does not establish every required rule.
Ask for questions and evidence gaps before a matrix. Each conclusion must point to a source, while inferences stay separate. Prices need the applicable plan and billing period; leave unresolved values unknown. Audit two cells before expanding the report. If using SWOT, attach a reason to each judgment rather than filling categories with unsupported claims of superiority.
The report should answer this decision rather than maximize chapter count. Here the next step tests whether visible drop-off slots are sufficient, while automatic routing stays outside scope. When there is no verified matching competitor-analysis skill in the current SkillPI catalog, perform bounded research from the task card instead of presenting an editor or design skill as a research specialist. The open-source PM Skills method library offers staged artifact examples as methodological reference; that is not proof of installation, execution or a verified catalog association.
PRDs: connect strategy, rules and acceptance
Provide context, target users, the current process, resource constraints and the evidence matrix together. Ask for requirements, open questions and exclusions before a draft. After the owner confirms them, explain when slots are selectable, who changes availability and how failures behave. Trace requirements to evidence and keep a decision log when scope changes so old screenshots do not silently define the new version.
For example, R1 lets a visitor review the selected date and slot before confirmation; R2 prevents choosing a closed day; R3 produces only one simulated booking after repeated submission clicks; R4 preserves entered information and explains recovery after failure. These are prototype acceptance rules. Real duplicate prevention and concurrent capacity handling still need engineering design. Keep telephone exceptions, while excluding payments, repair quotations and automatic technician assignment from this iteration.
Include the problem, goal, roles, normal and failure flows, scope, acceptance fixtures and unresolved decisions. A user story can explain why the behavior matters: a visitor unable to call during working hours needs to see suitable slots in advance. The story does not replace detailed rules or establish that every visitor shares the need. Product, design and engineering should confirm business intent, interaction expression and implementation limits separately.
Tie prioritization to the current goal, such as testing whether visible slots reduce avoidable coordination. Do not manufacture an OKR cascade or quarterly commitment from a feature idea alone. If the strategic objective is unclear, request the relevant owner and evidence before ranking work as essential.
At the technical-prose review step, Writing Guidelines can inspect structure, terminology and examples and return located revision suggestions. It requires target files and access to its linked writing handbook. Adapt its technical-writing guidance to the team's audience and language. It does not validate user needs or export Word. Recheck references, constraints and failure semantics after editing so smoother wording does not alter commitments.
User research: preserve evidence before prioritizing
Start with authorized, de-identified interview excerpts and feedback exports. Give each record an identifier and preserve relevant timing and context. Separate a participant's statement, observed behavior, interpretation and proposed need. Do not invent quotations to fill a persona or turn three comments into population-level demand.
For this synthetic exercise, one visitor misses calls during work, another does not know which day accepts electrical items, and staff report that phone availability changes with volunteers. These suggest questions about access, eligibility and capacity, not a proven need for automatic technician assignment. Keep contradictory cases, including a person who prefers calling because an item needs discussion.
Use themes only when their supporting identifiers and exceptions are visible. Ask what happens before the decision, which alternatives people use, what outcome they seek and which constraints influence them. Mark segment descriptions and motivations as hypotheses until supported. When evidence conflicts with the desired roadmap, preserve the conflict and plan a check rather than delete the inconvenient record.
Turn confirmed needs into tasks with an owner, dependency, deliverable and acceptance condition. Agree on availability rules before implementing a calendar, and agree on failure behavior before preparing a test script. Priority labels do not resolve dependency order. This planning method does not claim compliance with a named project-management standard simply because a task table exists.
An optional prototype makes the rules easier to inspect
Once research and requirements justify an interface trial, Frontend Design can guide implementation and visual direction from an agreed brief. Provide the audience, primary job, content, sample states, output format and a prohibition on real submissions. It needs a coding agent with project read/write access, the project runtime and rendering tools. Model usage and environment costs remain separate.
Build a local demonstration of slots, selection summary, closed-day messaging, confirmation and simulated failure. Use clear action labels, selection cues beyond color and a keyboard route through the key controls. Keep dates and errors visible on narrow screens. Mark data as simulated and ensure confirmation does not call a production service. Deliver a requirement-to-screen map, state notes, reusable styles, limitations and startup instructions. A static picture should be labeled static rather than described as a completed booking flow.
Afterward, Webapp Testing fits checks of the running local page. Its Python Playwright workflow needs Python, browser dependencies, a startup command, a port and fixtures. Observe before writing locators and assertions; retain scripts, screenshots and browser logs. Cover correct selection summary, disabled closed dates, preserved inputs after failure, duplicate simulated submissions, keyboard use and a narrow layout. Label checks that were not executed. Browser tests do not prove research conclusions, backend concurrency or production security.
Install, maintain and reassess the stack
Before installing a target, check whether SkillPI Skill Finder is available and follow its official instructions if missing. Search for the precise task, read full SKILL.md, source version, license, dependencies and permissions, and record why it fits that step. Use the official Codex skills documentation for invocation behavior. Discovery paths and tool prerequisites still need independent verification in another host.
Should six skills be installed at once? Start with the few needed for the current artifact. Skill descriptions occupy discoverable context and overlapping names can complicate selection. Validate one minimal task first. Manage enabled state and versions through supported host mechanisms rather than assuming a third-party personal page controls every local installation.
Before an update, keep a recoverable version and rerun the same selection card and fixtures. Check package fees, licenses, model calls, dependencies and maintenance separately; free instructions are not a zero-cost workflow. PMs can own briefs and acceptance without writing every line of code, but someone must inspect runtime failures and engineering limits. Accept the matrix, PRD and research table only when claims have sources, rules are explicit and unknowns remain visible. Reassess new catalog skills against those same artifacts before changing associations.