clarify-project-requirementslisted

Clarify and baseline software project requirements before production design or implementation. Use for new projects, ambiguous feature requests, major scope changes, conflicting product sources, missing acceptance criteria, or when brand, engineering name, audience, platform, SEO, performance, security, privacy, accessibility, visual direction, prototype need, or scope boundaries are not yet accepted. Apply first-principles reasoning internally while speaking to users in plain language, and defer framework, database, API, hosting, and deployment questions when the initial product outcome is still vague.
railgun20001/the-first · ★ 0 · Web & Frontend · score 70

Install: claude install-skill railgun20001/the-first

# Clarify Project Requirements Turn an idea into observable, accepted outcomes without disguising an unverified implementation choice as a requirement. ## Inspect before asking 1. Read applicable project instructions, `THE-FIRST.md`, and its requirement and experience sources. 2. Search existing PRDs, issues, roadmaps, user research, designs, schemas, tests, configuration, and current behavior. 3. Identify what each source governs, when it was accepted, and whether it conflicts with another source. 4. Answer discoverable questions from evidence. Ask the user only about intent, authority, trade-offs, missing constraints, and acceptance. 5. Stay read-only when the user requested discussion or design only. Do not create a new PRD merely because the preferred template differs from the project's existing documents. ## Reason from outcomes Maintain this reasoning chain internally: `goal → verified facts → high-impact assumptions → constraints → observable behavior → minimum sufficient requirement → acceptance evidence` Check each request: - Remove proposed technologies from the sentence. What user or business outcome remains? - Which statements have project or user evidence, and which are assumptions? - Which assumption would reverse the project direction if false? - Is the request describing an outcome, or prematurely selecting a mechanism? - What must remain true in success, failure, and boundary cases? Do not force the user to learn this vocabulary. Ask short, concrete