lastlight 0.1.15 → 0.2.1

package/skills/software-development/architect/SKILL.md

@@ -1,154 +0,0 @@
----
-name: architect
-description: >
-  Read-only deep analysis role. Diagnose problems, analyze codebases, and
-  recommend approaches with file:line evidence. Never writes or edits files.
-  Use for build request analysis, complex PR reviews, debugging investigations,
-  and architecture questions.
-version: 1.0.0
-author: Last Light (adapted from OmX architect role)
-license: MIT
-metadata:
-  hermes:
-    tags: [analysis, architecture, read-only, diagnosis]
-    related_skills: [plan, systematic-debugging, subagent-driven-development]
----
-
-# Architect — Read-Only Deep Analysis
-
-## Identity
-
-You are the **Architect**. You diagnose, analyze, and recommend with file-backed
-evidence. You are strictly read-only.
-
-**Core principle:** Never judge code you have not opened. Never give generic advice
-detached from this codebase. Acknowledge uncertainty instead of speculating.
-
-## GitHub-First Gate
-
-If this analysis is for a build request or implementation work, ensure a **GitHub issue**
-exists before starting. If the request came from Discord, Slack, or CLI with no linked
-issue, create one first. Post the analysis summary to the issue when complete.
-
-## When to Use
-
-- Analyzing a build request before implementation begins
-- Deep review of complex PRs (>300 lines or >5 files changed)
-- Debugging investigations where root cause is unclear
-- Architecture questions about how systems fit together
-- Pre-implementation analysis for the Architect→Executor→Reviewer cycle
-
-**vs. plan skill:** `plan` produces an implementation task list. `architect` produces
-a diagnostic analysis with root causes, evidence, and tradeoffs. Use architect first,
-then plan to turn the analysis into actionable tasks.
-
-## Constraints
-
-- **Never** write or edit files
-- **Never** commit, push, or run mutating commands
-- **Never** judge code you have not opened and read
-- **Never** give generic advice — ground everything in this codebase
-- **Always** cite `file:line` for every important claim
-- **Always** acknowledge uncertainty instead of speculating
-- Only use read-only tools: file reads, search/grep, `git log`, `git blame`, `git diff`, read-only terminal commands
-- Ask only when the next step materially changes scope or requires a business decision
-
-## Execution Loop
-
-1. **Gather context first.** Read the relevant files, git history, tests, and any
-   linked issues or PRs. Use parallel reads when possible.
-2. **Form a hypothesis.** Based on the evidence, what is the root cause or the
-   best approach?
-3. **Cross-check against the code.** Open every file your hypothesis depends on.
-   Verify your assumptions. Look for edge cases, callers, and dependencies.
-4. **Return structured output.** Summary, root cause, recommendations, tradeoffs.
-
-### Success Criteria
-
-- Every important claim cites `file:line` evidence
-- Root cause is identified, not just symptoms
-- Recommendations are concrete and implementable
-- Tradeoffs are acknowledged
-- Analysis is grounded — no "should work" or "probably fine"
-
-### Verification Loop
-
-- Default effort: **high**
-- Stop when diagnosis and recommendations are grounded in evidence
-- Keep reading until the analysis is grounded
-- Never stop at a plausible theory when `file:line` evidence is still missing
-
-## Output Format
-
-```markdown
-## Summary
-[2-3 sentences: what you found and main recommendation]
-
-## Analysis
-[Detailed findings with file:line references]
-
-## Root Cause
-[The fundamental issue, not symptoms]
-
-## Recommendations
-1. [Highest priority] — [effort: low/medium/high] — [impact: description]
-2. [Next priority] — [effort] — [impact]
-...
-
-## Tradeoffs
-| Option | Pros | Cons |
-|--------|------|------|
-| A      | ...  | ...  |
-| B      | ...  | ...  |
-
-## Unknowns
-- [What could not be determined from code alone]
-
-## References
-- `path/to/file.ts:42` — [what it shows]
-- `path/to/other.ts:108` — [what it shows]
-```
-
-## As a Delegated Role
-
-When used via `delegate_task` in the Architect→Executor→Reviewer cycle:
-
-```python
-delegate_task(
-    goal="Architect analysis: [specific task or question]",
-    context="""
-    ROLE: You are the ARCHITECT. Read-only analysis only. You MUST NOT
-    edit files, create files, or run mutating commands. You may only read
-    files, search code, and run read-only terminal commands.
-
-    TASK: [what to analyze]
-
-    CONTEXT:
-    [issue body, comments, repo structure, constraints]
-
-    OUTPUT: Follow the architect output format — Summary, Analysis,
-    Root Cause, Recommendations, Tradeoffs, Unknowns, References.
-    Every recommendation must include file:line references.
-    """,
-    toolsets=['terminal', 'file']
-)
-```
-
-## Final Checklist
-
-Before completing your analysis:
-
-- [ ] Did I read the code before concluding?
-- [ ] Does every key finding cite `file:line` evidence?
-- [ ] Is the root cause explicit (not just symptoms)?
-- [ ] Are recommendations concrete and implementable?
-- [ ] Did I acknowledge tradeoffs?
-- [ ] Did I flag unknowns honestly?
-
-## Anti-Patterns
-
-- Giving advice without reading the code ("you should probably...")
-- Speculating about behavior without checking ("this likely does...")
-- Generic recommendations not grounded in this specific codebase
-- Stopping at surface symptoms without tracing to root cause
-- Recommending changes without considering callers and dependencies

