devmethod-ai 0.3.1 → 0.4.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.
Files changed (65) hide show
  1. package/.agents/skills/devmethod-architecture/SKILL.md +14 -0
  2. package/.agents/skills/devmethod-correct-course/SKILL.md +12 -0
  3. package/.agents/skills/devmethod-design/SKILL.md +14 -0
  4. package/.agents/skills/devmethod-explore/SKILL.md +12 -0
  5. package/.agents/skills/devmethod-frame/SKILL.md +12 -0
  6. package/.agents/skills/devmethod-handoff/SKILL.md +14 -0
  7. package/.agents/skills/devmethod-implement/SKILL.md +14 -0
  8. package/.agents/skills/devmethod-integrate/SKILL.md +14 -0
  9. package/.agents/skills/devmethod-next/SKILL.md +14 -0
  10. package/.agents/skills/devmethod-plan/SKILL.md +14 -0
  11. package/.agents/skills/devmethod-ready/SKILL.md +14 -0
  12. package/.agents/skills/devmethod-review/SKILL.md +18 -0
  13. package/.agents/skills/devmethod-status/SKILL.md +12 -0
  14. package/.agents/skills/devmethod-verify/SKILL.md +14 -0
  15. package/.agents/skills/project-foundation/SKILL.md +1 -1
  16. package/.agents/skills/project-foundation/assets/START_HERE.md +3 -1
  17. package/.agents/skills/project-foundation/references/operating-commands.md +19 -15
  18. package/.agents/skills/scoped-delivery/assets/REVIEW.md +2 -2
  19. package/.agents/skills/scoped-delivery/references/review-format.md +26 -0
  20. package/.agents/skills/scoped-delivery/references/review-report.md +16 -0
  21. package/.agents/skills/scoped-delivery/references/review-workflow.md +10 -1
  22. package/.agents/skills/scoped-delivery/references/verification-and-cost.md +2 -0
  23. package/COMPATIBILITY.md +7 -3
  24. package/README.md +33 -27
  25. package/START_HERE.md +3 -1
  26. package/dist/cli.js +3 -1
  27. package/dist/commands.js +20 -0
  28. package/dist/doctor.js +7 -3
  29. package/dist/init.js +16 -2
  30. package/dist/review-agent.js +24 -0
  31. package/dist/review-runtime.js +9 -0
  32. package/docs/ADR-009-visible-workflow-commands.md +11 -0
  33. package/docs/ADR-010-installed-review-renderer.md +9 -0
  34. package/docs/COMMANDS-VALIDATION.md +13 -0
  35. package/docs/COMMANDS.md +36 -0
  36. package/docs/EVALUATION.md +4 -0
  37. package/docs/RELEASE-0.4.0.md +15 -0
  38. package/docs/RELEASE-0.4.1.md +13 -0
  39. package/docs/REVIEW-GUIDE.md +6 -0
  40. package/docs/REVIEWS.md +9 -23
  41. package/evaluation/review-detection/README.md +30 -0
  42. package/evaluation/review-detection/fixtures/compatibility.mjs +4 -0
  43. package/evaluation/review-detection/fixtures/consumer.mjs +3 -0
  44. package/evaluation/review-detection/fixtures/control.mjs +5 -0
  45. package/evaluation/review-detection/fixtures/sensitive.mjs +11 -0
  46. package/evaluation/review-detection/fixtures/submission.mjs +8 -0
  47. package/evaluation/review-detection/observed-0.4.1/README.md +16 -0
  48. package/evaluation/review-detection/observed-0.4.1/TASK.md +1 -0
  49. package/evaluation/review-detection/observed-0.4.1/adjudication.json +65 -0
  50. package/evaluation/review-detection/observed-0.4.1/case-a/sensitive.mjs +10 -0
  51. package/evaluation/review-detection/observed-0.4.1/case-b/submission.mjs +7 -0
  52. package/evaluation/review-detection/observed-0.4.1/case-c/compatibility.mjs +3 -0
  53. package/evaluation/review-detection/observed-0.4.1/case-c/consumer.mjs +2 -0
  54. package/evaluation/review-detection/observed-0.4.1/case-d/control.mjs +5 -0
  55. package/evaluation/review-detection/observed-0.4.1/input-hashes.json +7 -0
  56. package/evaluation/review-detection/observed-0.4.1/method-hashes.json +76 -0
  57. package/evaluation/review-detection/observed-0.4.1/probe-results.json +58 -0
  58. package/evaluation/review-detection/observed-0.4.1/raw-findings.md +75 -0
  59. package/evaluation/review-detection/observed-0.4.1/review-probes.mjs +41 -0
  60. package/evaluation/review-detection/observed-0.4.1/score.json +17 -0
  61. package/evaluation/review-detection/oracle.json +9 -0
  62. package/evaluation/review-detection/reproduce.test.mjs +53 -0
  63. package/evaluation/review-detection/score.mjs +26 -0
  64. package/package.json +1 -1
  65. package/scripts/package-smoke.mjs +13 -2
