agentleFS
Sign inStart free
liuqi1024liuqi1024/matrix-boot/skills/requirements-design/SKILL.md

requirements-design

Skill1 starsChanged 5 months agoMITView on GitHub

Clarify business context, business architecture, rough non-functional requirements, and detailed functional requirements for staged software projects. Use when a user gives a vague project idea, needs requirement elicitation, needs business workflows, user roles, acceptance criteria, or implementation-driving requirement slices before architecture or coding.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. Scoop-technology/claude-code-skills★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository7 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 8 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill to transform vague project ideas into clear business context and later into detailed implementation-driving requirements.

    line 12
  2. Distinctive:

    Run requirements in two passes:

    line 16
  3. Distinctive:

    When the idea is vague, ask focused questions about:

    line 23
  4. Distinctive:

    Ask only the questions needed for the next decision.

    line 37
  5. Distinctive:

    Use this order for vague ideas:

    line 43
  6. Distinctive:

    Use Mermaid for simple workflows when helpful.

    line 67
  7. Distinctive:

    After producing the project brief or business architecture, stop and request explicit user review.

    line 69
  8. Very specific:

    After architecture and stack direction exist, produce docs/04-requirements/requirements-detail.md with:

    line 73
  9. Distinctive:

    After producing detailed requirements, stop and request explicit user review.

    line 85

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Requirements Design

<!-- 中文说明: 这个 skill 负责先把“做什么系统、给谁用、规模多大、有哪些约束”问清楚，避免技术选型过早。 -->

Purpose

Use this skill to transform vague project ideas into clear business context and later into detailed implementation-driving requirements.

Two-Pass Requirements

Run requirements in two passes:

  1. Business discovery before technology selection.
  2. Detailed functional requirements after business architecture and technical architecture are roughly settled.

Business Discovery Questions

When the idea is vague, ask focused questions about:

  • Business domain and core problem.
  • Target users and user roles.
  • System surface: backend API only, web application, admin console, public website, mobile/H5, mini program, desktop/client, integration service, batch/data processing, or mixed.
  • Frontend/backend scope: backend required, frontend required, mobile required, open API required, or prototype only.
  • User boundary: internal users, external users, partners, public visitors, or mixed.
  • Core business capabilities.
  • Main workflows and business objects.
  • Expected scale after surface is clear: users, traffic, data volume, concurrency, latency.
  • Security, audit, compliance, and data sensitivity.
  • Existing systems, interfaces, databases, middleware, and deployment constraints.
  • Success criteria and out-of-scope items.

Ask only the questions needed for the next decision. Do not turn discovery into a long questionnaire.

Discovery Question Order

<!-- 中文说明: 问题顺序要从“这是什么系统、给谁用、有哪些端”开始，不要先问规模或技术栈。 -->

Use this order for vague ideas:

  1. What kind of system is it and who uses it?
  2. Does it need backend, web frontend, mobile/H5, mini program, open API, or only a prototype?
  3. Is it internal, external, partner-facing, or public-facing?
  4. What are the top 3-5 business capabilities?
  5. What are the main workflows and business objects?
  6. What rough scale and non-functional requirements matter?
  7. What enterprise technology constraints already exist?

Business Architecture Output

Produce docs/00-discovery/project-brief.md and support docs/00-discovery/business-architecture.md with:

  • Business background.
  • Goals and non-goals.
  • User roles.
  • Core business capabilities.
  • High-level business workflow.
  • Main business entities.
  • Rough functional scope.
  • Rough non-functional requirements.
  • Known constraints and open questions.

Use Mermaid for simple workflows when helpful.

After producing the project brief or business architecture, stop and request explicit user review. Do not proceed to technical architecture, stack selection, or detailed requirements until the user approves the current artifact.

Detailed Requirements Output

After architecture and stack direction exist, produce docs/04-requirements/requirements-detail.md with:

  • Feature slices.
  • User stories or use cases.
  • Preconditions and postconditions.
  • Business rules.
  • Acceptance criteria.
  • Permission requirements.
  • Data requirements.
  • API/database implications.
  • Testable scenarios.

After producing detailed requirements, stop and request explicit user review. Do not proceed to API/database design until the user approves the requirements.

Gate Checks

Business discovery is not complete until:

  • The system type is clear.
  • Users and core workflows are clear.
  • Rough scale and non-functional needs are known.
  • Major enterprise constraints are known.
  • Open questions are explicit.

Detailed requirements are not complete until each critical feature has acceptance criteria and testable scenarios.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free