Skip to content

Development Workflow

jos edited this page Jan 31, 2026 · 1 revision

Development Workflow

This page describes how development on the Ping project is performed using Prompt-Engineering with Roo and GPT-5.1.

Cross-links: Home · Architecture · Prompt-Engineering · Development-Workflow · API · Doxygen-Integration · Roadmap

Principles

  • Prompt-centric development: All changes originate from well-structured prompts.
  • Small, verifiable steps: Prefer incremental changes over large, multi-file rewrites.
  • Automated checks: Build, tests, and Doxygen generation are part of the standard loop.
  • Traceability: Prompts and their effects are recorded in docs/prompts and reports.

Day-to-Day Workflow

  1. Define the Change

    • Capture the desired behavior (feature, bug fix, refactor, or documentation) in natural language.
    • Identify affected modules (see Architecture for guidance).
  2. Prepare Context for Roo

    • Open the relevant files and/or paste code snippets.
    • Summarize the current behavior and constraints.
    • Formulate a prompt that clearly states:
      • What should change
      • What must remain compatible (APIs, tests, performance expectations)
  3. Run Roo + GPT-5.1

    • Use Roo to send the prompt along with context to GPT-5.1.
    • Let GPT propose code edits, new files, or refactorings.
  4. Apply and Review Changes

    • Review the generated diffs.
    • Ensure coding style, error handling, and interfaces remain consistent.
    • Update or add tests as suggested (or prompt GPT-5.1 to do so).
  5. Build, Test, and Document

    • Build the project using the provided scripts.
    • Run unit and integration tests.
    • Regenerate Doxygen documentation and inspect results under /docs.
  6. Record the Prompt

    • Store important prompts in docs/prompts for reproducibility.
    • Optionally create a short report in docs/Reports describing the change.

Branching Strategy

A lightweight Git workflow is recommended:

  • main – Stable, tested branch.
  • Feature branches – Short-lived branches per change or task, typically derived from a single prompt or small batch of related prompts.

Suggested pattern:

  1. Create a branch for each substantial task (e.g., feature/histogram-buckets).
  2. Run one or more prompt-driven development cycles on that branch.
  3. Open a pull request summarizing:
    • The prompts used (with links into docs/prompts)
    • The changes performed
    • Test and documentation status
  4. Merge into main when tests and documentation pass review.

Using Roo in this Project

  • Use Roo to:
    • Analyze existing code and architecture.
    • Propose new modules or refactors.
    • Generate implementations, tests, and documentation.
  • Always provide file paths and relevant excerpts to reduce hallucinations and ensure consistency.
  • When making repeated changes, reference earlier prompts explicitly so GPT-5.1 can maintain continuity.

Regenerating or Extending Code

When evolving the project:

  • To add a new feature:

    • Draft an architectural sketch or short spec.
    • Prompt GPT-5.1 via Roo to propose new interfaces or extend existing ones (see API).
    • Let GPT implement the changes, then refine.
  • To refactor an existing module:

    • Provide the current implementation and tests.
    • Specify the refactoring goals (e.g., reduce duplication, separate concerns, improve testability).
    • Ask GPT-5.1 to keep public interfaces stable unless explicitly allowed to change.
  • To regenerate documentation and diagrams:

    • Run Doxygen to refresh /docs and image outputs under /images.
    • Update Wiki sections if new modules or diagrams were added (see Doxygen-Integration).

By keeping all significant changes driven by prompts and recorded under docs/prompts, the project remains reproducible as a Prompt-Engineering artifact.

Clone this wiki locally