Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
robsonrung avatar

Collaborative Task Design

  • 24 installs
  • 1 repo stars
  • Updated August 4, 2026
  • robsonrung/rar-skills

Converts a PRD or spec into sequenced engineering tasks and test plans using multi-model review, DDD, clean architecture, and TDD.

About

A skill that bridges product intent and implementation by slicing a PRD into vertical, spec-traceable tasks with tests defined before code. A developer uses it to plan architecture, sequence work, and identify safe parallelization.

  • Converts a PRD into sequenced, spec-traceable engineering tasks and test plans
  • Applies DDD, clean architecture and TDD across multi-model review phases

Collaborative Task Design by the numbers

  • 24 all-time installs (skills.sh)
  • +2 installs in the week ending Jul 26, 2026 (Skillselion tracking)
  • Ranked #1,972 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/robsonrung/rar-skills --skill collaborative_task_design

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs24
repo stars1
Last updatedAugust 4, 2026
Repositoryrobsonrung/rar-skills

What it does

Converts a PRD or spec into sequenced engineering tasks and test plans using multi-model review, DDD, clean architecture, and TDD.

Files

SKILL.mdMarkdownGitHub ↗

Collaborative task design

Convert a PRD into sequenced engineering tasks using real multi-model review, spec driven development, domain driven design, clean architecture, and test driven development.

Shared scaffolding (inputs, routing and configurability, local panel runner and flags, native response helper, panel status taxonomy, completion gate) lives in ../_shared/collaborative-panel-runner.md. Read it before running any panel phase. This file keeps only what is specific to task design.

Roles

Task design uses the role names synthesis_anchor, adversarial_anchor, architecture, testing, interface, backend, and delivery. The mapping to models is editable in assets/routing.toml.

Phases

Run the configured panel phases in order: architecture_mapping, test_strategy, task_slicing, dependency_review, and convergence. Artifacts and prompts live under .codex_workflow/task_design.

Workflow

Use this skill to convert specification into executable engineering work. The output is not a PRD and not a patch. It is the bridge between product intent and implementation. Every task must trace back to a spec item and must define tests before code.

Read references/engineering_rules.md before running architecture_mapping and task_slicing; it holds the spec driven development, domain driven design, clean architecture, and test driven development rules this skill applies.

Core rule

Every phase must include the synthesis anchor and the adversarial anchor, and every role listed for that phase must produce a real response before the phase is complete (see the shared Core rule). If a specialist role is not relevant to the current plan, it still participates and states why it has no material concern.

Steps

1. Read the PRD and codebase fit artifacts. If they do not exist, create a minimal assumptions section and mark missing inputs. 2. Map the target architecture. Identify domain layer, application use cases, ports, adapters, infrastructure, presentation, data boundaries, and dependency direction. 3. Run the configured panel phases in order: architecture_mapping, test_strategy, task_slicing, dependency_review, and convergence. 4. Slice tasks into vertical slices (tracer bullets) by user visible value and architectural seam. Avoid tasks that are too broad, such as implement backend, and tasks that are too tiny, such as rename one variable, unless that variable is a blocking domain concept. 5. For each task, include goal, files likely touched, tests to write first, implementation notes, acceptance criteria, verification commands, dependencies, rollback note, and expected review focus. 6. Identify work that can be parallelized safely. Do not parallelize tasks that write the same files, migrations, shared contracts, or security sensitive paths unless there is an explicit merge plan. 7. Produce a task sequence that supports red, green, refactor execution.

Quality bar

A task is ready only when another agent can execute it without reinterpreting the product requirement. Each task must have a clear test first entry point and a bounded diff surface.

Do not implement code in this skill. Do not change files outside the workflow artifact directory unless the user explicitly asks for repository scaffolding.

Required outputs

Read references/output_contract.md before writing phase artifacts; it defines the per-phase presence audit structure each artifact must include.

Create these files under .codex_workflow/task_design unless the user asks for another path:

1. architecture_plan.md 2. tasks.md 3. test_plan.md 4. parallelization_plan.md 5. risk_register.md 6. decision_log.md 7. panel_summary.json

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.