agents-templated 2.2.18 → 2.2.20

package/templates/agents/commands/learn-loop.md

@@ -1,58 +1,58 @@
-# /learn-loop
-
-## A. Intent
-Capture deterministic retrospective outcomes and convert lessons into next-cycle actions.
-
-## B. When to Use
-- Use after delivery milestones, incidents, or release cycles.
-- Do not use for pre-implementation planning.
-
-## C. Context Assumptions
-- Cycle outcome data is available.
-- Owners for follow-up actions can be assigned.
-- Retrospective scope is defined.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `cycle_name` | string | "Sprint 18" |
-| `observations` | string[] | ["test flakiness", "scope churn"] |
-| `evidence_artifact` | artifact | metrics dashboard, incident notes, PR links |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] observations are evidence-backed
-- [ ] action owners can be assigned
-- [ ] follow-up window is defined
-
-## F. Execution Flow
-1. Collect outcomes, wins, and misses.
-2. Identify root process issues and patterns.
-3. Prioritize actionable improvements.
-4. Decision point ->
-   - condition A -> no actionable item -> request clearer observations
-   - condition B ->  actionable set ready -> continue.
-5. Map actions to owners and timelines.
-6. Emit learn-loop action report.
-
-## G. Output Schema
-
-```json
-{
-  "loop_id": "string",
-  "actions": ["array","of","strings"],
-  "urgency": "low | medium | high",
-  "blocker": "string | null"
-}
-```
-
-## H. Output Target
-- Default delivery: stdout
-- Override flag: --output=<target>
-
-## I. Stop Conditions <- abort with error message, never emit partial output
-- retrospective inputs are anecdotal without evidence
-- no owner can be assigned to critical actions
-
-## J. Safety Constraints
-- Hard block: hard block on publishing blame-focused output without actionable remediation
-- Warn only: warn when metrics are incomplete but direction is still usable
+# /learn-loop
+
+## A. Intent
+Capture deterministic retrospective outcomes and convert lessons into next-cycle actions.
+
+## B. When to Use
+- Use after delivery milestones, incidents, or release cycles.
+- Do not use for pre-implementation planning.
+
+## C. Context Assumptions
+- Cycle outcome data is available.
+- Owners for follow-up actions can be assigned.
+- Retrospective scope is defined.
+
+## D. Required Inputs
+| Input | Type | Example |
+|---------------------|------------|----------------------------------|
+| `cycle_name` | string | "Sprint 18" |
+| `observations` | string[] | ["test flakiness", "scope churn"] |
+| `evidence_artifact` | artifact | metrics dashboard, incident notes, PR links |
+
+## E. Pre-Execution Guards <- fail fast, check ALL before running
+- [ ] observations are evidence-backed
+- [ ] action owners can be assigned
+- [ ] follow-up window is defined
+
+## F. Execution Flow
+1. Collect outcomes, wins, and misses.
+2. Identify root process issues and patterns.
+3. Prioritize actionable improvements.
+4. Decision point ->
+   - condition A -> no actionable item -> request clearer observations
+   - condition B ->  actionable set ready -> continue.
+5. Map actions to owners and timelines.
+6. Emit learn-loop action report.
+
+## G. Output Schema
+
+```json
+{
+  "loop_id": "string",
+  "actions": ["array","of","strings"],
+  "urgency": "low | medium | high",
+  "blocker": "string | null"
+}
+```
+
+## H. Output Target
+- Default delivery: stdout
+- Override flag: --output=<target>
+
+## I. Stop Conditions <- abort with error message, never emit partial output
+- retrospective inputs are anecdotal without evidence
+- no owner can be assigned to critical actions
+
+## J. Safety Constraints
+- Hard block: hard block on publishing blame-focused output without actionable remediation
+- Warn only: warn when metrics are incomplete but direction is still usable

package/templates/agents/commands/perf.md

