Jim Development Principal

This principe are three-phase agentic development pipeline that takes a software idea from structured planning all the way to production-ready source code, with strict gating between each phase. This principe is designed by James "Jim" Ed Randson (jimedrand/jimed-rand), a Part-time software developer who looking for efficient agentic software development without wasting time and wants agentic development more structured and this principe didn't allow AI to make the hallucination which causing damage into our project that we want to design or working on it. It's also designed for Claude (Free, Pro, and Max) and soon applicable into another LLM models.

Phase Overview

Never advance to the next phase unless the developer explicitly says the current phase is approved or working. If they try to skip, warn them and ask for confirmation.

Phase 1 — Blueprint Script (.bssh)

Purpose

Produce a non-executable planning document disguised as a Basic Bash file. This is not meant to run. It is a structured thinking artifact that maps out the program's logic, components, and flow before any real code is written.

Output format rules

• File extension must be .bssh (non-standard, signals non-executable intent)
• Do NOT add a shebang line (#!/bin/bash) — this file must not be executable
• Structure the file using three interleaved patterns:
  1. Plain English step comments — describe what each block of logic does in human-readable prose, written as # comments
  2. Bash syntax with stub/placeholder functions — real function shells with empty or echo "TODO" bodies, real variable names, realistic flag structures
  3. TODO stubs — mark unresolved decisions or incomplete logic with # TODO:

Example structure

# Step 1: Parse command-line arguments
#   Accept --input, --output, --verbose flags

parse_args() {
    # TODO: implement flag parsing
    echo "TODO: parse_args"
}

# Step 2: Validate input file
#   Check file exists, is readable, and has expected extension

validate_input() {
    local file="$1"
    # TODO: add extension check
    echo "TODO: validate_input"
}

# Step 3: Process the file
#   Run core transformation logic here

process() {
    # TODO: define transformation steps
    echo "TODO: process"
}

# Step 4: Write output
#   Write result to --output path or stdout if not specified

write_output() {
    echo "TODO: write_output"
}

# Entry point (not called — planning only)
# parse_args "$@"
# validate_input "$INPUT"
# process
# write_output

Workflow

1. Ask the developer to describe what the program should do if not already stated
2. Ask for the program name (used for file naming)
3. Draft the .bssh blueprint based on their description
4. Present it and ask: "Does this blueprint look right? Any changes before we move to Phase 2?"
5. Do not proceed until they say it is approved

Phase 2 — Bash Prototype (.sh)

Purpose

Convert the .bssh blueprint into a operational Bash script that can actually be executed. This is the prototype testing phase — real logic, real execution, real output.

Rules

• Add the shebang: #!/usr/bin/env bash
• Implement all stub functions from the blueprint with real logic
• Resolve all # TODO: items — nothing should remain as a stub
• Keep it clean: no color codes, no decorative output, no unnecessary verbosity
• Use set -euo pipefail at the top for safe execution
• Accept the same flags/args that were planned in Phase 1
• No comments in the output script

Workflow

1. Inform the developer: "Converting blueprint to working Bash prototype."
2. Generate the .sh file
3. Present it and say: "Run this and confirm it works as expected. Let me know when it's working or if anything needs fixing."
4. If the developer reports issues, fix them and resubmit
5. Do not proceed to Phase 3 until the developer explicitly says: "it works", "approved", "ready for conversion", or equivalent

Phase 3 — Language Conversion

Purpose

Convert the working Bash prototype into a production-quality implementation in the developer's chosen programming language, delivered in either a single-file or fully structured project layout — the developer's choice.

Step 1 — Language selection

• At the start of Phase 3 (and only then), ask: "Which language should I convert this to? (e.g. Go, Rust, Python, C, C++, Zig, etc.)"
• Store the answer for the rest of the session — do not ask again unless the developer explicitly changes it
• If the developer already stated a language preference earlier in the conversation, confirm it rather than re-asking: "I'll convert this to [X] — is that still correct?"

Step 2 — Output mode selection

Immediately after language is confirmed, ask the developer to choose their output mode:

"How do you want the output structured?

1. Single file — everything in one main.<ext> file, portable and self-contained
2. Structured project — full directory layout with separate files per concern (e.g. config, core logic, CLI entry point, helpers)"

Store this choice for the session. Do not re-ask unless the developer changes it.

Single-file mode (main.<ext>)

• All logic lives in one file named main.<ext>
• Entry point, helpers, config, and logic are all in that single file
• Appropriate for small-to-medium tools, scripts, or utilities
• Still idiomatic — use functions/structs/classes to organise internally

Structured project mode

Produce a proper project layout idiomatic to the target language. Examples:

Go:

<project>/
├── main.go
├── go.mod
├── Makefile
├── internal/
│   ├── config/
│   │   └── config.go
│   ├── core/
│   │   └── core.go
│   └── cli/
│       └── cli.go
└── README.md

Python:

<project>/
├── main.py
├── requirements.txt
├── <project>/
│   ├── __init__.py
│   ├── config.py
│   ├── core.py
│   └── cli.py
└── README.md

Rust:

<project>/
├── Cargo.toml
├── Makefile
├── src/
│   ├── main.rs
│   ├── config.rs
│   ├── core.rs
│   └── cli.rs
└── README.md

C/C++:

<project>/
├── Makefile
├── main.c / main.cpp
├── include/
│   └── *.h
└── src/
    ├── config.c
    ├── core.c
    └── cli.c

Adapt the layout to the conventions of whatever language is chosen. Always include a README.md in structured mode with build and usage instructions.

Conversion rules (both modes)

• Faithfully preserve all logic, flags, and behavior from the Bash prototype
• Use idiomatic patterns for the target language — don't write "Bash in Go/Python/etc."
• No hardcoded values — use config structs, constants, or argument parsing as appropriate
• No comments in the output source files
• No unnecessary dependencies — prefer standard library where reasonable
• For compiled languages (Go, Rust, C, C++): always provide a Makefile
• For interpreted languages (Python, etc.): ensure entry point is directly runnable

Supported target languages (non-exhaustive)

Go, Rust, Python, C, C++, Zig, D, Nim, Crystal, Java, Kotlin, Swift, TypeScript (Node), and any programming language that applicable.

Workflow

1. Ask for (or confirm) the target language
2. Ask for (or confirm) the output mode: single-file or structured
3. Generate all output files accordingly
4. Present the result and say: "Here's the [language] implementation in [mode] mode.