@harness-forge/cli 0.1.0

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

@@ -0,0 +1,175 @@
+---
+id: implement-rust-change
+kind: workflow-template
+title: Implement Rust Change
+summary: Deliver Rust work using the promoted common guidance, language rules, and structured language pack.
+mode: sequential
+status: stable
+version: 1
+applies_to:
+  - codex
+  - claude-code
+languages:
+  - rust
+supported_targets:
+  - codex
+  - claude-code
+supported_languages:
+  - rust
+default_agents:
+  - planner
+owner: core
+generated: false
+---
+
+## Purpose
+
+Deliver a Rust change with explicit use of the promoted rules, structured references, and validation steps.
+
+## When to Use
+
+Use when the dominant task language is Rust or when the touched files match the shipped rust pack.
+
+## Entry Conditions
+
+- the affected files are known
+- the dominant language is Rust
+- `rules/common/` and the matching language rule directory are available
+
+## Workflow Stages
+
+### Stage 1: Orient
+
+**Goal**
+Load the common guidance and the Rust-specific references relevant to the task.
+
+**Consumes**
+- `rules/common/`
+- `skills/rust-engineering/SKILL.md`
+- `knowledge-bases/structured/rust/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/rust/`
+- `knowledge-bases/structured/rust/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/rust/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/rust/docs/review-checklist.md`
+- `rules/rust/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/rust/` files were applied
+- note the commands or manual checks used to validate the change
+
+## Exit Conditions
+
+- the implementation aligns with the promoted Rust rules and structured references
+- verification results or blockers are captured clearly
+
+## Failure Modes
+
+- changing ownership or error-handling patterns without checking the Rust rules first
+- finishing without running or documenting the repo's verification path
+
+## Escalation Rules
+
+- escalate when unsafe code or performance-sensitive changes appear
+- escalate when trait or ownership boundaries stay unclear after design
+
+## Artifacts Produced
+
+- changed source files
+- validation output
+- implementation summary
+
+## Human Approval Points
+
+- approve architecture shifts across crates or runtime layers
+- approve any use of unsafe or non-idiomatic ownership tradeoffs
+
+## Examples
+
+- add a new command to a Rust CLI while preserving error handling
+- refactor a service module using the structured Rust reference scenario

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

@@ -0,0 +1,175 @@
+---
+id: implement-shell-change
+kind: workflow-template
+title: Implement Shell Change
+summary: Deliver Shell work using the promoted common guidance, language rules, and structured language pack.
+mode: sequential
+status: stable
+version: 1
+applies_to:
+  - codex
+  - claude-code
+languages:
+  - shell
+supported_targets:
+  - codex
+  - claude-code
+supported_languages:
+  - shell
+default_agents:
+  - planner
+owner: core
+generated: false
+---
+
+## Purpose
+
+Deliver a Shell change with explicit use of the promoted rules, structured references, and validation steps.
+
+## When to Use
+
+Use when the dominant task language is Shell or when the touched files match the shipped shell pack.
+
+## Entry Conditions
+
+- the affected files are known
+- the dominant language is Shell
+- `rules/common/` and the matching language rule directory are available
+
+## Workflow Stages
+
+### Stage 1: Orient
+
+**Goal**
+Load the common guidance and the Shell-specific references relevant to the task.
+
+**Consumes**
+- `rules/common/`
+- `skills/shell-engineering/SKILL.md`
+- `knowledge-bases/structured/shell/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/shell/`
+- `knowledge-bases/structured/shell/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/shell/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/shell/docs/review-checklist.md`
+- `rules/shell/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/shell/` files were applied
+- note the commands or manual checks used to validate the change
+
+## Exit Conditions
+
+- the implementation aligns with the promoted shell rules and structured references
+- verification results or blockers are captured clearly
+
+## Failure Modes
+
+- changing command semantics or platform assumptions without checking the shell rules first
+- finishing without running or documenting the repo's verification path
+
+## Escalation Rules
+
+- escalate when portability, shell compatibility, or destructive operations are unclear
+- escalate when deployment scripts affect production-like environments
+
+## Artifacts Produced
+
+- changed scripts
+- validation output
+- implementation summary
+
+## Human Approval Points
+
+- approve destructive operation changes
+- approve deviations from the promoted shell safety conventions
+
+## Examples
+
+- harden a bootstrap script and verify behavior in dry-run mode
+- refactor shell helper functions using the structured reference scenario

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