@@ -0,0 +1,14 @@
1
+ ---
2
+ name: devmethod-architecture
3
+ description: Discuss structural alternatives and record an explicit choice or delegation before dependent detail. Use for the DevMethod architecture command.
4
+ ---
5
+
6
+ # DevMethod architecture
7
+
8
+ Execute the `architecture` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `architecture` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Use [decision-architecture](../decision-architecture/SKILL.md) for this stage’s detailed procedure.
13
+
14
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,12 @@
1
+ ---
2
+ name: devmethod-correct-course
3
+ description: Reconcile a scope or decision change with affected plans, tickets and evidence. Use for the DevMethod correct-course command.
4
+ ---
5
+
6
+ # DevMethod correct-course
7
+
8
+ Execute the `correct-course` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `correct-course` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,14 @@
1
+ ---
2
+ name: devmethod-design
3
+ description: Create or apply product design using the existing design workflow and approved directions. Use for the DevMethod design command.
4
+ ---
5
+
6
+ # DevMethod design
7
+
8
+ Execute the `design` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `design` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Use [design-to-code](../design-to-code/SKILL.md) for this stage’s detailed procedure.
13
+
14
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,12 @@
1
+ ---
2
+ name: devmethod-explore
3
+ description: Research existing solutions and discuss evidence, uncertainty and product direction. Use for the DevMethod explore command.
4
+ ---
5
+
6
+ # DevMethod explore
7
+
8
+ Execute the `explore` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `explore` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,12 @@
1
+ ---
2
+ name: devmethod-frame
3
+ description: Define product need, scope, exclusions and observable success criteria. Use for the DevMethod frame command.
4
+ ---
5
+
6
+ # DevMethod frame
7
+
8
+ Execute the `frame` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `frame` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,14 @@
1
+ ---
2
+ name: devmethod-handoff
3
+ description: Record a dated, concise handoff linked to canonical mission state and evidence. Use for the DevMethod handoff command.
4
+ ---
5
+
6
+ # DevMethod handoff
7
+
8
+ Execute the `handoff` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `handoff` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Use [scoped-delivery](../scoped-delivery/SKILL.md) for this stage’s detailed procedure.
13
+
14
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,14 @@
1
+ ---
2
+ name: devmethod-implement
3
+ description: Implement an authorized ticket, run relevant checks and review the resulting change. Use for the DevMethod implement command.
4
+ ---
5
+
6
+ # DevMethod implement
7
+
8
+ Execute the `implement` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `implement` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Use [scoped-delivery](../scoped-delivery/SKILL.md) for this stage’s detailed procedure.
13
+
14
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,14 @@
1
+ ---
2
+ name: devmethod-integrate
3
+ description: Prepare or perform authorized integration while respecting repository gates. Use for the DevMethod integrate command.
4
+ ---
5
+
6
+ # DevMethod integrate
7
+
8
+ Execute the `integrate` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `integrate` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Use [scoped-delivery](../scoped-delivery/SKILL.md) for this stage’s detailed procedure.
13
+
14
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,14 @@
1
+ ---
2
+ name: devmethod-next
3
+ description: Inspect real mission state and select the next authorized slice without starting it. Use for the DevMethod next command.
4
+ ---
5
+
6
+ # DevMethod next
7
+
8
+ Execute the `next` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `next` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Use [scoped-delivery](../scoped-delivery/SKILL.md) for this stage’s detailed procedure.
13
+
14
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,14 @@
1
+ ---
2
+ name: devmethod-plan
3
+ description: Discuss delivery scope and organize useful milestones and executable tickets. Use for the DevMethod plan command.
4
+ ---
5
+
6
+ # DevMethod plan
7
+
8
+ Execute the `plan` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `plan` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Use [scoped-delivery](../scoped-delivery/SKILL.md) for this stage’s detailed procedure.
13
+
14
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,14 @@
1
+ ---
2
+ name: devmethod-ready
3
+ description: Assess a ticket’s scope, dependencies and acceptance criteria without starting implementation. Use for the DevMethod ready command.
4
+ ---
5
+
6
+ # DevMethod ready
7
+
8
+ Execute the `ready` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `ready` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Use [scoped-delivery](../scoped-delivery/SKILL.md) for this stage’s detailed procedure.
13
+
14
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,18 @@
1
+ ---
2
+ name: devmethod-review
3
+ description: Review actual code changes, contracts and evidence, execute relevant checks and report actionable findings. Use for the DevMethod review command.
4
+ ---
5
+
6
+ # DevMethod review
7
+
8
+ Execute the `review` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `review` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Use [scoped-delivery](../scoped-delivery/SKILL.md) for this stage’s detailed procedure.
13
+
14
+ Follow [the review workflow](../scoped-delivery/references/review-workflow.md): inspect the actual diff and relevant interactions, execute applicable checks, and report findings with locations, impact, evidence and proposed corrections. Distinguish checked, failed and uninspected scope. Do not modify product code unless corrections were requested. Review artifacts may be written as part of the requested review.
15
+
16
+ For a substantial review, use [the review record](../scoped-delivery/assets/REVIEW.md) and complete [the report delivery procedure](../scoped-delivery/references/review-report.md). Produce the real JSON, derived Markdown and interactive HTML as one flow; open the HTML when the user asks to view/open the report. A request such as “review these changes, then open the report” authorizes generation and local opening, with no extra confirmation. Keep a small review concise unless a report is requested. Never substitute fictional demo data for actual findings or ask the user to run a terminal command.
17
+
18
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,12 @@
1
+ ---
2
+ name: devmethod-status
3
+ description: Report actual progress, evidence gaps and blockers without changing records or running checks. Use for the DevMethod status command.
4
+ ---
5
+
6
+ # DevMethod status
7
+
8
+ Execute the `status` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `status` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -0,0 +1,14 @@
1
+ ---
2
+ name: devmethod-verify
3
+ description: Execute missing or invalidated checks and report evidence for the inspected revision. Use for the DevMethod verify command.
4
+ ---
5
+
6
+ # DevMethod verify
7
+
8
+ Execute the `verify` stage now for the user's supplied ticket, mission, paths or revision. This is an agent workflow, not a shell command or a request for usage instructions. Do not ask the user to run npx or install a CLI to execute this stage.
9
+
10
+ Read [the stage contract](../project-foundation/references/operating-commands.md) and [project context routing](../project-foundation/SKILL.md), then apply only `verify` and its relevant references. Preserve the supplied arguments, existing decisions, authorizations and stage scope. Reuse available context; clarify only a missing target that materially changes the work. Do not run other stages merely because they are suggested next.
11
+
12
+ Use [scoped-delivery](../scoped-delivery/SKILL.md) for this stage’s detailed procedure.
13
+
14
+ Return the concrete outcome, verification limits and one next command from the stage contract.
@@ -30,7 +30,7 @@ This kit formalizes a complete method: exploration → framing → design → ar
30
30
 
31
31
  For a new change, select the quick, standard, or major path using [work sizing](references/work-sizing.md). These paths select relevant stages; they do not add commands or require fourteen separate turns. A clear small fix can perform readiness, implementation, review, and verification together under existing authorization.
32
32
 
