engineering-process 1.2.6__tar.gz → 2.0.1__tar.gz

{engineering_process-1.2.6/engineering_process.egg-info → engineering_process-2.0.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: engineering-process
-Version: 1.2.6
+Version: 2.0.1
 Summary: A small agent-neutral engineering lifecycle with managed adoption
 License-Expression: MIT
 Project-URL: Homepage, https://github.com/phuongnse/engineering-process
@@ -33,11 +33,27 @@ Portable skills explain what to do. processctl owns state transitions and curren
 evidence. Each consumer owns its product rules, exact commands, merge policy, and
 release decisions.
 
+Start delivery work with [deliver-change](process_assets/skills/deliver-change/SKILL.md).
+It selects the current phase from lifecycle state; callers do not select a phase skill:
+
+    deliver-change
+      change-start -> change-plan -> change-implement -> change-verify
+        -> change-review -> change-complete
+
+[process-improve](process_assets/skills/process-improve/SKILL.md) handles a reusable
+process problem, then returns delivery to the same lifecycle.
+[production-engineering](process_assets/skills/production-engineering/SKILL.md) supplies
+the invariant floor consulted from planning through independent review. Both are
+reachable specializations; neither advances lifecycle state. `change-complete` calls
+the existing `processctl change finish` command.
+
+For migration from the previous skill identifiers, see [Versioning](VERSIONING.md#skill-namespace-migration).
+
 ## Architecture
 
 The distribution has four live parts:
 
-1. Managed skills under process_assets/skills, all reachable from run-change.
+1. Managed skills under process_assets/skills, all reachable from deliver-change.
 2. One processctl state machine under engineering_process/lifecycle.py.
 3. JSON Schemas that are loaded directly by the runtime.
 4. One adoption transaction that synchronizes managed skills and configuration from
@@ -98,6 +114,20 @@ Commands are argument arrays, never shell strings. Each command has a finite tim
 Output has a hard aggregate budget; evidence stores byte counts and hashes, never raw
 stdout or stderr that could contain secrets.
 
+A failed profile also reports a safe `diagnostic` descriptor containing only its
+validated profile identifier, check identifier, canonical one-based profile position,
+and a fixed `processctl` argument array. The position remains unambiguous even when a
+compatible project has duplicate check identifiers. Run that array from the project
+root to reproduce only the failed configured check through the same bounded runner,
+for example:
+
+    processctl verify --profile rust --check-position 3
+
+This selective run is diagnostic only: it does not expose captured output, replace a
+required full-profile run, or count as lifecycle verification evidence. Maintainers
+who need semantic tool output must use a tool-owned structured report or run the
+consumer command in an appropriately trusted environment.
+
 ### Production readiness
 
 A consumer declares `.process/readiness.json` with production as its direction, its
@@ -175,7 +205,7 @@ This assessment is not a production certificate. Production still requires the
 consumer's immutable readiness pack, every required capability in `enforced` state,
 fresh consumer-owned verification on the exact candidate, and independent review.
 
-For each ordinary change, `run-change` first surfaces this readiness view. The accepted
+For each ordinary change, `deliver-change` first surfaces this readiness view. The accepted
 request and consumer rules determine which capabilities are affected. Every change
 retains the project's baseline `requiredProfiles`; start and plan add any conditional
 evidence profiles needed by affected capabilities and include a planned gap only when
@@ -184,7 +214,7 @@ floor. A planned-to-enforced promotion is a reviewed consumer source diff with f
 evidence. Unrelated planned gaps remain visible but do not block development, and no
 skill chooses product priorities or changes readiness automatically.
 
-When a consumer incident exposes a reusable process gap, `improve-process` first keeps
+When a consumer incident exposes a reusable process gap, `process-improve` first keeps
 the consumer safe, then prepares a sanitized GitHub issue draft from that checkout.
 It deduplicates by consumer/process-version/invariant, requires owner authorization
 before `gh issue create`, and uses an accepted issue as the later process change source
@@ -352,7 +382,7 @@ URL; without it, the review remains pending. Earlier plan and review documents r
 readable, and their runs remain registrable or finishable with the version selected by
 the authority that started the relevant phase.
 
-The [finding priority definitions](process_assets/skills/review-change/SKILL.md#finding-priority)
+The [finding priority definitions](process_assets/skills/change-review/SKILL.md#finding-priority)
 are the canonical P0-P3 impact convention for this process, including examples and
 their relationship to blocking decisions.
 

{engineering_process-1.2.6 → engineering_process-2.0.1}/README.md

@@ -9,11 +9,27 @@ Portable skills explain what to do. processctl owns state transitions and curren
 evidence. Each consumer owns its product rules, exact commands, merge policy, and
 release decisions.
 
+Start delivery work with [deliver-change](process_assets/skills/deliver-change/SKILL.md).
+It selects the current phase from lifecycle state; callers do not select a phase skill:
+
+    deliver-change
+      change-start -> change-plan -> change-implement -> change-verify
+        -> change-review -> change-complete
+
+[process-improve](process_assets/skills/process-improve/SKILL.md) handles a reusable
+process problem, then returns delivery to the same lifecycle.
+[production-engineering](process_assets/skills/production-engineering/SKILL.md) supplies
+the invariant floor consulted from planning through independent review. Both are
+reachable specializations; neither advances lifecycle state. `change-complete` calls
+the existing `processctl change finish` command.
+
+For migration from the previous skill identifiers, see [Versioning](VERSIONING.md#skill-namespace-migration).
+
 ## Architecture
 
 The distribution has four live parts:
 
-1. Managed skills under process_assets/skills, all reachable from run-change.
+1. Managed skills under process_assets/skills, all reachable from deliver-change.
 2. One processctl state machine under engineering_process/lifecycle.py.
 3. JSON Schemas that are loaded directly by the runtime.
 4. One adoption transaction that synchronizes managed skills and configuration from
@@ -74,6 +90,20 @@ Commands are argument arrays, never shell strings. Each command has a finite tim
 Output has a hard aggregate budget; evidence stores byte counts and hashes, never raw
 stdout or stderr that could contain secrets.
 
+A failed profile also reports a safe `diagnostic` descriptor containing only its
+validated profile identifier, check identifier, canonical one-based profile position,
+and a fixed `processctl` argument array. The position remains unambiguous even when a
+compatible project has duplicate check identifiers. Run that array from the project
+root to reproduce only the failed configured check through the same bounded runner,
+for example:
+
+    processctl verify --profile rust --check-position 3
+
+This selective run is diagnostic only: it does not expose captured output, replace a
+required full-profile run, or count as lifecycle verification evidence. Maintainers
+who need semantic tool output must use a tool-owned structured report or run the
+consumer command in an appropriately trusted environment.
+
 ### Production readiness
 
 A consumer declares `.process/readiness.json` with production as its direction, its
@@ -151,7 +181,7 @@ This assessment is not a production certificate. Production still requires the
 consumer's immutable readiness pack, every required capability in `enforced` state,
 fresh consumer-owned verification on the exact candidate, and independent review.
 
-For each ordinary change, `run-change` first surfaces this readiness view. The accepted
+For each ordinary change, `deliver-change` first surfaces this readiness view. The accepted
 request and consumer rules determine which capabilities are affected. Every change
 retains the project's baseline `requiredProfiles`; start and plan add any conditional
 evidence profiles needed by affected capabilities and include a planned gap only when
@@ -160,7 +190,7 @@ floor. A planned-to-enforced promotion is a reviewed consumer source diff with f
 evidence. Unrelated planned gaps remain visible but do not block development, and no
 skill chooses product priorities or changes readiness automatically.
 
-When a consumer incident exposes a reusable process gap, `improve-process` first keeps
+When a consumer incident exposes a reusable process gap, `process-improve` first keeps
 the consumer safe, then prepares a sanitized GitHub issue draft from that checkout.
 It deduplicates by consumer/process-version/invariant, requires owner authorization
 before `gh issue create`, and uses an accepted issue as the later process change source
@@ -328,7 +358,7 @@ URL; without it, the review remains pending. Earlier plan and review documents r
 readable, and their runs remain registrable or finishable with the version selected by
 the authority that started the relevant phase.
 
-The [finding priority definitions](process_assets/skills/review-change/SKILL.md#finding-priority)
+The [finding priority definitions](process_assets/skills/change-review/SKILL.md#finding-priority)
 are the canonical P0-P3 impact convention for this process, including examples and
 their relationship to blocking decisions.
 

{engineering_process-1.2.6 → engineering_process-2.0.1}/engineering_process/__init__.py

@@ -1,3 +1,3 @@
 """Agent-neutral engineering process."""
 
-VERSION = "1.2.6"
+VERSION = "2.0.1"

{engineering_process-1.2.6 → engineering_process-2.0.1}/engineering_process/cli.py

@@ -61,6 +61,16 @@ def _root(value: str) -> Path:
     return path
 
 
+def _check_position(value: str) -> int:
+    try:
+        position = int(value)
+    except ValueError as error:
+        raise argparse.ArgumentTypeError("check position must be an integer") from error
+    if position < 1 or position > 32:
+        raise argparse.ArgumentTypeError("check position must be between 1 and 32")
+    return position
+
+
 def _process_root(args: argparse.Namespace) -> Path:
     return distribution_root(args.process_root)
 
@@ -209,7 +219,12 @@ def command_verify(args: argparse.Namespace) -> Result:
     process_root = _process_root(args)
     project = load_project(args.project_root, process_root)
     before = repository_snapshot(args.project_root)
-    report = run_profile(args.project_root, project, args.profile)
+    report = run_profile(
+        args.project_root,
+        project,
+        args.profile,
+        check_position=args.check_position,
+    )
     after = repository_snapshot(args.project_root)
     if not same_checkpoint(before, after):
         report["status"] = "failed"
@@ -433,6 +448,7 @@ def build_parser() -> argparse.ArgumentParser:
     setup.add_argument("--allow", action="append", default=[])
     verify = _leaf(commands, "verify", command_verify, help="Run a project verification profile")
     verify.add_argument("--profile", required=True)
+    verify.add_argument("--check-position", type=_check_position)
     adoption = commands.add_parser("adoption", help="Apply or check managed adoption")
     adoption_commands = adoption.add_subparsers(dest="adoption_command", required=True)
     for name, handler in (("apply", command_adoption_apply), ("check", command_adoption_check)):

{engineering_process-1.2.6 → engineering_process-2.0.1}/engineering_process/commands.py

@@ -199,20 +199,61 @@ def run_profile(
     project_root: Path,
     project: dict[str, Any],
     profile: str,
+    *,
+    check_position: int | None = None,
 ) -> dict[str, Any]:
-    checks = project["profiles"].get(profile)
-    if checks is None:
+    configured_checks = project["profiles"].get(profile)
+    if configured_checks is None:
         raise ProcessError(f"unknown verification profile: {profile}")
+    if check_position is None:
+        checks = configured_checks
+        positions = range(1, len(checks) + 1)
+    else:
+        if check_position < 1 or check_position > len(configured_checks):
+            raise ProcessError(
+                f"profile {profile} has no check at position: {check_position}"
+            )
+        checks = [configured_checks[check_position - 1]]
+        positions = [check_position]
     reports: list[dict[str, Any]] = []
-    for check in checks:
+    failed_position: int | None = None
+    for position, check in zip(positions, checks, strict=True):
         report = run_check(project_root, check)
         reports.append(report)
         if report["status"] != "passed":
+            failed_position = position
             break
-    return {
+    result = {
         "profile": profile,
         "status": "passed" if len(reports) == len(checks) and all(
             report["status"] == "passed" for report in reports
         ) else "failed",
+        "scope": (
+            {"kind": "profile"}
+            if check_position is None
+            else {
+                "kind": "check",
+                "check": checks[0]["id"],
+                "position": check_position,
+            }
+        ),
         "checks": reports,
     }
+    failed = next((report for report in reports if report["status"] == "failed"), None)
+    if failed is not None:
+        assert failed_position is not None
+        result["diagnostic"] = {
+            "kind": "selective-check-reproduction",
+            "profile": profile,
+            "check": failed["id"],
+            "position": failed_position,
+            "command": [
+                "processctl",
+                "verify",
+                "--profile",
+                profile,
+                "--check-position",
+                str(failed_position),
+            ],
+        }
+    return result

{engineering_process-1.2.6 → engineering_process-2.0.1}/engineering_process/skills.py

@@ -90,6 +90,21 @@ def validate_skills(
     graph = load_and_validate(
         graph_path, "process-graph", schema_root=schemas_root(process_root)
     )
+    owners = {state["id"]: state["ownerSkill"] for state in graph["states"]}
+    if len(owners) != len(graph["states"]):
+        raise ProcessError("process graph state ids must be unique")
+    for state in graph["states"]:
+        for transition in state["transitions"]:
+            destination = transition["nextState"]
+            skill = transition["nextSkill"]
+            if (destination is None) != (skill is None):
+                raise ProcessError("process graph terminal transitions must have both targets null")
+            if destination is not None and destination not in owners:
+                raise ProcessError(f"process graph references missing state: {destination}")
+            if skill is not None and skill not in names:
+                raise ProcessError(
+                    f"process graph transition from {state['id']} references missing skill: {skill}"
+                )
     routed = {graph["entrySkill"]}
     routed.update(state["ownerSkill"] for state in graph["states"])
     routed.update(graph.get("specializations", {}).values())

{engineering_process-1.2.6 → engineering_process-2.0.1/engineering_process.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: engineering-process
-Version: 1.2.6
+Version: 2.0.1
 Summary: A small agent-neutral engineering lifecycle with managed adoption
 License-Expression: MIT
 Project-URL: Homepage, https://github.com/phuongnse/engineering-process
@@ -33,11 +33,27 @@ Portable skills explain what to do. processctl owns state transitions and curren
 evidence. Each consumer owns its product rules, exact commands, merge policy, and
 release decisions.
 
+Start delivery work with [deliver-change](process_assets/skills/deliver-change/SKILL.md).
+It selects the current phase from lifecycle state; callers do not select a phase skill:
+
+    deliver-change
+      change-start -> change-plan -> change-implement -> change-verify
+        -> change-review -> change-complete
+
+[process-improve](process_assets/skills/process-improve/SKILL.md) handles a reusable
+process problem, then returns delivery to the same lifecycle.
+[production-engineering](process_assets/skills/production-engineering/SKILL.md) supplies
+the invariant floor consulted from planning through independent review. Both are
+reachable specializations; neither advances lifecycle state. `change-complete` calls
+the existing `processctl change finish` command.
+
+For migration from the previous skill identifiers, see [Versioning](VERSIONING.md#skill-namespace-migration).
+
 ## Architecture
 
 The distribution has four live parts:
 
-1. Managed skills under process_assets/skills, all reachable from run-change.
+1. Managed skills under process_assets/skills, all reachable from deliver-change.
 2. One processctl state machine under engineering_process/lifecycle.py.
 3. JSON Schemas that are loaded directly by the runtime.
 4. One adoption transaction that synchronizes managed skills and configuration from
@@ -98,6 +114,20 @@ Commands are argument arrays, never shell strings. Each command has a finite tim
 Output has a hard aggregate budget; evidence stores byte counts and hashes, never raw
 stdout or stderr that could contain secrets.
 
+A failed profile also reports a safe `diagnostic` descriptor containing only its
+validated profile identifier, check identifier, canonical one-based profile position,
+and a fixed `processctl` argument array. The position remains unambiguous even when a
+compatible project has duplicate check identifiers. Run that array from the project
+root to reproduce only the failed configured check through the same bounded runner,
+for example:
+
+    processctl verify --profile rust --check-position 3
+
+This selective run is diagnostic only: it does not expose captured output, replace a
+required full-profile run, or count as lifecycle verification evidence. Maintainers
+who need semantic tool output must use a tool-owned structured report or run the
+consumer command in an appropriately trusted environment.
+
 ### Production readiness
 
 A consumer declares `.process/readiness.json` with production as its direction, its
@@ -175,7 +205,7 @@ This assessment is not a production certificate. Production still requires the
 consumer's immutable readiness pack, every required capability in `enforced` state,
 fresh consumer-owned verification on the exact candidate, and independent review.
 
-For each ordinary change, `run-change` first surfaces this readiness view. The accepted
+For each ordinary change, `deliver-change` first surfaces this readiness view. The accepted
 request and consumer rules determine which capabilities are affected. Every change
 retains the project's baseline `requiredProfiles`; start and plan add any conditional
 evidence profiles needed by affected capabilities and include a planned gap only when
@@ -184,7 +214,7 @@ floor. A planned-to-enforced promotion is a reviewed consumer source diff with f
 evidence. Unrelated planned gaps remain visible but do not block development, and no
 skill chooses product priorities or changes readiness automatically.
 
-When a consumer incident exposes a reusable process gap, `improve-process` first keeps
+When a consumer incident exposes a reusable process gap, `process-improve` first keeps
 the consumer safe, then prepares a sanitized GitHub issue draft from that checkout.
 It deduplicates by consumer/process-version/invariant, requires owner authorization
 before `gh issue create`, and uses an accepted issue as the later process change source
@@ -352,7 +382,7 @@ URL; without it, the review remains pending. Earlier plan and review documents r
 readable, and their runs remain registrable or finishable with the version selected by
 the authority that started the relevant phase.
 
-The [finding priority definitions](process_assets/skills/review-change/SKILL.md#finding-priority)
+The [finding priority definitions](process_assets/skills/change-review/SKILL.md#finding-priority)
 are the canonical P0-P3 impact convention for this process, including examples and
 their relationship to blocking decisions.
 

{engineering_process-1.2.6 → engineering_process-2.0.1}/engineering_process.egg-info/SOURCES.txt

@@ -31,16 +31,16 @@ engineering_process.egg-info/dependency_links.txt
 engineering_process.egg-info/entry_points.txt
 engineering_process.egg-info/requires.txt
 engineering_process.egg-info/top_level.txt
-process_assets/skills/finish-change/SKILL.md
-process_assets/skills/implement-change/SKILL.md
-process_assets/skills/improve-process/SKILL.md
-process_assets/skills/plan-change/SKILL.md
+process_assets/skills/change-complete/SKILL.md
+process_assets/skills/change-implement/SKILL.md
+process_assets/skills/change-plan/SKILL.md
+process_assets/skills/change-review/SKILL.md
+process_assets/skills/change-start/SKILL.md
+process_assets/skills/change-verify/SKILL.md
+process_assets/skills/deliver-change/SKILL.md
+process_assets/skills/process-improve/SKILL.md
 process_assets/skills/production-engineering/SKILL.md
 process_assets/skills/production-engineering/invariants.json
-process_assets/skills/review-change/SKILL.md
-process_assets/skills/run-change/SKILL.md
-process_assets/skills/start-change/SKILL.md
-process_assets/skills/verify-change/SKILL.md
 schemas/change.schema.json
 schemas/plan.schema.json
 schemas/process-graph.schema.json

{engineering_process-1.2.6 → engineering_process-2.0.1}/process-graph.json

@@ -1,83 +1,83 @@
 {
   "schemaVersion": 2,
-  "entrySkill": "run-change",
+  "entrySkill": "deliver-change",
   "specializations": {
-    "processChange": "improve-process",
+    "processChange": "process-improve",
     "productionEngineering": "production-engineering"
   },
   "states": [
     {
       "id": "unregistered",
-      "ownerSkill": "start-change",
+      "ownerSkill": "change-start",
       "commands": ["change start"],
       "transitions": [
-        {"result": "success", "nextState": "specified", "nextSkill": "plan-change"}
+        {"result": "success", "nextState": "specified", "nextSkill": "change-plan"}
       ]
     },
     {
       "id": "specified",
-      "ownerSkill": "plan-change",
+      "ownerSkill": "change-plan",
       "commands": ["change plan"],
       "transitions": [
-        {"result": "success", "nextState": "planned", "nextSkill": "implement-change"}
+        {"result": "success", "nextState": "planned", "nextSkill": "change-implement"}
       ]
     },
     {
       "id": "planned",
-      "ownerSkill": "implement-change",
+      "ownerSkill": "change-implement",
       "commands": ["change implement"],
       "transitions": [
-        {"result": "success", "nextState": "implementing", "nextSkill": "verify-change"}
+        {"result": "success", "nextState": "implementing", "nextSkill": "change-verify"}
       ]
     },
     {
       "id": "implementing",
-      "ownerSkill": "verify-change",
+      "ownerSkill": "change-verify",
       "commands": ["change implement", "change verify"],
       "transitions": [
-        {"result": "profile-passed", "nextState": "implementing", "nextSkill": "verify-change"},
-        {"result": "all-passed", "nextState": "verified", "nextSkill": "review-change"}
+        {"result": "profile-passed", "nextState": "implementing", "nextSkill": "change-verify"},
+        {"result": "all-passed", "nextState": "verified", "nextSkill": "change-review"}
       ]
     },
     {
       "id": "verified",
-      "ownerSkill": "review-change",
+      "ownerSkill": "change-review",
       "commands": ["change implement", "change review start"],
       "transitions": [
-        {"result": "assigned", "nextState": "review-pending", "nextSkill": "review-change"},
-        {"result": "source-changed", "nextState": "implementing", "nextSkill": "implement-change"}
+        {"result": "assigned", "nextState": "review-pending", "nextSkill": "change-review"},
+        {"result": "source-changed", "nextState": "implementing", "nextSkill": "change-implement"}
       ]
     },
     {
       "id": "review-pending",
-      "ownerSkill": "review-change",
+      "ownerSkill": "change-review",
       "commands": ["change implement", "change review submit"],
       "transitions": [
-        {"result": "approved", "nextState": "approved", "nextSkill": "finish-change"},
-        {"result": "changes-requested", "nextState": "changes-requested", "nextSkill": "implement-change"},
-        {"result": "source-changed", "nextState": "implementing", "nextSkill": "implement-change"}
+        {"result": "approved", "nextState": "approved", "nextSkill": "change-complete"},
+        {"result": "changes-requested", "nextState": "changes-requested", "nextSkill": "change-implement"},
+        {"result": "source-changed", "nextState": "implementing", "nextSkill": "change-implement"}
       ]
     },
     {
       "id": "changes-requested",
-      "ownerSkill": "implement-change",
+      "ownerSkill": "change-implement",
       "commands": ["change implement"],
       "transitions": [
-        {"result": "success", "nextState": "implementing", "nextSkill": "verify-change"}
+        {"result": "success", "nextState": "implementing", "nextSkill": "change-verify"}
       ]
     },
     {
       "id": "approved",
-      "ownerSkill": "finish-change",
+      "ownerSkill": "change-complete",
       "commands": ["change finish", "change implement"],
       "transitions": [
         {"result": "success", "nextState": null, "nextSkill": null},
-        {"result": "source-changed", "nextState": "implementing", "nextSkill": "implement-change"}
+        {"result": "source-changed", "nextState": "implementing", "nextSkill": "change-implement"}
       ]
     },
     {
       "id": "blocked",
-      "ownerSkill": "run-change",
+      "ownerSkill": "deliver-change",
       "commands": [],
       "transitions": []
     }

{engineering_process-1.2.6/process_assets/skills/finish-change → engineering_process-2.0.1/process_assets/skills/change-complete}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: finish-change
-description: Complete an approved change only while its verification and independent review still match the current repository snapshot.
+name: change-complete
+description: Complete an approved change when routed by deliver-change, only while verification and independent review still match the repository snapshot.
 ---
 
-# Finish a change
+# Complete a change
 
 Confirm the lifecycle is approved, every required profile passed, every blocking
 finding is closed, every non-blocking finding has its required disposition, and the
@@ -11,7 +11,8 @@ repository still matches the reviewed snapshot. Then run:
 
     processctl change finish --change-id ID --actor ACTOR --context CONTEXT
 
-The command writes one bounded completion receipt and marks the run completed.
+The existing `change finish` CLI operation writes one bounded completion receipt and
+marks the run completed.
 Completion does not itself grant merge, deployment, or release authority; those
 remain project-owned operations. Never report completion from prose alone.
 

{engineering_process-1.2.6/process_assets/skills/implement-change → engineering_process-2.0.1/process_assets/skills/change-implement}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: implement-change
-description: Implement the accepted plan or resolve blocking review findings without changing the contract implicitly.
+name: change-implement
+description: Implement the accepted plan or resolve blocking review findings when routed by deliver-change, without changing the contract implicitly.
 ---
 
 # Implement a change
@@ -29,4 +29,4 @@ gaps merely because they are listed.
 
 When evidence exposes a contract gap, stop and ask the project owner to supersede the
 contract. Do not make review prose into new scope. When implementation is ready,
-route to **verify-change**.
+route to **change-verify**.

{engineering_process-1.2.6/process_assets/skills/plan-change → engineering_process-2.0.1/process_assets/skills/change-plan}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: plan-change
-description: Produce the smallest implementation plan that covers every accepted outcome and its verification boundary.
+name: change-plan
+description: Plan the registered change and its verification boundary when deliver-change routes a specified change.
 ---
 
 # Plan a change

{engineering_process-1.2.6/process_assets/skills/review-change → engineering_process-2.0.1/process_assets/skills/change-review}/SKILL.md

@@ -1,15 +1,24 @@
 ---
-name: review-change
-description: Review the exact verified snapshot from an actor and context independent of its implementation.
+name: change-review
+description: Review the exact verified snapshot from an independent actor and context when routed by deliver-change.
 ---
 
 # Review a change
 
 The reviewer must not share either actor identity or execution context with an
-implementer in the current cycle. Start the assignment:
+implementer in the current cycle. Read `processctl change status --change-id ID`.
+When the phase is `verified`, start the assignment:
 
     processctl change review start --change-id ID --actor REVIEWER --context REVIEW_CONTEXT
 
+When the phase is `review-pending`, resume the existing assignment; do not run
+`change review start` again. Read `.process/runs/ID/run.json` for its `cycle` and
+`reviewAssignment`, including the assigned reviewer, checkpoint, and
+`reportSchemaVersion`. Continue with the assigned independent actor/context and the
+existing report path, `.process/runs/ID/review-CYCLE.json`. If that reviewer is
+unavailable, report the pending assignment as a blocker; never impersonate its
+identity or create a replacement assignment from another context.
+
 Review the accepted contract, plan, complete diff, focused tests, and verification
 evidence. The first pass is comprehensive within that frozen contract. Every finding
 maps to one accepted criterion and records priority, origin, severity, and location.
@@ -41,7 +50,7 @@ consider consumer evidence that the lifecycle cannot observe. Every schema-versi
 report classifies `processImprovement` as `none`, `consumer-specific`, or
 `shared-process` and gives a concrete rationale. Consumer-specific behavior stays in
 the consumer. For `shared-process`, keep the assignment `review-pending` and route the
-candidate through **improve-process**. Submit only after an existing or owner-authorized
+candidate through **process-improve**. Submit only after an existing or owner-authorized
 issue supplies the stable HTTPS `recordUrl`; the review itself remains read-only.
 
 Read the consumer readiness result and repository rules. Check the complete diff for
@@ -56,8 +65,8 @@ Validate and submit the report:
     processctl contract validate --kind review REPORT_PATH
     processctl change review submit --change-id ID --review REPORT_PATH
 
-Review is read-only. Requested changes route back to **implement-change**; approval
-routes to **finish-change**. Keep the same independent reviewer for corrections.
+Review is read-only. Requested changes route back to **change-implement**; approval
+routes to **change-complete**. Keep the same independent reviewer for corrections.
 Follow-up scope is only carried findings, remediation diffs, and regressions against
 the frozen contract. A new blocker must be either remediation-caused or a P0/P1 late
 violation with a rationale. After two correction cycles, another changes-requested

{engineering_process-1.2.6/process_assets/skills/start-change → engineering_process-2.0.1/process_assets/skills/change-start}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: start-change
-description: Turn an accepted request into a bounded change contract before planning or implementation begins.
+name: change-start
+description: Turn an accepted request into a bounded change contract when deliver-change routes a new change to lifecycle start.
 ---
 
 # Start a change