Nm Imbue Workflow Monitor

Detect workflow failures and inefficient patterns, then create GitHub issues for improvement via /fix-workflow

Security Scan

The skill's purpose and instructions are largely coherent for monitoring workflows and opening issues, but it omits explicit declarations for required tooling/credentials and includes steps that could expose sensitive command output to an external git platform unless careful safeguards are in place.

Purpose & Capability

The skill claims to detect failures/inefficiencies and create issues on the git platform; its instructions and templates align with that purpose. However, it uses the GitHub CLI (gh) in examples and expects access to a 'git platform' via configuration, yet declares no required binaries or credentials. The declared config paths (night-market.leyline:git-platform, night-market.imbue:proof-of-work, night-market.sanctum:fix-workflow) appear relevant, but the mapping from those config paths to actual tokens/permissions isn't shown — a minor mismatch between claimed behavior and explicit requirements.

Instruction Scope

Instructions tell the agent to capture commands, outputs, timings and to generate issue bodies that include command outputs and environment/context details. Creating issues with raw command output or environment notes could leak sensitive data (secrets, tokens, internal paths). There are no explicit redaction or sanitization steps in the SKILL.md. The skill also references reading session context (e.g., /context) and running shell commands (gh issue list, timeout, etc.), which is expected for this functionality but increases the risk of unintended data exposure if approval/redaction are not enforced.

Install Mechanism

This is instruction-only with no install spec and no code files; that reduces install-time risk. There is no downloading/extracting of remote archives or third‑party packages in the skill itself.

Credentials

The skill declares no required environment variables but does require three configuration paths that likely supply git-platform credentials and hooks. Requiring a git-platform credential is proportionate to creating issues, but the skill does not explicitly declare the need for the GitHub CLI binary or a GitHub token scope. Users should confirm what the named config paths resolve to and ensure only minimal (repo-scoped) permissions are granted. Templates reference 'ENV_NOTES' and 'WORKING_DIR' which could pull sensitive environment information if collected.

Persistence & Privilege

The skill does not request always:true and is user-invocable. It documents guardrails (approval required by default, rate limiting, no duplicates) which mitigate autonomous creation of issues. Autonomous invocation is allowed by platform default but not combined with always:true or broad undeclared credential access here.

What to consider before installing

Before installing: 1) Confirm what the three required config paths (night-market.leyline:git-platform, night-market.imbue:proof-of-work, night-market.sanctum:fix-workflow) will provide — specifically which tokens/credentials and scopes; prefer least privilege (repo-only tokens). 2) Ensure the environment where the skill runs has the gh CLI and any other tools the SKILL.md uses, or update the skill metadata to declare them. 3) Inspect how evidence is collected and stored (proof-of-work) and whether outputs or environment variables are sanitized — the templates include raw command output and env notes which can leak secrets; require redaction or manual approval before posting. 4) Keep auto_create_issues: false (the default) and test in a non-production repo to validate behavior. 5) If you accept the skill, restrict its git token scope, monitor created issues for leaked data, and ask the author to add explicit binary/credential declarations and an evidence-sanitization step to the SKILL.md.

Night Market Skill — ported from claude-night-market/imbue. For the full experience with agents, hooks, and commands, install the Claude Code plugin.

Table of Contents

• Philosophy
• Quick Start
• Detection Patterns
• Workflow
• Issue Template
• Configuration
• Guardrails
• Integration Points
• Output Format

Workflow Monitor

Monitor workflow executions for errors and inefficiencies, automatically creating issues on the detected git platform (GitHub/GitLab) for improvements. Check session context for git_platform: and use Skill(leyline:git-platform) for CLI command mapping.

Philosophy

Workflows should improve over time. When execution issues occur, capturing them systematically enables continuous improvement. This skill hooks into workflow execution to detect problems and propose fixes.

Quick Start

Manual Invocation

# After a failed workflow
/workflow-monitor --analyze-last

# Monitor a specific workflow execution
/workflow-monitor --session <session-id>

# Analyze efficiency of recent workflows
/workflow-monitor --efficiency-report

Automatic Monitoring (via hooks)

