[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79HTVEM0DMXM41ZWHGP8DWH":3,"skill-same:01M79HTVEM0DMXM41ZWHGP8DWH":48},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M79HTVEM0DMXM41ZWHGP8DWH","leanrigor-sequential-workflow",null,"Use when running LeanRigor's persisted sequential workflow in Claude Code.","sumanshusamarora\u002FLeanRigor","sumanshusamarora","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F45642655?v=4","01M79HSZPGVH469CEZBZXBDG7T","Sam Arora","01M79HSZQ7WW6FGDQ9QDXYWS2J",1,"MIT","https:\u002F\u002Fgithub.com\u002Fsumanshusamarora\u002FLeanRigor\u002Fblob\u002Fmain\u002Fplugin-skills\u002Fsequential-workflow\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: leanrigor-sequential-workflow\ndescription: Use when running LeanRigor's persisted sequential workflow in Claude Code.\nallowed-tools: AskUserQuestion, Bash(${CLAUDE_PLUGIN_ROOT}\u002Fbin\u002Fleanrigor *)\n---\n\nLeanRigor is Claude's persisted workflow controller. Users interact in plain\nlanguage; Claude invokes LeanRigor CLI transitions internally and renders\nconcise workflow summaries.\n\nUse the plugin-owned runtime internally:\n\n`${CLAUDE_PLUGIN_ROOT}\u002Fbin\u002Fleanrigor`\n\nWrite user-provided request, answer, and feedback text through a tool-native\nfile operation and pass its path with `--request-file`, `--answer-file`, or\n`--feedback-file`. Never interpolate user text into a Bash command.\n\n## Engineering Methodology\n\nLeanRigor's shared methodology lives under `methodology\u002F` in the plugin root.\nAfter reading the current workflow mode from `flow next --json`, load:\n\n- `methodology\u002Fcore.md`\n- `methodology\u002Fmodes\u002F\u003Cfast|standard|rigorous>.md`\n\nThen load only the relevant methodology files for the current step:\n\n- planning or plan revision: `methodology\u002Fplanning.md`\n- design-heavy changes: `methodology\u002Fdesign.md`\n- implementation edits: `methodology\u002Fimplementation.md`\n- bugs, failures, failed repairs, or flaky behavior: `methodology\u002Fdebugging.md`\n- validation selection or recording: `methodology\u002Ftesting.md`\n- phase or final review: `methodology\u002Freview.md`\n- completion evidence or success claims: `methodology\u002Fevidence.md`\n- security, migration, API, data, privacy, production, infrastructure,\n  concurrency, or destructive-operation risks: `methodology\u002Fsafeguards.md`\n\nDo not load every methodology file for every task. Fast mode must stay compact.\n\nRepository-local state:\n\n- `.leanrigor\u002Fconfig.json`\n- `.leanrigor\u002Fworkflows\u002F`\n\nDo not create or modify repository `.claude\u002F` files in marketplace mode. Do not\ncommit, push, or spawn parallel agents automatically.\nLeanRigor is parallel-ready internally, but default execution remains\nsequential. Do not launch live parallel Claude agents. Use only\nLeanRigor-managed worktrees returned by the CLI; do not create ad hoc\nworktrees.\n\n## Conversational Flow\n\n`\u002Fleanrigor:start` is the primary command and owns the normal workflow:\n\n`triage summary -> approach approval -> Workflow Plan approval -> Phase Execution Brief approval -> workspace preparation -> provider dispatch -> provider result -> completion gate -> integration -> next Phase Execution Brief or final integrated review -> final completion`\n\nUse `flow active --json` to discover repository workflows and `flow next\n--json` to read the next gate. Use transition commands internally after user\napproval. Do not show shell commands during normal use.\n\nLifecycle terms must stay distinct:\n\n- `Approach approval`\n- `Workflow Plan approval`\n- `Phase Execution Brief approval`\n- `Workspace prepared`\n- `Provider dispatched`\n- `Provider completed`\n- `Completion gate passed`\n- `Phase accepted`\n- `Phase integrated`\n- `Final integrated validation passed`\n- `Final integrated review`\n- `User-approved final completion`\n\nNever collapse these into `Phase complete and approved`.\n\n## Active Workflow Selection\n\n- One active workflow: resume it.\n- No active workflow: start only when the user supplied a request. Invoke\n  `flow start --request-file \u003Crequest-file> --provider auto` so automatic triage can call Claude\n  when available. Refresh with `flow next --json` after start. Do not end the\n  turn from raw `flow start` JSON. Use `--provider deterministic` only when the user\n  explicitly requests deterministic triage.\n- Multiple active workflows: use `AskUserQuestion` to let the user choose among\n  them (header: \"Workflow\"). Show ID, request, state, mode, and updated time in\n  each option description. Do not render an ordinary text question first. Fall\n  back to a numbered list only when `AskUserQuestion` is genuinely unavailable.\n- Completed and cancelled workflows are not selected by default.\n- Never attach a new request to an unrelated active workflow silently.\n\n## Decision Envelope\n\n`flow next --json`, execution commands, polling, recovery, completion, and\nintegration use one normalized persisted envelope. `status` is authoritative.\nWhen `decision` exists, it contains a stable ID, exact revision identity,\nquestion, and ordered options. `nextOperation.automaticallyPermitted`\ndistinguishes an automatic operation from a user decision.\n\nAfter every state-changing command: read its envelope, refresh with `flow next\n--json`, render persisted status or decision, and invoke no additional\noperation unless `automaticallyPermitted` is true.\n\nWhen an envelope returns `decision`, call `AskUserQuestion` in the same\nassistant turn. This is mandatory whenever the tool is available. Use\n`decision.question` verbatim and copy every presented `decision.options` label\nand description in order. The controller limits and prioritizes this list to\nat most four options for `AskUserQuestion`. Match the selected option by persisted `intent` and run\nonly its persisted command. Never infer, cache, or reconstruct a question.\nNever call `AskUserQuestion` without a current `decision`.\n\nKeep the two presentation surfaces separate throughout the workflow. `flow next\n--json` always includes `presentation.markdown`; render it verbatim as normal\nassistant Markdown before calling `AskUserQuestion`. The selector question must be exactly\n`decision.question`; never copy `summary`, `status`, or\n`presentation.markdown` into it. The selector is for a compact choice, not for\ndisplaying an approval artifact.\n\nUse this `AskUserQuestion` input shape for approval selectors:\n\n```json\n{\n  \"questions\": [\n    {\n      \"question\": \"\u003Cdecision.question>\",\n      \"header\": \"Approach\",\n      \"options\": [\n        { \"label\": \"\u003Cdecision.options[0].label>\", \"description\": \"\u003Cdecision.options[0].description>\" }\n      ],\n      \"multiSelect\": false\n    }\n  ]\n}\n```\n\nReplace `header` with the current gate header and include every presented\noption in order.\n\nFall back to a numbered list of explicit choices only when `AskUserQuestion` is\ngenuinely unavailable in the current Claude Code environment. Each action has a\ndeterministic `command` which remains the authority for the transition. Do not infer approval from conversational tone — the user must select an action or type an explicit response.\nDo not use `ExitPlanMode` as a substitute for LeanRigor approval.\n\nFor the post-triage approach gate, render a compact summary before the selector.\n`flow next --json` returns both the decision envelope and the rich `summary`\nfield in a single call. Render `summary` first, then call `AskUserQuestion`\nwith `decisionEnvelope.decision.question` and `.options`:\n\n```text\nWorkflow created and triaged\n\nWorkflow: \u003Cid>\nMode: \u003CFast|Standard|Rigorous>\n\nAssessment\n\u003Ccomplexity, ambiguity, risk, blast radius, and concise explanation where available>\n\nKey constraints\n\u003Cpersisted triage constraints and explicit revision feedback>\n\nRecommended approach\n\u003Cpersisted recommended approach>\n\nNo implementation has started. Your approval is required before planning.\n```\n\nThen call `AskUserQuestion` in the same turn with one concise question and\nthese options in order:\n\n1. `Approve approach and create plan` — Continue to model-assisted planning\n   using the approved triage constraints.\n2. `Add constraints to workflow strategy` — Let me provide changes or additional constraints before\n   planning.\n3. `View workflow details` — Show full triage, policy, provenance, and current\n   workflow state.\n4. `Cancel workflow` — Stop this workflow without starting implementation.\n\nFor the clarification gate (`state: awaiting_clarification`), render the\npersisted question explicitly and verbatim before waiting for the user's answer:\n\n```text\nWorkflow created and triaged\n\nWorkflow: \u003Cid>\nRequest: \u003Crequest>\nProvisional recommendation: \u003CFast|Standard|Rigorous>\nFinal mode: pending clarification\n\nTriage clarification\n\nQuestion: \u003Cnext.summary.question or clarification.question>\n\nWhy this matters: \u003Cnext.summary.reason or clarification.reason>\n```\n\nDo not replace the question with the reason. Do not end with a blank prompt\nafter \"before continuing\". If `AskUserQuestion` is available, ask exactly the\npersisted question there as well; otherwise ask for a free-form answer in plain\nlanguage. The answer must be recorded through `flow answer \u003Cworkflow-id>\n--answer-file \u003Canswer-file> --provider auto`.\n\nClarification is already filtered by LeanRigor core. Do not invent additional\ntriage questions from repository scope or planning uncertainty; those are handled\nby targeted inspection or planning. When `next.summary.modeStatus` is\n`provisional`, do not present the mode as final.\n\n### Free-form fallback\n\nThe following typed responses remain supported as a fallback:\n\n- `approve`, `looks good`, `continue` at `awaiting_approach_approval`: approve approach with `flow approve-approach \u003Cworkflow-id> --provider auto`, adding `--add-constraint`, `--remove-constraint`, or `--override-constraint \"\u003Cold> => \u003Cnew>\"` for any user-supplied constraint changes, then immediately render the generated plan for plan approval. Use deterministic planning only when explicitly requested or when the model provider falls back with a recorded reason.\n- `approve`, `looks good`, `continue` at `awaiting_plan_approval`: approve only the Workflow Plan, then call `flow next --json` and render the persisted Phase Execution Brief approval decision. Do not invoke coordinator or manual execution until the user approves the exact brief revision.\n- `revise ...` at a Phase Execution Brief gate: persist the feedback with\n  `flow phase-brief \u003Cworkflow-id> \u003Cphase-id> --feedback-file\n  \u003Cfeedback-file>`, then render the new brief and its new pending decision.\n  Never reuse approval from the superseded revision.\n- `show status` during execution: render the persisted `recommendedNextPhase`\n  as the primary action. Show `otherDependencyReadyPhases` separately as\n  available only after explicit user choice. Do not replace Phase 2 with Phase\n  4 merely because both are dependency-ready.\n- `revise ...` at `awaiting_approach_approval`: record the feedback with `flow revise-approach \u003Cworkflow-id> --feedback-file \u003Cfeedback-file>`, rerender the updated workflow strategy summary, and ask for approval again. Do not start planning. This action records additional constraints; it does not regenerate the approach.\n- `revise ...` at `awaiting_plan_approval`: use `flow revise-plan \u003Cworkflow-id> --feedback-file \u003Cfeedback-file> --provider auto` unless deterministic planning was explicitly requested.\n- `reject because ...`: reject the approach with the supplied reason.\n- `cancel`: cancel the workflow after confirming intent when destructive to progress.\n- `show plan` \u002F `show status`: render persisted plan\u002Fstatus.\n- `repair it` at `needs_repair`: start the bounded repair requested by the gate.\n- `continue` at `needs_repair`, `needs_review`, or `needs_replan`: do not bypass the gate; explain the required repair, review, or replan.\n\nAsk one concise clarification for ambiguous responses.\n\n## Phase And Review Rules\n\nBefore phase approval, render the persisted Phase Execution Brief from `flow\nnext --json`. Render `presentation.markdown` verbatim in a normal assistant\nmessage before the selector. The response also includes both\n`decisionEnvelope` (question and options for `AskUserQuestion`) and `summary`\n(the rich brief details). Show the\nobjective, concrete deliverable, inspected current behaviour, implementation\napproach, read\u002Fwrite paths, relevant files and symbols, acceptance criteria,\ntest obligations, validation, dependencies, assumptions, exclusions, risks,\nchanges from the approved Workflow Plan, and inspection provenance from\n`summary`. Use the returned decision options in order from\n`decisionEnvelope.decision.options`. Do not summarise the Workflow Plan phase as\nthough it were the detailed brief.\n\nBrief generation is a read-only planning operation. It must not initialize a\nworkspace, dispatch the implementation provider, approve a phase, or expand\nwrite scope. If LeanRigor reports `Phase Execution Brief unavailable`, present\nits persisted retry, plan-boundary revision, diagnostics, and cancel actions.\nDo not invent a placeholder brief or proceed to execution.\n\nThe coordinator is the normal execution path. Invoke `flow execute-next\n--provider auto` or `flow execution-poll --provider auto` only after the exact\nbrief is approved and the refreshed envelope permits it. Use the scripted\nprovider only when explicitly requested. Claude must not implement phase edits\nitself or edit the original working tree. Present only persisted recovery\ndecisions; never silently switch provider or execution mode, and never fall\nback to main-session implementation. Manual execution requires an explicit\npersisted choice and explicit user selection.\n\nNever claim a\nphase is complete from visible file changes alone; only persisted LeanRigor\nstate and gates decide completion. Never compensate for an unavailable workflow\ntransition by narrating that the workflow is complete. Report the persisted\nstate and the exact blocker.\n\nDuring execution, each phase must pass:\n\n`planned -> ready -> leased\u002Frunning -> targeted validation -> completion gate -> completed | needs_repair | needs_review | needs_replan | blocked`\n\nUse `flow phase-result \u003Cworkflow-id> \u003Cphase-id> --json` to render provider\nidentity, changed files, scope checking, validation evidence, completion gate,\nintegration, risks, blockers, and next safe actions. Do not run `cd\n\u003Cphase-worktree> && git diff`, inspect the phase worktree, or request generic\nBash trust in the normal path. Manual inspection is allowed only when the user\nexplicitly requests it or persisted evidence is incomplete and a dedicated\ndecision states the reason.\n\nCoordinator-owned leases are completed by the coordinator only. Do not infer,\nprobe, or reuse a provider lease owner string from status output to run\n`phase-complete` directly. If the coordinator cannot collect a provider result,\npresent the recorded provider failure and the allowed recovery choices.\n\nAfter a phase gate passes, integrate the approved phase into the LeanRigor\nintegration worktree. After all required phases are integrated, run combined\nvalidation in the integration worktree before final integrated review. On\n`integration_conflict`, present the conflict-repair gate and do not resolve with\nours\u002Ftheirs.\n\nAfter Phase N is accepted and integrated, refresh. For phase-by-phase\nworkflows, render the freshly persisted Phase N+1 brief decision and its exact\noptions; never show a generic `Continue`. For workflow-authorized Standard\nflows, show a concise preflight status and continue only while the envelope\nmarks the next operation automatically permitted.\n\nIf a transition returns `revision_conflict`, reread workflow state and present\nthe changed situation. Never retry a rejected transition blindly. Raw lease and\nlock commands are troubleshooting details, not normal user-facing output.\n\nFinal integrated review remains required after all phase gates pass and the\ncurrent integration head has passing combined validation.\n\n## Presentation\n\nRender human summaries first. `flow next --json` returns both `decisionEnvelope`\nand the rich `summary` field, plus a deterministic `presentation.markdown`\nartifact for every workflow state. Always render that artifact as normal\nassistant Markdown before a decision selector. Never put that artifact inside\n`AskUserQuestion`: the selector receives only `decision.question` and its\noptions.\n\nRender at minimum:\n\n- workflow ID, request, mode, state;\n- current phase and completion-gate status;\n- criteria and validation progress;\n- repair attempts, blockers, and next action;\n- concise phase list or commit groups when relevant.\n\nAvoid raw JSON, repeated methodology, full state-machine dumps, and shell\ncommands in normal output.\n\n## Troubleshooting\n\nIf a LeanRigor command fails, show:\n\n```text\nI could not run the LeanRigor transition automatically.\n\nYou can retry, or run:\n\u003Cexact command>\n\nError:\n\u003Cconcise error>\n```\n\nRaw commands belong only in this troubleshooting fallback, manual\u002Fadvanced\ndocumentation, or when the user explicitly asks for them.\n","LeanRigor is Claude's persisted workflow controller. Users interact in plain\nlanguage; Claude invokes LeanRigor CLI transitions internally and renders\nconcise workflow summaries.\n\nUse the plugin-owned runtime internally:\n\n`${CLAUDE_PLUGIN_ROOT}\u002Fbin\u002Fleanrigor`\n\nWrite user-provided request, answer, and feedback text through a tool-native\nfile operation and pass its path with `--request-file`, `--answer-file`, or\n`--feedback-file`. Never interpolate user text into a Bash command.\n\n## Engineering Methodology\n\nLeanRigor's shared methodology lives under `methodology\u002F` in the plugin root.\nAfter reading the current workflow mode from `flow next --json`, load:\n\n- `methodology\u002Fcore.md`\n- `methodology\u002Fmodes\u002F\u003Cfast|standard|rigorous>.md`\n\nThen load only the relevant methodology files for the current step:\n\n- planning or plan revision: `methodology\u002Fplanning.md`\n- design-heavy changes: `methodology\u002Fdesign.md`\n- implementation edits: `methodology\u002Fimplementation.md`\n- bugs, failures, failed repairs, or flaky behavior: `methodology\u002Fdebugging.md`\n- validation selection or recording: `methodology\u002Ftesting.md`\n- phase or final review: `methodology\u002Freview.md`\n- completion evidence or success claims: `methodology\u002Fevidence.md`\n- security, migration, API, data, privacy, production, infrastructure,\n  concurrency, or destructive-operation risks: `methodology\u002Fsafeguards.md`\n\nDo not load every methodology file for every task. Fast mode must stay compact.\n\nRepository-local state:\n\n- `.leanrigor\u002Fconfig.json`\n- `.leanrigor\u002Fworkflows\u002F`\n\nDo not create or modify repository `.claude\u002F` files in marketplace mode. Do not\ncommit, push, or spawn parallel agents automatically.\nLeanRigor is parallel-ready internally, but default execution remains\nsequential. Do not launch live parallel Claude agents. Use only\nLeanRigor-managed worktrees returned by the CLI; do not create ad hoc\nworktrees.\n\n## Conversational Flow\n\n`\u002Fleanrigor:start` is the primary command and owns the normal workflow:\n\n`triage summary -> approach approval -> Workflow Plan approval -> Phase Execution Brief approval -> workspace preparation -> provider dispatch -> provider result -> completion gate -> integration -> next Phase Execution Brief or final integrated review -> final completion`\n\nUse `flow active --json` to discover repository workflows and `flow next\n--json` to read the next gate. Use transition commands internally after user\napproval. Do not show shell commands during normal use.\n\nLifecycle terms must stay distinct:\n\n- `Approach approval`\n- `Workflow Plan approval`\n- `Phase Execution Brief approval`\n- `Workspace prepared`\n- `Provider dispatched`\n- `Provider completed`\n- `Completion gate passed`\n- `Phase accepted`\n- `Phase integrated`\n- `Final integrated validation passed`\n- `Final integrated review`\n- `User-approved final completion`\n\nNever collapse these into `Phase complete and approved`.\n\n## Active Workflow Selection\n\n- One active workflow: resume it.\n- No active workflow: start only when the user supplied a request. Invoke\n  `flow start --request-file \u003Crequest-file> --provider auto` so automatic triage can call Claude\n  when available. Refresh with `flow next --json` after start. Do not end the\n  turn from raw `flow start` JSON. Use `--provider deterministic` only when the user\n  explicitly requests deterministic triage.\n- Multiple active workflows: use `AskUserQuestion` to let the user choose among\n  them (header: \"Workflow\"). Show ID, request, state, mode, and updated time in\n  each option description. Do not render an ordinary text question first. Fall\n  back to a numbered list only when `AskUserQuestion` is genuinely unavailable.\n- Completed and cancelled workflows are not selected by default.\n- Never attach a new request to an unrelated active workflow silently.\n\n## Decision Envelope\n\n`flow next --json`, execution commands, polling, recovery, completion, and\nintegration use one normalized persisted envelope. `status` is authoritative.\nWhen `decision` exists, it contains a stable ID, exact revision identity,\nquestion, and ordered options. `nextOperation.automaticallyPermitted`\ndistinguishes an automatic operation from a user decision.\n\nAfter every state-changing command: read its envelope, refresh with `flow next\n--json`, render persisted status or decision, and invoke no additional\noperation unless `automaticallyPermitted` is true.\n\nWhen an envelope returns `decision`, call `AskUserQuestion` in the same\nassistant turn. This is mandatory whenever the tool is available. Use\n`decision.question` verbatim and copy every presented `decision.options` label\nand description in order. The controller limits and prioritizes this list to\nat most four options for `AskUserQuestion`. Match the selected option by persisted `intent` and run\nonly its persisted command. Never infer, cache, or reconstruct a question.\nNever call `AskUserQuestion` without a current `decision`.\n\nKeep the two presentation surfaces separate throughout the workflow. `flow next\n--json` always includes `presentation.markdown`; render it verbatim as normal\nassistant Markdown before calling `AskUserQuestion`. The selector question must be exactly\n`decision.question`; never copy `summary`, `status`, or\n`presentation.markdown` into it. The selector is for a compact choice, not for\ndisplaying an approval artifact.\n\nUse this `AskUserQuestion` input shape for approval selectors:\n\n```json\n{\n  \"questions\": [\n    {\n      \"question\": \"\u003Cdecision.question>\",\n      \"header\": \"Approach\",\n      \"options\": [\n        { \"label\": \"\u003Cdecision.options[0].label>\", \"description\": \"\u003Cdecision.options[0].description>\" }\n      ],\n      \"multiSelect\": false\n    }\n  ]\n}\n```\n\nReplace `header` with the current gate header and include every presented\noption in order.\n\nFall back to a numbered list of explicit choices only when `AskUserQuestion` is\ngenuinely unavailable in the current Claude Code environment. Each action has a\ndeterministic `command` which remains the authority for the transition. Do not infer approval from conversational tone — the user must select an action or type an explicit response.\nDo not use `ExitPlanMode` as a substitute for LeanRigor approval.\n\nFor the post-triage approach gate, render a compact summary before the selector.\n`flow next --json` returns both the decision envelope and the rich `summary`\nfield in a single call. Render `summary` first, then call `AskUserQuestion`\nwith `decisionEnvelope.decision.question` and `.options`:\n\n```text\nWorkflow created and triaged\n\nWorkflow: \u003Cid>\nMode: \u003CFast|Standard|Rigorous>\n\nAssessment\n\u003Ccomplexity, ambiguity, risk, blast radius, and concise explanation where available>\n\nKey constraints\n\u003Cpersisted triage constraints and explicit revision feedback>\n\nRecommended approach\n\u003Cpersisted recommended approach>\n\nNo implementation has started. Your approval is required before planning.\n```\n\nThen call `AskUserQuestion` in the same turn with one concise question and\nthese options in order:\n\n1. `Approve approach and create plan` — Continue to model-assisted planning\n   using the approved triage constraints.\n2. `Add constraints to workflow strategy` — Let me provide changes or additional constraints before\n   planning.\n3. `View workflow details` — Show full triage, policy, provenance, and current\n   workflow state.\n4. `Cancel workflow` — Stop this workflow without starting implementation.\n\nFor the clarification gate (`state: awaiting_clarification`), render the\npersisted question explicitly and verbatim before waiting for the user's answer:\n\n```text\nWorkflow created and triaged\n\nWorkflow: \u003Cid>\nRequest: \u003Crequest>\nProvisional recommendation: \u003CFast|Standard|Rigorous>\nFinal mode: pending clarification\n\nTriage clarification\n\nQuestion: \u003Cnext.summary.question or clarification.question>\n\nWhy this matters: \u003Cnext.summary.reason or clarification.reason>\n```\n\nDo not replace the question with the reason. Do not end with a blank prompt\nafter \"before continuing\". If `AskUserQuestion` is available, ask exactly the\npersisted question there as well; otherwise ask for a free-form answer in plain\nlanguage. The answer must be recorded through `flow answer \u003Cworkflow-id>\n--answer-file \u003Canswer-file> --provider auto`.\n\nClarification is already filtered by LeanRigor core. Do not invent additional\ntriage questions from repository scope or planning uncertainty; those are handled\nby targeted inspection or planning. When `next.summary.modeStatus` is\n`provisional`, do not present the mode as final.\n\n### Free-form fallback\n\nThe following typed responses remain supported as a fallback:\n\n- `approve`, `looks good`, `continue` at `awaiting_approach_approval`: approve approach with `flow approve-approach \u003Cworkflow-id> --provider auto`, adding `--add-constraint`, `--remove-constraint`, or `--override-constraint \"\u003Cold> => \u003Cnew>\"` for any user-supplied constraint changes, then immediately render the generated plan for plan approval. Use deterministic planning only when explicitly requested or when the model provider falls back with a recorded reason.\n- `approve`, `looks good`, `continue` at `awaiting_plan_approval`: approve only the Workflow Plan, then call `flow next --json` and render the persisted Phase Execution Brief approval decision. Do not invoke coordinator or manual execution until the user approves the exact brief revision.\n- `revise ...` at a Phase Execution Brief gate: persist the feedback with\n  `flow phase-brief \u003Cworkflow-id> \u003Cphase-id> --feedback-file\n  \u003Cfeedback-file>`, then render the new brief and its new pending decision.\n  Never reuse approval from the superseded revision.\n- `show status` during execution: render the persisted `recommendedNextPhase`\n  as the primary action. Show `otherDependencyReadyPhases` separately as\n  available only after explicit user choice. Do not replace Phase 2 with Phase\n  4 merely because both are dependency-ready.\n- `revise ...` at `awaiting_approach_approval`: record the feedback with `flow revise-approach \u003Cworkflow-id> --feedback-file \u003Cfeedback-file>`, rerender the updated workflow strategy summary, and ask for approval again. Do not start planning. This action records additional constraints; it does not regenerate the approach.\n- `revise ...` at `awaiting_plan_approval`: use `flow revise-plan \u003Cworkflow-id> --feedback-file \u003Cfeedback-file> --provider auto` unless deterministic planning was explicitly requested.\n- `reject because ...`: reject the approach with the supplied reason.\n- `cancel`: cancel the workflow after confirming intent when destructive to progress.\n- `show plan` \u002F `show status`: render persisted plan\u002Fstatus.\n- `repair it` at `needs_repair`: start the bounded repair requested by the gate.\n- `continue` at `needs_repair`, `needs_review`, or `needs_replan`: do not bypass the gate; explain the required repair, review, or replan.\n\nAsk one concise clarification for ambiguous responses.\n\n## Phase And Review Rules\n\nBefore phase approval, render the persisted Phase Execution Brief from `flow\nnext --json`. Render `presentation.markdown` verbatim in a normal assistant\nmessage before the selector. The response also includes both\n`decisionEnvelope` (question and options for `AskUserQuestion`) and `summary`\n(the rich brief details). Show the\nobjective, concrete deliverable, inspected current behaviour, implementation\napproach, read\u002Fwrite paths, relevant files and symbols, acceptance criteria,\ntest obligations, validation, dependencies, assumptions, exclusions, risks,\nchanges from the approved Workflow Plan, and inspection provenance from\n`summary`. Use the returned decision options in order from\n`decisionEnvelope.decision.options`. Do not summarise the Workflow Plan phase as\nthough it were the detailed brief.\n\nBrief generation is a read-only planning operation. It must not initialize a\nworkspace, dispatch the implementation provider, approve a phase, or expand\nwrite scope. If LeanRigor reports `Phase Execution Brief unavailable`, present\nits persisted retry, plan-boundary revision, diagnostics, and cancel actions.\nDo not invent a placeholder brief or proceed to execution.\n\nThe coordinator is the normal execution path. Invoke `flow execute-next\n--provider auto` or `flow execution-poll --provider auto` only after the exact\nbrief is approved and the refreshed envelope permits it. Use the scripted\nprovider only when explicitly requested. Claude must not implement phase edits\nitself or edit the original working tree. Present only persisted recovery\ndecisions; never silently switch provider or execution mode, and never fall\nback to main-session implementation. Manual execution requires an explicit\npersisted choice and explicit user selection.\n\nNever claim a\nphase is complete from visible file changes alone; only persisted LeanRigor\nstate and gates decide completion. Never compensate for an unavailable workflow\ntransition by narrating that the workflow is complete. Report the persisted\nstate and the exact blocker.\n\nDuring execution, each phase must pass:\n\n`planned -> ready -> leased\u002Frunning -> targeted validation -> completion gate -> completed | needs_repair | needs_review | needs_replan | blocked`\n\nUse `flow phase-result \u003Cworkflow-id> \u003Cphase-id> --json` to render provider\nidentity, changed files, scope checking, validation evidence, completion gate,\nintegration, risks, blockers, and next safe actions. Do not run `cd\n\u003Cphase-worktree> && git diff`, inspect the phase worktree, or request generic\nBash trust in the normal path. Manual inspection is allowed only when the user\nexplicitly requests it or persisted evidence is incomplete and a dedicated\ndecision states the reason.\n\nCoordinator-owned leases are completed by the coordinator only. Do not infer,\nprobe, or reuse a provider lease owner string from status output to run\n`phase-complete` directly. If the coordinator cannot collect a provider result,\npresent the recorded provider failure and the allowed recovery choices.\n\nAfter a phase gate passes, integrate the approved phase into the LeanRigor\nintegration worktree. After all required phases are integrated, run combined\nvalidation in the integration worktree before final integrated review. On\n`integration_conflict`, present the conflict-repair gate and do not resolve with\nours\u002Ftheirs.\n\nAfter Phase N is accepted and integrated, refresh. For phase-by-phase\nworkflows, render the freshly persisted Phase N+1 brief decision and its exact\noptions; never show a generic `Continue`. For workflow-authorized Standard\nflows, show a concise preflight status and continue only while the envelope\nmarks the next operation automatically permitted.\n\nIf a transition returns `revision_conflict`, reread workflow state and present\nthe changed situation. Never retry a rejected transition blindly. Raw lease and\nlock commands are troubleshooting details, not normal user-facing output.\n\nFinal integrated review remains required after all phase gates pass and the\ncurrent integration head has passing combined validation.\n\n## Presentation\n\nRender human summaries first. `flow next --json` returns both `decisionEnvelope`\nand the rich `summary` field, plus a deterministic `presentation.markdown`\nartifact for every workflow state. Always render that artifact as normal\nassistant Markdown before a decision selector. Never put that artifact inside\n`AskUserQuestion`: the selector receives only `decision.question` and its\noptions.\n\nRender at minimum:\n\n- workflow ID, request, mode, state;\n- current phase and completion-gate status;\n- criteria and validation progress;\n- repair attempts, blockers, and next action;\n- concise phase list or commit groups when relevant.\n\nAvoid raw JSON, repeated methodology, full state-machine dumps, and shell\ncommands in normal output.\n\n## Troubleshooting\n\nIf a LeanRigor command fails, show:\n\n```text\nI could not run the LeanRigor transition automatically.\n\nYou can retry, or run:\n\u003Cexact command>\n\nError:\n\u003Cconcise error>\n```\n\nRaw commands belong only in this troubleshooting fallback, manual\u002Fadvanced\ndocumentation, or when the user explicitly asks for them.\n",{"name":5,"description":7,"allowed-tools":24},"AskUserQuestion, Bash(${CLAUDE_PLUGIN_ROOT}\u002Fbin\u002Fleanrigor *)","main","5fa7ff26606a40a23dac5de9dccd40d4aaf97be2","plugin-skills\u002Fsequential-workflow",0,"https:\u002F\u002Fgithub.com\u002Fsumanshusamarora\u002FLeanRigor","https:\u002F\u002Fgithub.com\u002Fsumanshusamarora","https:\u002F\u002Fdataeverything.ai","Dynamic and results-driven data science leader with over 13 years of experience in the data industry. Proven\r\nexpertise in solving complex business problems.","2026-08-02 14:01:17",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add sumanshusamarora\u002FLeanRigor --skill leanrigor-sequential-workflow",{"tool":40,"command":41},"bunx","bunx skills add sumanshusamarora\u002FLeanRigor --skill leanrigor-sequential-workflow",{"tool":43,"command":44},"pnpm","pnpm dlx skills add sumanshusamarora\u002FLeanRigor --skill leanrigor-sequential-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsumanshusamarora\u002FLeanRigor\u002Fblob\u002Fmain\u002Fplugin-skills\u002Fsequential-workflow\u002FSKILL.md",true,[],[49,55,61,67,73,79],{"skillNo":50,"name":51,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":52,"categories":53,"keywords":54,"publishedAt":19},"01M79HTS70GTT4531TK5QAM197","validate-integration","https:\u002F\u002Fgithub.com\u002Fsumanshusamarora\u002FLeanRigor\u002Fblob\u002Fmain\u002Finternal-skills\u002Fvalidate-integration\u002FSKILL.md",[],[],{"skillNo":56,"name":57,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":19},"01M79HTQ3S1A1QBVM4CV401XSA","triage-task","https:\u002F\u002Fgithub.com\u002Fsumanshusamarora\u002FLeanRigor\u002Fblob\u002Fmain\u002Finternal-skills\u002Ftriage-task\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M79HTNZY87XQGXG8XQS0PXZ2","prepare-commits","https:\u002F\u002Fgithub.com\u002Fsumanshusamarora\u002FLeanRigor\u002Fblob\u002Fmain\u002Finternal-skills\u002Fprepare-commits\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":19},"01M79HTKTRHHE9RTJMEHBCWX55","inspect-repository","https:\u002F\u002Fgithub.com\u002Fsumanshusamarora\u002FLeanRigor\u002Fblob\u002Fmain\u002Finternal-skills\u002Finspect-repository\u002FSKILL.md",[],[],{"skillNo":74,"name":75,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":19},"01M79HTHZ620511YVKCJ594RWF","evaluate-options","https:\u002F\u002Fgithub.com\u002Fsumanshusamarora\u002FLeanRigor\u002Fblob\u002Fmain\u002Finternal-skills\u002Fevaluate-options\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":19},"01M79HTFMS0PB4ZJSP5CPH2B0Y","dispatch-execution","https:\u002F\u002Fgithub.com\u002Fsumanshusamarora\u002FLeanRigor\u002Fblob\u002Fmain\u002Finternal-skills\u002Fdispatch-execution\u002FSKILL.md",[],[]]