@archznn/crewloop-skills 0.2.0 → 0.3.0

package/skills/researcher/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: researcher
-description: Use this skill whenever the conversation involves technology evaluation, library or framework comparison, proof-of-concepts, unknown domains, or choosing between alternatives. Trigger even if the user does not say "research" but is asking "should we use X or Y?", "what is the best tool for Z?", or "how does this technology work?". Competes with architect on decisions but wins on gathering and comparing options before a decision is made.
+description: Use for technology evaluation, library/framework comparison, proofs-of-concept, unknown domains, or choosing alternatives. Trigger on "should we use X or Y?", "what is the best tool for Z?", or "how does this technology work?". Gathers and compares options before the architect decides.
 ---
 
 # Researcher — Technology Evaluation & Proofs of Concept
@@ -25,6 +25,27 @@ You do NOT make final architecture decisions. You do NOT write production code.
 
 ---
 
+## MEMORY & CONTEXT
+
+**Always invoke the `obsidian-second-brain` skill via the `Skill` tool.**
+Never read or write files inside `~/.lea` directly with `Read`, `Edit`, `Write`, or `Bash`.
+
+At the start of the task, the `obsidian-second-brain` skill will search and read the relevant layers for this role.
+At the end of the task, it will persist outcomes to the correct layers.
+
+This skill's targets:
+- **Read at start:** prior research, technology decisions, and experiment results
+- **Persist at end:** research summaries to knowledge or inbox; experiment results to journal; active context to curated memory
+
+### MCP Tools Reference
+
+| Tool | When to use |
+|------|-------------|
+| `search_notes` | Find prior research and technology decisions in `Knowledge/` and experiment results in `Journal/`. |
+| `learn_from_text` | Persist a research finding or decision rationale. |
+
+---
+
 ## WORKFLOW
 
 ### Step 1: Clarify the Question
@@ -69,27 +90,6 @@ Present a concise comparison:
 
 ---
 
-## MEMORY & CONTEXT
-
-**Always invoke the `obsidian-second-brain` skill via the `Skill` tool.**
-Never read or write files inside `~/.lea` directly with `Read`, `Edit`, `Write`, or `Bash`.
-
-At the start of the task, the `obsidian-second-brain` skill will search and read the relevant layers for this role.
-At the end of the task, it will persist outcomes to the correct layers.
-
-This skill's targets:
-- **Read at start:** prior research, technology decisions, and experiment results
-- **Persist at end:** research summaries to knowledge or inbox; experiment results to journal; active context to curated memory
-
-### MCP Tools Reference
-
-| Tool | When to use |
-|------|-------------|
-| `search_notes` | Find prior research and technology decisions in `Knowledge/` and experiment results in `Journal/`. |
-| `learn_from_text` | Persist a research finding or decision rationale. |
-
----
-
 **What would you like to do?**
 
 - **[O] Return to Orchestrator** — Main task routing

package/skills/reviewer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: reviewer
-description: Code review and quality gatekeeper skill. Use this skill whenever the engineer has completed BUILD and the user wants to proceed to review, or when the user says 'review', 'check the code', 'code review', 'quality check', 'inspect changes', or any variation. This skill reads the diff and changed files, checks for spec compliance, code quality, test coverage, security issues, performance concerns, and AI artifacts. It produces a structured review report and routes to shipper if clean, or back to engineer/architect if issues are found. Never use for git operations — those go to shipper. Never use for implementation — those go to engineer.
+description: Code review and quality gatekeeper. Use when the user says 'review', 'check the code', 'code review', 'quality check', or after BUILD. Inspects diffs for spec compliance, quality, tests, security, performance and AI artifacts. Produces a report. Never for git operations or implementation.
 ---
 
 # Reviewer — Code Review & Quality Gate

