Start with three reviewable artifacts, even without coding
A fictional community equipment station is introducing projector reservations. Its product owner wants to compare existing reservation experiences, define requirements and hand a process to engineering. Codex can help organize evidence and drafts, but fast generation must not blur unknown needs, competitor marketing and verified behavior. A source matrix, PRD and editable flow are better starting deliverables than an unexplained bundle of packages. This guide preserves competitive analysis, PRDs and flowcharts from both originals. Examples are synthetic; no private system was accessed, user interviewed or feature released. Define inputs, available tools and acceptance first. Skills assist specific steps rather than replacing product judgment.
Scenario one: answer what competitors actually do with evidence
Define comparison questions: when capacity is reserved, how cancellation releases it, whether waitlists exist and how users see status. Select a few comparable public services, keeping audience, plan and region differences explicit. Record product, page, date, plan, visible behavior and evidence location. Mark inaccessible functionality unverified. Ask Codex to organize public descriptions and authorized observations into a matrix. Distinguish official claims, observed behavior, inference and unknowns in each cell. A page not mentioning waitlists does not establish absence. Do not invent pricing, user counts or feedback to complete a table, and do not treat a marketing adjective as a concrete capability. Before deriving opportunities, ask whether this team's users share the problem. Limited projectors may make waitlists valuable, but that remains a hypothesis. Record support, counterexamples and research needed. A competitor feature is not automatically a requirement, and more features do not establish a better option. If the team already uses authorized Notion connections, Notion Research & Documentation fits synthesis of reviewed materials. Its public listing, pinned OpenAI plugins source and MIT license have been checked. It requires readable authorized sources, needed Notion tools and an agreed destination. It is not a general web crawler, complete market-data source or replacement for research. Without the connection, an ordinary source table can suffice. Deliver the matrix, sources, comparison limits and opportunity hypotheses. Important conclusions should trace to cells and time-sensitive facts should be revisited before a decision. Distinguishing a competitor's description from actual observation is more useful than a polished report alone.
Scenario two: write a PRD with failure paths
Begin with user tasks: staff lend equipment, borrowers need confirmation and managers resolve conflicts. Limit scope, perhaps one item and fixed slots, rather than adding payments and cross-site approvals incidentally. Define goals, exclusions, roles, prerequisites, fields, rules, states, exceptions and acceptance before filling a template. Define observable reservation success: server confirmation with a stable identifier, the slot occupied and the state visible after refresh. A green button is not persistence evidence. Repeated activation, timeout, concurrent demand, cancellation and release need distinct behavior. Timeout can leave the outcome unknown, so a retry instruction must account for duplicates. Give rules identifiers and examples. One projector-slot can have one effective reservation; display pending before confirmation; cancellation releases capacity according to policy. Include positive, negative and unresolved cases. Describe who may view, cancel and act for another person rather than using administrator as an unlimited-access shortcut. Acceptance may use Given/When/Then or plain sentences as long as input, action and observable result are clear. Separate page, API and data evidence. Browser checks can inspect feedback; persistence and concurrency need appropriate engineering validation. A non-coding PM need not implement every test, but should understand what evidence supports each claim. Writing Guidelines fits clarity review of an existing technical requirements document. Its public listing, pinned Vercel source and MIT license have been checked. Provide the PRD, terminology and audience. It can improve structure and instructions, not decide priority, validate demand or guarantee a flaw-free system. Deliver a revisioned PRD, rule-to-acceptance mapping, open questions and review notes. Assign unresolved questions rather than inventing answers. Changes should update linked rules and diagrams so artifacts do not silently disagree.
Scenario three: model states and branches before choosing drawing tools
List start, input, server check, success, failure, unknown and cancellation. Label edges with conditions and distinguish user action from system decision. Include capacity conflict and unknown timeout, not only the ideal path. Endpoints should match PRD states and loops need exits. Open source Mermaid is a candidate for versioned text diagrams because of editable syntax and documentation, not because appearance proves correctness. Pick an appropriate flow or sequence view and keep node text manageable. Validate in the team's actual renderer; versions and layout differ. An exported PNG is not an editable source. Grouping borrower, service and staff can clarify responsibility, but a visual grouping should not be described as guaranteed strict swimlane semantics. Sequence views help explain request and confirmation; state views help explain lifecycle. A whiteboard tool is another option when editable source and export travel together. Ask Codex to map nodes and conditions to rules: cancellation release, failure versus unknown and staff intervention. Walk synthetic cases through the graph for missing entrances, exits and contradictory routes. Rendering proves syntax or presentation, not business correctness. Deliver source, rendered output, rule-node mapping and issues. No unverified diagram skill is linked, and a database ER package is not substituted for business-process modeling. Future candidates need source, license, dependencies and output-format review.
Verify skills inside a real bounded task
Official OpenAI documentation describes skills as instructions with optional resources, selected through metadata or explicit invocation in the current environment. Installation, discovery, invocation and artifact acceptance are different states. Verify the official SkillPI Skill Finder source and prerequisites before using discovery, or directly inspect a known package. A finder is not mandatory for every task, and paths and interfaces vary by product and environment. Record source revision, license, scripts, tools and data scope. A package requiring Notion, a browser, runtime or account does not gain those by being copied into a directory. Model and service costs may remain. Do not promise universal free use or token savings; validate a small fixture first. A bounded request is: “Using synthetic projector requirements, produce a source-typed comparison matrix, a scoped PRD with exceptions and an editable flow mapped to rules. Invent no prices or interviews, connect no real data and do not publish. Identify where skills apply and separate completed work from checks still needed.” This lets a non-coding owner assess more than writing style.
FAQ and troubleshooting
Insufficient material should remain unknown with a research plan. Repeated PRD rejection calls for checking goals, rules, scope and acceptance before adding prose. Diagram disagreement should be resolved against the accepted rule revision and reflected in change records. A skill is missing: inspect the actual environment, structure, metadata, scope and current product support instead of claiming one directory issue explains nearly every failure. Skills do not replace responsibility for value, decisions or real validation. Non-coding users can begin with evidence and documents, while tool execution and release retain prerequisites and permissions. Three scenarios do not require three packages each.
Sources and maintenance
Both originals cover competition, PRDs, diagrams and installation FAQ. These remain through an original projector-reservation case. Skill behavior references official OpenAI documentation, diagram source references Mermaid upstream and associations use pinned package sources. Anonymous success quotes, tested-by-many claims, popularity and zero-cost guarantees are omitted. No actual competitor testing or interviews were performed. Revisit sources and associations while preserving public slug and pairing.