Use this skill when rawsql-ts developer work is about to be shown to a human. The goal is to run the repo-local two-cycle review, triage the findings, and decide whether the result is ready.

Use It For

Checking wording drift, mirror drift, and test drift before human review.
Checking that final PR text and normal Codex work reports keep the required decision-oriented shape.
Separating blockers from follow-up work and nits.
Deciding whether the current result is ready for human review.

Workflow

Run consistency review.
Run concept boundary review for changed package behavior, generated scaffold output, docs, and review wording. Read the owning package concept, package scope, technology policy, or Concept Spec when one exists, and check whether the change violates durable boundaries such as SQL-first visibility, human-owned concept authority, or package responsibility limits.
For a final report or PR, run the pre-PR retro gate after the consistency review and confirm no open retro item blocks readiness.
Record findings about literal drift, mirror / test / policy mismatch, concept / package-policy mismatch, required fields, GitHub-safe references, per-item final form, and test wording.
Run human acceptance review.
Record findings about reviewer cognitive load, issue context, visible value, visible evidence, guarantee limits, gaps, and next human decision.
Triage each finding as blocker, follow-up, or nit.
Resolve blockers, rerun affected verification, and rerun every affected review gate, including consistency, concept-boundary, pre-PR retro, and human-acceptance review; otherwise mark the result not ready.
If the final report or PR changes a material claim after review, rerun the affected review cycle before handoff.

Output Shape

Source request or source issue
Review cycle 1 findings
Concept boundary review findings
Review cycle 2 findings
Triage summary
Review readiness
What the human should decide next

Constraints

Run both review cycles before claiming readiness for human review.
Do not claim readiness for package behavior, scaffold output, generated runtime code, docs, or PR text until the concept boundary review has checked the relevant Concept Spec or package concept when one exists.
Treat a violation of a durable package concept as a blocker unless the PR explicitly includes a human-approved concept or scope change.
Do not treat wording-only issues as blockers by default.
Do not bury blockers inside a summary paragraph.
If a blocker remains, mark the result not ready.

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

Self Review

Use this skill when rawsql-ts developer work is about to be shown to a human. The goal is to run the repo-local two-cycle review, triage the findings, and decide whether the result is ready.

Use It For

Checking wording drift, mirror drift, and test drift before human review.

Checking that final PR text and normal Codex work reports keep the required decision-oriented shape.

Separating blockers from follow-up work and nits.

Deciding whether the current result is ready for human review.

Workflow

Run consistency review.

Run concept boundary review for changed package behavior, generated scaffold output, docs, and review wording. Read the owning package concept, package scope, technology policy, or Concept Spec when one exists, and check whether the change violates durable boundaries such as SQL-first visibility, human-owned concept authority, or package responsibility limits.

For a final report or PR, run the pre-PR retro gate after the consistency review and confirm no open retro item blocks readiness.

Record findings about literal drift, mirror / test / policy mismatch, concept / package-policy mismatch, required fields, GitHub-safe references, per-item final form, and test wording.

Run human acceptance review.

Record findings about reviewer cognitive load, issue context, visible value, visible evidence, guarantee limits, gaps, and next human decision.

Triage each finding as blocker, follow-up, or nit.

Resolve blockers, rerun affected verification, and rerun every affected review gate, including consistency, concept-boundary, pre-PR retro, and human-acceptance review; otherwise mark the result not ready.

If the final report or PR changes a material claim after review, rerun the affected review cycle before handoff.

Output Shape

Source request or source issue

Review cycle 1 findings

Concept boundary review findings

Review cycle 2 findings

Triage summary

Review readiness

What the human should decide next

Constraints

Run both review cycles before claiming readiness for human review.

Do not claim readiness for package behavior, scaffold output, generated runtime code, docs, or PR text until the concept boundary review has checked the relevant Concept Spec or package concept when one exists.

Treat a violation of a durable package concept as a blocker unless the PR explicitly includes a human-approved concept or scope change.

Do not treat wording-only issues as blockers by default.

Do not bury blockers inside a summary paragraph.

If a blocker remains, mark the result not ready.