33
- Read [the operating commands](references/operating-commands.md) for any invocation with a stage, or to structure a new project, epic, or slice. In Codex, run `$project-foundation status`. In Claude Code or Cursor, run `/project-foundation status`. Replace `status` with the desired stage. The commands do not replace project commands.
33
+ Read [the operating commands](references/operating-commands.md) for any invocation with a stage, or to structure a new project, epic, or slice. In Codex, select `$devmethod-status`; in Claude Code or Cursor, select `/devmethod-status`. Each installed stage has a `devmethod-<stage>` entry, including `devmethod-review`. Existing `project-foundation <stage>` invocations remain supported. Execute the selected stage in the agent without asking the user to run npx. The commands do not replace project commands.
34
34
 
35
35
  For `explore`, use [existing solutions research](references/exploration.md) when product uncertainty warrants it. For an open `architecture`, resolve `decision-architecture` and discuss credible options in the conversation before detailing the dependent architecture. Preserve accepted choices and explicit delegations; invoking `plan` does not adopt a proposal. For `plan`, use [delivery planning](references/delivery-planning.md) to discuss useful outcomes and scope before fixing tickets.
36
36
 
@@ -2,7 +2,7 @@
2
2
 
3
3
  DevMethod offers six independent modules; this installation contains the modules you selected. If this is a staging directory, review and copy its installed skill folder into the project while preserving existing files. If you installed directly into the project, the selected skills are already in place. If a version already exists, compare changes before updating it. Keep `PROJECT_PROFILE.md` and complete the stack, commands, scope, deployment permissions, and data requirements from the project before adoption. `ENGINEERING_POLICY.template.md` retains the included policy; merge it with `CONTRIBUTING.md` and existing instructions.
4
4
 
5
- In Codex, start with `$project-foundation status`. In Claude Code or Cursor, start with `/project-foundation status`. For an open-ended request:
5
+ In Codex, start with `$devmethod-status`; for a review select `$devmethod-review` and add a ticket, PR or changed paths. In Claude Code or Cursor use `/devmethod-status` or `/devmethod-review`. All fourteen documented stages are exposed by a full installation. Module subsets expose stages backed by installed procedures. Once installed, run stages directly in the agent: no npx is needed. Existing `project-foundation <stage>` invocations still work. For an open-ended request:
6
6
 
7
7
  > Use the `project-foundation` skill for this project. Read existing instructions and sources, complete the profile without reinventing decisions, then deliver the following scope: [my objective]. Apply only relevant modules. Preserve the approved mockup, architecture boundaries, and React rules. Progress to a verified result within this scope.
8
8
 
@@ -24,3 +24,5 @@ Examples:
24
24
  This kit reduces repetitive framing; it does not by itself prove application quality or production readiness.
25
25
 
26
26
  For a new product, `explore` researches existing solutions and discusses the findings before framing. `architecture` discusses structural options before dependent detail; `plan` discusses delivery scope and stays conditional on open decisions. Keep accepted choices, delegations and approved design. For substantial work without conventions, propose a mission PLAN with tickets and a dated REPRISE; keep existing single-file missions usable.
27
+
28
+ To review and view results in one request, use `$devmethod-review the current changes, then open the report` (Codex) or `/devmethod-review` with the same request (Claude Code/Cursor). The agent performs the review and generates/opens the real report using the renderer installed with scoped-delivery. No user-run npx command is needed.
@@ -4,7 +4,11 @@ These commands describe a reusable work path. They are not shell commands and do
4
4
 
5
5
  ## Native invocation
6
6
 
7
- The table's short names are internal stages, not standalone native commands. Invoke `$project-foundation verify TASK-1` in Codex, or `/project-foundation verify TASK-1` in Claude Code and Cursor. Apply the same syntax to all fourteen stages, with their optional argument. Do not register `/verify`, `/review`, or other short names as global commands: they can conflict with the tool's commands. Every recommended next command must be qualified in the same way. If the host is unknown, write `project-foundation: verify TASK-1` in natural language.
7
+ Each documented stage has a discoverable `devmethod-<stage>` skill. In Codex invoke `$devmethod-review TASK-1`; in Claude Code or Cursor invoke `/devmethod-review TASK-1`. Select it in the host's skill menu and supply the target. No npx, terminal launcher or CLI installation is required to run the agent workflow after the skills are installed.
8
+
9
+ The equivalent `$project-foundation review TASK-1` (Codex) and `/project-foundation review TASK-1` (Claude Code/Cursor) remain supported. Table entries omit the host prefix: recommend the qualified `devmethod-<stage>` invocation when installed, otherwise the compatible `project-foundation <stage>` form. Never register bare `/review` or `/verify`, which may conflict with host commands. If the host is unknown, use `DevMethod review TASK-1` in natural language.
10
+
11
+ The default installation exposes all fourteen stages. Module subsets expose only commands whose procedure is installed; foundation commands remain available. Do not claim a missing module was loaded. These skills instruct the connected agent to do the work; they do not turn the installer into an autonomous executor.
8
12
 
9
13
  An unknown stage displays available stages without starting work. With no stage, read the current state and apply `status`. Routing is an instruction to the model, not a deterministic parser or execution guarantee.
10
14
 
@@ -14,20 +18,20 @@ Use [work sizing](work-sizing.md) to select relevant stages. A quick change may
14
18
 
15
19
  | Command | Purpose | Suggested next step |
16
20
  |---|---|---|
