planner-spec-draft-parallel

스타13

포크1

업데이트2026년 5월 2일 07:03

Internal Auto-Harness planning skill for parallel spec and design-direction drafting. Use only inside the Planner subagent when it is updating intake.md and producing spec.md plus design-direction.md under .harness-parallel.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

redker56

redker56/auto-harness

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Planner Spec Draft Parallel

This skill governs Spec Draft Mode for the parallel Auto-Harness workflow.

At the start of this action, read these harness artifacts from the project:

.harness-parallel/intake.md
.harness-parallel/status.md
.harness-parallel/spec.md when revising an existing spec.
.harness-parallel/design-direction.md when revising an existing design direction.

Then inspect the current project implementation relevant to this action:

Read the current implementation, architecture, routes, components, services, tests, and config that constrain or inform the spec and design direction.
Use the codebase to ground feasibility, compatibility, migration sequencing, and design constraints.

Then read the same reference files used by skills/planner-spec-draft/, including its file-ownership protocol, spec template, design-direction template, and status-board template. Apply those rules to .harness-parallel/ paths.

Follow these rules:

Update .harness-parallel/intake.md first so it stays the durable decision log.
Ask for clarification before drafting when core product, architecture, stack, or constraint decisions are still unresolved.
Then write or revise .harness-parallel/spec.md and .harness-parallel/design-direction.md.
Keep workflow_mode=parallel in .harness-parallel/status.md.
Use pending_action=spec_approval_parallel when the spec is ready for user approval.
Do not read or write .harness/.
Preserve the user's locked decisions faithfully and revise existing planning artifacts in place when the user requests changes.
Keep architecture and stack decisions concrete enough to guide implementation.
Organize the product into ordered, testable sprints where each sprint is a meaningful product slice, not only scaffolding.
Keep the spec sprinted, testable, and implementation-guiding, and keep code-level details out unless they are actual architecture constraints.
Keep design direction concrete enough for Generator and Evaluator, name anti-patterns when they matter, and avoid micro-specifying components.

이 저장소의 다른 Skills

같은 저장소

evaluator-review-contract-parallel

redker56/auto-harness

Internal Auto-Harness evaluator skill for parallel sprint contract review before implementation. Use only inside the Evaluator subagent during review mode.

2026-05-0213

evaluator-write-final-parallel

redker56/auto-harness

Internal Auto-Harness evaluator skill for parallel final QA report aggregation. Use only inside the Evaluator subagent during evaluator_final_parallel.

2026-05-0213

evaluator-write-qa-parallel

redker56/auto-harness

Internal Auto-Harness evaluator skill for parallel sprint QA and QA report writing. Use only inside the Evaluator subagent during evaluator_qa_parallel.

2026-05-0213

evaluator-write-retest-parallel

redker56/auto-harness

Internal Auto-Harness evaluator skill for parallel sprint retest and retest report writing. Use only inside the Evaluator subagent during evaluator_retest_parallel.

2026-05-0213

generator-build-integrator

redker56/auto-harness

Internal Auto-Harness generator skill for worktree-merge build integration. Use only inside the parallel Generator integrator during build mode.

2026-05-0213

generator-build-worker

redker56/auto-harness

Internal Auto-Harness generator skill for one build dependency-graph node in a dedicated worktree.

2026-05-0213

name	planner-spec-draft-parallel
description	Internal Auto-Harness planning skill for parallel spec and design-direction drafting. Use only inside the Planner subagent when it is updating intake.md and producing spec.md plus design-direction.md under .harness-parallel.
user-invocable	false

Planner Spec Draft Parallel

This skill governs Spec Draft Mode for the parallel Auto-Harness workflow.

At the start of this action, read these harness artifacts from the project:

.harness-parallel/intake.md
.harness-parallel/status.md
.harness-parallel/spec.md when revising an existing spec.
.harness-parallel/design-direction.md when revising an existing design direction.

Then inspect the current project implementation relevant to this action:

Read the current implementation, architecture, routes, components, services, tests, and config that constrain or inform the spec and design direction.
Use the codebase to ground feasibility, compatibility, migration sequencing, and design constraints.

Follow these rules:

Update .harness-parallel/intake.md first so it stays the durable decision log.
Ask for clarification before drafting when core product, architecture, stack, or constraint decisions are still unresolved.
Then write or revise .harness-parallel/spec.md and .harness-parallel/design-direction.md.
Keep workflow_mode=parallel in .harness-parallel/status.md.
Use pending_action=spec_approval_parallel when the spec is ready for user approval.
Do not read or write .harness/.
Preserve the user's locked decisions faithfully and revise existing planning artifacts in place when the user requests changes.
Keep architecture and stack decisions concrete enough to guide implementation.
Organize the product into ordered, testable sprints where each sprint is a meaningful product slice, not only scaffolding.
Keep the spec sprinted, testable, and implementation-guiding, and keep code-level details out unless they are actual architecture constraints.
Keep design direction concrete enough for Generator and Evaluator, name anti-patterns when they matter, and avoid micro-specifying components.