How does Go Routine work?

Mon, 06 Apr 2026 06:47:50 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

What is a Go Routine?

Go Routine is a lightweight thread managed by the Go Scheduler. Any thread created by the Go Runtime is handled by the Go Scheduler.

Go Scheduler is a part of the Go Runtime that manages the execution of Go Routines. It is responsible for scheduling the execution of Go Routines and managing the state of the Go Routines.

In Other Programming Languages, each thread has a stack size of 256 KB to 1 MB. But in Go, each thread has a stack size of 2 KB to 4 kb.

How Concurrency Different From Parallelism?

Concurrency

It is mostly software based.
Is the ability of a program to perform multiple tasks at the same time.
It Focuses on reducing the execution time of a program.
It is exececuting tasks in a most effient order the order is not specified it depends on the scheduler.

Parallelism

It is mostly hardware based.
It is the ability of a processor to execute multiple instructions at the same time.
It truly executes tasks in parallel.

How to create a Go Routine?

Every Go Program executes in a main go routine.

Other go routines are created using go keyword.

package main

import "fmt"

func main() {
    go say("hello")
    say("world")
}
func say(word string) {
    for i := 0; i < 5; i++ {
        time.Sleep(100 * time.Millisecond)
        fmt.Println(word)
    }
}

We can see that the output is not in order.

This is because the Go Scheduler is responsible for scheduling the execution of Go Routines and managing the state of the Go Routines.

We can't predict the output of the go routine.

Output:

gk@jarvis:~/exp/code/rd/go-exmaple$ go run main.go 
hello
world
world
hello
hello
world
world
hello
hello
world
gk@jarvis:~/exp/code/rd/go-exmaple$ go run main.go 
world
hello
hello
world
world
hello
hello
world
world

Conclusion

In Next Article, we will see how to work with unordered events.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Understanding the OpenClaw PIV Skill: Plan, Implement, Validate Orchestrator for Smarter Development

Fri, 20 Mar 2026 14:30:46 +0000

Understanding the OpenClaw PIV Skill: Plan, Implement, Validate Orchestrator for Smarter Development

Open‑source projects thrive when contributors have a clear, repeatable process for turning ideas into working code. The OpenClaw PIV skill (found in the repository openclaw/skills at skills/skills/smokealot420/ftw/SKILL.md) provides exactly that: a lightweight yet powerful orchestrator that guides teams through a Plan‑Implement‑Validate (PIV) loop. By combining a structured PRD‑first approach with automated sub‑agent spawning, the skill helps developers stay focused, reduces context‑switching overhead, and encourages early validation—core tenets of the FTW (First Try Works) philosophy promoted by SmokeAlot420.

What the Skill Does at a Glance

At its core, the PIV skill is a Bash‑style orchestrator that:

Accepts either a direct path to a PRD (.md) file or a project directory as its first argument.
Parses the supplied arguments to determine the mode of operation—either execution (when a PRD is present) or discovery (when no PRD exists).
Sets up the required directory layout (PRDs/, PRPs/templates/, PRPs/planning/, and a WORKFLOW.md file) if they are missing.
Iterates through user‑specified phases (default 1‑4), performing for each phase:
Checking for an existing PRP (Project‑Ready Plan); if none exists, performing codebase analysis and PRP generation in‑process.
Spawning three specialized sub‑agents—Executor, Validator, and (optionally) Debugger—to carry out the work, validate results, and iterate on fixes.
Committing changes with a semantic message that credits FTW.
Updating WORKFLOW.md to reflect phase completion.

Because each sub‑agent receives a fresh context (the orchestrator keeps only ~15% of the total context budget), the skill avoids contaminating later steps with stale information, which is a common pitfall in monolithic scripts.

Deep Dive: Argument Parsing and Mode Detection

The skill begins by examining $ARGUMENTS[0]. If that argument ends with .md, it is treated as a direct path to a PRD file. The orchestrator then derives the project root by moving up two directories (dirname(dirname(PRD_PATH)))—the assumption being that PRDs live in PROJECT_PATH/PRDs/. The remaining arguments become START_PHASE and END_PHASE, with sensible defaults (1 and auto‑detected from the PRD, respectively).

If the first argument does not end with .md, the skill assumes the user supplied a project path (or the current working directory if omitted). In this case:

PROJECT_PATH is set to the supplied directory (or .).
The orchestrator looks for a PRD file inside PROJECT_PATH/PRDs/.
If a PRD is discovered, the mode becomes execution; otherwise it falls back to discovery mode.

This dual‑mode design lets the same entry point be used both for kicking off a brand‑new project (discovery) and for continuing work on an existing PRD‑driven effort (execution).

Discovery Mode: From Idea to PRD

When no PRD is found, the skill invokes the discovery workflow defined in {baseDir}/references/piv-discovery.md. The orchestrator engages the user in a friendly, conversational interview—tailored for “vibe coders” rather than senior architects—asking about:

