engineering-process 0.1.0__tar.gz

engineering_process-0.1.0/.agents/skills/assess-design/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: assess-design
+description: Establish the owner, risk, production concerns, compatibility decision, blast radius, and required approval for a non-trivial engineering change before implementation. Use when a change affects architecture, contracts, trust boundaries, persistence, tooling, workflows, or several product surfaces.
+---
+
+# Assess a Design
+
+## Goal
+
+Produce a bounded design decision that implementation can follow without inventing
+product behavior or reopening foundational choices.
+
+## Workflow
+
+1. Read the change contract, nearest project instructions, owning product or
+   architecture contracts, and current implementation evidence.
+2. Identify the decision owner, affected consumers, data, trust boundaries,
+   generated artifacts, migrations, operational concerns, and rollback boundary.
+3. Classify risk using the project policy. Treat an absent policy as a gap rather
+   than inventing a local tier.
+4. Decide whether compatibility is required from supported consumers and data. When
+   it is not required, define a clean replacement and removal scope.
+5. Map every applicable production concern to an owner and proof. Keep unrelated
+   future capabilities out of scope without weakening the implemented boundary.
+6. Define implementation units, stop conditions, focused evidence, review evidence,
+   and required human decisions. Record durable decisions in their project owner.
+7. Return ready only when blocking decisions and required approvals are resolved.
+
+## Hard gates
+
+- Do not edit implementation before a required design decision or approval.
+- Do not replace a required owner, trust boundary, invariant, or evidence boundary
+  merely to bypass a failure.
+- Do not preserve obsolete compatibility paths without a supported requirement.
+
+## Output
+
+Return readiness, risk, owners, governing contracts, blast radius, production
+fitness, compatibility, implementation units, evidence, approvals, and blockers.

engineering_process-0.1.0/.agents/skills/build-frontend/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: build-frontend
+description: Implement a complete client journey from a ready product contract, including routes, state, forms, API consumers, accessibility, responsive behavior, recovery, and user-visible loading, empty, error, and success states.
+---
+
+# Build a Frontend Journey
+
+## Goal
+
+Deliver one coherent client outcome using the project's authoritative API and UI
+contracts with observable, accessible, and recoverable behavior.
+
+## Workflow
+
+1. Read the product outcome, acceptance rows, frontend architecture, active UI
+   contracts, generated API surface, and existing route and state owners.
+2. Trace entry and exit, neighboring journeys, permissions, URL and server state,
+   cache behavior, localization, generated types, and current tests.
+3. Define the primary and recovery paths, modes, visible state model, hierarchy,
+   content ownership, responsive behavior, keyboard behavior, and accessibility.
+4. Implement the complete planned journey narrowly. Use generated wire types and the
+   project's enforced UI contracts; do not duplicate server-owned reference data.
+5. Remove retired routes, state, mappings, translations, tests, and fallback behavior
+   when the approved design selected a clean replacement.
+6. Map each acceptance outcome to focused component, integration, or browser evidence
+   and run the declared project commands.
+
+## Hard gates
+
+- Do not define a new shared visual convention inside a feature.
+- Do not use fixed waits, hidden errors, or broad end-to-end tests as substitutes for
+  focused state and behavior evidence.
+- Do not hand-write a parallel API contract when generated types are authoritative.
+
+## Output
+
+Return journey, states, routes, UI and API contract usage, acceptance evidence, tests,
+accessibility and responsive proof, removals, and gaps.

engineering_process-0.1.0/.agents/skills/build-frontend-foundation/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: build-frontend-foundation
+description: Define or evolve reusable product-neutral frontend foundations such as application frames, navigation, route shells, providers, collection infrastructure, and cross-route behavior. Use when several client journeys depend on one non-product-specific contract.
+---
+
+# Build a Frontend Foundation
+
+## Goal
+
+Own one reusable frontend contract and its evidence without absorbing product journeys
+or the shared visual-system authority.
+
+## Workflow
+
+1. Locate the project-declared foundation owner and identify consumers, activation,
+   guarantees, alternate behavior, and out-of-scope product outcomes.
+2. Define reusable accessibility, responsiveness, localization, navigation, state,
+   and extension guarantees without embedding one consumer's identifiers or copy.
+3. Separate product-neutral mechanics from visible cross-feature UI conventions and
+   product behavior. Route those decisions to their declared owners.
+4. Implement one coherent foundation unit with focused tests and register all active
+   consumers through the project's chosen ownership mechanism.
+5. Maintain honest lifecycle, acceptance, and evidence state. A checker proves trace
+   integrity only; it cannot provide missing design or human acceptance.
+6. Run project-declared foundation, frontend, accessibility, and consumer checks.
+
+## Hard gates
+
+- Do not move actor goals or business side effects into a foundation.
+- Do not introduce a shared visual API without the UI governance contract.
+- Do not mark a foundation enforced while required consumers or evidence are missing.
+
+## Output
+
+Return foundation owner, guarantees, consumers, extension points, implementation,
+evidence, lifecycle state, delegated decisions, and gaps.