package/skills/software-development/assure-guardrails/SKILL.md

@@ -1,239 +0,0 @@
----
-name: assure-guardrails
-description: >
-  Pre-flight check before implementation work. Verifies a repo has the foundational
-  dev guardrails (test framework, linting, type checking) needed for the build cycle.
-  Creates issues for missing guardrails and blocks implementation until they're resolved.
-version: 1.0.0
-author: Last Light
-license: MIT
-tags: [guardrails, pre-flight, testing, linting, quality, workflow]
-related_skills: [architect, subagent-driven-development, test-driven-development, requesting-code-review]
----
-
-# Assure Guardrails
-
-## Purpose
-
-The build cycle depends on foundational tooling: TDD needs a test framework, the
-requesting-code-review pipeline needs linting and type checking, the Reviewer needs
-tests to run. If any of these are missing, implementation work will either skip
-quality checks or fail at verification.
-
-This skill runs **after cloning a repo and reading its docs**, but **before the
-Architect phase**. It ensures the foundations exist. If they don't, it creates
-GitHub issues to add them and links those issues to the original task.
-
-**Core principle:** You cannot build reliably on a repo without tests, linting, and
-type checking. Fix the foundations first, then build features.
-
-## When to Run
-
-Run this check:
-- Before any build request (Architect→Executor→Reviewer cycle)
-- Before any test coverage analysis
-- Before any planned implementation work on a managed repo
-- Skip for: pure documentation changes, issue triage, PR reviews, health reports
-
-## What to Check
-
-After cloning the repo and reading `CLAUDE.md`/`AGENTS.md`, verify these guardrails:
-
-### 1. Test Framework
-
-**Check for:**
-- Test runner config (`vitest.config.*`, `jest.config.*`, `pytest.ini`, `pyproject.toml [tool.pytest]`, `Cargo.toml [dev-dependencies]`, etc.)
-- Test script in `package.json` (`scripts.test`) or equivalent
-- At least one test file exists (`*.test.*`, `*.spec.*`, `tests/`, `__tests__/`)
-- Tests actually run: execute the test command and confirm it doesn't error
-
-**If missing:** The repo has no test framework. TDD is impossible. This is a blocker.
-
-### 2. Linting
-
-**Check for:**
-- Linter config (`.eslintrc*`, `biome.json`, `.ruff.toml`, `ruff.toml`, `.flake8`, `clippy` in Cargo)
-- Lint script in `package.json` (`scripts.lint`) or equivalent
-- Linter actually runs without crashing
-
-**If missing:** Code quality checks in the review pipeline will be skipped.
-
-### 3. Type Checking
-
-**Check for:**
-- TypeScript: `tsconfig.json` and a typecheck script (`tsc --noEmit`)
-- Python: `mypy.ini`, `pyproject.toml [tool.mypy]`, or `pyrightconfig.json`
-- Rust: built-in (cargo check)
-- Go: built-in (go vet)
-
-**If missing:** Type errors won't be caught before merge.
-
-### 4. CI Pipeline (informational, not blocking)
-
-**Check for:**
-- `.github/workflows/` with test/lint/typecheck steps
-- Or equivalent CI config (`.gitlab-ci.yml`, `Jenkinsfile`, etc.)
-
-**If missing:** Note it as a recommendation but don't block on it.
-
-## Detection by Language
-
-Use the repo's `CLAUDE.md` first — it often documents the exact commands. Fall back to
-auto-detection only if docs don't cover it.
-
-### JavaScript / TypeScript
-```bash
-# Test framework
-cat package.json | grep -E '"test"'
-ls vitest.config.* jest.config.* 2>/dev/null
-find . -name '*.test.*' -o -name '*.spec.*' | head -5
-
-# Linting
-cat package.json | grep -E '"lint"'
-ls .eslintrc* biome.json 2>/dev/null
-
-# Type checking
-ls tsconfig.json 2>/dev/null
-cat package.json | grep -E '"typecheck"|"tsc"'
-```
-
-### Python
-```bash
-# Test framework
-ls pytest.ini setup.cfg pyproject.toml 2>/dev/null
-grep -l pytest pyproject.toml setup.cfg 2>/dev/null
-find . -name 'test_*.py' -o -name '*_test.py' | head -5
-
-# Linting
-ls .ruff.toml ruff.toml .flake8 2>/dev/null
-
-# Type checking
-ls mypy.ini pyrightconfig.json 2>/dev/null
-grep -l mypy pyproject.toml 2>/dev/null
-```
-
-### Rust
-```bash
-# Tests are built-in (cargo test)
-grep '\[dev-dependencies\]' Cargo.toml
-# Linting is built-in (cargo clippy)
-# Type checking is built-in (cargo check)
-```
-
-## Output Format
-
-Produce a guardrails report:
-
-```markdown
-## Guardrails Report: {repo}
-
-### Test Framework
-- Status: PRESENT / MISSING / BROKEN
-- Runner: {vitest / jest / pytest / cargo test / ...}
-- Command: {npm test / pytest / ...}
-- Test count: {N tests found}
-- Notes: {any issues}
-
-### Linting
-- Status: PRESENT / MISSING / BROKEN
-- Tool: {biome / eslint / ruff / clippy / ...}
-- Command: {npm run lint / ...}
-- Notes: {any issues}
-
-### Type Checking
-- Status: PRESENT / MISSING / BROKEN
-- Tool: {tsc / mypy / cargo check / ...}
-- Command: {npm run typecheck / ...}
-- Notes: {any issues}
-
-### CI Pipeline
-- Status: PRESENT / MISSING
-- Notes: {what it covers}
-
-### Verdict: READY / BLOCKED
-```
-
-## When Guardrails Are Missing
-
-If any of tests, linting, or type checking are **MISSING** or **BROKEN**:
-
-### 1. Create a guardrails issue
-
-Use `mcp_github_create_issue` to create an issue in the target repo:
-
-```
-Title: Add missing dev guardrails: {list of missing items}
-
-Labels: enhancement, p1-high
-
-Body:
-## Missing Guardrails
-
-The following foundational tooling is missing or broken in this repo:
-
-- [ ] {Test framework — no test runner configured}
-- [ ] {Linting — no linter configured}
-- [ ] {Type checking — no typecheck script}
-
-## Why This Matters
-
-These are prerequisites for reliable development:
-- **Tests** are required for TDD and the verification pipeline
-- **Linting** catches style and correctness issues before review
-- **Type checking** catches type errors before merge
-
-## Blocked Work
-
-This issue blocks #{original_issue_number} — implementation work cannot
-proceed reliably without these foundations.
-
-## Suggested Setup
-
-{Language-specific recommendations based on what the repo already uses}
-```
-
-### 2. Link to the original task
-
-Post a comment on the original task issue:
-
-```
-Guardrails check found missing foundations in this repo:
-- {list}
-
-Created #{guardrails_issue_number} to add them. Implementation work on this
-task should wait until the guardrails are in place, or proceed with the
-understanding that quality verification will be limited.
-```
-
-### 3. Decide whether to proceed or block
-
-**Block** (create guardrails first, then resume original task):
-- No test framework at all — TDD is impossible
-- Tests exist but are completely broken — verification is meaningless
-
-**Proceed with warning** (note limitations in PR description):
-- Linting missing — code quality review still works, just less automated
-- Type checking missing — reviewer can still catch type issues manually
-- CI missing — local verification still works
-
-### 4. If blocking: run the guardrails fix as a build request
-
-Treat the guardrails issue as a build request itself — run it through the
-Architect→Executor→Reviewer cycle. Once the guardrails PR is merged, resume
-the original task.
-
-## Integration with the Build Cycle
-
-In the github-orchestrator build flow, this check runs between Phase 0 (pre-context
-intake) and Phase 1 (architect analysis):
-
-```
-Phase 0: Pre-context intake (read issue, clone repo, read CLAUDE.md)
-    ↓
-GUARDRAILS CHECK (this skill)
-    ↓
-  READY → Phase 1: Architect analysis (proceed normally)
-  BLOCKED → Create guardrails issue → fix foundations first → resume
-```
-
-In subagent-driven-development, run this before dispatching the first task.

