bigpowers 1.0.0

package/dispatch-agents/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: dispatch-agents
+description: Dispatch multiple subagents in parallel on independent tasks. No waiting between them — all run concurrently. Use when tasks are truly decoupled and speed matters. Distinct from delegate-task (concurrent here, no inter-task review gate).
+---
+
+# Dispatch Agents
+
+Run multiple subagents in parallel on independent tasks. Use when tasks are genuinely decoupled — no agent needs the output of another to start.
+
+**Distinct from `delegate-task`:** This skill maximizes throughput via concurrency. There is no sequential review gate between tasks. Use `delegate-task` instead when a single task needs careful two-stage oversight before proceeding.
+
+## When to use
+
+- Tasks that can run simultaneously without shared state
+- Large plans that can be broken into parallel workstreams
+- Exploration: gather information from multiple parts of the codebase at once
+
+## When NOT to use
+
+- Task B depends on Task A's output
+- You need to review Task A before Task B can start safely
+- The tasks share a file and concurrent edits would conflict
+
+## Process
+
+### 1. Confirm independence
+
+Before dispatching, verify each task pair is truly independent:
+- No shared files being written
+- No shared state (DB migrations, config files)
+- No ordering dependency between outcomes
+
+If any two tasks conflict, sequence them with `delegate-task` or `execute-plan` instead.
+
+### 2. Write task briefs
+
+Before writing briefs, read `specs/STATE.md` if it exists — each agent gets only the decisions relevant to its task, nothing else.
+
+For each task, use this minimal template (each agent starts cold — brief size directly controls token cost and hallucination risk):
+
+```
+Goal: [one sentence — what success looks like]
+In scope: [explicit file or module list]
+Out of bounds: [what NOT to touch]
+Verify: [runnable command]
+Prior decisions: [relevant entries from specs/STATE.md — omit section if none apply]
+```
+
+Do not include the full conversation, full file contents, or decisions unrelated to this agent's task.
+
+### 3. Dispatch in parallel
+
+Spawn all agents in a single message using multiple Agent tool calls. Each agent gets its own complete brief.
+
+```
+Agent 1: brief for task A
+Agent 2: brief for task B
+Agent 3: brief for task C
+```
+
+### 4. Collect and review results
+
+When all agents return:
+- Review each result independently
+- Run all verify commands
+- Check diffs for scope violations or CONVENTIONS.md breaches
+
+### 5. Integrate
+
+Merge accepted results. If any agent's result conflicts with another, resolve manually and note the conflict.
+
+Report a summary: which tasks succeeded, which need revision, and overall verify status.

package/edit-document/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: edit-document
+description: Edit and improve documents by restructuring sections, improving clarity, and tightening prose. Use when user wants to edit, revise, restructure, or improve any document — including specs/ files, articles, READMEs, or technical writing.
+---
+
+1. First, divide the document into sections based on its headings. Think about the main points made in each section.
+
+Consider that information is a directed acyclic graph, and that pieces of information can depend on other pieces of information. Make sure that the order of the sections and their contents respects these dependencies.
+
+Confirm the sections with the user.
+
+2. For each section:
+
+2a. Rewrite the section to improve clarity, coherence, and flow. Use maximum 240 characters per paragraph.

