@vegastack/skills 0.5.0 → 0.7.0
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 -2
- package/dist/index.js +8 -35
- package/package.json +1 -1
- package/skill/architect/SKILL.md +68 -0
- package/skill/architect/agents/openai.yaml +4 -0
- package/skill/architect/assets/adr-template.md +21 -0
- package/skill/architect/assets/arch-template.md +20 -0
- package/skill/architect/references/advisory.md +102 -0
- package/skill/architect/references/ai-agents.md +95 -0
- package/skill/architect/references/data.md +90 -0
- package/skill/architect/references/infra.md +128 -0
- package/skill/architect/references/mobile.md +78 -0
- package/skill/architect/references/pinned-facts.md +108 -0
- package/skill/architect/references/principles.md +91 -0
- package/skill/architect/references/project-profile.md +37 -0
- package/skill/architect/references/security.md +97 -0
- package/skill/architect/references/stack.md +38 -0
- package/skill/architect/references/web.md +152 -0
- package/skill/architect/refresh/REFRESH.md +29 -0
- package/skill/architect/refresh/sources.json +244 -0
- package/skill/dev-implement/SKILL.md +62 -0
- package/skill/dev-implement/agents/openai.yaml +4 -0
- package/skill/dev-implement/refresh/REFRESH.md +3 -0
- package/skill/dev-implement/refresh/sources.json +6 -0
- package/skill/dev-intake/SKILL.md +62 -0
- package/skill/dev-intake/agents/openai.yaml +4 -0
- package/skill/dev-intake/references/brief-template.md +56 -0
- package/skill/dev-intake/refresh/REFRESH.md +3 -0
- package/skill/dev-intake/refresh/sources.json +6 -0
- package/skill/dev-setup/SKILL.md +65 -0
- package/skill/dev-setup/agents/openai.yaml +4 -0
- package/skill/dev-setup/assets/agents-section.md.template +9 -0
- package/skill/dev-setup/assets/dev-profile.md.template +24 -0
- package/skill/dev-setup/references/harness-facts.md +22 -0
- package/skill/dev-setup/refresh/REFRESH.md +13 -0
- package/skill/dev-setup/refresh/sources.json +152 -0
- package/skill/dev-ship/SKILL.md +33 -0
- package/skill/dev-ship/agents/openai.yaml +4 -0
- package/skill/dev-ship/refresh/REFRESH.md +3 -0
- package/skill/dev-ship/refresh/sources.json +6 -0
- package/skill/skill-maintainer/SKILL.md +9 -10
- package/skill/skill-maintainer/references/release-ops.md +12 -16
- package/skill/skill-maintainer/refresh/REFRESH.md +4 -4
- package/skill/skillify/SKILL.md +38 -48
- package/skill/skillify/assets/templates/REFRESH.md.template +5 -10
- package/skill/skillify/assets/templates/SKILL.md.template +1 -0
- package/skill/skillify/assets/templates/skill.test.ts.template +11 -24
- package/skill/skillify/assets/templates/sources.json.template +1 -1
- package/skill/skillify/assets/templates/trigger-queries.json.template +1 -0
- package/skill/skillify/references/authoring.md +20 -14
- package/skill/skillify/refresh/REFRESH.md +1 -1
- package/skill/skillify/scripts/scaffold-skill.mjs +75 -17
- package/skill-integrity.json +66 -53
- package/skill/arch-guardian/SKILL.md +0 -84
- package/skill/arch-guardian/agents/openai.yaml +0 -4
- package/skill/arch-guardian/assets/adr-template.md +0 -25
- package/skill/arch-guardian/assets/answers-example.json +0 -10
- package/skill/arch-guardian/assets/architecture-profile.json +0 -13
- package/skill/arch-guardian/assets/architecture-profile.schema.json +0 -31
- package/skill/arch-guardian/assets/deployment-review-template.md +0 -24
- package/skill/arch-guardian/assets/service-design-template.md +0 -33
- package/skill/arch-guardian/assets/threat-model-template.md +0 -34
- package/skill/arch-guardian/references/advisory-report.md +0 -65
- package/skill/arch-guardian/references/architecture/agent-product.md +0 -22
- package/skill/arch-guardian/references/architecture/ai-cost.md +0 -24
- package/skill/arch-guardian/references/architecture/ai-data-boundaries.md +0 -21
- package/skill/arch-guardian/references/architecture/ai-evals.md +0 -28
- package/skill/arch-guardian/references/architecture/connectors-sandbox.md +0 -39
- package/skill/arch-guardian/references/architecture/data-memory.md +0 -25
- package/skill/arch-guardian/references/architecture/delivery-operations.md +0 -34
- package/skill/arch-guardian/references/architecture/durable-execution.md +0 -45
- package/skill/arch-guardian/references/architecture/flutter.md +0 -26
- package/skill/arch-guardian/references/architecture/foundation.md +0 -31
- package/skill/arch-guardian/references/architecture/hosting-reliability.md +0 -37
- package/skill/arch-guardian/references/architecture/identity-tenancy.md +0 -37
- package/skill/arch-guardian/references/architecture/model-lifecycle.md +0 -20
- package/skill/arch-guardian/references/architecture/models-observability.md +0 -23
- package/skill/arch-guardian/references/architecture/realtime-channels.md +0 -16
- package/skill/arch-guardian/references/architecture/security-privacy.md +0 -27
- package/skill/arch-guardian/references/architecture/topology-monorepo.md +0 -47
- package/skill/arch-guardian/references/architecture/web.md +0 -29
- package/skill/arch-guardian/references/foundation-compatibility.json +0 -44
- package/skill/arch-guardian/references/golden-patterns.md +0 -43
- package/skill/arch-guardian/references/profile-governance.md +0 -40
- package/skill/arch-guardian/references/rule-model.json +0 -36
- package/skill/arch-guardian/references/workflows.md +0 -48
- package/skill/arch-guardian/refresh/REFRESH.md +0 -47
- package/skill/arch-guardian/refresh/sources.json +0 -1171
- package/skill/arch-guardian/scripts/lib.mjs +0 -48
- package/skill/arch-guardian/scripts/profile-tool.mjs +0 -217
- package/skill/arch-guardian/scripts/refresh-evidence.mjs +0 -366
- package/skill/arch-guardian/scripts/schema-validate.mjs +0 -63
- package/skill/arch-guardian/scripts/validate-profile.mjs +0 -65
- package/skill/arch-guardian/scripts/verify-corpus.mjs +0 -136
|
@@ -0,0 +1,152 @@
|
|
|
1
|
+
# Web — frontend, design system, backend/API taste
|
|
2
|
+
|
|
3
|
+
## Project layout
|
|
4
|
+
|
|
5
|
+
- Top-level `server/` (or `packages/*` server code) holds DB, services, integrations — it
|
|
6
|
+
is sacred: never imported from client code, enforced with `server-only` + a boundary
|
|
7
|
+
check. The app router lives in `src/app/`; features are self-contained modules under
|
|
8
|
+
`src/features/<domain>/` (components/hooks per feature); shared pieces in
|
|
9
|
+
`src/{components,hooks,lib,store,messages}/`. Pages stay thin — they compose features.
|
|
10
|
+
- The house convention scopes agent instructions per directory (a short CLAUDE.md/AGENTS.md
|
|
11
|
+
at each boundary-bearing directory) — follow it where a project already does this.
|
|
12
|
+
|
|
13
|
+
## Frontend architecture
|
|
14
|
+
|
|
15
|
+
- Server state → RSC + TanStack Query; URL state → nuqs; ephemeral UI state → Zustand.
|
|
16
|
+
Remote/tenant data is never persisted client-side (IndexedDB/local-first was evaluated and
|
|
17
|
+
rejected for multi-tenant SaaS on governance grounds — a confirmed single-tenant/offline
|
|
18
|
+
product is the only exception, and that's a decision to ask for, not assume).
|
|
19
|
+
- Next config: `output: 'standalone'`, `cacheComponents: true` (PPR flags no longer exist).
|
|
20
|
+
Query key factories live in non-`'use client'` `.keys.ts` modules so RSC pages can prefetch.
|
|
21
|
+
- Server Components by default; `'use client'` only at the lowest leaf that needs it.
|
|
22
|
+
`/server` (or `packages/*` server code) is never imported from client code — `server-only`
|
|
23
|
+
plus a boundary check, not convention.
|
|
24
|
+
- Request interception: on OpenNext/Cloudflare, `proxy.ts`/Node middleware does NOT work
|
|
25
|
+
as of 2026-08 (open adapter issues — see infra.md); use what the adapter actually
|
|
26
|
+
supports and re-check its docs per feature. Either way interception is never the auth
|
|
27
|
+
boundary (see security.md).
|
|
28
|
+
- Internal navigation uses `next/link`; bare `<a>` only for true external links/downloads.
|
|
29
|
+
- Never TypeScript `any` — `unknown` and narrow.
|
|
30
|
+
- Dependencies: prefer the native/browser API when it covers the need
|
|
31
|
+
(`Intl.RelativeTimeFormat` over date-fns); self-implement simple behavior (a tween, a diff
|
|
32
|
+
view) by composing design-system primitives before adding a library; any non-trivial new
|
|
33
|
+
dependency needs a stated justification and approval. **Why:** self-contained code has no
|
|
34
|
+
supply-chain, licensing, or upgrade surface, and MK rejects "library because library".
|
|
35
|
+
|
|
36
|
+
## Design system (consuming `@vegastack/design` / `@vegastack/ui`)
|
|
37
|
+
|
|
38
|
+
- First-time setup in a fresh project (npm install, Tailwind wiring, provider, registry
|
|
39
|
+
auth) is a separate, already-built skill — `vegastack-consume` — use it; don't
|
|
40
|
+
re-derive the wiring here.
|
|
41
|
+
- Consume through the package barrel, never deep imports; never edit shipped component files.
|
|
42
|
+
A missing component or variant is an upstream request MK decides — the recommended
|
|
43
|
+
interim pattern is a local presentational composition in the app (inferred — confirm on
|
|
44
|
+
first use); don't fork the system.
|
|
45
|
+
- Semantic tokens only: no inline `style={}`, no arbitrary values (`bg-[#123]`, `h-[13px]`),
|
|
46
|
+
no raw palette classes (`bg-neutral-900`), not even for opacity. Dynamic values go through
|
|
47
|
+
CSS custom properties.
|
|
48
|
+
- Visual language: borders-only cards, flat surfaces (shadows only for true overlays); accent
|
|
49
|
+
color rationed to the primary action and real selected/active state — never hover, roughly
|
|
50
|
+
≤10 accent elements a page. Focus stays visible always (WCAG 2.2 AA floor) — the house
|
|
51
|
+
mechanism is a darker border or native outline, never a `ring-*` utility. Control heights
|
|
52
|
+
on the 28/32/40 scale = `h-7`/`h-8`/`h-10` (no off-scale `h-9`); radius: `rounded-md`
|
|
53
|
+
controls, `rounded-sm` menu items, `rounded-lg` containers, `rounded-full` pills — never
|
|
54
|
+
`rounded-xl` on cards/dialogs. Touch-target minimum is genuinely unresolved (24px WCAG AA
|
|
55
|
+
vs 44px mobile-HIG both appear in the record) — ask MK when it matters.
|
|
56
|
+
- Typography: product code caps at `font-semibold` and uses it sparingly (inside the design
|
|
57
|
+
system package itself the cap is `font-medium`); headings `font-lora`; numbers, versions,
|
|
58
|
+
costs, and card digits always `font-mono`; uppercase only in mono at ≤14px. Fonts are
|
|
59
|
+
self-hosted via `next/font` — never a Google Fonts CDN request.
|
|
60
|
+
- Icons: Lucide only. Toasts: sonner, never native/OS prompts. 4px spacing scale.
|
|
61
|
+
- Motion: subtle and minimal — no button hover/press animations, no `transition-all`; motion
|
|
62
|
+
is for state feedback (success/error) and structural changes. `prefers-reduced-motion`
|
|
63
|
+
disables animation entirely (instant, not softened).
|
|
64
|
+
- No decorative filler: no gratuitous badges, eyebrow text, or "3 of 3" counters — MK cuts
|
|
65
|
+
these on sight as AI-generated design tells.
|
|
66
|
+
- Light AND dark theme on every shipped surface (internal-only tools may opt out, stated
|
|
67
|
+
up front).
|
|
68
|
+
|
|
69
|
+
## UI completeness bar (every real surface, before it's "done")
|
|
70
|
+
|
|
71
|
+
- Full state matrix: loading skeleton shaped like the real content · empty state with
|
|
72
|
+
guidance · error routed to the specific failure (401/403, 404, 410, 429, generic — never
|
|
73
|
+
swallowed into `{}`) · success feedback. Optimistic updates where a mutation changes
|
|
74
|
+
visible state; the UI reflects backend mutations without a manual refresh.
|
|
75
|
+
- Forms: Enter submits; spinner replaces the button icon (not beside it); first field
|
|
76
|
+
auto-focused; all fields disabled while the primary action runs; state resets on error or
|
|
77
|
+
navigation.
|
|
78
|
+
- Responsive: no horizontal scroll at any width; computed layout math, never hardcoded pixel
|
|
79
|
+
offsets; truncation driven by available space, not character counts; iOS inputs must not
|
|
80
|
+
zoom on focus; the mobile keyboard must never occlude the active input.
|
|
81
|
+
- Systemic fixes: a defect found in one component (scroll leaking through an overlay, missing
|
|
82
|
+
cursor, wrong token) is fixed across the whole family in one sweep, with evidence.
|
|
83
|
+
- Perceived speed is the named pattern "instant shell": the layout shell renders
|
|
84
|
+
immediately (RSC + `cacheComponents`), every data region streams in behind a skeleton
|
|
85
|
+
shaped like its content — never a blank page or a full-page spinner.
|
|
86
|
+
- Long lists (>~50 rows) virtualize with `@tanstack/react-virtual` (the approved package —
|
|
87
|
+
still state the justification when adding it).
|
|
88
|
+
- Cloning/rebranding a reference site: strip every trace of the source tool's provenance
|
|
89
|
+
(class names, external asset domains, meta) so the result is fully self-contained, and
|
|
90
|
+
verify parity by clicking through as a real user — screenshot diffing alone doesn't count.
|
|
91
|
+
|
|
92
|
+
## SEO and metadata (every public-facing app)
|
|
93
|
+
|
|
94
|
+
- Every route exports `metadata`/`generateMetadata` — not just the root layout. Public
|
|
95
|
+
apps ship `sitemap.ts` and `robots.ts`; `llms.txt` is generated at build time, never
|
|
96
|
+
hand-maintained. OG images follow the house convention (generated, mono for
|
|
97
|
+
names/numbers). i18n uses next-intl `localePrefix: 'as-needed'` (stack.md) so default-
|
|
98
|
+
locale URLs stay clean. **Why:** MK has demanded "100% SEO" coverage on shipped sites
|
|
99
|
+
twice — treat it as a completeness bar, not an enhancement.
|
|
100
|
+
|
|
101
|
+
## Testing (web/backend — test where it pays off)
|
|
102
|
+
|
|
103
|
+
- Unit-test services and pure logic (Vitest); component/a11y tests run in Vitest browser
|
|
104
|
+
mode with the Playwright provider (real Chromium — jsdom's ARIA/layout gaps produce
|
|
105
|
+
false a11y results and are not trusted).
|
|
106
|
+
- E2E is a walking skeleton: one real happy path (boot → auth → core mutation → verify)
|
|
107
|
+
plus targeted adversarial invariants — not a blanket suite. DB-gated tests are authored
|
|
108
|
+
even when execution is blocked, and gated behind an env flag (`RUN_DB_TESTS=1` pattern);
|
|
109
|
+
E2E doubles implement real ports, never a parallel mock pathway.
|
|
110
|
+
- Every confirmed bug gets a regression test; no coverage-percentage targets — "100%"
|
|
111
|
+
means audit completeness, never a coverage metric. VRT/demo content is deterministic
|
|
112
|
+
(no `Date.now()`/`Math.random()`).
|
|
113
|
+
|
|
114
|
+
## Backend / API design
|
|
115
|
+
|
|
116
|
+
- Contract-first: zod schemas are the single source → OpenAPI 3.1 under `/api/v1`, camelCase,
|
|
117
|
+
cursor pagination on every list, RFC 9457 problem-details errors with a stable error-code
|
|
118
|
+
catalog. One contract serves web, Flutter, MCP, and public consumers.
|
|
119
|
+
- Every route: auth before parse, through the shared route-handler wrapper — no route-local
|
|
120
|
+
zod, no raw `request.json()`. Sanitize responses: secrets and credential references never
|
|
121
|
+
leave the server. Enforce with a CI ratchet (unwrapped routes fail the build), not review.
|
|
122
|
+
- Return what the view renders, not everything — no mega-responses. Select columns explicitly.
|
|
123
|
+
- Body limits stream: count bytes as they arrive and abort at the limit; never buffer the
|
|
124
|
+
whole body first.
|
|
125
|
+
- Webhooks over polling; the database is the source of truth. Once provider state lands in
|
|
126
|
+
Postgres via webhook, don't re-poll the provider — and don't build intermediary "waiting"
|
|
127
|
+
pages; redirect on success and let the rest arrive in the background.
|
|
128
|
+
- Money paths (Stripe): isolated intake (own worker or route), idempotency keys on every
|
|
129
|
+
mutation, event dedupe, append-only ledgers as the single cost source of truth, audit
|
|
130
|
+
events written in the same transaction as the business change. Pricing/quoting math is
|
|
131
|
+
deterministic code with server-enforced invariants — AI drafts and judges; deterministic
|
|
132
|
+
code calculates and enforces (a proven client-project pattern; treat as the strong
|
|
133
|
+
default for money paths).
|
|
134
|
+
- Centralize the boring: one ID helper (never raw `crypto.randomUUID` scattered), one logger
|
|
135
|
+
(never `console.log`; request/org context auto-injected; never log secrets or PII beyond
|
|
136
|
+
user IDs), one typed fail-hard zod env parser validated at startup — no
|
|
137
|
+
`DISABLE_AUTH`-style escape hatches, no plaintext fallbacks.
|
|
138
|
+
- Dead endpoints get deleted, not deprecated-and-kept. (Exception: a versioned `/api/v1`
|
|
139
|
+
contract consumed by a shipped mobile app outlives web deploy cycles — app-store install
|
|
140
|
+
lag means mobile clients keep the old contract alive; see mobile.md.)
|
|
141
|
+
- Outbound webhooks to customers (when a product offers them): a defined event catalog,
|
|
142
|
+
Standard Webhooks-style signing with rotatable secrets, delivery via the transactional
|
|
143
|
+
outbox → queue with retries/backoff, auto-disable an endpoint after N consecutive
|
|
144
|
+
failures, and a replay surface. Never fire webhooks inline from request handlers.
|
|
145
|
+
- Platform-native mentions over plain text: when the data allows it, resolve and mention
|
|
146
|
+
the real entity (Slack user @mentions, Notion Person fields) instead of rendering names
|
|
147
|
+
as text — the recurring "don't just fix, improve" integration principle.
|
|
148
|
+
- Wizard/checkout flow-state persistence (Zustand + sessionStorage vs server-side draft)
|
|
149
|
+
is not yet a settled house rule — ask MK when building one.
|
|
150
|
+
- Rate-limited responses return 429 with a `Retry-After` header.
|
|
151
|
+
- Timestamps stored UTC (`timestamptz`), rendered in the user's timezone; durations as
|
|
152
|
+
integer milliseconds; money in integer minor units.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Freshness contract — architect
|
|
2
|
+
|
|
3
|
+
Most of this skill is durable taste and recorded decisions; it does not go stale on its
|
|
4
|
+
own. Exactly one file decays with the platform landscape: `references/pinned-facts.md`
|
|
5
|
+
(plus the version claims embedded in `references/stack.md` and `references/mobile.md`).
|
|
6
|
+
|
|
7
|
+
## Mechanism
|
|
8
|
+
|
|
9
|
+
1. **Weekly scheduled agent (primary).** A scheduled Claude Code/Codex job re-verifies
|
|
10
|
+
each pinned fact against its stated source URL and opens ONE pull request quoting
|
|
11
|
+
evidence for anything that changed (fact text, version, date, source). The diffing
|
|
12
|
+
judgment lives in the agent run, not in maintained scripts. The PR is human-reviewed —
|
|
13
|
+
never auto-merged.
|
|
14
|
+
2. **Refresh-on-use (safety net, written into SKILL.md).** When a recommendation leans on
|
|
15
|
+
a pinned fact older than 60 days, the consuming agent re-verifies that one fact first
|
|
16
|
+
and says so. Never bulk-refresh in-session.
|
|
17
|
+
3. **Registry baseline (`sources.json`).** The repo-shared refresh runner
|
|
18
|
+
(`tooling/refresh/refresh-evidence.mjs`) keeps checksum baselines for the critical
|
|
19
|
+
source pages so CI can detect upstream drift deterministically between weekly runs.
|
|
20
|
+
|
|
21
|
+
## Rules
|
|
22
|
+
|
|
23
|
+
- Critical sources (Hyperdrive supported versions, Better Auth docs, eve/Workflow SDK
|
|
24
|
+
deploy constraints) get `critical: true` — drift there warrants a prompt PR, not a
|
|
25
|
+
batch.
|
|
26
|
+
- Every edited fact keeps the pattern: fact → why it changes a decision → source URL →
|
|
27
|
+
verified date. The file carries one blanket verified-date for facts checked together;
|
|
28
|
+
a fact re-verified alone gets its own inline date, superseding the blanket one.
|
|
29
|
+
- A fact that stops being decision-changing is deleted, not kept for completeness.
|
|
@@ -0,0 +1,244 @@
|
|
|
1
|
+
{
|
|
2
|
+
"schemaVersion": 1,
|
|
3
|
+
"policy": {
|
|
4
|
+
"criticalTopics": [
|
|
5
|
+
"hyperdrive-postgres",
|
|
6
|
+
"better-auth",
|
|
7
|
+
"eve-deploy"
|
|
8
|
+
],
|
|
9
|
+
"defaultChecksumScope": "html-text-v1",
|
|
10
|
+
"offline": "Use cached metadata only; fail closed when a critical entry is missing or older than thresholdDays.",
|
|
11
|
+
"drift": "Any drift requires reading the changed page and a human-reviewed PR updating references/pinned-facts.md (and version claims in references/stack.md / references/mobile.md); never auto-apply.",
|
|
12
|
+
"copyright": "Store claim metadata, URLs, hashes, and concise excerpts only; never archive third-party documentation corpora.",
|
|
13
|
+
"cadence": "weekly scheduled-agent refresh; thresholdDays must be >= 14 (2x cadence) so a single missed run never breaches a threshold"
|
|
14
|
+
},
|
|
15
|
+
"sources": [
|
|
16
|
+
{
|
|
17
|
+
"id": "CF-HYPERDRIVE-VERSIONS",
|
|
18
|
+
"service": "Cloudflare Hyperdrive supported databases",
|
|
19
|
+
"kind": "official-docs",
|
|
20
|
+
"stability": "vendor-docs",
|
|
21
|
+
"thresholdDays": 14,
|
|
22
|
+
"critical": true,
|
|
23
|
+
"urls": {
|
|
24
|
+
"primary": "https://developers.cloudflare.com/hyperdrive/reference/supported-databases-and-features/"
|
|
25
|
+
},
|
|
26
|
+
"versionDetection": {
|
|
27
|
+
"type": "manual-review"
|
|
28
|
+
},
|
|
29
|
+
"topics": [
|
|
30
|
+
"hyperdrive-postgres"
|
|
31
|
+
],
|
|
32
|
+
"affected": [
|
|
33
|
+
"references/pinned-facts.md",
|
|
34
|
+
"references/stack.md",
|
|
35
|
+
"references/data.md"
|
|
36
|
+
],
|
|
37
|
+
"checksum": "fda2870b95deffce48dca7f3df3707325b1bc4a2d58a17708ee9220bfba5eba1",
|
|
38
|
+
"retrievedAt": "2026-08-12T14:33:11.062Z"
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"id": "CF-R2-PRICING",
|
|
42
|
+
"service": "Cloudflare R2 pricing",
|
|
43
|
+
"kind": "official-docs",
|
|
44
|
+
"stability": "vendor-docs",
|
|
45
|
+
"thresholdDays": 30,
|
|
46
|
+
"critical": false,
|
|
47
|
+
"urls": {
|
|
48
|
+
"primary": "https://developers.cloudflare.com/r2/pricing/"
|
|
49
|
+
},
|
|
50
|
+
"versionDetection": {
|
|
51
|
+
"type": "manual-review"
|
|
52
|
+
},
|
|
53
|
+
"topics": [
|
|
54
|
+
"r2-economics"
|
|
55
|
+
],
|
|
56
|
+
"affected": [
|
|
57
|
+
"references/pinned-facts.md",
|
|
58
|
+
"references/stack.md"
|
|
59
|
+
],
|
|
60
|
+
"checksum": "bd5e8d26f7bbf2f92182ad4ac1a59ae9b1d90695120062adaf54c281bd88e81f",
|
|
61
|
+
"retrievedAt": "2026-08-12T14:33:11.062Z"
|
|
62
|
+
},
|
|
63
|
+
{
|
|
64
|
+
"id": "CF-WORKFLOWS-PRICING",
|
|
65
|
+
"service": "Cloudflare Workflows limits and pricing",
|
|
66
|
+
"kind": "official-docs",
|
|
67
|
+
"stability": "vendor-docs",
|
|
68
|
+
"thresholdDays": 30,
|
|
69
|
+
"critical": false,
|
|
70
|
+
"urls": {
|
|
71
|
+
"primary": "https://developers.cloudflare.com/workflows/reference/limits/"
|
|
72
|
+
},
|
|
73
|
+
"versionDetection": {
|
|
74
|
+
"type": "manual-review"
|
|
75
|
+
},
|
|
76
|
+
"topics": [
|
|
77
|
+
"workflows"
|
|
78
|
+
],
|
|
79
|
+
"affected": [
|
|
80
|
+
"references/pinned-facts.md",
|
|
81
|
+
"references/ai-agents.md"
|
|
82
|
+
],
|
|
83
|
+
"checksum": "64e10ca4ced4edc042d12a9a24f2e165ea71cb9481c30ac5f067f2f6c9218cda",
|
|
84
|
+
"retrievedAt": "2026-08-12T14:33:11.062Z"
|
|
85
|
+
},
|
|
86
|
+
{
|
|
87
|
+
"id": "BETTER-AUTH-DOCS",
|
|
88
|
+
"service": "Better Auth documentation",
|
|
89
|
+
"kind": "official-docs",
|
|
90
|
+
"stability": "vendor-docs",
|
|
91
|
+
"thresholdDays": 14,
|
|
92
|
+
"critical": true,
|
|
93
|
+
"urls": {
|
|
94
|
+
"primary": "https://better-auth.com/docs/plugins/organization"
|
|
95
|
+
},
|
|
96
|
+
"versionDetection": {
|
|
97
|
+
"type": "npm",
|
|
98
|
+
"package": "better-auth"
|
|
99
|
+
},
|
|
100
|
+
"topics": [
|
|
101
|
+
"better-auth"
|
|
102
|
+
],
|
|
103
|
+
"affected": [
|
|
104
|
+
"references/pinned-facts.md",
|
|
105
|
+
"references/security.md",
|
|
106
|
+
"references/stack.md"
|
|
107
|
+
],
|
|
108
|
+
"currentVersion": "1.6.27",
|
|
109
|
+
"versionCheckedAt": "2026-08-12T14:33:11.062Z",
|
|
110
|
+
"checksum": "30edf1b6658a473a00005153a3eafc07de5c3decd6b8f09fc6c32f3a21c4db1c",
|
|
111
|
+
"retrievedAt": "2026-08-12T14:33:11.062Z"
|
|
112
|
+
},
|
|
113
|
+
{
|
|
114
|
+
"id": "EVE-DOCS",
|
|
115
|
+
"service": "Vercel eve agent framework",
|
|
116
|
+
"kind": "official-docs",
|
|
117
|
+
"stability": "beta",
|
|
118
|
+
"thresholdDays": 14,
|
|
119
|
+
"critical": true,
|
|
120
|
+
"urls": {
|
|
121
|
+
"primary": "https://vercel.com/docs/eve"
|
|
122
|
+
},
|
|
123
|
+
"versionDetection": {
|
|
124
|
+
"type": "npm",
|
|
125
|
+
"package": "eve"
|
|
126
|
+
},
|
|
127
|
+
"topics": [
|
|
128
|
+
"eve-deploy"
|
|
129
|
+
],
|
|
130
|
+
"affected": [
|
|
131
|
+
"references/pinned-facts.md",
|
|
132
|
+
"references/ai-agents.md",
|
|
133
|
+
"references/stack.md"
|
|
134
|
+
],
|
|
135
|
+
"currentVersion": "0.33.2",
|
|
136
|
+
"versionCheckedAt": "2026-08-12T14:33:11.062Z",
|
|
137
|
+
"checksum": "a777f9da0cb3966a9c7cc06a3c12be34b2928800b370e966e8b6e0f5a5622915",
|
|
138
|
+
"retrievedAt": "2026-08-12T14:33:11.062Z"
|
|
139
|
+
},
|
|
140
|
+
{
|
|
141
|
+
"id": "WORKFLOW-SDK-POSTGRES",
|
|
142
|
+
"service": "Workflow SDK Postgres world deployment constraints",
|
|
143
|
+
"kind": "official-docs",
|
|
144
|
+
"stability": "vendor-docs",
|
|
145
|
+
"thresholdDays": 14,
|
|
146
|
+
"critical": true,
|
|
147
|
+
"urls": {
|
|
148
|
+
"primary": "https://workflow-sdk.dev/worlds/postgres"
|
|
149
|
+
},
|
|
150
|
+
"versionDetection": {
|
|
151
|
+
"type": "npm",
|
|
152
|
+
"package": "@workflow/world-postgres"
|
|
153
|
+
},
|
|
154
|
+
"topics": [
|
|
155
|
+
"eve-deploy"
|
|
156
|
+
],
|
|
157
|
+
"affected": [
|
|
158
|
+
"references/pinned-facts.md",
|
|
159
|
+
"references/ai-agents.md"
|
|
160
|
+
],
|
|
161
|
+
"currentVersion": "4.3.3",
|
|
162
|
+
"versionCheckedAt": "2026-08-12T14:33:11.062Z",
|
|
163
|
+
"checksum": "3eca56b5ec9668638d4e00b290c157383dfe8ceaaa334de13bb6244b32fa6839",
|
|
164
|
+
"retrievedAt": "2026-08-12T14:33:11.062Z"
|
|
165
|
+
},
|
|
166
|
+
{
|
|
167
|
+
"id": "NEXTJS-BLOG",
|
|
168
|
+
"service": "Next.js release blog",
|
|
169
|
+
"kind": "official-docs",
|
|
170
|
+
"stability": "vendor-docs",
|
|
171
|
+
"thresholdDays": 30,
|
|
172
|
+
"critical": false,
|
|
173
|
+
"urls": {
|
|
174
|
+
"primary": "https://nextjs.org/blog"
|
|
175
|
+
},
|
|
176
|
+
"versionDetection": {
|
|
177
|
+
"type": "npm",
|
|
178
|
+
"package": "next"
|
|
179
|
+
},
|
|
180
|
+
"topics": [
|
|
181
|
+
"nextjs"
|
|
182
|
+
],
|
|
183
|
+
"affected": [
|
|
184
|
+
"references/pinned-facts.md",
|
|
185
|
+
"references/web.md",
|
|
186
|
+
"references/stack.md"
|
|
187
|
+
],
|
|
188
|
+
"currentVersion": "16.3.0",
|
|
189
|
+
"versionCheckedAt": "2026-08-12T14:33:11.062Z",
|
|
190
|
+
"checksum": "9d5d2503e2e8aa7ed1c3f0cb972c78e64b2e3aae5f3ad264bb0a79bd179708f0",
|
|
191
|
+
"retrievedAt": "2026-08-12T14:33:11.062Z"
|
|
192
|
+
},
|
|
193
|
+
{
|
|
194
|
+
"id": "PG-BOSS-NPM",
|
|
195
|
+
"service": "pg-boss job queue",
|
|
196
|
+
"kind": "package-registry",
|
|
197
|
+
"stability": "stable",
|
|
198
|
+
"thresholdDays": 30,
|
|
199
|
+
"critical": false,
|
|
200
|
+
"urls": {
|
|
201
|
+
"primary": "https://registry.npmjs.org/pg-boss/latest"
|
|
202
|
+
},
|
|
203
|
+
"versionDetection": {
|
|
204
|
+
"type": "npm",
|
|
205
|
+
"package": "pg-boss"
|
|
206
|
+
},
|
|
207
|
+
"topics": [
|
|
208
|
+
"jobs"
|
|
209
|
+
],
|
|
210
|
+
"affected": [
|
|
211
|
+
"references/pinned-facts.md",
|
|
212
|
+
"references/ai-agents.md"
|
|
213
|
+
],
|
|
214
|
+
"currentVersion": "12.27.0",
|
|
215
|
+
"versionCheckedAt": "2026-08-12T14:33:11.062Z",
|
|
216
|
+
"checksumScope": "http-body",
|
|
217
|
+
"checksum": "abf4bc2795e2df03181a21dfd29c7b9234c933a9dcafa72b4583d590cad609da",
|
|
218
|
+
"retrievedAt": "2026-08-12T14:33:41.513Z"
|
|
219
|
+
},
|
|
220
|
+
{
|
|
221
|
+
"id": "FLUTTER-RELEASES",
|
|
222
|
+
"service": "Flutter release notes",
|
|
223
|
+
"kind": "official-docs",
|
|
224
|
+
"stability": "vendor-docs",
|
|
225
|
+
"thresholdDays": 30,
|
|
226
|
+
"critical": false,
|
|
227
|
+
"urls": {
|
|
228
|
+
"primary": "https://docs.flutter.dev/release/release-notes"
|
|
229
|
+
},
|
|
230
|
+
"versionDetection": {
|
|
231
|
+
"type": "manual-review"
|
|
232
|
+
},
|
|
233
|
+
"topics": [
|
|
234
|
+
"flutter"
|
|
235
|
+
],
|
|
236
|
+
"affected": [
|
|
237
|
+
"references/pinned-facts.md",
|
|
238
|
+
"references/mobile.md"
|
|
239
|
+
],
|
|
240
|
+
"checksum": "94f9df6f67615ee05d826995f9709309c5453d0d8e4be11232ca5d463929ed2b",
|
|
241
|
+
"retrievedAt": "2026-08-12T14:33:11.062Z"
|
|
242
|
+
}
|
|
243
|
+
]
|
|
244
|
+
}
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dev-implement
|
|
3
|
+
description: Implement an approved GitHub issue end to end without further user input. Use when given an issue to build - "do issue 12", "implement" plus an issue URL or number, "pick up the next ready issue", "go dark on" an issue - when returning to apply corrections the user left on a for-you issue, or when the user directly asks in chat for a quick fix or small change. Runs preflight, claims the issue, builds on a task branch, tests, gets independent review, and posts one evidence comment in the issue. Not for writing or approving issues (dev-intake), not for creating PRs or merging (dev-ship).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# dev-implement
|
|
7
|
+
|
|
8
|
+
One issue, one session, end to end: preflight → claim → build dark → verify → review → evidence in the issue → stop. The user reads the result in the issue on their own time; nothing here creates a PR or merges — those are `dev-ship`, on the user's word.
|
|
9
|
+
|
|
10
|
+
Nearest neighbor: `dev-intake` writes the brief this skill executes; if the issue turns out to need decisions, that's intake work — hand it back via `needs-you`, don't guess. `.vegastack/dev.md` missing → run `dev-setup` first. Read dev.md before anything; its knobs (review, ui-evidence, tests, branch, stop-list) govern this whole skill.
|
|
11
|
+
|
|
12
|
+
## Direct requests
|
|
13
|
+
|
|
14
|
+
The gates exist to stop agent-invented authority, never to slow the user down. When the user directly asks in chat for a change ("fix this typo", "bump that timeout"), their words are the approval — do it, verify it, and report; no issue required. Offer to record an issue when the change is material enough that its brief or evidence will matter later. Everything below is the path for issue-driven work.
|
|
15
|
+
|
|
16
|
+
## Preflight — all must hold, or stop and say which failed
|
|
17
|
+
|
|
18
|
+
- `gh auth status` works and the issue's repo matches dev.md.
|
|
19
|
+
- The issue is open, labeled `ready`, and carries the recorded approval comment (`Approved by … : "…"`). A label without the comment is not approval.
|
|
20
|
+
- No open blockers (issue dependencies) and no other assignee — an assigned or `working` issue belongs to someone else. A claim from a dead session is released only by the user: take over a `working` issue only when they explicitly hand it to you.
|
|
21
|
+
- Read the complete brief, plus parent issue and milestone for context. If the brief leaves a material decision open — including an unresolved Assumptions entry — do not start: label `needs-you`, comment the smallest question that unblocks it, stop.
|
|
22
|
+
- Re-verify the brief against reality before coding: its cited touch points against the current code (things drift between approval and execution), and volatile dependency claims when stale or version-sensitive. Reality contradicting the brief is a stop — label `needs-you` with the discrepancy; an approved brief is never a license to improvise past what's actually there.
|
|
23
|
+
|
|
24
|
+
## Claim and branch
|
|
25
|
+
|
|
26
|
+
Assign yourself, swap `ready` → `working`. Branch from the default branch: `<type>/<issue-number>-<short-slug>` (type from dev.md: feat, fix, docs, chore, refactor).
|
|
27
|
+
|
|
28
|
+
## Build — dark
|
|
29
|
+
|
|
30
|
+
No progress updates, no questions. A spike the brief flagged runs first — its result opens the evidence comment and shapes the rest of the build. Decide routine things yourself: file layout, helpers, fixtures, and root-cause fixes inside the issue's change areas. The brief's out-of-scope section and the dev.md stop-list bound you; hitting a stop condition (scope change, new dependency, spending, destructive/production action, unresolvable blocker) ends dark mode — post one `needs-you` comment stating the smallest decision needed with your recommendation, and stop.
|
|
31
|
+
|
|
32
|
+
Honesty over green: a failing test gets fixed at the root or reported as failing. Weakening a test, an assertion, or acceptance to pass is a cover-up, and cover-ups surface at review with interest.
|
|
33
|
+
|
|
34
|
+
## Verify
|
|
35
|
+
|
|
36
|
+
- Run the tests dev.md requires (`tests: required` → every changed behavior has a test that runs and passes; `logic-only` → content/config tweaks may skip). Record commands and results for the evidence comment.
|
|
37
|
+
- A `risky` issue gets focused security, failure, and recovery checks on top of the required tests.
|
|
38
|
+
- UI changed and `ui-evidence: playwright` → capture screenshots of the key states and flows, push them to the evidence repo (dev.md `evidence-repo`) under `<repo>/<issue-number>/`, and link them. Links, not embeds — private-repo images don't render inline in issues. Evidence repo missing or unreachable → name the local file paths in the evidence comment and say so; the hand-back never blocks on it.
|
|
39
|
+
|
|
40
|
+
## Independent review — per the dev.md knob
|
|
41
|
+
|
|
42
|
+
- `subagent` (default): spawn a fresh reviewer subagent that gets the diff, the brief, and dev.md — and no memory of writing the code. It checks: does the change do what the brief says, does anything break, are the tests real? In a harness without subagents, do a separate fresh-eyes review pass against the brief and label it a self-review in the evidence comment; prefer cross-agent there for `risky` work.
|
|
43
|
+
- `cross-agent` (or `cross-agent-risky` on a `risky` issue): push the branch, add to the evidence comment "awaiting cross-agent review", keep `working`, and tell the user which agent to point at the issue. The reviewing session posts findings on the issue; you apply them.
|
|
44
|
+
- Fix real findings and rerun affected checks. Disagree with a finding → say why in the evidence comment rather than silently skipping it.
|
|
45
|
+
|
|
46
|
+
## The evidence comment — exactly one, edited in place
|
|
47
|
+
|
|
48
|
+
```
|
|
49
|
+
## Result
|
|
50
|
+
**Done:** what changed, in behavior terms
|
|
51
|
+
**Tests:** <command> → <result summary>
|
|
52
|
+
**Review:** <mode> — <findings fixed / none / disputed with reason>
|
|
53
|
+
**UI evidence:** <links> (when applicable)
|
|
54
|
+
**Not done / limits:** the honest list
|
|
55
|
+
Branch: <name> @ <short-sha>
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
Post it, swap `working` → `for-you`, unassign nothing, stop. Later corrections update this same comment — a stack of stale result comments hides the current truth.
|
|
59
|
+
|
|
60
|
+
## Corrections loop
|
|
61
|
+
|
|
62
|
+
The user's comments on a `for-you` issue are the new frontier: apply them, re-verify what they touch, update the evidence comment, back to `for-you`. Their corrections never need re-approval ceremony unless they change scope — then it's `needs-you` and dev-intake's recording rule.
|
|
@@ -0,0 +1,3 @@
|
|
|
1
|
+
# Refresh contract — dev-implement
|
|
2
|
+
|
|
3
|
+
Evergreen: this skill asserts no version pins, vendor mechanism names beyond long-stable `gh` subcommands, numeric vendor limits, or dated facts — its content is workflow discipline (preflight, claiming, dark-mode bounds, review modes, the evidence-comment contract), all versionless. Harness mechanics are tracked by `dev-setup`'s registry. Revisit if a future edit introduces a volatile fact.
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dev-intake
|
|
3
|
+
description: Turn ideas, brainstorms, feature requests, or SOW documents into GitHub issues an agent can implement without further questions. Use when asked to "turn this into issues", "create tasks from this SOW", "write up an issue for" a feature or bug, "plan this as issues", "slice this epic", or when the user gives approval on a drafted issue and it needs recording. Produces complete inline build briefs with labels, milestones, and blocker links. Not for implementing issues (dev-implement), creating PRs or merging (dev-ship), or project bootstrap (dev-setup).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# dev-intake
|
|
7
|
+
|
|
8
|
+
Requirements come in as the user's brainstorm, feature thought, or SOW; issues go out complete enough that a fresh agent needs nothing but the URL. Every question gets asked **here** — once implementation starts, dark mode means no questions, so an under-specified issue becomes either an interruption or a guess. This skill exists to make both impossible.
|
|
9
|
+
|
|
10
|
+
Nearest neighbor: `dev-implement` consumes what this produces — intake writes and gets approval, implement builds. If `.vegastack/dev.md` is missing, run `dev-setup` first, then continue here.
|
|
11
|
+
|
|
12
|
+
## Ground before you ask
|
|
13
|
+
|
|
14
|
+
Finding facts is your job, never the user's — and a brief built on unverified facts is a confident mistake waiting for dark mode. The source can be one sentence in chat; thinner material just means the grounding and interview carry more weight. Before the first question:
|
|
15
|
+
|
|
16
|
+
- **Read the touched code.** Open the actual paths the feature would change: current behavior, existing patterns to reuse, where the new work plugs in. The brief cites these real paths later — a brief naming no files is a sign this step was skipped.
|
|
17
|
+
- **Verify dependencies.** Any library, service, or API capability the approach leans on gets checked against current official docs (docs tools or web search), noted with the date. Consult `architect`'s pinned facts for stack questions before re-researching; re-verify a pinned fact older than 60 days; skip lookups for long-stable basics — judgment, not ritual.
|
|
18
|
+
- **Cross-check the request** against product docs and current behavior. A contradiction is pushback, never a silent resolution: "you asked for X; the code/docs currently do Y — which wins?" Push back on cost the same way: when a simpler version covers most of the need, name it.
|
|
19
|
+
- **Triage every unknown** into exactly three bins: *findable* → find it now, yourself; *only-the-user-knows* → ask, with a recommendation; *only-running-code-can-tell* → flag it as a spike that becomes the issue's first step. Guessing is not a bin.
|
|
20
|
+
|
|
21
|
+
## The interview
|
|
22
|
+
|
|
23
|
+
Ask in rounds using your harness's question tool (AskUserQuestion in Claude Code, `request_user_input` in Codex where the mode allows; no tool available → draft with recommended answers marked `TODO confirm` and say so). Each round covers the current frontier: every open decision that does not depend on another answer.
|
|
24
|
+
|
|
25
|
+
- Number the questions. Give each a **recommended answer with a one-line reason**, so the user can reply "all recommended" or override by number.
|
|
26
|
+
- Stop asking when the bar is met: *a fresh agent could implement each issue without asking anything.* Test every brief against that sentence before calling it done.
|
|
27
|
+
- Do not re-ask what the material or an earlier round already settled.
|
|
28
|
+
|
|
29
|
+
## The angles, in order
|
|
30
|
+
|
|
31
|
+
Work the design the way a joint product-and-tech review would; each round's answers feed the next:
|
|
32
|
+
|
|
33
|
+
1. **Product** — who this is for, the observable outcome, what's in and out of scope now, how it splits into slices or phases, priority.
|
|
34
|
+
2. **Behavior** — primary and alternate flows, rules, permissions, validations, edge and failure cases; for UI, the states, components, and copy.
|
|
35
|
+
3. **Technical** — only the choices that are genuinely the user's: approach trade-offs, data and interface implications, integrations, migration; recommend one and say why. Routine implementation stays the implementer's.
|
|
36
|
+
4. **Quality and risk** — what proves it works (test cases, acceptance), what earns the `risky` label, what should stop a dark run beyond the standing stop-list.
|
|
37
|
+
|
|
38
|
+
These are the brief template's sections in interview form — a question exists only where reading the material, the codebase, and sensible defaults cannot fill a section.
|
|
39
|
+
|
|
40
|
+
## Slicing
|
|
41
|
+
|
|
42
|
+
- One issue = one outcome that fits one agent session, sliced vertically (a thin working path through the stack beats a layer at a time).
|
|
43
|
+
- Blockers use native issue dependencies (blocked-by); phases use milestones; hierarchy uses parent/sub-issues. Labels never duplicate these.
|
|
44
|
+
- A large feature gets a parent issue holding the map and child issues holding the work. **Only child issues ever get `ready`** — a parent brief is context, not an executable task, and an agent must never pick it up whole.
|
|
45
|
+
- Deliberately deferred work ("someday, not now") lives in the parent's out-of-scope section, not as its own issue — icebox issues clutter the tracker. Create a tracking issue for it only when the user asks.
|
|
46
|
+
|
|
47
|
+
## The brief
|
|
48
|
+
|
|
49
|
+
Every issue body follows [brief-template](references/brief-template.md): Outcome · Out of scope · Rules and edge cases · UI states (when there is UI) · Approach and touch points · Tests and acceptance · Risks and stop conditions · Assumptions. Write the sections that apply and delete the ones that don't — an empty "N/A" section is noise, not diligence. Details live inline in the issue; links to docs are supporting material, never a substitute for the brief. Evidence over confidence: touch points name real paths, dependency claims carry their check date, and anything material the grounding could not verify goes in **Assumptions — confirm or correct**, never asserted as fact.
|
|
50
|
+
|
|
51
|
+
## Labels and approval
|
|
52
|
+
|
|
53
|
+
- A new issue starts at `needs-you`. Add `risky` when it touches security, money, user data, or production.
|
|
54
|
+
- Approval is only the user's explicit words — "approved", "go ahead", clearly tied to this issue, in chat or on the issue. Labels, silence, or the passage of time never create approval.
|
|
55
|
+
- Record it once: comment `Approved by <user> on <date>: "<their words>"`, then swap `needs-you` → `ready`. That comment is what dev-implement's preflight looks for.
|
|
56
|
+
- An issue with an unconfirmed entry in its Assumptions section cannot go `ready` — the recorded approval covers the ledger the user saw, so resolve every entry (confirmed, corrected, or moved to a spike) first.
|
|
57
|
+
- An issue that settles a material cross-cutting decision records it as one comment starting `Decision:` — dev-ship appends that line to the project's decision register at merge.
|
|
58
|
+
- The user edits or corrects a draft → apply, and summarize what changed since they last read it.
|
|
59
|
+
|
|
60
|
+
## After approval
|
|
61
|
+
|
|
62
|
+
An approved issue that later needs a material change flips back to `needs-you` with one comment naming what changed; the new approval is recorded the same way. Small wording fixes that change no behavior don't reopen anything.
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
# Issue brief template
|
|
2
|
+
|
|
3
|
+
The issue body a `ready` issue must have. Write the sections that apply, delete the rest. The test for every section: would a fresh agent have to guess or ask without it?
|
|
4
|
+
|
|
5
|
+
```markdown
|
|
6
|
+
## Outcome
|
|
7
|
+
|
|
8
|
+
What exists when this is done, in observable terms — what the user can do, what the
|
|
9
|
+
system produces. One paragraph.
|
|
10
|
+
|
|
11
|
+
## Out of scope
|
|
12
|
+
|
|
13
|
+
The nearby things this issue deliberately does NOT do. This is what stops scope creep
|
|
14
|
+
in dark mode — name the tempting adjacent work.
|
|
15
|
+
|
|
16
|
+
## Rules and edge cases
|
|
17
|
+
|
|
18
|
+
The behavior that isn't obvious: validations, permissions, limits, empty/error/concurrent
|
|
19
|
+
cases, what happens on failure. Bullet list, one behavior per line.
|
|
20
|
+
|
|
21
|
+
## UI states <!-- only when there is UI -->
|
|
22
|
+
|
|
23
|
+
Loading, empty, error, success, disabled. Which design-system components. Copy for
|
|
24
|
+
user-facing text. Responsive and keyboard behavior when it matters.
|
|
25
|
+
|
|
26
|
+
## Approach and touch points
|
|
27
|
+
|
|
28
|
+
The chosen technical approach in a few lines: which parts of the codebase change,
|
|
29
|
+
new/changed interfaces or schemas, data migrations. Routine choices (file names,
|
|
30
|
+
helpers, fixtures) stay the implementer's — don't specify them.
|
|
31
|
+
|
|
32
|
+
## Tests and acceptance
|
|
33
|
+
|
|
34
|
+
What proves it works: the cases tests must cover (success, boundary, failure,
|
|
35
|
+
authorization where relevant) and the commands to run. Acceptance = the Outcome plus
|
|
36
|
+
these passing.
|
|
37
|
+
|
|
38
|
+
## Risks and stop conditions
|
|
39
|
+
|
|
40
|
+
What could go wrong and what should make the agent stop and ask instead of pushing
|
|
41
|
+
through — beyond the standing stop-list in .vegastack/dev.md.
|
|
42
|
+
|
|
43
|
+
## Assumptions — confirm or correct
|
|
44
|
+
|
|
45
|
+
Anything material the grounding investigation could not verify, one per line, each
|
|
46
|
+
awaiting the user's confirm/correct. The issue cannot go `ready` while one is
|
|
47
|
+
unconfirmed. Verified facts never appear here — they live in their section with
|
|
48
|
+
their evidence. Delete the section once every entry is resolved.
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
## Writing rules
|
|
52
|
+
|
|
53
|
+
- Inline over linked: the material details live in the issue itself. A link supports; it never substitutes.
|
|
54
|
+
- Concrete over abstract: "rejects amounts over 10,000 with error E402" beats "validates input".
|
|
55
|
+
- Evidence over confidence: touch points name real file paths; a dependency capability claim carries the doc check and its date; what couldn't be verified goes to Assumptions, never stated as fact.
|
|
56
|
+
- The brief binds the agent, so ambiguity is a bug in the brief — if two readings exist, the interview wasn't done.
|
|
@@ -0,0 +1,3 @@
|
|
|
1
|
+
# Refresh contract — dev-intake
|
|
2
|
+
|
|
3
|
+
Evergreen: this skill asserts no version pins, vendor mechanism names, numeric vendor limits, or dated facts — its content is interview discipline, slicing rules, the brief template, and the approval-recording rule, all versionless. The harness question-tool mechanics it leans on are tracked by `dev-setup`'s registry (see `skills/dev-setup/refresh/`). Revisit if a future edit introduces a volatile fact.
|