@mriekki/lean 0.0.0-stage → 0.1.1

package/assets/generated/core/core/skills/deliver/SKILL.md

@@ -0,0 +1,315 @@
+---
+name: deliver
+description: "Streamlined delivery after implementation review/approval: short-lived branch recovery/setup, selective commit/push/PR/CI mechanics, one explicit merge/finalize gate, post-merge CI, and safe delivered-branch cleanup."
+argument-hint: "[optional work-item ID or external key]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Deliver
+
+`/deliver` is the clear handoff after:
+
+```text
+implementation complete
+→ relevant local checks satisfactory
+→ Reviewer READY
+→ human meaningful-diff approval
+```
+
+Existing repository conventions outrank Lean defaults. Preserve branch rules, PR template, CI, merge strategy, required reviews, long-lived branch policy, and other repository policy.
+
+## 1. Authorization model
+
+Because `/deliver` is manually invoked, invoking it is one bounded authorization for the routine delivery mechanics of the already-reviewed/accepted work item:
+
+```text
+establish/recover the short-lived work branch when needed
+→ selective stage
+→ verify staged diff
+→ generate repository-appropriate commit message
+→ commit
+→ normal push
+→ create/update PR
+→ populate PR body from observed evidence
+→ inspect/recheck PR CI
+```
+
+Do **not** ask separate `Create branch?`, `Stage?`, `Commit?`, `Push?`, `Create PR?`, `Mark ready?`, or `Check CI?` questions when those actions are safe, deterministic, and within the current delivery scope.
+
+Invocation does **not** authorize merge, production deployment, force push, unrelated branch deletion, scope expansion, code fixes, or destructive/history-rewriting Git operations.
+
+## 2. Phases
+
+```text
+A. RESUME / PREFLIGHT
+B. ROUTINE PR PREPARATION — automatic within /deliver authorization
+C. PR CI — automatic read/recheck within practical limits
+D. MERGE + FINALIZE DECISION — one human gate
+E. POST-MERGE DEFAULT-BRANCH CI — automatic observation
+F. DELIVERED-BRANCH FINALIZATION — automatic when authorized and safe
+G. DELIVERY COMPLETE
+```
+
+## 3. Resume-aware initial inspection
+
+Inspect only what is needed to determine the furthest safe delivery state, such as:
+
+```text
+git branch --show-current
+git status --short --branch
+git diff --stat
+git diff
+git diff --cached --stat
+git log -1 --oneline
+git remote -v
+```
+
+When available:
+
+```text
+gh auth status
+gh pr status
+```
+
+Resolve current work-item/review evidence and detect already-completed delivery steps.
+
+If implementation, required local checks, Reviewer, or human meaningful-diff approval are not ready, route back to the missing gate. Do not perform delivery writes merely because `/deliver` was invoked too early.
+
+If `/deliver` is rerun after interruption/tool unavailability, continue from the observed safe state. Do not repeat already-completed branch/commit/push/PR operations and do not ask the human to re-authorize the same routine mechanics.
+
+Examples:
+- branch exists + changes uncommitted → continue with selective staging/commit/push/PR;
+- commit exists + branch not pushed → push and continue;
+- branch pushed + no PR → create PR and continue;
+- PR exists + CI pending → inspect/recheck CI;
+- PR merged + post-merge CI pending → resume observation/finalization rather than starting over.
+
+## 4. Short-lived branch handling
+
+Normal implementation should already be on a short-lived work branch because `/start-work` establishes it when implementation begins.
+
+If reviewed, scoped, uncommitted work is still on the default/integration branch, `/deliver` may recover automatically by creating/switching to the repository-appropriate short-lived work branch while preserving the current worktree.
+
+Branch naming order:
+1. repository/team convention when defined,
+2. an already-existing branch clearly tied to the work item,
+3. Lean fallback: `<lowercase-work-item-id>-<concise-slug>` for ID-backed work, or `work/<concise-slug>` for an ad hoc change.
+
+Before creating/switching, capture enough worktree evidence to confirm the scoped diff. After switching, verify the same files/content remain changed and no work was lost or broadened.
+
+Do not ask a separate branch-creation question when the branch operation is safe and deterministic under this rule.
+
+Stop instead when:
+- branch policy/naming is materially ambiguous,
+- an intended branch already exists with divergent/unrelated work,
+- unrelated/unexpected files are present,
+- switching would require stash/reset/rebase/force/history rewriting,
+- repository policy forbids the planned branch operation.
+
+## 5. Routine PR preparation
+
+Proceed automatically within `/deliver` authorization:
+
+1. Selectively stage only the accepted delivery scope. Do not use blind `git add .` when unrelated changes exist.
+2. Inspect staged diff/stat and verify it still matches the human-accepted implementation scope.
+3. Generate a concise repository-appropriate commit message; do not create a separate commit-message approval ceremony unless ambiguity is material.
+4. Commit.
+5. Push normally without force.
+6. Create a normal PR when none exists, or update/use the existing branch PR when appropriate.
+7. Use Draft PR only when repository policy/convention requires it or meaningful work is still intentionally incomplete. Because `/deliver` begins after implementation/review acceptance, a normal ready PR is the default Lean behavior.
+8. Populate the PR body from actual evidence only.
+9. Inspect PR CI.
+
+The repository PR template is internal scaffolding. Do not ask the human to validate the template itself.
+
+PR evidence may include:
+- work item,
+- change summary,
+- approved requirements/acceptance criteria,
+- local checks actually observed,
+- Reviewer verdict,
+- known limitations/follow-up,
+- CI status when observed.
+
+Do not claim evidence that was not observed.
+
+## 6. Stop conditions during routine delivery
+
+Stop before/during routine writes for:
+- unrelated/unexpected files,
+- possible secrets,
+- unclear work-item boundary,
+- known failing required local checks,
+- Reviewer `CHANGES REQUIRED`,
+- conflicts,
+- Git/GitHub authentication/permission failure,
+- unexpected generated/tracked files,
+- repository policy that blocks the planned action,
+- a branch/remote state that requires rebase/reset/force or other history rewriting.
+
+Never force-push unless separately and explicitly authorized.
+
+## 7. PR CI
+
+Inspect repository-required PR checks without asking permission for each recheck.
+
+### Pending
+
+Use bounded read-only polling/rechecks when practical. If CI is still running beyond the practical interaction/tool window, report:
+
+```text
+PR CI: RUNNING
+Delivery state preserved. Re-run /deliver to resume.
+```
+
+Do not insert a new write-authorization prompt merely because CI is pending.
+
+### Failed
+
+Inspect failing evidence when available. Report the failure and offer inspect/diagnose/targeted-fix/stop. Do not automatically change code because CI failed.
+
+Any code fix returns through the review/meaningful-diff gate as warranted before delivery resumes.
+
+### Green
+
+Before the merge gate, verify:
+- PR head branch/head SHA are the expected delivered branch/commit,
+- no unexpected commits appeared,
+- PR diff still represents the locally reviewed/accepted implementation,
+- Reviewer/policy/check state is still satisfactory,
+- PR is mergeable under observed repository rules.
+
+If the final PR differs materially from the accepted local implementation, require final diff review before merge. Do not silently treat changed evidence as accepted.
+
+If a Draft PR was required earlier and all readiness conditions are now satisfied, mark it ready as routine delivery mechanics unless repository policy requires a different human/reviewer action.
+
+## 8. Single merge + finalize gate
+
+When PR evidence still matches the accepted implementation and CI/policy are satisfactory, combine final PR acceptance and merge authorization into one meaningful gate:
+
+```text
+MERGE READY
+
+PR CI: GREEN
+Reviewer: READY
+PR diff: matches accepted delivery scope
+Mergeable/policy: <observed state>
+
+1. Merge and finalize delivery [HUMAN ACCEPTANCE + GITHUB/GIT WRITE] — recommended
+2. Review final PR diff first [READ ONLY]
+3. Leave PR open [NO ACTION]
+```
+
+Selecting option 1 means:
+- the human accepts the final PR as observed,
+- merge is authorized using the repository-approved strategy,
+- required post-merge default-branch CI may be observed/rechecked automatically,
+- after required post-merge CI is green, the delivered normal short-lived branch may be finalized automatically locally/remotely under the safety rules below.
+
+Do not present a second `Accept PR?` prompt immediately followed by `Merge?` when the evidence has not changed.
+
+If the human chooses to review the final PR diff, return to this same merge gate after the review if no new issues appear.
+
+If merge strategy is materially ambiguous and repository convention does not resolve it, stop and ask rather than inventing one.
+
+Before merge, record the PR head branch and head SHA so finalization can distinguish the approved delivered state from later work.
+
+Stop before merge if checks regress, new commits appear, conflicts arise, or policy changes the state.
+
+## 9. Post-merge default-branch CI
+
+After authorized merge, inspect the actual configured default branch/workflow automatically.
+
+If required post-merge CI is pending, use bounded read-only rechecks when practical. If still pending beyond the practical interaction/tool window, report:
+
+```text
+MERGED — DEFAULT-BRANCH CI PENDING
+Delivery state preserved. Re-run /deliver to resume finalization.
+```
+
+Do not ask the human to authorize observation again.
+
+If post-merge CI fails, report it clearly and inspect/diagnose; do not silently revert, modify production, or delete the delivered branch.
+
+Only after required post-merge CI is observed green may delivered-branch finalization proceed. If the repository has no post-merge CI policy, state that explicitly and proceed using the observed merged/default-branch state.
+
+## 10. Delivered-branch finalization
+
+For a normal short-lived delivered branch, option 1 at the merge gate already authorizes finalization. Do not ask a separate `Delete branch?` question.
+
+Preserve by default:
+- the configured default branch,
+- protected branches,
+- release/integration/environment branches intended to be long-lived,
+- branches repository policy says to retain,
+- a branch the human explicitly asked to retain before/during the merge gate,
+- any branch whose state changed or became ambiguous after merge.
+
+Before deletion, revalidate:
+- the PR is still merged,
+- the recorded PR head branch/head SHA are unchanged as delivery evidence,
+- the remote branch, when present, still points to the recorded PR head SHA,
+- no open PR now depends on the branch,
+- the local branch has no commits beyond the recorded approved PR head,
+- the working tree is safe to switch to the default branch.
+
+Then:
+1. switch to the default branch,
+2. update it using the repository's normal non-rewriting method, usually `git pull --ff-only`,
+3. delete the remote delivered branch when it still exists and policy allows,
+4. delete the local delivered branch,
+5. prune stale remote-tracking refs,
+6. confirm final default-branch/working-tree state.
+
+For the local branch:
+- prefer `git branch -d <branch>` when Git recognizes it as merged,
+- squash/rebase merges may make `-d` reject even when the PR is merged,
+- only when merged-PR evidence is exact and the local head has no commits beyond the recorded PR head may `git branch -D <branch>` be used under the merge-and-finalize authorization.
+
+An already-auto-deleted remote branch is `already clean`, not a failure.
+
+Never use force deletion merely to bypass uncertainty.
+
+If any safety condition fails, preserve the branch and report `BRANCH CLEANUP PENDING` with the exact reason instead of asking repetitive yes/no questions.
+
+## 11. Delivery completion
+
+Report the observed outcome:
+
+```text
+DELIVERY COMPLETE
+
+PR: MERGED
+Default branch: UPDATED
+Post-merge CI: GREEN / NOT CONFIGURED
+Branch finalization: DELETED / RETAINED BY POLICY OR CHOICE / ALREADY CLEAN
+```
+
+If merge/default-branch delivery is complete but requested/authorized cleanup could not be performed safely, report:
+
+```text
+DELIVERY COMPLETE — BRANCH CLEANUP PENDING
+```
+
+and preserve the branch.
+
+## 12. Production handoff
+
+If the delivered work item owns production release/deployment, successful engineering delivery may hand off to:
+
+```text
+/production-readiness <deployment-enabler-ID> enable
+```
+
+Merge approval never implies production-deployment authorization.
+
+## 13. Relationship to /start-work, /next-step, and /cleanup-branches
+
+`/start-work` establishes the short-lived work branch as routine implementation setup once implementation is actually authorized.
+
+`/next-step` answers `Where am I?`.
+
+`/deliver` takes reviewed/accepted work through routine branch/commit/push/PR/CI mechanics automatically, then stops once for the merge-and-finalize decision.
+
+`/cleanup-branches` is the standalone preview-first path for accumulated, previously retained, unrelated, or otherwise out-of-band branch housekeeping.

