Rs Vibe Algorithm Workflow

Then collect answers from three channels in order:

1. LLM internal method summary
2. Web evidence collection
3. GitHub implementation collection

All stage-A content must be merged into one file only: METHOD_DISCOVERY.md.

Default hard thresholds (generic):

• N (primary method categories) >= 5
• M (representative methods per category) >= 2

Exception rule:

• Threshold reduction is allowed only with explicit user approval.
• Any exception must be recorded in METHOD_DISCOVERY.md and DECISIONS_TO_CONFIRM.md with reason and risk impact.

Hard requirements:

1. Start from user purpose and constraints, not from preselected algorithm.
2. Use three sources in sequence: LLM -> Web -> GitHub.
3. Enforce thresholds N and M before proposal drafting.
4. For each category, record: core idea, required data, strengths, risks, compute/deploy cost, and maturity.
5. No proposal or plan is allowed before METHOD_DISCOVERY.md is complete.

When to Use

Use when one or more of these are true:

• Starting a new remote sensing algorithm project from zero.
• Adding a new index, retrieval formula, or sensor mapping.
• Refactoring for chunked processing, memory limits, or platform constraints.
• Preparing a merge-ready artifact with validation evidence.
• Need a repeatable "research -> confirm -> refine -> implement -> feedback -> refine" process.

Do not use when:

• Task is pure prose editing with no algorithm or engineering decision.
• Task is unrelated to remote sensing or geospatial raster workflows.

Mandatory Skill-First Rule

Before writing algorithm code, invoke relevant external skills to improve context quality.

Recommended order:

1. geospatial-data-pipeline for data and raster architecture.
2. mapbox-geospatial-operations for geospatial operation choices and CRS logic.
3. python-testing-patterns for test strategy and acceptance criteria.
4. python-performance-optimization for profiling and resource strategy.

If task scope is unclear, do not code first. Run discovery first and output METHOD_DISCOVERY.md.

Progressive Output Protocol (Mandatory)

Do not dump all artifacts in one shot.

Required incremental behavior:

1. At checkpoints 1-4, output only METHOD_DISCOVERY.md.
2. At checkpoints 5-8, output only proposal and confirmation artifacts.
3. At checkpoints 9-10, output only plan.md and plan revisions.
4. At checkpoints 11-12, output only implementation and execute decision.
5. At checkpoints 13-15, output only feedback, improvements, and re-run results.

Do not pre-generate later-stage files before the user confirms the current gate.

Mandatory Single-File Discovery Contract

Before plan writing, the method discovery must be complete in METHOD_DISCOVERY.md.

Required METHOD_DISCOVERY.md fields:

• Purpose and success criteria.
• Reverse-question list and user answers.
• Channel 1 (LLM) method categories and representative methods.
• Channel 2 (Web) evidence links and extracted method updates.
• Channel 3 (GitHub) repositories/snippets, reuse boundary, and license risk.
• Unified comparison table across all channels.
• N/M threshold check and gap fixes.
• Selected baseline direction with reasons and deferred options.

Do not proceed to plan.md until this file is complete.

Constraint Mode Selection (Mandatory)

At task start, classify execution mode and write it into METHOD_DISCOVERY.md and plan.md.

Mode 1: Constrained mode (e.g., starborne deployment)

• Follow platform constraints, memory budget, entrypoint contract, and no-interaction rules.
• Prioritize lightweight, explainable, and deterministic methods.

Mode 2: General mode (no strict platform constraints)

• Ask more scoping questions before planning.
• Explore broader method candidates and stronger models.
• Keep deployment assumptions explicit instead of implicit.

Mandatory User Confirmation Gate

Use multi-gate confirmation, not one-time confirmation.

Minimum confirmation package:

1. METHOD_DISCOVERY.md
2. Baseline solution summary (before full plan)
3. External skills invocation log (what was called and what was adopted)
4. Open decisions list requiring user confirmation
5. Constraint mode declaration and its impact

Mandatory gates:

• Gate A (checkpoint 6): baseline solution confirmation
• Gate B (checkpoint 8): refined solution confirmation
• Gate C (checkpoint 10): full plan confirmation
• Gate D (checkpoint 12): execute-now or review-first decision

Do not start implementation until gate C is passed.

Inputs To Collect First

• Target mission objective and output product definition.
• Sensor metadata: bands, units, scale factors, nodata semantics.
• Runtime constraints: memory, CPU/GPU, latency, batch size.
• Acceptance criteria: numeric thresholds and test scenes.

General Remote Sensing Scope Contract

Default scope for this universal skill:

• Data types: GeoTIFF, COG, NetCDF, HDF, ENVI, SHP, GeoJSON, CSV.
• Task types: preprocessing, index calculation, inversion, classification, change detection, evaluation, packaging.
• Output requirement: preserve geospatial metadata and nodata semantics.

Out-of-scope by default:

• Pure frontend or non-remote-sensing business logic.
• Coding tasks with no geospatial data contract.

15-Checkpoint Collaborative Loop (Mandatory)

This is the default operating loop for each feature or algorithm task.

Phase A: Purpose and Discovery (Checkpoints 1-4)

