diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
new file mode 100644
index 0000000..b8ce3ae
--- /dev/null
+++ b/.github/copilot-instructions.md
@@ -0,0 +1,7 @@
+# Repository instructions
+
+Follow `AGENTS.md` as the repository-wide engineering contract.
+
+Keep fstack portable, dependency-light, and simple. Preserve the distinction between interactive skills and the continuous `fstack-run` cloud workflow. Inspect source truth before editing, make the smallest complete change, run `sh scripts/validate.sh`, inspect the final diff, and deliver changes on a task branch through a pull request.
+
+Never overwrite unrelated work, commit secrets, force-push, or claim unobserved test results.
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
new file mode 100644
index 0000000..95b4158
--- /dev/null
+++ b/.github/pull_request_template.md
@@ -0,0 +1,28 @@
+## What changed
+
+<!-- State the user-visible or agent-visible outcome. -->
+
+## Why this is the smallest complete change
+
+<!-- Name deliberate exclusions and avoided complexity. -->
+
+## Evidence
+
+```text
+Commands run:
+
+Observed results:
+```
+
+## Skill and documentation checks
+
+- [ ] `sh -n scripts/validate.sh`
+- [ ] `sh scripts/validate.sh`
+- [ ] `git diff --check` against the base branch
+- [ ] New or changed skills are documented in `README.md`
+- [ ] Frontmatter name matches the skill directory
+- [ ] No secrets, credentials, private local paths, or generated files were added
+
+## Missing evidence or remaining risk
+
+<!-- Write "None" only when every applicable check was observed. -->
diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml
new file mode 100644
index 0000000..87303aa
--- /dev/null
+++ b/.github/workflows/validate.yml
@@ -0,0 +1,37 @@
+name: Validate skills
+
+on:
+  push:
+    branches:
+      - main
+      - 'feat/**'
+      - 'fix/**'
+  pull_request:
+
+permissions:
+  contents: read
+
+concurrency:
+  group: validate-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  validate:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out repository
+        uses: actions/checkout@v6
+        with:
+          fetch-depth: 0
+
+      - name: Check validator syntax
+        run: sh -n scripts/validate.sh
+
+      - name: Validate skill collection
+        run: sh scripts/validate.sh
+
+      - name: Check changed text for whitespace errors
+        shell: sh
+        run: |
+          base=${GITHUB_BASE_REF:-main}
+          git diff --check "origin/$base...HEAD"
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000..2b16615
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,91 @@
+# fstack repository agent contract
+
+## Purpose
+
+fstack is a portable collection of Agent Skills. Keep it small, readable, agent-agnostic, and safe to install in other repositories.
+
+The interactive skills intentionally stop at human decision points. `fstack-run` is the continuous cloud-agent path. Do not remove either mode or silently make one behave like the other.
+
+## Source of truth
+
+Before changing the repository:
+
+1. Confirm the repository root, current branch, HEAD, and working-tree state.
+2. Read this file, `README.md`, and every skill or document affected by the task.
+3. Inspect recent history when the task changes established behavior.
+4. Treat repository files and command output as authoritative. Do not substitute conversation memory for current state.
+5. Preserve unrelated or pre-existing changes. Never reset, clean, overwrite, or force-push them away.
+
+## Change rules
+
+- Make the smallest complete change that satisfies the request.
+- Keep one job per skill.
+- Keep `SKILL.md` concise. The hard limit is 500 lines; prefer roughly 150 or fewer.
+- Keep skill names lowercase and hyphenated. The frontmatter `name` must match the containing directory.
+- Put activation conditions in the frontmatter `description` so agents can discover the skill correctly.
+- Prefer plain Markdown. Add scripts, references, or assets only when they improve repeatability or correctness.
+- Do not hardcode one vendor's tool names into a generally portable skill unless the skill is explicitly vendor-specific.
+- Do not add dependencies or generated files for validation that POSIX shell can handle.
+- Update `README.md` whenever a skill is added, renamed, removed, or materially changes behavior.
+
+## Continuous cloud-agent behavior
+
+When a user asks for autonomous, end-to-end, unattended, cloud-agent, or "finish it" execution, use `fstack-run`.
+
+Proceed without routine approval stops. Ask only when the missing answer changes the safe action and cannot be resolved from repository evidence. Ordinary implementation choices should use the smallest reversible option consistent with existing conventions.
+
+A cloud run is not complete after planning, editing, one passing test, or opening a pull request. It is complete only after implementation, verification, final diff review, and a durable delivery artifact exist, or after a concrete external blocker is proven.
+
+## Verification
+
+Run all applicable checks. For this repository, the minimum gate is:
+
+```sh
+sh -n scripts/validate.sh
+sh scripts/validate.sh
+git diff --check
+```
+
+Then inspect the final diff and confirm:
+
+- every changed file belongs to the task;
+- all skill frontmatter is valid and discoverable;
+- the README and routing tables match the skills on disk;
+- no secret, credential, local path, or generated artifact was added;
+- no interactive behavior was accidentally converted into autonomous behavior, or vice versa.
+
+Never claim a command passed unless its output was observed.
+
+## Git and delivery
+
+- Work on a task branch, not directly on `main`.
+- Commit only task-owned files.
+- Do not skip hooks, force-push, or amend published commits.
+- Push the task branch and open a pull request when the environment supports it.
+- Do not merge or deploy unless the user explicitly requests it and repository policy permits it.
+
+## Completion receipt
+
+End substantial work with:
+
+```text
+PROVEN
+- implemented files and behavior
+- commands run and observed results
+- branch, commit, and pull request
+
+MISSING EVIDENCE
+- checks that could not be run and the exact reason
+
+POSSIBLY WRONG OR OVERSTATED
+- remaining assumptions, or none
+
+EXACT NEXT ACTION
+- the one smallest action needed next, or none
+
+WHAT DOES NOT COUNT AS COMPLETION
+- planning, unverified edits, or a PR with failing/unknown checks
+
+CONTEXT
+- safe to continue here, or why a fresh context is required
+```
diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 100644
index 0000000..aacc882
--- /dev/null
+++ b/CLAUDE.md
@@ -0,0 +1,7 @@
+# Claude Code instructions
+
+Read and follow `AGENTS.md` before planning or editing.
+
+Use the repository files and observed command output as source truth. Preserve unrelated changes. For autonomous or end-to-end work, use the `fstack-run` workflow and continue through implementation, verification, final review, commit, push, and pull request unless a concrete blocker prevents it.
+
+Do not treat planning, unverified edits, or opening a pull request as completion.
diff --git a/README.md b/README.md
index 1281515..3969e9b 100644
--- a/README.md
+++ b/README.md
@@ -4,106 +4,153 @@ Agent skills that ask: can this be less?
 
 ## The problem
 
