Name: do
Author: xiaodoushabing

Prompt file imported from xiaodoushabing/request-maximiser (.windsurf/workflows/do.md). Copyright stays with the author.

/do — disciplined request workflow

Single entry point for all /do <request> invocations on this repo. Orchestrates existing rules (coding standards, security, git, test discipline) — does NOT redefine them. Where this protocol and a global rule conflict, the rule wins.

Activation

Type /do <request> from Cascade. Optional token prefixes:

Token	Effect
`!`	Force C-mode (full clarification round, even for small tasks). For important / risky work.
`quick:`	Skip spec-lock, proceed with documented assumptions. Stop only on destructive ops.
`iterate:`	Vertical-slices mode. Ship smallest viable change, verify, stop. User reviews before continuing.

Examples:

/do refactor cost parser to handle nulls
/do ! migrate the data load to use polars
/do quick: fix typo in README
/do iterate: build a new feature flag UI

Per-repo config

Read .windsurf/workflows/_project.md if present. Use it for verification commands, smoke setup, guards, and idioms. If the file is missing or a section is missing, degrade gracefully — never invent defaults that touch the env, install dependencies, modify configs, or delete files.

The 7 phases

Triage → Spec-lock → Survey → Plan → Execute → Verify → Report
 inline    STOP*      STOP*    out    edits     run+      end
                                       (note    hand-off
                                        devs)

STOP* = consumes one extra request (justified). inline = no stop.

1. Triage (always; inline)

Output exactly one line:

Triage: <Small|Medium|Large> — <mode A|B|C|iterate|quick> — <one-sentence rationale>

Buckets (any criterion matches → that bucket):

Bucket	Criteria
Small	1 file, no data schema change, no model arch change, no API contract change, < ~50 LOC delta
Medium	2-4 files, OR adds/modifies a transform or feature, OR adds new pytest, OR changes a data load
Large	> 4 files, OR data contract change, OR model arch change, OR new ML pipeline component, OR touches CML/deploy config, OR adds new external API call patterns, OR PII/secrets handling

Token override: ! → C-mode (Large/spec-lock), quick: → A-mode (Small/skip-spec-lock), iterate: → slice-mode.

2. Spec-lock (Medium/Large or `!`) — STOP

Output and halt:

SPEC LOCK
─────────
Goal: <one-sentence restatement>
Inputs: <bullets, what user supplied>
Out of scope: <bullets, what won't be touched>
Assumptions: <numbered, decision-shaping only>
Blocking questions: <numbered, ONLY if a wrong guess changes implementation>
Plan sketch: <2-5 bullets>

Reply 'go' to proceed, or correct any line.

Rules:

No cosmetic questions (naming, formatting, indentation). Pick a default.
"Blocking" means: a wrong guess forces redo of the work.
Skipped if _project.md declares Spec-lock: Status: disabled — unless ! token forces it.

3. Survey (always) — STOP only on blocker

Read 3-8 relevant code files. If Survey: Data inspection: enabled and the task touches data flow, also inspect the sample.

SURVEY
──────
Code: <files read, one-line summary each>
Data (if applicable):
  Source: <path>
  Shape: <rows × cols>
  Dtypes: <dict>
  Nulls: <columns with > 0 nulls>
  Sample: <head(3)>
Upstream/Downstream: <one line each>