17
- | `/explore` | Research existing solutions proportionately and discuss evidence and next direction | `/frame` |
18
- | `/frame` | Define value, scope, exclusions, and metrics | `/design` or `/architecture` |
19
- | `/design` | Create/select visual direction, master and derived screens, or apply approved UX; resolve design-to-code for visual work | `/design` for unfinished visual scope, then `/architecture` |
20
- | `/architecture` | Discuss structural alternatives and record choice/delegation before dependent detail | `/plan` |
21
- | `/plan` | Discuss useful delivery scope, then milestones and near-term tickets; stay conditional on open decisions | `/ready` |
22
- | `/ready <ticket>` | Verify scope, DoD, dependencies, contract, and tests | `/implement <ticket>` |
23
- | `/implement <ticket>` | Deliver a coherent slice with focused tests | `/review <ticket>` |
24
- | `/review <ticket>` | Review diff, architecture, contracts, tests, and risks | `/verify` or `/implement` |
25
- | `/verify <ticket>` | Run documented checks and assess evidence | `/integrate <ticket>` |
26
- | `/integrate <ticket>` | Prepare a PR/merge under repository policy | `/next` |
27
- | `/correct-course` | Address a scope change or invalidated decision | `/architecture` or `/plan` |
28
- | `/next` | Resume from real status and select the next slice | appropriate command |
29
- | `/status` | Distinguish planned, in progress, PR, merged, and deployed | `/next` or `/correct-course` |
30
- | `/handoff` | Create a concise checkpoint for another session or agent | `/next` |
21
+ | `devmethod-explore` | Research existing solutions proportionately and discuss evidence and next direction | `devmethod-frame` |
22
+ | `devmethod-frame` | Define value, scope, exclusions, and metrics | `devmethod-design` or `devmethod-architecture` |
23
+ | `devmethod-design` | Create/select visual direction, master and derived screens, or apply approved UX; resolve design-to-code for visual work | `devmethod-design` for unfinished visual scope, then `devmethod-architecture` |
24
+ | `devmethod-architecture` | Discuss structural alternatives and record choice/delegation before dependent detail | `devmethod-plan` |
25
+ | `devmethod-plan` | Discuss useful delivery scope, then milestones and near-term tickets; stay conditional on open decisions | `devmethod-ready` |
26
+ | `devmethod-ready <ticket>` | Verify scope, DoD, dependencies, contract, and tests | `devmethod-implement <ticket>` |
27
+ | `devmethod-implement <ticket>` | Deliver a coherent slice with focused tests | `devmethod-review <ticket>` |
28
+ | `devmethod-review <ticket>` | Review diff, architecture, contracts, tests, and risks | `devmethod-verify` or `devmethod-implement` |
29
+ | `devmethod-verify <ticket>` | Run documented checks and assess evidence | `devmethod-integrate <ticket>` |
30
+ | `devmethod-integrate <ticket>` | Prepare a PR/merge under repository policy | `devmethod-next` |
31
+ | `devmethod-correct-course` | Address a scope change or invalidated decision | `devmethod-architecture` or `devmethod-plan` |
32
+ | `devmethod-next` | Resume from real status and select the next slice | appropriate command |
33
+ | `devmethod-status` | Distinguish planned, in progress, PR, merged, and deployed | `devmethod-next` or `devmethod-correct-course` |
34
+ | `devmethod-handoff` | Create a concise checkpoint for another session or agent | `devmethod-next` |
31
35
 
32
36
  ## Responsibility and minimal context
33
37
 
@@ -1,8 +1,8 @@
1
1
  # Structured review authoring
2
2
 
3
- Reuse the existing review convention, or docs/missions/<mission-id>/reviews/<review-id>/review.json. The JSON owns results. Derive REVIEW.md and the browser interface with the package's `devmethod review --review --output --markdown …` command; it validates records but never performs checks. Existing Markdown remains readable through `--legacy`; do not invent missing fields during migration.
3
+ Reuse the existing review convention, or docs/missions/<mission-id>/reviews/<review-id>/review.json. The JSON owns results. Keep small reviews in the conversation unless a report is requested. For substantial reviews or a requested report, follow [the installed format](../references/review-format.md), then [generate and deliver the report](../references/review-report.md) using the installed renderer. The agent performs these steps; do not hand terminal instructions back to the user.
4
4
 
5
- Begin only with known scope and sources. Replace the placeholders below, then add checks/findings/evidence using format 1 documented in the package's docs/REVIEWS.md and complete examples/review/review.json. These package references are not files automatically installed into the application root. The packaged `--demo` viewer can export its explicitly fictional JSON as a format example; never reuse its results as real evidence.
5
+ Begin with the actual scope and sources. Replace the placeholders below and add only observed checks/findings/evidence. Generate Markdown and HTML from that record. An unavailable runtime or failed browser opening is a specific delivery limitation to report after preserving completed artifacts; never substitute a demo or describe an unexecuted check as passed.
6
6
 
