From long-task
Processes increment-request.json: orients on project state, elicits incremental EARS requirements with acceptance criteria, classifies changes, updates SRS/design docs, appends to feature-list.json.
npx claudepluginhub suriyel/longtaskforagent --plugin long-taskThis skill uses the workspace's default tool permissions.
Add new requirements, modify existing ones, or deprecate features in a live project. All changes are written back into the existing SRS/Design/UCD documents (tracked via git history), and new features are appended to `feature-list.json` with wave metadata.
Analyzes impact of additions, deletions, or modifications to requirements, scope, acceptance criteria, or constraints; synchronizes artifacts and hands off to canonical workflow re-entry points after hf-workflow-router routes to increment branch.
Analyzes feature requests, maintains PRDs, and decomposes into tracks with work breakdowns and execution order. For new feature planning, architecture changes, requirements analysis, or plan adjustments.
Transforms business analyses into epics, features, user stories, and tech-agnostic success criteria. Creates handoff documents for architects.
Share bugs, ideas, or general feedback.
Add new requirements, modify existing ones, or deprecate features in a live project. All changes are written back into the existing SRS/Design/UCD documents (tracked via git history), and new features are appended to feature-list.json with wave metadata.
Announce at start: "I'm using the long-task-increment skill. Let me orient on the current project state before collecting new requirements."
feature-list.json exists (project has been initialized)increment-request.json exists in project root (signal file created by user)You MUST create a TodoWrite task for each step and complete them in order:
increment-request.json — understand the reason and scope of this incrementfeature-list.json — note all features, their statuses, wave history, constraints, assumptionsdocs/plans/*-srs.md) — current requirements baselinedocs/plans/*-design.md) — current architecturedocs/plans/*-ats.md) — current test strategy baselinedocs/plans/*-ucd.md)docs/plans/*-deferred.md) — pre-elicited requirements available for pickup (skip re-elicitation for items with complete EARS + acceptance criteria)task-progress.md — session historygit log --oneline -10 — recent contextmax(wave for all features) + 1 (default to 1 if no wave fields exist)Collect new/changed requirements using structured elicitation (same rigor as Phase 0a):
AskUserQuestion to collect requirements in rounds (2-4 related questions per round)Output: A structured list of new/modified/deprecated requirements with IDs, EARS statements, and acceptance criteria.
Compare new requirements against the existing feature set:
srs_trace referencing the original requirement ID; these features will need re-verificationdependencies[]Output: Impact matrix presented to user for approval:
| Change | Type | Affected Features | Action |
|--------|------|-------------------|--------|
| FR-021 | New | (none) | Add feature(s) |
| FR-005 (modified) | Modified | Feature 5, Feature 8 | Reset to failing, update srs_trace |
| FR-012 (deprecated) | Deprecated | Feature 12 | Mark deprecated |
Hard gate: User must approve the impact matrix before proceeding.
Trigger conditions (ALL must be true):
Skip if: only new features with no existing code dependencies, OR only deprecations with no code to understand.
Execution:
From the approved Impact Matrix, extract Hard Impact features' srs_trace IDs and dependencies
Locate affected code areas:
git_sha from affected features (if set) to find relevant files via git show --statreport_path from affected features to read prior implementation contextDetermine exploration depth from impact scope (do NOT hardcode):
| Signal | Depth adjustment |
|---|---|
| 1-2 Hard Impact features, localized to one module | Prefer quick (locator sufficient) |
| 3-5 Hard Impact features, or cross-module impact | Prefer standard (need dependency + flow analysis) |
| 6+ Hard Impact features, or transitive cascade depth ≥2 | Prefer deep (comprehensive analysis) |
Affected features share a single --path subtree | Keep current or lower (narrow scope) |
| Affected features span unrelated directories | Bump up one level (broad scope) |
When in doubt, omit --depth and let explore's LOC-based auto-detection decide.
Dispatch long-task-explore with context-driven parameters:
Agent(
subagent_type="general-purpose",
description="Targeted codebase exploration for increment impact",
prompt="""
Invoke the long-task:long-task-explore skill with these parameters:
- Depth: {determined_depth or omit for auto-detect}
- Focus: architecture,dataflow,deps
- Path: {inferred_path_from_affected_features or "."}
- User question: "Understand modules affected by: {increment_scope_summary}.
Affected features: {hard_impact_feature_titles}."
Execute the skill and return the exploration results.
"""
)
Use exploration output to inform Step 4 (Design Revision):
This step is non-blocking — if explore returns BLOCKED or no actionable findings, proceed to Step 4 normally.
Update the existing design document in place for affected sections:
docs/plans/*-design.md[DEPRECATED - Wave N] marker to the corresponding design sectiondocs/rules/ and re-run in a new session).docs: update design for wave N — <brief scope>
New: FR-021 (feature title), FR-022 (feature title)
Modified: FR-005 (what changed)
Deprecated: FR-012 (reason)
Skip this step if no ATS document exists (docs/plans/*-ats.md).
Update the existing ATS document in place for affected requirements:
docs/plans/*-ats.md[DEPRECATED - Wave N] marker to the corresponding mapping table rowdocs: update ATS for wave N — <brief scope>
New: <req_ids added>
Modified: <req_ids changed>
Deprecated: <req_ids deprecated>
Skip this step if the project has no UI features AND none of the new requirements involve UI.
docs/plans/*-ucd.md[DEPRECATED - Wave N] marker to the corresponding promptsdocs: update UCD style guide for wave N — <brief scope>
Update the SRS and decompose into features:
6a. Update SRS in place:
docs/plans/*-srs.md<!-- Wave N: Modified YYYY-MM-DD — <reason> -->[DEPRECATED - Wave N: <reason>] prefixdocs: update SRS for wave N — <brief scope>
Added: FR-021, FR-022
Modified: FR-005
Deprecated: FR-012
6b. Decompose into features:
New features: Append to feature-list.json features[]:
id: max existing ID + 1 (continue incrementing)wave: current wave number Nstatus: "failing"srs_trace: array of new SRS requirement IDs (e.g. ["FR-021"])verification_steps: optional — from new acceptance criteria (Given/When/Then)dependencies: reference existing feature IDs as neededui, ui_entry: set appropriatelyModified features: For each affected existing feature:
status back to "failing" (will require re-implementation/re-verification)srs_trace to reflect the revised requirement IDsverification_steps if presentwave to N (to indicate when the modification occurred)Deprecated features: For each deprecated feature:
deprecated: truedeprecated_reason: "<reason>"Replacement features (when deprecated + new replacement):
supersedes: <deprecated_feature_id>Update root waves[] array:
{
"id": N,
"date": "YYYY-MM-DD",
"description": "Brief description from increment-request.json"
}
Update constraints[] and assumptions[] if new CON/ASM items
Update required_configs[] if new configs needed
Validate:
python scripts/validate_features.py feature-list.json
Update supporting files as needed:
long-task-guide.md: If new tools, frameworks, or patterns were introduced → regenerate or update relevant sections; re-validate with python scripts/validate_guide.py long-task-guide.md --feature-list feature-list.jsoninit.sh / init.ps1: If new dependencies were added → update bootstrap scripts (keep idempotent).env.example: If new required_configs of type env → append template lines (this is the canonical env-var reference template regardless of the project's actual config format)scripts/check_configs.py: If new required_configs are added → regenerate or update the project-specific checker to include the new configsincrement-request.json (signal file consumed)python scripts/validate_features.py feature-list.json
feat: increment wave N — <scope from increment-request.json>
New features: <ids>
Modified features: <ids>
Deprecated features: <ids>
Total features: X (Y active, Z deprecated)
task-progress.md:
## Current State header: progress count (X/Y active features passing), last event (Increment Wave M, date), next up (first failing feature)## Session N — Increment Wave M
- **Date**: YYYY-MM-DD
- **Phase**: Increment
- **Scope**: <from increment-request.json>
- **Changes**: Added N features, modified M features, deprecated K features
- **Documents updated**: SRS, Design, [UCD]
RELEASE_NOTES.md under [Unreleased] sectionchore: update progress for increment wave N
The router will now detect failing features in feature-list.json and route to Worker phase automatically.
| Rationalization | Correct Action |
|---|---|
| "I'll just add features to the JSON directly" | Use this skill for tracked, audited changes. |
| "The existing tests still pass, no need to re-verify" | Modified features must be reset to failing. |
| "I'll update the design later" | Design revision comes BEFORE feature decomposition. |
| "This change is small, skip impact analysis" | Impact analysis catches hidden dependencies. |
| "I'll create a separate SRS document" | Update the main SRS in place; git tracks history. |
Called by: using-long-task (when increment-request.json exists) Reads: SRS, Design, ATS, UCD, feature-list.json, increment-request.json Writes: SRS (in place), Design (in place), ATS (in place), UCD (in place), feature-list.json (append/modify) Chains to: long-task-work (after increment complete, via router detecting failing features)