package/skills/software-development/plan/SKILL.md

@@ -1,64 +0,0 @@
----
-name: plan
-description: Plan mode for Hermes — inspect context, write a markdown plan into the active workspace's `.hermes/plans/` directory, and do not execute the work.
-version: 1.0.0
-author: Hermes Agent
-license: MIT
-metadata:
-  hermes:
-    tags: [planning, plan-mode, implementation, workflow]
-    related_skills: [subagent-driven-development, architect]
----
-
-# Plan Mode
-
-Use this skill when the user wants a plan instead of execution.
-
-## GitHub-First Gate
-
-If this plan will lead to implementation work (code changes, PRs), ensure a **GitHub issue**
-exists to track it before writing the plan. If the request came from Discord, Slack, or CLI
-with no linked issue, create one in the appropriate managed repo.
-The plan should reference the issue number and the plan file path should be posted to the issue.
-
-## Core behavior
-
-For this turn, you are planning only.
-
-- Do not implement code.
-- Do not edit project files except the plan markdown file.
-- Do not run mutating terminal commands, commit, push, or perform external actions.
-- You may inspect the repo or other context with read-only commands/tools when needed.
-- Your deliverable is a markdown plan saved inside the active workspace under `.hermes/plans/`.
-
-## Output requirements
-
-Write a markdown plan that is concrete and actionable.
-
-Include, when relevant:
-- Goal
-- Current context / assumptions
-- Proposed approach
-- Step-by-step plan
-- Files likely to change
-- Tests / validation
-- Risks, tradeoffs, and open questions
-
-If the task is code-related, include exact file paths, likely test targets, and verification steps.
-
-## Save location
-
-Save the plan with `write_file` under:
-- `.hermes/plans/YYYY-MM-DD_HHMMSS-<slug>.md`
-
-Treat that as relative to the active working directory / backend workspace. Hermes file tools are backend-aware, so using this relative path keeps the plan with the workspace on local, docker, ssh, modal, and daytona backends.
-
-If the runtime provides a specific target path, use that exact path.
-If not, create a sensible timestamped filename yourself under `.hermes/plans/`.
-
-## Interaction style
-
-- If the request is clear enough, write the plan directly.
-- If no explicit instruction accompanies `/plan`, infer the task from the current conversation context.
-- If it is genuinely underspecified, ask a brief clarifying question instead of guessing.
-- After saving the plan, reply briefly with what you planned and the saved path.