Use this skill when a rawsql-ts developer task needs a decision-complete plan that a reviewer can later compare against the final report without reconstructing the issue or next human decision from memory.

Use It For

Turning an issue into explicit acceptance items.
Writing a verification method for each item.
Recording assumptions and working rules before implementation starts.
Making the source issue and why it matters visible in the plan itself.
Creating a plan that the final PR report can mirror without re-deriving context.
Making the expected human decision points visible before implementation starts.

Workflow

State the developer-only scope.
Identify the source issue and explain why it matters.
Extract the smallest useful set of acceptance items or decision points.
Attach a verification method to each item.
Note assumptions, working rules, and what the human will need to decide after execution.
If the task is broad, hand the plan to the planning subagent for decomposition.

Output Shape

Source issue
Why it matters
Acceptance items
Decision points
Verification methods
Assumptions
Working rules

Constraints

Keep the plan focused on rawsql-ts developer work.
Do not add customer-oriented guidance.
Do not omit the source issue or why it matters.
Do not leave verification methods implicit.
For ConceptSpec-related work, do not treat unresolved concept questions as failure by default.
Upstream ConceptSpec tasks may finish with classified unresolved items when the intended business process is not blocked.
If work requires undefined business meaning, missing process definition, or unapproved scope expansion, route it to ConceptSpec or process work before implementation acceptance items are finalized.

Más de este repositorio

mismo repositorio

rawsql-task-orchestrator

mk3008/rawsql-ts

Assess and dispatch rawsql-ts developer tasks by tracing repository impact, concept and package boundaries, verification cost, difficulty, risk, model and reasoning effort, and Codex worktree requirements. Use when a new rawsql-ts issue, bug, feature, refactor, investigation, CI failure, review request, migration, or documentation change must be analyzed before action or handed to a new Codex task.

2026-07-1230

developer-attainment-reporting

mk3008/rawsql-ts

Report per-item attainment for completed rawsql-ts developer work.

2026-07-1030

package-spec-review

mk3008/rawsql-ts

Review tracked rawsql-ts package-level Scope, Test Policy, Authority Model, Technology Policy, review-plan, and generated review views before package implementation or documentation changes. Use only when those package-owned artifacts exist in the checked-out base.

2026-07-1030

developer-pr-readiness

mk3008/rawsql-ts

Prepare rawsql-ts pull requests with the repository PR template and local readiness gate so required merge, CLI migration, and scaffold proof sections are not missed.

2026-07-1030

developer-pre-pr-retro-gate

mk3008/rawsql-ts

Check tmp/RETRO.md before PR or human review so unresolved retro items do not slip through rawsql-ts developer workflow.

2026-07-1030

developer-retro-capture

mk3008/rawsql-ts

Capture meaningful recognition mismatches, false completion claims, and verification misses into tmp/RETRO.md for rawsql-ts developer work.

2026-07-1030

name	developer-acceptance-planning
description	Draft acceptance items and verification methods for rawsql-ts developer work.

Acceptance Planning

Use It For

Turning an issue into explicit acceptance items.
Writing a verification method for each item.
Recording assumptions and working rules before implementation starts.
Making the source issue and why it matters visible in the plan itself.
Creating a plan that the final PR report can mirror without re-deriving context.
Making the expected human decision points visible before implementation starts.

Workflow

State the developer-only scope.
Identify the source issue and explain why it matters.
Extract the smallest useful set of acceptance items or decision points.
Attach a verification method to each item.
Note assumptions, working rules, and what the human will need to decide after execution.
If the task is broad, hand the plan to the planning subagent for decomposition.

Output Shape

Source issue
Why it matters
Acceptance items
Decision points
Verification methods
Assumptions
Working rules

Constraints

Keep the plan focused on rawsql-ts developer work.
Do not add customer-oriented guidance.
Do not omit the source issue or why it matters.
Do not leave verification methods implicit.
For ConceptSpec-related work, do not treat unresolved concept questions as failure by default.
Upstream ConceptSpec tasks may finish with classified unresolved items when the intended business process is not blocked.
If work requires undefined business meaning, missing process definition, or unapproved scope expansion, route it to ConceptSpec or process work before implementation acceptance items are finalized.