@harness-forge/cli 0.1.0

package/templates/workflows/implement-go-change.md

@@ -0,0 +1,175 @@
+---
+id: implement-go-change
+kind: workflow-template
+title: Implement Go Change
+summary: Deliver Go work using the promoted common guidance, language rules, and structured language pack.
+mode: sequential
+status: stable
+version: 1
+applies_to:
+  - codex
+  - claude-code
+languages:
+  - go
+supported_targets:
+  - codex
+  - claude-code
+supported_languages:
+  - go
+default_agents:
+  - planner
+owner: core
+generated: false
+---
+
+## Purpose
+
+Deliver a Go change with explicit use of the promoted rules, structured references, and validation steps.
+
+## When to Use
+
+Use when the dominant task language is Go or when the touched files match the shipped go pack.
+
+## Entry Conditions
+
+- the affected files are known
+- the dominant language is Go
+- `rules/common/` and the matching language rule directory are available
+
+## Workflow Stages
+
+### Stage 1: Orient
+
+**Goal**
+Load the common guidance and the Go-specific references relevant to the task.
+
+**Consumes**
+- `rules/common/`
+- `skills/go-engineering/SKILL.md`
+- `knowledge-bases/structured/go/docs/overview.md`
+
+**Produces**
+- selected rule set
+- implementation constraints
+
+**Exit Criteria**
+- the applicable guidance is identified
+- the validation path is known
+
+**Failure Conditions**
+- the task language is mismatched
+- the structured references are unavailable
+
+**Next Trigger**
+Move to design once the active rules and examples are pinned down.
+
+### Stage 2: Design
+
+**Goal**
+Map the change to modules, boundaries, validation, and tests.
+
+**Consumes**
+- `rules/common/`
+- `rules/golang/`
+- `knowledge-bases/structured/go/examples/01-reference-scenario.md`
+
+**Produces**
+- file touch list
+- verification approach
+
+**Exit Criteria**
+- file-level intent is explicit
+- the test or review path is clear
+
+**Failure Conditions**
+- dependencies or boundaries remain ambiguous
+- no workable validation path exists
+
+**Next Trigger**
+Move to implementation when the change is concrete enough to execute safely.
+
+### Stage 3: Implement
+
+**Goal**
+Apply the change following the promoted guidance.
+
+**Consumes**
+- selected design
+- `rules/common/security.md`
+- `rules/golang/security.md`
+
+**Produces**
+- code or script changes
+- updated docs if behavior changes
+
+**Exit Criteria**
+- the implementation matches the intended design
+- obvious safety checks are addressed
+
+**Failure Conditions**
+- the implementation diverges from the selected pattern
+- a blocking compile or runtime issue appears without a safe fix
+
+**Next Trigger**
+Move to verification after the implementation compiles or is otherwise ready to validate.
+
+### Stage 4: Verify
+
+**Goal**
+Validate behavior against the structured review and testing guidance.
+
+**Consumes**
+- `knowledge-bases/structured/go/docs/review-checklist.md`
+- `rules/golang/testing.md`
+- repo-specific build or test commands
+
+**Produces**
+- validation results
+- release notes or follow-up tasks if needed
+
+**Exit Criteria**
+- the intended behavior is verified
+- outstanding follow-ups are captured clearly
+
+**Failure Conditions**
+- tests fail without a safe remediation path
+- the change introduces a release-blocking regression
+
+**Next Trigger**
+End the workflow or hand off follow-up tasks.
+
+## Handoff Contracts
+
+- record which `rules/common/` and `rules/golang/` files were applied
+- note the commands or manual checks used to validate the change
+
+## Exit Conditions
+
+- the implementation aligns with the promoted Go rules and structured references
+- verification results or blockers are captured clearly
+
+## Failure Modes
+
+- changing package or concurrency boundaries without checking the Go rules first
+- finishing without running or documenting the repo's verification path
+
+## Escalation Rules
+
+- escalate when the task needs cross-service or protocol guidance not covered by the pack
+- escalate when module or API boundaries stay ambiguous after the design stage
+
+## Artifacts Produced
+
+- changed source files
+- validation output
+- implementation summary
+
+## Human Approval Points
+
+- approve architecture shifts across packages or service boundaries
+- approve deviations from the promoted Go conventions
+
+## Examples
+
+- add a new CLI command while keeping package boundaries explicit
+- implement an HTTP handler change using the structured Go reference scenario

