@skilly-hand/skilly-hand 0.7.0 → 0.8.1

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": []
+}

package/catalog/skills/test-driven-development/SKILL.md

@@ -0,0 +1,159 @@
+# Test-Driven Development Guide
+
+## When to Use
+
+Use this skill when:
+
+- Implementing a new feature, service, component, or function from scratch.
+- Adding behavior to existing code where the expected outcome can be defined upfront.
+- Debugging a regression by writing a failing test that reproduces the bug first.
+- Reviewing or pair-programming on code where test-first discipline is required.
+
+Do not use this skill for:
+
+- Exploratory prototyping where requirements are entirely undefined.
+- Snapshot or visual regression tests driven by existing UI.
+- Infrastructure or environment setup with no testable behavior.
+
+---
+
+## Critical Patterns
+
+### Pattern 1: RED First, Always
+
+Write a failing test before writing any implementation code. This proves:
+
+- The test is meaningful (not passing by accident).
+- The feature is actually needed.
+- You understand the requirements before touching implementation.
+
+Never write implementation code without a failing test that demands it.
+
+### Pattern 2: Minimum Code to GREEN
+
+Write the **smallest possible code** to make the test pass:
+
+- No extra features beyond what the test requires.
+- No premature optimization or defensive handling.
+- No "while I'm here, let me add…" additions.
+
+The goal is to satisfy the test, nothing more.
+
+### Pattern 3: REFACTOR With Tests GREEN
+
+Only improve code structure **after** all tests pass:
+
+- Extract constants, improve naming, simplify logic.
+- Tests must stay green throughout every refactoring step.
+- If a refactor breaks a test, revert — the refactor was wrong.
+
+### Pattern 4: One Scenario Per Test
+
+Each test must validate exactly one behavior:
+
+- Use explicit GIVEN / WHEN / THEN structure in test bodies.
+- A test name should complete the sentence: *"it should ___"*.
+- If a test asserts two behaviors, split it into two tests.
+
+---
+
+## Decision Tree
+
+```text
+Starting a new feature or function?          -> Write failing test first (RED)
+Test is failing as expected?                 -> Write minimum code to pass (GREEN)
+Test is passing?                             -> Improve code structure without changing behavior (REFACTOR)
+Refactor broke a test?                       -> Revert — refactor introduced a behavior change
+Test is already passing before writing code? -> Test is not meaningful; redesign it
+Fixing a bug?                                -> Write failing test that reproduces the bug first
+```
+
+---
+
+## Code Examples
+
+### Example 1: GIVEN / WHEN / THEN Structure
+
+```typescript
+it('should return the sum of two numbers', () => {
+  // GIVEN: Two positive integers
+  const a = 3;
+  const b = 4;
+
+  // WHEN: Sum is computed
+  const result = add(a, b);
+
+  // THEN: Result equals their sum
+  expect(result).toBe(7);
+});
+```
+
+### Example 2: RED — Write Failing Test First
+
+```typescript
+// calculator.test.ts
+import { divide } from './calculator';
+
+it('should throw when dividing by zero', () => {
+  // GIVEN / WHEN / THEN
+  expect(() => divide(10, 0)).toThrow('Cannot divide by zero');
+});
+```
+
+Run the test — it **must** fail before writing any implementation.
+
+### Example 3: GREEN — Write Minimum Implementation
+
+```typescript
+// calculator.ts
+export function divide(a: number, b: number): number {
+  if (b === 0) throw new Error('Cannot divide by zero');
+  return a / b;
+}
+```
+
+Run the test — it should now pass. No additional logic yet.
+
+### Example 4: REFACTOR — Improve Without Changing Behavior
+
+```typescript
+// calculator.ts (refactored)
+const DIVIDE_BY_ZERO_MESSAGE = 'Cannot divide by zero';
+
+export function divide(numerator: number, denominator: number): number {
+  if (denominator === 0) throw new Error(DIVIDE_BY_ZERO_MESSAGE);
+  return numerator / denominator;
+}
+```
+
+Run the test — it must still pass after renaming and extracting the constant.
+
+---
+
+## Commands
+
+```bash
+# Run a single test file
+npm test -- {test-file}
+
+# Run all tests
+npm test
+
+# Run tests in watch mode
+npm test -- --watch
+
+# Type check without emitting
+npx tsc --noEmit
+
+# Lint check
+npm run lint
+
+# Full verify (tests + lint + type check + build)
+npm test && npm run lint && npx tsc --noEmit && npm run build
+```
+
+---
+
+## Resources
+
+- Full cycle examples with Angular: [assets/tdd-cycle.md](assets/tdd-cycle.md)