@vegastack/skills 0.10.0 → 0.11.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 +5 -0
- package/package.json +1 -1
- package/skill/dev-architect/SKILL.md +7 -4
- package/skill/dev-architect/references/conventions.md +93 -0
- package/skill/dev-chronicle/SKILL.md +45 -0
- package/skill/dev-chronicle/agents/openai.yaml +4 -0
- package/skill/dev-chronicle/references/conventions.md +93 -0
- package/skill/dev-chronicle/refresh/REFRESH.md +3 -0
- package/skill/dev-chronicle/refresh/sources.json +6 -0
- package/skill/dev-debug/SKILL.md +43 -0
- package/skill/dev-debug/agents/openai.yaml +4 -0
- package/skill/dev-debug/references/conventions.md +93 -0
- package/skill/dev-debug/references/loop-ladder.md +20 -0
- package/skill/dev-debug/refresh/REFRESH.md +3 -0
- package/skill/dev-debug/refresh/sources.json +6 -0
- package/skill/dev-implement/SKILL.md +41 -36
- package/skill/dev-implement/references/conventions.md +93 -0
- package/skill/dev-implement/references/ledger-and-resume.md +27 -0
- package/skill/dev-implement/scripts/evidence-check.mjs +57 -0
- package/skill/dev-implement/scripts/lib/gh.mjs +93 -0
- package/skill/dev-implement/scripts/preflight.mjs +101 -0
- package/skill/dev-intake/SKILL.md +39 -33
- package/skill/dev-intake/references/brief-template.md +27 -12
- package/skill/dev-intake/references/conventions.md +93 -0
- package/skill/dev-intake/scripts/brief-lint.mjs +87 -0
- package/skill/dev-plan/SKILL.md +53 -0
- package/skill/dev-plan/agents/openai.yaml +4 -0
- package/skill/dev-plan/references/conventions.md +93 -0
- package/skill/dev-plan/references/plan-format.md +54 -0
- package/skill/dev-plan/refresh/REFRESH.md +3 -0
- package/skill/dev-plan/refresh/sources.json +6 -0
- package/skill/dev-plan/scripts/plan-lint.mjs +86 -0
- package/skill/dev-review/SKILL.md +69 -0
- package/skill/dev-review/agents/openai.yaml +4 -0
- package/skill/dev-review/assets/review-known-patterns.md.template +30 -0
- package/skill/dev-review/references/conventions.md +93 -0
- package/skill/dev-review/references/cross-agent.md +39 -0
- package/skill/dev-review/references/dispatch-prompts.md +104 -0
- package/skill/dev-review/references/security-axis.md +33 -0
- package/skill/dev-review/refresh/REFRESH.md +3 -0
- package/skill/dev-review/refresh/sources.json +6 -0
- package/skill/dev-setup/SKILL.md +7 -5
- package/skill/dev-setup/assets/agents-section.md.template +2 -2
- package/skill/dev-setup/assets/dev-profile.md.template +4 -3
- package/skill/dev-setup/references/conventions.md +93 -0
- package/skill/dev-ship/SKILL.md +14 -7
- package/skill/dev-ship/references/conventions.md +93 -0
- package/skill/dev-ship/references/runbook.md +1 -1
- package/skill/dev-ship/scripts/ship-gate.mjs +213 -0
- package/skill/dev-status/SKILL.md +45 -0
- package/skill/dev-status/agents/openai.yaml +4 -0
- package/skill/dev-status/references/conventions.md +93 -0
- package/skill/dev-status/refresh/REFRESH.md +3 -0
- package/skill/dev-status/refresh/sources.json +6 -0
- package/skill/dev-status/scripts/status.mjs +152 -0
- package/skill/skillify/SKILL.md +1 -1
- package/skill/skillify/references/eval-playbook.md +6 -0
- package/skill-integrity.json +78 -14
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
// dev-plan guard: deterministic checks on a drafted plan comment. Placeholders
|
|
3
|
+
// and structural gaps block; nothing here warns. The banned-placeholder list's
|
|
4
|
+
// single home is this file — brief-lint defers inline-plan checks to it.
|
|
5
|
+
//
|
|
6
|
+
// Exit codes: 0 pass · 2 blocked (this guard has no warn class).
|
|
7
|
+
// Usage: node plan-lint.mjs --file <plan.md> --json
|
|
8
|
+
import { readFileSync } from 'node:fs';
|
|
9
|
+
import { resolve } from 'node:path';
|
|
10
|
+
import { fileURLToPath } from 'node:url';
|
|
11
|
+
// Self-contained on purpose: plan-lint ships with dev-plan and must run on a
|
|
12
|
+
// standalone install, so it carries its own tiny flag/result helpers instead of
|
|
13
|
+
// importing dev-implement's lib.
|
|
14
|
+
|
|
15
|
+
export const bannedPlaceholders = [
|
|
16
|
+
/\bTBD\b/,
|
|
17
|
+
/\bTODO\b/,
|
|
18
|
+
/implement later/i,
|
|
19
|
+
/fill in details/i,
|
|
20
|
+
/add appropriate error handling/i,
|
|
21
|
+
/\badd validation\b/i,
|
|
22
|
+
/handle edge cases/i,
|
|
23
|
+
/write tests for the above/i,
|
|
24
|
+
/similar to task \d+/i,
|
|
25
|
+
];
|
|
26
|
+
|
|
27
|
+
export function lintPlan(text) {
|
|
28
|
+
const blocks = [];
|
|
29
|
+
|
|
30
|
+
if (!/<!--\s*vsk:v1\s+type=plan\b/.test(text)) blocks.push('missing plan marker (<!-- vsk:v1 type=plan rev=n -->)');
|
|
31
|
+
|
|
32
|
+
for (const pattern of bannedPlaceholders) {
|
|
33
|
+
const hit = pattern.exec(text);
|
|
34
|
+
if (hit) blocks.push(`banned placeholder: "${hit[0]}" — plans carry the actual content`);
|
|
35
|
+
}
|
|
36
|
+
|
|
37
|
+
// A Task-header line not carried by a checkbox would otherwise be absorbed
|
|
38
|
+
// into the previous task's chunk and inherit its sections — detect it.
|
|
39
|
+
// Anchored to the line START so mid-line references ("consumes Task 2's
|
|
40
|
+
// output") never false-block.
|
|
41
|
+
for (const line of text.split('\n')) {
|
|
42
|
+
const t = line.trim();
|
|
43
|
+
if (/^(\*\*|[-*]\s+\*\*)?Task \d+:/.test(t) && !/^- \[[ x]\]/.test(t)) {
|
|
44
|
+
blocks.push(`task line without a checkbox: "${t.slice(0, 60)}"`);
|
|
45
|
+
}
|
|
46
|
+
}
|
|
47
|
+
|
|
48
|
+
const tasks = text.split(/^- \[[ x]\] \*\*Task /m).slice(1);
|
|
49
|
+
if (tasks.length === 0) blocks.push('no checkbox tasks found (- [ ] **Task N: ...**)');
|
|
50
|
+
tasks.forEach((task, index) => {
|
|
51
|
+
const n = index + 1;
|
|
52
|
+
if (!/Files\s*—/.test(task)) blocks.push(`task ${n}: missing "Files —" line with exact paths`);
|
|
53
|
+
if (!/Interfaces\s*—/.test(task)) blocks.push(`task ${n}: missing "Interfaces —" block (consumes/produces)`);
|
|
54
|
+
if (!/Steps[:\s]/.test(task)) blocks.push(`task ${n}: missing "Steps" line`);
|
|
55
|
+
if (/failing test/i.test(task) && !task.includes('```')) {
|
|
56
|
+
blocks.push(`task ${n}: a failing-test step must carry the actual test code in a fenced block`);
|
|
57
|
+
}
|
|
58
|
+
});
|
|
59
|
+
|
|
60
|
+
return { blocks, warns: [] };
|
|
61
|
+
}
|
|
62
|
+
|
|
63
|
+
const invokedDirectly = process.argv[1] && resolve(process.argv[1]) === fileURLToPath(import.meta.url);
|
|
64
|
+
if (invokedDirectly) {
|
|
65
|
+
const argv = process.argv.slice(2);
|
|
66
|
+
const json = argv.includes('--json');
|
|
67
|
+
const fileIndex = argv.indexOf('--file');
|
|
68
|
+
let outcome;
|
|
69
|
+
if (fileIndex === -1 || !argv[fileIndex + 1]) {
|
|
70
|
+
outcome = { blocks: ['usage: plan-lint.mjs --file <plan.md> [--json]'], warns: [] };
|
|
71
|
+
} else {
|
|
72
|
+
try {
|
|
73
|
+
outcome = lintPlan(readFileSync(argv[fileIndex + 1], 'utf8'));
|
|
74
|
+
} catch (error) {
|
|
75
|
+
outcome = { blocks: [`cannot read plan: ${error.message}`], warns: [] };
|
|
76
|
+
}
|
|
77
|
+
}
|
|
78
|
+
const ok = outcome.blocks.length === 0;
|
|
79
|
+
if (json) {
|
|
80
|
+
console.log(JSON.stringify({ guard: 'plan-lint', ok, ...outcome }, null, 2));
|
|
81
|
+
} else {
|
|
82
|
+
console.log(`plan-lint: ${ok ? 'pass' : 'BLOCKED'}`);
|
|
83
|
+
for (const b of outcome.blocks) console.log(` block: ${b}`);
|
|
84
|
+
}
|
|
85
|
+
process.exit(ok ? 0 : 2);
|
|
86
|
+
}
|
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dev-review
|
|
3
|
+
description: Independent review of finished implementation work — a diff against its brief and plan. Use when dev-implement's review step runs, when asked to "review this branch/diff/issue", "give this a second pair of eyes", "check the finished work on issue N", when a cross-agent session (Claude or Codex) is handed a REVIEW REQUEST, or when review findings need a fix loop, re-review, or adjudication. Not for reviewing an unbuilt plan (dev-plan's approval gate), architecture review (dev-architect), shipping gates (dev-ship), or generic PR review in repos outside this workflow.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# dev-review
|
|
7
|
+
|
|
8
|
+
Review is a specified system, not a vibe: fresh eyes per axis, severities with teeth, a bounded fix loop, and every dismissal on the record. The reviewer's job is findings or verified absence of findings — never praise. Formats follow the `dev-setup` skill's `references/conventions.md`; the reviewer briefs live in [dispatch-prompts](references/dispatch-prompts.md).
|
|
9
|
+
|
|
10
|
+
Nearest neighbors: `dev-implement` invokes this per dev.md's `review:` knob and applies the findings; `dev-ship` consumes the verdict marker; `dev-plan`'s approval gate reviews plans before build — this skill reviews built work after.
|
|
11
|
+
|
|
12
|
+
## Inputs — files, never pasted context
|
|
13
|
+
|
|
14
|
+
Build the review package first: `git log --oneline <base>..<head>` + `git diff --stat` + `git diff -U10`, written to `.vegastack/.tmp/<issue>-<slug>/review-<base7>..<head7>.diff`. Reviewers get paths — the brief (issue body), the plan comment, the package file, the project's `.vegastack/review-known-patterns.md` — plus the binding constraints copied verbatim. Reviewers write their full reports to `.tmp` files and return short status; a dead reviewer's findings survive on disk.
|
|
15
|
+
|
|
16
|
+
## The axes — parallel, fresh, never merged
|
|
17
|
+
|
|
18
|
+
| Axis | Runs | Judges |
|
|
19
|
+
|---|---|---|
|
|
20
|
+
| **Spec** | always | the diff vs the CURRENT brief + plan: missing, scope creep, implemented-but-wrong — quoting the brief line per finding; includes the tests-are-real rubric |
|
|
21
|
+
| **Standards** | always | project rules (known-patterns file + repo docs, which override) + the fixed smell baseline pasted in full into its prompt |
|
|
22
|
+
| **Security** | on `risky`, or when touch points hit auth, money, user data, or external input | data-flow traces, exploitability before severity — method in [security-axis](references/security-axis.md) |
|
|
23
|
+
|
|
24
|
+
Each axis is a fresh subagent with no memory of writing the code (its prompt: [dispatch-prompts](references/dispatch-prompts.md)). Axes report separately and are never re-ranked into one list — a change can pass one axis and fail another, and merging lets one mask the other.
|
|
25
|
+
|
|
26
|
+
**Never pre-judge.** A dispatch containing "do not flag…", "don't treat X as a defect", or "at most minor" is forbidden — if you believe something is a false positive, let the reviewer raise it and adjudicate it openly in the loop.
|
|
27
|
+
|
|
28
|
+
## The review comment — one per cycle, rounds appended, marker always current
|
|
29
|
+
|
|
30
|
+
One comment per review cycle. **The single marker at the top is edited every round** to the newest `round`/`sha`/`verdict` — consumers (ship-gate) read the first marker, so a stale round-1 `needs-fixes` must never sit above a clean round 3. Prior rounds stay as plain `## Review — round <n>` sections appended below, carrying no markers of their own.
|
|
31
|
+
|
|
32
|
+
```markdown
|
|
33
|
+
<!-- vsk:v1 type=review round=<n> sha=<head7> agent=<claude|codex> verdict=<clean|needs-fixes> -->
|
|
34
|
+
## Review — round <n> @ <sha7>
|
|
35
|
+
|
|
36
|
+
**Verdict: <clean|needs-fixes>** — spec: <counts> · standards: <counts> · security: <counts | n/a (no surface)>
|
|
37
|
+
|
|
38
|
+
### <Axis> axis
|
|
39
|
+
**Finding [N]: <title>** — **[SEVERITY]** (confidence: high|medium|low) `path/file.ts:42`
|
|
40
|
+
<issue> / <why it matters> / <fix, fenced snippet> / <quoted brief line, spec axis>
|
|
41
|
+
|
|
42
|
+
<details><summary>Nitpicks and low-confidence (N) — non-blocking</summary>…</details>
|
|
43
|
+
|
|
44
|
+
Reviewed: <sha7> · axes: <list> · reviewer: <mode>
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
Severities: `[CRITICAL]` (security axis: exploitable now — blocks) > `[MUST-FIX]` (wrong, broken, or contradicts the brief — blocks) > `[SHOULD-FIX]` (convention or quality, does not block) > `[NIT]`. Finding IDs are `Finding [N]` — never `#N`, which GitHub auto-links. Low-confidence findings and nitpicks go in the collapsed block, never the main list. Group one recurring defect across files into one finding with a location list.
|
|
48
|
+
|
|
49
|
+
## The loop — 3 rounds max, then open adjudication
|
|
50
|
+
|
|
51
|
+
`[CRITICAL]` and `[MUST-FIX]` findings enter the loop; `[SHOULD-FIX]`/`[NIT]` are fixed opportunistically or recorded as deferred minors — they never extend it.
|
|
52
|
+
|
|
53
|
+
- **Rounds 1–2:** resume (or redispatch) the implementer with the open findings verbatim and the report-file path. It fixes, re-runs the covering tests, appends its fix report to the same file.
|
|
54
|
+
- **Round 3:** a fresh implementer — "a prior implementer attempted this; read the report file for what was tried." A loop surviving two resumes usually means the implementer can't see its own problem.
|
|
55
|
+
- **Every round:** the re-review is scoped to the fix diff (`FIX_BASE..HEAD`, a new package file); the re-reviewer verdicts each finding **ADDRESSED / NOT ADDRESSED** ("attempted" is not addressed), and new breakage in the fix diff joins the open list. Out-of-scope observations become deferred minors.
|
|
56
|
+
- **At the cap:** adjudicate each open finding yourself, openly — parked with a ruling ("why the code stands"), or fixed forward — every adjudication lands in the evidence comment's Review line and the ledger. Adjudicating early to end a loop is pre-judging with a different name.
|
|
57
|
+
|
|
58
|
+
## Noise controls — hard filters, not politeness
|
|
59
|
+
|
|
60
|
+
- Default quiet profile: spec, bugs, and security always; style only where a documented rule exists. The comment count is the noise metric.
|
|
61
|
+
- `.vegastack/review-known-patterns.md` (seed: [template](assets/review-known-patterns.md.template)) holds the project's never-flag patterns — each entry REQUIRES a **"Still flag if:"** exception clause; a suppression without one is a blind spot. Operator dismissals of findings get appended there by dev-implement's corrections loop, so a dismissed pattern stays dismissed.
|
|
62
|
+
|
|
63
|
+
## Cross-agent — the independence upgrade
|
|
64
|
+
|
|
65
|
+
The dev.md `review:` knob maps to exactly three states — `subagent` (fresh-subagent axes always, cross-agent never), `cross-agent-risky` (subagent axes normally; the other agent on `risky` — the recommended default where the CLI exists), `cross-agent` (the other agent always). When it runs on the other agent, follow [cross-agent](references/cross-agent.md): announce the invocation to the operator at trigger time, send the `REVIEW REQUEST (vsk cross-agent v1)` handoff (`codex exec` from Claude; `claude -p` from Codex), and summarize the outcome at the end. The reviewing agent posts its own review comment (`agent=codex`), so independence is verifiable. CLI absent → fall back to the manual relay and note that dev-setup recommends installing it.
|
|
66
|
+
|
|
67
|
+
## Closing
|
|
68
|
+
|
|
69
|
+
End with the plain-language summary: verdict, what was found and fixed, what was adjudicated and why, and what's worth the operator double-checking.
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# Review known patterns — {{owner/repo}}
|
|
2
|
+
|
|
3
|
+
The project's never-flag list. Every entry REQUIRES a "Still flag if:" exception clause — a suppression without one is a blind spot, not a calibration. dev-implement's corrections loop appends an entry whenever the operator dismisses a review finding, so dismissed patterns stay dismissed. Repo-documented standards override the reviewer's baseline; this file overrides neither — it only suppresses specific recurring false positives.
|
|
4
|
+
|
|
5
|
+
Format, one entry per pattern:
|
|
6
|
+
|
|
7
|
+
```markdown
|
|
8
|
+
## <short pattern name>
|
|
9
|
+
|
|
10
|
+
**Pattern:** <what the reviewer keeps flagging, concretely — code shape, file area>
|
|
11
|
+
**Why it's safe here:** <the project fact that makes it a false positive>
|
|
12
|
+
**Still flag if:** <the exception that makes it a real finding after all>
|
|
13
|
+
**Origin:** <date + issue where the dismissal happened — operator (<username>)>
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
## Worked examples (replace with real entries)
|
|
17
|
+
|
|
18
|
+
### Sequential awaits in setup scripts
|
|
19
|
+
|
|
20
|
+
**Pattern:** consecutive `await` calls in bootstrap/setup code flagged as a parallelization miss.
|
|
21
|
+
**Why it's safe here:** setup steps have ordering dependencies the reviewer can't see locally (labels before issues, scaffold before wiring).
|
|
22
|
+
**Still flag if:** the awaits are inside a hot request path or a loop over user data.
|
|
23
|
+
**Origin:** seeded example — delete when the first real entry lands.
|
|
24
|
+
|
|
25
|
+
### Direct `gh` CLI calls without a wrapper
|
|
26
|
+
|
|
27
|
+
**Pattern:** scripts shelling to `gh` flagged as needing an API client abstraction.
|
|
28
|
+
**Why it's safe here:** the workflow standardizes on `gh` for auth and pagination; a wrapper would duplicate it.
|
|
29
|
+
**Still flag if:** arguments are interpolated into a shell string instead of an execFile arg array.
|
|
30
|
+
**Origin:** seeded example — delete when the first real entry lands.
|
|
@@ -0,0 +1,93 @@
|
|
|
1
|
+
# Workflow conventions
|
|
2
|
+
|
|
3
|
+
The single spec for the artifacts every dev-family skill reads and writes. One home per rule: skills cite this file, never restate it. Everything here is harness-neutral.
|
|
4
|
+
|
|
5
|
+
## Comment metadata markers
|
|
6
|
+
|
|
7
|
+
Every workflow-generated issue comment opens with an invisible HTML marker followed by a human heading:
|
|
8
|
+
|
|
9
|
+
```markdown
|
|
10
|
+
<!-- vsk:v1 type=<type> rev=<n> [key=value ...] -->
|
|
11
|
+
## <Human title> (v<n>)
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
| type | required keys | instances |
|
|
15
|
+
|---|---|---|
|
|
16
|
+
| `approval` | `scope=<brief\|brief+plan\|plan>` | one per approval event |
|
|
17
|
+
| `plan` | `rev` | one, edited in place |
|
|
18
|
+
| `ledger` | `branch` | one, edited in place |
|
|
19
|
+
| `evidence` | `rev branch sha` | one, edited in place |
|
|
20
|
+
| `review` | `round sha agent=<claude\|codex> verdict=<clean\|needs-fixes>` | one per review cycle, rounds appended inside |
|
|
21
|
+
| `decision` | — | one per decision proposal |
|
|
22
|
+
| `handback` | — | one per stop event |
|
|
23
|
+
|
|
24
|
+
`rev=<n>` and the matching `(v<n>)` heading suffix appear only on revisable artifacts — the brief (issue description), `plan`, and `evidence` — starting at `rev=1`/`(v1)`. Single-event comments (`approval`, `decision`, `handback`) and the `ledger` carry neither. Scripts and agents locate comments strictly by marker, never by heading text. A comment without its marker does not count as the artifact — there is no legacy fallback.
|
|
25
|
+
|
|
26
|
+
## Operator identity
|
|
27
|
+
|
|
28
|
+
Every human reference in every artifact — approvals, revisions, decisions, changelog attributions, review adjudications — is written `operator (<github-username>)`:
|
|
29
|
+
|
|
30
|
+
- Approval: `Approved by operator (<username>) on DD-MM-YYYY: "<their words>"`
|
|
31
|
+
- Register line: `- DD-MM-YYYY operator (<username>) — <decision>`
|
|
32
|
+
|
|
33
|
+
## Revision markers
|
|
34
|
+
|
|
35
|
+
Any artifact edited after its first approval: the heading gains `(v2)`, the marker gains `rev=2`, and a `Revisions:` line is appended at the bottom — `v2 — DD-MM-YYYY: <what changed>, per operator (<username>) correction`. Existing revision lines are never rewritten.
|
|
36
|
+
|
|
37
|
+
## Scope classes
|
|
38
|
+
|
|
39
|
+
Set at intake, applied as a label, announced with its reason (operator can override):
|
|
40
|
+
|
|
41
|
+
- **`research`** — a question to answer; throwaway code allowed, never merged. No branch/PR/changelog; findings + recommendation are the evidence comment.
|
|
42
|
+
- **`quick-build`** — small change and the flow being changed already exists in the repo to read. Brief (description) + plan (comment) are drafted in the same conversation; **one approval covers both**; then straight to `ready`.
|
|
43
|
+
- **`full-plan`** — big or new ground. Brief approval → `needs-plan` → a separate, fresh-grounded planning session posts the plan → `needs-operator` → "plan approved" → `ready`. Multi-deliverable work becomes an epic; each sub-issue is classified independently.
|
|
44
|
+
|
|
45
|
+
Scope calls are revisited through the one-way ratchet, whose rules and mechanics live in the `dev-plan` skill — the one home for upgrade/downgrade behavior.
|
|
46
|
+
|
|
47
|
+
## Labels
|
|
48
|
+
|
|
49
|
+
State — exactly one per issue (creation colors live in dev-setup's labels row, their one home):
|
|
50
|
+
|
|
51
|
+
| label | meaning |
|
|
52
|
+
|---|---|
|
|
53
|
+
| `needs-operator` | waiting on the operator: a question, a brief or plan to approve, a proposal |
|
|
54
|
+
| `needs-plan` | brief approved; waiting for the planning stage (full-plan only) |
|
|
55
|
+
| `ready` | fully approved — an agent may start |
|
|
56
|
+
| `working` | claimed, in progress; the ledger comment shows live progress |
|
|
57
|
+
| `for-operator` | done — evidence posted, awaiting operator review |
|
|
58
|
+
|
|
59
|
+
Modifiers (may coexist with the state label): `risky` · scope `research` / `quick-build` / `full-plan` · `epic` (map parents, only where the org has no native Epic issue type).
|
|
60
|
+
|
|
61
|
+
## Titles, types, hierarchy
|
|
62
|
+
|
|
63
|
+
- **Title prefixes** on issues, branches, and PRs identically: dev.md's `branch:` knob type list (that knob stays the list's one home) plus `research:` for research issues. PR title = issue title.
|
|
64
|
+
- **Native issue types** where the org defines them: Feature (feat) · Bug (fix) · Task (docs/chore/refactor/research) · Epic for parents (label fallback otherwise).
|
|
65
|
+
- **Hierarchy:** epic parent = map only (Destination · Decisions so far as one-line gists · Not clear yet · Out of scope), children attached as native sub-issues; issues = the unit of work (brief in description, own approvals/branch/PR/evidence); tasks = checkboxes **in the plan comment only**. Blockers use native issue dependencies; phases use milestones. Only issues — never epics — get `ready`. GitHub caps issue bodies and comments at ~65,536 characters; what a plan nearing that cap means is the `dev-plan` ratchet's call.
|
|
66
|
+
|
|
67
|
+
## The ledger
|
|
68
|
+
|
|
69
|
+
Maintained by the implement session as one comment, edited in place:
|
|
70
|
+
|
|
71
|
+
```markdown
|
|
72
|
+
<!-- vsk:v1 type=ledger branch=<branch> -->
|
|
73
|
+
## Ledger — <branch>
|
|
74
|
+
- Task <N>: complete (commits <base7>..<head7>[, review clean | K parked])
|
|
75
|
+
- Task <N>: fix round <R>/3 (<X> addressed, <Y> open — <one-liners>; commits <a>..<b>)
|
|
76
|
+
- Ruling: <what> — <why> — cost if wrong: <cost>
|
|
77
|
+
- Task <N>: parked — <finding> — Ruling: <why the code stands>
|
|
78
|
+
- Deferred minor: <one-liner>
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
**Resume protocol:** a fresh, compacted, or (operator-handed) takeover session reads, in order: the brief → the plan comment → the ledger → `git log` on the branch — **nothing else**. Tasks with a `complete` line are DONE, never re-executed; a task whose last line is a fix round resumes at the next round. After compaction, trust the ledger and `git log` over recollection. Every `Ruling:` line surfaces in the evidence comment — a ruling that dies with the session was a decision made in secret.
|
|
82
|
+
|
|
83
|
+
## `.vegastack/.tmp/` workspace
|
|
84
|
+
|
|
85
|
+
All transitory artifacts — subagent reports, review packages, plan drafts, extracted diffs — live at `.vegastack/.tmp/<issue-number>-<title-slug>/` (pre-issue intake drafts, which have no number yet: `.vegastack/.tmp/intake-<slug>/`), kept out of git by a self-ignoring `.gitignore` (`printf '*\n' > .vegastack/.tmp/.gitignore`, created on first use). Subagents write full reports to files there and return only short status — a dead subagent's findings survive on disk, and the primary session never holds full reports in context. The workspace lives in the working tree (never under `.git/`, which harnesses protect from writes).
|
|
86
|
+
|
|
87
|
+
## Verification gate
|
|
88
|
+
|
|
89
|
+
Before claiming any status: **IDENTIFY** the command that proves the claim → **RUN** it fresh and complete → **READ** the full output and exit code → only then claim, with the evidence. "Should pass", a previous run, or a subagent's say-so are never evidence. Guard scripts follow the same doctrine: machine-verifiable facts **block** (exit 2 with the reason); regex or judgment heuristics only **warn** — no AI inference inside guards, and an unverifiable state fails closed.
|
|
90
|
+
|
|
91
|
+
## Plain-language collaboration
|
|
92
|
+
|
|
93
|
+
Every skill run ends with a simple-language summary: what happened, which paths were taken — cross-agent invocations announced at trigger time AND summarized at the end — and what is worth the operator double-checking. Use mermaid or ASCII diagrams in issues wherever a picture beats prose. A vague or self-contradicting operator answer gets pushback with concrete options, never silent absorption.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Cross-agent review
|
|
2
|
+
|
|
3
|
+
The independence upgrade: the review runs on the *other* agent — Codex when Claude built the code, Claude when Codex did — so the reviewer shares no model, no session, and no authorship with the implementer. Used on `risky` issues by default and whenever dev.md's `review:` knob says `cross-agent`.
|
|
4
|
+
|
|
5
|
+
## Announce, invoke, summarize — the operator is never blind
|
|
6
|
+
|
|
7
|
+
1. **At trigger time**, tell the operator in plain language: "invoking Codex for the cross-agent review of issue #N" — before the call, not after.
|
|
8
|
+
2. **Invoke** non-interactively with the handoff below passed as ONE argument through an exec arg array — `execFile('codex', ['exec', handoff])` from Claude, `execFile('claude', ['-p', handoff])` from Codex — never interpolated into a shell string (the exact pattern this skill's own known-patterns template says to still-flag).
|
|
9
|
+
3. **At the end**, summarize: which agent reviewed, the verdict, where its comment is, and what's worth the operator double-checking.
|
|
10
|
+
|
|
11
|
+
## The handoff — exact format
|
|
12
|
+
|
|
13
|
+
```
|
|
14
|
+
REVIEW REQUEST (vsk cross-agent v1)
|
|
15
|
+
repo: <absolute path> · issue: <url> · branch: <name> · range: <base7>..<head7>
|
|
16
|
+
brief: the issue description (marker type=brief) · plan: the issue comment
|
|
17
|
+
marked type=plan · package: <path to the review package file> · known-patterns:
|
|
18
|
+
.vegastack/review-known-patterns.md · conventions: references/conventions.md inside ANY installed dev-family skill
|
|
19
|
+
(e.g. .claude/skills/dev-review/references/conventions.md — every dev skill ships a copy)
|
|
20
|
+
axes: spec, standards[, security]
|
|
21
|
+
output contract: post exactly ONE issue comment in the review-comment format
|
|
22
|
+
(marker: <!-- vsk:v1 type=review round=<n> sha=<head7> agent=codex verdict=... -->;
|
|
23
|
+
the reverse direction writes agent=claude);
|
|
24
|
+
on a re-review round, EDIT that same comment — update its single top marker to the
|
|
25
|
+
new round/sha/verdict and append the round section below (never a second marker,
|
|
26
|
+
never a second comment),
|
|
27
|
+
findings as Finding [N] with severities [CRITICAL|MUST-FIX|SHOULD-FIX|NIT] and
|
|
28
|
+
path:line evidence; nitpicks and low-confidence collapsed in <details>.
|
|
29
|
+
constraints: READ-ONLY — never commit, push, edit files, or change labels; your
|
|
30
|
+
only write is the review comment, via gh.
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
The reviewing agent posts its own comment with its own `agent=` key — independence stays verifiable in the record, never paraphrased by the author.
|
|
34
|
+
|
|
35
|
+
## Fallbacks and failure honesty
|
|
36
|
+
|
|
37
|
+
- The other agent's CLI is not installed → fall back to the manual relay (tell the operator which agent to point at the issue), and note that `dev-setup` records the gap and recommends installing it.
|
|
38
|
+
- The invocation fails or times out → say so plainly, fall back to a fresh-subagent review, and label the evidence comment's Review line accordingly — never silently substitute and call it cross-agent.
|
|
39
|
+
- The other agent's review misses the output contract (no marker, no severities) → treat its content as raw findings: post them yourself in the correct format with `agent=` credited, and note the reformatting.
|
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
# Reviewer dispatch prompts
|
|
2
|
+
|
|
3
|
+
The verbatim briefs each axis subagent receives. Compose with paths and constraints — never pasted history. Every dispatch carries the shared preamble, then its axis brief.
|
|
4
|
+
|
|
5
|
+
## Shared preamble (every axis)
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
You are a fresh-context reviewer with no memory of writing this change and no
|
|
9
|
+
stake in it passing. Inputs (read them all): the brief at <issue url or path>,
|
|
10
|
+
the plan comment (marker type=plan), the review package at <package path>, and
|
|
11
|
+
the constraints below, copied verbatim from the brief/plan:
|
|
12
|
+
|
|
13
|
+
<constraints block>
|
|
14
|
+
|
|
15
|
+
Write your FULL report to <report path> — complete findings there, each as:
|
|
16
|
+
Finding [N]: <title> — [SEVERITY] (confidence: high|medium|low) path:line,
|
|
17
|
+
issue, why it matters, fix (fenced snippet when code).
|
|
18
|
+
Return only short status: verdict, per-severity counts, and one line per
|
|
19
|
+
finding (title + severity + path:line) — the detail lives in the report file.
|
|
20
|
+
|
|
21
|
+
You do not dispatch subagents. Do all reading and judging yourself — a reviewer
|
|
22
|
+
you spawn duplicates this review at full cost and its opinion counts for
|
|
23
|
+
nothing in the process. Read full files where the diff needs context (30+
|
|
24
|
+
lines around a hunk) — diff-only review misses invariants.
|
|
25
|
+
|
|
26
|
+
Report findings or verified absence of findings, never praise. Do not soften a
|
|
27
|
+
finding because the change is large, late, or almost done.
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
## Spec axis brief
|
|
31
|
+
|
|
32
|
+
```
|
|
33
|
+
Judge the diff against the CURRENT brief and plan only:
|
|
34
|
+
(a) MISSING — requirements asked for that are absent or partial;
|
|
35
|
+
(b) SCOPE CREEP — behavior in the diff nobody asked for;
|
|
36
|
+
(c) WRONG — requirements that look implemented but don't do what the brief
|
|
37
|
+
says.
|
|
38
|
+
Quote the exact brief/plan line for every finding. If code and brief diverge
|
|
39
|
+
because the operator changed direction, that is still a finding — the brief
|
|
40
|
+
must be revision-updated before review can pass; say so.
|
|
41
|
+
|
|
42
|
+
Tests-are-real rubric — flag as [MUST-FIX] any acceptance-relevant test that is:
|
|
43
|
+
- implementation-coupled: mocks internal collaborators, asserts call
|
|
44
|
+
counts/order, or breaks on refactor without behavior change;
|
|
45
|
+
- tautological: the assertion recomputes the expected value the way the code
|
|
46
|
+
does, so it can never disagree;
|
|
47
|
+
- horizontal-sliced: bulk tests asserting imagined shapes rather than the
|
|
48
|
+
behavior the brief names.
|
|
49
|
+
A changed behavior with no covering test at the brief's named seams is MISSING.
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
## Standards axis brief
|
|
53
|
+
|
|
54
|
+
```
|
|
55
|
+
Judge the diff against, in priority order:
|
|
56
|
+
1. .vegastack/review-known-patterns.md — its never-flag entries suppress
|
|
57
|
+
findings UNLESS their "Still flag if:" clause applies;
|
|
58
|
+
2. the project's documented standards (dev.md Project rules, CONTRIBUTING);
|
|
59
|
+
a documented repo standard always overrides the baseline below;
|
|
60
|
+
3. the smell baseline — each a labeled judgment call ("possible feature
|
|
61
|
+
envy"), never a hard violation; skip anything tooling already enforces:
|
|
62
|
+
|
|
63
|
+
- Mysterious name: a name that doesn't reveal what it does or holds → rename.
|
|
64
|
+
- Duplicated code: the same logic shape in more than one hunk/file → extract.
|
|
65
|
+
- Feature envy: a method reaching into another object's data more than its
|
|
66
|
+
own → move it to the data it envies.
|
|
67
|
+
- Data clumps: the same fields/params traveling together → bundle into a type.
|
|
68
|
+
- Primitive obsession: a primitive standing in for a domain concept → type it.
|
|
69
|
+
- Repeated switches: the same case-cascade on the same type recurring → one
|
|
70
|
+
shared map or polymorphism.
|
|
71
|
+
- Shotgun surgery: one logical change forcing scattered edits everywhere →
|
|
72
|
+
gather it into one module.
|
|
73
|
+
- Divergent change: one module edited for several unrelated reasons → split.
|
|
74
|
+
- Speculative generality: abstraction or hooks for needs the brief doesn't
|
|
75
|
+
have → delete, inline until a real need shows.
|
|
76
|
+
- Message chains: long a.b().c().d() walks the caller depends on → hide the
|
|
77
|
+
walk behind one method.
|
|
78
|
+
- Middle man: a unit that mostly delegates onward → cut it, call direct.
|
|
79
|
+
- Refused bequest: an implementer ignoring most of what it inherits → compose
|
|
80
|
+
instead.
|
|
81
|
+
|
|
82
|
+
Quiet profile: report style only where a documented rule exists. Hard
|
|
83
|
+
violations of documented standards may be [MUST-FIX]; baseline smells are
|
|
84
|
+
[SHOULD-FIX] or [NIT].
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
## Security axis brief
|
|
88
|
+
|
|
89
|
+
Compose the security dispatch from [security-axis](security-axis.md): the shared preamble above, then that file's Method steps, finding format (the three extra lines), severity definitions, and standing red lines, quoted into the prompt — the reviewer must receive them in full, not a pointer it cannot follow.
|
|
90
|
+
|
|
91
|
+
## Re-review brief (scoped, every fix round)
|
|
92
|
+
|
|
93
|
+
```
|
|
94
|
+
Findings under verification: <the open findings, verbatim>.
|
|
95
|
+
Inputs: the same brief and plan, the implementer's report file (its fix
|
|
96
|
+
reports are the test evidence — do not re-run suites), and the SCOPED package
|
|
97
|
+
at <fix package path> covering only <FIX_BASE>..<HEAD>.
|
|
98
|
+
|
|
99
|
+
For each finding, in order: ADDRESSED or NOT ADDRESSED, with path:line
|
|
100
|
+
evidence. "Attempted" is not addressed — the specific defect must no longer
|
|
101
|
+
exist. Then: new breakage the fix diff itself introduced (severity + line),
|
|
102
|
+
and out-of-scope observations (non-blocking, one line each). Final line:
|
|
103
|
+
"Fix round: all addressed | findings remain open".
|
|
104
|
+
```
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# The security axis
|
|
2
|
+
|
|
3
|
+
Runs on `risky` issues, and whenever the diff's touch points hit an auth surface, money, user data, or externally-controlled input — the trigger is the surface, not the label alone.
|
|
4
|
+
|
|
5
|
+
## Method — evidence before severity
|
|
6
|
+
|
|
7
|
+
1. **Trace the data flow** for every candidate finding: origin → transformations → sink. Is the value attacker-controlled at the point of use? A finding without a traced flow is a hunch, not a finding.
|
|
8
|
+
2. **Check defense in depth before flagging a gap.** A missing check at one layer is not a vulnerability if another layer enforces it on every path — name the enforcing layer instead. Flag it only when no layer holds, or the only holding layer is UX (client-side, middleware-as-convenience).
|
|
9
|
+
3. **Verify library defaults** before "missing configuration" findings — frameworks ship safe defaults more often than training-data memory suggests; check the current docs per `dev-architect`'s verify protocol.
|
|
10
|
+
4. **Assess exploitability**: what does the attacker need (auth level, network position, timing, knowledge)? What mitigating controls exist? Severity follows exploitability, never vibes.
|
|
11
|
+
|
|
12
|
+
## Finding format — three extra lines
|
|
13
|
+
|
|
14
|
+
On top of the standard finding shape, every security finding carries:
|
|
15
|
+
|
|
16
|
+
```
|
|
17
|
+
Data flow: <origin> → <transformations> → <sink>
|
|
18
|
+
Attack prerequisites: <what the attacker needs>
|
|
19
|
+
Mitigating controls: <existing defenses that reduce but don't eliminate>
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
A finding that can't fill the Data flow line goes to the collapsed low-confidence block, not the main list.
|
|
23
|
+
|
|
24
|
+
## Severity
|
|
25
|
+
|
|
26
|
+
- **[CRITICAL]** — exploitable now: auth bypass at the enforcement layer, injection with a traced user-input path, secret/credential exposure, unprotected sensitive mutation. Blocks, above MUST-FIX.
|
|
27
|
+
- **[MUST-FIX]** — a real weakness needing prerequisites an attacker can plausibly meet.
|
|
28
|
+
- **[SHOULD-FIX]** — hardening: rate limits, PII in logs, missing timeouts, defense-in-depth gaps with a holding layer.
|
|
29
|
+
- Never round up to look thorough; judge against the project's Architecture facts — platform-scale concerns are not defects on a small internal tool.
|
|
30
|
+
|
|
31
|
+
## Standing red lines (summary — `dev-architect` remains their home)
|
|
32
|
+
|
|
33
|
+
Middleware/proxy is never the authorization boundary; authorization lives server-side per resource. No secret in plaintext anywhere — code, config, logs, events, agent state. Permission checks fail closed, and the deny is still audited.
|
|
@@ -0,0 +1,3 @@
|
|
|
1
|
+
# Refresh contract — dev-review
|
|
2
|
+
|
|
3
|
+
Evergreen: this skill asserts no version pins, numeric vendor limits, or dated claims — its content is review discipline (axes, severities, the bounded loop, dispatch briefs, the smell baseline, cross-agent handoff shape), all versionless. The `codex exec` / `claude -p` invocation forms are deliberately treated as durable CLI surfaces; dev-setup's detection covers their presence per machine. Revisit if a future edit introduces a volatile fact.
|
package/skill/dev-setup/SKILL.md
CHANGED
|
@@ -1,11 +1,11 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: dev-setup
|
|
3
|
-
description: Bootstrap a project for issue-driven agent development — existing repo or brand-new empty directory. Use when asked to "set up the dev workflow", "bootstrap this project for agents", "install the dev workflow here", "set up this new project",
|
|
3
|
+
description: Bootstrap a project for issue-driven agent development — existing repo or brand-new empty directory. Use when asked to "set up the dev workflow", "bootstrap this project for agents", "install the dev workflow here", "set up this new project", "wire the release guards", "create the workflow labels", "set up the changelog convention", "fill the architecture profile section", to re-run setup after machinery appeared or knobs changed, or invoked as dev-setup; also run automatically when any dev-family skill finds no .vegastack/dev.md in the project. Not for architecture advice (dev-architect reads the section this skill writes), authoring skills (skillify), or general CI and app scaffolding.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# dev-setup
|
|
7
7
|
|
|
8
|
-
Re-runnable bootstrap that gives a project everything the dev workflow needs: a profile file holding the knobs and runbooks, a thin AGENTS.md section that both Claude Code and Codex read, the GitHub labels, and the decision register. The other dev skills call this automatically when `.vegastack/dev.md` is missing, then continue with their original request.
|
|
8
|
+
Re-runnable bootstrap that gives a project everything the dev workflow needs: a profile file holding the knobs and runbooks, a thin AGENTS.md section that both Claude Code and Codex read, the GitHub labels, and the decision register. The other dev skills call this automatically when `.vegastack/dev.md` is missing, then continue with their original request. The workflow-wide artifact spec — comment markers, operator identity, revision markers, scope classes, ledger format, `.vegastack/.tmp/` workspace — lives in [conventions](references/conventions.md); dev skills cite it rather than restating it (the v3 rewrites adopt it skill by skill).
|
|
9
9
|
|
|
10
10
|
Nearest neighbor: `dev-architect` consumes dev.md's `## Architecture` section and gives architecture advice; dev-setup detects the facts and writes the section. There is no separate architecture profile — dev.md is the one file.
|
|
11
11
|
|
|
@@ -24,6 +24,8 @@ Facts are your job; decisions are the user's. Gather these silently and present
|
|
|
24
24
|
| architecture (app repos) | wrangler files (a `d1_databases` binding with no Postgres driver = the D1-only class), drizzle config, better-auth usage, `@aws-sdk/client-s3`/R2 bindings, pg-boss dependency, `eve`/`ai` packages, Dockerfiles/compose, pubspec.yaml — these draft `## Architecture` |
|
|
25
25
|
| existing files | AGENTS.md, CLAUDE.md, `.vegastack/dev.md`, a legacy `.vegastack/arch.md`, the decision register |
|
|
26
26
|
| existing labels | `gh label list` |
|
|
27
|
+
| native issue types | `gh api orgs/<org>/issue-types` — an `Epic` type routes parents to it; absent endpoint or type → the `epic` label fallback ([conventions](references/conventions.md)) |
|
|
28
|
+
| Codex CLI (cross-agent review) | `command -v codex` — absent → record the gap in dev.md `## Environments` and recommend installing it |
|
|
27
29
|
|
|
28
30
|
Not a git repo, or no origin remote → this is a **greenfield run, not an error**: follow the greenfield playbook in [stack-playbooks](references/stack-playbooks.md) — interview for the intended stack, offer `git init` and `gh repo create` each on its own yes, and render dev.md from the chosen playbook's conventions with TODO lines where machinery doesn't exist yet. A declined remote skips labels and records the TODO plainly.
|
|
29
31
|
|
|
@@ -35,7 +37,7 @@ Ask with your harness's question tool — AskUserQuestion in Claude Code, `reque
|
|
|
35
37
|
|
|
36
38
|
**Round B — the workflow knobs**, recommended default first:
|
|
37
39
|
|
|
38
|
-
1. Review of finished work: **
|
|
40
|
+
1. Review of finished work (`review:` knob, mapped by dev-review): **cross-agent-risky** (subagent axes, the other agent on `risky` — recommended where the Codex CLI was detected; otherwise recommend `subagent`) · `subagent` (never cross-agent) · `cross-agent` (always)
|
|
39
41
|
2. Proof for UI work: **playwright screenshots** · none
|
|
40
42
|
3. Gates: **3** (approve → PR → merge as separate user words) · 2 (approve → one "ship it" covers PR and merge) · 1 (direct-to-main for single-operator projects: the ship word merges locally and pushes, no PR — everything else unchanged)
|
|
41
43
|
4. Tests: **required for every change** · required for logic changes only
|
|
@@ -62,8 +64,8 @@ Everything else — merge style, branch naming, the stop-and-ask list — takes
|
|
|
62
64
|
| `.vegastack/dev.md` | render [dev-profile template](assets/dev-profile.md.template) with the answers — the project's single canonical process doc (short directional bullets; Ship/Verify/Environments/Design drafted from the playbook, Architecture drafted from detection, Decisions test included, placeholders deleted, TODO lines where machinery is absent) |
|
|
63
65
|
| `AGENTS.md` | create it, or insert/replace only the block between `<!-- vsk-dev:start -->` and `<!-- vsk-dev:end -->` using the [agents-section template](assets/agents-section.md.template); content outside the markers is the user's and stays untouched |
|
|
64
66
|
| `CLAUDE.md` | ensure its first line is `@AGENTS.md` — Claude Code does not read AGENTS.md natively and needs this import ([harness-facts](references/harness-facts.md)); create the file when absent |
|
|
65
|
-
| labels | `gh label create <name> --color <hex> --description "<text>"` for the names the `labels:` knob records, skipping ones that exist; default names and creation colors: `needs-operator` FBCA04
|
|
66
|
-
| decision register | create the file the `decisions:` knob names (default `.vegastack/decisions.md`) when missing, with a two-line header stating the format: `- DD-MM-YYYY (github-username) — the decision` (username via `gh api user -q .login`, fallback `git config user.name`); a project with an existing register keeps it and the knob points there |
|
|
67
|
+
| labels | `gh label create <name> --color <hex> --description "<text>"` for the names the `labels:` knob records, skipping ones that exist; default names and creation colors ([conventions](references/conventions.md) holds meanings): state `needs-operator` FBCA04 · `needs-plan` E36209 · `ready` 0E8A16 · `working` 1D76DB · `for-operator` 5319E7; modifiers `risky` B60205 · scope `research` C5DEF5 · `quick-build` 76C7C0 · `full-plan` 2A9D8F · `epic` 24292E (only when the org has no native Epic issue type) |
|
|
68
|
+
| decision register | create the file the `decisions:` knob names (default `.vegastack/decisions.md`) when missing, with a two-line header stating the format: `- DD-MM-YYYY operator (github-username) — the decision` (username via `gh api user -q .login`, fallback `git config user.name`); a project with an existing register keeps it and the knob points there |
|
|
67
69
|
| guard workflows / hook files | only the ones the user said yes to in Round C |
|
|
68
70
|
|
|
69
71
|
## Step 4 — Report
|
|
@@ -1,9 +1,9 @@
|
|
|
1
1
|
<!-- vsk-dev:start -->
|
|
2
2
|
## Dev workflow
|
|
3
3
|
|
|
4
|
-
Read `.vegastack/dev.md` for this project's stack, commands, and workflow knobs.
|
|
4
|
+
Read `.vegastack/dev.md` for this project's stack, commands, and workflow knobs. The workflow's stages are the dev-family skills: dev-setup (bootstrap) · dev-intake (ideas to briefs) · dev-plan (approved briefs to plans) · dev-architect (stack judgment) · dev-implement (dark builds) · dev-debug (reproduce-first fixes) · dev-review (independent review) · dev-ship (gated landing) · dev-status (the operator's board) · dev-chronicle (the project's story).
|
|
5
5
|
|
|
6
|
-
Work flows through GitHub issues. An issue labeled `ready` carries the user's recorded approval and a complete brief — implement it end to end per the `dev-implement` skill, post the evidence in the issue, and hand it back with `for-operator`. Start only on `ready` issues. The workflow vocabulary is the labels dev.md's `labels:` knob names (defaults: `needs-operator` waiting on the user → `ready` approved → `working` claimed
|
|
6
|
+
Work flows through GitHub issues. An issue labeled `ready` carries the user's recorded approval and a complete brief — implement it end to end per the `dev-implement` skill, post the evidence in the issue, and hand it back with `for-operator`. Start only on `ready` issues. The workflow vocabulary is the labels dev.md's `labels:` knob names (defaults — state: `needs-operator` waiting on the user → `needs-plan` awaiting the planning stage → `ready` approved → `working` claimed → `for-operator` result awaiting review; modifiers: `risky` for security/money/data/production, scope `research`/`quick-build`/`full-plan`, `epic` on map parents) — use them and no others. Artifact formats (comment markers, ledger, revisions, operator identity) follow the dev-setup skill's `references/conventions.md`.
|
|
7
7
|
|
|
8
8
|
**Nothing ships without the operator's explicit instruction** — no push to the default branch, merge, tag, publish, or deploy on green checks, schedules, or standing approvals alone. The `gates` knob in dev.md changes how many of those actions one instruction covers, never whether an instruction is needed. Behavior changes carry their changelog entry per dev.md's `changelog:` knob before hand-back; after merge, the `## Ship` runbook in dev.md says what happens next and which steps need the operator's word.
|
|
9
9
|
|
|
@@ -9,17 +9,18 @@ authority: {{ordered — e.g. "CONTRIBUTING.md → this file → skill defaults"
|
|
|
9
9
|
|
|
10
10
|
## Knobs
|
|
11
11
|
|
|
12
|
-
review:
|
|
12
|
+
review: cross-agent-risky # subagent (never cross-agent) | cross-agent-risky (other agent on risky) | cross-agent (always) — dev-review maps these
|
|
13
13
|
ui-evidence: playwright # playwright | none
|
|
14
14
|
evidence-repo: {{owner}}/dev-review-evidence # shared across projects; this project's folder = repo name; delete the line when ui-evidence is none
|
|
15
15
|
gates: 3 # 3 = approve/PR/merge · 2 = approve + one "ship it" · 1 = direct-to-main, ship word merges locally and pushes, no PR
|
|
16
16
|
tests: required # required | logic-only
|
|
17
17
|
merge: squash
|
|
18
18
|
branch: <type>/<issue>-<slug> # type: feat | fix | docs | chore | refactor — the only place this list lives
|
|
19
|
-
labels: needs-operator ready working for-operator risky
|
|
19
|
+
labels: needs-operator needs-plan ready working for-operator risky research quick-build full-plan epic # epic label marks map parents only where the org has no native Epic issue type
|
|
20
20
|
changelog: {{changesets | keep-a-changelog | pubspec+changelog | none (reason)}}
|
|
21
21
|
decisions: .vegastack/decisions.md
|
|
22
22
|
release: on-request # per-merge = Ship runbook runs as part of shipping · on-request = only when the operator says "release"
|
|
23
|
+
chronicle: on # on = dev-implement writes a .vegastack/chronicle.md story entry per behavior-changing branch · off
|
|
23
24
|
|
|
24
25
|
## Ship — what happens after merge, in order
|
|
25
26
|
|
|
@@ -66,7 +67,7 @@ mobile: {{no | flutter (separate repo)}}
|
|
|
66
67
|
|
|
67
68
|
Record a decision only when it is directional — it steers work beyond this issue: a real alternative was rejected; it constrains work not yet written; and no dev.md line, lint rule, or guard can enforce it instead (if one can, write the rule). Feature requests, one-off fixes, and routine implementation choices never qualify. Every entry needs the user's explicit yes. One line in the register (`decisions:` knob), append-only, no other metadata:
|
|
68
69
|
|
|
69
|
-
- DD-MM-YYYY (github-username) — the decision
|
|
70
|
+
- DD-MM-YYYY operator (github-username) — the decision
|
|
70
71
|
|
|
71
72
|
## Stop and ask
|
|
72
73
|
|