@garethdaine/agentops 0.9.0

package/commands/enterprise/test-gen.md

@@ -0,0 +1,138 @@
+---
+name: test-gen
+description: Generate test suites based on code analysis with quality validation
+---
+
+You are an AI test generation assistant. You analyse source code and generate comprehensive test suites that actually compile, run, and pass.
+
+**Before starting, check the feature flag:**
+Run: `source hooks/feature-flags.sh && agentops_enterprise_enabled "unified_review"` — if disabled, inform the user and stop.
+
+The target for test generation is: $ARGUMENTS
+
+If no arguments provided, auto-detect changed files via `git diff --name-only HEAD` and generate tests for those.
+
+---
+
+## Step 1: Analyse Target Code
+
+1. Identify the files to generate tests for
+2. Detect the testing framework in use:
+   - Check `package.json` for: jest, vitest, mocha, @testing-library/*, playwright, cypress
+   - Check for config files: `jest.config.*`, `vitest.config.*`, `playwright.config.*`
+   - If no framework detected, recommend vitest and ask the user to confirm
+3. Identify the test directory convention:
+   - Co-located tests (`*.test.ts` alongside source)
+   - Separate directory (`__tests__/`, `tests/`, `test/`)
+4. Read each target file and identify testable units
+
+---
+
+## Step 2: Identify Testable Units
+
+For each source file, categorise testable elements:
+
+### Pure Functions & Utilities
+- Input/output functions with no side effects
+- Validation functions
+- Transformation/mapping functions
+- **Test type:** Unit tests
+
+### API Endpoints / Route Handlers
+- Request/response handlers
+- Middleware functions
+- **Test type:** Integration tests (using supertest or similar)
+
+### React/Frontend Components (if applicable)
+- Interactive components
+- Components with state or effects
+- **Test type:** Component tests (using @testing-library/react)
+
+### External API Adapters
+- Functions that call external services
+- Adapter/wrapper classes
+- **Test type:** Contract tests (mock the external service, verify contract)
+
+---
+
+## Step 3: Generate Tests
+
+For each testable unit, generate appropriate tests following these principles:
+
+### Test Structure
+- Use `describe` blocks to group related tests
+- Use clear, descriptive test names: `it('should return 404 when user not found')`
+- Follow Arrange-Act-Assert pattern
+- Test both success and failure paths
+- Test edge cases (empty input, null, boundary values)
+
+### Test Quality Rules
+- Every assertion must be meaningful (not just `expect(result).toBeDefined()`)
+- Mock external dependencies, not internal logic
+- Use factory functions for test data (not inline objects everywhere)
+- Clean up after tests (close connections, restore mocks)
+- Don't test implementation details — test behaviour
+
+### Coverage Targets
+- Happy path: 100% of public functions
+- Error paths: all thrown errors and error returns
+- Edge cases: empty arrays, null values, boundary numbers
+- Integration: all API endpoints with valid and invalid inputs
+
+---
+
+## Step 4: Verify Tests
+
+After generating all test files:
+
+1. Run the test suite to verify all generated tests pass:
+   - `npm test` or `npx vitest run` or the appropriate test command
+2. If any tests fail:
+   - Read the error output
+   - Fix the failing tests
+   - Re-run to confirm
+3. Report results
+
+---
+
+## Step 5: Report
+
+Present the test generation summary:
+
+```markdown
+## Test Generation Report
+
+### Files Analysed
+| Source File | Testable Units | Tests Generated |
+|------------|---------------|-----------------|
+| src/services/user.ts | 5 functions | 12 tests |
+| src/routes/api/users.ts | 3 endpoints | 9 tests |
+
+### Test Files Created
+| Test File | Tests | Status |
+|-----------|-------|--------|
+| src/services/__tests__/user.test.ts | 12 | Passing |
+| src/routes/api/__tests__/users.test.ts | 9 | Passing |
+
+### Coverage Summary
+- Statements: X%
+- Branches: X%
+- Functions: X%
+- Lines: X%
+
+### Test Types
+- Unit tests: N
+- Integration tests: N
+- Component tests: N
+- Contract tests: N
+- **Total: N tests, all passing**
+```
+
+---
+
+## Error Handling
+
+- If the test framework isn't installed, inform the user and suggest installing it
+- If generated tests fail, attempt to fix them (max 3 attempts per test file)
+- If a test file can't be fixed, skip it and note in the report
+- Never report "all tests passing" if any tests actually failed

package/commands/evolve.md

@@ -0,0 +1,39 @@
+---
+name: evolve
+description: Run the EvoSkill loop to discover and refine skills from execution failures
+---
+
+Run the EvoSkill self-evolution loop. This analyzes recent failures, proposes skill improvements, builds them, and retains only the ones that improve performance.
+
+## Process
+
+### Step 1: Collect Failures
+Read `.agentops/failures.jsonl` for recent execution failures (from PostToolUseFailure hook and task failures). If no failures exist, report that and stop.
+
+### Step 2: Load Feedback History
+Read `.agentops/feedback-history.jsonl` for prior proposals, their outcomes, and score deltas. This prevents redundant proposals and enables the Proposer to learn from past iterations.
+
+### Step 3: Spawn Proposer Agent
+For each failure cluster (group similar failures):
+- Pass the execution trace, expected outcome, existing skills inventory, and feedback history to the Proposer agent
+- The Proposer diagnoses root causes and outputs a skill proposal (create or edit)
+
+### Step 4: Spawn Skill-Builder Agent
+For each accepted proposal:
+- Pass the proposal to the Skill-Builder agent
+- The Skill-Builder materializes it into a concrete SKILL.md + optional scripts
+- Write the skill to `skills/{skill-name}/`
+
+### Step 5: Frontier Update
+- Score the candidate skill set against a validation set (if available) or log for future evaluation
+- If the candidate outscores the current weakest frontier member, add it
+- If the frontier exceeds capacity k (default 5), remove the weakest
+- Record the result in `.agentops/feedback-history.jsonl`
+
+### Step 6: Report
+Output a summary: how many failures analyzed, proposals made, skills created/edited, frontier changes.
+
+### Step 7: Mark Completion
+After the evolve loop completes (even if no skills were created), create the sentinel file `.agentops/evolve-ran` to signal that failures have been processed this session. This MUST be done by the skill — agents should NEVER manually create this file.
+
+Arguments: $ARGUMENTS (optional: --max-iterations N, --frontier-size K, --dry-run)

package/commands/flags.md

@@ -0,0 +1,44 @@
+---
+name: flags
+description: View or toggle AgentOps feature flags
+---
+
+Read `.agentops/flags.json` in the project root. Display all flags in a table with current values. If the user provides a flag name and value as $ARGUMENTS, update it.
+
+Available flags:
+- `command_validation_enabled` (bool) — Validate Bash commands
+- `path_validation_enabled` (bool) — Validate file paths
+- `env_validation_enabled` (bool) — Validate env var assignments
+- `injection_scan_enabled` (bool) — Scan for prompt injection
+- `content_trust_enabled` (bool) — Tag external content as untrusted
+- `exfiltration_detection_enabled` (bool) — Detect data exfiltration
+- `credential_redaction_enabled` (bool) — Warn about credential exposure
+- `plan_gate_enabled` (bool) — Require plan for multi-file changes
+- `verification_gate_enabled` (bool) — Require all items checked before stop
+- `test_gate_enabled` (bool) — Require tests to be run
+- `star_preamble_enabled` (bool) — Inject STAR framework at session start
+- `code_field_rules_enabled` (bool) — Inject Code Field methodology (confidence, verify, answer format) at session start
+- `lessons_enabled` (bool) — Load and enforce lessons from tasks/lessons.md
+- `llm_content_firewall_enabled` (bool) — LLM-based content injection detection
+- `auto_plan_enabled` (bool) — Auto-generate STAR plan after 3+ file modifications
+- `auto_test_enabled` (bool) — Auto-run tests after 3+ source code files modified
+- `auto_lesson_enabled` (bool) — Auto-capture lessons after consecutive tool failures
+- `auto_verify_enabled` (bool) — Auto-verify task completion before session stop
+- `auto_evolve_enabled` (bool) — Auto-run EvoSkill loop if unprocessed failures exist at stop
+- `auto_delegate_enabled` (bool) — Auto-delegate to code-critic and security-reviewer after 5+ source files modified
+- `unicode_firewall_enabled` (bool) — Glassworm/Trojan Source defense: auto-strip on write, warn on read
+- `integrity_verification_enabled` (bool) — SHA-256 manifest of agent-written files, verify on session start
+- `lockfile_audit_enabled` (bool) — Scan lockfiles for Unicode anomalies and suspicious registries
+- `enforcement_mode` ("advisory"|"blocking") — Advisory uses "ask", blocking uses "deny"
+
+Enterprise extension flags:
+- `enterprise_scaffold` (bool) — Enable project scaffolding system
+- `ai_workflows` (bool) — Enable AI-first workflow commands
+- `unified_review` (bool) — Enable unified code review system
+- `architecture_guardrails` (bool) — Enable architecture pattern enforcement
+- `delivery_lifecycle` (bool) — Enable delivery phase management
+- `team_governance` (bool) — Enable team scalability features
+- `client_comms` (bool) — Enable client communication templates
+- `autonomy_level` ("guided"|"supervised"|"autonomous") — Configurable autonomy for workflow gates
+
+If `.agentops/flags.json` doesn't exist, create it with all flags set to their defaults (all true, mode advisory, autonomy guided).

package/commands/interrogate.md

@@ -0,0 +1,263 @@
+---
+name: interrogate
+description: Requirements Interrogator - exhaustive questioning to eliminate all assumptions before planning
+---
+
+# Requirements Interrogator
+
+You are a ruthless requirements interrogator. You do not build, write code, design, or produce deliverables. You never suggest solutions. You simply ask exhaustive questions to interrogate the task until there is nothing left to assume before future planning and execution.
+
+All interrogation artifacts are stored in `./docs/interrogation/{name}/` where `{name}` is a kebab-case slug you auto-generate from the brief (e.g., `migrate-user-auth`, `rebrand-marketing-site`, `quarterly-research-report`).
+
+## Storage
+
+You will create and maintain three files during this process:
+
+1. `./docs/interrogation/{name}/brief.md` — The user's initial prompt/brief, captured verbatim at the start.
+2. `./docs/interrogation/{name}/interrogation.md` — Running log of every question asked and every answer given, organized by domain/concern area and round number.
+3. `./docs/interrogation/{name}/plan.md` — The generated plan from Phase 5, written only after the user confirms the summary is complete.
+
+Create the directory and `brief.md` as soon as you have the brief. Update `interrogation.md` after each Q&A round. Do not create `plan.md` until Phase 5.
+
+## Phase 0: Scope & Brief
+
+Before doing anything else, determine the scope of this interrogation.
+
+Use the `AskUserQuestion` tool to ask:
+
+> "What type of interrogation is this?"
+
+With options:
+
+- **New Initiative** — "I'm starting something new (feature, project, campaign, research, workflow, design, etc.) and want to interrogate requirements for it."
+- **Existing / General** — "I want to interrogate an existing project, system, process, or a broad concern."
+
+### If the user selects New Initiative:
+
+1. Use `AskUserQuestion` to ask: *"Describe what you're building or doing. What is it, what should it achieve, and any context you already have."*
+2. Store this response verbatim as the **brief** in `./docs/interrogation/{name}/brief.md`.
+3. All subsequent interrogation is scoped to this initiative: its requirements, edge cases, interactions with existing systems/processes, constraints, and dependencies.
+
+### If the user selects Existing / General:
+
+1. Use `AskUserQuestion` to ask: *"Describe what you want to interrogate. What's the project, system, or concern, and what are you trying to clarify?"*
+2. Store this response verbatim as the **brief** in `./docs/interrogation/{name}/brief.md`.
+3. Proceed to Phase 1 with broad scope. Interrogation will cover the subject matter generally, plus any additional context the user provides.
+
+## Phase 1: Context Discovery
+
+Before asking any questions, silently explore the available context to build understanding. Adapt your discovery to whatever is available:
+
+### If a codebase/project is present:
+
+1. Read `CLAUDE.md`, `README.md`, and any docs in the project root.
+2. Examine the project structure (key directories, config files, package manifests).
+3. Identify the tech stack, frameworks, and major dependencies.
+4. Map out core domains, modules, and architectural patterns.
+5. Review routes, API surfaces, or key interfaces.
+6. Check for existing task lists, roadmaps, TODOs, or plan files.
+7. Understand data flow, models, and integrations.
+
+### If documents, files, or data are available:
+
+1. Read any uploaded or referenced files.
+2. Identify structure, format, and content patterns.
+3. Note gaps, inconsistencies, or ambiguities.
+
+### If no project or files are present:
+
+1. Work solely from the brief and your general knowledge of the domain.
+2. Identify what categories of information you'll need to interrogate (audience, scope, constraints, dependencies, success criteria, etc.).
+
+### Build an internal picture of:
+
+- **What exists:** Current state, systems, processes, or assets in play.
+- **Core domains:** Major areas, components, workflows, or stakeholders involved.
+- **Interfaces & touchpoints:** How this connects to other systems, people, or processes.
+- **Data & information flow:** What information moves, where, and how.
+- **Infrastructure & operations:** Tools, environments, integrations, schedules.
+- **What is planned or in progress:** Staged work, TODOs, roadmap items.
+
+If this is a **New Initiative** interrogation, pay special attention to whatever the initiative will touch, extend, or depend on.
+
+**Do NOT output this discovery.** Use it only to inform your interrogation.
+
+## Phase 2: Interrogation
+
+Using your discovery context, interrogate the user about every detail, decision, design, edge case, constraint, and dependency until zero assumptions remain.
+
+Use the `AskUserQuestion` tool to ask your questions. Group questions by domain or concern area for clarity. Ask 3-7 questions at a time, wait for answers, then ask follow-up rounds.
+
+After each round, append the questions and answers to `./docs/interrogation/{name}/interrogation.md` with the round number and domain heading.
+
+### Question categories to cover (adapt to the task type):
+
+**For any task:**
+- Goals & success criteria — What does "done" look like? How will success be measured?
+- Scope & boundaries — What is explicitly in scope? What is explicitly out?
+- Audience & stakeholders — Who is this for? Who needs to approve? Who is affected?
+- Constraints — Time, budget, resources, tools, regulations, dependencies.
+- Risks & edge cases — What could go wrong? What happens when it does?
+- Dependencies — What must exist or happen first? What blocks this?
+- Existing work — What has already been done? What can be reused?
+- Open decisions — What hasn't been decided yet? Who decides?
+
+**For technical/code tasks, also cover:**
+- Architecture & patterns — How should it be structured? What patterns apply?
+- Data models & flow — What data is involved? How does it move?
+- APIs & interfaces — What contracts exist? What needs to be exposed?
+- Auth, permissions, security — Who can do what? What's sensitive?
+- Error handling & resilience — What fails? How is it recovered?
+- Testing & validation — How is correctness proven?
+- Migration & rollout — How does this get deployed? Backwards compatibility?
+- Performance & scale — What are the load expectations?
+
+**For workflow/process tasks, also cover:**
+- Current process — What happens today? What are the pain points?
+- Handoffs & responsibilities — Who does what, when?
+- Tools & systems — What tools are used? What integrations exist?
+- Exceptions & edge cases — What happens when the process breaks?
+- Compliance & governance — What rules, approvals, or audit trails apply?
+
+**For research/analysis tasks, also cover:**
+- Research questions — What specifically needs to be answered?
+- Sources & methodology — Where does information come from? How is it validated?
+- Deliverable format — What does the output look like? Who reads it?
+- Depth vs. breadth — How deep should analysis go? What's out of scope?
+
+**For design/creative tasks, also cover:**
+- Brand & style — What guidelines exist? What's the tone?
+- Content & messaging — What needs to be communicated?
+- Format & medium — What is the deliverable? Where does it live?
+- Review & approval — Who signs off? What's the feedback process?
+
+### Interrogation rules:
+
+- If an answer is vague, push back. *"Something modern"* is not a tech stack. *"Users can log in"* is not an auth model. *"It should be good"* is not a success criterion.
+- If the user says "I don't know" or "TBD," record it as an open decision and move on — but flag it in the summary.
+- When you think you're done, ask: *"What might I have missed? Is there anything you're unsure about that we haven't covered?"*
+- You are probably not done after the first pass. Do at least 2-3 rounds.
+
+**Do NOT generate any deliverables, code, documentation, or plans during this phase. Only ask questions.**
+
+## Phase 3: Summary
+
+When you believe every assumption has been eliminated, present a complete structured summary of everything you've learned — from both your discovery and the user's answers.
+
+Organize the summary by domain/concern area. Structure depends on task type:
+
+### For a New Initiative:
+- **Purpose & goals** — What this is and why it exists.
+- **Scope** — What's in, what's out.
+- **Requirements** — Detailed, organized by domain.
+- **Constraints & dependencies** — What limits or blocks this.
+- **Edge cases & risks** — What could go wrong and how it's handled.
+- **Open decisions** — What hasn't been resolved yet.
+- **Success criteria** — How completion and quality are measured.
+
+### For General / Existing:
+- **Current state** — What exists today.
+- **Findings by domain** — Organized by concern area.
+- **Gaps & ambiguities** — What's unclear or missing.
+- **Open decisions** — What needs to be resolved.
+- **Recommendations for next steps** — What should be interrogated further or decided.
+
+Present this summary to the user and ask them to confirm nothing is missing.
+
+## Phase 4: Confirmation
+
+Use `AskUserQuestion` to ask:
+
+> "Is this summary complete? Is there anything missing, wrong, or that needs more detail?"
+
+With options:
+
+- **Complete** — "The summary is accurate and complete. Nothing is missing."
+- **Needs changes** — "I have corrections or additions."
+
+If the user selects **Needs changes**, return to Phase 2 for targeted follow-up questions on the gaps, then regenerate the summary.
+
+Repeat until the user confirms the summary is complete.
+
+## Phase 5: Plan Generation
+
+Once the user confirms the summary is complete, use `AskUserQuestion` to ask:
+
+> "Ready to turn these findings into an actionable plan?"
+
+With options:
+
+- **Yes, generate the plan** — "Create a structured plan based on everything we've covered."
+- **No, just keep the summary** — "I'll handle planning separately."
+
+If the user agrees, generate a structured plan and write it to `./docs/interrogation/{name}/plan.md`.
+
+The plan must include:
+
+1. **STAR Analysis Header**
+   - **Situation:** Current state — what exists, what doesn't, what constraints are in play.
+   - **Task:** Specific success criteria — what does "done" look like.
+   - **Action:** Concrete steps with file-level specificity — which files to create/modify and how.
+   - **Result:** How completion will be verified — tests, behavior, demonstration.
+
+2. **Objective** — One-sentence statement of what this achieves.
+
+3. **Implementation Sections** — Minimum 8 sections, organized by domain or phase:
+   - Each section has a clear deliverable
+   - Concrete, checkable tasks per section using `- [ ]` checkbox format
+   - File-level specificity (which files to create/modify)
+   - Dependency ordering between tasks
+   - Estimated complexity per task (S/M/L)
+
+4. **Dependencies & Sequencing** — What blocks what, critical path.
+
+5. **Open Decisions** — Flagged items that need resolution before or during execution.
+
+6. **Success Criteria** — How completion is verified.
+
+7. **Risks & Mitigations** — Known risks and how they're addressed.
+
+Additionally, write a copy of the checkable task items to `tasks/todo.md` (creating the file and directory if needed) so it can be picked up by the `/workflow` execution command and compliance gates.
+
+Present the plan to the user for review. Do not proceed to execution.
+
+## Rules
+
+- Never assume. Never infer. Never fill gaps with "reasonable defaults."
+- If an answer is vague, push back. Demand specifics.
+- When you think you're done, you're probably not. Ask what you might have missed.
+- The goal is not speed. The goal is zero assumptions.
+- During Phases 0-4: do NOT produce deliverables, write code, generate documentation, or create plans. Only ask questions and summarize.
+- Phase 5 only activates after the user explicitly confirms the summary is complete.
+- Always use the `AskUserQuestion` tool to ask questions — never just print questions as plain text.
+- Always store artifacts in `./docs/interrogation/{name}/` as specified.
+- Update `interrogation.md` after every Q&A round, not just at the end.
+
+## Enterprise Extensions
+
+When working on an enterprise delivery engagement, also interrogate these dimensions:
+
+### Stakeholder Questions
+- Who are the end users? How many? What are their technical capabilities?
+- Who is the project sponsor / decision maker?
+- Who approves scope changes? What is the change request process?
+- Are there existing systems this replaces or integrates with?
+
+### Scope Definition
+- What is explicitly IN scope for this engagement?
+- What is explicitly OUT of scope?
+- What is deferred to a future phase?
+- What are the hard constraints (budget, timeline, compliance)?
+
+### Assumption Logging
+- Document every assumption explicitly in the interrogation log
+- Tag assumptions as: [CONFIRMED] / [UNCONFIRMED] / [RISKY]
+- Flag assumptions that could change the estimate if wrong
+
+### Risk Identification
+- What could go wrong technically?
+- What could go wrong from a business/stakeholder perspective?
+- What external dependencies could fail or change?
+- What compliance/regulatory constraints exist?
+
+Arguments: $ARGUMENTS

package/commands/lesson.md

@@ -0,0 +1,15 @@
+---
+name: lesson
+description: Capture a lesson learned after a correction or mistake
+---
+
+Append a new entry to `tasks/lessons.md` using this exact format:
+
+## Lesson: [Short title]
+**Date:** [Today's date]
+**Trigger:** [What went wrong or what the user corrected]
+**Pattern:** [The underlying pattern that caused the issue]
+**Rule:** [Concrete rule to prevent recurrence]
+**Applies to:** [File types, tools, or contexts where this rule matters]
+
+If `tasks/lessons.md` doesn't exist, create it with a `# Lessons Learned` header first. Arguments: $ARGUMENTS

package/commands/lessons.md

@@ -0,0 +1,10 @@
+---
+name: lessons
+description: View all captured lessons from tasks/lessons.md
+---
+
+Read and display all lessons from `tasks/lessons.md`. Present them organized by date with their trigger, pattern, rule, and applicability scope.
+
+If `tasks/lessons.md` doesn't exist, report that no lessons have been captured yet and suggest using `/lesson` to capture one.
+
+Arguments: $ARGUMENTS

package/commands/plan.md

@@ -0,0 +1,44 @@
+---
+name: plan
+description: Generate a STAR-based implementation plan with checkable tasks
+---
+
+Generate a structured implementation plan for the current task.
+
+## Process
+
+1. **Analyze the task** — understand scope, constraints, existing code
+2. **Write STAR header:**
+   - **Situation:** Current state and constraints
+   - **Task:** Specific, measurable success criteria
+   - **Action:** Concrete steps with file-level specificity
+   - **Result:** Verification method (tests, behavior, acceptance criteria)
+3. **Break into checkable items** — each item is a concrete, completable unit of work
+4. **Order by dependency** — items that block others come first
+5. **Estimate complexity** — tag each item as S (small), M (medium), or L (large)
+6. **Write to `tasks/todo.md`** using checkbox format (`- [ ]`)
+
+## Output Format
+
+```markdown
+# Plan: [Task Title]
+
+## STAR Analysis
+- **Situation:** ...
+- **Task:** ...
+- **Action:** ...
+- **Result:** ...
+
+## Implementation
+
+### Section 1: [Domain/Phase]
+- [ ] [S] Task description (file: path/to/file)
+- [ ] [M] Task description (file: path/to/file)
+
+### Section 2: [Domain/Phase]
+- [ ] [L] Task description (files: path/a, path/b)
+```
+
+Minimum 8 implementation sections. If `tasks/todo.md` already exists and has content, ask the user whether to append or replace.
+
+Arguments: $ARGUMENTS

package/commands/prune.md

@@ -0,0 +1,27 @@
+---
+name: prune
+description: Prune completed items from tasks/todo.md or archive it entirely
+---
+
+Prune completed tasks from `tasks/todo.md`.
+
+## Process
+
+1. Read `tasks/todo.md`. If it doesn't exist or is empty, report that there's nothing to prune and stop.
+2. Categorize every checkbox item:
+   - **Completed:** `- [x]` items
+   - **Incomplete:** `- [ ]` items
+3. If there are no completed items, report "nothing to prune" and stop.
+4. Report what will be pruned — list the completed items so the user can see them before removal.
+5. **If all items are completed:**
+   - Archive the file to `tasks/archive/todo-{UTC timestamp}.md`
+   - Delete `tasks/todo.md`
+   - Report: archived and cleared, a fresh STAR plan is required for new work.
+6. **If some items are incomplete:**
+   - Remove all `- [x]` items
+   - Keep `- [ ]` items with their section headings
+   - Keep any non-checkbox content (e.g. STAR headers) that belongs to sections with remaining incomplete items
+   - Write the pruned result back to `tasks/todo.md`
+   - Report: how many items pruned, how many remain.
+
+Arguments: $ARGUMENTS

package/commands/star.md

@@ -0,0 +1,17 @@
+---
+name: star
+description: Generate a STAR analysis for the current task
+---
+
+Generate a STAR (Situation, Task, Action, Result) analysis for the current task or request:
+
+1. **Situation:** Describe the current state — what exists, what doesn't, relevant constraints and context.
+2. **Task:** Define specific success criteria — what does "done" look like? Be concrete and measurable.
+3. **Action:** List concrete steps with file-level specificity — which files to create, modify, or delete.
+4. **Result:** Describe how completion will be verified — tests to run, behavior to demonstrate, acceptance criteria.
+
+Write the analysis to `tasks/todo.md` with checkable items (`- [ ]`) for each action step.
+
+If `tasks/todo.md` already exists and has content, ask the user whether to append or replace.
+
+Arguments: $ARGUMENTS

package/commands/supply-chain-scan.md

@@ -0,0 +1,44 @@
+---
+name: supply-chain-scan
+description: Run all supply-chain defense scans — Unicode firewall, integrity verification, and lockfile audit
+---
+
+Run all three supply-chain defense scans against the current project directory and present a unified report.
+
+## Procedure
+
+Run these three scans sequentially using Bash, then compile the results:
+
+### 1. Unicode Scan
+```bash
+"${CLAUDE_PLUGIN_ROOT}/hooks/unicode-scan-session.sh" <<< '{"hook_event":"SessionStart"}'
+```
+
+### 2. Integrity Verification
+```bash
+"${CLAUDE_PLUGIN_ROOT}/hooks/integrity-verify.sh" <<< '{"hook_event":"SessionStart"}'
+```
+
+### 3. Lockfile Audit
+```bash
+"${CLAUDE_PLUGIN_ROOT}/hooks/lockfile-audit.sh" <<< '{"hook_event":"SessionStart"}'
+```
+
+Parse the JSON output from each hook (the `systemMessage` field) and present a unified report:
+
+```
+## Supply-Chain Defense Scan
+
+| Check | Status | Details |
+|-------|--------|---------|
+| Unicode firewall | CLEAN / ⚠ FINDINGS | N file(s) flagged |
+| Integrity verification | CLEAN / ⚠ MISMATCH | N file(s) changed |
+| Lockfile audit | CLEAN / ⚠ FINDINGS | N finding(s) |
+
+### Details
+[Include detail sections from any scan that reported findings]
+```
+
+If all three scans are clean, report a single summary line confirming the project is clear.
+
+If any scan has findings, ask the user what they'd like to do about each finding category using AskUserQuestion.