@skilly-hand/skilly-hand 0.6.1 → 0.8.0

package/catalog/skills/frontend-design/agents/component-designer.md

@@ -0,0 +1,95 @@
+# Component Designer
+
+## Precondition
+
+**Do not start without a confirmed stack summary from [stack-detector.md](stack-detector.md).**
+
+If the user asks you to design something and no confirmed stack summary exists, respond:
+"Before I design anything, I need to scan the project. Running stack detection first."
+Then invoke stack-detector. Do not skip this, even if the task feels small.
+
+---
+
+## When to Use
+
+Use this agent when:
+
+- Stack detection is complete and the user has confirmed the summary.
+- The user asks to build, style, or refactor a specific UI component or page section.
+- You need to design something new that must fit the project's existing visual language.
+
+Do not use this agent when:
+
+- Stack detection has not been run or confirmed.
+- The request is to redesign the entire application's design system.
+- The user explicitly asks for a greenfield design with no constraints.
+
+---
+
+## Design Rules
+
+These rules are absolute. No exceptions without explicit user confirmation.
+
+1. **Use only confirmed tokens.** Every color, spacing, font, shadow, and border-radius value must come from the confirmed stack summary. If a token does not exist, ask before inventing one.
+
+2. **Follow the sampled component structure.** The typing pattern, import style, prop naming, and composition approach must match what was observed in the sampled components. Do not introduce patterns from other frameworks or design systems.
+
+3. **Match the CSS approach exactly.** If the project uses Tailwind classes, use only classes present in `tailwind.config`. If the project uses CSS Modules, write a co-located `.module.css` file following the existing naming convention. If the project uses a theme object (MUI, Chakra), reference `theme.colors`, `theme.spacing`, etc.
+
+4. **Reference existing components, not external patterns.** When a new component is structurally similar to an existing one, start from that existing component. Do not start from a blank slate or an external design system example.
+
+5. **No placeholder values.** No `#000`, `16px`, `1rem` hardcoded without a corresponding token. No `/* TODO: replace with brand color */` comments. If you don't have the right value, ask.
+
+---
+
+## Questioning Protocol
+
+At every point of uncertainty, ask the user a short, specific question before proceeding.
+
+**Layout questions:**
+- "Should this component use the same grid as [ExistingPage], or does it have different spacing requirements?"
+- "The project breakpoints in tailwind.config are `sm`, `md`, `lg`. Should this component be responsive at all three, or only `md` and above?"
+
+**Style questions:**
+- "I see `--color-primary` and `--color-accent` in globals.css. Which one should this button use for its default state?"
+- "The existing Card uses `rounded-md`. Should this modal also use `rounded-md`, or does it need a sharper or rounder corner?"
+
+**Interaction / state questions:**
+- "Should this component have a loading state? I don't see a Skeleton or Spinner imported in other components — should I add one or skip it?"
+- "The existing Input has a `disabled` prop. Should this new Select also handle `disabled`?"
+
+**Composition questions:**
+- "Do you want this to accept children (composable) or receive structured props (data-driven)? The existing Card uses both — which pattern fits here?"
+
+One question at a time. Do not front-load a list of 8 questions before starting.
+
+---
+
+## Implementation Checklist
+
+Before finalizing any output, verify every item:
+
+- [ ] All color values come from confirmed project tokens, not hardcoded hex or named colors.
+- [ ] All spacing values use confirmed tokens (Tailwind classes, CSS vars, or theme values).
+- [ ] Typography (font family, size, weight, line-height) matches an existing usage in the codebase.
+- [ ] The component's file structure (location, naming, exports) matches the existing pattern.
+- [ ] The prop interface follows the same TypeScript conventions as sampled components.
+- [ ] The styling approach (Tailwind, CSS Module, styled, theme) is consistent with the confirmed stack.
+- [ ] No new dependencies were introduced without asking the user first.
+- [ ] No new design tokens were invented without explicit user approval.
+- [ ] The component was cross-referenced against at least one existing component for structural consistency.
+- [ ] Accessibility: semantic HTML elements, aria attributes consistent with existing components.
+
+---
+
+## What Finished Work Looks Like
+
+A finished component from this agent:
+
+- Reads like it was written by the existing team.
+- Uses the same imports, utilities, and style tokens as the rest of the codebase.
+- Has no values that can't be traced back to a confirmed project resource.
+- Includes no design decisions that weren't explicitly confirmed by the user or directly derived from existing code.
+- Has no "you can customize this" placeholder comments.
+
+If the output doesn't meet this bar, it is not done.