package/elaborate-spec/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: elaborate-spec
+description: Refine a rough idea into a clear, detailed specification through dialogue. Does not produce code. Use when user has a vague idea, wants to think through a feature before planning, or needs to turn "I want X" into a concrete spec.
+---
+
+# Elaborate Spec
+
+Turn a rough idea into a clear specification through focused dialogue. No code is written during this skill — the output is shared understanding and a refined problem statement.
+
+## Process
+
+### 1. Listen first
+
+Let the user describe their idea in their own words. Do not interrupt or redirect. Take notes on:
+- The core problem they're trying to solve
+- Who is affected (actors)
+- What success looks like to them
+- Any constraints they've already identified
+
+### 2. Ask clarifying questions
+
+Ask one question at a time. Work through these areas:
+
+**Problem clarity**
+- What is the current behavior (or lack of behavior) that prompted this?
+- Who experiences this problem? How often?
+- What's the cost of not solving it?
+
+**Solution boundaries**
+- What is explicitly IN scope?
+- What is explicitly OUT of scope?
+- Are there existing solutions (internal or external) this replaces or integrates with?
+
+**Success criteria**
+- How will you know this is done?
+- What does the happy path look like end-to-end?
+- What are the key failure modes to handle?
+
+**Constraints**
+- Any performance requirements?
+- Any compatibility constraints (existing APIs, data formats)?
+- Any non-negotiable implementation decisions already made?
+
+### 2.5. Multiple Interpretations (HARD GATE)
+
+> **HARD GATE** — If the request admits ≥2 valid interpretations, do NOT guess. You must list them and ask the user to choose before proceeding. Proceeding with unresolved ambiguity is a failure of integrity.
+
+Present the options clearly:
+> "I see two ways to read this:
+> 1. [Interpretation A] — my recommendation because [reason]
+> 2. [Interpretation B]
+> Which is closer to what you mean?"
+
+### 3. Surface hidden assumptions
+
+Once the user has answered the main questions, probe for assumptions:
+- "You mentioned X — does that mean Y is also true?"
+- "What happens when Z fails?"
+- "Is this for internal users, external users, or both?"
+
+### 4. Synthesize and confirm
+
+Summarize your understanding in 3–5 bullet points:
+- The problem
+- The solution
+- The key constraints
+- The success criteria
+- What's out of scope
+
+Ask: "Is this an accurate summary? Anything missing or wrong?"
+
+### 5. Suggest next skill
+
+Once the spec is clear, recommend the next step:
+- If domain model needs work → `model-domain`
+- If ready to plan → `plan-release` then `plan-work` per story
+- If a spike is needed first → `spike-prototype`
+- If architecture decisions are needed → `deepen-architecture` or `grill-me`
+- If the plan depends on a specific library or API → `grill-me` in docs mode

package/enforce-first/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: enforce-first
+description: Apply the F.I.R.S.T test quality rubric (Fast, Independent, Repeatable, Self-Validating, Timely) to a test suite or individual tests. Use when develop-tdd is writing tests, when test quality needs to be checked, or when user mentions F.I.R.S.T or "test quality".
+---
+
+# Enforce FIRST
+
+Apply the F.I.R.S.T rubric (Uncle Bob, Clean Code Chapter 9) to evaluate and improve tests.
+
+This skill is typically invoked internally by `develop-tdd` during the test-writing phase. It can also be run standalone on an existing test suite.
+
+## The F.I.R.S.T Rubric
+
+### F — Fast
+
+Tests must run quickly. Slow tests don't get run. They don't get trusted.
+
+- [ ] No real network calls (use fakes/stubs for external I/O)
+- [ ] No real database (use in-memory or transaction-rollback strategies)
+- [ ] No `sleep` or arbitrary timeouts in test code
+- [ ] The full suite runs in under 30 seconds (target; adjust to project size)
+
+**Fix:** Replace slow I/O with named fake classes. Never inline anonymous stubs.
+
+### I — Independent
+
+Tests must not depend on each other. Running in any order must produce the same result.
+
+- [ ] No shared mutable state between tests
+- [ ] Each test sets up its own data and tears it down
+- [ ] No test assumes another test ran first
+- [ ] Tests can be run individually (e.g. `npm test -- mytest.test.ts`) and pass
+
+**Fix:** Move setup into `beforeEach`. Use factory functions to build test data.
+
+### R — Repeatable
+
+Tests must pass consistently in any environment.
+
+- [ ] No dependency on machine-specific paths, ports, or environment variables (unless explicitly injected)
+- [ ] No dependency on current time without mocking the clock
+- [ ] No flakiness — a test that sometimes fails is worse than no test
+- [ ] Tests pass on CI the same way they pass locally
+
+**Fix:** Inject time, randomness, and environment as parameters. Pin seeds for anything random.
+
+### S — Self-Validating
+
+Tests must report pass or fail automatically. No human inspection required.
+
+- [ ] Tests use assertions (`expect`, `assert`, etc.) — not just `console.log`
+- [ ] Failure messages are descriptive enough to diagnose without reading the test body
+- [ ] No tests that "pass" by default when the feature is broken
+
+**Fix:** Add assertion messages. Use matchers that describe the expected behavior.
+
+### T — Timely
+
+Tests must be written at the right time — before or immediately with the code they test.
+
+- [ ] Tests are written in the same commit as the code (or the commit before, if TDD)
+- [ ] No "I'll add tests later" patterns
+- [ ] Bug fixes include a regression test that would have caught the bug
+
+**Fix:** Run `develop-tdd` — it enforces the timely principle by design.
+
+## Applying the rubric
+
+For each failing criterion:
+1. Identify which tests violate it
+2. Describe the fix
+3. Apply the fix
+4. Re-run the suite to confirm it still passes
+
+Report: "F.I.R.S.T audit complete. X criteria passed, Y fixed."

