Run any Skill in Manus with one click

specrail-plan-tasks

Stars22

Forks0

UpdatedJuly 11, 2026 at 17:16

Use when turning an approved SpecRail product and technical spec into the numbered `tasks.md` plan. Creates stable task IDs, owners, done-when conditions, verification commands, dependencies, and handoff notes without implementing the tasks.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

majiayu000

majiayu000/specrail

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	specrail-plan-tasks
description	Use when turning an approved SpecRail product and technical spec into the numbered `tasks.md` plan. Creates stable task IDs, owners, done-when conditions, verification commands, dependencies, and handoff notes without implementing the tasks.

SpecRail Plan Tasks

Use this skill to create or update the task plan before implementation.

Steps

Read specs/GH<issue-number>/product.md and specs/GH<issue-number>/tech.md.
Read templates/<locale>/tasks.md or templates/tasks.md.
Run the implementation route gate when available:

python3 checks/route_gate.py --repo . --route implement --issue <issue-number> --state ready_to_implement --json

Write specs/GH<issue-number>/tasks.md.
Use stable task IDs such as SP<issue-number>-T1.
Collect every B-xxx invariant from product.md, then map each one to at least one implementation or verification task using Covers: B-xxx.
For every task, include owner, dependencies, done-when evidence, verify commands, and its Covers: field.
Separate implementation tasks from verification and handoff notes.

Invariant coverage

The union of task Covers: fields must include every B-xxx in product.md; a missing ID blocks completion of the task plan.
A task may cover several invariants, and an invariant may require several tasks. Keep the mapping explicit on each affected task.
Use Covers: none only for infrastructure or housekeeping that implements no product invariant, and include a concrete reason on the same task.
Boundary-checklist N/A verdicts have no B-xxx IDs and therefore need no task mapping. Never invent an ID only to make the coverage sets match.
Before finishing, compare the product ID set with the task coverage union and report both sets in the handoff when any mismatch remains.

Boundaries

Do not implement while planning tasks.
Do not remove human gates for readiness, spec approval, final review, merge, release, or security decisions.
Do not mark a task plan complete while a product invariant is absent from the task coverage union.
Keep the plan small enough for one agent or a clearly partitioned thread lane.

More from this repository

same repository

specrail-write-product-spec

majiayu000/specrail

Use when writing or updating a SpecRail product spec for a linked issue. Produces the numbered `product.md` spec from the locale-appropriate template, focusing on user-facing behavior, goals, non-goals, and acceptance criteria without implementation detail.

2026-07-1122

specrail-write-tech-spec

majiayu000/specrail

Use when writing or updating a SpecRail technical spec for a linked issue. Produces the numbered `tech.md` spec from the locale-appropriate template, translating accepted product behavior into design, affected files, risks, verification, and rollback without starting implementation.

2026-07-1122

implx

majiayu000/specrail

Use when the user says "implx", "use implx", "用 implx", or asks for the one-line SpecRail queue shortcut. Plain implx means drain the full actionable issue/PR queue in auto mode: run SpecRail preflight, create missing spec/task PR work before implementation, use threads for reviewer/merge-reviewer lanes when available, create per-issue implementation PRs, require CI/reviewThreads/pr_gate evidence, auto-merge on complete evidence, and perform closure audit. Say "implx review" / "implx 人工" for the review mode that keeps per-PR human merge authorization.

2026-07-0722

specrail-implement-queue

majiayu000/specrail

Use when implementing or draining a GitHub issue/PR queue in a SpecRail-governed repository where approved specs already exist, such as multiple numbered specs/GH packets that need one or more implementation PRs per issue. Maps issues to specs and existing PRs, supports full-queue drain requests from implx, selects single-agent or optional threads orchestration, preserves partial versus final closing semantics, and requires SpecRail verification plus PR gates before merge-readiness claims.

2026-07-0722

specrail-pr-gate

majiayu000/specrail

Use before reporting a SpecRail PR as merge-ready. Collects read-only PR evidence, runs the offline PR gate, checks linked work, current head SHA, CI, review decision, review threads, merge state, and human merge authorization without merging.

2026-07-0422

specrail-review-pr

majiayu000/specrail

Use when performing an advisory SpecRail PR review. Checks linked issue/spec evidence, route gates, verification evidence, review-thread state, human-gate preservation, and implementation quality without granting final approval or merging.

2026-07-0422

name	specrail-plan-tasks
description	Use when turning an approved SpecRail product and technical spec into the numbered `tasks.md` plan. Creates stable task IDs, owners, done-when conditions, verification commands, dependencies, and handoff notes without implementing the tasks.

SpecRail Plan Tasks

Use this skill to create or update the task plan before implementation.

Steps

Read specs/GH<issue-number>/product.md and specs/GH<issue-number>/tech.md.
Read templates/<locale>/tasks.md or templates/tasks.md.
Run the implementation route gate when available:

python3 checks/route_gate.py --repo . --route implement --issue <issue-number> --state ready_to_implement --json

Write specs/GH<issue-number>/tasks.md.
Use stable task IDs such as SP<issue-number>-T1.
Collect every B-xxx invariant from product.md, then map each one to at least one implementation or verification task using Covers: B-xxx.
For every task, include owner, dependencies, done-when evidence, verify commands, and its Covers: field.
Separate implementation tasks from verification and handoff notes.

Invariant coverage

The union of task Covers: fields must include every B-xxx in product.md; a missing ID blocks completion of the task plan.
A task may cover several invariants, and an invariant may require several tasks. Keep the mapping explicit on each affected task.
Use Covers: none only for infrastructure or housekeeping that implements no product invariant, and include a concrete reason on the same task.
Boundary-checklist N/A verdicts have no B-xxx IDs and therefore need no task mapping. Never invent an ID only to make the coverage sets match.
Before finishing, compare the product ID set with the task coverage union and report both sets in the handoff when any mismatch remains.

Boundaries

Do not implement while planning tasks.
Do not remove human gates for readiness, spec approval, final review, merge, release, or security decisions.
Do not mark a task plan complete while a product invariant is absent from the task coverage union.
Keep the plan small enough for one agent or a clearly partitioned thread lane.