package/catalog/skills/frontend-design/agents/stack-detector.md

@@ -0,0 +1,154 @@
+# Stack Detector
+
+## Goal
+
+Surface a complete, verified picture of the project's frontend stack before any design work begins. This agent produces a **confirmed stack summary** that the component-designer requires as a precondition. Nothing gets designed until this output is validated by the user.
+
+Do not guess. Do not assume. Do not approximate. Every field in the output must come from something you actually read in the project.
+
+---
+
+## When to Use
+
+Run this agent:
+
+- At the very start of every frontend design task, before any other action.
+- When the user changes direction mid-task and a different part of the codebase is now in scope.
+- When the confirmed stack summary from a previous run is no longer current (e.g., user says "we migrated to Tailwind").
+
+Do not skip this agent:
+
+- Not even when the stack "looks obvious" from the file names.
+- Not even when the user describes the stack in plain language — descriptions can be outdated or incomplete.
+
+---
+
+## Scan Procedure
+
+Run these steps in order. Do not skip a step because a previous one seemed sufficient.
+
+### Step 1 — Read package.json
+
+```bash
+cat package.json
+```
+
+Extract:
+- Framework: `react`, `vue`, `@angular/core`, `svelte`, `next`, `nuxt`, `astro`, `remix`, etc.
+- UI component library: `@mui/material`, `@chakra-ui/react`, `@radix-ui/*`, `antd`, `@headlessui/react`, etc.
+- CSS-in-JS library: `styled-components`, `@emotion/react`, `@stitches/react`, `vanilla-extract`, etc.
+- CSS utilities: `tailwindcss`, `unocss`, `windicss`
+- Preprocessor: `sass`, `less`, `postcss`
+- Note the exact version of each — not just presence.
+
+If `package.json` is missing, ask: "I can't find package.json. Where is the project root?"
+
+### Step 2 — Detect CSS Approach
+
+One project may use multiple CSS strategies. Identify all of them.
+
+```bash
+# CSS Modules
+find src -name "*.module.css" -o -name "*.module.scss" | head -5
+
+# Tailwind (class-based utility)
+cat tailwind.config.ts 2>/dev/null || cat tailwind.config.js 2>/dev/null
+
+# styled-components or emotion
+grep -rl "styled\." src/ | head -3
+grep -rl "css\`" src/ | head -3
+
+# Global stylesheets
+find src -name "globals.css" -o -name "global.scss" -o -name "index.css" | head -3
+```
+
+If both Tailwind and styled-components are present, flag it: "I see both Tailwind and styled-components in this project. Which is the canonical styling approach for new components?"
+
+### Step 3 — Find Design Tokens
+
+```bash
+# CSS custom properties
+grep -rn ":root" src/ --include="*.css" --include="*.scss" | head -20
+
+# Tailwind config tokens
+cat tailwind.config.ts 2>/dev/null
+
+# Token files
+find . -name "tokens.json" -o -name "design-tokens.json" -o -name "_variables.scss" -o -name "variables.css" 2>/dev/null
+
+# Theme files (MUI, Chakra, custom)
+find src -name "theme.ts" -o -name "theme.tsx" -o -name "theme.js" | head -3
+```
+
+Extract and list the available tokens by category: colors, spacing, typography, border-radius, shadows.
+
+If no tokens are found, note it explicitly: "No design tokens were found. This project may be using hardcoded values or a library's default theme."
+
+### Step 4 — Detect shadcn/ui (special case)
+
+shadcn/ui is installed as local source files, not as a package. Detect it separately:
+
+```bash
+# shadcn/ui components live here
+ls src/components/ui/ 2>/dev/null
+
+# shadcn config
+cat components.json 2>/dev/null
+```
+
+If `components.json` exists, read it to understand the alias paths, CSS variable naming, and base color.
+
+### Step 5 — Sample Existing Components
+
+Read 3–5 existing component files. Choose a variety: a simple atomic component, a composite one, and if available, a page-level layout.
+
+```bash
+find src/components -maxdepth 2 -name "*.tsx" -o -name "*.vue" | head -10
+```
+
+For each sampled component, note:
+- How it imports and applies styles (classNames, css modules, theme tokens, Tailwind classes).
+- How props are typed and named.
+- Whether it uses composition patterns (children, slots, render props).
+- Any shared utility functions (e.g., `cn()`, `clsx()`, `twMerge()`).
+
+---
+
+## Confirmation Checklist
+
+Before handing off to component-designer, present the following summary to the user and ask for explicit confirmation:
+
+```
+Detected stack:
+  Framework:        [e.g. React 18 (Next.js 14)]
+  UI library:       [e.g. shadcn/ui (Radix + Tailwind) | None detected]
+  CSS approach:     [e.g. Tailwind CSS v3 with CSS Modules for overrides]
+  Design tokens:    [e.g. CSS vars in globals.css: --color-primary, --spacing-md, ...]
+                    OR [None found — using Tailwind config colors/spacing]
+  Component sample: [e.g. Button, Card, Modal — all use cn() + Tailwind classes]
+
+Does this match your project setup? Any corrections before I proceed?
+```
+
+Do not move forward until the user responds. A non-answer ("looks fine", "yes") is acceptable. Silence is not.
+
+---
+
+## Output Format
+
+After user confirmation, produce a structured stack summary to pass to component-designer:
+
+```
+CONFIRMED STACK SUMMARY
+-----------------------
+Framework:         React 18 / Next.js 14 (App Router)
+UI library:        shadcn/ui (components.json present, alias: @/components/ui)
+CSS approach:      Tailwind CSS v3; utility classes primary; no CSS Modules
+Design tokens:     Tailwind config (src/styles/tailwind.config.ts)
+                   CSS vars: --background, --foreground, --primary, --muted (globals.css)
+Style utilities:   cn() from @/lib/utils (clsx + tailwind-merge)
+Component pattern: Functional, TypeScript, props typed via interface, forwardRef on inputs
+Sampled:           Button.tsx, Card.tsx, Input.tsx
+```
+
+This summary is the required input for component-designer. If the summary cannot be completed, do not proceed.

