Documentation
README
bcc-clean-cut
Job: ship the shortest correct code that satisfies the active PLAN.md, then verify and progress-only 约减 the checklist.
Deep source: ponytail SKILL.md (coding ladder only — not review/audit family).
Does not: interview the user for domain design, write ADRs, adversarial-review the plan, or refine PLAN design while coding — do that in bcc-plan-spar first.
Workflow preflight (required — before any code edit)
Do not write product code until this check passes.
If uncertain → ask the user (one question + recommended default). Never invent APPROVE.
1. Snapshot disk + session
| Check | Read |
|---|---|
| Global map | plans.md / progress.md (if present) — which hardpoint is current? |
| Coding brief | PLAN.md (or plan_path from session) — exists? draft? locked? checklist open items? |
| Domain | CONTEXT.md / ADRs if referenced by PLAN |
.bcc/session.json |
Cross-session APPROVE — see SESSION.md |
| Chat this session | APPROVE implement / “开写” / explicit skip-gate |
human_APPROVE=yes if either:
- Chat this session clearly APPROVE implement / skip-gate, or
- Session file has
approved_for=clean-cutandplan_sha256equals SHA-256 of current PLAN file bytes.
If session says approved but hash mismatch → PLAN changed after approve → human_APPROVE=no → ask re-APPROVE or plan-spar (do not code).
Echo:
preflight · PLAN=… · human_APPROVE=yes|no|unclear · session=… · hash=match|mismatch|none · throughline=yes|no · recommend=code|plan-spar|throughline|ask-user
2. Is bcc-clean-cut appropriate now?
| Situation | Suitable? | Do this |
|---|---|---|
No PLAN.md |
No | Stop. Send to bcc-plan-spar. Ask if they meant to plan first. |
PLAN.md is _Draft — not locked_ |
No | Stop. Finish bcc-plan-spar lock (or ask user to force-lock). |
| Checklist all complete / slice already shipped | Usually no | Ask: “PLAN is done. New slice (plan-spar), throughline next, or re-open checklist?” |
| PLAN topic ≠ user’s request / ≠ throughline current hardpoint | Ask | “PLAN is for X; you asked to implement Y. Switch (plan-spar), or implement X?” |
Human APPROVE implement this session or valid .bcc/session.json approve (hash match) |
Yes | Proceed to ladder |
| User said “implement / clean-cut” but no chat APPROVE and no valid session approve | Ask | “PLAN is locked but not human-approved for coding. APPROVE implement, amend, or back to plan-spar?” Default recommend: confirm APPROVE once. |
| User only asked “where are we?” | No | bcc-throughline |
| User still wants alignment / more grill | No | bcc-plan-spar |
| Multi-step endeavor, no throughline, large remaining work | Warn + ask | Optional: “No plans.md cockpit — continue one-off cut, or create throughline first?” Coding may proceed if PLAN is solid and user wants speed. |
3. Coding readiness checklist (all should be true, or user override)
PLAN.mdexists and is not an unlabeled draft.- Goal + checklist + verification sections are present enough to execute.
- Human has approved implement (chat or valid session file) or explicit override (“skip gate / just code this PLAN”).
- You know which slice this PLAN is for (title/goal matches the work / session.active_slice).
If any item fails and user did not override → do not code; ask or route.
4. After preflight OK
Only then: optionally set session status=coding → read code flow → ladder → verify → 约减 PLAN → throughline writeback → on pass set session status=done, approved_for=none (consume one-shot approve per SESSION.md).
Preconditions (short)
- Preflight passed (above).
- Trace the real code flow before editing.
- PLAN is the contract — no invented scope.
PLAN freeze (execute, don't refine)
After human APPROVE, PLAN.md is a frozen contract for design content.
| Allowed during cut | Forbidden during cut |
|---|---|
| Implement within Goal / Approach / checklist / Verification | Rewrite Goal, Approach, Key decisions, Out of scope, Verification design |
Check off [ ] → [x] only after implement + verify |
Add new checklist items, “improve” wording of the brief, expand scope |
| 约减 progress only: remove completed checklist rows / finished bulk that is already done | Mid-cut plan polish, second-guess architecture into the file |
Note learnings in progress.md / findings.md |
Quietly change the brief so APPROVE no longer matches reality |
Conflict / plan wrong / can't meet Verification: stop coding → say the conflict in one short line → bcc-plan-spar (or user amends PLAN) → re-APPROVE. Do not “fix the plan while shipping.”
No extra user ceremony: same gates as today; agent just won't rewrite the brief while coding.
Intensity (default full)
| Level | Behavior |
|---|---|
| lite | Build what PLAN asks; name a lazier alternative in one line. |
| full | Ladder enforced. Shortest correct diff. Default. |
| ultra | YAGNI extremist on the code. May mention a speculative checklist item in chat; still execute PLAN as approved unless user sends you back to plan-spar. Never edit design sections to “improve” the plan. |
Echo: bcc-clean-cut · full · PLAN.md
Off only if user says stop bcc-clean-cut / normal mode for coding style (suite may still own process).
Before the ladder
- Read every file the change touches; end-to-end flow.
- Bug fix = root cause, not symptom — one fix where all callers route.
- Ladder shortens the solution, never the reading.
The ladder (stop at first rung that holds)
- Does this need to exist at all? (YAGNI)
- Already in this codebase? Reuse.
- Stdlib?
- Native platform feature?
- Already-installed dependency? Never add a dep for a few lines.
- One line?
- Only then: minimum code that works.
Rules
- No unrequested abstractions (interface-for-one, factory-for-one, config-for-never).
- No scaffolding “for later”.
- Deletion over addition when safe. Fewest files. Shortest correct diff.
- Equal-size options → pick edge-correct one.
- Deliberate ceilings:
# bcc: <ceiling>; upgrade when <condition>.
Never simplify away
Trust-boundary validation, data-loss handling, security, a11y basics, anything PLAN/user explicitly requires. Never lazy about understanding.
Verify + PLAN 约减 (progress only)
- Run checks from
PLAN.mdVerification + checklist. - Mark items complete only after implement + verify.
- Non-trivial logic: one minimal runnable check if none exist (no test framework sprawl).
- 约减
PLAN.md(progress only): check off done items; drop completed bulk; keep open checklist + unchanged Goal/Approach/decisions/Verification design. Narrative history → throughlineprogress.md, not a redesign of the brief.
Output
Code first. At most a few short lines: skipped / add when.
Pattern: done → skipped: X, add when Y unless user asked for a full report.
Close
Pass (required order):
- Trim/约减
PLAN.md. - Mandatory throughline writeback per WRITEBACK.md — update
progress.md(session block + tests),plans.mdhardpoint status,findings.mdonly if global learning. - Consume session approve (
approved_for=none,status=done). - Say the slice is done.
- Next (strict):
- If any throughline hardpoint still open → only mention next hardpoint (or stop). No wrap-up talk.
- If Gate A (every hardpoint
complete) and Gate B (not yet offered/closed) per bcc-throughline Endeavor wrap-up → one wrap-up offer (write### Wrap-up offeredfirst, then ask global verify / what kind / skip). - If already offered/closed → do not re-ask.
Incomplete without writeback. If writeback fails, fix files before claiming success.
Fail: log error in progress.md; 3-strike then escalate; after 2 verify fails → stop cutting, require bcc-plan-spar to revise PLAN.
Invocation
| How | Example |
|---|---|
| After bcc-plan-spar | User APPROVE → agent loads bcc-clean-cut |
| Skill | /bcc-clean-cut · /bcc-clean-cut ultra |
| Chat | "bcc-clean-cut", "按 PLAN 最小实现", "implement the brief" |
Hard rules
- Preflight first — PLAN + human APPROVE (chat or valid session).
- PLAN is the single coding contract for the active slice; across hardpoints plan-spar rewrites that same file — during cut, design content is frozen (progress 约减 only).
- Read fully, then climb the ladder.
- No plan-review theater — that is bcc-plan-spar.
- Global progress only via throughline trio — writeback mandatory on success.
- If unsure → ask the user; never invent APPROVE.
- Infer fit from docs/context; suggest next skill — no formal state machine required.
- Execute, don't refine — design change → stop → plan-spar + re-APPROVE.
What NOT to do
- Don't skip preflight or skip writeback.
- Don't treat auto-review APPROVED as human APPROVE.
- Don't put global phase history into PLAN.md.
- Don't re-open unbounded product design mid-cut.
- Don't rewrite Goal / Approach / decisions / Verification design while coding.
- Don't “improve” PLAN mid-cut to match what you feel like implementing.