package/execute-plan/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: execute-plan
+description: Batch-execute tasks from specs/RELEASE-PLAN.md sequentially, with a human checkpoint after each step. Use when user has an approved plan and wants to execute it step-by-step with oversight, or mentions "execute the plan" or "run the plan".
+---
+
+# Execute Plan
+
+Execute the tasks in `specs/RELEASE-PLAN.md` one at a time, showing evidence after each step before proceeding.
+
+> **HARD GATE** — Do NOT proceed if on `main` or `master`. Run `kickoff-branch` first to create a feature branch or worktree.
+>
+> **HARD GATE** — Do NOT execute a plan if `specs/RELEASE-PLAN.md` does not exist or if its tasks lack runnable `verify:` commands. If the plan is missing or weak, run `plan-release` then `plan-work` first.
+
+## Process
+
+### 1. Read the plan
+
+Read `specs/RELEASE-PLAN.md` in full. Confirm with the user:
+- How many steps are there?
+- Any steps to skip or reorder?
+- Should you stop after a specific step?
+
+### 2. Execute step by step
+
+For each step in the plan:
+
+**a. Announce the step**
+```
+─── Step N of M ─────────────────────────
+Task: [step description]
+verify: [verify command]
+```
+
+**b. Execute the work**
+Implement the step using the appropriate approach:
+- Write/edit code directly for small focused changes
+- Spawn a subagent via `delegate-task` for complex isolated work
+
+> **STREAM CONTINUITY** — When writing file content, output in continuous chunks of ~200 lines. Do not pause. Continue immediately until complete. If you need time, emit a placeholder comment rather than going silent.
+
+**c. Run the verify command**
+Every task in `specs/RELEASE-PLAN.md` must have a `verify: <cmd>`. Run it and show the output.
+
+**d. Log the decision**
+After verify passes, append to `specs/STATE.md` under `## Active Decisions`:
+```
+**Step N — [short name]**: [what approach was chosen and why — one sentence]
+```
+Only log if a non-obvious decision was made (approach chosen, constraint discovered, blocker resolved). Skip if the step was mechanical.
+
+**e. Checkpoint**
+Report the result and ask: "Step N complete. Proceed to step N+1?" (or proceed automatically if the user asked for fully autonomous execution)
+
+**f. Story Verification (UAT)**
+After the last step of a Story is completed:
+1. Present the **Verification Script** from `specs/RELEASE-PLAN.md` for this story.
+2. Ask the user to perform the manual verification steps.
+3. Wait for the user to confirm "pass" or describe issues.
+4. If issues are reported, log them and stop execution for diagnosis.
+
+If verify fails:
+- Do NOT move to the next step — never advance on a red verify
+- Diagnose the failure
+- Fix it and re-run verify
+- Loop on this step until the verify command is green
+- Only then proceed to the next step
+
+If verify passes but behavioral correctness is in doubt, do not advance — a mechanical green is not enough; confirm behavior is correct first.
+
+### 3. Handle blockers
+
+If a step cannot be completed as written:
+- Report the blocker clearly
+- Ask the user whether to skip, adapt, or stop
+- Update `specs/RELEASE-PLAN.md` if the plan needs revision
+
+### 4. Final report
+
+After all steps complete:
+```
+✓ Plan complete: N/N steps executed
+All verify commands passed.
+Suggested next: audit-code → commit-message → release-branch
+```

