From long-task
Produces feature-level detailed designs with interface contracts, algorithm pseudocode, diagrams, and test inventory before TDD in long-task projects.
npx claudepluginhub suriyel/longtaskforagent --plugin long-taskThis skill uses the workspace's default tool permissions.
Delegate feature detailed design production to a SubAgent with fresh context. The main Agent only dispatches and parses the structured result — it never reads design/SRS/UCD document sections or writes the design document directly.
Generates architecture/design documents from approved SRS docs when no prior design exists, proposing 2-3 approaches with trade-offs and securing section-by-section approval.
Generates product specs, engineering designs, and TDD implementation plans for features, bugfixes, migrations, or refactors via multi-perspective analysis, validation, and adversarial review.
Guides feature development from idea to implementation: creates EARS requirements, design documents, and task lists in .kiro/specs/.
Share bugs, ideas, or general feedback.
Delegate feature detailed design production to a SubAgent with fresh context. The main Agent only dispatches and parses the structured result — it never reads design/SRS/UCD document sections or writes the design document directly.
Announce at start: "I'm using the long-task-feature-design skill to produce a detailed design via SubAgent."
category: "bugfix" features)long-task-work as a sub-skill (not directly by router)For
category: "bugfix"features: SubAgent should focus on: (1) root cause documentation (fromroot_causefield), (2) targeted fix approach, (3) regression test inventory from SRS acceptance criteria (viasrs_trace). Skip full interface contracts, data flow diagrams, and state diagrams unless the bug directly touches those surfaces.
Collect these from the current session state. Do NOT read document contents yourself:
feature_json — current feature object from feature-list.json (compact JSON)quality_gates_json — quality_gates from feature-list.json (compact JSON)tech_stack_json — tech_stack from feature-list.json (compact JSON)design_doc_path — path to design doc (docs/plans/*-design.md)design_start / design_end — line range of the §4.N subsection (from Orient Document Lookup)srs_doc_path — path to SRS doc (docs/plans/*-srs.md)srs_start / srs_end — line range of the FR-xxx subsection (from Orient Document Lookup)ucd_doc_path — path to UCD doc (only if "ui": true; omit otherwise)ucd_start / ucd_end — line range of relevant UCD sections (if applicable)ats_doc_path — path to ATS doc (docs/plans/*-ats.md), if it exists; omit otherwiseconstraints — constraints[] from feature-list.json rootassumptions — assumptions[] from feature-list.json rootoutput_path — target file: docs/features/YYYY-MM-DD-<feature-name>.mdworking_dir — project working directoryYou are a Feature Design execution SubAgent.
## Your Task
1. Read the execution rules: Read {skills_root}/long-task-feature-design/references/feature-design-execution.md
2. Read the template: Read {skills_root}/long-task-feature-design/references/feature-design-template.md
3. Read design section: Read {design_doc_path} lines {design_start} to {design_end}
4. Read SRS section: Read {srs_doc_path} lines {srs_start} to {srs_end}
5. Read UCD sections: Read {ucd_doc_path} lines {ucd_start} to {ucd_end} (only if ui:true)
5b. Read ATS mapping table: Read {ats_doc_path} (only if ATS doc exists) — locate the mapping rows for the feature's requirement ID(s) (from srs_trace); extract required categories
5c. Read internal API contracts: Read {design_doc_path} Section 6.2 — locate rows where this feature appears as Provider or Consumer. These define the exact schemas this feature must produce or consume.
6. Follow the execution rules to produce the detailed design document
7. Write the document to: {output_path}
8. Return your result using the Structured Return Contract in the execution rules
## Input Parameters
- Feature: {feature_json}
- quality_gates: {quality_gates_json}
- tech_stack: {tech_stack_json}
- Constraints: {constraints}
- Assumptions: {assumptions}
- ATS doc path: {ats_doc_path} (or "none" if no ATS doc exists)
- Working directory: {working_dir}
## Key Constraints
- Write the complete design document to {output_path}
- Every section (§2-§6) must be COMPLETE or have "N/A — [reason]"
- Test Inventory negative ratio must be >= 40%
- Test Inventory main categories (FUNC/BNDRY/SEC/UI/PERF/INTG) must cover all ATS-required categories for this feature's requirement(s)
- Features with external dependencies must have ≥1 INTG row per dependency type; pure-computation features: "INTG: N/A"
- Features with `"ui": true` MUST have a complete Visual Rendering Contract (§Visual Rendering Contract): all visual elements listed, rendering technology specified, positive rendering assertions defined. "N/A" is only valid for `"ui": false`. For each positive rendering assertion, at least one `UI/render` Test Inventory row must exist. Missing rows → FAIL.
- **Codebase constraints** (if Design doc §13 exists): Read {design_doc_path} §13 for codebase conventions. Interface Contract method names must follow §13.5 naming conventions. Error handling must follow §13.6 pattern. Dependencies must use §13.1 internal libraries where applicable. Do not reference prohibited APIs from §13.2.
- Do NOT start TDD — only produce the design document
Claude Code: Use the Agent tool:
Agent(
description = "Feature Design for feature #{feature_id}",
prompt = [the constructed prompt above]
)
OpenCode: Use @mention syntax or the platform's native subagent mechanism with the same prompt content.
Read the SubAgent's returned text and locate the ### Verdict: line:
### Verdict: PASS
output_path## Visual Rendering Contract section from the produced document and verifies:
UI/render rows in the Test Inventory matches or exceeds the number of Visual Rendering Contract elementsfeature_design_doc, test_inventory_count, tdd_task_counttask-progress.md: "Feature Design: PASS ({N} test scenarios, {M} TDD tasks)"assumption_count > 0: append to task-progress.md: "({K} assumptions documented in Clarification Addendum)"### Verdict: CLARIFY
AskUserQuestion in a structured format:
Feature Design Clarification Required: Feature #{id} ({title})
While analyzing requirements and design documents, {N} ambiguity(ies) were found
that affect the design. For each, a suggested interpretation is provided —
you may accept it, provide a different answer, or say "skip" to use the suggestion as an assumption.
Ambiguity 1 [{category}]: {description}
Source: {source}
Impact: {impact}
Suggested: {suggested_interpretation}
→ Your answer (or "accept" to use suggested, or "skip" to assume):
Ambiguity 2 [{category}]: ...
AskUserQuestion:
Clarification Summary for Feature #{id}:
1. [{category}] {description} → Resolution: {answer} (Authority: {authority})
2. ...
Proceed with these resolutions? (yes / revise #N)
## Clarification Addendum (user-approved resolutions)
| # | Category | Original Ambiguity | Resolution | Authority |
|---|----------|--------------------|------------|-----------|
| 1 | {category} | {description} | {resolution} | user-approved / assumed |
Apply these resolutions as authoritative constraints. Do NOT re-flag these
as ambiguities. Incorporate them into the design as if they were in the
original SRS/Design documents.
task-progress.md: "Feature Design: CLARIFY ({N} ambiguities resolved) → re-dispatching"CLARIFY a second time after receiving clarifications, escalate remaining ambiguities to user:
"Persistent specification gaps found after 2 clarification rounds. Consider using long-task-increment to update the SRS/Design documents."
task-progress.md, suggest long-task-increment, skip to next eligible feature### Verdict: FAIL
AskUserQuestion### Verdict: BLOCKED
AskUserQuestionCalled by: long-task-work (Step 4)
Requires: System design doc, SRS, feature-list.json
Produces: docs/features/YYYY-MM-DD-<feature-name>.md (written by SubAgent)
Chains to: long-task-tdd (via Work Steps 5-7)