package/assets/generated/core/core/skills/deploy/SKILL.md

@@ -0,0 +1,193 @@
+---
+name: deploy
+description: "Guided deployment orchestration for a configured named environment. Selects and verifies the environment/target, preserves production gates, and delegates deterministic execution to repository-provided platform scripts."
+argument-hint: "[environment] [release-or-artifact]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Deploy
+
+`/deploy` is the normal human-facing deployment interface once deployment engineering and the selected environment are ready.
+
+The skill owns interaction, validation, target safety, and authorization. Repository-provided scripts own deployment mechanics.
+
+Do not implement application deployment logic directly in the skill when an approved repository script exists.
+
+## 1. Begin read-only
+
+Invocation starts read-only.
+
+Read only the minimum repository context needed to identify:
+
+- the approved deployment/release requirements,
+- configured named deployment environments,
+- checkout-local environment-to-target bindings when the project uses them,
+- the selected environment's readiness evidence,
+- the approved release/artifact policy,
+- repository-provided deployment entry points,
+- expected developer-workstation and target operating systems.
+
+Do not assume configuration file names, script paths, target OS, SSH aliases, container runtime, or release format unless the repository establishes them.
+
+If deployment engineering is not delivered or the selected environment is not operationally ready, stop and route to the repository's deployment work item or `/production-readiness` as appropriate.
+
+## 2. Select an environment explicitly
+
+If the invocation did not name an environment, enumerate only environments configured for this checkout and ask the human to select one.
+
+Show enough non-secret identity to distinguish them, for example:
+
+```text
+SELECT DEPLOYMENT ENVIRONMENT
+
+1. staging
+   Role: non-production
+   Target: portable-ubuntu
+   [REMOTE WRITE]
+
+2. production
+   Role: production
+   Target: home-production
+   [PRODUCTION WRITE]
+
+3. Stop
+```
+
+Environment names and target labels above are examples only.
+
+Rules:
+
+- never silently default to `production`;
+- never use a remembered prior selection as implicit production authorization;
+- never fall back from one environment to another because discovery, access, readiness, or deployment failed;
+- if an environment is named but is not configured in this checkout, fail explicitly;
+- selecting an environment chooses scope but does not itself authorize the deployment write.
+
+## 3. Resolve and verify the target binding
+
+Treat these as separate concepts:
+
+```text
+named environment
+→ configured target binding
+→ stable logical/SSH identity
+→ current address discovery
+→ independently verified host identity
+```
+
+Address discovery is not host trust.
+
+Before a remote deployment:
+
+- verify the selected environment resolves to its configured target;
+- use the repository-approved stable target/SSH alias rather than a hard-coded transient address when that is the approved design;
+- preserve enrolled SSH host-key verification independently of the current IP address;
+- stop on an unknown host identity or changed host key;
+- never bypass host-key checks, silently enroll new trust, scan/select another host, or weaken network controls as recovery;
+- verify the actual target OS is compatible with the environment's approved expected target OS before choosing target-specific deployment behavior.
+
+Changing an environment's bound target is configuration/readiness work, not a deployment fallback. Stop and route to the approved rebind/readiness workflow when rebinding is needed.
+
+Keep private keys, passphrases, credentials, copied trust databases, and other secret values out of repository configuration and logs.
+
+## 4. Select the local launcher by developer workstation OS
+
+Use repository-provided platform-appropriate deployment entry points.
+
+Typical dispatch is:
+
+```text
+Windows developer workstation → approved PowerShell deployment entry point
+macOS/Linux developer workstation → approved shell deployment entry point
+```
+
+The repository may define different supported launchers. Follow its contract rather than inventing a path.
+
+The launcher choice is based on the developer workstation OS. Target-specific behavior is based on the selected environment's approved target OS. Do not confuse those two dimensions.
+
+If the developer workstation or target OS is unsupported by the repository's approved deployment implementation, stop with a clear blocker.
+
+## 5. Preserve one deployment contract across launchers
+
+Where a repository provides multiple local launchers, they must preserve equivalent deployment semantics and safety behavior.
+
+Prefer a common logical contract such as:
+
+```text
+environment
+release/version or artifact identity
+immutable digest when required
+dry-run/check mode when supported
+```
+
+Do not pass secret values on command lines merely to make launchers symmetric. Use the repository's approved protected credential mechanism.
+
+Environment-specific values are configuration, not reasons to duplicate otherwise equivalent deployment procedures.
+
+## 6. Resolve release/artifact identity
+
+Use the repository's approved policy for the selected environment.
+
+For a production-role environment, require the approved formal release/artifact evidence, including immutable identity when the project requires it.
+
+For non-production environments, the repository may allow the same formal release policy or a broader immutable CI/commit artifact policy. Do not invent broader permissions when the project has not approved them.
+
+When promoting a tested artifact from a non-production environment to production, prefer deploying the exact same immutable artifact/digest rather than rebuilding it for production.
+
+## 7. Present the deployment preview and authorization gate
+
+Before running the modifying deployment script, show the resolved non-secret facts:
+
+```text
+DEPLOYMENT READY
+
+Environment: <name>
+Role: <production|non-production>
+Target: <verified logical target>
+Target OS: <verified>
+Launcher: <repository-provided script>
+Release/artifact: <verified identity>
+Readiness blockers: NONE
+```
+
+For a non-production remote deployment ask for one bounded authorization such as:
+
+```text
+Authorize deployment to <environment>? [REMOTE WRITE]
+```
+
+For a production-role environment require the project's explicit production deployment gate:
+
+```text
+Authorize deployment to <environment>? [PRODUCTION WRITE]
+```
+
+Production authorization applies only to the exact environment, verified target, release/artifact, and evidence shown. If any of those materially changes, stop and require renewed review/authorization.
+
+No requirements approval, code review, PR merge, CI pass, environment selection, prior deployment, or readiness result implicitly authorizes this deployment.
+
+## 8. Execute only the approved script contract
+
+After authorization, invoke the repository-provided launcher with the explicitly selected environment and approved release/artifact inputs.
+
+Do not perform unrelated host provisioning, target rebinding, firewall changes, credential creation, destructive recovery, or other out-of-band remote writes as part of `/deploy` unless they are explicitly part of the already-approved deployment script contract and authorization scope.
+
+If the script reports missing prerequisites, identity mismatch, unexpected target OS, lock contention, migration failure, readiness failure, or another blocker, stop according to the repository's deployment contract. Never redirect the deployment to another environment or host.
+
+## 9. Verify and record outcome
+
+After the script completes, use repository-provided readiness/smoke checks and evidence recording when available.
+
+Report at least the non-secret outcome supported by evidence:
+
+- selected environment,
+- verified target identity/label,
+- release/artifact identity,
+- deployment result,
+- readiness/smoke result,
+- rollback outcome when applicable.
+
+Do not report success merely because a command returned or a container/process started if the repository requires stronger readiness evidence.
+
+Application rollback and database restore/destructive recovery remain separate decisions when the project contract makes them separate.