package/grill-me/REFERENCE.md

@@ -0,0 +1,63 @@
+# Docs Mode — Full Process
+
+Triggered by "grill me with docs" or when a plan depends on a specific library or external API.
+
+**Why this matters:** AI agents hallucinate API methods, argument orders, and behaviors. Every assumption about an external dependency must be validated against the actual docs before code is written.
+
+## Step 1 — Identify the dependencies
+
+From the plan or conversation, list:
+- Every external library being used
+- Every third-party API being called
+- Every framework behavior being relied upon
+
+Ask: "Which of these are you most confident about? Which are you less sure of?"
+
+## Step 2 — Fetch the relevant docs
+
+For each dependency, fetch the actual documentation:
+
+```
+WebFetch the official docs for [library/API]
+```
+
+Prioritize:
+- The API reference for the specific method being used
+- The changelog for the version in use (breaking changes)
+- Migration guides if upgrading from a previous version
+- Known gotchas / FAQ sections
+
+## Step 3 — Challenge each assumption
+
+For every assumption in the plan, find the corresponding doc section and ask:
+
+- "Does the real API actually work this way? Show me the doc."
+- "Is this method available in the version you're using?"
+- "Does this argument order match the actual signature?"
+- "Are there rate limits, quotas, or timeout behaviors that affect this design?"
+- "Is this marked as deprecated in the current version?"
+
+Ask one question at a time. For each challenge, cite the specific URL and section.
+
+## Step 4 — Surface hallucinations
+
+When an assumption doesn't match the docs:
+
+> "Your plan uses `library.doThing(a, b)` but the [docs](URL) show the signature is `doThing(config: {a, b})` with a config object. This will fail at runtime."
+
+Document each discrepancy clearly.
+
+## Step 5 — Update the plan
+
+For each confirmed discrepancy, recommend a concrete fix:
+- Correct method signature
+- Correct argument order
+- Alternative approach that matches what the library actually supports
+- Whether a spike (`spike-prototype`) is needed to validate a remaining uncertainty
+
+## Step 6 — Sign off
+
+When all major assumptions have been validated against docs, report:
+- Which assumptions were confirmed ✓
+- Which were corrected ✗ + what the correct approach is
+- Which remain uncertain → recommend `spike-prototype`

package/grill-me/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: grill-me
+description: Stress-test a plan or design through relentless questioning until every decision is resolved. Two modes: Design (default Q&A on decisions) and Docs (grounds every challenge in real library or API documentation). Use when user wants to challenge a plan, validate API assumptions, or mentions "grill me" or "grill me with docs".
+---
+
+# Grill Me
+
+Two modes. Default is **Design**. Switch to **Docs** by saying "grill me with docs" or when the plan relies on a specific library or external API.
+
+## Design mode (default)
+
+Interview relentlessly about every aspect of this plan until reaching shared understanding. Walk each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask one question at a time.
+
+If a question can be answered by exploring the codebase, explore it instead.
+
+## Docs mode
+
+Ground every challenge in real documentation — no assumption about a library's behavior goes unchecked. See [REFERENCE.md](REFERENCE.md) for the full process.
+
+Short form:
+1. List every external library, third-party API, and framework behavior relied upon.
+2. Fetch the actual docs for each (`WebFetch` the official API reference).
+3. Challenge each plan assumption against the real docs: correct method signature? right version? deprecated?
+4. Report confirmed ✓, corrected ✗ (with the real behavior), and uncertain → `spike-prototype`.
+5. Update the plan for each confirmed discrepancy.

package/guard-git/REFERENCE.md