@@ -1,58 +1,58 @@
-# /perf
-
-## A. Intent
-Define and execute deterministic performance optimization workflow against known baselines.
-
-## B. When to Use
-- Use when improving latency, throughput, or resource efficiency.
-- Do not use for one-off smoke checks; use /perf-scan for quick regression comparison.
-
-## C. Context Assumptions
-- Baseline metrics exist or can be captured.
-- Performance target is defined.
-- Measurement method is repeatable.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `performance_goal` | string | "p95 latency under 200ms" |
-| `baseline_metrics` | string[] | ["p95=260ms", "cpu=70%"] |
-| `benchmark_artifact` | artifact | profiling report or benchmark output |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] goal is measurable
-- [ ] baseline metric set is present
-- [ ] benchmark method is consistent
-
-## F. Execution Flow
-1. Capture or validate baseline metrics.
-2. Apply targeted optimization changes.
-3. Measure post-change metrics.
-4. Decision point ->
-   - condition A -> target unmet -> iterate optimization
-   - condition B ->  target met -> continue.
-5. Summarize gains, tradeoffs, and risks.
-6. Emit performance optimization report.
-
-## G. Output Schema
-
-```json
-{
-  "perf_run_id": "string",
-  "metrics": ["array","of","strings"],
-  "impact": "low | medium | high",
-  "regression": "string | null"
-}
-```
-
-## H. Output Target
-- Default delivery: stdout
-- Override flag: --output=<target>
-
-## I. Stop Conditions <- abort with error message, never emit partial output
-- baseline cannot be measured reliably
-- measurement method is non-deterministic
-
-## J. Safety Constraints
-- Hard block: do not trade correctness/security for performance gains
-- Warn only: warn when gains are within noise threshold
+# /perf
+
+## A. Intent
+Define and execute deterministic performance optimization workflow against known baselines.
+
+## B. When to Use
+- Use when improving latency, throughput, or resource efficiency.
+- Do not use for one-off smoke checks; use /perf-scan for quick regression comparison.
+
+## C. Context Assumptions
+- Baseline metrics exist or can be captured.
+- Performance target is defined.
+- Measurement method is repeatable.
+
+## D. Required Inputs
+| Input | Type | Example |
+|---------------------|------------|----------------------------------|
+| `performance_goal` | string | "p95 latency under 200ms" |
+| `baseline_metrics` | string[] | ["p95=260ms", "cpu=70%"] |
+| `benchmark_artifact` | artifact | profiling report or benchmark output |
+
+## E. Pre-Execution Guards <- fail fast, check ALL before running
+- [ ] goal is measurable
+- [ ] baseline metric set is present
+- [ ] benchmark method is consistent
+
+## F. Execution Flow
+1. Capture or validate baseline metrics.
+2. Apply targeted optimization changes.
+3. Measure post-change metrics.
+4. Decision point ->
+   - condition A -> target unmet -> iterate optimization
+   - condition B ->  target met -> continue.
+5. Summarize gains, tradeoffs, and risks.
+6. Emit performance optimization report.
+
+## G. Output Schema
+
+```json
+{
+  "perf_run_id": "string",
+  "metrics": ["array","of","strings"],
+  "impact": "low | medium | high",
+  "regression": "string | null"
+}
+```
+
+## H. Output Target
+- Default delivery: stdout
+- Override flag: --output=<target>
+
+## I. Stop Conditions <- abort with error message, never emit partial output
+- baseline cannot be measured reliably
+- measurement method is non-deterministic
+
+## J. Safety Constraints
+- Hard block: do not trade correctness/security for performance gains
+- Warn only: warn when gains are within noise threshold

package/templates/agents/commands/plan.md

