@jakkrichm/create-nexus-devflow 2.5.0 → 2.6.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +58 -45
- package/dist/lib/branch-context.d.ts +61 -8
- package/dist/lib/branch-context.js +362 -125
- package/dist/lib/branch-context.js.map +1 -1
- package/dist/lib/core-skill-inventory.d.ts +16 -0
- package/dist/lib/core-skill-inventory.js +96 -0
- package/dist/lib/core-skill-inventory.js.map +1 -0
- package/dist/lib/doctor.js +13 -10
- package/dist/lib/doctor.js.map +1 -1
- package/dist/lib/status.d.ts +2 -0
- package/dist/lib/status.js +7 -2
- package/dist/lib/status.js.map +1 -1
- package/dist/lib/update.js +5 -8
- package/dist/lib/update.js.map +1 -1
- package/dist/scripts/prepare-template.js +19 -16
- package/dist/scripts/prepare-template.js.map +1 -1
- package/package.json +1 -1
- package/template/.agents/skills/adopt/SKILL.md +1 -1
- package/template/.agents/skills/audit/SKILL.md +1 -1
- package/template/.agents/skills/autopilot/SKILL.md +1 -1
- package/template/.agents/skills/brainstorm/SKILL.md +1 -1
- package/template/.agents/skills/brief/SKILL.md +1 -1
- package/template/.agents/skills/check/SKILL.md +80 -75
- package/template/.agents/skills/ci/SKILL.md +1 -1
- package/template/.agents/skills/complete/SKILL.md +9 -3
- package/template/.agents/skills/convert-any-to-md/SKILL.md +1 -1
- package/template/.agents/skills/debug/SKILL.md +76 -94
- package/template/.agents/skills/devflow/SKILL.md +1 -1
- package/template/.agents/skills/discovery/SKILL.md +7 -9
- package/template/.agents/skills/doctor/SKILL.md +1 -1
- package/template/.agents/skills/feature/SKILL.md +10 -5
- package/template/.agents/skills/fix/SKILL.md +6 -8
- package/template/.agents/skills/grill/SKILL.md +1 -1
- package/template/.agents/skills/idea/SKILL.md +1 -1
- package/template/.agents/skills/implement/SKILL.md +10 -4
- package/template/.agents/skills/onboard/SKILL.md +1 -1
- package/template/.agents/skills/overview/SKILL.md +1 -1
- package/template/.agents/skills/prototype/SKILL.md +1 -1
- package/template/.agents/skills/release/SKILL.md +1 -1
- package/template/.agents/skills/report-html/SKILL.md +1 -1
- package/template/.agents/skills/rollback/SKILL.md +1 -1
- package/template/.agents/skills/status/SKILL.md +1 -1
- package/template/.agents/skills/test/SKILL.md +1 -1
- package/template/.agents/skills/tests/SKILL.md +1 -1
- package/template/.agents/skills/try/SKILL.md +1 -1
- package/template/.claude/skills/adopt/SKILL.md +1 -1
- package/template/.claude/skills/audit/SKILL.md +1 -1
- package/template/.claude/skills/autopilot/SKILL.md +1 -1
- package/template/.claude/skills/brainstorm/SKILL.md +1 -1
- package/template/.claude/skills/brief/SKILL.md +1 -1
- package/template/.claude/skills/check/SKILL.md +80 -75
- package/template/.claude/skills/ci/SKILL.md +1 -1
- package/template/.claude/skills/complete/SKILL.md +9 -3
- package/template/.claude/skills/convert-any-to-md/SKILL.md +1 -1
- package/template/.claude/skills/debug/SKILL.md +76 -94
- package/template/.claude/skills/devflow/SKILL.md +1 -1
- package/template/.claude/skills/discovery/SKILL.md +7 -9
- package/template/.claude/skills/doctor/SKILL.md +1 -1
- package/template/.claude/skills/feature/SKILL.md +10 -5
- package/template/.claude/skills/fix/SKILL.md +6 -8
- package/template/.claude/skills/grill/SKILL.md +1 -1
- package/template/.claude/skills/idea/SKILL.md +1 -1
- package/template/.claude/skills/implement/SKILL.md +10 -4
- package/template/.claude/skills/onboard/SKILL.md +1 -1
- package/template/.claude/skills/overview/SKILL.md +1 -1
- package/template/.claude/skills/prototype/SKILL.md +1 -1
- package/template/.claude/skills/release/SKILL.md +1 -1
- package/template/.claude/skills/report-html/SKILL.md +1 -1
- package/template/.claude/skills/rollback/SKILL.md +1 -1
- package/template/.claude/skills/status/SKILL.md +1 -1
- package/template/.claude/skills/test/SKILL.md +1 -1
- package/template/.claude/skills/tests/SKILL.md +1 -1
- package/template/.claude/skills/try/SKILL.md +1 -1
- package/template/AGENTS.md +1 -1
- package/template/devflow/build-plan.md +10 -0
- package/template/devflow/context/ai-interaction.md +5 -6
- package/template/devflow/context/coding-standards.md +31 -6
- package/template/devflow/context/current-stage.md +10 -7
- package/template/devflow/history/HISTORY.md +1 -1
- package/template/devflow/project-plan.md +2 -2
- package/template/devflow/reference/running-id-contract.md +24 -20
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: grill
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Interactive Socratic alignment & domain modeling - stress-test plans, extract domain glossary, and record architecture decision records (ADRs) before delivery."
|
|
4
4
|
argument-hint: "{topic, plan, or question}"
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: idea
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Quick idea capture and AI enrichment - analyze feasibility, value, key points, and record into devflow/ideas.md inbox."
|
|
4
4
|
argument-hint: "\"<idea text or description>\""
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -1,9 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: implement
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Build the feature, fix, or rollback spec, one small reviewable step at a time with Strict TDD. Supports Multi-Run: given an optional ID or name (/implement 12, /implement 012), targets that spec from devflow/context/{xxx-slug}/. Checks out matching branch, runs pre-flight drift revalidation, executes TDD steps with diffs, and offers commit checkpoints. Use when running /implement, or starting work on a spec."
|
|
4
|
+
argument-hint: "[{run-id, number, or name}]"
|
|
4
5
|
---
|
|
5
6
|
|
|
6
|
-
# implement - build the
|
|
7
|
+
# implement - build the target spec, one reviewed step at a time
|
|
7
8
|
|
|
8
9
|
Where this sits in the workflow:
|
|
9
10
|
|
|
@@ -12,7 +13,7 @@ Where this sits in the workflow:
|
|
|
12
13
|
reviewed) merge + log)
|
|
13
14
|
|
|
14
15
|
`/feature`, `/fix`, or `/rollback` wrote the spec to
|
|
15
|
-
`devflow/context/current-feature.md` and stopped.
|
|
16
|
+
`devflow/context/{xxx-slug}/spec.md` (or `devflow/context/current-feature.md`) and stopped.
|
|
16
17
|
This skill turns that spec into code, following the build loop in
|
|
17
18
|
`devflow/context/ai-interaction.md`, without vibe coding: small steps, a visible diff plus
|
|
18
19
|
a plain-English explanation for each, testing, and iteration until it works, all
|
|
@@ -20,9 +21,14 @@ behind your approval. It builds on a branch and offers an optional commit
|
|
|
20
21
|
checkpoint after each step; the work-level commit, merging, and logging are
|
|
21
22
|
`/complete`'s job.
|
|
22
23
|
|
|
24
|
+
## Multi-Run Target Resolution
|
|
25
|
+
|
|
26
|
+
- **Given an ID or name** (e.g. `/implement 12`, `/implement 012`, `/implement kanban`) -> locates the matching run folder `devflow/context/{xxx-slug}/`, checks out `feature/{xxx-slug}`, and loads only that run's `spec.md`.
|
|
27
|
+
- **With no argument** (`/implement`) -> checks current git branch, or auto-picks if only 1 spec is active, or prompts the user if multiple specs are queued.
|
|
28
|
+
|
|
23
29
|
## Before you start
|
|
24
30
|
|
|
25
|
-
Read `devflow/context/current-feature.md
|
|
31
|
+
Read the target spec from `devflow/context/{xxx-slug}/spec.md` (or `devflow/context/current-feature.md`). If it has no real spec (still the stub, or its
|
|
26
32
|
status is already complete), stop and tell the user to run `/feature` (for a
|
|
27
33
|
planned feature), `/fix` (for an ad-hoc bug or change), or `/rollback` (for a
|
|
28
34
|
completed feature reversal) first. Pull the
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: onboard
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Set up the Blueprint after overlaying it onto a freshly scaffolded or early project. Detects the stack, tunes project files and adapters, documents real commands and existing checks, points to the optional standalone CI setup, and tells the user what to fill in before /overview or $overview. Use when the user runs /onboard, invokes $onboard, just copied the Blueprint into a new project, or asks what to do after overlaying the Blueprint. For an existing app with meaningful shipped features, use adopt instead."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# onboard - finish the Blueprint overlay setup
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: overview
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Distill user-owned planning docs into `devflow/context/project-overview.md` using a deterministic compiler. The overview is the living source of truth that agents read every session."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# overview - dynamic project overview compiler
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: prototype
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Interactively prototype the look of a project. Asks about the desired look and feel and which pages to draft, proposes a plan, and only then writes throwaway static HTML/CSS mockups to prototypes/ that share one theme (a set of CSS theme variables). A plan-first, pre-build helper that sits outside the spec-driven feature loop, like scaffolding. Use when the user runs /prototype, names screens to mock up, or asks to prototype the layout, theme, or look and feel."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# prototype - lock the look before you build
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: release
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Prepare a Blueprint project for deployment to Render or Vercel. Reads the plans, project commands, app config, and current repo state; verifies build, start, output, env, health checks, and provider config; can create or update render.yaml or vercel.json when requested; and stops before any external deploy, service creation, remote env change, push, publish, or destructive action unless the user explicitly approves. Use when the user runs /release, invokes $release, asks for Render setup, Vercel setup, deploy readiness, deployment config, render.yaml, or vercel.json."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# release - deployment readiness for Render and Vercel
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: report-html
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Standalone HTML Report Generator - render an interactive standalone HTML dashboard from current-feature.md or 60-report.md on demand."
|
|
4
4
|
argument-hint: "{running-id or workspace path}"
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: rollback
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Plan a safe reversal of a completed Blueprint feature using its archived spec and squashed git commit. Finds the exact feature commit, reviews later commits for dependency risk, writes a Type: Rollback spec to devflow/context/current-feature.md, and stops for review before /implement applies any code change. Use when the user runs /rollback, asks to remove or undo a completed feature, or wants to return the app to its pre-feature behavior without erasing Blueprint history."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# rollback - safely reverse a completed feature
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: status
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Show where the project stands: build-plan progress, the current feature's checked and unchecked steps, git state, drift warnings, and the exact next action. Read-only. Use when the user runs /status, asks where things stand, what's next, what's in progress, or is picking work back up after a break or a context clear."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# status - where the project stands right now
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: test
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Test execution, missing test generation, and coverage analysis across unit, integration, and smoke test suites."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Test-Driven Development, Generation & Execution
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: tests
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Add or normalize unit testing for a Blueprint project. Detects the stack, reuses an existing test runner when present, or installs the stack-native unit test runner when missing, then adds one small example test, updates AGENTS.md commands, runs build and tests, and reports the diff. Use when the user runs /tests, invokes $tests, asks to add unit tests, set up unit testing, configure tests, or make tests part of the Blueprint workflow."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# tests - add unit testing to the project
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: try
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Generate a human manual try guide for the current or most recently completed Blueprint feature, fix, or rollback. Reads the spec, project commands, and available app context, then tells the user exactly what to start, where to go, what to click or run, what to expect, and what would count as wrong. Read-only. Use when the user runs /try, invokes $try, asks how to test manually, asks where to click, asks how to see the change, or wants a manual review path after /implement, /autopilot, /check, or /complete."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# try - manual review guide
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: adopt
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Bring the blueprint into an existing (brownfield) codebase. Surveys the real repo, interviews for intent, generates the owned plans and coding standards, documents existing verification and CI, asks whether DevFlow workflow files should be committed or kept local-only, and points to the optional standalone CI setup. Use when the user runs /adopt, is overlaying the blueprint onto an app that already has meaningful code, or asks to adopt or bootstrap the workflow into an existing project. For freshly scaffolded or early projects, use onboard instead."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# adopt - bootstrap the blueprint from an existing codebase
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: audit
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Read-only code audit for a Blueprint project, except for the findings ledger it maintains at devflow/context/findings.md. Reviews the active feature, changed files, a selected path, or the full project through all concerns or a focused quality, security, performance, or tests lens. Use when the user runs /audit, invokes $audit, asks for a code or quality audit, security review, performance review, test quality review, dead-code or duplication check, vibe-coded project cleanup, or standards review."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# audit - review code quality against the project standards
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: autopilot
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Optional explicit Blueprint mode for one bounded spec/build/check/audit pass. It can pick or resume the current feature, write the spec when needed, create or reuse the branch, implement small steps, run build/tests/checks, create checkpoint commits after passing steps, audit changed code, repair confirmed high-severity findings, and stop with a review packet. It never completes, merges, pushes, deploys, publishes, sends, or performs destructive actions without explicit approval. Use only when the user explicitly runs /autopilot, invokes $autopilot, or directly asks for Autopilot."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# autopilot - optional Blueprint loop
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: brainstorm
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Companion skill for structured divergent and convergent ideation, generating 2-3 viable options with trade-off analysis before committing to delivery."
|
|
4
4
|
argument-hint: "{topic, feature, or discovery-id}"
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: brief
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Read-only briefing on an upcoming build-plan feature before you spec it. With no argument, briefs the next unchecked item; given a number or name, briefs that one. Reads build-plan.md and project-overview.md and explains what the feature is, what it depends on, what it will touch, how big it is, and whether it will split - without writing anything. Use when the user runs /brief, asks what the next feature involves, wants to understand or preview a feature before /feature, or is deciding what to build or reorder next."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# brief - understand a feature before you spec it
|
|
@@ -1,108 +1,113 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: check
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Prove the current work actually does what its spec says and adheres to architectural standards through a Dual-Axis Independent Review. Supports Multi-Run: given an optional ID or name (/check 12), targets that spec and records proof to devflow/context/{xxx-slug}/findings.md. Drives the app, captures empirical evidence, checks Fowler smells, and reports pass/fail. Use when running /check, confirming work, or validating before /complete."
|
|
4
|
+
argument-hint: "[{run-id, number, or name}]"
|
|
4
5
|
---
|
|
5
6
|
|
|
6
|
-
# check -
|
|
7
|
+
# check - Dual-Axis Independent Verification Engine
|
|
7
8
|
|
|
8
9
|
Where this sits in the workflow:
|
|
9
10
|
|
|
10
11
|
/implement -> [check] -> /complete
|
|
11
|
-
(built a (
|
|
12
|
-
step or
|
|
13
|
-
the feature)
|
|
12
|
+
(built a (dual-axis (only once both
|
|
13
|
+
step or review with axes pass with
|
|
14
|
+
the feature) empirical proof) evidence)
|
|
14
15
|
|
|
15
|
-
`/implement` builds and does a quick build-plus-screenshot check inline. `/check`
|
|
16
|
-
is the deeper, repeatable gate for when a "done when" needs the *real running app*,
|
|
17
|
-
not just a green build: a click that triggers a download, a route that returns a
|
|
18
|
-
file, a flow across screens. Run it on a single step whose done-when is
|
|
19
|
-
behavioral, or on the whole feature as the acceptance check before `/complete`.
|
|
16
|
+
`/implement` builds and does a quick build-plus-screenshot check inline. `/check` is the rigorous, repeatable gate for when a feature or step needs **empirical proof** on the running app and **two-axis code review** before merging.
|
|
20
17
|
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
18
|
+
It changes no source and commits nothing — it executes, inspects, and reports observed facts.
|
|
19
|
+
|
|
20
|
+
---
|
|
24
21
|
|
|
25
22
|
## Input
|
|
26
23
|
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
`devflow/context/current-feature.md`.
|
|
24
|
+
- **Given an ID or name** (e.g. `/check 12`, `/check 012`) -> targets `devflow/context/{xxx-slug}/` and records audit ledger to `{xxx-slug}/findings.md`.
|
|
25
|
+
- **With no argument** (`/check`) -> verifies the active run matching current git branch or single active spec.
|
|
30
26
|
|
|
31
|
-
|
|
27
|
+
---
|
|
32
28
|
|
|
33
|
-
|
|
34
|
-
criteria from the build steps (and any acceptance notes in the Testing section).
|
|
35
|
-
Turn them into a concrete checklist of claims to prove - each one a specific,
|
|
36
|
-
observable behavior, not "it works". If the user named one thing, scope to that.
|
|
29
|
+
## Step 1 - Build the Dual-Axis Review Matrix
|
|
37
30
|
|
|
38
|
-
|
|
31
|
+
Read the target spec from `devflow/context/{xxx-slug}/spec.md` (or `devflow/context/current-feature.md`) and `devflow/context/coding-standards.md`. Prepare the inspection criteria across two independent axes:
|
|
39
32
|
|
|
40
|
-
|
|
33
|
+
1. **Axis 1 (Standards & Architecture Criteria)**:
|
|
34
|
+
- Coding conventions in `coding-standards.md`
|
|
35
|
+
- Deep Modules discipline (Small interface, deep implementation, clean seams, no leaky abstractions)
|
|
36
|
+
- Baseline 12 Fowler Code Smells (Primitive obsession, Feature envy, Shotgun surgery, Speculative generality, etc.)
|
|
37
|
+
- Multi-lane technical gates (Typecheck, test suites, zero secrets, zero P0/P1 findings)
|
|
38
|
+
2. **Axis 2 (Spec Fidelity & Behavioral Observables)**:
|
|
39
|
+
- Line-by-line Acceptance Criteria (ACs) and "Done When" observables from `current-feature.md`
|
|
40
|
+
- Scope Creep detection (Unrequested behavior in the diff)
|
|
41
|
+
- Missing Requirements detection (Unimplemented edge cases)
|
|
41
42
|
|
|
42
|
-
|
|
43
|
-
type:
|
|
43
|
+
---
|
|
44
44
|
|
|
45
|
-
|
|
46
|
-
to the relevant routes. Prefer reusing an already-running server over starting a
|
|
47
|
-
duplicate. If Playwright is already installed or declared in `AGENTS.md`, prefer
|
|
48
|
-
it for browser driving, screenshots, console errors, and failed request checks.
|
|
49
|
-
If it is not installed, do not add it from `/check`; use another real-browser
|
|
50
|
-
evidence path and report what you used.
|
|
51
|
-
- **CLI** - run the actual command(s) with representative inputs.
|
|
52
|
-
- **Server/API** - start it and hit the endpoints.
|
|
53
|
-
- **Library** - exercise the public API through an example or the test command.
|
|
45
|
+
## Step 2 - Get the App Running & Exercise Live Proof
|
|
54
46
|
|
|
55
|
-
|
|
56
|
-
`/check` is broader than unit tests: it checks real behavior, which is exactly the
|
|
57
|
-
evidence UI and integration steps ride on instead of unit tests.
|
|
47
|
+
Use the project's real commands (from `AGENTS.md`):
|
|
58
48
|
|
|
59
|
-
|
|
49
|
+
- **Web app**: Start (or reuse) the local dev server. Drive a real browser to relevant routes. Prefer Playwright when installed for screenshots, network errors, and console assertions.
|
|
50
|
+
- **CLI**: Execute commands with representative input fixtures, asserting exit codes and output snapshots.
|
|
51
|
+
- **Server / API**: Hit endpoints with real payloads and assert on HTTP response status and bodies.
|
|
52
|
+
- **Library**: Exercise public interfaces through integration tests or sample scripts.
|
|
60
53
|
|
|
61
|
-
|
|
54
|
+
> [!IMPORTANT]
|
|
55
|
+
> **Evidence or it didn't happen**: Every verdict must be backed by empirical evidence (screenshot, command output, status code, response time). Never assume a pass from reading source code alone.
|
|
62
56
|
|
|
63
|
-
|
|
64
|
-
from the code what the running app would do.
|
|
65
|
-
- Capture **screenshots** for visual/UI claims, **output** for CLI/API claims.
|
|
66
|
-
- Watch for **console errors and failed network requests**; a clean-looking screen
|
|
67
|
-
with errors in the console is not a pass.
|
|
57
|
+
---
|
|
68
58
|
|
|
69
|
-
## Step
|
|
59
|
+
## Step 3 - Dual-Axis Independent Report
|
|
70
60
|
|
|
71
|
-
Format the
|
|
61
|
+
Format the report into two distinct, un-merged review axes:
|
|
72
62
|
|
|
73
|
-
|
|
74
|
-
|
|
63
|
+
```markdown
|
|
64
|
+
# 🔍 Verification Report: [Feature Name]
|
|
75
65
|
|
|
76
|
-
|
|
77
|
-
[pass] AC-2: Both buttons show a loading state - screenshot: loading-state.png
|
|
78
|
-
[fail] AC-3: PDF border missing - printBackground not set; screenshot: pdf-no-border.png
|
|
79
|
-
[skip] AC-4: Vercel deploy smoke test - can't verify locally (pending staging)
|
|
66
|
+
## ⚖️ Axis 1: Standards, Architecture & Quality Gate
|
|
80
67
|
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
-
|
|
84
|
-
-
|
|
85
|
-
-
|
|
86
|
-
- **
|
|
68
|
+
- **Technical Lanes**:
|
|
69
|
+
- [pass] Type Safety: `tsc --noEmit` (0 errors)
|
|
70
|
+
- [pass] Automated Tests: `npm test` (All tests green)
|
|
71
|
+
- [pass] Security & Hygiene: Zero secrets, sanitized inputs
|
|
72
|
+
- [pass] Findings Ledger: 0 blocking P0/P1 in `devflow/context/findings.md`
|
|
73
|
+
- **Deep Modules & Architecture**:
|
|
74
|
+
- [pass] Seam Integrity: Public interfaces remain small, implementation details hidden.
|
|
75
|
+
- [pass] The Deletion Test: Complexity is concentrated inside the module, not scattered across callers.
|
|
76
|
+
- **Code Smells Assessment**:
|
|
77
|
+
- [clean] 12 Fowler Code Smells evaluated across git diff: No critical smells detected.
|
|
87
78
|
|
|
88
|
-
|
|
89
|
-
- **All Passed**: State that the feature is verified and ready for `/complete`.
|
|
90
|
-
- **Any Failure**: Hand back to `/implement` with exact failure evidence and reproduction steps. Never fix issues inside `/check`.
|
|
91
|
-
- **Unverifiable**: Clearly state reasons and residual risk. Never fabricate a pass.
|
|
79
|
+
## 🎯 Axis 2: Spec Fidelity & Behavioral Acceptance Gate
|
|
92
80
|
|
|
93
|
-
|
|
81
|
+
Line-by-line verification against `current-feature.md`:
|
|
82
|
+
- [pass] **AC-1 (<title>)**: <Observed empirical evidence / screenshot path>
|
|
83
|
+
- [pass] **AC-2 (<title>)**: <Observed empirical evidence / terminal output>
|
|
84
|
+
- [fail] **AC-3 (<title>)**: <Exact observed failure with reproduction command>
|
|
85
|
+
- [clean] **Scope Creep Check**: No unrequested features or unnecessary abstractions introduced.
|
|
86
|
+
- [clean] **Completeness Check**: 100% of spec requirements addressed.
|
|
87
|
+
|
|
88
|
+
---
|
|
89
|
+
|
|
90
|
+
## 🚦 Final Routing & Verdict
|
|
94
91
|
|
|
95
|
-
- **
|
|
96
|
-
|
|
97
|
-
- **
|
|
98
|
-
|
|
99
|
-
- **Honest over green.** "Couldn't verify" and "failed" are valid, useful results.
|
|
100
|
-
Faking a pass defeats the entire gate.
|
|
101
|
-
- **Check the spec, not vibes.** Verify against the done-whens in
|
|
102
|
-
`current-feature.md`, so "works" means what the spec said it would do.
|
|
92
|
+
- **ALL PASSED**: Both axes green. Ready for `/complete`.
|
|
93
|
+
- **ANY FAILURE**: Hand back to `/implement` with exact failure evidence and reproduction steps.
|
|
94
|
+
- **UNVERIFIABLE**: Clearly document the gap and residual risk. Never fabricate a pass.
|
|
95
|
+
```
|
|
103
96
|
|
|
104
|
-
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
## Why Two Independent Axes?
|
|
100
|
+
|
|
101
|
+
A code change can pass one axis and fail the other:
|
|
102
|
+
- **Standards Pass, Spec Fail**: Code is beautifully architected and tested, but implements the wrong business behavior.
|
|
103
|
+
- **Spec Pass, Standards Fail**: Feature works end-to-end, but violates encapsulation, introduces shallow modules, or leaks secrets.
|
|
104
|
+
|
|
105
|
+
Reporting both axes side-by-side stops elegance from masking functional bugs, and stops functional completeness from excusing architectural rot.
|
|
106
|
+
|
|
107
|
+
---
|
|
108
|
+
|
|
109
|
+
## Rules
|
|
105
110
|
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
111
|
+
- **Observe, don't change**: `/check` runs the app and reports. It never edits source or commits. Fixing is `/implement`'s job.
|
|
112
|
+
- **Honest over green**: "Failed" and "Could not verify" are valid, valuable outputs. Faking a pass destroys the gate.
|
|
113
|
+
- **Check the spec, not vibes**: Verify against documented ACs, not subjective feelings.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ci
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Set up or normalize automatic GitHub checks for a Blueprint project around one documented Verify command. Detects the real stack, package manager, existing checks, default branch, and workflows; preserves existing CI; combines only configured typecheck, test, and build commands; runs the command locally; and stops before push or remote ruleset changes. Use when the user runs /ci, invokes $ci, asks to add CI, set up GitHub Actions, add pull-request checks, or create automatic GitHub checks."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# ci - set up automatic GitHub checks
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: complete
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Wrap up a finished feature, fix, or rollback. Supports Multi-Run: given an optional ID (/complete 12), archives that run from devflow/context/{xxx-slug}/ to devflow/history/, cleans up the run workspace, updates build-plan and HISTORY.md, and makes the work commit. Enforces mandatory user gate (Squash-merge vs MR/PR)."
|
|
4
|
+
argument-hint: "[{run-id, number, or name}]"
|
|
4
5
|
---
|
|
5
6
|
|
|
6
7
|
# complete - log the finished work, make the work commit, and deliver
|
|
@@ -12,13 +13,18 @@ Where this sits in the workflow:
|
|
|
12
13
|
|
|
13
14
|
`/implement` built the feature, fix, or rollback on its branch, with optional per-step commit
|
|
14
15
|
checkpoints. This skill closes it out: it logs the work, makes the single
|
|
15
|
-
work-level commit, and guides the delivery through a **Mandatory User Delivery Gate**. Run it only when the work is done,
|
|
16
|
+
work-level commit, archives from `devflow/context/{xxx-slug}/`, cleans up the active run workspace, and guides the delivery through a **Mandatory User Delivery Gate**. Run it only when the work is done,
|
|
16
17
|
reviewed, and the documented `Verify` command, or the fallback build and tests,
|
|
17
18
|
passes.
|
|
18
19
|
|
|
20
|
+
## Multi-Run Target Resolution
|
|
21
|
+
|
|
22
|
+
- **Given an ID or name** (e.g. `/complete 12`, `/complete 058`) -> targets `devflow/context/{xxx-slug}/` for archiving and cleanup.
|
|
23
|
+
- **With no argument** (`/complete`) -> targets the run matching the active branch or single active spec.
|
|
24
|
+
|
|
19
25
|
## Before you start
|
|
20
26
|
|
|
21
|
-
Confirm the work is actually finished: `devflow/context/current-feature.md`
|
|
27
|
+
Confirm the target work is actually finished: `devflow/context/{xxx-slug}/spec.md` (or `current-feature.md`)
|
|
22
28
|
holds a real spec, its steps are built on a branch, and `Verify`, or the fallback
|
|
23
29
|
build and tests, passes. If any of the
|
|
24
30
|
spec's done-whens are behavioral, `/check` should have proven them against the
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: convert-any-to-md
|
|
3
|
-
description: "[devflow]
|
|
3
|
+
description: "[devflow] Converts any document (.xlsx, .pdf, .docx, .txt, .csv, .log, .json, .yaml, etc.) or mixed folders into clean Markdown in devflow/reference. Use whenever documents need to be analyzed, summarized, searched, or extracted from."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Convert Any Document to Markdown
|