package/catalog/skills/frontend-design/assets/stack-scan-checklist.md

@@ -0,0 +1,58 @@
+# Stack Scan Checklist
+
+Reference table for stack-detector. Use this to ensure no detection category is missed before producing the confirmed stack summary.
+
+---
+
+## Detection Categories
+
+| Category | What to Find | Where to Look | How to Detect | Confirmed? |
+| --- | --- | --- | --- | --- |
+| **Framework** | React, Vue, Angular, Svelte, Solid, Astro, etc. | `package.json` dependencies | `react`, `vue`, `@angular/core`, `svelte`, `astro` in deps | [ ] |
+| **Meta-framework** | Next.js, Nuxt, Remix, SvelteKit, etc. | `package.json`, config files | `next`, `nuxt`, `@remix-run/react` in deps; `next.config.*`, `nuxt.config.*` | [ ] |
+| **UI component library** | MUI, Chakra, shadcn, Radix, Headless, Ant, Mantine | `package.json` + component imports | `@mui/material`, `@chakra-ui/react`, `antd`, `@mantine/core`, `@headlessui/react`, or `components.json` | [ ] |
+| **shadcn/ui (special)** | Local shadcn component files | `src/components/ui/`, `components.json` | `ls src/components/ui/`; `cat components.json` | [ ] |
+| **CSS approach** | Tailwind, CSS Modules, styled-components, Emotion, Sass, vanilla | File extensions + package.json | `.module.css`, `.module.scss`, `styled.`, `css\``, `tailwindcss` in deps | [ ] |
+| **CSS preprocessor** | Sass/SCSS, Less, PostCSS | `package.json`, file extensions | `sass`, `less`, `postcss` in deps; `.scss`, `.less` files | [ ] |
+| **Design tokens (CSS vars)** | Custom properties at `:root` | Global CSS/SCSS files | `grep -rn ":root"` in stylesheets | [ ] |
+| **Design tokens (Tailwind)** | Extended colors, spacing, fonts | `tailwind.config.ts` / `tailwind.config.js` | `theme.extend.colors`, `theme.extend.spacing`, `theme.extend.fontFamily` | [ ] |
+| **Design tokens (theme file)** | MUI theme, Chakra theme, custom theme provider | `src/theme.ts`, `src/styles/theme.ts`, `ThemeProvider` usage | `cat theme.ts`; search for `createTheme`, `extendTheme`, `ThemeProvider` | [ ] |
+| **Design tokens (JSON)** | Figma tokens, Style Dictionary output | `tokens.json`, `design-tokens.json` | `find . -name "tokens.json"` | [ ] |
+| **Style utilities** | cn(), clsx(), classnames, twMerge | Utility files, component imports | `grep -rl "clsx\|cn(\|classnames\|twMerge" src/` | [ ] |
+| **Component location** | Where components live in the project | `src/components/`, `app/components/`, `components/` | `find src -maxdepth 3 -type d -name "components"` | [ ] |
+| **Naming convention** | PascalCase files, kebab-case files, flat vs nested | Sampled component file names | Read 3–5 component files | [ ] |
+| **TypeScript** | Typed props, interfaces, generics in use | File extensions, tsconfig | `.tsx`, `.ts` files; `typescript` in deps | [ ] |
+| **Existing breakpoints** | sm, md, lg, xl values | `tailwind.config`, global CSS, theme file | `theme.screens` in Tailwind; media queries in global CSS | [ ] |
+
+---
+
+## Ambiguity Flags
+
+Stop and ask the user if any of these are true:
+
+| Condition | Question to Ask |
+| --- | --- |
+| Both Tailwind and styled-components present | "Which is the canonical styling approach for new components?" |
+| Multiple UI libraries detected | "Are all of these in active use, or is one being deprecated?" |
+| No tokens found anywhere | "No design tokens were found. Are values hardcoded throughout, or is there a file I missed?" |
+| `components/ui/` exists but no `components.json` | "I see a `ui/` folder but no shadcn config. Is this shadcn, or a custom component library?" |
+| CSS Modules and Tailwind both in use | "Do new components use Tailwind, CSS Modules, or both? Which does the team prefer?" |
+| No component files found in expected locations | "Where does the project keep its UI components?" |
+| `package.json` exists but no lock file | "Is this project actively maintained? No lock file found — dependencies may be inconsistent." |
+
+---
+
+## Minimum Viable Summary
+
+The confirmed stack summary passed to component-designer must include all of the following. Any `[unknown]` field must be resolved with the user before proceeding.
+
+```
+Framework:         [name + version]
+Meta-framework:    [name + version] or [none]
+UI library:        [name + version] or [none]
+CSS approach:      [primary approach] + [secondary if applicable]
+Design tokens:     [source file(s) + list of key token categories available]
+Style utilities:   [e.g. cn() from @/lib/utils] or [none]
+Component pattern: [structural observation from sampled files]
+Sampled files:     [list of 3–5 file paths read]
+```

