suriyel/longtaskforagent/long-task-requirements

LANGUAGE RULE: You MUST respond to the user in Chinese (Simplified). All generated documents, reports, and user-facing output must be written in Chinese. Skill names, code identifiers, and JSON field names remain in English.

Requirements Elicitation & SRS Generation

Turn raw ideas into a structured, high-quality Software Requirements Specification (SRS) through systematic elicitation, challenge, and validation — aligned with ISO/IEC/IEEE 29148 and EARS requirement syntax.

Adapts depth automatically: Lite track for clear-scope projects (3–5 rounds), Expert track for complex domains (10–20 rounds). Both produce the same SRS template output.

<HARD-GATE> Do NOT invoke any design skill, implementation skill, write any code, scaffold any project, or take any design/implementation action until you have presented the SRS and the user has approved it. This applies to EVERY project regardless of perceived simplicity. </HARD-GATE>

Anti-Pattern: "This Is Too Simple To Need an SRS"

Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The SRS can be short (a few sentences for truly simple projects), but you MUST present it and get approval.

Checklist

You MUST create a TodoWrite task for each of these items and complete them in order:

1. Explore project context — read existing docs, code, constraints; detect SRS template
2. Complexity assessment — evaluate 5 signals, select Lite or Expert track (internal)
3. Problem & scope elicitation

• Lite: L1 (focused problem & scope, 1 round)
• Expert: E1 (problem framing via references/problem-framing.md) + E2 (enhanced scope)

1. Functional requirements elicitation

• Lite: L2 (flat capability rounds)
• Expert: E3 (scenario walkthrough via references/scenario-walkthrough.md) + E4 (hypothesis-correction via references/hypothesis-correction.md)

1. NFR + hidden requirements

• Lite: L3 (merged, 1 round)
• Expert: E5 (hidden requirements) + E6 (NFR quantification)

1. Constraints, assumptions, glossary — same for both tracks
2. Classify requirements — functional / NFR / constraint / assumption / interface / exclusion
3. Write requirements — apply EARS templates, assign IDs, write acceptance criteria, generate diagrams
4. Validate SRS — check 8 quality attributes, detect anti-patterns, verify testability
5. Granularity analysis — bidirectional sizing: detect oversized FRs (G1-G6 split) AND undersized FRs (S1-S4 group) to fit context budget; user approval for non-trivial changes
6. Scope fit & deferral — assess current-round vs next-round, generate deferred backlog if applicable
7. [Expert only] Alignment validation — via references/alignment-validation.md
8. SRS Compliance Review — dispatch srs-reviewer subagent; gate: all checks PASS before proceeding
9. Present & approve SRS — Lite: single combined step; Expert: section-by-section
10. Save SRS & backlog — docs/plans/YYYY-MM-DD-<topic>-srs.md + deferred backlog (if any) and commit
11. Transition to UCD — REQUIRED SUB-SKILL: Invoke long-task:long-task-ucd

The terminal state is invoking long-task-ucd. Do NOT invoke any other skill.

Step 1: Explore Context

1. Read the user-provided requirement doc / idea description thoroughly
2. Explore existing code / repos the project will build on or integrate with
3. Identify initial constraints: tech stack, platform, integrations, regulations
4. Read docs/rules/ (if exists and populated) — codebase conventions extracted by Phase 0-pre scanner:

• coding-constraints.md — 2/3方件 library constraints, prohibited APIs, internal library mandates
• build-and-compilation.md — build system and CI/CD constraints
• These constraints may affect requirement feasibility and should be considered during elicitation (e.g., "this feature requires HTTP calls — project mandates using internal HTTP library, not standard fetch"; "project CI requires all code to pass checkstyle — affects acceptance criteria")

1. Check for an SRS template:

• If the user specified a template path → read and validate it
• Else → read docs/templates/srs-template.md (the default template shipped with this skill)
• Validation: template must be a .md file containing at least one ## heading

Step 1.5: Complexity Assessment (internal — no user interaction)

After Step 1, evaluate 5 complexity signals against the user's description and project context:

≥3 Expert signals → Expert track. Otherwise → Lite track.

Record the tier decision internally. Do NOT ask the user which tier to use.

Escalation Trigger (Lite → Expert)

During Lite elicitation, if ANY of these emerge, switch seamlessly to Expert track:

• 2+ distinct user roles with conflicting needs
• 3+ external system integrations surface
• Regulatory/compliance requirements are mentioned
• User contradicts their own earlier answers (signals unclear mental model)
• FR count exceeds 10 after elicitation

On escalation: all Lite artifacts gathered so far become Expert input. Do NOT restart or announce a disruptive switch — simply begin asking deeper questions (E1 problem framing, E3 walkthrough, etc.).

Step 1.6: Targeted Codebase Exploration (brownfield only — no user interaction)