engineering_process-0.1.0/.agents/skills/change-api/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: change-api
+description: Change a public or internal API contract while preserving ownership, authorization, validation, generated artifacts, compatibility decisions, and consumer parity. Use for routes, operations, request or response shapes, status behavior, schemas, or generated clients.
+---
+
+# Change an API
+
+## Goal
+
+Evolve one API surface without drifting from its product owner or supported consumers.
+
+## Workflow
+
+1. Read the owning product and architecture contracts, current design decision, API
+   description, implementation, consumers, generated artifacts, and tests.
+2. Trace operation identity, authorization, request and response fields, validation,
+   status behavior, error format, generated clients, and all supported callers.
+3. Decide compatibility from explicit consumer and data evidence. Apply the approved
+   clean replacement or versioned compatibility strategy consistently.
+4. Implement the smallest authoritative contract change. Keep server-owned derived
+   values out of caller-authored requests and preserve safe failure mapping.
+5. Regenerate every declared artifact from its owner; never hand-maintain generated
+   parity. Update consumers in the same slice when a clean replacement was selected.
+6. Run focused contract, authorization, validation, status, generation, and consumer
+   checks declared by the project.
+
+## Hard gates
+
+- Do not expose a new public or trust-boundary surface without required approval.
+- Do not accept both retired and replacement shapes unless compatibility requires it.
+- Do not claim parity from source inspection when generated or runtime proof is required.
+
+## Output
+
+Return operation and shape changes, authorization, compatibility, generated artifacts,
+consumer updates, evidence, and unresolved decisions.

engineering_process-0.1.0/.agents/skills/cross-repo-change/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: cross-repo-change
+description: Coordinate one engineering change across independent repositories connected by public contracts or versioned dependencies. Use when two or more repositories require ordered checkpoints, compatibility decisions, release coordination, and separate verification.
+---
+
+# Coordinate a Cross-Repository Change
+
+## Goal
+
+Keep cross-repository delivery explicit and reproducible without making one
+repository depend on another repository's internal process files.
+
+## Workflow
+
+1. Identify the owning repository for every changed contract and behavior.
+2. Build a matrix containing repository, responsibility, dependency, base,
+   checkpoint, local change contract, and required verification profiles.
+3. Order work by public contract dependency. Consumers depend on an immutable
+   producer contract or version, never on an uncommitted working tree.
+4. Apply each repository's nearest AGENTS.md and project manifest independently.
+5. Verify each checkpoint in its own repository. Cross-repository evidence supplements
+   rather than replaces local evidence.
+6. Review compatibility and rollout at the public boundary. Record an atomic release
+   order or an explicit compatibility window when project policy requires one.
+7. Report every repository state; do not call the aggregate change complete while one
+   required repository remains failed, stale, not run, or blocked.
+
+## Hard gates
+
+- Do not copy private implementation knowledge across a public contract boundary.
+- Do not use sibling filesystem layout as a production dependency.
+- Do not silently advance one repository beyond an unresolved owner decision in another.
+
+## Output
+
+Return the repository matrix, ordered checkpoints, contract and rollout decisions,
+per-repository evidence, blockers, and next owner.