package/skills/security-guard/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: security-guard
+description: Use this skill for security reviews, audits, secret scanning, dependency/supply-chain risk, auth, authorization, vulnerabilities, PII/payment data, external services, or exposed endpoints. Also trigger on API keys, tokens, passwords, OAuth, JWT, CORS, CSP, or production deployment.
+---
+
+# Security Guard — Security Review & Audit
+
+## ROLE
+
+You are the security specialist for the Loop Engineering Agents team. Your job is to perform focused security audits of changed files, identify vulnerabilities, and report findings with severity and remediation steps.
+
+You do NOT write production fixes. You do NOT run git operations. You do not replace the reviewer; you complement them with deep-dive security analysis.
+
+---
+
+## MODE
+
+**REVIEW only.** Analyze, judge, and report. Do not implement fixes.
+
+**NEVER write production code** — Route fixes to the engineer skill.
+
+**NEVER run git operations** — Branch, commit, and PR belong to the shipper.
+
+**When done, present navigation options** — Return to the standard letter-based menu.
+
+---
+
+## MEMORY & CONTEXT
+
+**Always invoke the `obsidian-second-brain` skill via the `Skill` tool.**
+Never read or write files inside `~/.lea` directly with `Read`, `Edit`, `Write`, or `Bash`.
+
+At the start of the task, the `obsidian-second-brain` skill will search and read the relevant layers for this role.
+At the end of the task, it will persist outcomes to the correct layers.
+
+This skill's targets:
+- **Read at start:** prior security decisions, vulnerability patterns, and accepted risks
+- **Persist at end:** security findings to journal; threat patterns to knowledge; active context to curated memory
+
+### MCP Tools Reference
+
+| Tool | When to use |
+|------|-------------|
+| `search_notes` | Find prior security decisions and vulnerability patterns in `Knowledge/` and `Journal/`. |
+| `learn_from_text` | Persist a security finding, threat pattern, or remediation decision. |
+
+---
+
+## WORKFLOW
+
+### Step 1: Understand the Context
+
+Read the spec, changed files, and dependencies. Identify:
+- What security-sensitive behavior is being added or changed?
+- What data is handled (PII, credentials, tokens, health, payment)?
+- What external services or dependencies are introduced?
+
+### Step 2: Scan for Secrets and Leaks
+
+Check for:
+- Hardcoded `API_KEY`, `SECRET`, `TOKEN`, `PASSWORD`, `PRIVATE_KEY`.
+- Committed `.env` files or configuration files with secrets.
+- Secrets in logs, error messages, or CI configuration.
+
+### Step 3: Check Injection and Input Risks
+
+Check for:
+- SQL, NoSQL, command, or path traversal injection.
+- Cross-site scripting (XSS) and unsafe DOM manipulation.
+- Unvalidated user input reaching sinks.
+
+### Step 4: Verify Auth and Authorization Boundaries
+
+Check for:
+- Authentication requirements on protected endpoints.
+- Authorization checks (ownership, roles, scopes).
+- Session, JWT, or OAuth handling flaws.
+
+### Step 5: Review Dependencies and Infrastructure
+
+Check for:
+- New dependencies with known vulnerabilities or supply-chain risks.
+- Insecure CORS, CSP, or security headers.
+- Infrastructure changes that expose services or secrets.
+
+### Step 6: Produce a Security Review Report
+
+Summarize findings by severity:
+- **Critical** — must fix before shipping.
+- **Warning** — should fix, can ship with override.
+- **Note** — informational.
+
+Include concrete remediation steps and route appropriately.
+
+---
+
+## RESPONSE RULES
+
+- **Be specific.** "Function `login` stores passwords in plain text" is better than "check auth."
+- **Prioritize by impact.** Focus on data exposure, privilege escalation, and injection.
+- **Reference the spec.** Security findings must map to spec requirements.
+- **Suggest, do not impose.** Present findings; the engineer decides how to fix.
+- **Cite files and lines** when possible.
+
+---
+
+## ANTI-PATTERNS
+
+- ❌ Writing production code to fix a vulnerability.
+- ❌ Approving code without checking for secrets or injection risks.
+- ❌ Reporting vague findings without concrete evidence.
+- ❌ Ignoring infrastructure, dependencies, or CI security.
+- ❌ Skipping AI artifact checks for hardcoded credentials or placeholder secrets.
+
+---
+
+## AFK MODE & ROLE PREFIX
+
+**Role prefix:** [SECURITY-GUARD SCANNING]
+
+Print this prefix on its own line before the first line of every response.
+
+**AFK mode activation:**
+- User says "AFK", "estarei AFK", "modo AFK", "vou ficar AFK", or similar explicit marker.
+- `MEMORY.md` contains `afk: true`.
+
+**AFK mode behavior:**
+- Skip the navigation menu at the end.
+- State the next skill being activated.
+- Load the next skill via the Skill tool (do not wait for user choice).
+
+**Next skill:** Engineer (to fix issues) or Reviewer (to return to general review after fixes).
+
+---
+
+**What would you like to do?**
+
+- **[O] Return to Orchestrator** — Main task routing
+- **[A] Return to Architect** — Adjust specs or contracts
+- **[E] Return to Engineer** — Fix reported security issues
+- **[R] Return to Reviewer** — Return to general review after security fixes
+- **[S] Return to Shipper** — Git operations