Project goals and desired outcomes.
Preferred technology stack (if unknown, the orchestrator will research and propose a stack).
High‑level feature breakdown that can be translated into phases.

After each question, the orchestrator echoes back a summary and asks for confirmation (“Here’s what I’d suggest — does this sound right?”). Only after the user validates the proposed direction does the orchestrator proceed to create the necessary directories, copy the PRD template (create-prd.md), and write a PRD file named PRD-{project-name}.md into PROJECT_PATH/PRDs/. Once the PRD exists, the skill automatically switches to execution mode, using the newly generated PRD to determine phase boundaries.

Phase Workflow: The Heart of PIV

For each numeric phase from START_PHASE through END_PHASE, the orchestrator follows a seven‑step routine:

Check/Generate PRP – Looks for an existing PRP matching the phase (patterns like phase.*N, pN, or p-N). If none is found, it performs:
Codebase analysis (guided by codebase-analysis.md) and stores the result in PRPs/planning/{PRD_NAME}-phase-{N}-analysis.md.
PRP generation (using generate-prp.md and the base template prp_base.md) yielding PRPs/PRP-{PRD_NAME}-phase-{N}.md.
Spawn Executor – A fresh sub‑agent receives the PRP path and project root, then follows the executor playbook (piv-executor.md + execute-prp.md) to load the PRP, plan thoroughly, execute, validate, and verify. The executor returns an Execution Summary containing status, touched files, test results, and any issues.
Spawn Validator – Another independent sub‑agent reads the validator guide (piv-validator.md) and checks the executor’s summary against the PRP requirements, producing a Verification Report with a grade, checklist, and identified gaps.
Debug Loop (max 3 iterations) – If the validator reports gaps or failures, a debugger sub‑agent is spawned (piv-debugger.md) to examine the gaps and errors, fix root causes, and rerun tests. After each fix, the validator is invoked again. The process repeats up to three times; if still failing, the orchestrator escalates to a human.
Smart Commit – Upon successful validation, the orchestrator changes into the project directory, runs git status and git diff --stat, then creates a commit message:

https://github.com/SmokeAlot420/ftw

Update WORKFLOW.md – Marks the phase as complete, logs validation results, and prepares the file for the next iteration.
Next Phase – Loops back to step 1 for the subsequent phase number.

This repeatable cadence ensures that each phase is fully planned, executed, and validated before moving on, dramatically reducing the chance of rework later in the project.

Why the Skill Embraces FTW (First Try Works)

The FTW mantra—popularized by SmokeAlot420—emphasizes delivering working increments on the first attempt through rigorous preparation, clear contracts, and immediate validation. The PIV skill operationalizes FTW by:

Requiring a PRD (the “what” and “why”) before any code is written.
Generating a PRP that captures the “how” for a specific phase, acting as a detailed contract for the executor.
Using isolated sub‑agents so that each step starts with a clean slate, preventing leakage of assumptions or stale state.
Validating immediately after execution, and allowing a limited debug loop to fix issues before they propagate.
Committing only after a passing validation, with a commit message that explicitly credits the FTW workflow.

By tying each commit to a verified increment, teams gain a traceable history where every snapshot is known to be correct—a powerful aid for debugging, auditing, and continuous integration.

Practical Example: Using the Skill in a Real Project

Imagine you are starting a new CLI tool called “task‑tracker”. You would invoke the skill as follows:

./piv.sh . 1 4

(Assuming the script is named piv.sh and you are in the project root.) Since no PRD exists, the skill enters discovery mode, asks you about the tool’s purpose, suggests a stack (e.g., Go with Cobra), and proposes three phases: (1) project scaffolding & CLI parser, (2) core task‑storage logic, (3) UI enhancements and testing. After you confirm, it creates the PRD, sets up directories, and begins phase 1.

During phase 1, the orchestrator:

Analyzes the empty repo, noting the lack of any source files.
Generates a PRP that outlines creating a main.go with Cobra initialization, a go.mod file, and a unit test skeleton.
Spawns an executor sub‑agent that writes the files, runs go mod tidy, and executes the test suite.
Spawns a validator that confirms the CLI builds, prints help, and the tests pass.
Since validation passes, no debugger is needed.
Commits with the FTW message and updates WORKFLOW.md.

The process repeats for phases 2 and 3, each time building on the verified increment from the previous phase.

Customization and Extensibility

Although the skill ships with sensible defaults, it is designed to be tailored:

The base directory ({baseDir}) can point to a custom set of reference markdown files, allowing teams to substitute their own PRD/PRP templates or validation checklists.
Phase limits (START_PHASE and END_PHASE) are user‑controlled, enabling teams to run only a subset of phases (e.g., just validation of an existing PRP).
The debugger loop’s maximum iterations (hard‑coded to 3) can be adjusted by editing the skill’s source if a team prefers a different tolerance.
Commit message format is explicit in the code; teams wishing to adopt a different convention (e.g., Conventional Commits) can modify the Smart Commit step.