engineering_process-0.1.0/.agents/skills/define-change-contract/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: define-change-contract
+description: Specify and register scope, acceptance outcomes, comparison base, risk, sign-off, affected repositories, and required verification before engineering implementation begins. Use for feature, bug, architecture, contract, migration, security, or cross-project work whose completion boundary is not already explicit.
+---
+
+# Define a Change Contract
+
+## Goal
+
+Establish one evidence-backed change boundary before implementation without
+inventing product behavior or duplicating the owning specification.
+
+## Workflow
+
+1. Read the nearest AGENTS.md and the project sources it identifies as authoritative.
+2. Trace affected callers, consumers, contracts, tests, generated artifacts, and
+   repositories only far enough to define the real blast radius.
+3. Record a stable change id, concise summary, source request, comparison base,
+   affected projects, measurable acceptance outcomes, risk, required verification
+   profiles, and sign-off state. Link the project-owned specification when one owns
+   product behavior; otherwise state why the change contract is sufficient.
+4. Classify risk as low, medium, or high using project policy. When policy requires
+   sign-off, stop implementation until approval evidence exists.
+5. Validate the document with processctl contract validate --kind change, then
+   register it with processctl change start. Registration completes specification;
+   it does not authorize implementation.
+6. Hand the registered contract to planning. Keep durable product decisions in their
+   project-owned specification rather than in process history.
+
+## Hard gates
+
+- Do not replace missing product decisions with assumptions.
+- Do not lower required security, compatibility, migration, accessibility, or
+  evidence boundaries to keep moving.
+- Report missing or blocked evidence honestly.
+
+## Output
+
+Return the registered change id, validated contract, unresolved decisions, sign-off
+state, lifecycle phase, and next owner.

engineering_process-0.1.0/.agents/skills/design-module/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: design-module
+description: Decide durable module boundaries, ownership, data, persistence, messages, integration contracts, and operational guarantees before foundational module implementation. Use for a new module or a change to established architecture.
+---
+
+# Design a Module
+
+## Goal
+
+Produce a ready or blocked architecture decision that tactical implementation can
+follow without reopening foundational ownership.
+
+## Workflow
+
+1. Read the owning product contract, project architecture, enforcement status, and
+   current design assessment.
+2. Define language, lifecycle and data ownership, mutation authority, upstream inputs,
+   downstream contracts, composition boundary, and forbidden dependencies.
+3. Decide invariants, requests, validation, authorization, tenancy, idempotency,
+   concurrency, and business-failure mapping where applicable.
+4. Decide persistence, migration, transaction, query, rollback, and operational
+   boundaries from current requirements rather than hypothetical reuse.
+5. Define message delivery, ordering, versioning, replay, retention, and rebuild only
+   for message or event patterns actually in scope.
+6. Name deterministic enforcement and proving evidence, then return ready or blocked.
+
+## Hard gates
+
+- Do not place product behavior in a shared module without an explicit contract.
+- Do not choose event sourcing or another high-operational-cost pattern without the
+  required project approval and complete operational decisions.
+- Do not implement a foundational module while its architecture is blocked.
+
+## Output
+
+Return readiness, boundary, ownership, invariants, persistence, integration, events,
+operations, enforcement, evidence, and adopted tactical patterns.

engineering_process-0.1.0/.agents/skills/evolve-process/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: evolve-process
+description: Improve or retire engineering process guidance from validated defects, escaped gates, false positives, review findings, or repeated friction. Use when evidence suggests a local fix, reusable rule, deterministic checker, schema change, or obsolete process behavior.
+---
+
+# Evolve the Process
+
+## Goal
+
+Change the smallest correct owner and prove the affected class without turning
+incident history into permanent ceremony.
+
+## Workflow
+
+1. Start from a reproducer, escaped defect, false positive, review finding, or measured
+   workflow cost. Do not generalize from speculation alone.
+2. Classify the evidence as a project-local defect, reusable process rule,
+   deterministic invariant, portability gap, or obsolete rule.
+3. Fix local behavior in the project owner. Change shared skills only for portable
+   semantics. Add CLI or schema enforcement only when deterministic.
+4. Add a regression case at the lowest reliable boundary. For skill behavior, run a
+   realistic forward test without providing the expected answer.
+5. Validate backward compatibility, version impact, consumer locks, and migration
+   needs. Remove superseded guidance instead of preserving duplicate paths.
+6. Measure whether the change improves task fidelity without disproportionate
+   workflow cost.
+
+## Hard gates
+
+- Do not promote an agent-host quirk into the portable core.
+- Do not add a gate without an owner, failure message, and regression proof.
+- Do not break a released schema within its major version.
+
+## Output
+
+Report classification, changed owner, regression evidence, version impact, affected
+consumers, and any rule retired.

