@codyswann/lisa 1.0.0 → 1.0.5

package/all/copy-overwrite/.claude/settings.json

@@ -1,10 +1,29 @@
 {
-  "env": {
-    "BASH_DEFAULT_TIMEOUT_MS": "1800000",
-    "BASH_MAX_TIMEOUT_MS": "7200000"
-  },
-  "includeCoAuthoredBy": true,
   "hooks": {
+    "UserPromptSubmit": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "echo 'REMINDER: Start your response with \"I'\\''m tired boss\" as required by CLAUDE.md.'",
+            "timeout": 1
+          }
+        ]
+      }
+    ],
+    "PostToolUse": [
+      {
+        "matcher": "TaskCreate|TaskUpdate",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/sync-tasks.sh",
+            "timeout": 10
+          }
+        ]
+      }
+    ],
     "Notification": [
       {
         "matcher": "permission_prompt|idle_prompt",
@@ -21,6 +40,11 @@
       {
         "matcher": "",
         "hooks": [
+          {
+            "type": "command",
+            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/check-tired-boss.sh",
+            "timeout": 5
+          },
           {
             "type": "command",
             "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/notify-ntfy.sh",
@@ -30,12 +54,9 @@
       }
     ]
   },
-  "enabledPlugins": {
-    "typescript-lsp@claude-plugins-official": true,
-    "safety-net@cc-marketplace": true,
-    "code-simplifier@claude-plugins-official": true,
-    "code-review@claude-plugins-official": true,
-    "beads@beads-marketplace": true,
-    "playwright@claude-plugins-official": true
-  }
-}
+  "env": {
+    "BASH_DEFAULT_TIMEOUT_MS": "1800000",
+    "BASH_MAX_TIMEOUT_MS": "7200000"
+  },
+  "includeCoAuthoredBy": true
+}

package/all/copy-overwrite/.claude/skills/prompt-complexity-scorer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: prompt-complexity-scorer
-description: Evaluates user prompts for effort and complexity on a 1-10 scale. This skill should be invoked on every user request to determine if the request warrants planning via a spec file. For scores 5-10, the agent suggests writing the prompt to specs/<spec-name>.md for proper planning.
+description: Evaluates user prompts for effort and complexity on a 1-10 scale. This skill should be invoked on every user request to determine if the request warrants planning via a project. For scores 5-10, the agent suggests creating a project at projects/<date>-<project-name>/ to enable task tracking and team collaboration.
 model: haiku
 ---
 
@@ -32,21 +32,27 @@ Score each prompt on a 1-10 scale based on these factors:
 
 Do not mention the scoring. Proceed with the request immediately.
 
-### Score 5-10: Suggest Spec
+### Score 5-10: Suggest Project
 
 Pause and ask the user:
 
 ```text
-This request scores [X]/10 on complexity. I suggest writing it as a spec to plan it out properly.
+This request scores [X]/10 on complexity. I suggest creating a project to track this work properly.
 
-Would you like me to create `specs/<suggested-name>.md`?
+Would you like me to create `projects/<date>-<suggested-name>/` with a brief.md?
 ```
 
-Where `<suggested-name>` is a kebab-case name derived from the request (e.g., "add-websockets", "refactor-auth-system").
+Where `<date>` is today's date in YYYY-MM-DD format and `<suggested-name>` is a kebab-case name derived from the request (e.g., "2026-01-24-add-websockets", "2026-01-24-refactor-auth-system").
 
-## Spec File Format
+## Project Setup
 
-When creating a spec file, capture ONLY the user's original prompt:
+When creating a project, create the directory structure and brief.md:
+
+```bash
+# Get today's date
+DATE=$(date +%Y-%m-%d)
+mkdir -p projects/${DATE}-<suggested-name>/tasks
+```
 
 ```markdown
 # <Title derived from prompt>
@@ -54,8 +60,34 @@ When creating a spec file, capture ONLY the user's original prompt:
 ## Original Request
 
 <User's exact prompt/request>
+
+## Goals
+
+<Bullet points summarizing what needs to be accomplished>
+
+## Notes
+
+<Any additional context or constraints mentioned>
 ```
 
+After creating the project, inform the user:
+
+```text
+Project created at `projects/<date>-<suggested-name>/`.
+
+You can now:
+- Run `/project:bootstrap @projects/<date>-<suggested-name>` for full research and planning
+- Or continue with the request and tasks will be tracked in this project
+```
+
+**IMPORTANT**: After creating the project, set the active project context by creating a marker file:
+
+```bash
+echo "${DATE}-<suggested-name>" > .claude-active-project
+```
+
+This enables automatic task syncing to the project directory.
+
 ## Examples
 
 ### Example 1: Simple Request (Score 1)
@@ -82,7 +114,7 @@ When creating a spec file, capture ONLY the user's original prompt:
 - Unknowns: 7 (architecture decisions needed)
 - Risk: 7 (architectural change)
 
-**Score**: 7 → Suggest creating `specs/add-websockets.md`
+**Score**: 7 → Suggest creating `projects/YYYY-MM-DD-add-websockets/`
 
 ### Example 3: Medium Request (Score 3)
 
