Use when a bluetape ecosystem change is a narrow Type B feature, API extension, test improvement, or small class addition that does not need full design artifacts.
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.
Use when a bluetape ecosystem change is a narrow Type B feature, API extension, test improvement, or small class addition that does not need full design artifacts.
bluetape4k Fast Track
Parent Contract
Use bluetape-workflow first for classification, first-plan approval, Step
DoD, common gates, GitHub metadata, concurrency tests, and side-effect authority.
This skill shortens artifacts, not verification. Load the language pattern skill
for every implementation/review:
Kotlin: bluetape-kotlin-patterns
Go: bluetape-go-patterns
Rust: bluetape-rs-patterns
Python: bluetape-py-patterns
Type B Boundary
Use this lane only when the change:
fits an existing module and architecture;
has one clear approach and narrow blast radius;
adds no new dependency or subsystem;
does not require a broad public API/product decision;
can be explained by an inline scope and task list.
Escalate to bluetape-full-feature before editing when it adds/moves/removes a
module, changes architecture, introduces a dependency, spans five or more
meaningfully coupled files, or exposes a public contract needing alternatives
and compatibility review.
Mandatory Type B Checklist
Apply bluetape-workflow/references/checklist-contract.md. Complete these
items in order. An unchecked item blocks every dependent item.
B-01 — Confirm the Type B boundary
Action: Inspect the repository, worktree, user changes, requested behavior, files/modules, exclusions, and risk; reclassify before editing if any Type B boundary is false.
Evidence: Safe branch/worktree, preserved dirty state, inline scope, acceptance criteria, exclusions, and explicit Type B classification.
Failure: Stop implementation and route to the correct workflow lane.
B-02 — Inspect existing patterns
Action: Load the language pattern skill and inspect repository anchors; consult official documentation only for unfamiliar external APIs.
Evidence: Named skill and concrete source/test/config anchors that the change will follow.
Failure: Do not design or edit from recall; complete repository and reference discovery first.
B-03 — Prepare and review the lightweight design
Action: Record one approach, contract, risks, and tests inline; create a spec or plan only when useful, and independently review every written artifact with material 7-Tier lenses.
Evidence: Inline contract and ordered task list, plus artifact paths and review result when created; P0/P1 findings are zero or a concrete evidence-backed N/A.
Failure: Repair the design/review gate or reclassify before implementation.
B-04 — Implement narrowly
Action: Make the smallest pattern-aligned change inside the approved scope; simplify duplication or generated slop before verification.
Evidence: Scoped diff mapped to the accepted behavior and existing repository patterns.
Failure: Revert or split out-of-scope work; stop if the blast radius no longer fits Type B.
B-05 — Prove changed behavior
Action: Run RED/GREEN for behavior changes, diagnostics/format/lint, targeted compile/tests, and cancellation/race/resource checks when those risks are touched.
Evidence: Fresh command outputs showing the regression test fails before the fix when applicable and all required targeted checks pass afterward.
Failure: Keep this item unchecked, diagnose the failure, and do not advance to final review.
B-06 — Review the final scope and blast radius
Action: Review Tier 4/5 always, affected risk lenses, Tier 7 evidence, and README locale/KDoc/module/CI registration when affected.
Evidence: Final scoped-diff review with P0/P1 findings at zero and every conditional surface either verified or evidence-backed N/A.
Failure: Repair findings and rerun affected downstream proof before delivery.
B-07 — Capture durable learning when applicable
Action: Record a concise lesson and reindex reusable knowledge when the change produced substantial reusable guidance.
Evidence: Lesson path and indexing result, or concrete scope evidence proving N/A.
Failure: Do not use a generic “not needed”; supply the artifact or valid N/A evidence.
B-08 — Complete authorized PR delivery through live CI and review
Action: Complete CG-11 through CG-14: verify exact PR delivery authority, publish the exact head, create or update and verify the PR with linked issue metadata and final ## DoD Status, review the live diff and threads, and wait for required CI conclusions. If PR delivery is outside scope, record CG-11 through CG-18 N/A with concrete evidence.
Evidence: Authority naming repository/base/head/action, live PR metadata/body/head/review-thread evidence, required checks successful, and applicable human-inspection artifacts complete; or the common no-PR N/A evidence.
Failure: Keep the applicable common gate PENDING or FAIL; do not treat pending, stale, missing, or unexplained skipped evidence as success.
B-09 — Report merge readiness or no-delivery completion
Action: With a PR, complete CG-15 by rendering every Type B row with phase-aware counts, commands, commits, risks, exact PR/head, and CG-16 through CG-18 explicitly unchecked; stop at CG-16. Without a PR, mark the PR-specific CG-15 action N/A and pass B-09 by rendering the final no-delivery report.
Evidence: Reconciled Required checks: X/Y; N/A: N; Blocked: 0; with a PR, a user-visible exact-head merge-ready report and pending IDs; without a PR, concrete CG-11 through CG-18 N/A evidence and every other applicable row PASS.
Failure: Do not claim merge-ready or DONE; expose the unchecked row and its next repair action. Waiting at CG-16 is normal PENDING, not failure.
B-10 — Close out only after fresh merge approval
Action: With a PR, after fresh user approval of the current B-09 report, complete CG-16 through CG-18: record approval, merge and verify live state, then sync and clean the merged worktree/branch. Without a PR, record B-10 N/A from the common no-PR branch.
Evidence: With a PR, fresh approval tied to the exact head, merge result/SHA, integration-branch sync, and cleanup result; without a PR, the same concrete CG-11 through CG-18 N/A evidence used at B-09.
Failure: Waiting at CG-16 is PENDING; refusal or invalid authority is BLOCKED. CG-17 failure returns to repair; CG-18 ambiguity remains PENDING with state preserved.
Written spec/plan artifacts trigger B-03 review evidence; omitting the artifact
is allowed only when the inline scope/task list is sufficient. Implementation
review is never optional.
Verification Minimum
diagnostics/format/lint for the touched language;
regression test for new or changed behavior;
targeted module/package compile and tests;
cancellation/race/resource tests when that risk is touched;
README locale/KDoc/module/CI registration checks when affected;
git diff --check and final scoped-diff review.
Run heavyweight infrastructure checks sequentially. A flaky first failure needs
lifecycle/timing investigation before it can be classified as noise.
Stop Conditions
Stop and reclassify when scope grows beyond Type B, a second architecture
approach becomes materially plausible, the test shape cannot prove the contract,
or review finds a broad compatibility/security/data-migration risk. Otherwise
continue through review and verification until required Step DoD rows pass.
With a PR, the normal pre-merge state is B-09 PASS and CG-16 PENDING; report
DONE only after B-10 completes CG-16 through CG-18. Without a PR, report DONE
after CG-11 through CG-18 and B-10 are evidence-backed N/A and every other
applicable row passes.