Because the orchestrator itself is only a few hundred lines of Bash and relies on external reference files, extending or porting it to other shells (e.g., Zsh, Fish) or even to a Python wrapper is straightforward.

Benefits for Teams and Individual Contributors

Adopting the OpenClaw PIV skill yields several tangible advantages:

Clarity of Intent – The mandatory PRD forces teams to articulate goals before writing a single line of code, reducing misaligned effort.
Incremental Confidence – Each phase ends with a validated increment, giving early and frequent feedback.
Reduced Context Switching – Fresh sub‑agent contexts mean developers do not need to keep the entire project state in mind while working on a narrow task.
Automated Boilerplate – Directory scaffolding, template copying, and commit messaging are handled automatically, lowering the friction of starting new work.
Traceability – The WORKFLOW.md file provides a lightweight audit trail showing which phases passed, what validation grades were earned, and any debug iterations required.
Alignment with FTW Principles – By embedding the FTW loop directly into the workflow, teams naturally adopt the habit of “first try works” without extra ceremony.

These benefits are especially valuable in remote or asynchronous environments where clear handoffs and minimal reliance on tribal knowledge are crucial.

Limitations and Considerations

While the skill is powerful, teams should be aware of a few considerations:

The orchestrator assumes a Unix‑like environment with git, bash, and standard command‑line utilities. Windows users may need to run it via WSL or a similar compatibility layer.
The discovery mode relies on the orchestrator’s ability to ask questions and interpret answers; if the user provides vague or contradictory responses, the resulting PRD may need manual refinement.
Because each sub‑agent receives a fresh context, any shared state that must persist across phases (e.g., a global configuration file) must be explicitly persisted in the project repo and referenced by the PRP.
The skill does not enforce any particular programming language or framework; suitability therefore depends on the quality of the reference guides (codebase-analysis.md, generate-prp.md, etc.) that the team provides.

Addressing these points typically involves customizing the reference files to match the team’s tech stack and adding lightweight wrapper scripts for Windows compatibility.

Getting Started

To begin using the OpenClaw PIV skill:

Clone the openclaw/skills repository:

https://github.com/openclaw/skills.git

Navigate to the skill directory:
Make the script executable (if needed) and run it against your project:
Follow the prompts in discovery mode (if applicable) or let the orchestrator proceed with an existing PRD.

After the first run, examine the generated PRDs/, PRPs/, and WORKFLOW.md files to confirm that the process captured your intentions correctly. Subsequent runs can skip discovery by pointing directly to the PRD file:

./piv.sh /path/to/your/project/PRDs/PRD-myproject.md 2 4

This will start execution at phase 2 and run through phase 4, picking up where you left off.

Conclusion

The OpenClaw PIV skill is more than a simple Bash script; it is a thoughtfully designed orchestration layer that puts the FTW (First Try Works) philosophy into practice. By mandating a PRD‑first approach, generating phase‑specific PRPs, isolating work in fresh sub‑agent contexts, and validating before each commit, the skill helps teams deliver reliable software increments with minimal waste. Whether you are starting a brand‑new project or seeking to bring rigor to an existing codebase, the PIV orchestrator offers a repeatable, transparent pathway from concept to validated implementation—all while keeping the process lightweight enough for individual contributors and scalable enough for larger teams.

If you value clear requirements, incremental validation, and a commit history you can trust, give the OpenClaw PIV skill a try. Your future self (and your teammates) will thank you for the reduced rework, increased confidence, and the satisfying feeling of seeing each phase pass validation on the first try.

Skill can be found at: https://github.com/openclaw/skills/tree/main/skills/smokealot420/ftw/SKILL.md

The post Understanding the OpenClaw PIV Skill: Plan, Implement, Validate Orchestrator for Smarter Development first appeared on Insight Ginie.

Coder Legion - Recent posts tagged each

How does Go Routine work?

What is a Go Routine?

How Concurrency Different From Parallelism?

How to create a Go Routine?

Conclusion

Understanding the OpenClaw PIV Skill: Plan, Implement, Validate Orchestrator for Smarter Development

Understanding the OpenClaw PIV Skill: Plan, Implement, Validate Orchestrator for Smarter Development

What the Skill Does at a Glance

Deep Dive: Argument Parsing and Mode Detection

Discovery Mode: From Idea to PRD

Phase Workflow: The Heart of PIV

Why the Skill Embraces FTW (First Try Works)

Practical Example: Using the Skill in a Real Project

Customization and Extensibility

Benefits for Teams and Individual Contributors

Limitations and Considerations

Getting Started

Conclusion