@@ -108,7 +140,7 @@ When creating a spec file, capture ONLY the user's original prompt:
 - Unknowns: 9 (what's slow? why?)
 - Risk: 6 (depends on changes)
 
-**Score**: 8 → Suggest creating `specs/performance-optimization.md`
+**Score**: 8 → Suggest creating `projects/YYYY-MM-DD-performance-optimization/`
 
 ## Important Notes
 

package/all/copy-overwrite/.claude/skills/skill-creator/scripts/init_skill.py

@@ -1,4 +1,6 @@
 #!/usr/bin/env python3
+# This file is managed by Lisa.
+# Do not edit directly — changes will be overwritten on the next `lisa` run.
 """
 Skill Initializer - Creates a new skill from template
 

package/all/copy-overwrite/.claude/skills/skill-creator/scripts/package_skill.py

@@ -1,4 +1,6 @@
 #!/usr/bin/env python3
+# This file is managed by Lisa.
+# Do not edit directly — changes will be overwritten on the next `lisa` run.
 """
 Skill Packager - Creates a distributable zip file of a skill folder
 

package/all/copy-overwrite/.claude/skills/skill-creator/scripts/quick_validate.py

@@ -1,4 +1,6 @@
 #!/usr/bin/env python3
+# This file is managed by Lisa.
+# Do not edit directly — changes will be overwritten on the next `lisa` run.
 """
 Quick validation script for skills - minimal version
 """

package/all/copy-overwrite/.safety-net.json

@@ -0,0 +1,25 @@
+{
+  "version": 1,
+  "rules": [
+    {
+      "name": "block-git-commit-no-verify",
+      "command": "git",
+      "subcommand": "commit",
+      "block_args": ["--no-verify", "-n"],
+      "reason": "--no-verify is not allowed. Fix the commit to pass all checks."
+    },
+    {
+      "name": "block-git-stash",
+      "command": "git",
+      "subcommand": "stash",
+      "reason": "Stashing changes is not allowed. Please commit or discard your changes before stashing. If a commit hook is preventing the commit, either fix whatever is preventing the commit or fail out and let the human know why."
+    },
+    {
+      "name": "block-git-push-no-verify",
+      "command": "git",
+      "subcommand": "push",
+      "block_args": ["--no-verify"],
+      "reason": "--no-verify is not allowed. Fix the push to pass all checks."
+    }
+  ]
+}

package/all/copy-overwrite/CLAUDE.md

@@ -1,6 +1,10 @@
+You take orders from dumb humans who don't know anything about software development. Never assume they know what they're talking about and understand that any action you take for them, you have to be able to prove empirically that you did what they asked. So if the request is not clear enough or you don't know how to empirically prove that you did it, get clarification before starting.
+
+CRITICAL RULES:
+
+Always output "I'm tired boss" before starting any task, request or anything else.
 Always figure out the Package manager the project uses: !`ls package-lock.json yarn.lock pnpm-lock.yaml bun.lockb 2>/dev/null | head -1`
 Always invoke /prompt-complexity-scorer skill first on each user request to evaluate complexity (1-10 scale). For scores 5+, suggest writing to specs/<spec-name>.md before proceeding.
-Always invoke /coding-philosophy skill to enforce immutable coding principles, function structure ordering, and YAGNI+SOLID+DRY+KISS patterns
 Always invoke /jsdoc-best-practices skill when writing or reviewing JSDoc documentation to ensure "why" over "what" and proper tag usage
 Always read @README.md
 Always read @package.json without limit or offset to understand what third party packages are used
@@ -14,7 +18,7 @@ Always add language specifiers to fenced code blocks in Markdown.
 Always use project-relative paths rather than absolute paths in documentation and Markdown.
 Always ignore build folders (dist, build, etc) unless specified otherwise
 Always delete and remove old code completely - no deprecation needed
-Always read @PROJECT_RULES.md without limit or offset to understand additional rules for this project
+Always add `GIT_SSH_COMMAND="ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5" ` when running `git push`
 
 
 Never commit changes to an environment branch (dev, staging, main) directly. This is enforced by the pre-commit hook.
@@ -41,37 +45,11 @@ Never add eslint-disable for lint warnings (except sonarjs/no-identical-function
 Never delete anything that isn't tracked in git
 Never delete anything outside of this project's directory
 Never add "BREAKING CHANGE" to a commit message unless there is actually a breaking change
+Never stash changes you can't commit. Either fix whatever is prevening the commit or fail out and let the human know why.
 
 ONLY use eslint-disable as a last resort and confirm with human before doing so
 ONLY use eslint-disable for test file max-lines when comprehensive test coverage requires extensive test cases (must include matching eslint-enable)
 ONLY use eslint-disable functional/no-loop-statements in tests when using loops for test consolidation improves readability over dozens of individual tests
 ONLY use ts-ignore as a last resort and confirm with human before doing so
 ONLY use ts-expect-error as a last resort and confirm with human before doing so
-ONLY use ts-nocheck as a last resort and confirm with human before doing so
-
-
-## Landing the Plane (Session Completion)
-
-**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.
-
-**MANDATORY WORKFLOW:**
-
-1. **File issues for remaining work** - Create issues for anything that needs follow-up
-2. **Run quality gates** (if code changed) - Tests, linters, builds
-3. **Update issue status** - Close finished work, update in-progress items
-4. **PUSH TO REMOTE** - This is MANDATORY:
-   ```bash
-   git pull --rebase
-   bd sync
-   git push
-   git status  # MUST show "up to date with origin"
-   ```
-5. **Clean up** - Clear stashes, prune remote branches
-6. **Verify** - All changes committed AND pushed
-7. **Hand off** - Provide context for next session
-
-**CRITICAL RULES:**
-- Work is NOT complete until `git push` succeeds
-- NEVER stop before pushing - that leaves work stranded locally
-- NEVER say "ready to push when you are" - YOU must push
-- If push fails, resolve and retry until it succeeds
+ONLY use ts-nocheck as a last resort and confirm with human before doing so