engineering_process-0.1.0/.agents/skills/finish-change/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: finish-change
+description: Complete an independently approved engineering change only when its checkpoint, verification, review, findings, and workspace remain current. Use after review approval and before any completion, merge-readiness, release-readiness, or delivery claim.
+---
+
+# Finish a Change
+
+## Goal
+
+Close the lifecycle with an auditable completion record without publishing, merging,
+or deploying implicitly.
+
+## Workflow
+
+1. Read processctl change status and require the approved phase.
+2. Confirm the current clean checkpoint and workspace fingerprint match the approved
+   review and every required verification report.
+3. Confirm every acceptance criterion is covered, every required finding is resolved,
+   required sign-off is current, and project-owned status or evidence is reconciled.
+4. Run processctl change finish. Treat any stale artifact, source change, missing
+   profile, or identity mismatch as a blocker that returns to the owning phase.
+5. Report completion separately from publication, merge, release, or deployment.
+   Perform those operations only through an explicitly authorized project workflow.
+
+## Hard gates
+
+- Do not finish a changes-requested, merely verified, or review-pending change.
+- Do not reuse approval after the source checkpoint or workspace changes.
+- Do not infer release or deployment authorization from process completion.
+
+## Output
+
+Return change id, completed checkpoint, comparison base, verification reports,
+independent-review report, completion record, and any separate publication owner.

engineering_process-0.1.0/.agents/skills/govern-ui/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: govern-ui
+description: Define, review, verify, enforce, or replace shared UI contracts, semantic roles, tokens, surface archetypes, component ownership, visual evidence, and conformance policy. Use when a change affects cross-feature visual language or reusable interaction composition.
+---
+
+# Govern a UI System
+
+## Goal
+
+Maintain one enforceable UI contract per shared visual or interaction decision while
+features retain product state and content ownership.
+
+## Workflow
+
+1. Declare one coherent review unit with one owner, contract, invalidation set, and
+   rollback boundary. Obtain the required design decision before implementation.
+2. Inventory representative surfaces and define semantic roles across color,
+   typography, spacing, density, elevation, motion, layout, interaction, feedback,
+   responsiveness, and accessibility.
+3. Keep reusable values in the project-declared theme or token owner and expose typed
+   semantic contracts to consumers. Avoid policy based on filenames or source text.
+4. Define ownership, allowed composition, consumer registration, acceptance criteria,
+   evidence kinds, required modes, invalidation triggers, and retirement behavior.
+5. Implement only the declared unit. Prove types, rendered ownership, behavior,
+   accessibility, responsive modes, and visual evidence through project commands.
+6. Keep machine lifecycle and coverage state honest. Human acceptance cannot be
+   inferred from deterministic checks, and accepted evidence must be invalidated by
+   declared contract, theme, owner, consumer, or evidence changes.
+
+## Hard gates
+
+- Do not refresh a baseline merely to silence unexplained drift.
+- Do not mark an unproved requirement covered or claim standards compliance without
+  criterion-level evidence.
+- Do not leave a retired composition on the supported path after a clean replacement.
+
+## Output
+
+Lead with review-unit state and decision needed; retain owners, consumers, semantic
+decisions, modes, coverage, evidence, acceptance, invalidation, and retirement audit.

engineering_process-0.1.0/.agents/skills/implement-change/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: implement-change
+description: Implement a registered engineering plan, preserve scope and project policy, and prepare a clean immutable checkpoint for required verification. Use after processctl reports the change as planned or after independent review requests changes.
+---
+
+# Implement a Change
+
+## Goal
+
+Produce the smallest complete implementation of the registered plan and return it to
+the canonical verification and review lifecycle.
+
+## Workflow
+
+1. Confirm processctl change status reports planned or changes-requested, then register
+   the implementation actor and isolated context with processctl change implement.
+2. Read the contract, plan, nearest AGENTS.md, and affected project owners. Resolve a
+   conflict through the owning contract instead of silently changing scope.
+3. Implement work items in dependency order. Add or update proving tests at the lowest
+   reliable boundary and keep generated artifacts, migrations, callers, and docs in
+   the same accepted slice.
+4. Run focused project checks while editing. These checks diagnose implementation but
+   do not replace lifecycle verification.
+5. Reconcile every acceptance criterion and planned work item. Record exact blockers
+   or accepted deferrals; never convert missing evidence into completion.
+6. Create a clean immutable checkpoint according to project policy, then hand the
+   change to verify-change. After review findings, preserve the reviewed checkpoint,
+   begin the next implementation cycle, resolve findings, and repeat verification.
+
+## Hard gates
+
+- Do not implement before a valid plan and required sign-off.
+- Do not expand product behavior, compatibility, dependencies, or trust boundaries
+  without returning to specification and planning.
+- The implementation actor cannot perform or approve independent review for a cycle
+  in which it implemented source.
+
+## Output
+
+Return change id, cycle, implemented work items, changed owners, focused evidence,
+checkpoint readiness, gaps, and next owner.

