mustflow 2.107.1 → 2.107.9
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 +6 -1
- package/dist/cli/commands/init.js +49 -1
- package/dist/cli/commands/run/execution.js +7 -0
- package/dist/cli/commands/run/executor.js +7 -0
- package/dist/cli/commands/verify.js +14 -0
- package/dist/cli/commands/workspace.js +106 -16
- package/dist/cli/i18n/en.js +6 -1
- package/dist/cli/i18n/es.js +6 -1
- package/dist/cli/i18n/fr.js +6 -1
- package/dist/cli/i18n/hi.js +6 -1
- package/dist/cli/i18n/ko.js +6 -1
- package/dist/cli/i18n/zh.js +6 -1
- package/dist/cli/index.js +8 -0
- package/dist/cli/lib/agent-context.js +7 -0
- package/dist/cli/lib/repo-map.js +14 -0
- package/dist/cli/lib/run-plan.js +7 -0
- package/dist/core/change-verification.js +7 -0
- package/dist/core/verification-scheduler.js +7 -0
- package/package.json +1 -1
- package/schemas/README.md +3 -3
- package/schemas/workspace-status.schema.json +4 -2
- package/templates/default/common/.mustflow/config/mustflow.toml +3 -3
- package/templates/default/i18n.toml +19 -1
- package/templates/default/locales/en/.mustflow/docs/agent-workflow.md +4 -3
- package/templates/default/locales/en/.mustflow/skills/INDEX.md +11 -0
- package/templates/default/locales/en/.mustflow/skills/cli-option-contract-review/SKILL.md +147 -0
- package/templates/default/locales/en/.mustflow/skills/routes.toml +18 -0
- package/templates/default/locales/en/.mustflow/skills/third-party-api-integration-review/SKILL.md +188 -0
- package/templates/default/locales/en/.mustflow/skills/website-task-friction-review/SKILL.md +139 -0
- package/templates/default/manifest.toml +18 -1
package/templates/default/locales/en/.mustflow/skills/third-party-api-integration-review/SKILL.md
ADDED
|
@@ -0,0 +1,188 @@
|
|
|
1
|
+
---
|
|
2
|
+
mustflow_doc: skill.third-party-api-integration-review
|
|
3
|
+
locale: en
|
|
4
|
+
canonical: true
|
|
5
|
+
revision: 1
|
|
6
|
+
lifecycle: mustflow-owned
|
|
7
|
+
authority: procedure
|
|
8
|
+
name: third-party-api-integration-review
|
|
9
|
+
description: Apply this skill when integrating, reviewing, debugging, or upgrading a third-party SDK or external API service, including authentication, scopes, sandbox versus production behavior, request timeouts, retries, rate limits, idempotency, pagination, webhooks, SDK/API drift, provider error mapping, changelogs, deprecations, migration guides, observability, or production-readiness tests.
|
|
10
|
+
metadata:
|
|
11
|
+
mustflow_schema: "1"
|
|
12
|
+
mustflow_kind: procedure
|
|
13
|
+
pack_id: mustflow.core
|
|
14
|
+
skill_id: mustflow.core.third-party-api-integration-review
|
|
15
|
+
command_intents:
|
|
16
|
+
- changes_status
|
|
17
|
+
- changes_diff_summary
|
|
18
|
+
- lint
|
|
19
|
+
- build
|
|
20
|
+
- test_related
|
|
21
|
+
- test
|
|
22
|
+
- test_audit
|
|
23
|
+
- docs_validate_fast
|
|
24
|
+
- test_release
|
|
25
|
+
- mustflow_check
|
|
26
|
+
---
|
|
27
|
+
|
|
28
|
+
# Third-Party API Integration Review
|
|
29
|
+
|
|
30
|
+
<!-- mustflow-section: purpose -->
|
|
31
|
+
## Purpose
|
|
32
|
+
|
|
33
|
+
Make third-party SDK and API integrations production-safe instead of merely making the first demo call succeed.
|
|
34
|
+
|
|
35
|
+
Developers usually suffer when provider complexity is pushed into the consuming product: unclear auth scopes, stale docs, SDK/API mismatch, opaque errors, rate limits, unsafe retries, duplicate webhooks, undocumented version drift, and missing recovery evidence. This skill turns those failure paths into explicit design and test requirements.
|
|
36
|
+
|
|
37
|
+
<!-- mustflow-section: use-when -->
|
|
38
|
+
## Use When
|
|
39
|
+
|
|
40
|
+
- A product calls, wraps, replaces, upgrades, or removes a third-party SDK, external REST/GraphQL/RPC API, hosted auth provider, payment provider, messaging provider, storage provider, analytics provider, AI provider, search provider, CRM, email/SMS/push provider, geocoding provider, or SaaS integration.
|
|
41
|
+
- Code handles provider authentication, authorization scopes, refresh tokens, tenant or organization ids, sandbox/production environments, API keys, service accounts, or webhook signing secrets.
|
|
42
|
+
- Code implements or reviews provider request timeouts, retry policy, rate-limit handling, pagination, idempotency keys, webhook event handling, provider error mapping, request ids, logs, metrics, traces, or dead-letter/replay behavior.
|
|
43
|
+
- A provider SDK version, API version, changelog, migration guide, deprecation notice, webhook payload, response shape, error shape, pagination model, or rate-limit policy changes.
|
|
44
|
+
- Integration tests, fakes, fixtures, docs, runbooks, or recovery tools must prove the integration handles unhappy paths.
|
|
45
|
+
|
|
46
|
+
<!-- mustflow-section: do-not-use-when -->
|
|
47
|
+
## Do Not Use When
|
|
48
|
+
|
|
49
|
+
- The API is owned by the same repository or organization and the task is primarily public contract design; use `api-contract-change`, `api-misuse-resistance-review`, or `http-api-semantics-review`.
|
|
50
|
+
- The only question is where to place the provider boundary or how to hide provider types from core logic; use `adapter-boundary` first, then return here for provider operational behavior.
|
|
51
|
+
- The task is only a rate-limit implementation, retry loop, idempotency mechanism, queue consumer, or payment ledger change with no third-party provider integration; use the narrower integrity skill.
|
|
52
|
+
- The task is a one-off local script that is not production, repeated, automated, or connected to customer, money, entitlement, privacy, or operational state.
|
|
53
|
+
|
|
54
|
+
<!-- mustflow-section: required-inputs -->
|
|
55
|
+
## Required Inputs
|
|
56
|
+
|
|
57
|
+
- Provider name, SDK package and version, API version, environment, endpoint or event names, and whether the integration is inbound, outbound, or both.
|
|
58
|
+
- Source-of-truth ledger: provider reference docs, OpenAPI or schema files, SDK docs, changelog, migration guide, status page or incident notes when relevant, and local wrapper or adapter patterns.
|
|
59
|
+
- Auth ledger: credential source, secret storage boundary, auth flow, token lifetime, refresh behavior, scopes, tenant or organization binding, sandbox/production separation, and failure behavior for 401 versus 403.
|
|
60
|
+
- Operation ledger: reads, writes, mutating operations, money or entitlement effects, external side effects, pagination model, idempotency support, rate limits, retryability, unknown-outcome recovery, and rollback or reconciliation path.
|
|
61
|
+
- Webhook ledger when inbound events exist: signature verification, raw-body requirement, event id, duplicate policy, ordering assumptions, retry behavior, ack timing, async processing, replay tooling, and retention.
|
|
62
|
+
- Error and observability ledger: provider error codes, HTTP statuses, request id, retry-after or reset headers, local error taxonomy, redaction policy, logs, metrics, traces, alerts, and support diagnostics.
|
|
63
|
+
- Existing tests, fakes, sandbox credentials policy, fixtures, runbooks, and command-intent entries for verification.
|
|
64
|
+
|
|
65
|
+
<!-- mustflow-section: preconditions -->
|
|
66
|
+
## Preconditions
|
|
67
|
+
|
|
68
|
+
- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
|
|
69
|
+
- Secrets, credentials, tokens, webhook secrets, customer payloads, and provider console output are treated as sensitive. Do not copy them into code, fixtures, docs, logs, test output, or final reports.
|
|
70
|
+
- If provider docs and SDK behavior disagree, record the mismatch and choose an explicit compatibility path instead of guessing.
|
|
71
|
+
- If the provider operation can cause money movement, entitlement changes, customer communication, irreversible mutation, or external side effects, classify unknown outcomes before adding retries.
|
|
72
|
+
- If the provider boundary would leak provider SDK objects, raw provider ids, private URLs, or dashboard-only truth into core logic, use `adapter-boundary` for that boundary before implementing production behavior.
|
|
73
|
+
|
|
74
|
+
<!-- mustflow-section: allowed-edits -->
|
|
75
|
+
## Allowed Edits
|
|
76
|
+
|
|
77
|
+
- Add or update provider adapters, wrappers, clients, request/response mappers, error mappers, webhook handlers, fakes, fixtures, sandbox tests, contract tests, runbooks, and docs directly tied to the integration.
|
|
78
|
+
- Add explicit timeout, retry, backoff, jitter, rate-limit, idempotency, pagination, webhook dedupe, observability, and redaction behavior when the repository already supports the required primitives or the change can stay local.
|
|
79
|
+
- Add typed local errors and provider result models that preserve request id, retryability, support evidence, and safe diagnostic detail.
|
|
80
|
+
- Do not hardcode credentials, broaden provider scopes, introduce a new runtime dependency, enable live production calls, or change provider dashboard settings without explicit approval and command authority.
|
|
81
|
+
- Do not implement infinite retries, retry permanent errors, generate a new idempotency key for every retry of the same logical operation, trust webhook payloads before signature verification, or treat success-page redirects as proof of provider completion.
|
|
82
|
+
|
|
83
|
+
<!-- mustflow-section: procedure -->
|
|
84
|
+
## Procedure
|
|
85
|
+
|
|
86
|
+
1. Classify the integration surface.
|
|
87
|
+
- Outbound: SDK or API call made by the product.
|
|
88
|
+
- Inbound: webhook, callback, redirect, polling response, or provider event consumed by the product.
|
|
89
|
+
- Bidirectional: outbound request plus later webhook or callback that confirms, rejects, or updates the same operation.
|
|
90
|
+
2. Establish source of truth before coding. Prefer current provider API reference or schema for wire shape, provider changelog or migration guide for version behavior, local wrapper patterns for code placement, and tests for repository expectations. Treat blog posts, examples, AI output, and stale snippets as hints only.
|
|
91
|
+
3. Choose SDK versus raw API explicitly.
|
|
92
|
+
- Prefer the official SDK only when it supports the needed endpoint, runtime, auth method, timeout control, retry control, pagination, idempotency, error access, and request id access.
|
|
93
|
+
- Use raw API only when the SDK lacks coverage or blocks a production requirement, and then provide typed local request/response models, timeout, retry policy, pagination, error mapping, and tests.
|
|
94
|
+
- Do not let SDK convenience hide auth scopes, retries, idempotency, pagination, or error taxonomy.
|
|
95
|
+
4. Build the auth and environment contract.
|
|
96
|
+
- Separate sandbox from production credentials.
|
|
97
|
+
- Load credentials from approved secret surfaces.
|
|
98
|
+
- Bind tokens or API keys to tenant, organization, account, or environment when applicable.
|
|
99
|
+
- Validate required scopes before business logic.
|
|
100
|
+
- Distinguish authentication failure from authorization or scope failure.
|
|
101
|
+
- Handle token expiration and refresh without logging token values.
|
|
102
|
+
5. Classify every operation before adding retry behavior.
|
|
103
|
+
- Reads may be retried when timeout and retry budget are bounded.
|
|
104
|
+
- Mutating requests need a stable idempotency key or another documented duplicate-safety mechanism before retry.
|
|
105
|
+
- Unknown outcomes after timeout or connection loss must trigger provider lookup, reconciliation, or manual recovery instead of blind replay.
|
|
106
|
+
- Validation, authentication, authorization, missing-resource, malformed-request, and domain-rejection errors are not transient.
|
|
107
|
+
6. Implement request safety.
|
|
108
|
+
- Set explicit per-attempt timeout and total attempt budget.
|
|
109
|
+
- Respect documented rate-limit headers, reset times, and retry-after hints.
|
|
110
|
+
- Use exponential backoff with jitter for transient failures.
|
|
111
|
+
- Bound concurrency when provider capacity can starve local work.
|
|
112
|
+
- Use documented pagination cursors, iterators, or link headers; do not invent next-page URLs or assume stable offset pagination unless the provider promises it.
|
|
113
|
+
7. Implement provider error mapping.
|
|
114
|
+
- Map provider status, code, message, field errors, request id, retryability, and endpoint into local typed errors.
|
|
115
|
+
- Preserve enough detail for support without logging secrets, full customer payloads, raw tokens, or payment data.
|
|
116
|
+
- Make rate-limit, auth, validation, provider outage, timeout, and unknown-outcome errors distinguishable to callers.
|
|
117
|
+
- Keep provider error classes and SDK response objects out of core logic.
|
|
118
|
+
8. Implement webhook and callback safety when events exist.
|
|
119
|
+
- Verify signature using the raw body when the provider requires it.
|
|
120
|
+
- Acknowledge quickly and move expensive work to an internal queue or use case when possible.
|
|
121
|
+
- Store event id or delivery id before side effects.
|
|
122
|
+
- Deduplicate repeated events and return safe success for already-processed duplicates.
|
|
123
|
+
- Do not assume events arrive once, in order, immediately, or only after the user-facing redirect.
|
|
124
|
+
- Make handlers idempotent and add replay or dead-letter handling when failures need recovery.
|
|
125
|
+
9. Handle SDK/API version drift.
|
|
126
|
+
- Check changelog and migration guide before SDK or API version upgrades.
|
|
127
|
+
- Identify breaking changes in auth, endpoint paths, request fields, response fields, error shape, pagination, rate limits, idempotency, webhook payloads, and retry behavior.
|
|
128
|
+
- Keep old and new behavior side by side when migration risk is high.
|
|
129
|
+
- Add compatibility tests before replacing production behavior.
|
|
130
|
+
10. Add observability that helps support without leaking data.
|
|
131
|
+
- Record local operation id, provider request id, endpoint or event name, retry attempt count, final provider status category, retry-after timing, idempotency key hash or local operation id, and redacted error code.
|
|
132
|
+
- Add metrics or logs for rate-limit hits, retries exhausted, webhook duplicates, invalid signatures, unknown outcomes, SDK version, and migration path when local patterns support them.
|
|
133
|
+
- Avoid raw provider payload dumps in logs and fixtures.
|
|
134
|
+
11. Test failure paths, not only the first successful call.
|
|
135
|
+
- Cover auth failure, scope failure, validation failure, timeout, transient 5xx, rate limit, retry exhaustion, idempotent duplicate request, pagination continuation, SDK error mapping, webhook invalid signature, webhook duplicate event, webhook out-of-order event when relevant, and version-upgrade fixture compatibility.
|
|
136
|
+
- Prefer fakes or sandbox tests unless the repository has explicit live-provider test authority.
|
|
137
|
+
- Do not mark the integration complete when only the happy path is tested.
|
|
138
|
+
12. Report provider ambiguity honestly. Name undocumented behavior, doc/SDK mismatch, skipped live checks, missing sandbox evidence, manual console steps, missing idempotency support, missing webhook replay tooling, and remaining operational risk.
|
|
139
|
+
|
|
140
|
+
<!-- mustflow-section: postconditions -->
|
|
141
|
+
## Postconditions
|
|
142
|
+
|
|
143
|
+
- The integration has explicit auth, environment, timeout, retry, rate-limit, idempotency, pagination, webhook, error, observability, version, and test decisions.
|
|
144
|
+
- Provider-specific behavior is contained at the integration boundary or explicitly classified as a public contract.
|
|
145
|
+
- Failure paths and recovery states are tested, faked, documented, or reported as missing evidence.
|
|
146
|
+
- Secrets and sensitive provider data are not copied into code, fixtures, logs, docs, or reports.
|
|
147
|
+
|
|
148
|
+
<!-- mustflow-section: verification -->
|
|
149
|
+
## Verification
|
|
150
|
+
|
|
151
|
+
Use configured oneshot command intents when available:
|
|
152
|
+
|
|
153
|
+
- `changes_status`
|
|
154
|
+
- `changes_diff_summary`
|
|
155
|
+
- `lint`
|
|
156
|
+
- `build`
|
|
157
|
+
- `test_related`
|
|
158
|
+
- `test`
|
|
159
|
+
- `test_audit`
|
|
160
|
+
- `docs_validate_fast`
|
|
161
|
+
- `test_release`
|
|
162
|
+
- `mustflow_check`
|
|
163
|
+
|
|
164
|
+
Use the narrowest configured tests that cover the changed provider adapter, webhook handler, error mapping, retry behavior, idempotency behavior, SDK version migration, and docs or template surfaces touched.
|
|
165
|
+
|
|
166
|
+
<!-- mustflow-section: failure-handling -->
|
|
167
|
+
## Failure Handling
|
|
168
|
+
|
|
169
|
+
- If provider docs are missing or contradictory, stop relying on inferred behavior and report the mismatch with the safest local fallback.
|
|
170
|
+
- If mutating operations lack idempotency support, avoid automatic retry and require reconciliation or manual recovery for unknown outcomes.
|
|
171
|
+
- If webhook signatures cannot be verified with current framework parsing, fix the raw-body handling before trusting the event.
|
|
172
|
+
- If tests would require live production credentials, skip them and report the missing configured sandbox or fake instead of using real credentials.
|
|
173
|
+
- If SDK retry behavior is implicit or unconfigurable, wrap or disable it when local retry budgets must be enforced.
|
|
174
|
+
- If a provider dashboard setting is required, document it as manual or config-owned evidence; do not claim code alone enforces it.
|
|
175
|
+
|
|
176
|
+
<!-- mustflow-section: output-format -->
|
|
177
|
+
## Output Format
|
|
178
|
+
|
|
179
|
+
- Third-party provider and SDK/API surface reviewed
|
|
180
|
+
- Source-of-truth docs, SDK version, changelog, and migration evidence checked
|
|
181
|
+
- Auth, environment, scope, and secret boundary decisions
|
|
182
|
+
- Timeout, retry, rate-limit, idempotency, pagination, and unknown-outcome decisions
|
|
183
|
+
- Webhook or callback delivery, signature, dedupe, ordering, and replay decisions
|
|
184
|
+
- Error mapping, observability, redaction, and support diagnostics
|
|
185
|
+
- Tests added, reused, skipped, or missing for happy and unhappy paths
|
|
186
|
+
- Command intents run
|
|
187
|
+
- Skipped checks and reasons
|
|
188
|
+
- Remaining provider, SDK drift, documentation, sandbox, or operational risk
|
|
@@ -0,0 +1,139 @@
|
|
|
1
|
+
---
|
|
2
|
+
mustflow_doc: skill.website-task-friction-review
|
|
3
|
+
locale: en
|
|
4
|
+
canonical: true
|
|
5
|
+
revision: 1
|
|
6
|
+
lifecycle: mustflow-owned
|
|
7
|
+
authority: procedure
|
|
8
|
+
name: website-task-friction-review
|
|
9
|
+
description: Apply this skill when a public website, landing page, marketing page, ecommerce flow, signup flow, checkout flow, account page, support surface, navigation, search, form, mobile web surface, cookie or consent surface, pricing page, or conversion path is planned, edited, reviewed, or reported and common user complaints such as slowness, popups, forced signup, confusing navigation, broken mobile layout, unclear errors, hidden costs, dark patterns, weak trust, or missing recovery paths must be prevented.
|
|
10
|
+
metadata:
|
|
11
|
+
mustflow_schema: "1"
|
|
12
|
+
mustflow_kind: procedure
|
|
13
|
+
pack_id: mustflow.core
|
|
14
|
+
skill_id: mustflow.core.website-task-friction-review
|
|
15
|
+
command_intents:
|
|
16
|
+
- changes_status
|
|
17
|
+
- changes_diff_summary
|
|
18
|
+
- docs_validate_fast
|
|
19
|
+
- test_release
|
|
20
|
+
- mustflow_check
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
# Website Task Friction Review
|
|
24
|
+
|
|
25
|
+
<!-- mustflow-section: purpose -->
|
|
26
|
+
## Purpose
|
|
27
|
+
|
|
28
|
+
Prevent website changes from blocking the user's intended task. Review the site by whether a real visitor can find, understand, decide, enter information, recover from errors, trust the service, and complete the action without surprise or coercion.
|
|
29
|
+
|
|
30
|
+
<!-- mustflow-section: use-when -->
|
|
31
|
+
## Use When
|
|
32
|
+
|
|
33
|
+
- A change touches a public website, landing page, ecommerce page, product page, pricing page, signup flow, checkout flow, account flow, support page, help center, contact path, search path, cookie or consent surface, promotional overlay, or mobile web experience.
|
|
34
|
+
- A task asks for website UX review, conversion review, landing-page polish, navigation improvement, form or checkout improvement, mobile usability, trust signals, dark-pattern removal, or complaint prevention.
|
|
35
|
+
- A report claims a website is usable, fast, clear, trustworthy, accessible, mobile-ready, conversion-ready, or ready to ship.
|
|
36
|
+
- A UI change could add friction through overlays, forced account creation, hidden fees, vague copy, long forms, weak error recovery, hard-to-find support, inaccessible controls, or slow first interaction.
|
|
37
|
+
|
|
38
|
+
<!-- mustflow-section: do-not-use-when -->
|
|
39
|
+
## Do Not Use When
|
|
40
|
+
|
|
41
|
+
- The task changes only backend internals, CLI output, data processing, or documentation with no public website or user task path.
|
|
42
|
+
- The task is only visual component geometry, hostile content, responsive container behavior, or layout stress; use `frontend-stress-layout-review` for that focused layer.
|
|
43
|
+
- The task is only accessibility-tree semantics, keyboard behavior, focus, ARIA, labels, or assistive-technology evidence; use `frontend-accessibility-tree-review` for that focused layer.
|
|
44
|
+
- The task is only first-render performance, Core Web Vitals field instrumentation, image delivery, bundle size, or frame rendering; use the narrower performance skill for that focused layer.
|
|
45
|
+
- The task is an internal dashboard or app UI with no public website, acquisition, support, signup, checkout, or visitor conversion path; use `ui-quality-gate`.
|
|
46
|
+
|
|
47
|
+
<!-- mustflow-section: required-inputs -->
|
|
48
|
+
## Required Inputs
|
|
49
|
+
|
|
50
|
+
- The primary visitor task, target audience, entry point, and expected completion point.
|
|
51
|
+
- The changed route, page, component, copy, form, navigation, search, checkout, support, consent, or conversion surface.
|
|
52
|
+
- Existing product constraints, legal requirements, pricing, account requirements, support policy, privacy boundary, and trust or compliance claims relevant to the flow.
|
|
53
|
+
- The likely devices and input modes, especially small-screen touch use, keyboard use, slow networks, logged-out users, new users, returning users, and users with incomplete information.
|
|
54
|
+
- Current evidence from code, tests, screenshots, analytics, complaints, support tickets, field metrics, or product requirements when available.
|
|
55
|
+
- Relevant command-intent contract entries for status, diff, docs, build, test, release, visual, browser, accessibility, or mustflow validation.
|
|
56
|
+
|
|
57
|
+
<!-- mustflow-section: preconditions -->
|
|
58
|
+
## Preconditions
|
|
59
|
+
|
|
60
|
+
- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
|
|
61
|
+
- The primary user task can be named. If it cannot, stop and ask for or infer the smallest plausible task from repository evidence, then report the uncertainty.
|
|
62
|
+
- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
|
|
63
|
+
|
|
64
|
+
<!-- mustflow-section: allowed-edits -->
|
|
65
|
+
## Allowed Edits
|
|
66
|
+
|
|
67
|
+
- Change website copy, navigation labels, page order, form fields, validation, error states, mobile layout, support links, trust disclosures, pricing visibility, consent behavior, and recovery paths when they directly reduce task friction.
|
|
68
|
+
- Remove or defer overlays, decorative content, forced account gates, vague marketing blocks, nonessential form fields, misleading urgency, and interruptions that do not help the current task.
|
|
69
|
+
- Add focused tests, fixtures, docs, or template updates that preserve the website task contract.
|
|
70
|
+
- Do not invent pricing, policy, compliance, delivery, guarantee, refund, legal, or support claims.
|
|
71
|
+
- Do not add dark patterns, hidden costs, coerced consent, preselected paid add-ons, fake urgency, nagging opt-ins, or visually weakened rejection controls.
|
|
72
|
+
- Do not claim visual, mobile, accessibility, performance, or interactive verification without actual evidence or a named verification gap.
|
|
73
|
+
|
|
74
|
+
<!-- mustflow-section: procedure -->
|
|
75
|
+
## Procedure
|
|
76
|
+
|
|
77
|
+
1. Name the primary visitor task in plain language. Use the user's words, not the company's internal taxonomy.
|
|
78
|
+
2. Walk the task from entry to completion: arrive, orient, find, compare, decide, enter information, submit or pay, recover from failure, and get help.
|
|
79
|
+
3. Identify the first blocking point. Treat a delay, forced decision, hidden requirement, unclear label, missing price, broken mobile control, or vague error as a product defect, not a cosmetic nit.
|
|
80
|
+
4. Check interruption pressure. Avoid first-task-blocking newsletter modals, app-install prompts, surveys, promotional overlays, cookie banners beyond legal need, chat widgets covering controls, and upsells that block completion.
|
|
81
|
+
5. Check account pressure. Do not force account creation before checkout, booking, inquiry, download, trial, or support unless the product cannot function without an account. Offer guest, passkey, magic-link, or deferred-account paths when the business rules allow them.
|
|
82
|
+
6. Check cost and commitment clarity. Show total price, taxes, shipping, fees, renewal terms, cancellation terms, delivery estimates, refund rules, and required commitments before the user reaches the final commit action.
|
|
83
|
+
7. Check navigation and search. Labels should match user vocabulary, sibling categories should be distinguishable, search should be discoverable on content-heavy sites, and no-results states should offer spelling help, related links, popular paths, or a way back to browsing.
|
|
84
|
+
8. Check mobile task completion. Core tasks must work on small screens without zooming, hover, tiny targets, horizontal scrolling, covered bottom actions, keyboard-covered inputs, or sticky elements hiding validation messages.
|
|
85
|
+
9. Check form load. Every field must earn its place for the current task. Use labels, input types, autocomplete, examples, sane defaults, grouped fields, inline recovery, preserved entered data, and field-level errors.
|
|
86
|
+
10. Check error language. Replace developer-centered messages with what happened, which field or action needs attention, how to fix it, and whether the user's entered data or payment state is safe.
|
|
87
|
+
11. Check trust and proof. Make operator identity, contact, support, security, privacy, returns, cancellation, unsubscribe, delete-account, and policy paths findable where users expect them. Do not bury trust-critical information behind marketing copy.
|
|
88
|
+
12. Check content for scanning. Put the next decision near the top, use concrete headings, remove vague claims, shorten paragraphs, and expose requirements, limits, risk, price, and next steps before asking for commitment.
|
|
89
|
+
13. Check accessibility as task completion. Keyboard-only users, screen-reader users, zoomed users, users with reduced motion, and users who cannot rely on color should complete the same task with visible focus, labels, error associations, contrast, target size, and no focus traps.
|
|
90
|
+
14. Check performance from the user's patience budget. Prefer evidence for Core Web Vitals, responsive first interaction, stable layout, reserved media dimensions, bounded third-party scripts, and no render-blocking decorative assets.
|
|
91
|
+
15. Check recovery and support. Users should have a next useful action after search failure, validation failure, payment failure, permission denial, empty state, unavailable inventory, timeout, expired session, or partial submission.
|
|
92
|
+
16. Check coercion and dark patterns. Remove hidden opt-outs, fake urgency, confirmshaming, cancellation mazes, prechecked add-ons, subscription traps, unclear consent, and asymmetric accept or reject controls.
|
|
93
|
+
17. If the issue belongs to a narrower skill, route the focused fix there after naming the website-level friction. Examples: Core Web Vitals, image delivery, bundle pruning, accessibility tree, layout stress, localization, payment integrity, or support-surface selection.
|
|
94
|
+
18. For implemented fixes, preserve existing style, component, data, policy, and localization patterns. Do not add a one-off UX framework or dependency for a flow-level problem.
|
|
95
|
+
19. Use the narrowest configured verification that covers the changed website, docs, package, template, or mustflow contract.
|
|
96
|
+
|
|
97
|
+
<!-- mustflow-section: postconditions -->
|
|
98
|
+
## Postconditions
|
|
99
|
+
|
|
100
|
+
- The primary visitor task is named and can be followed without unnecessary interruption.
|
|
101
|
+
- Navigation, search, mobile use, forms, errors, accessibility, performance, trust, cost clarity, account pressure, support, and recovery paths are checked or explicitly reported as unverified.
|
|
102
|
+
- Any dark pattern, hidden commitment, invented claim, or support-policy uncertainty is removed, deferred, or reported.
|
|
103
|
+
- Focused follow-up skills are named when a narrower performance, accessibility, layout, payment, support, localization, or security review is still needed.
|
|
104
|
+
|
|
105
|
+
<!-- mustflow-section: verification -->
|
|
106
|
+
## Verification
|
|
107
|
+
|
|
108
|
+
Use configured oneshot command intents when available:
|
|
109
|
+
|
|
110
|
+
- `changes_status`
|
|
111
|
+
- `changes_diff_summary`
|
|
112
|
+
- `docs_validate_fast`
|
|
113
|
+
- `test_release`
|
|
114
|
+
- `mustflow_check`
|
|
115
|
+
|
|
116
|
+
Use a narrower configured build, browser, screenshot, accessibility, performance, or related-test intent when it better proves the changed website task path.
|
|
117
|
+
|
|
118
|
+
<!-- mustflow-section: failure-handling -->
|
|
119
|
+
## Failure Handling
|
|
120
|
+
|
|
121
|
+
- If the primary task is unclear, stop broad polishing and identify the task before editing.
|
|
122
|
+
- If business, legal, pricing, support, or compliance facts are missing, do not invent them; add placeholders only when the repository already uses placeholder policy text and report the unresolved authority.
|
|
123
|
+
- If visual or interactive inspection is unavailable, report the unverified viewport, device, state, and interaction instead of claiming the website is ready.
|
|
124
|
+
- If a stakeholder asks for a friction pattern, such as forced signup or an interrupting popup, implement the least coercive version allowed by direct instructions and report the conversion, trust, support, and regulatory risk.
|
|
125
|
+
- If a fix conflicts with a narrower skill's rule, follow the stricter task-safety or public-contract rule and report the conflict.
|
|
126
|
+
|
|
127
|
+
<!-- mustflow-section: output-format -->
|
|
128
|
+
## Output Format
|
|
129
|
+
|
|
130
|
+
- Website task reviewed
|
|
131
|
+
- Entry point and completion point
|
|
132
|
+
- Friction findings by severity
|
|
133
|
+
- User complaint in the user's likely words
|
|
134
|
+
- Cause, fix, and acceptance test
|
|
135
|
+
- Navigation, search, mobile, form, error, accessibility, performance, trust, pricing, consent, support, and recovery checks
|
|
136
|
+
- Narrower skills used or recommended
|
|
137
|
+
- Command intents run
|
|
138
|
+
- Skipped visual or interactive checks and reasons
|
|
139
|
+
- Remaining website task risk
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
id = "default"
|
|
2
2
|
name = "default"
|
|
3
|
-
version = "2.107.
|
|
3
|
+
version = "2.107.9"
|
|
4
4
|
description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
|
|
5
5
|
common_root = "common"
|
|
6
6
|
locales_root = "locales"
|
|
@@ -32,6 +32,7 @@ creates = [
|
|
|
32
32
|
".mustflow/skills/payment-integrity-review/SKILL.md",
|
|
33
33
|
".mustflow/skills/credit-ledger-integrity-review/SKILL.md",
|
|
34
34
|
".mustflow/skills/api-misuse-resistance-review/SKILL.md",
|
|
35
|
+
".mustflow/skills/third-party-api-integration-review/SKILL.md",
|
|
35
36
|
".mustflow/skills/api-access-control-review/SKILL.md",
|
|
36
37
|
".mustflow/skills/file-upload-security-review/SKILL.md",
|
|
37
38
|
".mustflow/skills/error-message-integrity-review/SKILL.md",
|
|
@@ -58,6 +59,7 @@ creates = [
|
|
|
58
59
|
".mustflow/skills/frontend-stress-layout-review/SKILL.md",
|
|
59
60
|
".mustflow/skills/frontend-accessibility-tree-review/SKILL.md",
|
|
60
61
|
".mustflow/skills/frontend-localization-review/SKILL.md",
|
|
62
|
+
".mustflow/skills/website-task-friction-review/SKILL.md",
|
|
61
63
|
".mustflow/skills/cache-integrity-review/SKILL.md",
|
|
62
64
|
".mustflow/skills/quadratic-scan-review/SKILL.md",
|
|
63
65
|
".mustflow/skills/type-state-modeling-review/SKILL.md",
|
|
@@ -117,6 +119,7 @@ creates = [
|
|
|
117
119
|
".mustflow/skills/wails-code-change/SKILL.md",
|
|
118
120
|
".mustflow/skills/typescript-code-change/SKILL.md",
|
|
119
121
|
".mustflow/skills/unocss-code-change/SKILL.md",
|
|
122
|
+
".mustflow/skills/cli-option-contract-review/SKILL.md",
|
|
120
123
|
".mustflow/skills/cli-output-contract-review/SKILL.md",
|
|
121
124
|
".mustflow/skills/command-contract-authoring/SKILL.md",
|
|
122
125
|
".mustflow/skills/config-env-change/SKILL.md",
|
|
@@ -249,6 +252,7 @@ minimal = [
|
|
|
249
252
|
"payment-integrity-review",
|
|
250
253
|
"credit-ledger-integrity-review",
|
|
251
254
|
"api-misuse-resistance-review",
|
|
255
|
+
"third-party-api-integration-review",
|
|
252
256
|
"api-access-control-review",
|
|
253
257
|
"file-upload-security-review",
|
|
254
258
|
"error-message-integrity-review",
|
|
@@ -275,6 +279,7 @@ minimal = [
|
|
|
275
279
|
"frontend-stress-layout-review",
|
|
276
280
|
"frontend-accessibility-tree-review",
|
|
277
281
|
"frontend-localization-review",
|
|
282
|
+
"website-task-friction-review",
|
|
278
283
|
"cache-integrity-review",
|
|
279
284
|
"quadratic-scan-review",
|
|
280
285
|
"type-state-modeling-review",
|
|
@@ -404,6 +409,7 @@ patterns = [
|
|
|
404
409
|
"payment-integrity-review",
|
|
405
410
|
"credit-ledger-integrity-review",
|
|
406
411
|
"api-misuse-resistance-review",
|
|
412
|
+
"third-party-api-integration-review",
|
|
407
413
|
"api-access-control-review",
|
|
408
414
|
"file-upload-security-review",
|
|
409
415
|
"error-message-integrity-review",
|
|
@@ -430,6 +436,7 @@ patterns = [
|
|
|
430
436
|
"frontend-stress-layout-review",
|
|
431
437
|
"frontend-accessibility-tree-review",
|
|
432
438
|
"frontend-localization-review",
|
|
439
|
+
"website-task-friction-review",
|
|
433
440
|
"cache-integrity-review",
|
|
434
441
|
"quadratic-scan-review",
|
|
435
442
|
"type-state-modeling-review",
|
|
@@ -570,6 +577,7 @@ oss = [
|
|
|
570
577
|
"payment-integrity-review",
|
|
571
578
|
"credit-ledger-integrity-review",
|
|
572
579
|
"api-misuse-resistance-review",
|
|
580
|
+
"third-party-api-integration-review",
|
|
573
581
|
"api-access-control-review",
|
|
574
582
|
"file-upload-security-review",
|
|
575
583
|
"error-message-integrity-review",
|
|
@@ -596,6 +604,7 @@ oss = [
|
|
|
596
604
|
"frontend-stress-layout-review",
|
|
597
605
|
"frontend-accessibility-tree-review",
|
|
598
606
|
"frontend-localization-review",
|
|
607
|
+
"website-task-friction-review",
|
|
599
608
|
"cache-integrity-review",
|
|
600
609
|
"quadratic-scan-review",
|
|
601
610
|
"type-state-modeling-review",
|
|
@@ -651,6 +660,7 @@ oss = [
|
|
|
651
660
|
"wails-code-change",
|
|
652
661
|
"typescript-code-change",
|
|
653
662
|
"unocss-code-change",
|
|
663
|
+
"cli-option-contract-review",
|
|
654
664
|
"cli-output-contract-review",
|
|
655
665
|
"command-contract-authoring",
|
|
656
666
|
"command-intent-mapping-gate",
|
|
@@ -752,6 +762,7 @@ team = [
|
|
|
752
762
|
"payment-integrity-review",
|
|
753
763
|
"credit-ledger-integrity-review",
|
|
754
764
|
"api-misuse-resistance-review",
|
|
765
|
+
"third-party-api-integration-review",
|
|
755
766
|
"api-access-control-review",
|
|
756
767
|
"file-upload-security-review",
|
|
757
768
|
"error-message-integrity-review",
|
|
@@ -778,6 +789,7 @@ team = [
|
|
|
778
789
|
"frontend-stress-layout-review",
|
|
779
790
|
"frontend-accessibility-tree-review",
|
|
780
791
|
"frontend-localization-review",
|
|
792
|
+
"website-task-friction-review",
|
|
781
793
|
"cache-integrity-review",
|
|
782
794
|
"quadratic-scan-review",
|
|
783
795
|
"type-state-modeling-review",
|
|
@@ -920,6 +932,7 @@ product = [
|
|
|
920
932
|
"payment-integrity-review",
|
|
921
933
|
"credit-ledger-integrity-review",
|
|
922
934
|
"api-misuse-resistance-review",
|
|
935
|
+
"third-party-api-integration-review",
|
|
923
936
|
"api-access-control-review",
|
|
924
937
|
"file-upload-security-review",
|
|
925
938
|
"error-message-integrity-review",
|
|
@@ -946,6 +959,7 @@ product = [
|
|
|
946
959
|
"frontend-stress-layout-review",
|
|
947
960
|
"frontend-accessibility-tree-review",
|
|
948
961
|
"frontend-localization-review",
|
|
962
|
+
"website-task-friction-review",
|
|
949
963
|
"cache-integrity-review",
|
|
950
964
|
"quadratic-scan-review",
|
|
951
965
|
"type-state-modeling-review",
|
|
@@ -1094,6 +1108,7 @@ library = [
|
|
|
1094
1108
|
"payment-integrity-review",
|
|
1095
1109
|
"credit-ledger-integrity-review",
|
|
1096
1110
|
"api-misuse-resistance-review",
|
|
1111
|
+
"third-party-api-integration-review",
|
|
1097
1112
|
"api-access-control-review",
|
|
1098
1113
|
"file-upload-security-review",
|
|
1099
1114
|
"error-message-integrity-review",
|
|
@@ -1120,6 +1135,7 @@ library = [
|
|
|
1120
1135
|
"frontend-stress-layout-review",
|
|
1121
1136
|
"frontend-accessibility-tree-review",
|
|
1122
1137
|
"frontend-localization-review",
|
|
1138
|
+
"website-task-friction-review",
|
|
1123
1139
|
"cache-integrity-review",
|
|
1124
1140
|
"quadratic-scan-review",
|
|
1125
1141
|
"type-state-modeling-review",
|
|
@@ -1175,6 +1191,7 @@ library = [
|
|
|
1175
1191
|
"wails-code-change",
|
|
1176
1192
|
"typescript-code-change",
|
|
1177
1193
|
"unocss-code-change",
|
|
1194
|
+
"cli-option-contract-review",
|
|
1178
1195
|
"cli-output-contract-review",
|
|
1179
1196
|
"command-contract-authoring",
|
|
1180
1197
|
"command-intent-mapping-gate",
|