-Skill collections keep growing. 30 skills, personas, pipelines, voice triggers. You can't hold that in your head, so you stop using it.
+Skill collections keep growing. Personas, pipelines, ceremonies, and overlapping commands become harder to remember than the work itself.
 
-And the complexity doesn't stay in the workflow. A process built to sound smart — phases, personas, ceremony — produces code that sounds smart too: layers, abstractions, and options nobody asked for.
+That complexity leaks into the code. A process built to sound smart often produces layers, abstractions, and options nobody asked for.
 
 ## The idea
 
-fstack is 13 skills. Plain names, one job each.
+fstack is 14 small skills with plain names and one job each.
 
-The agent works in small steps and checks in with you. You approve; it executes. No long autonomous runs.
+It has two deliberate modes:
 
-One skill — `/fstack-simplify` — exists only to remove things. No other stack has that.
+- **Interactive mode:** you drive each stage and approve real choices.
+- **Cloud mode:** `/fstack-run` continues from source-truth inspection through implementation, tests, review, fixes, commit, push, and pull request.
+
+One skill — `/fstack-simplify` — exists only to remove things.
 
 ## Install
 
-```bash
-npx skills@latest add flaviocopes/fstack
+With GitHub CLI 2.90 or later, preview and install the continuous runner for GitHub Copilot or another supported agent host:
+
+```sh
+gh skill preview naytewilson/fstack fstack-run
+gh skill install naytewilson/fstack fstack-run
+```
+
+With the cross-agent `skills` CLI, review the collection and install only the runner globally:
+
+```sh
+npx skills@latest add naytewilson/fstack --list
+npx skills@latest add naytewilson/fstack --skill fstack-run -g -y
+```
+
+Install the complete collection interactively:
+
+```sh
+npx skills@latest add naytewilson/fstack
 ```
 
-That's it. No dependencies, no build step, no config.
+The skills themselves have no runtime dependencies or build step.
 
-## The core loop
+See [Cloud-agent setup](docs/CLOUD_AGENTS.md) for agent-specific installation, permissions, invocation prompts, safety defaults, validation, updates, and maintenance.
+
+## Cloud mode
+
+Use `/fstack-run` when the agent should finish a repository task without routine approval stops.
+
+```mermaid
+flowchart LR
+    Inspect["Inspect source truth"] --> Isolate["Protect existing work"]
+    Isolate --> Plan["Plan briefly"]
+    Plan --> Build["Implement"]
+    Build --> Test["Test and validate"]
+    Test --> Review["Review and simplify"]
+    Review -->|Fix needed| Build
+    Review -->|Ready| Deliver["Commit, push, pull request"]
+    Deliver --> Verify["Verify checks and receipt"]
+```
+
+The runner stops only for a proven external blocker, a decision that changes the safe action, an explicit user stop, or a completed verified delivery.
+
+## Interactive mode
+
+Use the original loop when you want to control each transition:
 
 ```mermaid
 flowchart TD
-    Start{"Human: task clear?"}
+    Start{"Task clear?"}
     Start -->|No| N["fstack-nail"]
-    N --> Task["Human approves the task"]
+    N --> Task["Human approves task"]
     Task --> P["fstack-plan"]
     Start -->|Yes| P
-    P --> Plan["Human approves the plan"]
+    P --> Plan["Human approves plan"]
     Plan --> B["fstack-build"]
     B --> C["fstack-check"]