engineering_process-0.1.0/.agents/skills/implement-module/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: implement-module
+description: Implement approved tactical module patterns for domain behavior, coordination, persistence, read models, concurrency, and messaging. Use only when current acceptance criteria or a ready module design requires those patterns.
+---
+
+# Implement a Module
+
+## Goal
+
+Implement and prove only the tactical patterns selected by current product and
+architecture contracts.
+
+## Workflow
+
+1. Confirm every requested pattern is required by current acceptance criteria or a
+   ready module design. Return undecided foundational choices to design-module.
+2. Implement domain invariants, identities, values, lifecycle, and safe failures in
+   the project-declared domain boundary.
+3. Implement coordination, validation, transactions, repositories, queries,
+   deterministic ordering, and concurrency only as selected.
+4. Implement messages, delivery, inbox, outbox, or replay only when their operational
+   semantics are already decided.
+5. Prove behavior at the lowest reliable project boundary and add deterministic
+   enforcement only for reusable declared invariants.
+6. Return the evidence and remaining architecture decisions to the caller.
+
+## Hard gates
+
+- Do not add tactical patterns for hypothetical future needs.
+- Do not leak infrastructure dependencies across a forbidden architecture boundary.
+- Do not call a rule enforced without a deterministic mechanism and regression proof.
+
+## Output
+
+Return the implemented pattern set, source boundaries, behavior and persistence
+evidence, enforcement changes, and blocked decisions.

engineering_process-0.1.0/.agents/skills/implement-use-case/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: implement-use-case
+description: Implement a planned product slice from an approved use-case contract, preserving layer ownership, acceptance traceability, generated artifacts, and honest status. Use as a domain overlay within the shared implementation lifecycle.
+---
+
+# Implement a Use Case
+
+## Goal
+
+Deliver one coherent product slice whose source and tests trace to approved behavior.
+
+## Workflow
+
+1. Read the registered change, plan, owning use case, applicable foundation and
+   architecture contracts, and affected project instructions.
+2. Map each in-scope acceptance criterion to work items and its lowest reliable test
+   boundary before editing.
+3. Implement in dependency order defined by the project architecture. Stop when a
+   required lower boundary or owner decision is unresolved.
+4. Keep adapters thin, generated contracts authoritative, business failures explicit,
+   and compatibility aligned with the approved design decision.
+5. Update tests, generated artifacts, acceptance evidence, and product status in the
+   same slice. Remove retired callers and guidance when overlap is not required.
+6. Run focused project commands during implementation, then return to shared
+   verification, independent review, and completion gates.
+
+## Hard gates
+
+- Do not treat product evidence as a replacement for lifecycle verification.
+- Do not mark behavior complete without current evidence for required outcomes.
+- Do not broaden the planned product scope without updating its contract and plan.
+
+## Output
+
+Return implemented scope, acceptance mapping, source and generated artifacts, tests,
+status changes, delegated decisions, deferrals, and remaining gaps.

engineering_process-0.1.0/.agents/skills/integrate-mcp/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: integrate-mcp
+description: Design, implement, verify, and maintain a typed Model Context Protocol tool surface backed by an authoritative application API. Use for operation coverage, tool schemas, authorization, mutation safety, runtime registration, or supported-client evidence.
+---
+
+# Integrate MCP
+
+## Goal
+
+Expose useful typed tools without creating a second domain authority or bypassing the
+application's authentication, authorization, validation, tenancy, and concurrency.
+
+## Workflow
+
+1. Read the authoritative API contract, product acceptance criteria, integration
+   architecture, current operation inventory, and supported client lifecycle.
+2. Classify every applicable API operation as exposed, intentionally internal, or
+   blocked with an owner. Do not silently omit gaps.
+3. Map each exposed operation to a typed semantic tool. Preserve server-owned request,
+   response, identity, authorization, idempotency, revision, and failure contracts.
+4. Classify tools as read, write, or destructive. Do not retry mutations after an
+   ambiguous timeout or server failure; bind confirmations to authoritative state.
+5. Prove protocol shape, operation coverage, safety, authenticated integration, tool
+   registry refresh, authorized invocation, and required read-back.
+6. Stop at browser consent, credentials, permissions, client reload, or other
+   user-controlled boundaries. Preserve the pending operation and exact evidence.
+
+## Hard gates
+
+- Do not let the tool adapter call internal storage or domain implementation directly.
+- Do not accept caller-supplied identity that must come from authentication context.
+- A protocol harness or raw API call cannot replace supported-client runtime evidence.
+
+## Output
+
+Return operation coverage, tool changes, auth and mutation decisions, protocol and
+runtime evidence, client state, read-back result, and blockers.

