Requirements Discussion
Investigate the current behavior and, before design begins, organize the goals into confirmed product requirements, clear decisions, and acceptance criteria.
Requirements
Intended for Codex-class agents with repository and file access capabilities. The documentation does not provide browser, testing tools, credentials, project data, or permission to modify external systems; other hosts may require adaptation.
- Clarify access to the goals and relevant existing project information
- Users who can make decisions on product issues not yet clarified by authoritative sources
- Real samples provided or specified by the user when key acceptance criteria depend on samples
Quick start
- After downloading, check the package documentation first, then extract the ZIP to a temporary directory.
- When installing the combined package, copy the six Skill folders and the same-level shared folder into the project's .agents/skills/ or the personal ~/.agents/skills/. Keep the relative directory structure, and do not treat the outer directory of the combined package as one Skill.
- When installing an individual ZIP, put its same-named folder into the selected Skills directory and keep its internal shared resources. Back up the same-named Skill before overwriting to avoid duplicate installation.
- Use the accurate $talking-us call in Codex; if it is not detected, restart the host. When a task requires workflow handoff, install the corresponding companion Skill separately.
Applicable Scenarios
- Clarify new features or changes to existing behavior
- Address permissions, ownership, failure recovery, and boundary rules that may affect implementation
Usage Steps
- Call $talking-us with the target and the actual project; the flow first investigates relevant facts and does not pass issues that can be independently verified to the user.
- Clarify roles, normal entry points, inputs, rules, results, and recovery methods, and record confirmed, inherited, suggested, and pending items separately.
- Answer remaining independent product choices; partial answers close only the corresponding sub-items, while unresolved dependencies remain.
- Review the requirements draft and acceptance criteria, and determine whether it is ready for design, partially ready, or blocked, as well as unresolved issues and documentation location.
Field Naming and Page Copy
Requirements, frontend and backend fields, pages, interfaces, and exports use common, accurate, and consistent business names, and clarify the mapping between display labels and existing identifiers without breaking the public contract due to renamed display names. Pages do not add explanations that were not explicitly requested by default, and do not move explanations to placeholders, Tooltip, or collapsible areas; required labels, validation, status, error, and recovery feedback are retained as usual. A separate ZIP already includes the required shared references.
Delivery
- Save the detailed requirements documentation that is continuously maintained under the actual project's .talking-us/ directory
- Stable REQ/AC numbers, decisions, and issue records, and an explicit ready status
Limitations
- Only conduct requirements work; do not write design documentation, and do not modify product code, configuration, or data.
- Existing behavior is a fact, not approval that the target behavior has been approved; silence and suggestions are not confirmation.
- Missing samples or unresolved key rules may block readiness; when discussion ends, deliver the draft rather than fabricate consensus.
Example Prompts, Not an Actual Execution Case
Use $talking-us to clarify this project's export functionality. First check existing roles and export behavior, then ask me about ownership, format, quota, and failure recovery rules that have not yet been determined, and maintain the requirements draft. Do not implement, and do not decide unresolved business rules for me.
This guide explains the in-package workflow; it does not represent validated cross-model reliability, nor is it an actual acceptance run report.
--- name: talking-us license: MIT description: >- Investigate the current state, clarify product requirements, and confirm decisions about impact, business rules, permissions, interactions, and acceptance one by one to produce a detailed requirements document ready for design handoff. Use for requirements discussions and iterative clarification; do not write development designs or modify product code. --- # Requirements Discussion Turn the user's goals into product agreements with traceable sources and no known critical ambiguities. Establish completeness through user tasks and counterexamples, and confirmation through actual answers; do not judge readiness by the number of questions, document length, or model confidence. Only investigate and maintain requirements documents. Do not modify the product, configuration, database, deployment, or global terminology files. Load `write-design-doc`, `develop-closed-loop`, `test-case`, or `bug-fixing` only at handoff. Prefer the version specified by the user; otherwise use the currently enabled entry point. Do not load the entire set at once. ## 1. Investigate Facts First and Identify Decisions That Require Asking
talking-us/LICENSE talking-us/MANIFEST.json talking-us/README.md talking-us/SKILL.md talking-us/agents/openai.yaml talking-us/references/product-interaction.md talking-us/references/question-format.md talking-us/references/requirements-doc-template.md …