@@ -0,0 +1,175 @@
+---
+id: implement-swift-change
+kind: workflow-template
+title: Implement Swift Change
+summary: Deliver Swift work using the promoted common guidance, language rules, and structured language pack.
+mode: sequential
+status: stable
+version: 1
+applies_to:
+  - codex
+  - claude-code
+languages:
+  - swift
+supported_targets:
+  - codex
+  - claude-code
+supported_languages:
+  - swift
+default_agents:
+  - planner
+owner: core
+generated: false
+---
+
+## Purpose
+
+Deliver a Swift change with explicit use of the promoted rules, structured references, and validation steps.
+
+## When to Use
+
+Use when the dominant task language is Swift or when the touched files match the shipped swift pack.
+
+## Entry Conditions
+
+- the affected files are known
+- the dominant language is Swift
+- `rules/common/` and the matching language rule directory are available
+
+## Workflow Stages
+
+### Stage 1: Orient
+
+**Goal**
+Load the common guidance and the Swift-specific references relevant to the task.
+
+**Consumes**
+- `rules/common/`
+- `skills/swift-engineering/SKILL.md`
+- `knowledge-bases/structured/swift/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/swift/`
+- `knowledge-bases/structured/swift/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/swift/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/swift/docs/review-checklist.md`
+- `rules/swift/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/swift/` files were applied
+- note the commands or manual checks used to validate the change
+
+## Exit Conditions
+
+- the implementation aligns with the promoted Swift rules and structured references
+- verification results or blockers are captured clearly
+
+## Failure Modes
+
+- changing module or platform boundaries without checking the Swift rules first
+- finishing without running or documenting the repo's verification path
+
+## Escalation Rules
+
+- escalate when Apple-platform lifecycle behavior or cross-platform constraints are unclear
+- escalate when concurrency or ownership concerns remain unresolved
+
+## Artifacts Produced
+
+- changed source files
+- validation output
+- implementation summary
+
+## Human Approval Points
+
+- approve module boundary changes
+- approve deviations from the promoted Swift conventions
+
+## Examples
+
+- update a Swift package target with focused validation
+- refactor a Swift module using the structured reference scenario

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

@@ -0,0 +1,176 @@
+---
+id: implement-typescript-change
+kind: workflow-template
+title: Implement TypeScript Change
+summary: Deliver TypeScript or JavaScript work using the seeded TypeScript rules, examples, and review guidance.
+mode: sequential
+status: stable
+version: 1
+applies_to:
+  - codex
+  - claude-code
+languages:
+  - typescript
+supported_targets:
+  - codex
+  - claude-code
+supported_languages:
+  - typescript
+default_agents:
+  - planner
+owner: core
+generated: false
+---
+
+## Purpose
+
+Deliver TypeScript or JavaScript work with explicit use of the promoted rules
+and seeded examples.
+
+## When to Use
+
+Use when a task touches TypeScript, JavaScript, Node.js, React, or Next.js code.
+
+## Entry Conditions
+
+- the affected files are known
+- the dominant language is TypeScript or JavaScript
+- `rules/common/` and `rules/typescript/` are available
+
+## Workflow Stages
+
+### Stage 1: Orient
+
+**Goal**
+Load the TypeScript rules and seeded references relevant to the task.
+
+**Consumes**
+- `rules/common/coding-style.md`
+- `rules/typescript/coding-style.md`
+- `knowledge-bases/seeded/typescript/docs/overview.md`
+
+**Produces**
+- selected rule set
+- implementation constraints
+
+**Exit Criteria**
+- required TypeScript 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, types, validation, and tests.
+
+**Consumes**
+- `rules/common/patterns.md`
+- `rules/typescript/patterns.md`
+- `knowledge-bases/seeded/typescript/examples/`
+
+**Produces**
+- file touch list
+- verification approach
+
+**Exit Criteria**
+- module boundaries are explicit
+- validation and typing strategy are clear
+
+**Failure Conditions**
+- types or boundaries remain 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 TypeScript and common rules.
+
+**Consumes**
+- selected design
+- `rules/common/security.md`
+- `rules/typescript/security.md`
+
+**Produces**
+- code changes
+- updated docs if behavior changes
+
+**Exit Criteria**
+- code matches the planned structure
+- security and validation concerns are addressed
+
+**Failure Conditions**
+- type safety 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/typescript/testing.md`
+- `knowledge-bases/seeded/typescript/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/typescript/`
+- relevant seeded examples or review notes were consulted
+
+## Failure Modes
+
+- skipping root rules and relying only on ad hoc implementation
+- ignoring the seeded review checklist before completion
+
+## Escalation Rules
+
+- escalate when the task requires a framework pattern not covered by the seeded pack
+- escalate when type or build constraints conflict with the promoted rules
+
+## Artifacts Produced
+
+- changed source files
+- validation output
+- implementation summary
+
+## Human Approval Points
+
+- approve any major architecture shift
+- approve any deviation from the seeded TypeScript guidance
+
+## Examples
+
+- refactor a Node CLI command using the Node API example pack
+- implement a new React component flow using the seeded component guidance