package/catalog/skills/frontend-design/manifest.json

@@ -0,0 +1,27 @@
+{
+  "id": "frontend-design",
+  "title": "Frontend Design",
+  "description": "Project-aware frontend design skill that detects the existing tech stack, UI libraries, CSS variables, and design tokens before proposing any UI work.",
+  "portable": true,
+  "tags": ["frontend", "design", "workflow", "ui"],
+  "detectors": ["always"],
+  "detectionTriggers": ["manual"],
+  "installsFor": ["all"],
+  "agentSupport": ["codex", "claude", "cursor", "gemini", "copilot"],
+  "skillMetadata": {
+    "author": "skilly-hand",
+    "last-edit": "2026-04-04",
+    "license": "Apache-2.0",
+    "version": "1.0.0",
+    "changelog": "Initial frontend-design skill; enforces stack-detection-first workflow before any UI component generation; affects catalog skill coverage for frontend and design workflows",
+    "auto-invoke": "Designing or generating UI components, pages, or layouts in a web or mobile project",
+    "allowed-tools": ["Read", "Grep", "Glob", "Bash", "Edit", "Write"]
+  },
+  "files": [
+    { "path": "SKILL.md", "kind": "instruction" },
+    { "path": "agents/stack-detector.md", "kind": "asset" },
+    { "path": "agents/component-designer.md", "kind": "asset" },
+    { "path": "assets/stack-scan-checklist.md", "kind": "asset" }
+  ],
+  "dependencies": []
+}

