bigpowers 1.3.2 → 1.4.0

package/edit-document/SKILL.md

@@ -4,6 +4,12 @@ model: sonnet
 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.
 ---
 
+# Edit Document
+
+> **HARD GATE** — Document edits must preserve intent and accuracy. Do NOT remove or contradict existing content without understanding why it was written. Check git history for context.
+
+## Process
+
 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.

package/elaborate-spec/SKILL.md

@@ -8,6 +8,8 @@ description: Refine a rough idea into a clear, detailed specification through di
 
 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.
 
+> **HARD GATE** — Do NOT proceed with planning or implementation until the problem space is clearly understood. Success criteria, actors, and scope must be explicit before drafting a plan.
+
 ## Process
 
 ### 1. Listen first

package/enforce-first/SKILL.md

@@ -5,6 +5,8 @@ description: Apply the F.I.R.S.T test quality rubric (Fast, Independent, Repeata
 ---
 
 # Enforce FIRST
+> **HARD GATE** — **HARD GATE** — Before shipping, ALL enforcement checks must pass: lint, typecheck, tests, coverage gates. Do NOT disable or skip checks to get to green.
+
 
 Apply the F.I.R.S.T rubric (Uncle Bob, Clean Code Chapter 9) to evaluate and improve tests.
 

package/grill-me/SKILL.md

@@ -8,6 +8,8 @@ description: Stress-test a plan or design through relentless questioning until e
 
 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.
 
+> **HARD GATE** — Do NOT accept a design until every hard decision has been stress-tested. "Seems right" is not a decision. Grilling must identify and resolve tensions before build begins.
+
 ## 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.

package/guard-git/SKILL.md

@@ -5,6 +5,8 @@ description: Block dangerous git commands (push, force push, reset --hard, clean
 ---
 
 # Guard Git
+> **HARD GATE** — **HARD GATE** — Before committing, verify: branch is not main/master, author is correct, git user is configured. Bad commits are hard to fix.
+
 
 Installs a shared hook that blocks destructive git operations and enforces workflow discipline. **Requires `jq` on the agent's PATH** when the hook runs.
 

package/hook-commits/SKILL.md

@@ -5,6 +5,8 @@ description: Set up pre-commit hooks with lint-staged (Prettier), type checking,
 ---
 
 # Hook Commits
+> **HARD GATE** — **HARD GATE** — Pre-commit and commit-msg hooks must run before any commit lands. Skipping hooks (`--no-verify`) is forbidden unless explicitly authorized for a specific commit and documented.
+
 
 ## What This Sets Up
 

package/inspect-quality/SKILL.md

@@ -5,6 +5,8 @@ description: Interactive QA session where user reports bugs or issues conversati
 ---
 
 # Inspect Quality
+> **HARD GATE** — **HARD GATE** — Quality metrics (coverage, lint, cyclomatic complexity, security scans) must be monitored. If a metric degrades, surface it as a blocker. Do NOT accept regressions.
+
 
 Run an interactive QA session. The user describes problems they're encountering. You clarify, explore the codebase for context, and log each issue to `specs/bugs/registry.yaml` with a structured, durable format.
 

package/kickoff-branch/SKILL.md

@@ -93,3 +93,8 @@ Ready to develop.
 ```
 
 Suggest next skill: `develop-tdd` to start the TDD loop, or `execute-plan` if `specs/release-plan.yaml + epic shards` already exists.
+
+## Handoff
+
+Gate: READY -> next: develop-tdd
+Writes: state.yaml handoff.next_skill = develop-tdd

package/map-codebase/SKILL.md

@@ -8,6 +8,8 @@ description: "High-fidelity codebase surveying — analyzes stack, architecture,
 
 Perform a deep architectural and structural analysis of the codebase. Unlike `survey-context` which identifies "where we are", `map-codebase` identifies "what we are dealing with" and "how things are done".
 
+> **HARD GATE** — Cold analysis only. Do NOT assume architectural patterns without reading the code. If the codebase structure surprises you, call out the delta.
+
 ## Process
 
 ### 1. Identify Core Stack & Dependencies

package/model-domain/SKILL.md

@@ -4,8 +4,12 @@ model: sonnet
 description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates specs/plans/TECH_STACK_LATEST.md and specs/adr/ inline as decisions crystallise. Use when user wants to stress-test a plan against their project's domain language and documented decisions.
 ---
 
+# Model Domain
+
 Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
 
+> **HARD GATE** — Capture invariants (what MUST always be true) and state machines (what transitions are legal) for core entities. If these are fuzzy, design will fail.
+
 Ask the questions one at a time, waiting for feedback on each question before continuing.
 
 If a question can be answered by exploring the codebase, explore the codebase instead.

package/orchestrate-project/REFERENCE.md

@@ -13,7 +13,7 @@ Detailed documentation for the `orchestrate-project` meta-skill.
 ### PHASE 2: ELABORATE
 - **Goal**: Research solutions and lock architectural design.
 - **Deliverables**: Prior art in scope YAML, ADRs in `specs/adr/`.
-- **Skills**: `model-domain`, `define-language`, `challenge-design`.
+- **Skills**: `grill-me`, `model-domain`, `define-language`, `deepen-architecture`, `design-interface`.
 - **Gate**: Quality ≥94% (via `request-review`) + Confirm ("Are decisions locked?").
 
 ### PHASE 3: PLAN

package/orchestrate-project/SKILL.md

@@ -5,6 +5,8 @@ description: Meta-skill that enforces the 6-phase core loop (discover → elabor
 ---
 
 # Orchestrate
+> **HARD GATE** — **HARD GATE** — Do NOT invoke orchestrate-project unless you have a clear multi-phase workflow. Single-skill tasks should use dedicated skills instead. Orchestrate is for complex, multi-stage work that requires coordination across phases.
+
 
 The orchestrate skill coordinates projects through a prescriptive 6-phase core loop with hard gates, ensuring consistent quality and preventing scope creep.
 
@@ -26,7 +28,7 @@ claude /orchestrate --mode fast-track
 1. **DISCOVER** (3-6 hours): Understand problem. Deliverables: `requirements/VISION_LATEST.yaml`, `requirements/SCOPE_LATEST.yaml`, `plans/TECH_STACK_LATEST.md`.
 2. **ELABORATE** (3-6 hours): Research solutions. Deliverables: Prior art in scope YAML, ADRs in `specs/adr/`.
 3. **PLAN** (2-4 hours): Write verifiable plan. Deliverables: `release-plan.yaml`, `epics/eNN-*.yaml` with `verify:` per task.
-4. **BUILD** (1-8 hours): Execute plan. Deliverables: Code; update `execution-status.yaml`.
+4. **BUILD** (1-8 hours): Execute plan. Runs build-epic once per story in WSJF order. Deliverables: Code; update `execution-status.yaml`.
 5. **VERIFY** (1-3 hours): Validate success criteria. Deliverables: UAT evidence, `specs/EVALS-*.md` if used.
 6. **RELEASE** (30 min - 2 hours): Ship to production. Deliverables: Release tag (vX.Y.Z), `state.yaml` `release.last_tag`.
 

package/organize-workspace/SKILL.md

@@ -5,6 +5,8 @@ description: Scans the active workspace for disposable artifacts—logs, caches,
 ---
 
 # Organize Workspace
+> **HARD GATE** — **HARD GATE** — Workspace structure must reflect domain structure. If the codebase feels disorganized, flag it. Disorganization != 'just a style thing;' it is a signal of domain misalignment.
+
 
 ## Principles
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bigpowers",
-  "version": "1.3.2",
+  "version": "1.4.0",
   "description": "61 agent skills for spec-driven, test-first software development by solo developers",
   "main": "index.js",
   "scripts": {
@@ -11,7 +11,9 @@
     "version": "bash scripts/sync-skills.sh && git add .gemini/extensions/bigpowers/gemini-extension.json specs/SKILL-SEARCH-INDEX.md",
     "install": "bash scripts/install.sh",
     "postinstall": "bash scripts/sync-skills.sh && bash scripts/install.sh",
-    "release": "semantic-release"
+    "release": "semantic-release",
+    "dashboard": "node dashboard/bin/dashboard.js",
+    "dashboard:web": "node dashboard/bin/dashboard.js --web"
   },
   "keywords": [
     "skills",

package/plan-refactor/SKILL.md

@@ -5,6 +5,8 @@ description: Create a detailed refactor plan with tiny commits via user intervie
 ---
 
 # Plan Refactor
+> **HARD GATE** — **HARD GATE** — Before refactoring, document the current behavior and why it is wrong. Extract one invariant that must be preserved. If you skip this, you will break things you don't expect.
+
 
 Create a detailed refactor plan through a user interview. Save output to `specs/REFACTOR.md`.
 

package/plan-work/SKILL.md

@@ -39,6 +39,11 @@ If this plan touches an existing module or symbol, run `assess-impact` first to
 
 > **SLOPCHECK (HARD GATE)** — For every external package proposed in the plan, run slopcheck (or manual registry check) and tag: `[OK]`, `[SUS]`, or `[SLOP]`. `[SUS]` and `[SLOP]` require explicit human approval before the step may execute. Document tags inline next to the package name.
 
+## Invocation modes
+
+- Default: full plan with zoom-out mandate, impact assessment, slopcheck
+- --fast (formerly plan-work-fast): Skip zoom-out and impact assessment. Use for tasks under 3 BCPs with no module interface changes.
+
 ## Process
 
 ### 1. Explore the codebase
@@ -62,6 +67,8 @@ Break the implementation into the smallest possible steps where each step:
 
 Append tasks under the relevant story in `specs/epics/{epic-id}-*.yaml` (`tasks[]` with `desc` + `verify`). Update `specs/release-plan.yaml` if a new story is needed. Run `bash scripts/sync-status-from-epics.sh` after structural changes.
 
+**BCP Accounting:** Each task line MUST be prefixed `[BCP N]` where N is its sequence number. After all tasks, write `bcps: <total>` to the epic shard YAML under the story's metadata.
+
 <plan-template>
 
 ### Story [X.Y]: [title] — Implementation Steps
@@ -127,3 +134,40 @@ Before finalizing, confirm:
 - Are the verify commands actually runnable in this project?
 
 After writing epic tasks, suggest `kickoff-branch` (if not already on a feature branch) then `build-epic`, `execute-plan`, or `develop-tdd`.
+
+## Sub-operations
+
+### Define Success (absorbed)
+
+Before planning, convert task statements into observable "step → verify: <cmd>" pairs:
+
+- Break the task into observable outcomes (behaviors) rather than implementation steps
+- Write pairs in the format: [What must be true] → verify: <runnable command>
+- Challenge completeness: are there any required behaviors not covered?
+- Get user confirmation: "Does this capture everything the task requires?"
+- Once confirmed, these pairs become the skeleton for plan-work steps
+
+### Zoom-Out Check (absorbed)
+
+When modifying an existing module, confirm scope is understood:
+
+- State the module's **purpose** — what is it responsible for?
+- Name the **callers** — who depends on it?
+- List the **contracts** — what invariants or interfaces must be preserved?
+
+If you cannot answer all three without deep code archaeology, scope is misunderstood. Clarify with the user before writing steps.
+
+### Slopcheck (absorbed)
+
+For every external package proposed in the plan, tag each with one of:
+
+- `[OK]` — package is mature, actively maintained, appropriate scope
+- `[SUS]` — package is suspiciously broad, has maintenance concerns, or unclear fit
+- `[SLOP]` — package is unmaintained, has known security issues, or out of scope
+
+`[SUS]` and `[SLOP]` require explicit human approval before the step may execute. Document tags inline next to the package name.
+
+## Handoff
+
+Gate: READY -> next: kickoff-branch
+Writes: state.yaml handoff.next_skill = kickoff-branch

package/release-branch/SKILL.md

@@ -10,6 +10,10 @@ description: Make the merge/PR/keep/discard decision for a feature branch, verif
 
 Finalize a completed feature branch: verify coverage gates, integrate onto `main`, and clean up the worktree.
 
+## Additional modes
+
+- --hotfix: Emergency fix. Cherry-pick to main plus immediate tag. Skip PR in solo profile.
+
 ## Integrate mode
 
 Choose mode from project profile or explicit user request:
@@ -140,6 +144,25 @@ git branch -d <branch-name>
 - If `git worktree remove` fails due to uncommitted changes, ask the user: "There are uncommitted changes in the worktree. Force remove? (y/n)". If yes: `git worktree remove -f ../<branch-name>`.
 - If the directory `../<branch-name>` is already missing, `git worktree remove` might fail; the `|| true` ensures the process continues to branch deletion.
 
+### 8a. Cycle-time recording
+
+After landing the branch, record delivery metrics for this story:
+
+1. Write `metrics.story_end` with the current ISO 8601 timestamp to `specs/state.yaml`
+2. Compute `cycle_minutes`: `story_end` minus `story_start` in minutes
+3. Compute `bcp_per_hour`: `epic_cycle.story_bcps` divided by `(cycle_minutes / 60)`
+4. Append a row to `specs/metrics/cycle-times.yaml` with fields: `id`, `bcps`, `start`, `end`, `cycle_minutes`, `bcp_per_hour`
+
+Example row:
+```yaml
+- id: e01s01
+  bcps: 3
+  start: "2026-06-10T09:45:00Z"
+  end: "2026-06-10T11:15:00Z"
+  cycle_minutes: 90
+  bcp_per_hour: 2.0
+```
+
 ### 9. Return to main (primary worktree)
 
 ```bash
@@ -154,3 +177,8 @@ Confirm:
 - [ ] cwd is the primary repository root, not `../<task-slug>`
 
 Report: "Branch released. Integrate mode: <solo-local|team-pr>. cwd: $(pwd) on $(git branch --show-current)."
+
+## Handoff
+
+Gate: READY -> next: survey-context
+Writes: state.yaml handoff.next_skill = survey-context

package/respond-review/SKILL.md

@@ -5,6 +5,8 @@ description: Act on a reviewer agent's feedback systematically — categorize fi
 ---
 
 # Respond Review
+> **HARD GATE** — **HARD GATE** — Every reviewer comment must be addressed (fix, disagree + document reason, or ask clarification). Do NOT ignore feedback and merge.
+
 
 Work through reviewer findings systematically. Don't apply changes blindly — categorize first, then decide, then fix, then verify.
 

package/run-planning/SKILL.md

@@ -5,6 +5,8 @@ description: Advance discover-phase workflows and update specs/planning-status.y
 ---
 
 # Run Planning
+> **HARD GATE** — **HARD GATE** — Before running planning skills, confirm the epic shard exists and the active story is clear. Planning without a target is noise.
+
 
 Updates `specs/planning-status.yaml` as discover-phase skills complete.
 

package/search-skills/SKILL.md

@@ -5,6 +5,8 @@ model: haiku
 ---
 
 # Search Skills
+> **HARD GATE** — **HARD GATE** — Search results must be ranked by relevance. Do NOT return all matches without prioritization. Use skill metadata (phase, purpose, frequency) to rank.
+
 
 Lexical search only — no embedding service (ADR: zero external dependency).
 

package/seed-conventions/SKILL.md

@@ -5,6 +5,8 @@ description: Generate CLAUDE.md and CONVENTIONS.md for a brand-new project throu
 ---
 
 # Seed Conventions
+> **HARD GATE** — **HARD GATE** — Before any new code lands, confirm the project conventions are understood. Ask: 'What does a good commit message look like in this project?'
+
 
 Bootstrap a new project with the AI agent conventions it needs. Run this once at the start of a greenfield project.
 

package/session-state/SKILL.md

@@ -5,6 +5,8 @@ description: Track implementation decisions and progress in specs/state.yaml to
 ---
 
 # Session State
+> **HARD GATE** — **HARD GATE** — Session state must be synchronized with git state. If state.yaml conflicts with the working tree, halt and ask for clarification. Do NOT assume state is correct.
+
 
 Track the current state of implementation, including decisions made, pending tasks, and open questions, to ensure continuity across session boundaries and prevent "context rot."
 
@@ -66,6 +68,20 @@ Whenever a significant decision is made or a milestone is reached:
 
 → verify: `bash scripts/validate-specs-yaml.sh`
 
+## Operations
+
+### show-state (absorbed)
+
+Print the current session state: `cat specs/state.yaml`, then display `active_flow` and `handoff.next_skill` for quick reference.
+
+### reset-state (absorbed)
+
+Clear ephemeral session state. Set `active_epic_id`, `active_story_id`, and `epic_cycle.current_step` to `null` in `specs/state.yaml`. Use when ending a phase or starting a new project context.
+
+### compact-state (absorbed)
+
+Archive verbose decisions before a context transition. Move all entries from `handoff.open_decisions` to `specs/adr/` as individual ADR files, then reset `handoff.open_decisions` to an empty list.
+
 ## File Format: specs/state.yaml
 
 ```yaml

package/setup-environment/SKILL.md

@@ -5,6 +5,8 @@ model: haiku
 ---
 
 # Setup Environment
+> **HARD GATE** — **HARD GATE** — Environment setup must be idempotent and reproducible. If setup fails, provide clear error messages and remediation steps. Do NOT assume prior state.
+
 
 Idempotent prep so BUILD phase commands succeed on first run.
 

package/simulate-agents/SKILL.md

@@ -5,6 +5,8 @@ model: sonnet
 ---
 
 # Simulate Agents
+> **HARD GATE** — **HARD GATE** — Simulations are hypothetical. Do NOT use sim results to make production decisions without validation on real agents. Sims help discover gaps, not replace testing.
+
 
 Two roles, **isolated contexts** (no shared state with BUILD agent):
 

package/spike-prototype/SKILL.md

@@ -5,6 +5,8 @@ description: Throw-away prototype for unknown problem spaces. Output is learning
 ---
 
 # Spike Prototype
+> **HARD GATE** — **HARD GATE** — Spikes are time-boxed experiments, not shipping code. Results must be throwaway or clearly isolated. Do NOT merge a spike without a plan to integrate it or replace it with a proper implementation.
+
 
 A spike is a time-boxed experiment to answer a specific question. The code is thrown away. The learning is kept in `specs/archive/spikes/SPIKE-<name>.md`.
 

package/stocktake-skills/SKILL.md

@@ -5,6 +5,8 @@ model: sonnet
 ---
 
 # Stocktake Skills
+> **HARD GATE** — **HARD GATE** — Skill inventory must be current. Missing HARD GATEs, stale descriptions, or broken verify commands are defects, not cosmetic. Fix them in `evolve-skill`.
+
 
 Audit SKILL.md catalog for drift, stale triggers, missing HARD GATEs, and INDEX mismatches.
 

package/survey-context/SKILL.md

@@ -8,6 +8,10 @@ description: Per-task context survey — reads specs/ and CONVENTIONS.md, maps t
 
 Read the project's current state and give a phase map + next-skill recommendation. This is the "where am I?" skill — run it at the start of every task.
 
+> **HARD GATE** — Read specs/ files before suggesting next steps. If state.yaml is stale or contradicts the codebase, request clarification rather than assuming intent.
+
+Orchestrate-project 6 phases: Phase 1 Discover - Phase 2 Elaborate - Phase 3 Plan - Phase 4 Build - Phase 5 Verify - Phase 6 Release
+
 ## Process
 
 ### 1. Read CONVENTIONS.md
@@ -103,3 +107,22 @@ If something looks wrong:
 - Git hash in `state.yaml` stale vs `git rev-parse`
 
 Report blockers first, before recommendations.
+
+### 8. Record story start timestamp
+
+At story start, write `metrics.story_start` with the current ISO 8601 timestamp to `specs/state.yaml` for cycle-time tracking.
+
+## Utility outputs
+
+### list-epics (absorbed)
+
+Loop through all `specs/epics/*.yaml` files and print a summary of story counts per epic. Useful for understanding overall project scope and epic distribution.
+
+### check-gates (absorbed)
+
+Print the current `active_flow` from `specs/state.yaml`, run `bash scripts/validate-specs-yaml.sh` to verify YAML integrity, and show `git status` to report uncommitted changes and branch state. Use before handoffs or context transitions.
+
+## Handoff
+
+Gate: READY -> next: plan-work
+Writes: state.yaml handoff.next_skill = plan-work

package/terse-mode/SKILL.md

@@ -7,6 +7,8 @@ description: Fallback ultra-compressed communication mode. Cuts token usage ~75%
 Respond terse like smart caveman. All technical substance stay. Only fluff die.
 
 ## Persistence
+> **HARD GATE** — **HARD GATE** — Terse mode is for reducing token usage in long sessions. Do NOT use terse mode when clarity is critical (complex design decisions, bug investigations). Enable it only on explicit user request.
+
 
 ACTIVE EVERY RESPONSE once triggered. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop" or "normal mode".
 

package/using-bigpowers/SKILL.md

@@ -5,6 +5,8 @@ description: One-time bootstrap that introduces the bigpowers skills system, the
 ---
 
 # Using bigpowers
+> **HARD GATE** — **HARD GATE** — This skill is the entry point. Do NOT skip it when onboarding new users or starting a new session. It establishes the bigpowers methodology, lifecycle phases, and conventions.
+
 
 Welcome to **bigpowers** — a lifecycle of **61** agent skills for production-ready, TDD-driven software by solo developers.
 
@@ -25,6 +27,8 @@ A curated set of skills organized around the PMBOK developer lifecycle. Each ski
 
 ## The lifecycle at a glance
 
+See orchestrate-project for the canonical 6-phase lifecycle.
+
 ```
 BOOTSTRAP   using-bigpowers (this skill, first time only)
               ↓

package/validate-fix/SKILL.md

@@ -5,6 +5,8 @@ description: Prove a fix works before declaring done — re-run the failing test
 ---
 
 # Validate Fix
+> **HARD GATE** — **HARD GATE** — Fix must not regress. Run full test suite and manual UAT before declaring success. A fix that passes tests but breaks something else is a failure.
+
 
 Prove the fix works. "I think it works" is not evidence. Run the suite, show the output, then harden against recurrence.
 

package/verify-work/SKILL.md

@@ -12,6 +12,11 @@ model: haiku
 
 Review answers "is the code good?"; Verify answers "does the built thing do what was promised?"
 
+## Modes
+
+- Default: full UAT plus gaps loop
+- --smoke: Cold-start only plus one happy-path flow. Use for hotfixes.
+
 ## Process
 
 0. **Branch check** — must not be `main`/`master`.
@@ -22,6 +27,29 @@ Review answers "is the code good?"; Verify answers "does the built thing do what
 4. **Step-by-step UAT** — one user-observable action at a time.
 5. **Gaps loop** — failures → log → `plan-work` → re-verify.
 
+## Verify sub-operations
+
+### Cold-Start Smoke (absorbed)
+
+For applications, verify correctness from a clean state:
+
+- Stop the running server (if any)
+- Clear any caches (browser, application caches, compiled artifacts)
+- Boot the application from scratch
+- Verify that no stale artifacts or configuration are affecting the behavior
+
+This catches environment-specific bugs and ensures the build is reproducible.
+
+### Gaps Loop (absorbed)
+
+After UAT, identify and close any gaps between promised behavior and actual behavior:
+
+- Capture what was promised in the epic task description
+- Document what actually happened (expected vs actual)
+- If behavior doesn't match the promises, log the gap
+- Loop back to `plan-work` or `develop-tdd` to fix the gap
+- Re-verify until all gaps are closed (gaps count = 0)
+
 ## UAT dialogue
 
 - Pass: user confirms per step.
@@ -32,3 +60,8 @@ Review answers "is the code good?"; Verify answers "does the built thing do what
 → verify: `grep -c 'verify:' specs/epics/*.yaml | awk '{if($1>0) print "OK"; else print "MISSING"}'`
 
 See [REFERENCE.md](REFERENCE.md) for cold-start and gaps template.
+
+## Handoff
+
+Gate: READY -> next: audit-code
+Writes: state.yaml handoff.next_skill = audit-code

package/visual-dashboard/SKILL.md

@@ -5,6 +5,8 @@ description: Start a browser-based dashboard that visualizes architecture, imple
 ---
 
 # Visual Dashboard
+> **HARD GATE** — **HARD GATE** — Dashboards are read-only. Do NOT use visualization to make decisions without consulting the source data. 'The chart looks better' is not a decision.
+
 
 Browser-based visual companion for bigpowers. Visualizes architecture, plans, and status.
 

package/wire-observability/SKILL.md

@@ -5,6 +5,8 @@ description: Add structured JSON logging, observability commands, and idempotent
 ---
 
 # Wire Observability
+> **HARD GATE** — **HARD GATE** — Observability is not optional. Before shipping, verify: structured logging is in place, key metrics are instrumented, error cases emit signals. 'We'll add metrics later' becomes 'never.'
+
 
 Add structured logging, observability commands, and idempotent setup scripts. Can be invoked at any phase — recommended at the end of the first working slice, before the first deploy.