@@ -1,58 +1,58 @@
-# /plan
-
-## A. Intent
-Build a deterministic implementation plan with scoped phases and acceptance checks.
-
-## B. When to Use
-- Use when a feature or change request is approved for planning before coding starts.
-- Do not use for post-incident debugging; use /debug-track instead.
-
-## C. Context Assumptions
-- Problem statement and objective are available.
-- Primary stakeholders and delivery window are known.
-- Scope boundaries can be explicitly defined.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `objective` | string | "Ship onboarding v2" |
-| `constraints` | string[] | ["2-week deadline", "no schema rewrite"] |
-| `references` | artifact | PRD link, issue URL, screenshot |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] objective is non-empty and testable
-- [ ] constraints are explicit and non-contradictory
-- [ ] required references are accessible
-
-## F. Execution Flow
-1. Collect requirements and constraints.
-2. Split work into ordered phases and milestones.
-3. Attach measurable acceptance criteria per phase.
-4. Decision point ->
-   - condition A -> phase risk > threshold -> add mitigation gate
-   - condition B ->  otherwise -> continue with baseline plan.
-5. Assemble plan artifacts and dependency map.
-6. Emit final plan package.
-
-## G. Output Schema
-
-```json
-{
-  "plan_id": "string",
-  "phases": ["array","of","strings"],
-  "risk_level": "low | medium | high",
-  "notes": "string | null"
-}
-```
-
-## H. Output Target
-- Default delivery: stdout
-- Override flag: --output=<target>
-
-## I. Stop Conditions <- abort with error message, never emit partial output
-- any guard in section E fails
-- acceptance criteria cannot be made measurable
-
-## J. Safety Constraints
-- Hard block: no hidden scope expansion beyond declared boundaries
-- Warn only: allow proceed with warning when estimate confidence is low
+# /plan
+
+## A. Intent
+Build a deterministic implementation plan with scoped phases and acceptance checks.
+
+## B. When to Use
+- Use when a feature or change request is approved for planning before coding starts.
+- Do not use for post-incident debugging; use /debug-track instead.
+
+## C. Context Assumptions
+- Problem statement and objective are available.
+- Primary stakeholders and delivery window are known.
+- Scope boundaries can be explicitly defined.
+
+## D. Required Inputs
+| Input | Type | Example |
+|---------------------|------------|----------------------------------|
+| `objective` | string | "Ship onboarding v2" |
+| `constraints` | string[] | ["2-week deadline", "no schema rewrite"] |
+| `references` | artifact | PRD link, issue URL, screenshot |
+
+## E. Pre-Execution Guards <- fail fast, check ALL before running
+- [ ] objective is non-empty and testable
+- [ ] constraints are explicit and non-contradictory
+- [ ] required references are accessible
+
+## F. Execution Flow
+1. Collect requirements and constraints.
+2. Split work into ordered phases and milestones.
+3. Attach measurable acceptance criteria per phase.
+4. Decision point ->
+   - condition A -> phase risk > threshold -> add mitigation gate
+   - condition B ->  otherwise -> continue with baseline plan.
+5. Assemble plan artifacts and dependency map.
+6. Emit final plan package.
+
+## G. Output Schema
+
+```json
+{
+  "plan_id": "string",
+  "phases": ["array","of","strings"],
+  "risk_level": "low | medium | high",
+  "notes": "string | null"
+}
+```
+
+## H. Output Target
+- Default delivery: stdout
+- Override flag: --output=<target>
+
+## I. Stop Conditions <- abort with error message, never emit partial output
+- any guard in section E fails
+- acceptance criteria cannot be made measurable
+
+## J. Safety Constraints
+- Hard block: no hidden scope expansion beyond declared boundaries
+- Warn only: allow proceed with warning when estimate confidence is low

package/templates/agents/commands/pr.md

@@ -1,58 +1,58 @@
-# /pr
-
-## A. Intent
-Prepare a deterministic pull request package with implementation and validation evidence.
-
-## B. When to Use
-- Use after code changes and validation are complete and review package is needed.
-- Do not use when critical findings are still unresolved.
-
-## C. Context Assumptions
-- Change set exists.
-- Validation evidence is available.
-- Linked issue/task context is known.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `change_summary` | string | "add retry policy to webhook worker" |
-| `linked_items` | string[] | ["ISSUE-18", "TASK-42"] |
-| `validation_evidence` | artifact | test report, benchmark output, screenshot |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] change summary is complete
-- [ ] linked items are resolvable
-- [ ] validation evidence is present
-
-## F. Execution Flow
-1. Collect changed files and linked references.
-2. Summarize intent, impact, and scope.
-3. Attach validation and risk evidence.
-4. Decision point ->
-   - condition A -> critical blocker open -> abort PR package
-   - condition B ->  no blocker -> continue.
-5. Build reviewer checklist and rollout notes.
-6. Emit PR payload.
-
-## G. Output Schema
-
-```json
-{
-  "title": "string",
-  "files_changed": ["array","of","strings"],
-  "risk_assessment": "low | medium | high",
-  "blockers": "string | null"
-}
-```
-
-## H. Output Target
-- Default delivery: stdout
-- Override flag: --output=<target>
-
-## I. Stop Conditions <- abort with error message, never emit partial output
-- validation evidence missing for critical changes
-- open critical findings remain unresolved
-
-## J. Safety Constraints
-- Hard block: hard block if critical issues remain
-- Warn only: warn when non-critical follow-up items are deferred
+# /pr
+
+## A. Intent
+Prepare a deterministic pull request package with implementation and validation evidence.
+
+## B. When to Use
+- Use after code changes and validation are complete and review package is needed.
+- Do not use when critical findings are still unresolved.
+
+## C. Context Assumptions
+- Change set exists.
+- Validation evidence is available.
+- Linked issue/task context is known.
+
+## D. Required Inputs
+| Input | Type | Example |
+|---------------------|------------|----------------------------------|
+| `change_summary` | string | "add retry policy to webhook worker" |
+| `linked_items` | string[] | ["ISSUE-18", "TASK-42"] |
+| `validation_evidence` | artifact | test report, benchmark output, screenshot |
+
+## E. Pre-Execution Guards <- fail fast, check ALL before running
+- [ ] change summary is complete
+- [ ] linked items are resolvable
+- [ ] validation evidence is present
+
+## F. Execution Flow
+1. Collect changed files and linked references.
+2. Summarize intent, impact, and scope.
+3. Attach validation and risk evidence.
+4. Decision point ->
+   - condition A -> critical blocker open -> abort PR package
+   - condition B ->  no blocker -> continue.
+5. Build reviewer checklist and rollout notes.
+6. Emit PR payload.
+
+## G. Output Schema
+
+```json
+{
+  "title": "string",
+  "files_changed": ["array","of","strings"],
+  "risk_assessment": "low | medium | high",
+  "blockers": "string | null"
+}
+```
+
+## H. Output Target
+- Default delivery: stdout
+- Override flag: --output=<target>
+
+## I. Stop Conditions <- abort with error message, never emit partial output
+- validation evidence missing for critical changes
+- open critical findings remain unresolved
+
+## J. Safety Constraints
+- Hard block: hard block if critical issues remain
+- Warn only: warn when non-critical follow-up items are deferred