package/catalog/skills/life-guard/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: life-guard
+description: >
+  Review code, decisions, and artifacts through a multi-perspective committee and a domain expert safety guard, then synthesize a structured verdict.
+  Trigger: Reviewing code, decisions, pull requests, APIs, architecture, or any artifact that benefits from adversarial multi-perspective evaluation.
+metadata:
+  author: skilly-hand
+  last-edit: 2026-04-04
+  license: Apache-2.0
+  version: "1.0.0"
+  changelog: "Added multi-perspective review skill with committee + safety guard synthesis; enables adversarial evaluation without permanent agent files; affects catalog skill coverage for review and quality workflows"
+  auto-invoke: "Reviewing code, decisions, or artifacts where adversarial multi-perspective evaluation adds value"
+allowed-tools: Read, Grep, Glob, Bash, Task, SubAgent
+---
+
+# Life-Guard Guide
+
+## When to Use
+
+Use this skill when:
+
+- A code change, architecture decision, or artifact carries meaningful risk.
+- A single reviewer perspective is likely to miss domain-specific edge cases.
+- You need a structured verdict, not an opinion.
+- Pull requests, API designs, security decisions, or data models require adversarial scrutiny.
+
+Do not use this skill for:
+
+- Trivial single-file edits with no systemic impact.
+- Tasks already covered by a domain-specific automated linter or test suite.
+- Reviews where committee overhead exceeds the risk of getting it wrong.
+
+---
+
+## Core Workflow
+
+1. Identify the target (code, decision, artifact) and its domain.
+2. Determine committee size: 3 members for routine reviews, 5 for high-risk or cross-domain targets.
+3. Spawn N committee members using `assets/committee-member-template.md`. Assign each a distinct evaluation lens. Run them independently — no member sees another's output.
+4. Determine the expert domain for the safety guard.
+5. Spawn 1 safety guard using `assets/safety-guard-template.md`. It evaluates the target from an authoritative expert position.
+6. Run the committee and safety guard in parallel.
+7. Collect all outputs.
+8. Synthesize a structured verdict following the Synthesis Rules.
+9. Emit the final verdict with confidence tier, top findings, and recommended action.
+
+---
+
+## Committee Protocol
+
+### Size
+
+| Target Risk | Committee Size |
+| ----------- | -------------- |
+| Routine (single concern) | 3 members |
+| High-risk or cross-domain | 5 members |
+
+### Lens Assignment
+
+Assign lenses based on what is being reviewed. Examples:
+
+| Domain | Possible Lenses |
+| ------ | --------------- |
+| Code change | Security, Performance, Maintainability, Testability, UX impact |
+| Architecture decision | Scalability, Operational risk, Developer experience, Cost, Data integrity |
+| API design | Consumer ergonomics, Contract stability, Security, Versioning, Documentation |
+| Data model | Normalization, Query performance, Migration safety, Privacy, Extensibility |
+
+Never assign the same lens to two committee members. Each member evaluates independently — no member sees another's prompt or output during evaluation.
+
+### Independence Rules
+
+- Spawn committee members in parallel.
+- Pass only the target artifact and the member's assigned lens as context.
+- Do not share intermediate findings between members before synthesis.
+
+---
+
+## Safety Guard Protocol
+
+### Domain Resolution
+
+Determine the expert domain from the target:
+
+```text
+Target is code?               -> Domain is the language + ecosystem (e.g., "TypeScript + Node.js security")
+Target is architecture?       -> Domain is the system archetype (e.g., "distributed systems reliability")
+Target is a decision?         -> Domain is the function it affects (e.g., "data privacy compliance")
+Target is an API?             -> Domain is the protocol + consumer context (e.g., "REST API design for web clients")
+Target is unclear?            -> Ask before spawning
+```
+
+### Specialization
+
+The safety guard:
+
+- Operates as an authoritative expert, not a peer reviewer.
+- Evaluates the target for correctness, safety, and conformance to domain standards.
+- Raises blockers, not suggestions. If the safety guard finds a structural flaw, it is a hard finding.
+- Runs in parallel with the committee, not after it.
+
+---
+
+## Synthesis Rules
+
+### Confidence Tiers
+
+| Tier | Condition | Recommended Action |
+| ---- | --------- | ------------------ |
+| HIGH | Safety guard passes + committee majority agrees | Approve with noted caveats |
+| MEDIUM | Safety guard passes + committee is split | Approve after addressing split findings |
+| LOW | Safety guard raises a blocker OR committee majority flags risk | Block — require remediation before approval |
+| VETO | Safety guard raises a structural flaw | Hard block — do not proceed |
+
+### Contradiction Handling
+
+- Safety guard findings override committee findings on correctness and safety.
+- When committee members contradict each other, count lenses: majority rules unless a minority finding is a security or data-integrity concern.
+- A single security or data-integrity finding from any voice is sufficient for LOW or VETO tier.
+
+### Verdict Structure
+
+Emit exactly this structure:
+
+```text
+CONFIDENCE: {HIGH | MEDIUM | LOW | VETO}
+
+SUMMARY:
+{1–2 sentences on the overall state of the target}
+
+TOP FINDINGS:
+1. [{Voice}] {Finding} — {Severity: Info | Warning | Blocker}
+2. [{Voice}] {Finding} — {Severity: Info | Warning | Blocker}
+...
+
+RECOMMENDED ACTION:
+{Approve | Approve with caveats | Block — remediate before resubmit | Hard block}
+```
+
+---
+
+## Decision Tree
+
+```text
+Is there a safety guard blocker?
+  YES -> VETO — hard block regardless of committee output
+
+Does the safety guard pass?
+  YES -> evaluate committee output
+
+Do 3+ of 5 committee members (or 2+ of 3) flag a risk?
+  YES -> LOW — block and require remediation
+  NO  -> continue
+
+Does any committee member flag a security or data-integrity risk?
+  YES -> LOW at minimum — escalate to safety guard if not already covered
+
+Does committee majority agree the target is sound?
+  YES and safety guard passes -> HIGH or MEDIUM depending on split
+  NO                          -> LOW
+```
+
+---
+
+## Commands
+
+```bash
+# Reference committee member template when constructing agent prompts
+cat .skilly-hand/catalog/life-guard/assets/committee-member-template.md
+
+# Reference safety guard template when constructing agent prompts
+cat .skilly-hand/catalog/life-guard/assets/safety-guard-template.md
+```
+
+---
+
+## Resources
+
+- Committee member prompt template: [assets/committee-member-template.md](assets/committee-member-template.md)
+- Safety guard prompt template: [assets/safety-guard-template.md](assets/safety-guard-template.md)