package/templates/workflows/implement-java-change.md

@@ -0,0 +1,175 @@
+---
+id: implement-java-change
+kind: workflow-template
+title: Implement Java Change
+summary: Deliver Java work using the seeded Java rules, examples, and review guidance.
+mode: sequential
+status: stable
+version: 1
+applies_to:
+  - codex
+  - claude-code
+languages:
+  - java
+supported_targets:
+  - codex
+  - claude-code
+supported_languages:
+  - java
+default_agents:
+  - planner
+owner: core
+generated: false
+---
+
+## Purpose
+
+Deliver Java work with explicit use of the promoted rules and seeded examples.
+
+## When to Use
+
+Use when a task touches Java, Spring Boot, Gradle, Maven, or JVM backend code.
+
+## Entry Conditions
+
+- the affected files are known
+- the dominant language is Java
+- `rules/common/` and `rules/java/` are available
+
+## Workflow Stages
+
+### Stage 1: Orient
+
+**Goal**
+Load the Java rules and seeded references relevant to the task.
+
+**Consumes**
+- `rules/common/coding-style.md`
+- `rules/java/coding-style.md`
+- `knowledge-bases/seeded/java/docs/overview.md`
+
+**Produces**
+- selected rule set
+- implementation constraints
+
+**Exit Criteria**
+- required Java constraints are identified
+- an example path is chosen if one is relevant
+
+**Failure Conditions**
+- the task language is mismatched
+- the seeded references are unavailable
+
+**Next Trigger**
+Move to design once the applicable rules are pinned down.
+
+### Stage 2: Design
+
+**Goal**
+Map the change to modules, services, contracts, and tests.
+
+**Consumes**
+- `rules/common/patterns.md`
+- `rules/java/patterns.md`
+- `knowledge-bases/seeded/java/examples/`
+
+**Produces**
+- file touch list
+- verification approach
+
+**Exit Criteria**
+- domain and service boundaries are explicit
+- testing strategy is clear
+
+**Failure Conditions**
+- architecture remains ambiguous
+- verification strategy is missing
+
+**Next Trigger**
+Move to implementation when file-level changes are concrete.
+
+### Stage 3: Implement
+
+**Goal**
+Apply the change following the promoted Java and common rules.
+
+**Consumes**
+- selected design
+- `rules/common/security.md`
+- `rules/java/security.md`
+
+**Produces**
+- code changes
+- updated docs if behavior changes
+
+**Exit Criteria**
+- implementation follows the selected structure
+- security and validation concerns are addressed
+
+**Failure Conditions**
+- layering collapses
+- error handling or validation is incomplete
+
+**Next Trigger**
+Move to verification after implementation is complete.
+
+### Stage 4: Verify
+
+**Goal**
+Check behavior against the seeded review and testing guidance.
+
+**Consumes**
+- `rules/common/testing.md`
+- `rules/java/testing.md`
+- `knowledge-bases/seeded/java/docs/review-checklist.md`
+
+**Produces**
+- test results
+- final review notes
+
+**Exit Criteria**
+- validations are run or blockers are documented
+- the review checklist is satisfied
+
+**Failure Conditions**
+- tests fail without a safe fix
+- critical review issues remain
+
+**Next Trigger**
+Complete the workflow when verification is documented.
+
+## Handoff Contracts
+
+- record which rule files shaped the implementation
+- list the validation commands that were run
+
+## Exit Conditions
+
+- code aligns with `rules/common/` and `rules/java/`
+- relevant seeded examples or review notes were consulted
+
+## Failure Modes
+
+- bypassing the promoted Java rules
+- shipping service changes without seeded review coverage
+
+## Escalation Rules
+
+- escalate when framework constraints conflict with the promoted guidance
+- escalate when the seeded examples do not cover the required architecture
+
+## Artifacts Produced
+
+- changed source files
+- validation output
+- implementation summary
+
+## Human Approval Points
+
+- approve any architectural boundary changes
+- approve any deviation from the seeded Java guidance
+
+## Examples
+
+- add a Spring Boot endpoint using the seeded REST API example
+- refactor a backend module using the seeded multi-module structure

package/templates/workflows/implement-kotlin-change.md