engineering_process-0.1.0/.agents/skills/maintain-docs/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: maintain-docs
+description: Maintain durable documentation, diagrams, links, status text, routing, and ownership without duplicating product or process decisions. Use when guidance changes, when renamed or retired concepts may drift, or when documentation consistency must be verified.
+---
+
+# Maintain Documentation
+
+## Goal
+
+Keep one authoritative owner per fact and make every dependent document point to it.
+
+## Workflow
+
+1. Classify the content as product behavior, architecture, process, enforcement,
+   operations, navigation, or generated output.
+2. Locate the project-declared owner. Preserve the domain decision supplied by that
+   owner; documentation maintenance does not invent it.
+3. Edit the owner once, replace duplicate rules with links, and remove stale names,
+   session history, temporary status, and superseded instructions.
+4. Update diagrams or generated documentation from their declared source rather than
+   editing derived output independently.
+5. Run the smallest documentation checks declared by the project verification
+   profiles. Validate changed links and anchors when their targets moved.
+6. Apply the retirement sweep and report unresolved ownership or generation gaps.
+
+## Hard gates
+
+- Do not move product, architecture, or release authority into a documentation skill.
+- Do not keep approval provenance or conversational history as durable policy.
+- Do not duplicate a reusable process rule in a consumer project.
+
+## Output
+
+Return the owner changed, duplicates removed, generated artifacts, retirement sweep,
+verification evidence, and unresolved ownership decisions.

engineering_process-0.1.0/.agents/skills/plan-change/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: plan-change
+description: Build and register an executable implementation plan from a specified change contract. Use after change specification and required sign-off, before editing implementation files for any non-trivial engineering change.
+---
+
+# Plan a Change
+
+## Goal
+
+Convert accepted outcomes and project policy into one bounded, reviewable execution
+plan without changing implementation source.
+
+## Workflow
+
+1. Read lifecycle status, the registered change contract, nearest AGENTS.md, and only
+   the project owners needed for the affected surface.
+2. Trace callers, consumers, trust boundaries, tests, migrations, generated outputs,
+   documentation, and retirement work far enough to define complete work items.
+3. Record ordered work items with owned paths and verification profiles. Map every
+   acceptance criterion to at least one work item and project-owned profile.
+4. Record concrete risks and mitigations. Leave behavior-changing ambiguity as an
+   open decision; do not plan around it.
+5. Validate the plan with processctl contract validate --kind plan, then register it
+   with processctl change plan. Implementation remains blocked while required
+   sign-off or open decisions remain.
+
+## Hard gates
+
+- Do not edit implementation files during planning.
+- Do not omit required security, compatibility, data, accessibility, rollout, or
+  rollback work merely to reduce scope.
+- Do not invent project commands; select profiles from .process/project.json.
+
+## Output
+
+Return change id, lifecycle phase, ordered work items, acceptance mapping, risks,
+open decisions, required profiles, and next owner.

engineering_process-0.1.0/.agents/skills/publish-change/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: publish-change
+description: Publish or update a branch, pull request, or equivalent review object after the engineering lifecycle completes. Use only when the user authorizes a remote publication action or asks to change publication metadata.
+---
+
+# Publish a Change
+
+## Goal
+
+Publish one approved immutable checkpoint through the project-owned remote workflow
+without duplicating implementation, verification, or review.
+
+## Workflow
+
+1. Classify the exact authorized remote action and read the project publication
+   policy and current lifecycle status.
+2. For source publication, require a current completion record whose checkpoint and
+   workspace fingerprint match the source being published.
+3. Populate the managed PR-description sections with project-specific facts. Run
+   processctl publication validation for branch, commit range, PR title, body, and
+   draft/ready state; then run any stronger project-declared publication checks.
+4. Perform only the authorized remote action. Preserve draft state unless ready state
+   was explicitly requested.
+5. Record the remote identifier and status. Treat any later source change as a new
+   lifecycle cycle with invalidated publication readiness.
+
+## Hard gates
+
+- Never infer authorization to commit, push, open, merge, release, or deploy.
+- Do not publish source with stale evidence or unresolved required findings.
+- Do not replace, omit, or weaken the managed publication sections or standard
+  requirements; projects may append stricter metadata and checklists.
+- Metadata-only work may skip code implementation only when project policy permits it.
+
+## Output
+
+Return action, change id, checkpoint, completion evidence, metadata validation,
+remote state, and blockers.