7
7
  ```json
8
8
  {
@@ -0,0 +1,26 @@
1
+ # Review record format
2
+
3
+ ## One versioned source
4
+
5
+ Use existing conventions, or `docs/missions/<mission-id>/reviews/<review-id>/review.json`, with generated `REVIEW.md` and deliberately included `preuves/`. Tickets link stable finding IDs; the report and UI derive results from the JSON. Do not maintain another independent score or status table.
6
+
7
+ Format 1 is shared by the optional CLI and browser validator. This installed reference supports authoring without fetching the npm package. Schema conformance never proves that a check ran.
8
+
9
+ | Object | Required fields and ownership |
10
+ |---|---|
11
+ | Review | format, id, title, project, mission, tickets, date, scope, exclusions, revision, technologies, sources, checks, findings, evidence, limits, policy, summary |
12
+ | revision | commit (recorded revision label), dirty (explicit uncommitted changes); no automatic Git execution |
13
+ | technologies | name, version, detectedFrom (actual manifest/lockfile/source evidence) |
14
+ | ticket | id, title, url (HTTPS or null; local/unpublished destinations remain unavailable) |
15
+ | source | id, title, kind (documentation/skill/project), publisher, technology, version, url, consultedAt, access (consulted/unavailable/unverified), usage, compatibility, provenance; consulted requires a date |
16
+ | check | id, title, domain, kind (automated/manual), status (passed/failed/not-run/blocked/out-of-scope), result, reason, evidenceIds, revision, targets; unexecuted/excluded checks need a reason |
17
+ | finding | id, title, domain, severity (critical/major/moderate/minor), severityReason, confidence (confirmed/suspected), resolution (open/in-progress/resolved/accepted-risk), location, trigger, expected, observed, impact, reproduction, evidenceIds, correction, tradeoffs, sourceIds, ticketIds, verification, resolutionEvidenceIds, targets |
18
+ | location | path or component description, line (positive integer or null), component (text or null); display metadata, never arbitrary file access |
19
+ | evidence | id, title, kind (text/log/screenshot/diagram), content (text alternative or excerpt), url (HTTPS or null), image (null or explicit PNG/JPEG object) |
20
+ | image | mime=image/png or image/jpeg, base64, alt, origin=captured/explanatory, privacyReviewed=true; only deliberately included reviewed images, not filesystem paths or remote images |
21
+ | policy | blockingSeverities, requireAllChecks, rationale; project-owned explicit policy, no numeric risk score |
22
+
23
+ A confirmed finding still needs evidence or reproduction. A resolved finding requires resolution evidence IDs; schema validation checks the references, **not the truth of execution or whether the fix really works**. Authors must retain the original evidence and supply fresh verification. Closing a panel never changes resolution. Finding counts include all resolution states and stay independent from filtered results; uncertain unresolved findings have a separate count. Failed-check counts are separate from finding counts.
24
+
25
+ A blocking confirmed open finding or a failed check requires corrections. Otherwise a blocked check yields blocked; no passed checks, an unresolved suspected finding, or required unrun checks yields incomplete. Otherwise the conclusion is ready **on the verified scope**, with exclusions and limits still visible. This conclusion does not authorize integration/deployment or replace repository policy.
26
+
@@ -0,0 +1,16 @@
1
+ # Deliver the real review report
2
+
3
+ This is the final part of the review workflow, performed by the agent. First inspect actual work and record the checks, findings and limits using [the review format](review-format.md). A substantial review produces JSON, Markdown and HTML; a small review may stay in the conversation unless a report is requested. Use the actual inspected revision, and label synthetic test inputs only as test fixtures.
4
+
5
+ 1. Write the real review JSON in the project's existing convention, or docs/missions/<mission-id>/reviews/<review-id>/review.json. Preserve previous review snapshots. Do not fabricate checks to make the report look complete.
6
+ 2. Resolve the installed scoped-delivery folder from this skill, even if renamed. Its `scripts/review-agent.mjs` renderer ships with the installation and needs Node.js 22+, but no npm, npx, server or network. It works in ESM, CommonJS and projects without package.json. Execute it yourself, with separately quoted arguments, for example from the project root:
7
+
8
+ ```sh
9
+ node .agents/skills/scoped-delivery/scripts/review-agent.mjs --review docs/missions/my-mission/reviews/review-1/review.json --output docs/missions/my-mission/reviews/review-1/review.html --markdown docs/missions/my-mission/reviews/review-1/REVIEW.md --open
10
+ ```
11
+
12
+ Replace sample paths with the actual record and fresh output paths. Use an absolute script path if needed and `--dest` for the actual project root. Omit `--open` for a report-only request or a headless environment. A request to open/show the report already authorizes local browser opening. Do not add a second approval or show this command as work for the user to perform.
13
+ 3. The renderer validates the real record before writing. Correct schema problems from actual evidence, preserving all review outcomes; never remove findings or change results to pass validation. Existing outputs are protected: select a new snapshot path. A valid rendering is not a passed code review.
14
+ 4. Check that both output files exist and report the review conclusion, unresolved findings, coverage limits and clickable artifact paths. If opening fails, retain and link the generated files, explain that specific limitation and use an available host file/browser preview where supported. Do not claim the browser opened merely because generation passed.
15
+
16
+ The installed helper intentionally has no demo mode. For a legacy installation lacking the helper, use an available reviewed DevMethod CLI/source checkout internally; otherwise stage the published kit through the project's authorized installation procedure and use its renderer without overwriting the project. Never stop at telling the user to run npx. If Node.js, download access or browser support is genuinely unavailable, finish independent inspection and preserve the real record, naming the specific remaining export/opening blocker. An actual environment restriction is not permission to bypass it.
@@ -10,11 +10,20 @@ Consult relevant official documentation and search for skills published by the a
10
10
 
11
11
  Choose checks according to affected scope: need/acceptance, business rules/edges, architecture/contracts, authorization/data isolation, integrity/transactions/concurrency, errors/recovery, UX/accessibility/visual fidelity, performance/operations/maintainability and relevant tests. Read affected interactions, then execute available checks. For UI inspect real rendering and interactions at relevant viewports even when automated tests pass; for backend inspect flows, errors, contracts and permissions.
12
12
 
13
+ Follow relevant behavior beyond changed lines. Trace affected callers, other user journeys, downstream contract consumers and previously stored data. Identify the concrete compatibility obligation before proposing a migration. A clean diff or passing new-path test does not establish compatibility with existing consumers or records.
14
+
15
+ Select the following probes only when the change's data and failure risks justify them; a small text or isolated logic change does not require a full audit:
16
+
17
+ - For credentials, tokens, secrets or personal data, follow input/storage through transformations and error handling to each reachable sink: logs, exception messages, API responses and telemetry. Check success and failure paths, including SDK/HTTP error objects and nested fields. Use synthetic sentinel values, captured outputs and relevant configuration to reproduce exposure without collecting real secrets. State which sinks were inspected and which remain unknown. Masking secrets in the review report protects that artifact; it does **not** demonstrate that the application prevents leaks. Inspect the original synthetic output before report sanitization and record the application-level result separately.
18
+ - For mutable state or external operations, exercise relevant concurrency, double submission, timeouts, retries, interruption and partial success. Identify the invariant, ordering, commit point and retry/recovery behavior. A timed-out call may already have applied its effect. Inspect idempotency scope, atomicity and compensation/reconciliation where needed; use controlled interleavings or injected failures rather than relying on a race happening by chance. Explain the observable integrity or recovery consequence, not merely that a transaction or retry mechanism is absent.
19
+
20
+ Classify each criticism explicitly in the existing finding rationale: a confirmed defect with reproduction/evidence; a risk requiring a named verification step; a project requirement linked to its authoritative source; or a style preference. A requirement is a basis for assessment, not itself proof of a violation. Personal style preferences are non-blocking and should normally stay out of defect findings. An architecture criticism must demonstrate a concrete consequence for a relevant scenario (such as data loss, incompatible consumers or unrecoverable partial success); disagreement with a pattern or layering preference alone is insufficient. Severity follows justified impact and the project's blocking policy, not the reviewer's preferred design.
21
+
13
22
  Keep checks distinct from findings. Record passed, failed, not-run, blocked and out-of-scope checks with result, evidence, inspected revision, kind (automated/manual) and non-execution reason. A failed test count is not a finding count. Distinguish confirmed problems from plausible risks still needing verification. Severity expresses justified impact; confidence expresses evidence. Absence of findings is not complete coverage.
14
23
 
15
24
  Each finding needs a stable ID, concrete title/domain, justified severity, confidence, resolution state, precise location, trigger, expected/observed behavior, impact, evidence or reproduction, proposed correction and trade-offs, relevant sources/tickets and resolution verification. Closing a pane, accepting a risk or applying a patch does not prove resolution: retain history and mark resolved only with fresh relevant verification.
16
25
 
17
- Use [structured review authoring](../assets/REVIEW.md) for the versioned record and derived report contract.
26
+ Use [structured review authoring](../assets/REVIEW.md) for the versioned record and [report delivery](review-report.md) to generate Markdown/HTML and open the report when requested. Carry the request through these steps instead of asking the user to run npx.
18
27
 
19
28
  ## Communicate and preserve ownership
20
29
 
@@ -17,6 +17,8 @@ Use project gates even when stricter. Do not invent an unavailable command; repo
17
17
 
18
18
  Connect every finding to a location, observable consequence, scenario, and correction. Distinguish bug, demonstrated risk, and preference. Do not request multiple identical opinions to create an appearance of certainty. If independent review is required but impossible, report it rather than simulating it.
19
19
 
20
+ Use [the review workflow](review-workflow.md) as the owner of data-flow, failure-scenario, compatibility and finding-classification guidance. Choose relevant probes; do not turn every small change into an exhaustive audit.
21
+
20
22
  Evaluate complete diff, boundaries, behavior, security, and tests at the stated commit. Re-examine touched areas after corrections, and the whole only when impact warrants it.
21
23
 
22
24
  ## Operational cost
package/COMPATIBILITY.md CHANGED
@@ -4,14 +4,16 @@ Historical platform assessment date: 2026-09-12; those results apply only to the
4
4
 
5
5
  | Host | Export directory | Invocation | Evidence |
6
6
  |---|---|---|---|
7
- | Codex | `.agents/skills/<name>/SKILL.md` | `$project-foundation status` | Local payload/export tests; method exercised with Codex in this session |
8
- | Claude Code | `.claude/skills/<name>/SKILL.md` | `/project-foundation status` | Official format reviewed; export tests; authenticated native session pending |
9
- | Cursor Agent | `.cursor/skills/<name>/SKILL.md` | `/project-foundation status` | Official format reviewed; export tests; authenticated native session pending |
7
+ | Codex | `.agents/skills/<name>/SKILL.md` | `$devmethod-status` (legacy `$project-foundation status`) | Local payload/export tests; method exercised with Codex in this session |
8
+ | Claude Code | `.claude/skills/<name>/SKILL.md` | `/devmethod-status` (legacy `/project-foundation status`) | Official format reviewed; export tests; authenticated native session pending |
9
+ | Cursor Agent | `.cursor/skills/<name>/SKILL.md` | `/devmethod-status` (legacy `/project-foundation status`) | Official format reviewed; export tests; authenticated native session pending |
10
10
 
11
11
  The earlier validation environment lacked native executables/credentials. On 2026-09-13, version probes found Codex CLI 0.147.0 and Claude Code 2.1.238; Cursor CLI was not found on PATH. The subsequent delegated pilot executed six authenticated Codex invocations; see [reviewed native results](docs/NATIVE-PILOT-RESULTS.md) for the narrow fixture coverage, budget stop and incomplete comparison. Passing installer tests does not prove host discovery, model behavior or UI command completion. No Claude Code or Cursor version is claimed as runtime-tested. Therefore these profiles are provisionally compatible, not certified end-to-end.
12
12
 
13
13
  Official references: [Claude Code skills](https://code.claude.com/docs/en/skills), [Claude Code memory](https://code.claude.com/docs/en/memory), [Cursor skills](https://cursor.com/docs/skills), [Codex skills](https://developers.openai.com/codex/skills). A host version or organization policy may change discovery or execution.
14
14
 
15
+ Version 0.4.0 adds discoverable stage adapters; [current command validation](docs/COMMANDS-VALIDATION.md) distinguishes installation checks from unverified menu discovery and model execution. Historical native results above do not validate these new adapters.
16
+
15
17
  ## Native smoke protocol
16
18
 
17
19
  Run separately in authenticated Codex, Claude Code and Cursor Agent sessions. Use a disposable local repo with only the chosen profile. Record date, exact host version, model, discovery result, commands, artifacts read, actual check output and observed next commands. Redact credentials and personal data. Keep the evaluation transcript local until reviewed for publication.
@@ -24,3 +26,5 @@ Run separately in authenticated Codex, Claude Code and Cursor Agent sessions. Us
24
26
  6. For a complete host evaluation, additionally run `explore`, `frame`, `design`, `architecture`, `plan` and `correct-course` on a fresh fictional brief, preserving each output and its one qualified next command.
25
27
 
26
28
  Read the project's CONTRIBUTING and accepted decisions throughout. Evaluate all fourteen stages before marking full native workflow coverage. An absent discovery entry, broken relative link, unexecuted check reported as passed, forbidden write or unexplained permission expansion is a failure, not a cosmetic issue.
29
+
30
+ Version 0.4.1 installs the offline report runtime with scoped-delivery. Tests execute it in all three exported layouts under CommonJS, ESM and package-less projects, intercepting only the OS-opening boundary. These tests validate report generation and dispatch, not native menu discovery or graphical browser rendering. See [release details](docs/RELEASE-0.4.1.md).
package/README.md CHANGED
@@ -28,11 +28,11 @@ The video uses illustrative Codex commands with real generated images and record
28
28
 
29
29
  ![DevMethod workflow](docs/images/devmethod-flow.svg)
30
30
 
31
- DevMethod is the public name of the kit. Its entry-point skill remains `project-foundation`, preserving existing invocations and the six-module structure.
31
+ DevMethod exposes fourteen `devmethod-*` workflow commands in the agent’s skill menu. The six procedure modules and existing `project-foundation <stage>` invocations remain supported.
32
32
 
33
33
  A reusable workflow for taking a software project from exploration to delivery: decisions, UX, architecture, tickets, development, tests, review and handoff. Six focused skills support fourteen workflow stages, each ending with evidence, limitations and one suggested next command.
34
34
 
35
- **DevMethod 0.3.1.** [Documentation and film update](docs/RELEASE-0.3.1.md) · [0.3 workflow changes](docs/RELEASE-0.3.0.md). This release adds proportionate research, explicit architecture decisions, delivery-scope discussion, linked mission/ticket templates, and a functional browser review viewer. Check the registry and GitHub release for publication evidence.
35
+ **DevMethod 0.4.1.** [Complete review-to-report flow](docs/RELEASE-0.4.1.md) · [0.3 workflow changes](docs/RELEASE-0.3.0.md). This release completes review generation and opening inside the agent, with an installed offline renderer. Review guidance now follows sensitive-data outputs, failure recovery and affected contracts beyond the diff; [detection evaluation](evaluation/review-detection/README.md) separates reproducible defects from measured reviewer results. Check the registry and GitHub release for publication evidence.
36
36
 
37
37
  For developers and small teams using coding agents in new or existing repositories. Requires Node.js 22+ and npm; Git is required for context provenance. Application examples have separate framework/database prerequisites. DevMethod records scope, decisions and verification; it does not certify agent output, infer all dependencies, deploy applications or run an autonomous backlog. Installation and deterministic fixture results are separate from native host validation. See [compatibility](COMPATIBILITY.md).
38
38
 
@@ -43,18 +43,18 @@ Start with [missions and the tested source quick start](docs/MISSIONS.md), the [
43
43
  Requires Node.js 22+ and npm. Install into a fresh staging directory first:
44
44
 
45
45
  ```bash