package/templates/agents/commands/problem-map.md

@@ -1,58 +1,58 @@
-# /problem-map
-
-## A. Intent
-Frame the real user problem and guarantee a clear problem statement before planning.
-
-## B. When to Use
-- Use at the start of a feature cycle when pain points are unclear or broad.
-- Do not use for implementation details or code-level debugging.
-
-## C. Context Assumptions
-- User objective is available.
-- Stakeholder context can be collected.
-- Outcome can be stated as a measurable problem.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `user_problem` | string | "onboarding drop-off at step 2" |
-| `signals` | string[] | ["support tickets", "analytics"] |
-| `evidence_artifact` | artifact | funnel screenshot, issue links |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] problem statement is concrete
-- [ ] signals support the stated pain
-- [ ] scope remains problem-focused
-
-## F. Execution Flow
-1. Collect user pain signals and context.
-2. Synthesize candidate problem statements.
-3. Validate statement against evidence.
-4. Decision point ->
-   - condition A -> weak evidence -> request stronger signals
-   - condition B ->  strong evidence -> continue.
-5. Produce framed problem and success criteria.
-6. Emit problem map package.
-
-## G. Output Schema
-
-```json
-{
-  "problem_id": "string",
-  "core_pains": ["array","of","strings"],
-  "urgency": "low | medium | high",
-  "unknowns": "string | null"
-}
-```
-
-## H. Output Target
-- Default delivery: stdout
-- Override flag: --output=<target>
-
-## I. Stop Conditions <- abort with error message, never emit partial output
-- problem statement remains vague
-- evidence contradicts proposed framing
-
-## J. Safety Constraints
-- Hard block: hard block on fabricated assumptions presented as facts
-- Warn only: warn when evidence quality is limited
+# /problem-map
+
+## A. Intent
+Frame the real user problem and guarantee a clear problem statement before planning.
+
+## B. When to Use
+- Use at the start of a feature cycle when pain points are unclear or broad.
+- Do not use for implementation details or code-level debugging.
+
+## C. Context Assumptions
+- User objective is available.
+- Stakeholder context can be collected.
+- Outcome can be stated as a measurable problem.
+
+## D. Required Inputs
+| Input | Type | Example |
+|---------------------|------------|----------------------------------|
+| `user_problem` | string | "onboarding drop-off at step 2" |
+| `signals` | string[] | ["support tickets", "analytics"] |
+| `evidence_artifact` | artifact | funnel screenshot, issue links |
+
+## E. Pre-Execution Guards <- fail fast, check ALL before running
+- [ ] problem statement is concrete
+- [ ] signals support the stated pain
+- [ ] scope remains problem-focused
+
+## F. Execution Flow
+1. Collect user pain signals and context.
+2. Synthesize candidate problem statements.
+3. Validate statement against evidence.
+4. Decision point ->
+   - condition A -> weak evidence -> request stronger signals
+   - condition B ->  strong evidence -> continue.
+5. Produce framed problem and success criteria.
+6. Emit problem map package.
+
+## G. Output Schema
+
+```json
+{
+  "problem_id": "string",
+  "core_pains": ["array","of","strings"],
+  "urgency": "low | medium | high",
+  "unknowns": "string | null"
+}
+```
+
+## H. Output Target
+- Default delivery: stdout
+- Override flag: --output=<target>
+
+## I. Stop Conditions <- abort with error message, never emit partial output
+- problem statement remains vague
+- evidence contradicts proposed framing
+
+## J. Safety Constraints
+- Hard block: hard block on fabricated assumptions presented as facts
+- Warn only: warn when evidence quality is limited