If the spec is unimplementable as described (function doesn't exist, types contradict, hidden constraint blocks the approach), STOP and report. This is a justified extra request — proceeding would waste it.

4. Plan (always; output)

Numbered checklist before any edit:

PLAN
────
Edits:
  1. <file:line> — <what changes>
  2. ...
Data assertions (if applicable):
  Input: <shape, dtypes>
  Output: <shape, dtypes>
Smoke sample: <path>, <size>
Verification: <commands from _project.md, in run order>
Hand-off (if applicable): <commands user will run manually>

The Plan is the contract. No edits during Execute that aren't on the Plan, except as documented deviations.

5. Execute (always) — STOP only on destructive boundary

Edits in plan order. Mid-flight rules:

Minor deviation (path slightly off, need a tiny helper not on the plan): note it inline; final Report lists it under "Deviations". Continue.
Destructive boundary — STOP and report:
- Deleting files
- Schema / API contract change not on plan
- Mass refactor not on plan
- Anything in _project.md's "Forbid paths" or "Destructive boundaries"
- Env mutations, dependency add/remove, lockfile changes
Plan-invalidating discovery (target is dead code, contradiction with hidden constraint): STOP and report.

6. Verify (always)

Auto-run (in order, per _project.md):

Format check (e.g. black --check .)
Linter (if declared)
Type check (if declared)
Targeted pytest — only the test file/path relevant to this change. Never the full suite unless Verification: Full suite safe: yes.
Smoke run — only if Smoke: Status: enabled AND Pure transforms: auto AND task touches data flow. Execute the changed code on the declared sample; capture output dtypes/shape/head(3) for the Report.

Hand-off (NOT auto-run; produced as commands in the Report):

Training (if Smoke: Training: hand-off)
Notebook execution (if Smoke: Notebook execution: hand-off)
Full LLM eval loops (anything beyond Max LLM calls per smoke)
Anything declared hand-off in _project.md

Cost guard: Never exceed Max training iters per smoke, Max batch size per smoke, or Max LLM calls per smoke. If running auto would exceed those, treat as hand-off.

Failures: if an auto-run command fails, attempt one targeted fix only (the failure must be clearly caused by an edit on the Plan). If the fix doesn't restore green, STOP and report. Do not iterate beyond one fix attempt.

7. Report (always; end of request)

DONE
────
Mode: <A | B | C | iterate-slice-N | quick>
Changed:
  - <file> (<line ranges>) — <one-line summary>
  - ...
Plan items completed: <list>
Plan items deferred: <list with reason>
Deviations: <if any, with one-line rationale each>
Verification:
  Auto-run:
    - <cmd>: <pass | fail with short snippet>
  Hand-off:
    - <cmd> — expected: <what to look for>
Manual check (if UI/exploratory): <what to look at>
Next: <follow-up `/do` recommended? name it concretely, or 'none'>

Invariants (cannot be disabled)

Plan is always written before code is edited.
No edit without a plan item or a documented deviation.
Verification block always present (auto + hand-off); failures are reported, not swallowed.
Report is always structured.
Destructive boundaries always halt — these are a safety floor.
Cosmetic questions are never asked.

Composition with existing rules

Coding style, security, git conventions, test discipline, naming, immutability, file size — these live in global rules (Windsurf rules / Everything Claude Code rules). This workflow tells the model when they fire, not what they say. If a rule and this protocol conflict, the rule wins.

Install do and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# /do — disciplined request workflow Single entry point for all `/do <request>` invocations on this repo. Orchestrates existing rules (coding standards, security, git, test discipline) — does NOT redefine them. Where this protocol and a global rule conflict, **the rule wins**. ## Activation Type `/do <request>` from Cascade. Optional token prefixes: | Token | Effect | |---|---| | `!` | Force C-mode (full clarification round, even for small tasks). For important / risky work. | | `quick:` | Skip spec-lock, proceed with documented assumptions. Stop only on destructive ops. | | `iterate:` | Vertical-slices mode. Ship smallest viable change, verify, stop. User reviews before continuing. | Examples: - `/do refactor cost parser to handle nulls` - `/do ! migrate the data load to use polars` - `/do quick: fix typo in README` - `/do iterate: build a new feature flag UI` ## Per-repo config Read `.windsurf/workflows/_project.md` if present. Use it for verification commands, smoke setup, guards, and idioms. If the file is missing or a section is missing, **degrade gracefully** — never invent defaults that touch the env, install dependencies, modify configs, or delete files. ## The 7 phases ``` Triage → Spec-lock → Survey → Plan → Execute → Verify → Report inline STOP* STOP* out edits run+ end (note hand-off devs) ``` `STOP*` = consumes one extra request (justified). `inline` = no stop. ### 1. Triage (always; inline) Output exactly one line: ``` Triage: <Small|Medium|Large> — <mode A|B|C|iterate|quick> — <one-sentence rationale> ``` Buckets (any criterion matches → that bucket): | Bucket | Criteria | |---|---| | Small | 1 file, no data schema change, no model arch change, no API contract change, < ~50 LOC delta | | Medium | 2-4 files, OR adds/modifies a transform or feature, OR adds new pytest, OR changes a data load | | Large | > 4 files, OR data contract change, OR model arch change, OR new ML pipeline component, OR touches CML/deploy config, OR adds new external API call patterns, OR PII/secrets handling | Token override: `!` → C-mode (Large/spec-lock), `quick:` → A-mode (Small/skip-spec-lock), `iterate:` → slice-mode. ### 2. Spec-lock (Medium/Large or `!`) — STOP Output and halt: ``` SPEC LOCK ───────── Goal: <one-sentence restatement> Inputs: <bullets, what user supplied> Out of scope: <bullets, what won't be touched> Assumptions: <numbered, decision-shaping only> Blocking questions: <numbered, ONLY if a wrong guess changes implementation> Plan sketch: <2-5 bullets> Reply 'go' to proceed, or correct any line. ``` Rules: - **No cosmetic questions** (naming, formatting, indentation). Pick a default. - "Blocking" means: a wrong guess forces redo of the work. - Skipped if `_project.md` declares `Spec-lock: Status: disabled` — unless `!` token forces it. ### 3. Survey (always) — STOP only on blocker Read 3-8 relevant code files. If `Survey: Data inspection: enabled` and the task touches data flow, also inspect the sample. ``` SURVEY ────── Code: <files read, one-line summary each> Data (if applicable): Source: <path> Shape: <rows × cols> Dtypes: <dict> Nulls: <columns with > 0 nulls> Sample: <head(3)> Upstream/Downstream: <one line each> ``` If the spec is unimplementable as described (function doesn't exist, types contradict, hidden constraint blocks the approach), STOP and report. This is a justified extra request — proceeding would waste it. ### 4. Plan (always; output) Numbered checklist before any edit: ``` PLAN ──── Edits: 1. <file:line> — <what changes> 2. ... Data assertions (if applicable): Input: <shape, dtypes> Output: <shape, dtypes> Smoke sample: <path>, <size> Verification: <commands from _project.md, in run order> Hand-off (if applicable): <commands user will run manually> ``` The Plan is the contract. No edits during Execute that aren't on the Plan, except as documented deviations. ### 5. Execute (always) — STOP only on destructive boundary Edits in plan order. Mid-flight rules: - **Minor deviation** (path slightly off, need a tiny helper not on the plan): note it inline; final Report lists it under "Deviations". Continue. - **Destructive boundary** — STOP and report: - Deleting files - Schema / API contract change not on plan - Mass refactor not on plan - Anything in `_project.md`'s "Forbid paths" or "Destructive boundaries" - Env mutations, dependency add/remove, lockfile changes - **Plan-invalidating discovery** (target is dead code, contradiction with hidden constraint): STOP and report. ### 6. Verify (always) **Auto-run** (in order, per `_project.md`): 1. Format check (e.g. `black --check .`) 2. Linter (if declared) 3. Type check (if declared) 4. Targeted pytest — only the test file/path relevant to this change. Never the full suite unless `Verification: Full suite safe: yes`. 5. Smoke run — only if `Smoke: Status: enabled` AND `Pure transforms: auto` AND task touches data flow. Execute the changed code on the declared sample; capture output dtypes/shape/head(3) for the Report. **Hand-off** (NOT auto-run; produced as commands in the Report): - Training (if `Smoke: Training: hand-off`) - Notebook execution (if `Smoke: Notebook execution: hand-off`) - Full LLM eval loops (anything beyond `Max LLM calls per smoke`) - Anything declared `hand-off` in `_project.md` **Cost guard:** Never exceed `Max training iters per smoke`, `Max batch size per smoke`, or `Max LLM calls per smoke`. If running auto would exceed those, treat as hand-off. **Failures:** if an auto-run command fails, attempt one targeted fix only (the failure must be clearly caused by an edit on the Plan). If the fix doesn't restore green, STOP and report. Do not iterate beyond one fix attempt. ### 7. Report (always; end of request) ``` DONE ──── Mode: <A | B | C | iterate-slice-N | quick> Changed: - <file> (<line ranges>) — <one-line summary> - ... Plan items completed: <list> Plan items deferred: <list with reason> Deviations: <if any, with one-line rationale each> Verification: Auto-run: - <cmd>: <pass | fail with short snippet> Hand-off: - <cmd> — expected: <what to look for> Manual check (if UI/exploratory): <what to look at> Next: <follow-up `/do` recommended? name it concretely, or 'none'> ``` ## Invariants (cannot be disabled) - Plan is always written before code is edited. - No edit without a plan item or a documented deviation. - Verification block always present (auto + hand-off); failures are reported, not swallowed. - Report is always structured. - Destructive boundaries always halt — these are a safety floor. - Cosmetic questions are never asked. ## Composition with existing rules Coding style, security, git conventions, test discipline, naming, immutability, file size — these live in **global rules** (Windsurf rules / Everything Claude Code rules). This workflow tells the model **when** they fire, not **what** they say. If a rule and this protocol conflict, the rule wins.

{ "prompt": "# /do — disciplined request workflow\n\nSingle entry point for all `/do <request>` invocations on this repo. Orchestrates existing rules (coding standards, security, git, test discipline) — does NOT redefine them. Where this protocol and a global rule conflict, **the rule wins**.\n\n## Activation\n\nType `/do <request>` from Cascade. Optional token prefixes:\n\n| Token | Effect |\n|---|---|\n| `!` | Force C-mode (full clarification round, even for small tasks). For important / risky work. |\n| `quick:` | Skip spec-lock, proceed with documented assumptions. Stop only on destructive ops. |\n| `iterate:` | Vertical-slices mode. Ship smallest viable change, verify, stop. User reviews before continuing. |\n\nExamples:\n\n- `/do refactor cost parser to handle nulls`\n- `/do ! migrate the data load to use polars`\n- `/do quick: fix typo in README`\n- `/do iterate: build a new feature flag UI`\n\n## Per-repo config\n\nRead `.windsurf/workflows/_project.md` if present. Use it for verification commands, smoke setup, guards, and idioms. If the file is missing or a section is missing, **degrade gracefully** — never invent defaults that touch the env, install dependencies, modify configs, or delete files.\n\n## The 7 phases\n\n```\nTriage → Spec-lock → Survey → Plan → Execute → Verify → Report\n inline STOP* STOP* out edits run+ end\n (note hand-off\n devs)\n```\n\n`STOP*` = consumes one extra request (justified). `inline` = no stop.\n\n### 1. Triage (always; inline)\n\nOutput exactly one line:\n\n```\nTriage: <Small|Medium|Large> — <mode A|B|C|iterate|quick> — <one-sentence rationale>\n```\n\nBuckets (any criterion matches → that bucket):\n\n| Bucket | Criteria |\n|---|---|\n| Small | 1 file, no data schema change, no model arch change, no API contract change, < ~50 LOC delta |\n| Medium | 2-4 files, OR adds/modifies a transform or feature, OR adds new pytest, OR changes a data load |\n| Large | > 4 files, OR data contract change, OR model arch change, OR new ML pipeline component, OR touches CML/deploy config, OR adds new external API call patterns, OR PII/secrets handling |\n\nToken override: `!` → C-mode (Large/spec-lock), `quick:` → A-mode (Small/skip-spec-lock), `iterate:` → slice-mode.\n\n### 2. Spec-lock (Medium/Large or `!`) — STOP\n\nOutput and halt:\n\n```\nSPEC LOCK\n─────────\nGoal: <one-sentence restatement>\nInputs: <bullets, what user supplied>\nOut of scope: <bullets, what won't be touched>\nAssumptions: <numbered, decision-shaping only>\nBlocking questions: <numbered, ONLY if a wrong guess changes implementation>\nPlan sketch: <2-5 bullets>\n\nReply 'go' to proceed, or correct any line.\n```\n\nRules:\n\n- **No cosmetic questions** (naming, formatting, indentation). Pick a default.\n- \"Blocking\" means: a wrong guess forces redo of the work.\n- Skipped if `_project.md` declares `Spec-lock: Status: disabled` — unless `!` token forces it.\n\n### 3. Survey (always) — STOP only on blocker\n\nRead 3-8 relevant code files. If `Survey: Data inspection: enabled` and the task touches data flow, also inspect the sample.\n\n```\nSURVEY\n──────\nCode: <files read, one-line summary each>\nData (if applicable):\n Source: <path>\n Shape: <rows × cols>\n Dtypes: <dict>\n Nulls: <columns with > 0 nulls>\n Sample: <head(3)>\nUpstream/Downstream: <one line each>\n```\n\nIf the spec is unimplementable as described (function doesn't exist, types contradict, hidden constraint blocks the approach), STOP and report. This is a justified extra request — proceeding would waste it.\n\n### 4. Plan (always; output)\n\nNumbered checklist before any edit:\n\n```\nPLAN\n────\nEdits:\n 1. <file:line> — <what changes>\n 2. ...\nData assertions (if applicable):\n Input: <shape, dtypes>\n Output: <shape, dtypes>\nSmoke sample: <path>, <size>\nVerification: <commands from _project.md, in run order>\nHand-off (if applicable): <commands user will run manually>\n```\n\nThe Plan is the contract. No edits during Execute that aren't on the Plan, except as documented deviations.\n\n### 5. Execute (always) — STOP only on destructive boundary\n\nEdits in plan order. Mid-flight rules:\n\n- **Minor deviation** (path slightly off, need a tiny helper not on the plan): note it inline; final Report lists it under \"Deviations\". Continue.\n- **Destructive boundary** — STOP and report:\n - Deleting files\n - Schema / API contract change not on plan\n - Mass refactor not on plan\n - Anything in `_project.md`'s \"Forbid paths\" or \"Destructive boundaries\"\n - Env mutations, dependency add/remove, lockfile changes\n- **Plan-invalidating discovery** (target is dead code, contradiction with hidden constraint): STOP and report.\n\n### 6. Verify (always)\n\n**Auto-run** (in order, per `_project.md`):\n\n1. Format check (e.g. `black --check .`)\n2. Linter (if declared)\n3. Type check (if declared)\n4. Targeted pytest — only the test file/path relevant to this change. Never the full suite unless `Verification: Full suite safe: yes`.\n5. Smoke run — only if `Smoke: Status: enabled` AND `Pure transforms: auto` AND task touches data flow. Execute the changed code on the declared sample; capture output dtypes/shape/head(3) for the Report.\n\n**Hand-off** (NOT auto-run; produced as commands in the Report):\n\n- Training (if `Smoke: Training: hand-off`)\n- Notebook execution (if `Smoke: Notebook execution: hand-off`)\n- Full LLM eval loops (anything beyond `Max LLM calls per smoke`)\n- Anything declared `hand-off` in `_project.md`\n\n**Cost guard:** Never exceed `Max training iters per smoke`, `Max batch size per smoke`, or `Max LLM calls per smoke`. If running auto would exceed those, treat as hand-off.\n\n**Failures:** if an auto-run command fails, attempt one targeted fix only (the failure must be clearly caused by an edit on the Plan). If the fix doesn't restore green, STOP and report. Do not iterate beyond one fix attempt.\n\n### 7. Report (always; end of request)\n\n```\nDONE\n────\nMode: <A | B | C | iterate-slice-N | quick>\nChanged:\n - <file> (<line ranges>) — <one-line summary>\n - ...\nPlan items completed: <list>\nPlan items deferred: <list with reason>\nDeviations: <if any, with one-line rationale each>\nVerification:\n Auto-run:\n - <cmd>: <pass | fail with short snippet>\n Hand-off:\n - <cmd> — expected: <what to look for>\nManual check (if UI/exploratory): <what to look at>\nNext: <follow-up `/do` recommended? name it concretely, or 'none'>\n```\n\n## Invariants (cannot be disabled)\n\n- Plan is always written before code is edited.\n- No edit without a plan item or a documented deviation.\n- Verification block always present (auto + hand-off); failures are reported, not swallowed.\n- Report is always structured.\n- Destructive boundaries always halt — these are a safety floor.\n- Cosmetic questions are never asked.\n\n## Composition with existing rules\n\nCoding style, security, git conventions, test discipline, naming, immutability, file size — these live in **global rules** (Windsurf rules / Everything Claude Code rules). This workflow tells the model **when** they fire, not **what** they say. If a rule and this protocol conflict, the rule wins.", "variables": [], "notes": "Single entry point for all requests. Triages, locks the spec, surveys, plans, executes, verifies, and reports — using the project's _project.md for verification commands and guards.", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/xiaodoushabing/request-maximiser", "path": ".windsurf/workflows/do.md", "ref": "7b5a075854aa127957c3a475d790c90177db87df", "url": "https://github.com/xiaodoushabing/request-maximiser/blob/7b5a075854aa127957c3a475d790c90177db87df/.windsurf/workflows/do.md", "key": "xiaodoushabing/request-maximiser/.windsurf/workflows/do.md" } } }

do

About

/do — disciplined request workflow

Activation

Per-repo config

The 7 phases

1. Triage (always; inline)

2. Spec-lock (Medium/Large or `!`) — STOP

3. Survey (always) — STOP only on blocker

4. Plan (always; output)

5. Execute (always) — STOP only on destructive boundary

6. Verify (always)

7. Report (always; end of request)

Invariants (cannot be disabled)

Composition with existing rules

Install do and it becomes one more candidate the router can pick - when it fits.

Use it

Manifest

Reviews

About

/do — disciplined request workflow

Activation

Per-repo config

The 7 phases

1. Triage (always; inline)

2. Spec-lock (Medium/Large or !) — STOP

3. Survey (always) — STOP only on blocker

4. Plan (always; output)

5. Execute (always) — STOP only on destructive boundary

6. Verify (always)

7. Report (always; end of request)

Invariants (cannot be disabled)

Composition with existing rules

Install do and it becomes one more candidate the router can pick - when it fits.

Use it

Manifest

Reviews

2. Spec-lock (Medium/Large or `!`) — STOP