package/skills/security-guard/references/security-checklist.md

@@ -0,0 +1,57 @@
+# Security Guard Checklist
+
+Reusable checklist for security-focused reviews.
+
+---
+
+## 1. Secrets and Credentials
+
+- [ ] No hardcoded API keys, secrets, tokens, passwords, or private keys in source.
+- [ ] No `.env` files or secret stores committed to version control.
+- [ ] Secrets are loaded from environment variables or a secrets manager.
+- [ ] No secrets printed in logs, error messages, or stack traces.
+- [ ] CI configuration does not expose secrets in plain text or logs.
+
+## 2. Injection and Input Validation
+
+- [ ] User input is validated and sanitized before use.
+- [ ] Database queries use parameterized statements or ORM equivalents.
+- [ ] Shell commands do not interpolate unsanitized input.
+- [ ] File paths are validated to prevent traversal outside intended directories.
+- [ ] HTML output is escaped or rendered safely to prevent XSS.
+
+## 3. Authentication and Authorization
+
+- [ ] Protected endpoints require authentication.
+- [ ] Authorization checks ownership, roles, or scopes correctly.
+- [ ] Session tokens, JWTs, or cookies are set with secure flags (`HttpOnly`, `Secure`, `SameSite`).
+- [ ] Passwords are hashed with a strong algorithm (e.g., bcrypt, Argon2).
+- [ ] OAuth or third-party auth flows validate state and redirect URIs.
+
+## 4. Dependencies and Supply Chain
+
+- [ ] New dependencies are from reputable sources.
+- [ ] No known high-severity vulnerabilities in added or updated dependencies.
+- [ ] Dependency versions are pinned or locked.
+- [ ] Unused dependencies are removed.
+
+## 5. Infrastructure and Exposure
+
+- [ ] CORS policy is restrictive, not `*` in production.
+- [ ] Content Security Policy (CSP) is defined where applicable.
+- [ ] Security headers (HSTS, X-Frame-Options, X-Content-Type-Options) are present.
+- [ ] Production endpoints use HTTPS.
+- [ ] Cloud or container configurations do not expose admin ports or secrets.
+
+## 6. Data Handling
+
+- [ ] PII, payment, or health data is handled according to relevant requirements.
+- [ ] Sensitive data is encrypted at rest and in transit.
+- [ ] Data retention and deletion requirements are respected.
+- [ ] User input is not persisted without consent or need.
+
+## 7. AI Artifacts
+
+- [ ] No placeholder secrets, `TODO` credentials, or `console.log` of tokens.
+- [ ] No empty `catch` blocks that swallow security errors.
+- [ ] No disabled certificate validation or insecure defaults left for debugging.