@@ -0,0 +1,175 @@
+---
+id: implement-kotlin-change
+kind: workflow-template
+title: Implement Kotlin Change
+summary: Deliver Kotlin work using the promoted common guidance, language rules, and structured language pack.
+mode: sequential
+status: stable
+version: 1
+applies_to:
+  - codex
+  - claude-code
+languages:
+  - kotlin
+supported_targets:
+  - codex
+  - claude-code
+supported_languages:
+  - kotlin
+default_agents:
+  - planner
+owner: core
+generated: false
+---
+
+## Purpose
+
+Deliver a Kotlin change with explicit use of the promoted rules, structured references, and validation steps.
+
+## When to Use
+
+Use when the dominant task language is Kotlin or when the touched files match the shipped kotlin pack.
+
+## Entry Conditions
+
+- the affected files are known
+- the dominant language is Kotlin
+- `rules/common/` and the matching language rule directory are available
+
+## Workflow Stages
+
+### Stage 1: Orient
+
+**Goal**
+Load the common guidance and the Kotlin-specific references relevant to the task.
+
+**Consumes**
+- `rules/common/`
+- `skills/kotlin-engineering/SKILL.md`
+- `knowledge-bases/structured/kotlin/docs/overview.md`
+
+**Produces**
+- selected rule set
+- implementation constraints
+
+**Exit Criteria**
+- the applicable guidance is identified
+- the validation path is known
+
+**Failure Conditions**
+- the task language is mismatched
+- the structured references are unavailable
+
+**Next Trigger**
+Move to design once the active rules and examples are pinned down.
+
+### Stage 2: Design
+
+**Goal**
+Map the change to modules, boundaries, validation, and tests.
+
+**Consumes**
+- `rules/common/`
+- `rules/kotlin/`
+- `knowledge-bases/structured/kotlin/examples/01-reference-scenario.md`
+
+**Produces**
+- file touch list
+- verification approach
+
+**Exit Criteria**
+- file-level intent is explicit
+- the test or review path is clear
+
+**Failure Conditions**
+- dependencies or boundaries remain ambiguous
+- no workable validation path exists
+
+**Next Trigger**
+Move to implementation when the change is concrete enough to execute safely.
+
+### Stage 3: Implement
+
+**Goal**
+Apply the change following the promoted guidance.
+
+**Consumes**
+- selected design
+- `rules/common/security.md`
+- `rules/kotlin/security.md`
+
+**Produces**
+- code or script changes
+- updated docs if behavior changes
+
+**Exit Criteria**
+- the implementation matches the intended design
+- obvious safety checks are addressed
+
+**Failure Conditions**
+- the implementation diverges from the selected pattern
+- a blocking compile or runtime issue appears without a safe fix
+
+**Next Trigger**
+Move to verification after the implementation compiles or is otherwise ready to validate.
+
+### Stage 4: Verify
+
+**Goal**
+Validate behavior against the structured review and testing guidance.
+
+**Consumes**
+- `knowledge-bases/structured/kotlin/docs/review-checklist.md`
+- `rules/kotlin/testing.md`
+- repo-specific build or test commands
+
+**Produces**
+- validation results
+- release notes or follow-up tasks if needed
+
+**Exit Criteria**
+- the intended behavior is verified
+- outstanding follow-ups are captured clearly
+
+**Failure Conditions**
+- tests fail without a safe remediation path
+- the change introduces a release-blocking regression
+
+**Next Trigger**
+End the workflow or hand off follow-up tasks.
+
+## Handoff Contracts
+
+- record which `rules/common/` and `rules/kotlin/` files were applied
+- note the commands or manual checks used to validate the change
+
+## Exit Conditions
+
+- the implementation aligns with the promoted Kotlin rules and structured references
+- verification results or blockers are captured clearly
+
+## Failure Modes
+
+- changing coroutine, DI, or module boundaries without checking the Kotlin rules first
+- finishing without running or documenting the repo's verification path
+
+## Escalation Rules
+
+- escalate when the task needs Android or KMP guidance beyond the shipped pack
+- escalate when state or concurrency behavior remains ambiguous after design
+
+## Artifacts Produced
+
+- changed source files
+- validation output
+- implementation summary
+
+## Human Approval Points
+
+- approve architecture shifts across modules or platform layers
+- approve deviations from the promoted Kotlin conventions
+
+## Examples
+
+- update a Ktor route while preserving serialization and plugin setup
+- refactor a Kotlin module using the structured reference scenario

