@martinffx/atelier 0.1.0

package/skills/code-security/references/security-tools.md

@@ -0,0 +1,102 @@
+# Security Tools
+
+## Node.js
+
+### npm audit
+
+```bash
+npm audit
+npm audit fix
+npm audit --audit-level=high
+```
+
+### Snyk
+
+```bash
+npm install -g snyk
+snyk auth
+snyk test
+snyk monitor
+```
+
+### ESLint Security
+
+```bash
+npm install --save-dev eslint-plugin-security
+```
+
+.eslintrc.json:
+```json
+{
+  "plugins": ["security"],
+  "rules": {
+    "security/detect-object-injection": "error",
+    "security/detect-non-literal-fs-filename": "error"
+  }
+}
+```
+
+---
+
+## Python
+
+### pip-audit
+
+```bash
+pip install pip-audit
+pip-audit
+```
+
+### Bandit
+
+```bash
+pip install bandit
+bandit -r src/
+bandit -r src/ -f json -o report.json
+```
+
+### Safety
+
+```bash
+pip install safety
+safety check
+safety check --json
+```
+
+---
+
+## Go
+
+### govulncheck
+
+```bash
+go install golang.org/x/vuln/cmd/govulncheck@latest
+govulncheck ./...
+```
+
+### gosec
+
+```bash
+go install github.com/securego/gosec/cmd/gosec@latest
+gosec ./...
+```
+
+---
+
+## Multi-Language
+
+### Trivy
+
+```bash
+brew install trivy
+trivy fs .
+trivy fs --severity HIGH,CRITICAL .
+trivy image myimage:latest
+```
+
+### OWASP ZAP
+
+```bash
+# Docker
+docker run -p 8080:8080 owasp/zap2docker-stable zap-baseline.py -t https://example.com
+```

package/skills/code-security/references/vulnerability-patterns.md

@@ -0,0 +1,129 @@
+# Vulnerability Patterns
+
+## SQL Injection
+
+### Bad
+```python
+query = f"SELECT * FROM users WHERE id = {user_id}"
+```
+
+### Good
+```python
+query = "SELECT * FROM users WHERE id = %s"
+cursor.execute(query, (user_id,))
+```
+
+---
+
+## Command Injection
+
+### Bad
+```python
+os.system(f"ping {host}")
+```
+
+### Good
+```python
+subprocess.run(['ping', host], check=True)
+```
+
+---
+
+## XSS (Cross-Site Scripting)
+
+### Bad
+```javascript
+element.innerHTML = userInput;
+```
+
+### Good
+```javascript
+element.textContent = userInput;
+// or
+element.setAttribute('title', sanitize(userInput));
+```
+
+---
+
+## Path Traversal
+
+### Bad
+```python
+file = open(f"uploads/{filename}")
+```
+
+### Good
+```python
+import os
+base = "/app/uploads"
+filename = os.path.basename(filename)
+filepath = os.path.join(base, filename)
+if not filepath.startswith(base):
+    raise ValueError("Invalid path")
+file = open(filepath)
+```
+
+---
+
+## Hardcoded Secrets
+
+### Bad
+```javascript
+const API_KEY = "sk_live_abc123";
+```
+
+### Good
+```javascript
+const API_KEY = process.env.API_KEY;
+if (!API_KEY) throw new Error("API_KEY not set");
+```
+
+---
+
+## Insecure Random
+
+### Bad
+```javascript
+const token = Math.random().toString(36);
+```
+
+### Good
+```javascript
+const crypto = require('crypto');
+const token = crypto.randomBytes(32).toString('hex');
+```
+
+---
+
+## Unvalidated Redirect
+
+### Bad
+```javascript
+res.redirect(req.query.url);
+```
+
+### Good
+```javascript
+const allowed = ['/dashboard', '/profile'];
+if (allowed.includes(req.query.url)) {
+  res.redirect(req.query.url);
+}
+```
+
+---
+
+## Mass Assignment
+
+### Bad
+```javascript
+const user = req.body;  // All fields accepted
+```
+
+### Good
+```javascript
+const user = {
+  name: req.body.name,
+  email: req.body.email
+  // Explicitly select allowed fields
+};
+```