-    C -->|Ready to push| Push["fstack-push"]
-    C -->|Not ready| Earlier["Human picks the right earlier step"]
+    C -->|Ready| Push["fstack-push"]
+    C -->|Not ready| Earlier["Human chooses an earlier step"]
     Earlier -.-> N
     Earlier -.-> P
     Earlier -.-> B
 ```
 
-Invoke a skill directly, or ask `/fstack` to choose one. Nothing continues automatically.
-
-Before the loop:
-
-- `/fstack-roast` — when you have a product idea and want honest pushback before writing code
-- `/fstack-interview` — when the agent should know the business behind the project; it asks, you answer, the answers land in AGENTS.md
-
-Sprinkle in anywhere:
+Invoke a skill directly, or ask `/fstack` to choose one.
 
-- `/fstack-simplify` — when something feels bloated, from one file to the whole codebase
-- `/fstack-design` — when UI looks off or inconsistent with the rest
-- `/fstack-document` — when the project needs docs, or the docs have gone stale
-- `/fstack-learn` — when something is worth remembering
-- `/fstack-counselors` — when a decision is big enough to want three independent model opinions
-
-Don't know where to start? `/fstack` is the front door.
-
-```mermaid
-flowchart LR
-    Map["Where each skill fits"]
-    Map --> Front["Front door<br/>fstack"]
-    Map --> Before["Before building<br/>fstack-roast<br/>fstack-interview"]
-    Map --> Core["Core loop<br/>fstack-nail<br/>(when unclear)<br/>fstack-plan<br/>fstack-build<br/>fstack-check<br/>fstack-push"]
-    Map --> Needed["Use when needed<br/>fstack-simplify<br/>fstack-design<br/>fstack-document<br/>fstack-counselors"]
-    Map --> After["After useful work<br/>fstack-learn"]
-```
-
-## The 13 skills
+## The 14 skills
 
 | Skill | What it does |
 |---|---|
-| `/fstack` | The front door. Picks the right skill for your request. |
-| `/fstack-roast` | Stress-tests a product idea. Ends with a verdict and the smallest version worth building. |
-| `/fstack-interview` | Interviews you about the product — demand, customer, pricing, risks — and records the answers in AGENTS.md. |
-| `/fstack-counselors` | Asks the 3 most capable models the same question, independently, and synthesizes one verdict plus each opinion. |
-| `/fstack-nail` | Clarifies a vague task, nails down a 3-line summary, and gets your yes before planning. |
+| `/fstack` | Front door. Lists the stack or routes a task to one skill. |
+| `/fstack-run` | Completes repository work continuously from inspection through verified pull request. |
+| `/fstack-roast` | Stress-tests a product idea and finds the smallest version worth building. |
+| `/fstack-interview` | Records product, customer, demand, pricing, distribution, and risk context in the repository. |
+| `/fstack-counselors` | Gets three independent model opinions and synthesizes one verdict. |
+| `/fstack-nail` | Clarifies a vague task and gets approval on a three-line summary. |
 | `/fstack-plan` | Writes a one-page plan with a mandatory "what we're NOT doing" section. |
-| `/fstack-build` | Implements the plan one small step at a time, asking at real choices. |
-| `/fstack-simplify` | Audits for unnecessary complexity and proposes deletions — one file or the whole codebase. Only deletions. |
-| `/fstack-design` | Makes UI adhere to the project's existing styles and cleans up design slop. |
-| `/fstack-document` | Writes docs/ for the project, ELI5 to deep. Run again to update them with changes. |
-| `/fstack-check` | Three questions: does it work, does it match the plan, is it simple. |
-| `/fstack-learn` | Captures one lesson in three lines, so future sessions start smarter. |
-| `/fstack-push` | Commits the current task's changes and pushes to the remote. Nothing else — no tests, no deploy. |
+| `/fstack-build` | Implements an approved plan in small verified steps. |
+| `/fstack-simplify` | Audits unnecessary complexity and proposes deletions only. |
+| `/fstack-design` | Makes UI follow the project's existing visual system. |
+| `/fstack-document` | Writes or updates project documentation from ELI5 to deep. |
+| `/fstack-check` | Reviews whether work functions, matches the plan, and stays simple. |
+| `/fstack-learn` | Captures one non-obvious lesson in three lines. |
+| `/fstack-push` | Commits task-owned changes and pushes them. It intentionally does not test or deploy. |
+
+## Repository support for cloud agents
+
+This fork includes:
+
+- `AGENTS.md` — canonical repository-wide agent contract;
+- `CLAUDE.md` — Claude Code entrypoint;
+- `.github/copilot-instructions.md` — GitHub Copilot coding-agent entrypoint;
+- `.github/workflows/validate.yml` — automatic skill validation;
+- `.github/pull_request_template.md` — evidence-focused delivery checklist;
+- `scripts/validate.sh` — dependency-free frontmatter, naming, size, duplication, and README checks;
+- `docs/CLOUD_AGENTS.md` — complete operator guide.
+
+Validate locally with:
+
+```sh
+sh -n scripts/validate.sh
+sh scripts/validate.sh
+git diff --check
+```
+
+With GitHub CLI 2.90 or later, run the current Agent Skills publishing checks without publishing:
+
+```sh
+gh skill publish --dry-run
+```
 
 ## Philosophy
 
 1. Short sentences. One idea per sentence.
 2. Short paragraphs, then a blank line.
-3. No jargon. If a plumber wouldn't understand the word, find a simpler one.
-4. No personas. Skills describe steps, not characters.
+3. Plain language before jargon.
+4. No personas. Skills describe actions, not characters.
 5. One job per skill.
-6. Prefer deletion. When something can be shorter, make it shorter.
-7. Every skill fits in ~150 lines. If it doesn't, it's doing too much.
-8. The human drives. Skills pause at decision points and ask.
-9. Agent-agnostic. Plain markdown, no hardcoded tool names.
-10. Plain-English tone. Like explaining to a friend.
+6. Prefer deletion and the smallest complete change.
+7. Keep each skill compact; move real detail into referenced files only when needed.
+8. Interactive skills stop at decision points. The cloud runner continues through ordinary choices.
+9. Stay agent-agnostic and use the open `SKILL.md` format.
+10. Evidence beats confidence. Unrun tests are missing evidence, not a pass.
+11. Preserve unrelated work. Never make destructive Git behavior an automation default.
+12. A cloud run is done only after implementation, verification, review, and durable delivery.
 
 ## Credits
 
-fstack exists because of the stacks it distills. [gstack](https://github.com/garrytan/gstack) by Garry Tan gave it the full lifecycle idea and, through office hours, the idea-roasting step. [pstack](https://cursor.com/marketplace/cursor/pstack) by Lauren Tan gave it design-before-code and blast-radius thinking. [Compound Engineering](https://github.com/EveryInc/compound-engineering-plugin) by Every gave it the plan artifact and the lesson-capture step. [Matt Pocock's skills](https://github.com/mattpocock/skills) gave it grilling, the two-axis review, and the small-skills shape. [counselors](https://github.com/aarondfrancis/fstack-counselors) by Aaron Francis gave it the council-of-advisors pattern behind `/fstack-counselors`. Go look at all of them — they're generous, thoughtful work.
+fstack exists because of the stacks it distills. [gstack](https://github.com/garrytan/gstack) by Garry Tan gave it the full lifecycle idea and idea-roasting step. [pstack](https://cursor.com/marketplace/cursor/pstack) by Lauren Tan gave it design-before-code and blast-radius thinking. [Compound Engineering](https://github.com/EveryInc/compound-engineering-plugin) by Every gave it the plan artifact and lesson-capture step. [Matt Pocock's skills](https://github.com/mattpocock/skills) gave it grilling, two-axis review, and the small-skills shape. [counselors](https://github.com/aarondfrancis/fstack-counselors) by Aaron Francis gave it the independent-advisor pattern behind `/fstack-counselors`.
+
+The original fstack was created by [Flavio Copes](https://github.com/flaviocopes/fstack). This fork keeps the interactive stack and adds the continuous cloud-agent operating mode.
 
 ## License
 
diff --git a/docs/CLOUD_AGENTS.md b/docs/CLOUD_AGENTS.md
new file mode 100644
index 0000000..3af1d9e
--- /dev/null
+++ b/docs/CLOUD_AGENTS.md
@@ -0,0 +1,216 @@
+# Cloud-agent setup
+
+`fstack-run` is the end-to-end mode for remote coding agents. It preserves fstack's small-change discipline while removing routine approval pauses between inspection, planning, implementation, testing, review, and delivery.
+
+The original skills remain interactive. Use them when you want to drive each stage manually.
+
+## 1. Review before installing
+
+Agent skills are executable instructions. Inspect this repository and the selected `SKILL.md` before giving an agent write access to an important repository.
+
+With GitHub CLI 2.90 or later, preview the continuous runner without installing it:
+
+```sh
+gh skill preview naytewilson/fstack fstack-run
+```
+
+For clients using the cross-agent `skills` CLI, list the collection without installing it:
+
+```sh
+npx skills@latest add naytewilson/fstack --list
+```
+
+## 2. Install with GitHub CLI
+
+`gh skill` is GitHub's preview interface for Copilot cloud agent and supported agent hosts. A project install is the safest default because the reviewed skill version travels with one repository.
+
+Install `fstack-run` for GitHub Copilot at project scope:
+
+```sh
+gh skill install naytewilson/fstack fstack-run
+```
+
+Install it for a named host and user scope:
+
+```sh
+gh skill install naytewilson/fstack fstack-run --agent claude-code --scope user
+```
+
+Pin an audited tag or commit for a stricter environment:
+
+```sh
+gh skill install naytewilson/fstack fstack-run --pin <reviewed-tag-or-sha>
+```
+
+The installer writes the skill into the correct host-specific location. GitHub Copilot project skills live under `.github/skills`, `.claude/skills`, or `.agents/skills`; personal skills live under `~/.copilot/skills` or `~/.agents/skills`.
+
+## 3. Install with the cross-agent CLI
+
+Use this route for Codex, Claude Code, OpenCode, and other clients supported by the `skills` CLI.
+
+Install only the continuous runner into the current project:
+
+```sh
+npx skills@latest add naytewilson/fstack --skill fstack-run -y
+```
+
+Install it globally for supported agents detected on the machine:
+
+```sh
+npx skills@latest add naytewilson/fstack --skill fstack-run -g -y
+```
+
+Install it globally for named clients:
+
+```sh
+npx skills@latest add naytewilson/fstack --skill fstack-run -g -a codex -a claude-code -a opencode -y
+```
+
+Install the complete interactive and continuous collection:
+
+```sh
+npx skills@latest add naytewilson/fstack --all
+```
+
+Project installation is better when a team should share the same version. Global installation is better for a personal default across repositories.
+
+## 4. Give the cloud agent the right repository access
+
+A full run needs:
+
+- repository read access;
+- permission to create and push a task branch;
+- permission to open or update a pull request;
+- permission to read CI results;
+- the repository's normal build and test environment.
+
+It does not need permission to force-push, merge, deploy, edit repository settings, or read production secrets for ordinary coding tasks. Keep those permissions disabled unless a specific task requires them.
+
+## 5. Start a run
+
+A compact task is enough:
+
+```text
+Use /fstack-run. Fix the reported issue end to end. Inspect source truth first, preserve unrelated work, implement the smallest complete change, run the applicable checks, fix review findings, and deliver a task branch plus pull request. Stop only for a proven external blocker or a decision that changes the safe action.
+```
+
+Include acceptance criteria, issue links, screenshots, or failing commands when they exist. Do not restate repository facts that the agent can inspect.
+
+## 6. Expected lifecycle
+
+A compliant cloud run performs this loop:
+
+```text
+inspect -> isolate -> plan briefly -> implement -> test -> review -> fix -> retest -> commit -> push -> pull request -> verify checks
+```
+
+The agent may repeat implementation, testing, and review. It should not stop merely because one phase completed.
+
+## 7. Repository instruction files
+
+This repository includes:
+
+- `AGENTS.md` as the canonical cross-agent contract;
+- `CLAUDE.md` as a Claude Code entrypoint;
+- `.github/copilot-instructions.md` as a GitHub Copilot coding-agent entrypoint;
+- `skills/fstack-run/SKILL.md` as the portable continuous workflow.
+
+When installing fstack into another repository, that repository's own instructions remain authoritative. The skill must adapt to them rather than overwrite them.
+
+## 8. Verification and delivery
+
+A successful run must provide observed evidence for:
+
+- the requested behavior;
+- targeted tests or checks;
+- a reasonable broader regression check;
+- final diff review;
+- branch and commit identity;
+- pull-request identity and check status.
+
+Unavailable checks belong under `MISSING EVIDENCE`. They are not silently converted into a pass.
+
+By default, `fstack-run` stops after a verified pull request. Merging and deployment require an explicit request and repository permission.
+
+For this skills repository, run:
+
+```sh
+sh -n scripts/validate.sh
+sh scripts/validate.sh
+git diff --check
+```
+
+With GitHub CLI 2.90 or later, also validate against GitHub's current Agent Skills publishing checks:
+
+```sh
+gh skill publish --dry-run
+```
+
+The publish dry run validates the skills and reports relevant repository security settings without creating a release.
+
+## 9. Safe automation defaults
+
+Use these defaults for unattended cloud execution:
+
+- task branch, never direct-to-`main`;
+- no force-push;
+- no destructive cleanup or reset;
+- no broad `git add .` in a dirty repository;
+- no secret files, credentials, or private local paths in commits;
+- no dependency addition when the existing toolchain can solve the task;
+- no merge or deployment merely because tests passed;
+- no claim of success without observed output.
+
+Do not add `allowed-tools: shell` or `allowed-tools: bash` merely to suppress prompts. Pre-approve terminal execution only after auditing the full skill and every referenced script.
+
+## 10. Repository settings worth enabling
+
+For repositories where cloud agents routinely open pull requests, enable:
+
+- required status checks for the real test and lint workflows;
+- branch protection or rulesets for `main`;
+- blocked force-pushes and deletions;
+- pull requests before merge;
+- automatic branch deletion after merge, when appropriate;
+- least-privilege tokens or GitHub App permissions;
+- secret scanning and code scanning where the repository plan supports them.
+
+These are host-level controls. Installing a skill does not configure them automatically.
+
+## 11. Update and audit
+
+Review upstream changes before updating a trusted automation environment.
+
+For installations managed by GitHub CLI:
+
+```sh
+gh skill update
+gh skill update --all
+```
+
+For installations managed by the cross-agent CLI:
+
+```sh
+npx skills list
+npx skills update
+```
+
+Pinned GitHub CLI installations are skipped by normal updates. Reinstall them with a newly reviewed pin when you deliberately upgrade.
+
+## 12. Troubleshooting
+
+### The agent stops after planning
+
+Confirm that `fstack-run` was selected rather than `fstack-plan` or the interactive `/fstack` route.
+
+### The agent edits directly on `main`
+
+The repository or cloud platform did not enforce task-branch behavior. Stop the run, preserve the diff, create a branch, and continue there. Add a host-level branch rule so this cannot recur.
+
+### The agent opens a pull request without tests
+
+The run is incomplete. Resume it with the missing verification requirement and require observed output before final review.
+
+### The client cannot find the skill
+
+Preview or list the repository, verify the selected agent and installation scope, and confirm that the installed folder contains `fstack-run/SKILL.md` with intact YAML frontmatter.
diff --git a/scripts/validate.sh b/scripts/validate.sh
new file mode 100644
index 0000000..bcccc11
--- /dev/null
+++ b/scripts/validate.sh
@@ -0,0 +1,97 @@
+#!/bin/sh
+
+set -eu
+
+root=$(CDPATH= cd -- "$(dirname "$0")/.." && pwd)
+names_file="${TMPDIR:-/tmp}/fstack-skill-names.$$"
+trap 'rm -f "$names_file"' EXIT HUP INT TERM
+: > "$names_file"
+
+failures=0
+count=0
+files=$(find "$root/skills" -type f -name SKILL.md -print | LC_ALL=C sort)
+
+if [ -z "$files" ]; then
+  printf '%s\n' 'ERROR: no skills/*/SKILL.md files found.' >&2
+  exit 1
+fi
+
+for file in $files; do
+  count=$((count + 1))
+  relative=${file#"$root/"}
+  directory=$(basename "$(dirname "$file")")
+  first_line=$(sed -n '1p' "$file")
+  closing_line=$(awk 'NR > 1 && $0 == "---" { print NR; exit }' "$file")
+  name=$(awk '
+    NR == 1 { next }
+    $0 == "---" { exit }
+    /^name:[[:space:]]*/ {
+      sub(/^name:[[:space:]]*/, "")
+      print
+      exit
+    }
+  ' "$file")
+  description=$(awk '
+    NR == 1 { next }
+    $0 == "---" { exit }
+    /^description:[[:space:]]*/ {
+      sub(/^description:[[:space:]]*/, "")
+      print
+      exit
+    }
+  ' "$file")
+  lines=$(wc -l < "$file" | tr -d ' ')
+
+  if [ "$first_line" != '---' ] || [ -z "$closing_line" ]; then
+    printf 'ERROR: %s must start with a closed YAML frontmatter block.\n' "$relative" >&2
+    failures=$((failures + 1))
+  fi
+
+  if [ -z "$name" ]; then
+    printf 'ERROR: %s is missing frontmatter name.\n' "$relative" >&2
+    failures=$((failures + 1))
+  elif ! printf '%s\n' "$name" | grep -Eq '^[a-z0-9]+(-[a-z0-9]+)*$'; then
+    printf 'ERROR: %s has invalid skill name: %s\n' "$relative" "$name" >&2
+    failures=$((failures + 1))
+  elif [ "$name" != "$directory" ]; then
+    printf 'ERROR: %s declares name %s but directory is %s.\n' "$relative" "$name" "$directory" >&2
+    failures=$((failures + 1))
+  fi
+
+  if [ -z "$description" ]; then
+    printf 'ERROR: %s is missing frontmatter description.\n' "$relative" >&2
+    failures=$((failures + 1))
+  else
+    description_bytes=$(LC_ALL=C printf '%s' "$description" | wc -c | tr -d ' ')
+    if [ "$description_bytes" -gt 1024 ]; then
+      printf 'ERROR: %s description exceeds 1024 bytes.\n' "$relative" >&2
+      failures=$((failures + 1))
+    fi
+  fi
+
+  if [ "$lines" -gt 500 ]; then
+    printf 'ERROR: %s has %s lines; SKILL.md must stay at or below 500.\n' "$relative" "$lines" >&2
+    failures=$((failures + 1))
+  fi
+
+  if [ -n "$name" ]; then
+    if grep -Fxq "$name" "$names_file"; then
+      printf 'ERROR: duplicate skill name: %s\n' "$name" >&2
+      failures=$((failures + 1))
+    else
+      printf '%s\n' "$name" >> "$names_file"
+    fi
+
+    if ! grep -Fq "\`/$name\`" "$root/README.md"; then
+      printf 'ERROR: README.md does not document /%s.\n' "$name" >&2
+      failures=$((failures + 1))
+    fi
+  fi
+done
+
+if [ "$failures" -ne 0 ]; then
+  printf 'Validation failed: %s problem(s) across %s skill(s).\n' "$failures" "$count" >&2
+  exit 1
+fi
+
+printf 'Validated %s skills.\n' "$count"
diff --git a/skills/fstack-run/SKILL.md b/skills/fstack-run/SKILL.md
new file mode 100644
index 0000000..01b00c3
--- /dev/null
+++ b/skills/fstack-run/SKILL.md
@@ -0,0 +1,119 @@
+---
+name: fstack-run
+description: Take a repository task from source-truth inspection through implementation, verification, review, commit, push, and pull request in one continuous run. Use for cloud agents, autonomous execution, unattended coding, end-to-end fixes, or requests to keep working until a proven result exists.
+---
+
+# /fstack-run
+
+Complete one repository task end to end. Keep fstack's preference for small, simple changes, but do not inherit the interactive skills' routine approval stops.
+
+## Execution contract
+
+Continue until one of these outcomes exists:
+
+1. the requested result is implemented, verified, reviewed, and delivered on a task branch;
+2. a concrete external blocker is proven with preserved work and an exact unblocking action; or
+3. the user explicitly stops the run.
+
+Planning, editing, one passing check, a commit, or an open pull request is not completion by itself.
+
+## Steps
+
+### 1. Establish source truth
+
+- Confirm the repository root, current branch, HEAD, dirty state, remotes, and other worktrees when available.
+- Read repository instructions from broadest to most specific scope.
+- Read the relevant implementation, tests, manifests, CI, and recent history.
+- Separate observed facts from assumptions. Never invent repository state, paths, commands, or results.
+
+### 2. Protect existing work
+
+- Preserve unrelated changes exactly as found.
+- Use a task branch or isolated worktree when supported.
+- Never reset, clean, overwrite, force-push, or broadly stage a dirty tree.
+- If isolation is unavailable, touch only task-owned files and report the constraint.
+
+### 3. Resolve the task
+
+Infer ordinary implementation details from repository conventions and choose the smallest reversible option.
+
+Ask only when the missing answer changes the safe action and cannot be resolved from evidence. Valid stops include:
+
+- a real risk of irreversible data or code loss;
+- credentials, permissions, billing, or private data the agent cannot obtain safely;
+- a merge conflict whose correct resolution changes product behavior;
+- mutually exclusive public behavior with no repository-defined default.
+
+Do not stop for routine naming, library, formatting, or implementation choices when the repository already supplies a reasonable convention.
+
+### 4. Plan briefly
+
+Keep a short outcome-based plan with one active step. Write `PLAN.md` only when the repository already uses it or the task needs a durable handoff.
+
+State what is deliberately out of scope. Do not turn the plan into ceremony or wait for approval unless the user requested an approval gate.
+
+### 5. Implement and observe
+
+- Make the smallest complete change.
+- Avoid unrelated refactors and speculative abstractions.
+- Verify each meaningful step with the closest available behavior check.
+- Interpret every command result before continuing.
+- Recover from ordinary failures by changing a relevant condition; do not repeat the same failed action blindly.
+- Keep the user updated during long runs without stopping execution.
+
+### 6. Run the completion gate
+
+Run the repository's documented test, lint, build, format, and validation commands that apply to the change.
+
+At minimum:
+
+- run a targeted behavior check;
+- run a reasonable broader regression check;
+- inspect the final diff and repository state;
+- check for secrets, credentials, generated files, accidental scope expansion, and stale documentation;
+- map every explicit requirement to observed evidence.
+
+If no automated test surface exists, perform the strongest available static and behavioral checks and label the missing evidence. Never replace an unavailable test with confidence language.
+
+### 7. Review and fix
+
+Review the complete diff against the request, repository conventions, and the "can this be less?" rule.
+
+Fix correctness, scope, validation, documentation, and unnecessary-complexity findings that are within the task. Rerun affected checks after every fix. Do not merely report fixable findings and stop.
+
+### 8. Deliver durably
+
+- Stage only task-owned files.
+- Commit with a plain message describing the outcome.
+- Push the current task branch without force.
+- Open or update a pull request when supported.
+- Do not merge, release, or deploy unless the user explicitly requested it and repository policy allows it.
+- Confirm final branch, commit, diff, and check status after delivery.
+
+Do not delegate final delivery to a push-only routine that skips verification.
+
+## Final receipt
+
+Report:
+
+```text
+PROVEN
+- files and behavior implemented
+- exact checks run and observed results
+- branch, commit, and pull request
+
+MISSING EVIDENCE
+- unavailable checks and exact reasons, or none
+
+POSSIBLY WRONG OR OVERSTATED
+- remaining assumptions, or none
+
+EXACT NEXT ACTION
+- smallest remaining action, or none
+
+WHAT DOES NOT COUNT AS COMPLETION
+- any unverified or undelivered part of this task
+
+CONTEXT
+- safe to continue here, or why a fresh context is required
+```
diff --git a/skills/fstack/SKILL.md b/skills/fstack/SKILL.md
index 947fc7b..e5ac92b 100644
--- a/skills/fstack/SKILL.md
+++ b/skills/fstack/SKILL.md
@@ -1,81 +1,78 @@
 ---
 name: fstack
-description: The fstack front door. Invoke /fstack alone to list every skill, or with a task to route it to the right one.
+description: The fstack front door. Invoke /fstack alone to list every interactive and continuous skill, or with a task to route it. Routes cloud-agent, autonomous, unattended, end-to-end, and finish-the-task requests to fstack-run.
 ---
 
 # /fstack
 
-The front door for fstack. Read what the user wants. Pick one skill. Run it. Stop.
-
-## When to use
-
-- The user invokes `/fstack`.
-- The user asks which fstack skill fits their task.
-- The user describes work and mentions fstack without naming a skill.
+The front door for fstack. Read what the user wants. Pick one skill and run it. Do not chain separate skills.
 
 ## Steps
 
 1. Read the user's request.
-2. **If there is no task** — the user typed `/fstack` alone, or just asked what fstack can do — list the twelve skills with a one-line description each, then stop and ask what they want to do. Do not route or guess. This is the menu below.
-3. **If there is a task** — match it to one of the twelve skills below.
+2. **If there is no task** — the user typed `/fstack` alone or only asked what fstack can do — list the thirteen skills below with a one-line description each. Then stop and ask what they want to do.
+3. **If there is a task** — match it to one of the thirteen skills below.
 4. Say which skill you picked and why, in one sentence.
-5. Run that skill. Do not chain others.
+5. Run that skill. `fstack-run` owns its complete end-to-end loop; all other skills retain their own stopping rules.
 
 ## The skills
 
-When there is no task, show this list:
-
 | Skill | What it does |
 |---|---|
-| `/fstack-roast` | Stress-test a product idea. Ends with a verdict and the smallest version worth building. |
-| `/fstack-interview` | Ask about the product — demand, customer, pricing, risks — and record the answers in AGENTS.md. |
-| `/fstack-nail` | Clarify a vague task, nail down a 3-line summary, and get your yes before planning. |
-| `/fstack-plan` | Write a one-page plan with a mandatory "what we're NOT doing" section. |
-| `/fstack-build` | Implement the plan one small step at a time, asking at real choices. |
-| `/fstack-simplify` | Audit for unnecessary complexity and propose deletions — one file or the whole codebase. |
-| `/fstack-design` | Make UI match the project's existing styles and clean up design slop. |
-| `/fstack-counselors` | Ask the 3 most capable models the same question and synthesize one verdict. |
-| `/fstack-check` | Review finished work: does it work, does it match the plan, is it simple. |
-| `/fstack-document` | Write docs/ for the project, ELI5 to deep. Run again to update them. |
-| `/fstack-learn` | Capture one lesson in three lines, so future sessions start smarter. |
-| `/fstack-push` | Commit the current task's changes and push to the remote. Nothing else. |
+| `/fstack-run` | Completes a repository task continuously from inspection through verified pull request. |
+| `/fstack-roast` | Stress-tests a product idea. Ends with a verdict and the smallest version worth building. |
+| `/fstack-interview` | Asks about the product — demand, customer, pricing, risks — and records the answers in AGENTS.md. |
+| `/fstack-nail` | Clarifies a vague task, nails down a 3-line summary, and gets your yes before planning. |
+| `/fstack-plan` | Writes a one-page plan with a mandatory "what we're NOT doing" section. |
+| `/fstack-build` | Implements the plan one small step at a time, asking at real choices. |
+| `/fstack-simplify` | Audits unnecessary complexity and proposes deletions — one file or the whole codebase. |
+| `/fstack-design` | Makes UI match the project's existing styles and cleans up design slop. |
+| `/fstack-counselors` | Asks three capable models the same question and synthesizes one verdict. |
+| `/fstack-check` | Reviews finished work: does it work, does it match the plan, is it simple. |
+| `/fstack-document` | Writes or updates project documentation from ELI5 to deep. |
+| `/fstack-learn` | Captures one lesson in three lines so future sessions start smarter. |
+| `/fstack-push` | Commits the current task's changes and pushes them. It does not test or deploy. |
 
 ## Routing map
 
 | Situation | Skill |
 |---|---|
-| Product idea, not sure it's worth building | `/fstack-roast` |
-| New project, the agent lacks business context | `/fstack-interview` |
-| Vague or unclear task | `/fstack-nail` |
-| Idea is clear, no plan exists | `/fstack-plan` |
-| Plan exists and is approved | `/fstack-build` |
-| Feels bloated or sloppy — one file or the whole codebase | `/fstack-simplify` |
-| UI looks off or inconsistent with the rest | `/fstack-design` |
+| Cloud agent, autonomous, unattended, end-to-end, or "keep going until done" | `/fstack-run` |
+| Product idea, not sure it is worth building | `/fstack-roast` |
+| New project, agent lacks business context | `/fstack-interview` |
+| Vague or unclear task, user wants an approval gate | `/fstack-nail` |
+| Idea is clear, no plan exists, user wants planning only | `/fstack-plan` |
+| Approved plan exists, user wants implementation only | `/fstack-build` |
+| Feels bloated or sloppy | `/fstack-simplify` |
+| UI looks off or inconsistent | `/fstack-design` |
 | Big decision, one opinion is not enough | `/fstack-counselors` |
-| Work is done, needs review | `/fstack-check` |
-| Project needs docs, or the docs have gone stale | `/fstack-document` |
-| Something worth remembering just happened | `/fstack-learn` |
-| Just want it committed and pushed | `/fstack-push` |
+| Work is done and needs a report-only review | `/fstack-check` |
+| Project needs docs or docs are stale | `/fstack-document` |
+| A non-obvious lesson is worth preserving | `/fstack-learn` |
+| User explicitly wants only commit and push | `/fstack-push` |
 
-## Stop and ask
+## Ambiguity
 
-If you truly cannot tell which skill fits, ask **one** clarifying question. Then route.
-
-If still ambiguous after the answer, route to `/fstack-nail`. That is what it is for.
+If you truly cannot tell which skill fits, ask one clarifying question. If ambiguity remains, route to `/fstack-nail` for interactive work or `/fstack-run` when the user clearly requested continuous execution.
 
 ## Must NOT
 
-- Route when there is no task. List the skills and ask instead.
-- Chain multiple skills. Pick one, run it, stop.
-- Ask more than one clarifying question before routing.
-- Plan, code, or review inside this skill. Route and hand off.
+- Route when there is no task. List the skills instead.
+- Chain separate skills in the front door.
+- Ask more than one routing question.
+- Route a continuous cloud request into the stop-and-wait loop.
+- Route a request for review-only or push-only into autonomous code changes.
 
-## Example
+## Examples
 
 > User: `/fstack`
 >
-> Agent: *(lists the twelve skills with one-line descriptions)* "That's the full set. What do you want to do?"
+> Agent: *(lists the thirteen skills)* "What do you want to do?"
+
+> User: `/fstack fix issue 42 and keep going until the PR is verified`
+>
+> Agent: "This is end-to-end repository work, so I am using `/fstack-run`." *(runs fstack-run continuously)*
 
-> User: `/fstack I want to add dark mode to my site`
+> User: `/fstack write a plan for dark mode but do not implement it`
 >
-> Agent: "This leaves important choices open, so I'll start with `/fstack-nail` to make sure I understand what you want." *(runs /fstack-nail)*
+> Agent: "This is planning-only work, so I am using `/fstack-plan`." *(runs fstack-plan)*