package/assets/generated/core/core/skills/grill-me/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: grill-me
+description: Continuously challenge requirements, architecture, plans, implementation assumptions, or work-item coverage without editing files.
+argument-hint: "<work-item ID, external key, document, plan, or topic>"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Grill Me
+
+Purpose: improve reasoning by challenging the highest-value uncertainty without adding process overhead.
+
+## Rules
+
+- Read `.github/lean-workspace.json` when present and only the minimum relevant context.
+- Ask one material question at a time.
+- Explain briefly why the question matters.
+- Challenge vague answers, hidden scope, contradictions, and weak assumptions.
+- Recommend an answer or 2–3 options with tradeoffs when useful.
+- Do not edit files.
+- Do not invoke subagents.
+- Do not create artifacts merely because grilling occurred.
+- Do not claim external Jira/Issue content was read unless it was actually available.
+
+Challenge areas may include:
+- missing acceptance behavior,
+- cross-work-item/Epic gaps,
+- domain/business rules,
+- lifecycle/state transitions,
+- validation/failure behavior,
+- data integrity,
+- concurrency/transactions,
+- destructive/reversible actions,
+- architecture assumptions,
+- security/operational risk,
+- testability.
+
+## Cadence
+
+```text
+QUESTION
+<one focused question>
+
+WHY IT MATTERS
+<short explanation>
+
+RECOMMENDATION
+<recommended answer/options when useful>
+```
+
+After the human answers:
+
+```text
+analyze/challenge the answer
+→ explain implications when useful
+→ ask the next material question
+```
+
+Do not ask `Do you want to continue?` after each answer. The human already entered a continuous grilling mode.
+
+Stop only when:
+- the human says stop/done/pause,
+- no material issues remain,
+- a true scope/decision/action gate appears,
+- the human switches workflow.
+
+## Natural completion
+
+Summarize once:
+- decisions strengthened,
+- unresolved issues,
+- recommended next workflow.
+
+Typical next workflows:
+- `/grill-with-docs` to reconcile resolved decisions,
+- `/refine-requirements` for systematic detailed coverage,
+- `/start-work` when the item is ready.