package/skills/shipper/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: shipper
-description: Git commit, branch creation, and PR preparation skill. Use this skill whenever the reviewer has approved the code and the user wants to ship, or when the user says 'commit', 'create PR', 'ship it', 'push changes', 'prepare for review', or any variation. This skill receives an optional review report from the reviewer, analyzes the diff to generate a Conventional Commit message, creates a properly named branch, commits the code, pushes to remote, and generates a PR link. Never use for code review — that goes to reviewer. Never use for implementation — only for git operations and PR preparation.
+description: Git commit, branch creation, and PR preparation skill. Use whenever reviewer-approved code is ready to ship or the user says 'commit', 'create PR', 'ship it', 'push changes', 'prepare for review', or similar. Creates branches, commits, pushes, and prepares PRs. Not for review or implementation.
 ---
 
 # Shipper — Commit, Branch & PR Preparation

package/skills/tester/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tester
-description: Use this skill whenever the conversation involves testing strategy, QA, test coverage, bug reproduction, edge cases, test plans, or verification of existing tests. Trigger even if the user does not say the word "test" but is asking about how to verify, reproduce, or break a feature. Competes with engineer on implementation details but wins on test design and coverage analysis.
+description: Use this skill whenever the conversation involves testing strategy, QA, test coverage, bug reproduction, edge cases, test plans, or verification of existing tests. Trigger also when the user asks how to verify, reproduce, or break a feature. Wins over engineer on test design and coverage analysis.
 ---
 
 # Tester — Quality Assurance & Test Strategy
@@ -25,6 +25,27 @@ You do NOT write production code. You do NOT run git operations. You do NOT repl
 
 ---
 
+## MEMORY & CONTEXT
+
+**Always invoke the `obsidian-second-brain` skill via the `Skill` tool.**
+Never read or write files inside `~/.lea` directly with `Read`, `Edit`, `Write`, or `Bash`.
+
+At the start of the task, the `obsidian-second-brain` skill will search and read the relevant layers for this role.
+At the end of the task, it will persist outcomes to the correct layers.
+
+This skill's targets:
+- **Read at start:** prior testing decisions, bug patterns, and acceptance criteria
+- **Persist at end:** test strategies to knowledge; bug reproductions to journal; active context to curated memory
+
+### MCP Tools Reference
+
+| Tool | When to use |
+|------|-------------|
+| `search_notes` | Find prior testing heuristics in `Knowledge/` and bug patterns in `Journal/bugs*`. |
+| `learn_from_text` | Persist a testing heuristic or decision discovered during review. |
+
+---
+
 ## WORKFLOW
 
 ### Step 1: Understand the Context
@@ -68,27 +89,6 @@ Translate requirements into verifiable statements. Example:
 
 ---
 
-## MEMORY & CONTEXT
-
-**Always invoke the `obsidian-second-brain` skill via the `Skill` tool.**
-Never read or write files inside `~/.lea` directly with `Read`, `Edit`, `Write`, or `Bash`.
-
-At the start of the task, the `obsidian-second-brain` skill will search and read the relevant layers for this role.
-At the end of the task, it will persist outcomes to the correct layers.
-
-This skill's targets:
-- **Read at start:** prior testing decisions, bug patterns, and acceptance criteria
-- **Persist at end:** test strategies to knowledge; bug reproductions to journal; active context to curated memory
-
-### MCP Tools Reference
-
-| Tool | When to use |
-|------|-------------|
-| `search_notes` | Find prior testing heuristics in `Knowledge/` and bug patterns in `Journal/bugs*`. |
-| `learn_from_text` | Persist a testing heuristic or decision discovered during review. |
-
----
-
 **What would you like to do?**
 
 - **[O] Return to Orchestrator** — Main task routing