@@ -0,0 +1,136 @@
+# Git guardrails — reference
+
+## Copy layout
+
+The main script is `pre-tool-use.sh`.
+
+```text
+<hooks-dir>/pre-tool-use.sh
+```
+
+Example project locations:
+
+- Claude: `.claude/hooks/`
+- Cursor: `.cursor/hooks/`
+- Gemini: `.gemini/hooks/`
+
+Use the same layout for user-level hooks (`~/.claude/hooks`, `~/.cursor/hooks`, `~/.gemini/hooks`).
+
+---
+
+## Claude Code
+
+Hook command does **not** need `GIT_GUARDRAILS_MODE` (defaults to `claude`).
+
+**Project** (`.claude/settings.json`):
+
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/pre-tool-use.sh"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+---
+
+## Cursor and Cursor CLI
+
+Use `beforeShellExecution`. Set `GIT_GUARDRAILS_MODE=cursor`.
+
+**Project** (`.cursor/hooks.json`):
+
+```json
+{
+  "version": 1,
+  "hooks": {
+    "beforeShellExecution": [
+      {
+        "command": "GIT_GUARDRAILS_MODE=cursor .cursor/hooks/pre-tool-use.sh",
+        "matcher": "git"
+      }
+    ]
+  }
+}
+```
+
+---
+
+## Gemini CLI
+
+Use `BeforeTool` with matcher `run_shell_command`. Set **`GIT_GUARDRAILS_MODE=gemini`**.
+
+**Project** (`.gemini/settings.json`):
+
+```json
+{
+  "hooks": {
+    "BeforeTool": [
+      {
+        "matcher": "run_shell_command",
+        "hooks": [
+          {
+            "name": "git-guardrails",
+            "type": "command",
+            "command": "GIT_GUARDRAILS_MODE=gemini \"$GEMINI_PROJECT_DIR\"/.gemini/hooks/pre-tool-use.sh",
+            "timeout": 5000
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+---
+
+## Google Antigravity
+
+Add **Deny list** entries in **Antigravity → Settings → Terminal**:
+
+- `git push`
+- `git push --force`
+- `git reset --hard`
+- `git clean`
+- `git branch -D`
+- `git checkout .`
+- `git restore .`
+
+---
+
+## Verify (local tests)
+
+**1. Dangerous Pattern (Claude mode):**
+```bash
+echo '{"tool_input":{"command":"git push origin main"}}' | ./pre-tool-use.sh
+# Expected: exit 2, stderr message
+```
+
+**2. Conventional Commits (Gemini mode):**
+```bash
+echo '{"tool_input":{"command":"git commit -m \"bad message\""}}' | GIT_GUARDRAILS_MODE=gemini ./pre-tool-use.sh
+# Expected: exit 0, {"decision":"deny", "reason":"..."}
+```
+
+**3. Protected Branch (Cursor mode):**
+```bash
+# Run on 'main' branch
+echo '{"command":"git commit -m \"feat: valid message\""}' | GIT_GUARDRAILS_MODE=cursor ./pre-tool-use.sh
+# Expected: exit 2, "Direct commits to protected branch 'main' are forbidden"
+```
+
+**4. Allow (Gemini mode):**
+```bash
+echo '{"tool_input":{"command":"git status"}}' | GIT_GUARDRAILS_MODE=gemini ./pre-tool-use.sh
+# Expected: exit 0, {"decision":"allow"}
+```

package/guard-git/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: guard-git
+description: Block dangerous git commands (push, force push, reset --hard, clean, branch -D, checkout/restore .) and enforce Conventional Commits & Branch Protection before an AI agent runs them. Installs hook scripts for Claude Code, Cursor, Cursor CLI, and Gemini CLI; documents Google Antigravity Terminal deny lists. Use when the user wants git safety hooks, to block git push or destructive git in agents, or to mirror the same policy across AI coding tools.
+---
+
+# Guard Git
+
+Installs a shared hook that blocks destructive git operations and enforces workflow discipline. **Requires `jq` on the agent's PATH** when the hook runs.
+
+## What gets blocked/enforced
+
+- **Safety**: `git push` (including `--force`), `git reset --hard`, `git clean -f`, `git branch -D`, `git checkout .`, `git restore .`.
+- **Discipline**: Blocks direct commits or pushes to protected branches (`main`, `master`).
+- **Standardization**: Enforces [Conventional Commits](https://www.conventionalcommits.org/) for all `git commit` commands.
+
+## Quick start
+
+1. **Scope**: ask project-only vs global (paths differ per product).
+2. **Copy the hook bundle** from the root [hooks/](hooks/) directory to the client's hooks directory.
+3. **Run `chmod +x`** on `pre-tool-use.sh`.
+4. **Merge** the hook snippet from [REFERENCE.md](REFERENCE.md) into the right settings file — do not wipe unrelated keys.
+5. **Verify** with the tests in [REFERENCE.md](REFERENCE.md).
+
+| Client | Mechanism | Config |
+|--------|-----------|--------|
+| Claude Code | `PreToolUse` (Bash) | `.claude/settings.json` or `~/.claude/settings.json` |
+| Cursor / Cursor CLI | `beforeShellExecution` | `.cursor/hooks.json` or `~/.cursor/hooks.json` |
+| Gemini CLI | `BeforeTool` + `run_shell_command` | `.gemini/settings.json` or `~/.gemini/settings.json` |
+| Google Antigravity | Built-in Terminal **Deny list** | Settings UI (no shell hook) |
+
+**Modes (env on the hook command):** `GIT_GUARDRAILS_MODE` is `claude` (default) or `cursor` → stderr + exit `2` on block. Set `gemini` for Gemini CLI → JSON `decision` on stdout.
+
+## Customization
+
+To add or remove patterns or protected branches, edit `pre-tool-use.sh`.
+
+## Advanced
+
+Full JSON examples, merge rules, Antigravity deny-list entries, and test commands: [REFERENCE.md](REFERENCE.md).

package/guard-git/scripts/block-dangerous-git.sh

@@ -0,0 +1,41 @@
+#!/usr/bin/env bash
+# Blocks dangerous git commands for Claude Code, Cursor, and Gemini CLI hooks.
+# Requires jq on PATH.
+# GIT_GUARDRAILS_MODE: claude (default) | cursor | gemini
+#   claude/cursor: stderr message, exit 2 on block, exit 0 on allow
+#   gemini: JSON with decision on stdout, exit 0 always (allow or deny)
+
+set -euo pipefail
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/git-guardrails-core.sh
+. "$SCRIPT_DIR/lib/git-guardrails-core.sh"
+
+INPUT=$(cat)
+COMMAND=$(echo "$INPUT" | jq -r '.command // .tool_input.command // empty')
+MODE="${GIT_GUARDRAILS_MODE:-claude}"
+
+if [ -z "$COMMAND" ]; then
+  if [ "$MODE" = "gemini" ]; then
+    echo '{"decision":"allow"}'
+  fi
+  exit 0
+fi
+
+if PATTERN=$(git_guardrails_first_match "$COMMAND"); then
+  REASON="BLOCKED: '$COMMAND' matches dangerous pattern '$PATTERN'. The user has prevented you from doing this."
+  case "$MODE" in
+    gemini)
+      jq -nc --arg reason "$REASON" '{decision: "deny", reason: $reason}'
+      exit 0
+      ;;
+    claude|cursor|*)
+      echo "$REASON" >&2
+      exit 2
+      ;;
+  esac
+else
+  if [ "$MODE" = "gemini" ]; then
+    echo '{"decision":"allow"}'
+  fi
+  exit 0
+fi

package/guard-git/scripts/lib/git-guardrails-core.sh

@@ -0,0 +1,29 @@
+# Shared pattern list and matcher for git hook guardrails.
+# Source from block-dangerous-git.sh only.
+
+GIT_GUARDRAILS_PATTERNS=(
+  "git push"
+  "git reset --hard"
+  "git clean -fd"
+  "git clean -f"
+  "git branch -D"
+  "git checkout \\."
+  "git restore \\."
+  "push --force"
+  "reset --hard"
+)
+
+# Print first matching pattern to stdout; exit 0 if dangerous, 1 if safe.
+# Usage: if git_guardrails_first_match "$command"; then read pattern; fi
+# Actually: pattern=$(git_guardrails_first_match "$c") && ...
+git_guardrails_first_match() {
+  local cmd="$1"
+  local p
+  for p in "${GIT_GUARDRAILS_PATTERNS[@]}"; do
+    if echo "$cmd" | grep -qE "$p"; then
+      printf '%s' "$p"
+      return 0
+    fi
+  done
+  return 1
+}