46
- npx --yes devmethod-ai@0.3.1 init --tool codex --dest ../foundation-staging
46
+ npx --yes devmethod-ai@0.4.1 init --tool codex --dest ../foundation-staging
47
47
  ```
48
48
 
49
49
  Choose `codex`, `claude` or `cursor`. If you omit `--tool`, an interactive terminal asks. For example:
50
50
 
51
51
  ```bash
52
- npx --yes devmethod-ai@0.3.1 init --tool claude --dest ../foundation-staging --dry-run
52
+ npx --yes devmethod-ai@0.4.1 init --tool claude --dest ../foundation-staging --dry-run
53
53
  ```
54
54
 
55
55
  Remove `--dry-run` to write. Select a subset with `--modules decision-architecture,scoped-delivery`; `project-foundation` is always included. Without `--modules`, all six modules are installed. The installer refuses divergent files and duplicate skills across host directories. It never edits AGENTS.md, CLAUDE.md or your package.json. Review the staging output, then merge only what the project needs.
56
56
 
57
- The installer has no runtime dependencies and makes no network requests after npm obtains the package. To pin the final version, use `npx --yes devmethod-ai@0.3.1 init ...`. To pin a reviewed repository commit instead, use: `npx --yes --package=github:montassarkhalloufi/DevMethod#<commit-sha> devmethod init ...`.
57
+ The installer has no runtime dependencies and makes no network requests after npm obtains the package. To pin the final version, use `npx --yes devmethod-ai@0.4.1 init ...`. To pin a reviewed repository commit instead, use: `npx --yes --package=github:montassarkhalloufi/DevMethod#<commit-sha> devmethod init ...`.
58
58
 