package/templates/workflows/implement-lua-change.md

@@ -0,0 +1,175 @@
+---
+id: implement-lua-change
+kind: workflow-template
+title: Implement Lua Change
+summary: Deliver Lua work using the seeded Lua rules, examples, and review guidance.
+mode: sequential
+status: stable
+version: 1
+applies_to:
+  - codex
+  - claude-code
+languages:
+  - lua
+supported_targets:
+  - codex
+  - claude-code
+supported_languages:
+  - lua
+default_agents:
+  - planner
+owner: core
+generated: false
+---
+
+## Purpose
+
+Deliver Lua work with explicit use of the promoted rules and seeded examples.
+
+## When to Use
+
+Use when a task touches Lua modules, plugins, OpenResty, Love2D, or embedded scripting.
+
+## Entry Conditions
+
+- the affected files are known
+- the dominant language is Lua
+- `rules/common/` and `rules/lua/` are available
+
+## Workflow Stages
+
+### Stage 1: Orient
+
+**Goal**
+Load the Lua rules and seeded references relevant to the task.
+
+**Consumes**
+- `rules/common/coding-style.md`
+- `rules/lua/coding-style.md`
+- `knowledge-bases/seeded/lua/docs/overview.md`
+
+**Produces**
+- selected rule set
+- implementation constraints
+
+**Exit Criteria**
+- required Lua constraints are identified
+- an example path is chosen if one is relevant
+
+**Failure Conditions**
+- the task language is mismatched
+- the seeded references are unavailable
+
+**Next Trigger**
+Move to design once the applicable rules are pinned down.
+
+### Stage 2: Design
+
+**Goal**
+Map the change to modules, runtime boundaries, and tests.
+
+**Consumes**
+- `rules/common/patterns.md`
+- `rules/lua/patterns.md`
+- `knowledge-bases/seeded/lua/examples/`
+
+**Produces**
+- file touch list
+- verification approach
+
+**Exit Criteria**
+- module boundaries are explicit
+- runtime assumptions are clear
+
+**Failure Conditions**
+- runtime choice remains ambiguous
+- test strategy is missing
+
+**Next Trigger**
+Move to implementation when file-level changes are concrete.
+
+### Stage 3: Implement
+
+**Goal**
+Apply the change following the promoted Lua and common rules.
+
+**Consumes**
+- selected design
+- `rules/common/security.md`
+- `rules/lua/security.md`
+
+**Produces**
+- code changes
+- updated docs if behavior changes
+
+**Exit Criteria**
+- implementation matches the selected runtime pattern
+- security and validation concerns are addressed
+
+**Failure Conditions**
+- compatibility regresses
+- the implementation diverges from the selected pattern
+
+**Next Trigger**
+Move to verification after implementation is complete.
+
+### Stage 4: Verify
+
+**Goal**
+Check behavior against the seeded review and testing guidance.
+
+**Consumes**
+- `rules/common/testing.md`
+- `rules/lua/testing.md`
+- `knowledge-bases/seeded/lua/docs/review-checklist.md`
+
+**Produces**
+- test results
+- final review notes
+
+**Exit Criteria**
+- validations are run or blockers are documented
+- the review checklist is satisfied
+
+**Failure Conditions**
+- tests fail without a safe fix
+- critical review issues remain
+
+**Next Trigger**
+Complete the workflow when verification is documented.
+
+## Handoff Contracts
+
+- record which rule files shaped the implementation
+- list the validation commands that were run
+
+## Exit Conditions
+
+- code aligns with `rules/common/` and `rules/lua/`
+- relevant seeded examples or review notes were consulted
+
+## Failure Modes
+
+- bypassing the promoted Lua rules
+- shipping runtime-specific code without checking seeded examples
+
+## Escalation Rules
+
+- escalate when the target runtime is not covered by the seeded pack
+- escalate when the seeded examples do not cover the required pattern
+
+## Artifacts Produced
+
+- changed source files
+- validation output
+- implementation summary
+
+## Human Approval Points
+
+- approve any runtime-specific deviation from the seeded Lua guidance
+- approve any major change in module or plugin structure
+
+## Examples
+
+- implement a Neovim plugin feature using the seeded plugin example
+- update an OpenResty handler using the seeded request-handler example