package/skills/code-stacked-commit/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: code-stacked-commit
+description: Manage stacked commits using Graphite. Use when the user wants to create multiple stacked commits, manage a commit stack, sync with remote, or submit PRs from a stack. Triggers on "stacked", "stack", "gt ", "graphite", or when working with multiple related commits.
+user-invocable: true
+---
+
+# Stacked Commit Skill (Graphite)
+
+Manage stacked commits using [Graphite](https://graphite.dev) - a CLI for creating and managing stacked PRs.
+
+## When to Use
+
+- User wants to break work into multiple small, reviewable commits
+- Working with stacked commits (multiple commits stacked on each other)
+- Syncing and submitting stacked PRs
+
+## Prerequisites
+
+Ensure Graphite is installed:
+```bash
+brew install graphite-dev || npm install -g @graphite-dev/cli
+```
+
+## Core Operations
+
+### 1. View Current Stack
+
+```bash
+gt stack
+```
+
+Shows all branches in the stack with their status (synced, to-push, in-progress).
+
+### 2. Create a New Commit
+
+```bash
+gt branch create "feat(auth): add JWT authentication"
+```
+
+This:
+1. Creates a new branch on top of the current stack
+2. Opens editor for commit message (or use `-m` for inline)
+3. Commits the staged changes
+
+**Works best when you:**
+- Stage specific files: `git add file1 file2`
+- Then create commit: `gt branch create "feat: add feature"`
+- Repeat for each logical unit of work
+
+### 3. Restack (Rebase onto Main)
+
+```bash
+gt branch restack
+```
+
+Rebases all branches in the stack onto the latest main. Use before submitting or when main has advanced.
+
+### 4. Sync with Remote
+
+```bash
+gt branch sync
+```
+
+Pull latest changes from remote and restack.
+
+### 5. Submit Stack as PRs
+
+```bash
+gt branch submit
+```
+
+Creates PRs for each branch in the stack. Opens browser to create the first PR; subsequent PRs link to it.
+
+### 6. Continue Working on Branch
+
+If you need to add more changes to a specific commit:
+
+```bash
+# Make your changes, stage them
+git add .
+
+# Amend to current branch
+gt branch continue
+```
+
+### 7. Navigate Stack
+
+```bash
+# Go to parent branch
+gt branch checkout @parent
+
+# Go to child branch  
+gt branch checkout @child
+```
+
+## Workflow Example
+
+```
+# Start new feature work
+git checkout main
+gt branch create "feat(api): add user endpoint"
+
+# Add user endpoint code
+git add src/users/
+gt branch continue  # Amend to current commit
+
+# Create next commit in stack
+gt branch create "feat(api): add user validation"
+
+# Add validation code  
+git add src/validation/
+gt branch continue
+
+# View stack
+gt stack
+
+# Restack before submit
+gt branch restack
+
+# Submit all as stacked PRs
+gt branch submit
+```
+
+## Best Practices
+
+1. **One logical change per commit** - Each commit should be reviewable independently
+2. **Meaningful commit messages** - Use conventional commit format
+3. **Restack before submit** - Always `gt branch restack` before submitting to ensure clean history
+4. **Keep stack small** - Deep stacks can be hard to manage; 3-5 commits is ideal
+5. **Sync regularly** - Run `gt branch sync` often when working with others
+
+## Troubleshooting
+
+| Issue | Solution |
+|-------|----------|
+| Conflicts during restack | Resolve in editor, then `gt branch continue` |
+| Stack broken | `gt branch repair` to fix detached HEAD |
+| Too many branches | `gt branch delete <name>` to remove (won't delete remote) |
+
+## Commit Message Format
+
+Follow conventional commits within the Graphite workflow:
+
+```
+<type>(<scope>): <subject>
+
+[optional body]
+```
+
+Examples:
+```
+feat(api): add user profile endpoint
+fix(db): resolve connection pool exhaustion
+docs(readme): update installation instructions
+```

package/skills/code-subagents/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: code-subagents
+description: >
+  Subagent dispatch patterns for implementation tasks. Use when spec-implement has multiple
+  tasks to execute and subagents are available. Covers parallel dispatch for independent work,
+  the two-stage review cycle (spec compliance then code quality), focused prompt construction,
+  and integration of results. Trigger when executing plan tasks with subagent support, when
+  facing 2+ independent problems, or when the user asks to use subagents for implementation.
+user-invocable: false
+---
+
+# Spec Subagents
+
+Fresh subagent per task. Two-stage review after each. Parallel when independent, sequential
+when dependent.
+
+## When to Use Subagents
+
+**Use when:**
+- Executing tasks from plan.json with subagent support available
+- 2+ independent tasks that don't share state or files
+- Each problem can be understood without context from others
+
+**Don't use when:**
+- Tasks are tightly coupled (editing the same files)
+- You need to understand full system state across tasks
+- Failures are related (fixing one might fix others)
+- Exploratory work where the problem isn't well-defined yet
+
+## Dispatch Modes
+
+### Sequential (dependent tasks)
+
+Tasks with dependencies execute one at a time. Each gets a fresh subagent — no context
+pollution from previous tasks.
+
+```
+Task 1 (Entity) → review → complete
+Task 2 (Repository, depends on T1) → review → complete
+Task 3 (Service, depends on T2) → review → complete
+```
+
+### Parallel (independent tasks)
+
+Independent tasks dispatch simultaneously. One agent per problem domain.
+
+```
+Task A (auth tests) ──→ review → complete
+Task B (billing tests) ──→ review → complete    ← concurrent
+Task C (notification tests) ──→ review → complete
+```
+
+**Independence check:** Would fixing Task A affect Task B? Would they edit the same files?
+If no to both, dispatch in parallel.
+
+---
+
+## Prompt Templates
+
+Use these templates when dispatching subagents. Each template is battle-tested — don't
+improvise, use them as-is and fill in the variables.
+
+- **[references/implementer-prompt.md](references/implementer-prompt.md)** — Dispatch an implementer. Includes self-review checklist.
+- **[references/spec-reviewer-prompt.md](references/spec-reviewer-prompt.md)** — Spec compliance review. "Do not trust the report."
+- **[references/code-quality-reviewer-prompt.md](references/code-quality-reviewer-prompt.md)** — Code quality review. Critical/Important/Minor severity.
+
+### Prompt quality rules
+
+- **Focused** — one task, one problem domain
+- **Self-contained** — all context needed is in the prompt. Don't make the subagent
+  read the plan file; provide the full task text
+- **Specific about files** — exact paths, not "the relevant files"
+- **Specific about output** — what should the subagent return?
+- **Constrained** — what should they NOT touch?
+
+### Common mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| "Fix all the tests" | "Fix the 3 failures in user.test.ts" |
+| No context about codebase | Paste the relevant patterns and conventions |
+| No constraints | "Do NOT change production code" or scope to specific files |
+| Vague output expectations | "Return: root cause, changes made, test results" |
+
+---
+
+## Two-Stage Review
+
+Every completed task gets two reviews in order. Do not skip either. Do not reverse the order.
+
+### Stage 1: Spec Compliance
+
+Does the implementation match what was specified?
+
+```markdown
+## Spec Review
+
+Review the implementation against the task specification:
+
+**Task spec:** [paste task from plan.json]
+
+**Files changed:** [list from subagent output]
+
+Check:
+1. Are all requirements from the task spec implemented?
+2. Is anything implemented that wasn't specified? (over-building)
+3. Do tests cover the specified acceptance criteria?
+4. Does the implementation match the design in design.md?
+
+Report: List any gaps or extras. Mark ✅ if compliant, ❌ if not.
+```
+
+If the spec reviewer finds issues → the implementer subagent fixes them → spec reviewer
+reviews again. Repeat until ✅.
+
+### Stage 2: Code Quality
+
+Is the implementation well-built?
+
+```markdown
+## Code Quality Review
+
+Review the implementation for code quality:
+
+**Files changed:** [list]
+
+Check:
+1. Does the code follow existing patterns and conventions?
+2. Are tests meaningful (not just asserting true)?
+3. Is there unnecessary complexity?
+4. Are edge cases handled?
+5. Is the code clean (no dead code, no unnecessary comments)?
+
+Rate issues as Critical (blocks merge), Important (should fix), or Minor (nice to have).
+```
+
+If the quality reviewer finds Critical or Important issues → implementer fixes → reviewer
+reviews again. Minor issues can be noted and moved past.
+
+### Why this order matters
+
+Spec compliance first because there's no point polishing code that doesn't meet the spec.
+Quality second because compliant code still needs to be well-built.
+
+---
+
+## Handling Subagent Questions
+
+Subagents may ask questions before or during implementation. This is good — it means
+they're thinking rather than guessing.
+
+- Answer clearly and completely
+- Provide additional context if needed
+- Don't rush them into implementation
+- If the question reveals a gap in the plan, that's valuable — note it
+
+---
+
+## Integrating Results
+
+After subagents complete (especially parallel dispatch):
+
+1. **Read each summary** — understand what changed
+2. **Check for conflicts** — did any agents edit the same code?
+3. **Run full test suite** — verify all changes work together
+4. **Update task tracking** — mark tasks complete: beads `bd close <id>`, or harness todo list
+
+If there are conflicts between parallel results, resolve them manually. Don't dispatch
+another subagent to merge — that requires too much context.
+
+---
+
+## When Subagents Fail
+
+If a subagent fails a task:
+
+- **Don't fix it manually** — that pollutes your context
+- **Dispatch a fix subagent** with specific instructions about what went wrong
+- **If it fails twice**, stop and escalate to the human. The plan may need revision.
+
+If failure reveals a design problem:
+
+> "This task is failing because [reason]. The design in design.md may need to change.
+> Want me to go back to spec-brainstorm?"

package/skills/code-subagents/references/code-quality-reviewer-prompt.md

@@ -0,0 +1,48 @@
+# Code Quality Reviewer Prompt Template
+
+Dispatch after the spec compliance review passes (✅). Verifies the implementation is
+well-built — clean, tested, maintainable.
+
+**Only dispatch after spec compliance is confirmed.**
+
+## Template
+
+```
+You are reviewing code quality for Task {TASK_ID}: {TASK_NAME}
+
+## What Was Implemented
+
+{From implementer's report — what they built}
+
+## Requirements Reference
+
+Task {TASK_ID} from {PLAN_FILE_PATH}
+
+## Diff Range
+
+Base: {BASE_SHA} (commit before task)
+Head: {HEAD_SHA} (current commit)
+
+## Your Job
+
+Review the implementation for quality:
+
+1. Does the code follow existing patterns and conventions in the codebase?
+2. Are tests meaningful (not just asserting true or testing mocks)?
+3. Is there unnecessary complexity?
+4. Are edge cases handled?
+5. Is the code clean (no dead code, no unnecessary comments, clear naming)?
+6. Are the right things tested at the right boundaries (unit vs integration)?
+
+## Issue Severity
+
+- **Critical** — Blocks merge. Bugs, security issues, broken tests, missing error handling.
+- **Important** — Should fix. Magic numbers, unclear naming, missing edge cases, poor test design.
+- **Minor** — Nice to have. Style preferences, minor refactors, documentation suggestions.
+
+## Report
+
+- **Strengths:** What was done well
+- **Issues:** List with severity (Critical / Important / Minor) and file:line references
+- **Assessment:** Approved, Approved with minor issues, or Changes requested
+```

package/skills/code-subagents/references/implementor-prompt.md

@@ -0,0 +1,79 @@
+# Implementer Prompt Template
+
+Use this template when dispatching an implementer subagent. Paste the full task text from
+plan.json — don't make the subagent read the plan file.
+
+## Template
+
+```
+You are implementing Task {TASK_ID}: {TASK_NAME}
+
+## Task Description
+
+{FULL TEXT of task from plan.json — paste it here}
+
+## Context
+
+{Scene-setting: where this fits in the feature, what was built before this task,
+relevant architectural decisions from design.md, existing patterns to follow}
+
+## Before You Begin
+
+If you have questions about:
+- The requirements or acceptance criteria
+- The approach or implementation strategy
+- Dependencies or assumptions
+- Anything unclear in the task description
+
+**Ask them now.** Raise any concerns before starting work.
+
+## Your Job
+
+Once you're clear on requirements:
+1. Implement exactly what the task specifies
+2. Write tests following TDD (failing test → verify fail → implement → verify pass)
+3. Verify implementation works
+4. Commit your work
+5. Self-review (see below)
+6. Report back
+
+Work from: {WORKING_DIRECTORY}
+
+**While you work:** If you encounter something unexpected or unclear, ask questions.
+It's always OK to pause and clarify. Don't guess or make assumptions.
+
+## Before Reporting Back: Self-Review
+
+Review your work with fresh eyes:
+
+**Completeness:**
+- Did I fully implement everything in the spec?
+- Did I miss any requirements?
+- Are there edge cases I didn't handle?
+
+**Quality:**
+- Is this my best work?
+- Are names clear and accurate?
+- Is the code clean and maintainable?
+
+**Discipline:**
+- Did I avoid overbuilding (YAGNI)?
+- Did I only build what was requested?
+- Did I follow existing patterns in the codebase?
+
+**Testing:**
+- Do tests actually verify behaviour (not just mock behaviour)?
+- Did I follow TDD?
+- Are tests comprehensive?
+
+If you find issues during self-review, fix them before reporting.
+
+## Report Format
+
+When done, report:
+- What you implemented
+- What you tested and test results
+- Files changed
+- Self-review findings (if any)
+- Any issues or concerns
+```