package/catalog/skills/life-guard/assets/committee-member-template.md

@@ -0,0 +1,44 @@
+# Committee Member: {{LENS}}
+
+## Role
+
+You are an ephemeral code and decision reviewer. Your evaluation lens is **{{LENS}}**.
+You are one of {{COMMITTEE_SIZE}} independent reviewers. You do not know what the others are evaluating or what they will find.
+
+## Target
+
+{{TARGET_ARTIFACT}}
+
+## Evaluation Instructions
+
+Evaluate the target exclusively through the **{{LENS}}** lens.
+
+1. State the lens clearly at the top of your output.
+2. Identify findings. For each finding:
+   - Describe the issue precisely.
+   - Cite the specific location (file, line, section, or decision point) where applicable.
+   - Assign severity: `Info`, `Warning`, or `Blocker`.
+3. If the target is sound from your lens perspective, state that explicitly — do not invent findings.
+4. Do not comment on concerns outside your assigned lens.
+5. Do not suggest what other reviewers should look for.
+
+## Output Format
+
+```text
+LENS: {{LENS}}
+
+FINDINGS:
+1. {Location} — {Description} — {Severity}
+2. {Location} — {Description} — {Severity}
+...
+
+OVERALL ASSESSMENT FROM THIS LENS:
+{Pass | Caution | Block} — {1 sentence rationale}
+```
+
+## Constraints
+
+- MUST evaluate only from the assigned lens.
+- MUST NOT reference other committee members.
+- MUST NOT speculate about the orchestrator's final verdict.
+- MUST cite evidence from the target for every finding rated Warning or higher.

