agents-templated 2.2.12 → 2.2.13

package/agents/commands/plan.md

@@ -1,58 +0,0 @@
-# /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/agents/commands/pr.md

@@ -1,58 +0,0 @@
-# /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/agents/commands/problem-map.md

@@ -1,58 +0,0 @@
-# /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

package/agents/commands/release-ready.md

@@ -1,58 +0,0 @@
-# /release-ready
-
-## A. Intent
-Validate pre-release readiness gates and guarantee deploy prerequisites are satisfied.
-
-## B. When to Use
-- Use after implementation/tests/risk review and before final release decision.
-- Do not use to execute deployment itself.
-
-## C. Context Assumptions
-- Release candidate exists.
-- All required gate outputs are available.
-- Rollout and rollback plans are drafted.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `candidate_version` | string | "v2.4.0-rc1" |
-| `gate_artifacts` | string[] | ["test", "risk-review", "perf-scan"] |
-| `release_artifact` | artifact | release checklist, migration plan |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] mandatory gates are present
-- [ ] critical blockers are resolved
-- [ ] rollback steps are executable
-
-## F. Execution Flow
-1. Collect gate evidence for candidate.
-2. Validate checklist completion.
-3. Verify rollout and rollback readiness.
-4. Decision point ->
-   - condition A -> missing mandatory gate -> block readiness
-   - condition B ->  all gates complete -> continue.
-5. Assemble readiness summary and open items.
-6. Emit release-ready report.
-
-## G. Output Schema
-
-```json
-{
-  "readiness_id": "string",
-  "gate_status": ["array","of","strings"],
-  "readiness_risk": "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
-- mandatory gate missing or failed
-- rollback execution path is unverified
-
-## J. Safety Constraints
-- Hard block: hard block when release checklist is incomplete on critical items
-- Warn only: warn when non-critical items are deferred

package/agents/commands/release.md

@@ -1,58 +0,0 @@
-# /release
-
-## A. Intent
-Generate deterministic release decision package with rollout and rollback readiness.
-
-## B. When to Use
-- Use when deciding whether to ship to production.
-- Do not use before release-ready checks are complete.
-
-## C. Context Assumptions
-- Release candidate is identified.
-- Pre-release checks are completed.
-- Rollback strategy is defined.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `version` | string | "v2.4.0" |
-| `gate_results` | string[] | ["tests-pass", "risk-review-pass"] |
-| `release_artifacts` | artifact | release notes draft, migration plan |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] version is valid and unique
-- [ ] required gates are complete
-- [ ] rollback plan exists
-
-## F. Execution Flow
-1. Collect gate outputs and release artifacts.
-2. Validate rollout and rollback prerequisites.
-3. Classify release risk.
-4. Decision point ->
-   - condition A -> high unresolved risk -> block release
-   - condition B ->  acceptable risk -> continue.
-5. Build release decision and communication payload.
-6. Emit release package.
-
-## G. Output Schema
-
-```json
-{
-  "release_id": "string",
-  "gates": ["array","of","strings"],
-  "release_risk": "low | medium | high",
-  "rollback_status": "string | null"
-}
-```
-
-## H. Output Target
-- Default delivery: stdout
-- Override flag: --output=<target>
-
-## I. Stop Conditions <- abort with error message, never emit partial output
-- required gate missing or failed
-- rollback plan is undefined
-
-## J. Safety Constraints
-- Hard block: hard block on unresolved high-severity release risks
-- Warn only: warn when rollout is phased due to uncertainty

package/agents/commands/risk-review.md

@@ -1,58 +0,0 @@
-# /risk-review
-
-## A. Intent
-Perform deterministic release risk review with mitigation and rollback readiness.
-
-## B. When to Use
-- Use before merge or release approval on non-trivial changes.
-- Do not use as a substitute for running tests.
-
-## C. Context Assumptions
-- Change set is available.
-- Validation evidence exists.
-- Deployment context is known.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `change_set` | string | "payment retry + queue changes" |
-| `validation_status` | string[] | ["unit pass", "integration pass"] |
-| `deployment_artifact` | artifact | rollout plan, env config snapshot |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] change set is fully described
-- [ ] validation status is current
-- [ ] rollback path is defined
-
-## F. Execution Flow
-1. Inspect behavior deltas and blast radius.
-2. Rank risks by impact and likelihood.
-3. Validate mitigations and rollback readiness.
-4. Decision point ->
-   - condition A -> high unresolved risk -> block recommendation
-   - condition B ->  acceptable risk -> continue.
-5. Build release risk summary and actions.
-6. Emit risk review report.
-
-## G. Output Schema
-
-```json
-{
-  "review_id": "string",
-  "risks": ["array","of","strings"],
-  "risk_level": "low | medium | high",
-  "recommendation": "string | null"
-}
-```
-
-## H. Output Target
-- Default delivery: stdout
-- Override flag: --output=<target>
-
-## I. Stop Conditions <- abort with error message, never emit partial output
-- high-severity risk has no mitigation
-- rollback readiness is undefined
-
-## J. Safety Constraints
-- Hard block: hard block on unresolved high-severity risks
-- Warn only: warn when medium risks are accepted with owner

package/agents/commands/scope-shape.md

@@ -1,58 +0,0 @@
-# /scope-shape
-
-## A. Intent
-Constrain delivery scope to the smallest high-value reversible release.
-
-## B. When to Use
-- Use after problem framing and before architectural design.
-- Do not use when requirements are already contractually frozen.
-
-## C. Context Assumptions
-- Problem map exists.
-- Candidate feature list exists.
-- Delivery constraints are known.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `scope_goal` | string | "ship MVP in 2 weeks" |
-| `candidate_items` | string[] | ["email login", "social login", "tutorial"] |
-| `constraint_artifact` | artifact | timeline doc, staffing snapshot |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] scope goal is explicit
-- [ ] candidate items are ranked
-- [ ] out-of-scope list can be produced
-
-## F. Execution Flow
-1. Rank candidate items by value and effort.
-2. Draft in-scope and out-of-scope sets.
-3. Check scope against constraints.
-4. Decision point ->
-   - condition A -> scope exceeds constraints -> trim to MVP
-   - condition B ->  feasible scope -> continue.
-5. Build scope rationale and tradeoffs.
-6. Emit scope decision package.
-
-## G. Output Schema
-
-```json
-{
-  "scope_id": "string",
-  "scope_in": ["array","of","strings"],
-  "confidence": "low | medium | high",
-  "scope_out": "string | null"
-}
-```
-
-## H. Output Target
-- Default delivery: stdout
-- Override flag: --output=<target>
-
-## I. Stop Conditions <- abort with error message, never emit partial output
-- scope cannot satisfy constraints
-- no explicit out-of-scope definition is produced
-
-## J. Safety Constraints
-- Hard block: hard block on hidden scope creep
-- Warn only: warn when deferred items carry significant risk

package/agents/commands/task.md

@@ -1,58 +0,0 @@
-# /task
-
-## A. Intent
-Convert approved plans into deterministic, execution-ready task batches.
-
-## B. When to Use
-- Use when a plan exists and work must be distributed to implementers.
-- Do not use before planning is complete.
-
-## C. Context Assumptions
-- An approved plan exists.
-- Owners and execution context are known.
-- Dependencies can be sequenced.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `plan_id` | string | "plan-2026-04-03" |
-| `task_scope` | string[] | ["api", "ui", "tests"] |
-| `source_artifacts` | artifact | plan file path or issue board URL |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] plan exists and is approved
-- [ ] task scope maps to explicit plan items
-- [ ] dependency order is resolvable
-
-## F. Execution Flow
-1. Read plan outputs and dependency graph.
-2. Split work into atomic tasks.
-3. Assign execution order and ownership metadata.
-4. Decision point ->
-   - condition A -> blocking dependency found -> move item to blocked queue
-   - condition B ->  no blockers -> keep in active queue.
-5. Build task package with acceptance checks.
-6. Emit task list and execution order.
-
-## G. Output Schema
-
-```json
-{
-  "task_batch_id": "string",
-  "tasks": ["array","of","strings"],
-  "priority": "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
-- plan_id is missing or invalid
-- critical dependency cannot be resolved
-
-## J. Safety Constraints
-- Hard block: no task emission without traceability to a plan item
-- Warn only: warn when owner assignment is temporary

package/agents/commands/test.md

@@ -1,58 +0,0 @@
-# /test
-
-## A. Intent
-Run deterministic validation and gate release readiness based on test evidence.
-
-## B. When to Use
-- Use when validating behavior after implementation or before merge/release.
-- This command now includes quality-gate behavior; do not use /quality-gate.
-
-## C. Context Assumptions
-- Test targets are defined.
-- Required environments are available.
-- Pass/fail criteria are explicit.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `test_scope` | string | "api regression" |
-| `test_suites` | string[] | ["unit", "integration", "critical-flow"] |
-| `evidence_artifact` | artifact | test report path or CI run URL |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] test scope is non-empty
-- [ ] critical test suites are executable
-- [ ] pass criteria are declared
-
-## F. Execution Flow
-1. Collect test targets and runtime config.
-2. Execute suites in deterministic order.
-3. Aggregate results and failures.
-4. Decision point ->
-   - condition A -> critical failures present -> gate = blocked
-   - condition B ->  no critical failures -> gate = pass.
-5. Build validation evidence and remediation list.
-6. Emit test and gate report.
-
-## G. Output Schema
-
-```json
-{
-  "test_run_id": "string",
-  "results": ["array","of","strings"],
-  "gate_status": "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
-- critical test suite cannot run
-- result schema cannot be produced
-
-## J. Safety Constraints
-- Hard block: hard block when critical flow tests fail
-- Warn only: warn when flaky tests are excluded with justification

package/agents/commands/ux-bar.md

@@ -1,58 +0,0 @@
-# /ux-bar
-
-## A. Intent
-Assess UX quality bar and guarantee core interaction states are defined before build.
-
-## B. When to Use
-- Use when UX quality and accessibility need pre-implementation validation.
-- Do not use as a replacement for visual design exploration.
-
-## C. Context Assumptions
-- Scope and architecture are available.
-- Primary user flows are identified.
-- Design references exist.
-
-## D. Required Inputs
-| Input | Type | Example |
-|---------------------|------------|----------------------------------|
-| `ux_goal` | string | "reduce checkout friction" |
-| `flows` | string[] | ["cart", "payment", "confirmation"] |
-| `design_artifact` | artifact | wireframes, Figma link, screenshots |
-
-## E. Pre-Execution Guards <- fail fast, check ALL before running
-- [ ] critical flows are enumerated
-- [ ] interaction states include loading/error/empty
-- [ ] accessibility checks are defined
-
-## F. Execution Flow
-1. Review flows and interaction states.
-2. Evaluate accessibility and usability risks.
-3. Score UX gaps by severity.
-4. Decision point ->
-   - condition A -> critical UX gap -> block readiness
-   - condition B ->  manageable gaps -> continue.
-5. Build prioritized improvement list.
-6. Emit UX quality package.
-
-## G. Output Schema
-
-```json
-{
-  "ux_review_id": "string",
-  "ux_gaps": ["array","of","strings"],
-  "severity": "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
-- critical flow lacks defined interaction states
-- accessibility baseline is not addressed
-
-## J. Safety Constraints
-- Hard block: hard block on unaddressed critical accessibility failures
-- Warn only: warn when medium UX issues are deferred

package/agents/rules/planning.mdc

@@ -1,69 +0,0 @@
----
-title: "Planning Discipline"
-description: "Every feature discussion or implementation must produce a reusable prompt plan file in .github/prompts/"
-version: "1.0.0"
-tags: ["planning", "workflow", "documentation", "prompts"]
-alwaysApply: true
----
-
-## Purpose
-
-Ensure every feature discussion, design decision, or implementation produces a reusable prompt plan stored in `.github/prompts/`. Plans persist across sessions and serve as living context for future work — they are never discarded.
-
-## When to Apply
-
-This rule is always active. Trigger when:
-
-- User asks to implement a new feature
-- A design or architecture decision is being made
-- A significant refactor is planned
-- A bug fix requires non-trivial investigation or systemic changes
-- A discussion produces decisions that affect future work
-
-## Plan File Convention
-
-**Location:** `.github/prompts/`
-**Filename:** `YYYY-MM-DD-{feature-slug}.prompt.md`
-**Format:** VS Code reusable prompt (`.prompt.md` — usable as an `@workspace` prompt in Copilot Chat)
-
-## Required Sections
-
-Each plan file must contain:
-
-```
----
-agent: agent
-description: One-line summary of what this plan covers.
----
-
-## Context
-Brief background — what problem are we solving and why now.
-
-## Decision
-What we decided to do and the reasoning behind it (not just what, but why).
-
-## Steps
-Numbered implementation steps in dependency order.
-
-## Acceptance Criteria
-Concrete, testable outcomes that define "done".
-
-## Status
-- [ ] Not started  /  [ ] In progress  /  [x] Complete
-Blockers (if any):
-```
-
-## Workflow
-
-1. At the start of any feature discussion or implementation, create the plan file immediately.
-2. Use the filename convention: `YYYY-MM-DD-{feature-slug}.prompt.md`.
-3. Fill out **Context**, **Decision**, and **Steps** before starting implementation.
-4. Update **Status** and **Acceptance Criteria** incrementally as work progresses.
-5. Mark the plan complete when implementation is verified and accepted.
-
-## Guardrails
-
-- Do not skip plan creation for "small" features — small decisions accumulate into undocumented technical debt.
-- Plans are never deleted — they form a historical record of architectural decisions.
-- Plan files must not contain secrets, credentials, or PII.
-- If a plan changes significantly mid-implementation, update it in place rather than creating a new one.