Trigger conditions (ALL must be true):

1. docs/rules/ exists AND contains ≥1 .md file beyond a greenfield stub (brownfield project)
2. The user's description mentions concrete functionality, a domain area, or a specific module (not too abstract to target)

Skip if: greenfield project, OR user description is too vague to derive a focus direction (e.g., "I want to build a platform" with no specifics).

Execution:

1. Extract a focus direction from the user's description:

• Identify domain keywords (e.g., "authentication", "payment", "API gateway", "data pipeline")
• Infer relevant --focus dimensions (e.g., auth → api,architecture; data pipeline → dataflow,deps)
• Infer --path if the user mentions a specific module or directory

1. Determine exploration depth from context (do NOT hardcode):

When in doubt, omit --depth and let explore's LOC-based auto-detection decide (<1K→quick, 1K-10K→standard, >10K→deep).

1. Dispatch long-task-explore with context-driven parameters:

``` Agent( subagent_type="general-purpose", description="Targeted codebase exploration for requirements context", prompt=""" Invoke the long-task:long-task-explore skill with these parameters:

• Depth: {determined_depth or omit for auto-detect}
• Focus: {inferred_dimensions}
• Path: {inferred_path or "."}
• User question: "{user_description_summary}"

Execute the skill and return the exploration results. """ ) ```

1. If explore returns useful findings → incorporate into your mental model for L1/E1 questioning:

• Reference discovered modules, APIs, data models in your questions (e.g., "I found src/auth/ with JWT-based authentication — do you want to extend this or replace it?")
• Use discovered architecture patterns to ask more informed questions about integration points

1. If explore returns BLOCKED or no actionable findings → skip silently, proceed to L1/E1

This step is non-blocking — failure or lack of useful results never prevents proceeding to elicitation.

Lite Track

For projects with clear scope, single actor, and well-understood domain. Target: 3–5 interaction rounds.

L1: Focused Problem & Scope (single AskUserQuestion, ≤4 questions)

1. "What problem does this solve, and what does success look like when it's working?"
2. "Who uses it, and in what environment (desktop/mobile/CLI/API)?"
3. "What is explicitly out of scope for this version?"
4. "Any hard constraints — language, platform, hosting, licenses?"

Output: one-sentence problem statement in SRS Section 1, actor list, scope boundary, constraints.

If the answer to Q1 is vague or problem-oriented → escalation trigger fires → switch to Expert.

L2: Flat Capability Elicitation (1–3 rounds of ≤4 questions each)

For each capability area, ask per round (up to 4 questions):

• What does the user do? (trigger/action)
• What does the system do in response? (observable behavior)
• What inputs would be invalid, and what should happen?
• Confirm a concrete Given/When/Then example

Group related capabilities into the same round when they share a workflow. Split large capability areas across multiple rounds.

L3: Quick NFR + Hidden Requirements Check (single AskUserQuestion)

1. "Any performance targets — response time, throughput, data volume?"
2. "Does this handle personal data, face regulations, or need accessibility support? (If yes, which?)"
3. "Multiple languages or timezones?"
4. "Any security requirements beyond basic auth?"

Any YES to Q2 → generate EARS-formatted NFR candidates inline. If Q2 reveals significant regulatory exposure → escalation trigger.

L4–L6: Classify, Write, Validate, Present, Save

After Lite elicitation, proceed to the shared steps (Steps 7–16 in the checklist):

• L4 = Steps 7–8 (classify, EARS, diagrams)
• L5 = Steps 9–11 + Step 13 (validate, granularity, deferral, SRS reviewer with Group P = PASS-SKIPPED)
• L6 = Steps 14–16 (present entire SRS in one block as single approval, save, transition to UCD)

Expert Track

For projects with complex domains, multiple actors, or unclear scope. Target: 10–20 interaction rounds.

E1: Problem Framing [Expert only]

Read references/problem-framing.md and follow it exactly.

Summary: Single AskUserQuestion (≤4 questions) — 5-Whys seed, JTBD probe, pain ranking, solution challenge. Produces: 5-Whys chain, JTBD statement, Pain Map → embedded in SRS Section 1.3.

E2: Enhanced Scope Round [Expert only]

Use slots freed by E1 answers. Single AskUserQuestion (≤4 questions). Replace standard Round 1 questions already answered in E1 with targeted probes:

• Workaround probe: "Walk me through the most annoying step in [workaround from Pain Map]. What makes it frustrating — is it manual, error-prone, slow, or opaque?"

→ Every step the user hates in their current workaround is a candidate FR.

• Environment probe: "Where and when is this typically done — at a desk with a large screen, on mobile in the field, under time pressure, or shared among a team?"

→ Reveals UX, offline, mobile-first, multi-user, and accessibility constraints.

Plus remaining standard scope questions not yet answered by E1 (out of scope, constraints).