agents-templated 2.2.9 → 2.2.11
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +101 -86
- package/agents/commands/README.md +70 -0
- package/agents/commands/SCHEMA.md +22 -0
- package/agents/commands/arch-check.md +33 -0
- package/agents/commands/audit.md +38 -0
- package/agents/commands/debug-track.md +33 -0
- package/agents/commands/docs-sync.md +33 -0
- package/agents/commands/docs.md +34 -0
- package/agents/commands/fix.md +34 -0
- package/agents/commands/learn-loop.md +33 -0
- package/agents/commands/perf-scan.md +33 -0
- package/agents/commands/perf.md +34 -0
- package/agents/commands/plan.md +34 -0
- package/agents/commands/pr.md +35 -0
- package/agents/commands/problem-map.md +33 -0
- package/agents/commands/quality-gate.md +33 -0
- package/agents/commands/refactor.md +34 -0
- package/agents/commands/release-ready.md +33 -0
- package/agents/commands/release.md +39 -0
- package/agents/commands/risk-review.md +33 -0
- package/agents/commands/scaffold.md +34 -0
- package/agents/commands/scope-shape.md +33 -0
- package/agents/commands/task.md +35 -0
- package/agents/commands/test.md +34 -0
- package/agents/commands/ux-bar.md +33 -0
- package/agents/rules/planning.mdc +69 -0
- package/bin/cli.js +116 -4
- package/index.js +12 -1
- package/lib/workflow.js +190 -0
- package/package.json +2 -1
- package/templates/.claude/agents/README.md +13 -1
- package/templates/.claude/agents/compatibility-checker.md +79 -0
- package/templates/.claude/agents/configuration-validator.md +85 -0
- package/templates/.claude/agents/database-migrator.md +83 -0
- package/templates/.claude/agents/dependency-auditor.md +92 -0
- package/templates/.claude/agents/load-tester.md +80 -0
- package/templates/.claude/agents/performance-profiler.md +103 -0
- package/templates/CLAUDE.md +8 -0
- package/templates/README.md +104 -61
- package/templates/agents/commands/README.md +47 -1
- package/templates/agents/commands/arch-check.md +33 -0
- package/templates/agents/commands/debug-track.md +33 -0
- package/templates/agents/commands/docs-sync.md +33 -0
- package/templates/agents/commands/learn-loop.md +33 -0
- package/templates/agents/commands/perf-scan.md +33 -0
- package/templates/agents/commands/problem-map.md +33 -0
- package/templates/agents/commands/quality-gate.md +33 -0
- package/templates/agents/commands/release-ready.md +33 -0
- package/templates/agents/commands/risk-review.md +33 -0
- package/templates/agents/commands/scope-shape.md +33 -0
- package/templates/agents/commands/ux-bar.md +33 -0
- package/templates/agents/skills/README.md +6 -0
- package/templates/agents/skills/emilkowalski-skill/SKILL.md +51 -0
- package/templates/agents/skills/raphaelsalaja-userinterface-wiki/SKILL.md +51 -0
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# /perf-scan
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Measure baseline performance and detect regressions with deterministic thresholds.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use before and after performance-sensitive changes.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Baseline context
|
|
11
|
+
- Target endpoints or flows
|
|
12
|
+
- Performance thresholds
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Capture baseline metrics.
|
|
16
|
+
2. Execute candidate workload.
|
|
17
|
+
3. Compare p95/p99 latency and error rates.
|
|
18
|
+
4. Flag regressions with threshold deltas.
|
|
19
|
+
5. Emit optimization priorities.
|
|
20
|
+
|
|
21
|
+
## E. Structured Output Template
|
|
22
|
+
- `baseline_metrics`
|
|
23
|
+
- `candidate_metrics`
|
|
24
|
+
- `regressions[]`
|
|
25
|
+
- `threshold_checks[]`
|
|
26
|
+
- `recommendations[]`
|
|
27
|
+
|
|
28
|
+
## F. Stop Conditions
|
|
29
|
+
- Baseline missing.
|
|
30
|
+
- Thresholds undefined.
|
|
31
|
+
|
|
32
|
+
## G. Safety Constraints
|
|
33
|
+
- Avoid performance claims without before/after evidence.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# /perf
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Evaluate and optimize performance using measurable baselines.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use when latency, throughput, memory, or build-time regressions are reported.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Target metrics
|
|
11
|
+
- Baseline environment
|
|
12
|
+
- Optimization scope
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Capture baseline metrics.
|
|
16
|
+
2. Identify bottlenecks.
|
|
17
|
+
3. Apply one optimization unit.
|
|
18
|
+
4. Re-measure metrics.
|
|
19
|
+
5. Compare against baseline.
|
|
20
|
+
6. Emit performance report.
|
|
21
|
+
|
|
22
|
+
## E. Structured Output Template
|
|
23
|
+
- `baseline_metrics`
|
|
24
|
+
- `optimization_units[]`
|
|
25
|
+
- `post_metrics`
|
|
26
|
+
- `regression_check`
|
|
27
|
+
- `recommendation`
|
|
28
|
+
|
|
29
|
+
## F. Stop Conditions
|
|
30
|
+
- Missing baseline metrics.
|
|
31
|
+
- Non-reproducible benchmark.
|
|
32
|
+
|
|
33
|
+
## G. Safety Constraints
|
|
34
|
+
- Do not trade security controls for performance.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# /plan
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Generate an executable implementation plan with ordered steps and risk controls.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use for non-trivial work requiring sequencing, dependencies, and checkpoints.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Objective
|
|
11
|
+
- Scope boundaries
|
|
12
|
+
- Constraints
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Parse objective and constraints.
|
|
16
|
+
2. Extract atomic work units.
|
|
17
|
+
3. Compute dependency order.
|
|
18
|
+
4. Attach validation checkpoints.
|
|
19
|
+
5. Attach risk and rollback notes.
|
|
20
|
+
6. Emit plan artifacts.
|
|
21
|
+
|
|
22
|
+
## E. Structured Output Template
|
|
23
|
+
- `plan_summary`
|
|
24
|
+
- `work_units[]`
|
|
25
|
+
- `dependency_graph`
|
|
26
|
+
- `validation_checkpoints[]`
|
|
27
|
+
- `risk_register[]`
|
|
28
|
+
|
|
29
|
+
## F. Stop Conditions
|
|
30
|
+
- Missing objective or scope.
|
|
31
|
+
- Contradictory constraints.
|
|
32
|
+
|
|
33
|
+
## G. Safety Constraints
|
|
34
|
+
- Include security and testing gates for code-changing units.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# /pr
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Prepare a deterministic pull request payload with implementation evidence.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use after validated changes are ready for review.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Change summary
|
|
11
|
+
- Linked issues/tasks
|
|
12
|
+
- Validation evidence
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Collect changed files.
|
|
16
|
+
2. Summarize intent and impact.
|
|
17
|
+
3. Attach validation evidence.
|
|
18
|
+
4. Classify risk and rollout impact.
|
|
19
|
+
5. Build reviewer checklist.
|
|
20
|
+
6. Emit PR package.
|
|
21
|
+
|
|
22
|
+
## E. Structured Output Template
|
|
23
|
+
- `title`
|
|
24
|
+
- `summary`
|
|
25
|
+
- `files_changed[]`
|
|
26
|
+
- `validation_evidence[]`
|
|
27
|
+
- `risk_assessment`
|
|
28
|
+
- `review_checklist[]`
|
|
29
|
+
|
|
30
|
+
## F. Stop Conditions
|
|
31
|
+
- Missing validation evidence.
|
|
32
|
+
- Open critical findings.
|
|
33
|
+
|
|
34
|
+
## G. Safety Constraints
|
|
35
|
+
- Block PR package when critical issues remain unresolved.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# /problem-map
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Define the actual user problem and measurable pain signals before solutioning.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use at the start of an initiative when the request is a feature idea rather than a validated problem.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Problem statement
|
|
11
|
+
- Current user pain examples
|
|
12
|
+
- Target user segment
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Extract user outcomes and friction points.
|
|
16
|
+
2. Separate symptoms from root pain.
|
|
17
|
+
3. Identify constraints and non-goals.
|
|
18
|
+
4. Propose a focused problem frame.
|
|
19
|
+
5. Emit acceptance signals for success.
|
|
20
|
+
|
|
21
|
+
## E. Structured Output Template
|
|
22
|
+
- `problem_frame`
|
|
23
|
+
- `pain_signals[]`
|
|
24
|
+
- `root_causes[]`
|
|
25
|
+
- `target_user_segment`
|
|
26
|
+
- `success_signals[]`
|
|
27
|
+
|
|
28
|
+
## F. Stop Conditions
|
|
29
|
+
- Missing target user segment.
|
|
30
|
+
- No concrete pain evidence provided.
|
|
31
|
+
|
|
32
|
+
## G. Safety Constraints
|
|
33
|
+
- Do not lock implementation details in this stage.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# /quality-gate
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Enforce quality gates using test signals, behavior checks, and regression controls.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use before release, and after major bug fixes.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Target build/revision
|
|
11
|
+
- Test scope
|
|
12
|
+
- Critical user flows
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Run required test layers.
|
|
16
|
+
2. Validate critical user flows.
|
|
17
|
+
3. Inspect flaky or unstable results.
|
|
18
|
+
4. Define required remediations.
|
|
19
|
+
5. Emit pass/conditional/block outcome.
|
|
20
|
+
|
|
21
|
+
## E. Structured Output Template
|
|
22
|
+
- `test_results[]`
|
|
23
|
+
- `critical_flow_status[]`
|
|
24
|
+
- `quality_findings[]`
|
|
25
|
+
- `required_fixes[]`
|
|
26
|
+
- `gate_status`
|
|
27
|
+
|
|
28
|
+
## F. Stop Conditions
|
|
29
|
+
- Critical flow untested.
|
|
30
|
+
- Required tests failed.
|
|
31
|
+
|
|
32
|
+
## G. Safety Constraints
|
|
33
|
+
- Do not mark pass when critical regressions remain open.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# /refactor
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Improve internal structure without changing externally observable behavior.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use for maintainability and modularity improvements.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Target component/module
|
|
11
|
+
- Non-functional goals
|
|
12
|
+
- Behavior invariants
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Capture behavior invariants.
|
|
16
|
+
2. Define refactor units.
|
|
17
|
+
3. Apply one unit at a time.
|
|
18
|
+
4. Verify invariants after each unit.
|
|
19
|
+
5. Measure complexity delta.
|
|
20
|
+
6. Emit refactor report.
|
|
21
|
+
|
|
22
|
+
## E. Structured Output Template
|
|
23
|
+
- `target`
|
|
24
|
+
- `invariants[]`
|
|
25
|
+
- `transformations[]`
|
|
26
|
+
- `behavior_check_results[]`
|
|
27
|
+
- `complexity_delta`
|
|
28
|
+
|
|
29
|
+
## F. Stop Conditions
|
|
30
|
+
- Invariant violation.
|
|
31
|
+
- Missing baseline behavior.
|
|
32
|
+
|
|
33
|
+
## G. Safety Constraints
|
|
34
|
+
- Abort on behavior-change risk.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# /release-ready
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Validate release readiness with checks for quality, risk, and rollback.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use immediately before opening or merging a release PR.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Change summary
|
|
11
|
+
- Validation evidence
|
|
12
|
+
- Deployment path
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Confirm test and quality gate outcomes.
|
|
16
|
+
2. Confirm risk-review status.
|
|
17
|
+
3. Verify migration and deploy prerequisites.
|
|
18
|
+
4. Verify rollback plan.
|
|
19
|
+
5. Emit release readiness decision.
|
|
20
|
+
|
|
21
|
+
## E. Structured Output Template
|
|
22
|
+
- `release_scope`
|
|
23
|
+
- `checks_passed[]`
|
|
24
|
+
- `blocking_issues[]`
|
|
25
|
+
- `rollback_plan`
|
|
26
|
+
- `ready_status`
|
|
27
|
+
|
|
28
|
+
## F. Stop Conditions
|
|
29
|
+
- Blocking issue unresolved.
|
|
30
|
+
- Rollback plan absent.
|
|
31
|
+
|
|
32
|
+
## G. Safety Constraints
|
|
33
|
+
- Do not approve release when required evidence is missing.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# /release
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Produce deterministic release readiness decision and rollout contract.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use when promoting validated changes to release channels.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Version/tag
|
|
11
|
+
- Change manifest
|
|
12
|
+
- Rollback strategy
|
|
13
|
+
- Hardening verification evidence (when required by risk profile)
|
|
14
|
+
|
|
15
|
+
## D. Deterministic Execution Flow
|
|
16
|
+
1. Validate release prerequisites.
|
|
17
|
+
2. Validate compatibility and migration risks.
|
|
18
|
+
3. Validate security and test gates.
|
|
19
|
+
4. Validate hardening verification evidence when hardening-required profile applies.
|
|
20
|
+
5. Build release notes.
|
|
21
|
+
6. Build rollout and rollback steps.
|
|
22
|
+
7. Emit release contract.
|
|
23
|
+
|
|
24
|
+
## E. Structured Output Template
|
|
25
|
+
- `version`
|
|
26
|
+
- `release_readiness`
|
|
27
|
+
- `gates[]`
|
|
28
|
+
- `rollout_plan[]`
|
|
29
|
+
- `rollback_plan[]`
|
|
30
|
+
- `release_notes`
|
|
31
|
+
- `hardening_verification`
|
|
32
|
+
|
|
33
|
+
## F. Stop Conditions
|
|
34
|
+
- Gate failure.
|
|
35
|
+
- Missing rollback strategy.
|
|
36
|
+
|
|
37
|
+
## G. Safety Constraints
|
|
38
|
+
- Block release when any critical gate fails.
|
|
39
|
+
- Block release when required hardening evidence is missing.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# /risk-review
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Identify release risks that may pass CI but fail in production.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use before merge or release candidate approval.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Proposed changes
|
|
11
|
+
- Test and validation status
|
|
12
|
+
- Deployment context
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Inspect behavior deltas.
|
|
16
|
+
2. Rank risks by impact and likelihood.
|
|
17
|
+
3. Validate mitigation or rollback paths.
|
|
18
|
+
4. Identify missing tests.
|
|
19
|
+
5. Emit ship recommendation.
|
|
20
|
+
|
|
21
|
+
## E. Structured Output Template
|
|
22
|
+
- `risk_findings[]`
|
|
23
|
+
- `severity_summary`
|
|
24
|
+
- `mitigations[]`
|
|
25
|
+
- `rollback_readiness`
|
|
26
|
+
- `release_recommendation`
|
|
27
|
+
|
|
28
|
+
## F. Stop Conditions
|
|
29
|
+
- High-severity risk has no mitigation.
|
|
30
|
+
- Rollback path is undefined.
|
|
31
|
+
|
|
32
|
+
## G. Safety Constraints
|
|
33
|
+
- Block release for unresolved high-severity findings.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# /scaffold
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Create deterministic project/module boilerplate with secure defaults.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use to initialize new modules/features with approved structure.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Target module name
|
|
11
|
+
- Runtime/stack
|
|
12
|
+
- Required patterns
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Validate target path non-conflict.
|
|
16
|
+
2. Resolve scaffold template.
|
|
17
|
+
3. Generate file tree.
|
|
18
|
+
4. Apply secure defaults.
|
|
19
|
+
5. Generate baseline tests.
|
|
20
|
+
6. Emit scaffold manifest.
|
|
21
|
+
|
|
22
|
+
## E. Structured Output Template
|
|
23
|
+
- `target`
|
|
24
|
+
- `template_source`
|
|
25
|
+
- `files_created[]`
|
|
26
|
+
- `secure_defaults[]`
|
|
27
|
+
- `tests_created[]`
|
|
28
|
+
|
|
29
|
+
## F. Stop Conditions
|
|
30
|
+
- Path collision.
|
|
31
|
+
- Unsupported template/runtime.
|
|
32
|
+
|
|
33
|
+
## G. Safety Constraints
|
|
34
|
+
- Do not overwrite existing files without explicit confirmation.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# /scope-shape
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Constrain scope to the smallest high-leverage release that still proves value.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use after problem framing and before architecture planning.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Problem frame
|
|
11
|
+
- Candidate feature list
|
|
12
|
+
- Delivery constraints
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Rank features by impact and effort.
|
|
16
|
+
2. Define must-have vs defer list.
|
|
17
|
+
3. Freeze first-release boundaries.
|
|
18
|
+
4. Add explicit out-of-scope items.
|
|
19
|
+
5. Emit scope decision rationale.
|
|
20
|
+
|
|
21
|
+
## E. Structured Output Template
|
|
22
|
+
- `scope_in[]`
|
|
23
|
+
- `scope_out[]`
|
|
24
|
+
- `tradeoffs[]`
|
|
25
|
+
- `release_goal`
|
|
26
|
+
- `defer_queue[]`
|
|
27
|
+
|
|
28
|
+
## F. Stop Conditions
|
|
29
|
+
- Scope still exceeds constraints.
|
|
30
|
+
- No out-of-scope list produced.
|
|
31
|
+
|
|
32
|
+
## G. Safety Constraints
|
|
33
|
+
- Prefer one reversible release over broad irreversible scope.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# /task
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Convert a plan item into a deterministic execution task.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use for bounded work with clear acceptance criteria.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Task identifier
|
|
11
|
+
- Acceptance criteria
|
|
12
|
+
- Allowed scope
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Resolve task identifier.
|
|
16
|
+
2. Validate acceptance criteria completeness.
|
|
17
|
+
3. Validate scope boundaries.
|
|
18
|
+
4. Define execution steps.
|
|
19
|
+
5. Define verification steps.
|
|
20
|
+
6. Emit task contract.
|
|
21
|
+
|
|
22
|
+
## E. Structured Output Template
|
|
23
|
+
- `task_id`
|
|
24
|
+
- `objective`
|
|
25
|
+
- `allowed_scope`
|
|
26
|
+
- `execution_steps[]`
|
|
27
|
+
- `verification_steps[]`
|
|
28
|
+
- `acceptance_criteria[]`
|
|
29
|
+
|
|
30
|
+
## F. Stop Conditions
|
|
31
|
+
- Unknown task identifier.
|
|
32
|
+
- Missing acceptance criteria.
|
|
33
|
+
|
|
34
|
+
## G. Safety Constraints
|
|
35
|
+
- Reject out-of-scope changes.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# /test
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Generate or execute deterministic test plans and test artifacts.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use for feature validation, regression prevention, and release readiness.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Target scope
|
|
11
|
+
- Test level
|
|
12
|
+
- Expected behavior
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Resolve test scope.
|
|
16
|
+
2. Map behavior to test cases.
|
|
17
|
+
3. Execute or generate tests.
|
|
18
|
+
4. Capture pass/fail artifacts.
|
|
19
|
+
5. Classify failures.
|
|
20
|
+
6. Emit test report.
|
|
21
|
+
|
|
22
|
+
## E. Structured Output Template
|
|
23
|
+
- `scope`
|
|
24
|
+
- `test_matrix[]`
|
|
25
|
+
- `execution_results[]`
|
|
26
|
+
- `coverage_delta`
|
|
27
|
+
- `failures[]`
|
|
28
|
+
|
|
29
|
+
## F. Stop Conditions
|
|
30
|
+
- Unavailable runtime.
|
|
31
|
+
- Undefined scope.
|
|
32
|
+
|
|
33
|
+
## G. Safety Constraints
|
|
34
|
+
- Do not mark success if critical tests are skipped.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# /ux-bar
|
|
2
|
+
|
|
3
|
+
## A. Intent
|
|
4
|
+
Set a minimum UX quality bar with clear criteria before UI implementation.
|
|
5
|
+
|
|
6
|
+
## B. When to Use
|
|
7
|
+
Use when a feature has user-facing interaction or visual design impact.
|
|
8
|
+
|
|
9
|
+
## C. Required Inputs
|
|
10
|
+
- Target user flow
|
|
11
|
+
- Existing design language
|
|
12
|
+
- Accessibility requirements
|
|
13
|
+
|
|
14
|
+
## D. Deterministic Execution Flow
|
|
15
|
+
1. Evaluate key interaction states.
|
|
16
|
+
2. Check visual hierarchy and clarity.
|
|
17
|
+
3. Validate accessibility coverage.
|
|
18
|
+
4. Identify UX risks and gaps.
|
|
19
|
+
5. Emit UX quality checklist.
|
|
20
|
+
|
|
21
|
+
## E. Structured Output Template
|
|
22
|
+
- `ux_scorecard[]`
|
|
23
|
+
- `interaction_states[]`
|
|
24
|
+
- `accessibility_checks[]`
|
|
25
|
+
- `ux_gaps[]`
|
|
26
|
+
- `improvements[]`
|
|
27
|
+
|
|
28
|
+
## F. Stop Conditions
|
|
29
|
+
- Critical flow has undefined state handling.
|
|
30
|
+
- Accessibility constraints are missing.
|
|
31
|
+
|
|
32
|
+
## G. Safety Constraints
|
|
33
|
+
- Preserve existing design system patterns unless an explicit redesign is approved.
|
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Planning Discipline"
|
|
3
|
+
description: "Every feature discussion or implementation must produce a reusable prompt plan file in .github/prompts/"
|
|
4
|
+
version: "1.0.0"
|
|
5
|
+
tags: ["planning", "workflow", "documentation", "prompts"]
|
|
6
|
+
alwaysApply: true
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Purpose
|
|
10
|
+
|
|
11
|
+
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.
|
|
12
|
+
|
|
13
|
+
## When to Apply
|
|
14
|
+
|
|
15
|
+
This rule is always active. Trigger when:
|
|
16
|
+
|
|
17
|
+
- User asks to implement a new feature
|
|
18
|
+
- A design or architecture decision is being made
|
|
19
|
+
- A significant refactor is planned
|
|
20
|
+
- A bug fix requires non-trivial investigation or systemic changes
|
|
21
|
+
- A discussion produces decisions that affect future work
|
|
22
|
+
|
|
23
|
+
## Plan File Convention
|
|
24
|
+
|
|
25
|
+
**Location:** `.github/prompts/`
|
|
26
|
+
**Filename:** `YYYY-MM-DD-{feature-slug}.prompt.md`
|
|
27
|
+
**Format:** VS Code reusable prompt (`.prompt.md` — usable as an `@workspace` prompt in Copilot Chat)
|
|
28
|
+
|
|
29
|
+
## Required Sections
|
|
30
|
+
|
|
31
|
+
Each plan file must contain:
|
|
32
|
+
|
|
33
|
+
```
|
|
34
|
+
---
|
|
35
|
+
agent: agent
|
|
36
|
+
description: One-line summary of what this plan covers.
|
|
37
|
+
---
|
|
38
|
+
|
|
39
|
+
## Context
|
|
40
|
+
Brief background — what problem are we solving and why now.
|
|
41
|
+
|
|
42
|
+
## Decision
|
|
43
|
+
What we decided to do and the reasoning behind it (not just what, but why).
|
|
44
|
+
|
|
45
|
+
## Steps
|
|
46
|
+
Numbered implementation steps in dependency order.
|
|
47
|
+
|
|
48
|
+
## Acceptance Criteria
|
|
49
|
+
Concrete, testable outcomes that define "done".
|
|
50
|
+
|
|
51
|
+
## Status
|
|
52
|
+
- [ ] Not started / [ ] In progress / [x] Complete
|
|
53
|
+
Blockers (if any):
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
## Workflow
|
|
57
|
+
|
|
58
|
+
1. At the start of any feature discussion or implementation, create the plan file immediately.
|
|
59
|
+
2. Use the filename convention: `YYYY-MM-DD-{feature-slug}.prompt.md`.
|
|
60
|
+
3. Fill out **Context**, **Decision**, and **Steps** before starting implementation.
|
|
61
|
+
4. Update **Status** and **Acceptance Criteria** incrementally as work progresses.
|
|
62
|
+
5. Mark the plan complete when implementation is verified and accepted.
|
|
63
|
+
|
|
64
|
+
## Guardrails
|
|
65
|
+
|
|
66
|
+
- Do not skip plan creation for "small" features — small decisions accumulate into undocumented technical debt.
|
|
67
|
+
- Plans are never deleted — they form a historical record of architectural decisions.
|
|
68
|
+
- Plan files must not contain secrets, credentials, or PII.
|
|
69
|
+
- If a plan changes significantly mid-implementation, update it in place rather than creating a new one.
|