59
59
  Complete PROJECT_PROFILE.md with your real stack, commands, scope, deployment permissions and data requirements. Merge AGENTS.foundation.md into the project's existing instructions only after review. Claude Code reads CLAUDE.md: preserve its current content and, if the project has AGENTS.md, optionally add `@AGENTS.md` to import it. Keep existing accepted architecture decisions authoritative.
60
60
 
@@ -102,28 +102,30 @@ Risk and repository policy override apparent size. Reuse accepted UI, architectu
102
102
 
103
103
  ## Run the workflow
104
104
 
105
- In Codex: `$project-foundation status`.
105
+ In Codex: select `$devmethod-status` or `$devmethod-review TASK-1`.
106
106
 
107
- In Claude Code or Cursor: `/project-foundation status`.
107
+ In Claude Code or Cursor: select `/devmethod-status` or `/devmethod-review TASK-1`.
108
108
 
109
- Replace `status` with an action below. These are prompts to the skill, not shell commands or standalone `/verify` commands. They do not create a background autonomous loop.
109
+ After installation, these commands run the workflow in your agent without npx. For example, `$devmethod-review` inspects actual changes, runs relevant checks and reports findings; it does not merely open the viewer. Existing `project-foundation <stage>` syntax remains valid. Partial module installs expose only stages supported by the selected modules. See [command discovery and updates](docs/COMMANDS.md).
110
+
111
+ Select an action below and add its target. These are prompts to the skill, not shell commands or standalone `/verify` commands. They do not create a background autonomous loop.
110
112
 
111
113
  | Action | Result |
112
114
  |---|---|