1. Capture user objective and success criteria.
2. Ask reverse question to expand method space under current constraints.
3. Research methods using three sources in order:
   • LLM internal knowledge
   • Web method landscape
   • GitHub code/method references
4. Consolidate into one file with threshold check and selected baseline direction.

Output scope in this phase:

• METHOD_DISCOVERY.md

Phase B: Proposal and Double Confirmation (Checkpoints 5-8)

5. Write a baseline solution proposal.
6. Request user confirmation #1; stop until confirmed.
7. Refine the proposal using external skills and latest constraints.
8. Request user confirmation #2; stop until confirmed.

Output scope in this phase:

• Proposal updates and decision checklist only.
• Do not output full implementation plan yet.

Phase C: Full Plan and Implementation (Checkpoints 9-12)

9. Expand into full plan (files, patch order, tests, rollback, risks).
10. Request final plan confirmation; revise until approved.
11. Implement strictly by approved plan.
12. Ask execute gate decision:
    • Execute now
    • Review code first

Output scope in this phase:

• plan.md and its revisions.
• Code changes only after checkpoint 10 passes.

Phase D: Feedback, Improvement, and Closure (Checkpoints 13-15)

13. Capture execution feedback and metrics.
14. Improve plan and code based on feedback.
15. Re-execute and close only when user confirms no remaining blockers.

Output scope in this phase:

• validation.md plus concise delta updates.

Do not claim completion before checkpoint 15.

Deliverable Files Per Loop

• METHOD_DISCOVERY.md: purpose-driven three-channel method discovery and final summary.
• plan.md: full plan after confirmations.
• DECISIONS_TO_CONFIRM.md: gate-by-gate confirmations.
• validation.md: execution feedback, fixes, and re-run outcomes.

Quality Gates

All gates must pass before claiming completion:

• Correctness: expected numeric behavior on core and edge cases.
• Robustness: nodata, nan, and invalid denominator handled explicitly.
• Performance: memory use stays within stated budget under chunk mode.
• Reproducibility: commands and config can reproduce outputs.

Additional workflow gates:

• METHOD_DISCOVERY.md exists and is complete.
• N and M thresholds are satisfied or explicitly waived with approved rationale.
• Three-channel evidence exists inside METHOD_DISCOVERY.md with links and reuse notes.
• plan.md includes files, snippets, tradeoffs, and test plan.
• Gates A/B/C/D are explicitly recorded.
• GitHub research evidence exists with algorithm and code reference comparison.
• Unified method comparison table exists and is cited.
• Progressive output protocol was followed (no one-shot full dump).

Engineering gates:

• Input/output contract includes CRS, transform, nodata, dtype, resolution.
• Raster processing uses chunk strategy by default.
• Validation artifacts are recorded in validation.md.

Preferred Companion Skills

Invoke these when relevant:

• geospatial-data-pipeline
• mapbox-geospatial-operations
• python-testing-patterns
• python-performance-optimization
• multi-search-engine
• openclaw-tavily-search
• superpowers/skills/test-driven-development
• superpowers/skills/verification-before-completion

Execution Notes

• Prefer short loop cycles and narrow change scopes.
• Do not collapse research and implementation into one step.
• Keep the plan file as the source of truth for what gets coded.
• In each user-facing response, output only current-stage deliverables and next gate.

Standard Skill Package Layout

This skill package follows the Agent Skills standard (agentskills.io) and Anthropic reference pattern:

• Required root file: SKILL.md with YAML frontmatter (name, description).
• Optional support docs: workflow templates and playbooks.
• Optional reusable resources: examples/ for reference cases.

Current layout guidance:

• WORKFLOW_ZH_CN.md: Chinese team operating handbook.
• RS_WORKFLOW_TEMPLATE.md: loop template.
• PROMPT_PLAYBOOK.md: copy-ready prompts for each step.
• METHOD_DISCOVERY_TEMPLATE_ZH_CN.md: single-file discovery template.
• RS_ENGINEERING_RULES_ZH_CN.md: universal engineering constraints and pitfalls.
• MODULE_ROUTING_ZH_CN.md: task-to-module routing rules.
• SATELLITE_PROFILE_MS2612A_ZH_CN.md: starborne deployment profile.
• examples/cases-index.md: quick retrieval index for reference cases.
• examples/cases/<case-id>/: shared case code and validation artifacts.

Module Routing Requirement

Before plan finalization:

1. Choose a main module route using MODULE_ROUTING_ZH_CN.md.
2. Record chosen route and rejected alternatives in plan.md.
3. If starborne deployment is required, append constraints from SATELLITE_PROFILE_MS2612A_ZH_CN.md.

Case Reuse Protocol (Before New Coding)

Before implementing a new algorithm task:

1. Find 1-3 nearest cases in examples/cases-index.md.
2. Read their contracts, implementation, and validation notes.
3. Cite reused patterns and deviations in METHOD_DISCOVERY.md.
4. Add or update an index row when a new case is created.

Recommended case folder contents:

• README.md
• data_contract.md
• validation.md
• src/
• tests/

Use the supporting templates in RS_WORKFLOW_TEMPLATE.md and PROMPT_PLAYBOOK.md.