@zigrivers/scaffold 2.1.2 → 2.28.1
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 +272 -59
- package/knowledge/core/adr-craft.md +53 -0
- package/knowledge/core/ai-memory-management.md +246 -0
- package/knowledge/core/api-design.md +4 -0
- package/knowledge/core/claude-md-patterns.md +254 -0
- package/knowledge/core/coding-conventions.md +246 -0
- package/knowledge/core/database-design.md +4 -0
- package/knowledge/core/design-system-tokens.md +465 -0
- package/knowledge/core/dev-environment.md +223 -0
- package/knowledge/core/domain-modeling.md +4 -0
- package/knowledge/core/eval-craft.md +1008 -0
- package/knowledge/core/multi-model-review-dispatch.md +250 -0
- package/knowledge/core/operations-runbook.md +37 -226
- package/knowledge/core/project-structure-patterns.md +231 -0
- package/knowledge/core/review-step-template.md +247 -0
- package/knowledge/core/{security-review.md → security-best-practices.md} +5 -1
- package/knowledge/core/task-decomposition.md +57 -34
- package/knowledge/core/task-tracking.md +225 -0
- package/knowledge/core/tech-stack-selection.md +214 -0
- package/knowledge/core/testing-strategy.md +63 -70
- package/knowledge/core/user-stories.md +69 -60
- package/knowledge/core/user-story-innovation.md +57 -0
- package/knowledge/core/ux-specification.md +5 -148
- package/knowledge/finalization/apply-fixes-and-freeze.md +165 -14
- package/knowledge/product/prd-craft.md +55 -34
- package/knowledge/review/review-adr.md +32 -0
- package/knowledge/review/{review-api-contracts.md → review-api-design.md} +34 -1
- package/knowledge/review/{review-database-schema.md → review-database-design.md} +27 -1
- package/knowledge/review/review-domain-modeling.md +33 -0
- package/knowledge/review/review-implementation-tasks.md +50 -0
- package/knowledge/review/review-operations.md +55 -0
- package/knowledge/review/review-prd.md +33 -0
- package/knowledge/review/review-security.md +53 -0
- package/knowledge/review/review-system-architecture.md +28 -0
- package/knowledge/review/review-testing-strategy.md +51 -0
- package/knowledge/review/review-user-stories.md +54 -0
- package/knowledge/review/{review-ux-spec.md → review-ux-specification.md} +37 -1
- package/methodology/custom-defaults.yml +32 -3
- package/methodology/deep.yml +32 -3
- package/methodology/mvp.yml +32 -3
- package/package.json +2 -1
- package/pipeline/architecture/review-architecture.md +18 -6
- package/pipeline/architecture/system-architecture.md +14 -2
- package/pipeline/consolidation/claude-md-optimization.md +73 -0
- package/pipeline/consolidation/workflow-audit.md +73 -0
- package/pipeline/decisions/adrs.md +14 -2
- package/pipeline/decisions/review-adrs.md +18 -5
- package/pipeline/environment/ai-memory-setup.md +70 -0
- package/pipeline/environment/automated-pr-review.md +70 -0
- package/pipeline/environment/design-system.md +73 -0
- package/pipeline/environment/dev-env-setup.md +65 -0
- package/pipeline/environment/git-workflow.md +71 -0
- package/pipeline/finalization/apply-fixes-and-freeze.md +1 -1
- package/pipeline/finalization/developer-onboarding-guide.md +1 -1
- package/pipeline/finalization/implementation-playbook.md +3 -3
- package/pipeline/foundation/beads.md +68 -0
- package/pipeline/foundation/coding-standards.md +68 -0
- package/pipeline/foundation/project-structure.md +69 -0
- package/pipeline/foundation/tdd.md +60 -0
- package/pipeline/foundation/tech-stack.md +74 -0
- package/pipeline/integration/add-e2e-testing.md +65 -0
- package/pipeline/modeling/domain-modeling.md +14 -2
- package/pipeline/modeling/review-domain-modeling.md +18 -5
- package/pipeline/parity/platform-parity-review.md +70 -0
- package/pipeline/planning/implementation-plan-review.md +56 -0
- package/pipeline/planning/{implementation-tasks.md → implementation-plan.md} +29 -9
- package/pipeline/pre/create-prd.md +13 -4
- package/pipeline/pre/innovate-prd.md +37 -8
- package/pipeline/pre/innovate-user-stories.md +38 -7
- package/pipeline/pre/review-prd.md +18 -6
- package/pipeline/pre/review-user-stories.md +23 -6
- package/pipeline/pre/user-stories.md +12 -2
- package/pipeline/quality/create-evals.md +102 -0
- package/pipeline/quality/operations.md +38 -13
- package/pipeline/quality/review-operations.md +17 -5
- package/pipeline/quality/review-security.md +17 -5
- package/pipeline/quality/review-testing.md +20 -8
- package/pipeline/quality/security.md +25 -3
- package/pipeline/quality/story-tests.md +73 -0
- package/pipeline/specification/api-contracts.md +17 -2
- package/pipeline/specification/database-schema.md +17 -2
- package/pipeline/specification/review-api.md +18 -6
- package/pipeline/specification/review-database.md +18 -6
- package/pipeline/specification/review-ux.md +19 -7
- package/pipeline/specification/ux-spec.md +29 -10
- package/pipeline/validation/critical-path-walkthrough.md +34 -7
- package/pipeline/validation/cross-phase-consistency.md +34 -7
- package/pipeline/validation/decision-completeness.md +34 -7
- package/pipeline/validation/dependency-graph-validation.md +34 -7
- package/pipeline/validation/implementability-dry-run.md +34 -7
- package/pipeline/validation/scope-creep-check.md +34 -7
- package/pipeline/validation/traceability-matrix.md +34 -7
- package/skills/multi-model-dispatch/SKILL.md +326 -0
- package/skills/scaffold-pipeline/SKILL.md +195 -0
- package/skills/scaffold-runner/SKILL.md +465 -0
- package/pipeline/planning/review-tasks.md +0 -38
- package/pipeline/quality/testing-strategy.md +0 -42
|
@@ -0,0 +1,73 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: design-system
|
|
3
|
+
description: Create a cohesive design system with tokens and component patterns for frontend
|
|
4
|
+
phase: "environment"
|
|
5
|
+
order: 320
|
|
6
|
+
dependencies: [dev-env-setup]
|
|
7
|
+
outputs: [docs/design-system.md]
|
|
8
|
+
conditional: "if-needed"
|
|
9
|
+
knowledge-base: [design-system-tokens]
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Purpose
|
|
13
|
+
Define a complete visual language (colors, typography, spacing, borders, shadows)
|
|
14
|
+
and configure the frontend framework's theme with these design tokens. Document
|
|
15
|
+
reusable component patterns so all AI agents build consistent, accessible,
|
|
16
|
+
professional UI without requiring design expertise from the user.
|
|
17
|
+
|
|
18
|
+
## Inputs
|
|
19
|
+
- docs/tech-stack.md (required) — frontend framework and UI library choices
|
|
20
|
+
- docs/plan.md (required) — application purpose and target users inform design direction
|
|
21
|
+
- User preferences (gathered via questions) — overall feel, color preferences,
|
|
22
|
+
reference apps, dark mode requirement
|
|
23
|
+
|
|
24
|
+
## Expected Outputs
|
|
25
|
+
- docs/design-system.md — color palette, typography scale, spacing scale, border
|
|
26
|
+
radius, shadows, component patterns (buttons, forms, cards, feedback, navigation,
|
|
27
|
+
data display), layout system, and do's/don'ts
|
|
28
|
+
- Theme configuration files (tailwind.config.js, theme.ts, CSS custom properties, etc.)
|
|
29
|
+
- Example implementation page demonstrating the design system
|
|
30
|
+
- docs/coding-standards.md updated with Styling / Design System section
|
|
31
|
+
- CLAUDE.md updated with Design System section and quick reference
|
|
32
|
+
|
|
33
|
+
## Quality Criteria
|
|
34
|
+
- All colors meet WCAG AA contrast requirements
|
|
35
|
+
- Typography scale is consistent and readable
|
|
36
|
+
- Spacing uses a consistent base unit (e.g., 4px increments)
|
|
37
|
+
- Component patterns cover buttons, forms, cards, feedback, navigation, data display
|
|
38
|
+
- Theme configuration files actually work (verified by running dev server)
|
|
39
|
+
- Both light and dark mode token values provided (if dark mode requested)
|
|
40
|
+
- Responsive breakpoints defined (mobile, tablet, desktop)
|
|
41
|
+
- No arbitrary hex values or pixel values in component examples (all use tokens)
|
|
42
|
+
|
|
43
|
+
## Methodology Scaling
|
|
44
|
+
- **deep**: Full design system with all component categories, dark mode support,
|
|
45
|
+
responsive breakpoints, animation guidelines, accessibility audit, and example
|
|
46
|
+
page demonstrating all patterns. 15-20 pages.
|
|
47
|
+
- **mvp**: Color palette, typography, spacing scale, and button/form/card patterns.
|
|
48
|
+
No dark mode. Basic theme config. 3-5 pages.
|
|
49
|
+
- **custom:depth(1-5)**: Depth 1-2: colors + typography + buttons. Depth 3: add
|
|
50
|
+
forms, cards, spacing. Depth 4: add navigation, data display, layout. Depth 5:
|
|
51
|
+
full suite with dark mode and accessibility.
|
|
52
|
+
|
|
53
|
+
## Conditional Evaluation
|
|
54
|
+
Enable when: tech-stack.md includes a frontend framework (React, Vue, Angular, Svelte,
|
|
55
|
+
etc.), plan.md describes a UI-based application, or project targets web/mobile
|
|
56
|
+
platforms. Skip when: project is backend-only, a CLI tool, or a library with no UI.
|
|
57
|
+
|
|
58
|
+
## Mode Detection
|
|
59
|
+
Update mode if docs/design-system.md exists. In update mode: never change color
|
|
60
|
+
values, font families, or spacing scales without user approval. Preserve all
|
|
61
|
+
theme config file customizations.
|
|
62
|
+
|
|
63
|
+
## Update Mode Specifics
|
|
64
|
+
- **Detect prior artifact**: docs/design-system.md exists
|
|
65
|
+
- **Preserve**: color palette, typography scale, spacing scale, existing
|
|
66
|
+
component patterns, theme configuration files, dark mode token values,
|
|
67
|
+
responsive breakpoint definitions
|
|
68
|
+
- **Triggers for update**: new UI features need new component patterns, UX spec
|
|
69
|
+
requires additional interaction states, accessibility audit identified contrast
|
|
70
|
+
issues, user requests design direction change
|
|
71
|
+
- **Conflict resolution**: if a new component pattern conflicts with existing
|
|
72
|
+
token usage, extend the token set rather than modifying existing values;
|
|
73
|
+
always verify WCAG AA compliance after any color changes
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dev-env-setup
|
|
3
|
+
description: Configure local dev environment with live reload and simple commands
|
|
4
|
+
phase: "environment"
|
|
5
|
+
order: 310
|
|
6
|
+
dependencies: [project-structure]
|
|
7
|
+
outputs: [docs/dev-setup.md]
|
|
8
|
+
conditional: null
|
|
9
|
+
knowledge-base: [dev-environment]
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Purpose
|
|
13
|
+
Set up a complete local development environment with a one-command dev experience,
|
|
14
|
+
live/hot reloading, local database configuration, environment variable management,
|
|
15
|
+
and beginner-friendly documentation. Populates the CLAUDE.md Key Commands table
|
|
16
|
+
which becomes the single source of truth for project-specific commands referenced
|
|
17
|
+
by the entire workflow.
|
|
18
|
+
|
|
19
|
+
## Inputs
|
|
20
|
+
- docs/tech-stack.md (required) — determines dev server, database, and tooling
|
|
21
|
+
- docs/project-structure.md (required) — where config files live
|
|
22
|
+
- docs/coding-standards.md (optional) — linter/formatter already configured
|
|
23
|
+
- docs/tdd-standards.md (optional) — test runner, flags, coverage thresholds, quality gates
|
|
24
|
+
|
|
25
|
+
## Expected Outputs
|
|
26
|
+
- docs/dev-setup.md — getting started guide, daily development, common tasks,
|
|
27
|
+
troubleshooting, and AI agent instructions
|
|
28
|
+
- Makefile or package.json scripts (dev, test, test:watch, lint, db-setup, db-reset)
|
|
29
|
+
- .env.example with all required variables and sensible local defaults
|
|
30
|
+
- CLAUDE.md updated with Key Commands table and Dev Environment section
|
|
31
|
+
|
|
32
|
+
## Quality Criteria
|
|
33
|
+
- Dev server starts with a single command and supports live/hot reloading
|
|
34
|
+
- Local database setup is scripted (if applicable)
|
|
35
|
+
- .env.example documents all variables with comments
|
|
36
|
+
- Key Commands table in CLAUDE.md matches actual Makefile/package.json commands
|
|
37
|
+
- Lint and test commands exist and are runnable
|
|
38
|
+
- Verification checklist passes (install, dev server, browser, live reload, tests, db)
|
|
39
|
+
- Setup process works for first-time clone (max 5 steps)
|
|
40
|
+
|
|
41
|
+
## Methodology Scaling
|
|
42
|
+
- **deep**: Full environment with database setup, seed data, Docker Compose (if
|
|
43
|
+
needed), watch mode tests, multi-platform instructions (Mac, Linux, WSL),
|
|
44
|
+
troubleshooting section. Complete Key Commands table.
|
|
45
|
+
- **mvp**: Dev server with live reload, basic lint and test commands, .env.example.
|
|
46
|
+
Minimal docs. Key Commands table with essentials only.
|
|
47
|
+
- **custom:depth(1-5)**: Depth 1-2: dev server + test command. Depth 3: add
|
|
48
|
+
database and env vars. Depth 4: add troubleshooting. Depth 5: full docs with
|
|
49
|
+
multi-platform support.
|
|
50
|
+
|
|
51
|
+
## Mode Detection
|
|
52
|
+
Update mode if docs/dev-setup.md exists. In update mode: preserve port assignments,
|
|
53
|
+
custom scripts, .env variable names, database configuration, and Makefile
|
|
54
|
+
customizations. Update CLAUDE.md Key Commands section in-place.
|
|
55
|
+
|
|
56
|
+
## Update Mode Specifics
|
|
57
|
+
- **Detect prior artifact**: docs/dev-setup.md exists
|
|
58
|
+
- **Preserve**: port assignments, .env variable names and defaults, database
|
|
59
|
+
connection strings, custom Makefile targets, troubleshooting entries
|
|
60
|
+
- **Triggers for update**: tech stack changed (new dev server or database),
|
|
61
|
+
project structure changed (new config file locations), new dependencies
|
|
62
|
+
require setup steps, tdd-standards.md changed test commands
|
|
63
|
+
- **Conflict resolution**: if a new dependency conflicts with an existing port
|
|
64
|
+
or env var, propose a non-breaking alternative; always update CLAUDE.md Key
|
|
65
|
+
Commands table to match actual Makefile/package.json after changes
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: git-workflow
|
|
3
|
+
description: Configure git workflow with branching, PRs, CI, and worktree scripts for parallel agents
|
|
4
|
+
phase: "environment"
|
|
5
|
+
order: 330
|
|
6
|
+
dependencies: [dev-env-setup]
|
|
7
|
+
outputs: [docs/git-workflow.md]
|
|
8
|
+
conditional: null
|
|
9
|
+
knowledge-base: [dev-environment]
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Purpose
|
|
13
|
+
Configure the repository for parallel Claude Code sessions working simultaneously.
|
|
14
|
+
Define branching strategy (one task = one branch = one PR), commit standards
|
|
15
|
+
(with Beads task IDs if configured, conventional commits otherwise), rebase
|
|
16
|
+
strategy, PR workflow with squash-merge and auto-merge, worktree setup for
|
|
17
|
+
parallel agents, CI pipeline, branch protection, and conflict prevention rules.
|
|
18
|
+
|
|
19
|
+
## Inputs
|
|
20
|
+
- CLAUDE.md (required) — Key Commands table for lint/test/install commands
|
|
21
|
+
- docs/tech-stack.md (required) — CI environment setup (language, runtime)
|
|
22
|
+
- docs/coding-standards.md (required) — commit message format reference
|
|
23
|
+
|
|
24
|
+
## Expected Outputs
|
|
25
|
+
- docs/git-workflow.md — branching strategy, commit standards, rebase strategy,
|
|
26
|
+
PR workflow (8 sub-steps), task closure, agent crash recovery, branch protection,
|
|
27
|
+
conflict prevention, and worktree documentation
|
|
28
|
+
- scripts/setup-agent-worktree.sh — permanent worktree creation script
|
|
29
|
+
- .github/workflows/ci.yml — CI workflow with lint and test jobs
|
|
30
|
+
- .github/pull_request_template.md — PR template with task ID format
|
|
31
|
+
- CLAUDE.md updated with Committing/PR Workflow, Task Closure, Parallel Sessions,
|
|
32
|
+
Worktree Awareness, and Code Review sections
|
|
33
|
+
|
|
34
|
+
## Quality Criteria
|
|
35
|
+
- Branch naming format is consistent (Beads: bd-<task-id>/<desc>. Non-Beads: <type>/<desc>)
|
|
36
|
+
- Commit format is consistent (Beads: [BD-<id>] type(scope): desc. Non-Beads: type(scope): desc)
|
|
37
|
+
- PR workflow includes all 8 sub-steps (commit, AI review, rebase, push, create,
|
|
38
|
+
auto-merge with --delete-branch, watch CI, confirm merge)
|
|
39
|
+
- Worktree script creates permanent worktrees with workspace branches
|
|
40
|
+
- If Beads: BD_ACTOR environment variable documented for agent identity
|
|
41
|
+
- CI workflow job name matches branch protection context
|
|
42
|
+
- Branch cleanup documented for both single-agent and worktree-agent variants
|
|
43
|
+
- Agent crash recovery procedure documented
|
|
44
|
+
- Conflict prevention rule: don't parallelize tasks touching same files
|
|
45
|
+
|
|
46
|
+
## Methodology Scaling
|
|
47
|
+
- **deep**: Full git workflow with all sections, CI pipeline, branch protection
|
|
48
|
+
via gh api, worktree script, PR template, agent crash recovery, batch branch
|
|
49
|
+
cleanup, and comprehensive CLAUDE.md updates.
|
|
50
|
+
- **mvp**: Branching strategy, commit format, basic PR workflow, CI config.
|
|
51
|
+
Skip worktree script and crash recovery. Minimal CLAUDE.md updates.
|
|
52
|
+
- **custom:depth(1-5)**: Depth 1-2: branching + commits + CI. Depth 3: add PR
|
|
53
|
+
workflow and branch protection. Depth 4: add worktrees and crash recovery.
|
|
54
|
+
Depth 5: full suite with all sections.
|
|
55
|
+
|
|
56
|
+
## Mode Detection
|
|
57
|
+
Update mode if docs/git-workflow.md exists. In update mode: never rename CI jobs
|
|
58
|
+
without checking branch protection rules, preserve worktree directory naming,
|
|
59
|
+
keep setup-agent-worktree.sh customizations intact.
|
|
60
|
+
|
|
61
|
+
## Update Mode Specifics
|
|
62
|
+
- **Detect prior artifact**: docs/git-workflow.md exists
|
|
63
|
+
- **Preserve**: branch naming convention, commit message format, CI job names,
|
|
64
|
+
branch protection rules, worktree directory structure, PR template fields,
|
|
65
|
+
setup-agent-worktree.sh customizations
|
|
66
|
+
- **Triggers for update**: coding-standards.md changed commit format, new CI
|
|
67
|
+
stages needed (e.g., evals added), Beads status changed (added or removed),
|
|
68
|
+
new worktree patterns needed for parallel execution
|
|
69
|
+
- **Conflict resolution**: if CI job rename is required, update branch
|
|
70
|
+
protection rules in the same operation; verify CLAUDE.md workflow section
|
|
71
|
+
stays consistent after any changes
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: apply-fixes-and-freeze
|
|
3
3
|
description: Apply validation findings and freeze documentation
|
|
4
4
|
phase: "finalization"
|
|
5
|
-
order:
|
|
5
|
+
order: 1410
|
|
6
6
|
dependencies: [cross-phase-consistency, traceability-matrix, decision-completeness, critical-path-walkthrough, implementability-dry-run, dependency-graph-validation, scope-creep-check]
|
|
7
7
|
outputs: [docs/validation/fix-log.md]
|
|
8
8
|
conditional: null
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: implementation-playbook
|
|
3
3
|
description: Create the playbook that AI agents follow during implementation
|
|
4
4
|
phase: "finalization"
|
|
5
|
-
order:
|
|
5
|
+
order: 1430
|
|
6
6
|
dependencies: [developer-onboarding-guide]
|
|
7
7
|
outputs: [docs/implementation-playbook.md]
|
|
8
8
|
conditional: null
|
|
@@ -16,9 +16,9 @@ per task, coding standards, git workflow (branching/PR strategy), handoff
|
|
|
16
16
|
format between agents, and success criteria.
|
|
17
17
|
|
|
18
18
|
## Inputs
|
|
19
|
-
- docs/implementation-
|
|
19
|
+
- docs/implementation-plan.md (required) — tasks to sequence
|
|
20
20
|
- docs/system-architecture.md (required) — architecture context
|
|
21
|
-
- docs/
|
|
21
|
+
- docs/tdd-standards.md (required) — testing requirements
|
|
22
22
|
- All other frozen artifacts
|
|
23
23
|
|
|
24
24
|
## Expected Outputs
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: beads
|
|
3
|
+
description: Initialize Beads task tracking with CLAUDE.md conventions and lessons file
|
|
4
|
+
phase: "foundation"
|
|
5
|
+
order: 210
|
|
6
|
+
dependencies: []
|
|
7
|
+
outputs: [.beads/, tasks/lessons.md, CLAUDE.md]
|
|
8
|
+
conditional: "if-needed"
|
|
9
|
+
knowledge-base: [task-tracking]
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Purpose
|
|
13
|
+
Initialize the Beads issue tracker for AI-friendly task tracking, create the
|
|
14
|
+
lessons-learned file for cross-session memory, and establish the initial CLAUDE.md
|
|
15
|
+
skeleton with core principles, task management commands, self-improvement rules,
|
|
16
|
+
and autonomous behavior guidelines.
|
|
17
|
+
|
|
18
|
+
## Inputs
|
|
19
|
+
- Project root directory (required) — must be a git repository
|
|
20
|
+
- Existing CLAUDE.md (optional) — if present, operates in update mode
|
|
21
|
+
|
|
22
|
+
## Expected Outputs
|
|
23
|
+
- .beads/ directory — initialized Beads data store with git hooks
|
|
24
|
+
- tasks/lessons.md — patterns and anti-patterns file for cross-session learning
|
|
25
|
+
- CLAUDE.md — initial skeleton with Core Principles, Task Management (Beads),
|
|
26
|
+
Self-Improvement, and Autonomous Behavior sections
|
|
27
|
+
|
|
28
|
+
## Quality Criteria
|
|
29
|
+
- `bd ready` executes without error (Beads is initialized)
|
|
30
|
+
- .beads/ directory exists and contains Beads data files
|
|
31
|
+
- Beads git hooks are installed (data-sync hooks, not code-quality hooks)
|
|
32
|
+
- tasks/lessons.md exists with Patterns, Anti-Patterns, and Common Gotchas sections
|
|
33
|
+
- CLAUDE.md contains Core Principles with all four tenets (Simplicity, No Laziness, TDD, Prove It)
|
|
34
|
+
- CLAUDE.md contains Beads command reference table
|
|
35
|
+
- CLAUDE.md contains commit-message convention requiring Beads task IDs
|
|
36
|
+
- Bootstrap commit uses `[BD-0]` convention
|
|
37
|
+
|
|
38
|
+
## Methodology Scaling
|
|
39
|
+
- **deep**: Full Beads setup with all CLAUDE.md sections, detailed command reference
|
|
40
|
+
table, priority level documentation, and cross-doc consistency checks against
|
|
41
|
+
existing git-workflow.md and coding-standards.md.
|
|
42
|
+
- **mvp**: Initialize Beads, create tasks/lessons.md, add minimal CLAUDE.md
|
|
43
|
+
sections (Core Principles + Beads commands). Skip cross-doc checks.
|
|
44
|
+
- **custom:depth(1-5)**: Depth 1-2: MVP Beads init + minimal CLAUDE.md. Depth 3:
|
|
45
|
+
add full command table and priority docs. Depth 4-5: full setup with cross-doc
|
|
46
|
+
consistency and detailed autonomous behavior rules.
|
|
47
|
+
|
|
48
|
+
## Conditional Evaluation
|
|
49
|
+
Enable when: project uses Beads task tracking methodology (user selects Beads during
|
|
50
|
+
setup), or user explicitly enables structured task management. Skip when: user prefers
|
|
51
|
+
GitHub Issues, Linear, or another task tracker, or explicitly declines Beads setup.
|
|
52
|
+
|
|
53
|
+
## Mode Detection
|
|
54
|
+
Update mode if .beads/ directory exists. In update mode: never re-initialize
|
|
55
|
+
.beads/ (existing task data is irreplaceable), never overwrite tasks/lessons.md
|
|
56
|
+
(only add missing sections), update CLAUDE.md Beads sections in-place preserving
|
|
57
|
+
project-specific customizations.
|
|
58
|
+
|
|
59
|
+
## Update Mode Specifics
|
|
60
|
+
- **Detect prior artifact**: .beads/ directory exists with data files
|
|
61
|
+
- **Preserve**: all existing task data in .beads/, tasks/lessons.md content
|
|
62
|
+
(patterns, anti-patterns, gotchas), CLAUDE.md Beads command table
|
|
63
|
+
customizations, git hook configurations
|
|
64
|
+
- **Triggers for update**: new CLAUDE.md sections need Beads references,
|
|
65
|
+
Beads CLI version changed requiring command updates, git hooks need
|
|
66
|
+
reconfiguration after workflow changes
|
|
67
|
+
- **Conflict resolution**: if CLAUDE.md Beads section was manually customized,
|
|
68
|
+
merge new content around existing customizations rather than replacing
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: coding-standards
|
|
3
|
+
description: Create prescriptive coding standards tailored to the project's tech stack
|
|
4
|
+
phase: "foundation"
|
|
5
|
+
order: 230
|
|
6
|
+
dependencies: [tech-stack]
|
|
7
|
+
outputs: [docs/coding-standards.md]
|
|
8
|
+
reads: [create-prd]
|
|
9
|
+
conditional: null
|
|
10
|
+
knowledge-base: [coding-conventions]
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Purpose
|
|
14
|
+
Define the project's coding conventions with concrete, stack-specific examples
|
|
15
|
+
that AI agents reference during every implementation task. Covers project
|
|
16
|
+
structure conventions, code patterns, type safety, security, database access,
|
|
17
|
+
API design, logging, AI-specific pitfalls, commit message format, and a
|
|
18
|
+
self-review checklist.
|
|
19
|
+
|
|
20
|
+
## Inputs
|
|
21
|
+
- docs/tech-stack.md (required) — determines which languages, frameworks, and tools
|
|
22
|
+
the standards apply to
|
|
23
|
+
- docs/plan.md (required) — application domain informs which patterns matter most
|
|
24
|
+
|
|
25
|
+
## Expected Outputs
|
|
26
|
+
- docs/coding-standards.md — prescriptive standards document with sections for
|
|
27
|
+
project structure, code patterns, type safety, security, database access, API
|
|
28
|
+
design, logging, AI-specific rules, commit messages, and code review checklist
|
|
29
|
+
- Linter/formatter config files (e.g., .eslintrc, .prettierrc, ruff.toml) created
|
|
30
|
+
alongside the standards doc
|
|
31
|
+
|
|
32
|
+
## Quality Criteria
|
|
33
|
+
- Every standard references the specific tech stack, not generic principles
|
|
34
|
+
- Includes runnable code examples showing the RIGHT way for the stack
|
|
35
|
+
- Commit message format is [BD-<id>] type(scope): description
|
|
36
|
+
- AI-specific coding rules section addresses common AI mistakes (dead code,
|
|
37
|
+
duplication, magic numbers, premature abstraction, unnecessary features)
|
|
38
|
+
- Linter/formatter configs created and referenced from the document
|
|
39
|
+
- No aspirational standards — only rules enforced from day one
|
|
40
|
+
- Code review checklist is actionable (not vague)
|
|
41
|
+
|
|
42
|
+
## Methodology Scaling
|
|
43
|
+
- **deep**: Comprehensive standards with examples for every section. Stack-specific
|
|
44
|
+
security patterns. Detailed error handling strategy with code samples. Full
|
|
45
|
+
linter/formatter configuration with custom rules. 15-20 pages.
|
|
46
|
+
- **mvp**: Core naming conventions, commit format, import ordering, error handling
|
|
47
|
+
approach, and AI-specific rules. Basic linter config. 3-5 pages.
|
|
48
|
+
- **custom:depth(1-5)**: Depth 1-2: MVP conventions. Depth 3: add security and
|
|
49
|
+
database patterns. Depth 4: add API design and logging. Depth 5: full suite
|
|
50
|
+
with all sections and custom linter rules.
|
|
51
|
+
|
|
52
|
+
## Mode Detection
|
|
53
|
+
Update mode if docs/coding-standards.md exists. In update mode: preserve naming
|
|
54
|
+
conventions, lint rule customizations, commit message format, and project-specific
|
|
55
|
+
patterns. Never change commit message format without checking git-workflow.md
|
|
56
|
+
and CI config for references.
|
|
57
|
+
|
|
58
|
+
## Update Mode Specifics
|
|
59
|
+
- **Detect prior artifact**: docs/coding-standards.md exists
|
|
60
|
+
- **Preserve**: naming conventions, commit message format, lint/formatter
|
|
61
|
+
configurations, AI-specific coding rules, code review checklist, any
|
|
62
|
+
project-specific patterns added by the team
|
|
63
|
+
- **Triggers for update**: tech stack changed (new language or framework
|
|
64
|
+
requires new patterns), new architecture patterns need coding conventions,
|
|
65
|
+
team identified recurring issues needing new rules
|
|
66
|
+
- **Conflict resolution**: if tech stack added a new framework, add its
|
|
67
|
+
conventions as a new section rather than modifying existing sections;
|
|
68
|
+
verify commit format consistency with git-workflow.md before any changes
|
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: project-structure
|
|
3
|
+
description: Design directory layout and scaffold the actual project structure
|
|
4
|
+
phase: "foundation"
|
|
5
|
+
order: 250
|
|
6
|
+
dependencies: [tech-stack, coding-standards]
|
|
7
|
+
outputs: [docs/project-structure.md]
|
|
8
|
+
reads: [create-prd, user-stories]
|
|
9
|
+
conditional: null
|
|
10
|
+
knowledge-base: [project-structure-patterns]
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Purpose
|
|
14
|
+
Design the directory layout optimized for parallel AI agent work (minimizing
|
|
15
|
+
merge conflicts and maximizing task independence), document file placement rules,
|
|
16
|
+
and scaffold the actual directories and placeholder files. Updates CLAUDE.md
|
|
17
|
+
with a Quick Reference section for file placement.
|
|
18
|
+
|
|
19
|
+
## Inputs
|
|
20
|
+
- docs/tech-stack.md (required) — framework conventions determine structure
|
|
21
|
+
- docs/coding-standards.md (required) — naming and organization conventions
|
|
22
|
+
- docs/tdd-standards.md (optional) — test co-location rules
|
|
23
|
+
- docs/plan.md (required) — features inform organization strategy choice
|
|
24
|
+
|
|
25
|
+
## Expected Outputs
|
|
26
|
+
- docs/project-structure.md — complete directory tree with purpose annotations,
|
|
27
|
+
module organization strategy, file placement rules, shared code strategy,
|
|
28
|
+
import conventions, barrel file policy, test file location, and generated
|
|
29
|
+
vs. committed file rules
|
|
30
|
+
- Scaffolded directories with .gitkeep files
|
|
31
|
+
- Updated .gitignore for the tech stack
|
|
32
|
+
- CLAUDE.md updated with Project Structure Quick Reference section
|
|
33
|
+
|
|
34
|
+
## Quality Criteria
|
|
35
|
+
- Module organization strategy chosen and justified (feature-based, layer-based, or hybrid)
|
|
36
|
+
- File placement table covers all file types (routes, services, models, types, utils, tests)
|
|
37
|
+
- High-contention files identified with merge-conflict mitigation strategies
|
|
38
|
+
- Shared utilities rule enforced (2+ features before promoting to shared)
|
|
39
|
+
- Import conventions defined with ordering rules
|
|
40
|
+
- Test file location aligns with tdd-standards.md (if it exists)
|
|
41
|
+
- .gitignore covers all generated files for the tech stack
|
|
42
|
+
- Structure follows the chosen framework's conventions
|
|
43
|
+
|
|
44
|
+
## Methodology Scaling
|
|
45
|
+
- **deep**: Comprehensive structure with high-contention analysis, shared code
|
|
46
|
+
strategy, import path aliases, barrel file policy, responsive breakpoints for
|
|
47
|
+
screenshots, and generated vs. committed file inventory.
|
|
48
|
+
- **mvp**: Directory tree with annotations, basic file placement table, .gitignore.
|
|
49
|
+
Skip shared code strategy and high-contention analysis.
|
|
50
|
+
- **custom:depth(1-5)**: Depth 1-2: tree + placement table. Depth 3: add shared
|
|
51
|
+
code rules. Depth 4: add contention analysis. Depth 5: full suite with barrel
|
|
52
|
+
policy and import aliases.
|
|
53
|
+
|
|
54
|
+
## Mode Detection
|
|
55
|
+
Update mode if docs/project-structure.md exists. In update mode: never delete
|
|
56
|
+
existing directories (only add new ones), preserve module organization strategy
|
|
57
|
+
choice, update CLAUDE.md Quick Reference section in-place.
|
|
58
|
+
|
|
59
|
+
## Update Mode Specifics
|
|
60
|
+
- **Detect prior artifact**: docs/project-structure.md exists
|
|
61
|
+
- **Preserve**: module organization strategy (feature-based, layer-based, hybrid),
|
|
62
|
+
existing directory tree, file placement rules, import conventions, barrel file
|
|
63
|
+
policy, .gitignore entries
|
|
64
|
+
- **Triggers for update**: new features require new directories, architecture
|
|
65
|
+
changed module boundaries, tech stack added new file types needing placement
|
|
66
|
+
rules, tdd-standards.md changed test co-location rules
|
|
67
|
+
- **Conflict resolution**: if architecture restructured modules, add new
|
|
68
|
+
directories but do not remove existing ones until migration is complete;
|
|
69
|
+
update CLAUDE.md Quick Reference to reflect additions
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: tdd
|
|
3
|
+
description: Define testing conventions and TDD standards for the tech stack
|
|
4
|
+
phase: "foundation"
|
|
5
|
+
order: 240
|
|
6
|
+
dependencies: [coding-standards]
|
|
7
|
+
outputs: [docs/tdd-standards.md]
|
|
8
|
+
reads: [create-prd]
|
|
9
|
+
conditional: null
|
|
10
|
+
knowledge-base: [testing-strategy]
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Purpose
|
|
14
|
+
Define the project's testing conventions, TDD workflow, test pyramid, coverage
|
|
15
|
+
goals, quality gates, and testing patterns. This tells agents how to test the
|
|
16
|
+
code they write and establishes testing standards before implementation begins.
|
|
17
|
+
|
|
18
|
+
## Inputs
|
|
19
|
+
- docs/tech-stack.md (required) — determines test runner, assertion library, and framework-specific testing patterns
|
|
20
|
+
- docs/coding-standards.md (required) — naming conventions and code patterns that apply to test files
|
|
21
|
+
- docs/plan.md (required) — features inform which testing scenarios matter most
|
|
22
|
+
- docs/system-architecture.md (optional) — if available, layers to test
|
|
23
|
+
- docs/domain-models/ (optional) — if available, business rules to verify
|
|
24
|
+
- docs/adrs/ (optional) — if available, testing technology choices
|
|
25
|
+
|
|
26
|
+
## Expected Outputs
|
|
27
|
+
- docs/tdd-standards.md — testing approach with coverage goals and patterns
|
|
28
|
+
|
|
29
|
+
## Quality Criteria
|
|
30
|
+
- Test pyramid defined with coverage targets per layer
|
|
31
|
+
- Testing patterns specified for each layer (unit, integration, e2e)
|
|
32
|
+
- Quality gates defined (what must pass before merge)
|
|
33
|
+
- Edge cases from domain invariants are test scenarios
|
|
34
|
+
- Performance testing approach for critical paths
|
|
35
|
+
|
|
36
|
+
## Methodology Scaling
|
|
37
|
+
- **deep**: Comprehensive strategy. Test matrix by layer and component. Specific
|
|
38
|
+
test patterns per architecture pattern. Performance benchmarks. CI integration.
|
|
39
|
+
Test data strategy. Mutation testing approach.
|
|
40
|
+
- **mvp**: Test pyramid overview. Key testing patterns. What must pass before deploy.
|
|
41
|
+
- **custom:depth(1-5)**: Scale detail with depth.
|
|
42
|
+
|
|
43
|
+
## Mode Detection
|
|
44
|
+
Check for docs/tdd-standards.md. If it exists, operate in update mode: read
|
|
45
|
+
existing strategy and diff against current tech stack, coding standards, and
|
|
46
|
+
PRD. Preserve testing patterns, layer definitions, custom assertions, and test
|
|
47
|
+
data strategy. Update coverage goals if PRD scope or tech stack changed.
|
|
48
|
+
Re-generate only sections affected by upstream changes — do not rewrite
|
|
49
|
+
stable layer definitions or custom assertion patterns.
|
|
50
|
+
|
|
51
|
+
## Update Mode Specifics
|
|
52
|
+
- **Detect prior artifact**: docs/tdd-standards.md exists
|
|
53
|
+
- **Preserve**: test pyramid layer definitions, custom assertion helpers, test
|
|
54
|
+
data strategy, quality gate thresholds, framework-specific patterns
|
|
55
|
+
- **Triggers for update**: tech-stack.md changed (new test runner or framework),
|
|
56
|
+
coding-standards.md changed (naming conventions), PRD scope expanded (new
|
|
57
|
+
features needing test scenarios)
|
|
58
|
+
- **Conflict resolution**: if tech stack changed test runner, migrate pattern
|
|
59
|
+
examples to new runner syntax; preserve coverage targets unless user requests
|
|
60
|
+
adjustment
|
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: tech-stack
|
|
3
|
+
description: Research and document tech stack decisions with rationale for each choice
|
|
4
|
+
phase: "foundation"
|
|
5
|
+
order: 220
|
|
6
|
+
dependencies: []
|
|
7
|
+
outputs: [docs/tech-stack.md]
|
|
8
|
+
reads: [create-prd]
|
|
9
|
+
conditional: null
|
|
10
|
+
knowledge-base: [tech-stack-selection]
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Purpose
|
|
14
|
+
Research frameworks, languages, databases, and tools that fit the PRD requirements,
|
|
15
|
+
then document every technology choice with rationale, alternatives considered, and
|
|
16
|
+
AI compatibility notes. This becomes the definitive technology reference that all
|
|
17
|
+
subsequent phases depend on for framework-specific decisions.
|
|
18
|
+
|
|
19
|
+
At depth 4+, dispatches to external AI models (Codex, Gemini) for
|
|
20
|
+
independent technology research — different models have different knowledge
|
|
21
|
+
about ecosystem maturity, alternatives, and gotchas.
|
|
22
|
+
|
|
23
|
+
## Inputs
|
|
24
|
+
- docs/plan.md (required) — PRD features, integrations, and technical requirements
|
|
25
|
+
- User preferences (gathered via questions) — language, framework, deployment target, constraints
|
|
26
|
+
|
|
27
|
+
## Expected Outputs
|
|
28
|
+
- docs/tech-stack.md — complete technology reference with architecture overview,
|
|
29
|
+
backend, database, frontend (if applicable), infrastructure, developer tooling,
|
|
30
|
+
and third-party services sections, plus a Quick Reference dependency list
|
|
31
|
+
- docs/reviews/tech-stack/review-summary.md (depth 4+) — multi-model research synthesis
|
|
32
|
+
- docs/reviews/tech-stack/codex-review.json (depth 4+, if available) — raw Codex recommendations
|
|
33
|
+
- docs/reviews/tech-stack/gemini-review.json (depth 4+, if available) — raw Gemini recommendations
|
|
34
|
+
|
|
35
|
+
## Quality Criteria
|
|
36
|
+
- Every PRD feature cross-referenced against the proposed stack (no capability gaps)
|
|
37
|
+
- Each technology choice documents what, why, why not alternatives, and AI compatibility
|
|
38
|
+
- Architecture pattern chosen and justified (monolith vs. microservices, MVC vs. clean, etc.)
|
|
39
|
+
- No speculative technologies ("might need someday")
|
|
40
|
+
- Every choice is a decision, not a menu of options
|
|
41
|
+
- Quick Reference section lists every dependency with version
|
|
42
|
+
- Stack optimizes for AI familiarity, convention over configuration, minimal dependencies,
|
|
43
|
+
strong typing, and mature ecosystem
|
|
44
|
+
- (depth 4+) Multi-model recommendations cross-referenced — agreements flagged as high-confidence, disagreements flagged for human decision
|
|
45
|
+
|
|
46
|
+
## Methodology Scaling
|
|
47
|
+
- **deep**: Comprehensive research with competitive analysis for each category.
|
|
48
|
+
Detailed AI compatibility notes per library. Version pinning with upgrade
|
|
49
|
+
strategy. Infrastructure and DevOps recommendations. 10-15 pages. Multi-model
|
|
50
|
+
research dispatched to Codex and Gemini if available, with graceful fallback
|
|
51
|
+
to Claude-only enhanced research.
|
|
52
|
+
- **mvp**: Core stack decisions only (language, framework, database, test runner).
|
|
53
|
+
Brief rationale. Quick Reference with versions. 2-3 pages.
|
|
54
|
+
- **custom:depth(1-5)**: Depth 1-2: MVP decisions. Depth 3: add infrastructure
|
|
55
|
+
and tooling. Depth 4: add AI compatibility analysis + one external model
|
|
56
|
+
(if CLI available). Depth 5: full competitive analysis and upgrade strategy
|
|
57
|
+
+ multi-model with cross-referencing.
|
|
58
|
+
|
|
59
|
+
## Mode Detection
|
|
60
|
+
Update mode if docs/tech-stack.md exists. In update mode: never change a
|
|
61
|
+
technology choice without user approval, preserve version pins exactly, update
|
|
62
|
+
Quick Reference to match any structural changes. If multi-model artifacts exist
|
|
63
|
+
under docs/reviews/tech-stack/, preserve prior recommendation dispositions.
|
|
64
|
+
|
|
65
|
+
## Update Mode Specifics
|
|
66
|
+
- **Detect prior artifact**: docs/tech-stack.md exists
|
|
67
|
+
- **Preserve**: all technology choices and their rationale, version pins,
|
|
68
|
+
Quick Reference dependency list, multi-model review artifacts and dispositions
|
|
69
|
+
- **Triggers for update**: PRD requirements changed (new integrations needed),
|
|
70
|
+
user requests technology swap, security vulnerability in a dependency,
|
|
71
|
+
new PRD features require capabilities not covered by current stack
|
|
72
|
+
- **Conflict resolution**: if a new requirement conflicts with an existing
|
|
73
|
+
technology choice, document the conflict and propose alternatives with
|
|
74
|
+
migration cost — never silently swap a technology
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: add-e2e-testing
|
|
3
|
+
description: Configure end-to-end testing (Playwright for web, Maestro for mobile) based on detected project platform
|
|
4
|
+
phase: "integration"
|
|
5
|
+
order: 410
|
|
6
|
+
dependencies: [git-workflow, tdd]
|
|
7
|
+
outputs: [tests/screenshots/, maestro/]
|
|
8
|
+
reads: [tdd, coding-standards]
|
|
9
|
+
conditional: "if-needed"
|
|
10
|
+
knowledge-base: [testing-strategy]
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Purpose
|
|
14
|
+
Automatically detects project platform type from tech-stack.md and package.json
|
|
15
|
+
to determine which E2E framework(s) to configure. Configures Playwright for web
|
|
16
|
+
frontends, Maestro for mobile/Expo apps, or both for multi-platform projects.
|
|
17
|
+
Self-skips for backend-only or library projects with no UI.
|
|
18
|
+
|
|
19
|
+
## Inputs
|
|
20
|
+
- docs/tech-stack.md (required) — frontend framework and rendering approach
|
|
21
|
+
- docs/tdd-standards.md (required) — E2E placeholder section to fill
|
|
22
|
+
- docs/coding-standards.md (required for mobile) — testID conventions to add
|
|
23
|
+
- CLAUDE.md (required) — browser/mobile testing section to add
|
|
24
|
+
- package.json (read-only) — dependency detection for platform and brownfield signals
|
|
25
|
+
- docs/user-stories.md (optional) — key user flows for visual verification
|
|
26
|
+
|
|
27
|
+
## Expected Outputs
|
|
28
|
+
Outputs vary by detected platform:
|
|
29
|
+
- (web) Playwright config file, tests/screenshots/ directories, CLAUDE.md and
|
|
30
|
+
tdd-standards.md browser testing sections
|
|
31
|
+
- (mobile) maestro/ directory with config, flows, shared sub-flows, screenshots,
|
|
32
|
+
package.json test scripts, coding-standards.md testID conventions, CLAUDE.md
|
|
33
|
+
and tdd-standards.md mobile testing sections
|
|
34
|
+
- (both) All of the above
|
|
35
|
+
|
|
36
|
+
## Quality Criteria
|
|
37
|
+
- Platform detection is explicit and logged (web, mobile, both, or skip)
|
|
38
|
+
- (web) Playwright config uses framework-specific dev server command and port
|
|
39
|
+
- (web) Smoke test passes (navigate, screenshot, close)
|
|
40
|
+
- (mobile) Maestro CLI installed, sample flow executes, screenshot captured
|
|
41
|
+
- (mobile) testID naming convention defined and documented
|
|
42
|
+
- E2E section in tdd-standards.md distinguishes when to use E2E vs unit tests
|
|
43
|
+
- Baseline screenshots committed, current screenshots gitignored
|
|
44
|
+
|
|
45
|
+
## Methodology Scaling
|
|
46
|
+
- **deep**: Full setup for all detected platforms. All visual testing patterns,
|
|
47
|
+
baseline management, responsive verification, CI integration, sub-flows for
|
|
48
|
+
common journeys, and comprehensive documentation updates.
|
|
49
|
+
- **mvp**: Basic config and smoke test for detected platform. Minimal docs
|
|
50
|
+
updates. Two viewports for web, single platform for mobile.
|
|
51
|
+
- **custom:depth(1-5)**: Depth 1-2: config + smoke test. Depth 3: add patterns,
|
|
52
|
+
naming, testID rules. Depth 4: add CI integration, both mobile platforms.
|
|
53
|
+
Depth 5: full suite with baseline management and sub-flows.
|
|
54
|
+
|
|
55
|
+
## Conditional Evaluation
|
|
56
|
+
Enable when: tech-stack.md indicates a web frontend (Playwright) or mobile app
|
|
57
|
+
(Maestro). Detection signals: React/Vue/Angular/Svelte in tech-stack (web),
|
|
58
|
+
Expo/React Native (mobile), or explicit UI layer in architecture. Self-skips for
|
|
59
|
+
backend-only or library projects with no UI.
|
|
60
|
+
|
|
61
|
+
## Mode Detection
|
|
62
|
+
Check for existing E2E config: Playwright config file (playwright.config.ts or
|
|
63
|
+
.js) and/or maestro/ directory. If either exists, run in update mode for that
|
|
64
|
+
platform. Preserve baseline screenshots, custom viewports, existing flows,
|
|
65
|
+
and environment variables.
|