113
- | `explore` | Dated research on existing solutions, uncertainty and next direction |
114
- | `frame` | Product scope, exclusions and success measures |
115
- | `design` | Visual directions, selected mockups and UX criteria; image tooling depends on the host |
116
- | `architecture` | Conversation and explicit choice/delegation before dependent detail |
117
- | `plan` | Useful scope discussion, conditional milestones and near-term tickets |
118
- | `ready TASK-1` | Readiness assessment before implementation |
119
- | `implement TASK-1` | Scoped code, tests and corrections |
120
- | `review TASK-1` | Evidence-backed inspection, structured findings, checks, sources and report |
121
- | `verify TASK-1` | Executed checks and remaining gates |
122
- | `integrate TASK-1` | Delivery under existing permissions |
123
- | `correct-course` | Resolve changed scope or blocked decisions |
124
- | `next` | Select the next authorized slice |
125
- | `status` | Current evidenced implementation status |
126
- | `handoff` | Resumable checkpoint |
115
+ | `devmethod-explore` | Dated research on existing solutions, uncertainty and next direction |
116
+ | `devmethod-frame` | Product scope, exclusions and success measures |
117
+ | `devmethod-design` | Visual directions, selected mockups and UX criteria; image tooling depends on the host |
118
+ | `devmethod-architecture` | Conversation and explicit choice/delegation before dependent detail |
119
+ | `devmethod-plan` | Useful scope discussion, conditional milestones and near-term tickets |
120
+ | `devmethod-ready TASK-1` | Readiness assessment before implementation |
121
+ | `devmethod-implement TASK-1` | Scoped code, tests and corrections |
122
+ | `devmethod-review TASK-1` | Evidence-backed inspection, structured findings, checks, sources and report |
123
+ | `devmethod-verify TASK-1` | Executed checks and remaining gates |
124
+ | `devmethod-integrate TASK-1` | Delivery under existing permissions |
125
+ | `devmethod-correct-course` | Resolve changed scope or blocked decisions |
126
+ | `devmethod-next` | Select the next authorized slice |
127
+ | `devmethod-status` | Current evidenced implementation status |
128
+ | `devmethod-handoff` | Resumable checkpoint |
127
129
 
128
130
  See [research, decision dialogue and mission migration](docs/WORKFLOW-0.3.md). See the [full command contract](.agents/skills/project-foundation/references/operating-commands.md). A failed check returns to correction; a blocked gate leads to handoff or replanning. Tests, code review and native permissions remain necessary.
129
131
 
@@ -133,15 +135,19 @@ See [research, decision dialogue and mission migration](docs/WORKFLOW-0.3.md). S
133
135
 
134
136
  [Detailed recorded Lisière chain](docs/media/full-chain-4k/README.md) · [Short Clair demo](docs/media/from-zero/README.md) · [Run Clair](examples/clair-from-zero/README.md). Clair is a separate from-zero example. The featured film retains the Lisière story and adds an explicitly separate fictional review example.
135
137
 
136
- ## Inspect a review in your browser
138
+ ## Review your changes and open the report
137
139
 
138
- Generate a local interactive report from the packaged fictional demo:
140
+ In your coding agent, ask:
139
141
 
140
- ```sh
141
- npx --yes devmethod-ai@0.3.1 review --demo --output review.html --open
142
+ ```text
143
+ $devmethod-review the current changes, then open the report
142
144
  ```
143
145
 
144
- The command generates `review.html` and opens it in your browser without a local server. On a headless machine, omit `--open`; if opening fails, the file remains available. For your own results, use `--review relative/review.json`; add `--markdown REVIEW.md` for the derived report. Search and filter findings, inspect evidence and source provenance, and export the same results. Existing Markdown remains readable with `--legacy`. See [review commands, format and trust limits](docs/REVIEWS.md). The CLI presents recorded results; it does not perform an automatic code review.
146
+ In Claude Code or Cursor, use `/devmethod-review` with the same request. The agent inspects the actual changes, runs relevant checks, records evidence-backed findings and justified impact, then generates the Markdown and interactive HTML reports from the real review JSON and opens the HTML. You do not need to launch npx, a terminal command or a server. The renderer is installed with scoped-delivery and runs locally with Node.js 22+.
147
+
148
+ For a small review without a requested report, the result can stay in the conversation. On a headless machine or if browser opening fails, the generated artifacts are preserved and linked with the opening limitation. Existing reports are never overwritten. See [review workflow and report delivery](docs/REVIEWS.md).
149
+
150
+ The screenshots below use clearly fictional data to illustrate the interface; your review uses actual project results. The separate terminal viewer remains available for manual use and demos, as described in the [review guide](docs/REVIEW-GUIDE.md).
145
151
 
146
152
  ![Actual DevMethod review interface — fictional demonstration data](https://raw.githubusercontent.com/montassarkhalloufi/DevMethod/main/docs/images/review-interface-desktop.jpg)
147
153
 
package/START_HERE.md CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
  DevMethod offers six independent modules; this installation contains the modules you selected. If this is a staging directory, review and copy its installed skill folder into the project while preserving existing files. If you installed directly into the project, the selected skills are already in place. If a version already exists, compare changes before updating it. Keep `PROJECT_PROFILE.md` and complete the stack, commands, scope, deployment permissions, and data requirements from the project before adoption. `ENGINEERING_POLICY.template.md` retains the included policy; merge it with `CONTRIBUTING.md` and existing instructions.
4
4
 
5
- In Codex, start with `$project-foundation status`. In Claude Code or Cursor, start with `/project-foundation status`. For an open-ended request:
5
+ In Codex, start with `$devmethod-status`; for a review select `$devmethod-review` and add a ticket, PR or changed paths. In Claude Code or Cursor use `/devmethod-status` or `/devmethod-review`. All fourteen documented stages are exposed by a full installation. Module subsets expose stages backed by installed procedures. Once installed, run stages directly in the agent: no npx is needed. Existing `project-foundation <stage>` invocations still work. For an open-ended request:
6
6
 
7
7
  > Use the `project-foundation` skill for this project. Read existing instructions and sources, complete the profile without reinventing decisions, then deliver the following scope: [my objective]. Apply only relevant modules. Preserve the approved mockup, architecture boundaries, and React rules. Progress to a verified result within this scope.
8
8
 
@@ -24,3 +24,5 @@ Examples:
24
24
  This kit reduces repetitive framing; it does not by itself prove application quality or production readiness.
25
25
 
26
26
  For a new product, `explore` researches existing solutions and discusses the findings before framing. `architecture` discusses structural options before dependent detail; `plan` discusses delivery scope and stays conditional on open decisions. Keep accepted choices, delegations and approved design. For substantial work without conventions, propose a mission PLAN with tickets and a dated REPRISE; keep existing single-file missions usable.
27
+
28
+ To review and view results in one request, use `$devmethod-review the current changes, then open the report` (Codex) or `/devmethod-review` with the same request (Claude Code/Cursor). The agent performs the review and generates/opens the real report using the renderer installed with scoped-delivery. No user-run npx command is needed.