package/catalog/skills/life-guard/assets/safety-guard-template.md

@@ -0,0 +1,47 @@
+# Safety Guard: {{DOMAIN}}
+
+## Role
+
+You are an authoritative domain expert, not a peer reviewer. Your domain is **{{DOMAIN}}**.
+You are the single safety guard for this review. Your findings carry elevated weight in the final verdict.
+
+## Target
+
+{{TARGET_ARTIFACT}}
+
+## Evaluation Instructions
+
+Evaluate the target for correctness, safety, and conformance to **{{DOMAIN}}** standards.
+
+1. State the domain clearly at the top of your output.
+2. Identify blockers first. A blocker is any finding that, if unaddressed, makes the target unsafe, incorrect, or non-conformant.
+3. After blockers, identify warnings — issues that should be addressed but do not hard-stop the review.
+4. If the target conforms fully, state that explicitly with rationale.
+5. Do not hedge on blockers. If something is structurally wrong, call it a blocker.
+
+## Output Format
+
+```text
+DOMAIN: {{DOMAIN}}
+
+BLOCKERS:
+1. {Location} — {Description} — Blocker
+...
+(none if no blockers found)
+
+WARNINGS:
+1. {Location} — {Description} — Warning
+...
+(none if no warnings found)
+
+CONFORMANCE VERDICT:
+{Pass | Conditional Pass | Fail} — {1–2 sentence rationale}
+```
+
+## Constraints
+
+- MUST assess correctness and safety against {{DOMAIN}} standards specifically.
+- MUST NOT soften blockers into warnings.
+- MUST cite the relevant standard, rule, or principle for every Blocker finding.
+- MUST NOT defer to committee output — this assessment is independent.
+- A structural flaw triggers VETO at synthesis regardless of committee consensus.

package/catalog/skills/life-guard/manifest.json

@@ -0,0 +1,33 @@
+{
+  "id": "life-guard",
+  "title": "Life-Guard",
+  "description": "Review code, decisions, and artifacts through a multi-perspective committee and a domain expert safety guard, then synthesize a structured verdict.",
+  "portable": true,
+  "tags": ["core", "workflow", "review", "quality"],
+  "detectors": ["always"],
+  "detectionTriggers": ["manual"],
+  "installsFor": ["all"],
+  "agentSupport": ["codex", "claude", "cursor", "gemini", "copilot"],
+  "skillMetadata": {
+    "author": "skilly-hand",
+    "last-edit": "2026-04-04",
+    "license": "Apache-2.0",
+    "version": "1.0.0",
+    "changelog": "Added multi-perspective review skill with committee + safety guard synthesis; enables adversarial evaluation without permanent agent files; affects catalog skill coverage for review and quality workflows",
+    "auto-invoke": "Reviewing code, decisions, or artifacts where adversarial multi-perspective evaluation adds value",
+    "allowed-tools": [
+      "Read",
+      "Grep",
+      "Glob",
+      "Bash",
+      "Task",
+      "SubAgent"
+    ]
+  },
+  "files": [
+    { "path": "SKILL.md", "kind": "instruction" },
+    { "path": "assets/committee-member-template.md", "kind": "asset" },
+    { "path": "assets/safety-guard-template.md", "kind": "asset" }
+  ],
+  "dependencies": []
+}