package/assets/generated/core/core/skills/grill-with-docs/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: grill-with-docs
+description: Continuously challenge requirements/design and reconcile resolved decisions into permitted authoritative/supplemental documents or proposed external-work-item updates.
+argument-hint: "<work-item ID, external key, document, plan, or topic>"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Grill With Docs
+
+This is the documentation-aware form of `/grill-me`.
+
+## 1. Resolve authority
+
+Read `.github/lean-workspace.json` when present.
+
+Determine:
+- authoritative work-item source,
+- which local documents are authoritative/supplemental/read-only/not-used,
+- whether an external write integration is actually available and permitted.
+
+Never assume Product/Feature Briefs exist. Never assume `Jira Epic == Feature Brief`.
+
+## 2. Continuous grilling
+
+Ask one material question at a time and challenge:
+- ambiguous outcomes,
+- missing domain/engineering rules,
+- contradictory requirements,
+- lifecycle/destructive behavior,
+- data integrity/concurrency,
+- failure behavior,
+- accessibility/UX implications when relevant,
+- architecture/operational tradeoffs,
+- testability.
+
+When the challenge is a bounded decision with a small credible option set, use the choice-first interaction guidance from `INTERACTIVE_SESSION_GUIDE.md` and explain important tradeoffs. When the purpose is to expose or strengthen the human's reasoning, ask open-ended first; introduce options or hints later only when useful as scaffolding.
+
+Cadence:
+
+```text
+question
+→ human answer
+→ challenge/analyze
+→ reconcile the resolved decision when already authorized
+→ next material question
+```
+
+Do not ask whether to continue after every answer.
+
+## 3. Reconcile to the right authority
+
+When a decision is resolved:
+- update an existing permitted local authority/supplement only when the current session authorizes document edits;
+- if Jira/GitHub/another external system is authoritative and no permitted write integration is available, accumulate a concise `PROPOSED EXTERNAL WORK-ITEM UPDATE`;
+- if a permitted external write integration exists, require an explicit `[EXTERNAL WRITE]` choice before writing externally;
+- never create a competing local source merely to store an answer.
+
+For local-document models, common homes are:
+- brief: high-level scope/outcome/major rule,
+- combined requirements: detailed user/engineering behavior and testable scenarios,
+- decisions: resolved work-item decision/basis,
+- ADR: only a meaningful cross-cutting architecture decision.
+
+## 4. Editing authorization
+
+Invocation alone does not imply broad document-write permission.
+
+When document changes are needed, present a bounded choice such as:
+
+```text
+1. Continue grilling only [READ ONLY]
+2. Reconcile resolved decisions during this session [MODIFIES DOCS]
+3. Stop [NO ACTION]
+```
+
+After option 2 is selected, focused updates to the permitted current work-item documents are authorized for the active session. Do not ask again after each answer.
+
+Pause only when a new answer would change higher-level approved scope, contradict another authority/ADR, or require a new cross-cutting decision.
+
+## 5. Stop boundary
+
+Do not implement production code.
+
+At natural completion summarize:
+- decisions resolved,
+- documents/proposed external updates changed,
+- remaining conflicts/open items.
+
+If systematic detailed coverage is still needed, recommend `/refine-requirements`.