When enabled, workflow-monitor observes execution and flags:

• Command failures (exit codes > 0)
• Timeout events
• Repeated retry patterns
• Context exhaustion
• Inefficient tool usage

Detection Patterns

Error Detection

Pattern	Signal	Severity
Command failure	Exit code > 0	High
Timeout	Exceeded timeout limit	High
Retry loop	Same command >3 times	Medium
Context exhaustion	>90% context used	Medium
Tool misuse	Wrong tool for task	Low

Efficiency Detection

Pattern	Signal	Threshold
Verbose output	>1000 lines from command	500 lines recommended
Redundant reads	Same file read >2 times	2 reads max
Sequential vs parallel	Independent tasks run sequentially	Should parallelize
Over-fetching	Read entire file when snippet needed	Use offset/limit

Workflow

Phase 1: Capture (workflow-monitor:capture-complete)

1. Log execution events - Commands, outputs, timing
2. Tag anomalies - Failures, timeouts, inefficiencies
3. Store evidence - For reproducibility

Phase 2: Analyze (workflow-monitor:analysis-complete)

1. Classify issues - Error type, severity, scope
2. Identify root cause - What triggered the issue
3. Suggest fix - What would prevent recurrence

Phase 3: Report (workflow-monitor:report-generated)

1. Generate issue body - Structured format
2. Assign labels - workflow, bug, enhancement
3. Link evidence - Command outputs, session info

Phase 4: Create Issue (workflow-monitor:issue-created)

1. Check for duplicates - Search existing issues
2. Create if unique - Via gh CLI
3. Link to session - For traceability

Issue Template

## Background

Detected during workflow execution on [DATE].

**Source:** [workflow name] session [session-id]

## Problem

[Description of the error or inefficiency]

**Evidence:**

[Command that failed or was inefficient] [Output excerpt]

## Suggested Fix

[What should change to prevent this]

## Acceptance Criteria

- [ ] [Specific fix criterion]
- [ ] Tests added for new behavior
- [ ] Documentation updated

---
*Created automatically by workflow-monitor*

Configuration

# .workflow-monitor.yaml
enabled: true
auto_create_issues: false  # Require approval before creating
severity_threshold: "medium"  # Only report medium+ severity
efficiency_threshold: 0.7  # Flag workflows below 70% efficiency

detection:
  command_failures: true
  timeouts: true
  retry_loops: true
  context_exhaustion: true
  tool_misuse: true

efficiency:
  verbose_output_limit: 500
  max_file_reads: 2
  parallel_detection: true

Guardrails

1. No duplicate issues - Check existing issues before creating
2. Approval required - Unless auto_create_issues: true
3. Evidence required - Every issue must have reproducible evidence
4. Rate limiting - Max 5 issues per session

Required TodoWrite Items

1. workflow-monitor:capture-complete
2. workflow-monitor:analysis-complete
3. workflow-monitor:report-generated
4. workflow-monitor:issue-created (if issue created)

Integration Points

• imbue:proof-of-work: Captures execution evidence
• sanctum:fix-workflow: Implements suggested fixes
• Hooks: Can be triggered by session hooks for automatic monitoring

Output Format

Efficiency Report

## Workflow Efficiency Report

**Session:** [session-id]
**Duration:** 12m 34s
**Efficiency Score:** 0.72 (72%)

### Issues Detected

| Type | Count | Impact |
|------|-------|--------|
| Verbose output | 3 | Medium |
| Redundant reads | 2 | Low |
| Sequential tasks | 1 | Medium |

### Recommendations

1. Use `--quiet` flags for npm/pip commands
2. Cache file contents instead of re-reading
3. Parallelize independent file operations

### Create Issues?

- [ ] Issue 1: Verbose output from npm install
- [ ] Issue 2: Redundant file reads in validation

Related Skills

• imbue:proof-of-work: Evidence capture methodology
• sanctum:fix-workflow: Workflow improvement command
• imbue:proof-of-work: Validation methodology

---

Status: Skeleton implementation. Requires:

• Hook integration for automatic monitoring
• Efficiency scoring algorithm
• Duplicate detection logic