task-flow-close

Guides merging feature specs into domain specs and opening pull requests after task completion.

1|Updated Jan 14, 2024
One-click install
npx skills add https://github.com/Eyhenij/rt-tools --skill task-flow-close-eyhenij
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: task-flow-close
Source: https://github.com/Eyhenij/rt-tools/tree/main/.claude/skills/task-flow-close
Command: npx skills add https://github.com/Eyhenij/rt-tools --skill task-flow-close-eyhenij

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When finishing a development task, teams often forget to merge proposed specs into domain specs, leave documentation stale, or open pull requests without recording remaining steps. This Skill enforces a disciplined closing workflow so the spec, docs, and PR all reflect the actual state of the work. ## Core Features & Use Cases - Spec merging: Moves rules, scenarios (keeping their numbers), and file:symbol bindings from proposed/<feature>/ into the domain spec, then validates with npm run check:specs. - Documentation refresh: Re-reads rules, patterns, and specs the work touched, fixing stale sections like "What is not included" and "Where it lives". - PR handoff protocol: Opens the PR as draft or ready depending on CI, writes a mandatory "Remaining step" section in the PR body, and sends ordered status messages to the owner. - Use Case: After finishing a feature branch, run this pattern to merge the agreement into the domain spec, update affected docs, archive the task folder, and open a properly documented PR. ## Quick Start Ask the assistant to close the current task by merging the proposed spec into the domain spec, updating the touched documentation, and opening the pull request with the remaining-step section.

Frequently Asked Questions about task-flow-close

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I merge a proposed feature spec into a domain spec?

Append the rules from proposed/<feature>/spec.md into the domain spec sections, move scenarios keeping their original numbers, add the file:symbol bindings to implementation.md, then delete the proposed directory and run npm run check:specs to validate.

When should a pull request open as a draft versus ready?

Open as a draft when CI runs on the target base branch, then lift the draft after the run goes green. Where no pipeline runs for that base, open the PR ready immediately since the pre-push check suite already passed.

Why must scenario numbers stay unchanged when merging specs?

Test titles reference scenario numbers as link keys, so renumbering breaks the audit trail between tests and specs. If a scenario's promise changed, edit its text in place while keeping the number and update the test title in the same commit.

What documentation should be updated before opening a PR?

Re-read the specs, rules, and patterns the work touched, fixing stale sections like "What is not included", "Where it lives", and companion statements about missing features. Laws are never edited in the branch; proposed article text goes to the owner instead.

What is the remaining-step section in a PR body?

It is a mandatory final section stating exactly what remains before merge, such as waiting for the CI run and lifting the draft. It must exist from the moment the PR opens and is rewritten when nothing remains, never left empty or removed.