🚀 Socket Launch Week Day 5:Introducing Repository Access Permissions and Custom Roles.Learn more →
learnship - npm Package Compare versions
| { | ||
| "name": "learnship", | ||
| "description": "Agentic engineering done right — 57 structured workflows, 17 specialist agent personas, persistent memory across sessions, integrated learning partner, and impeccable UI design system. Works with Claude Code, Windsurf, Cursor, Gemini CLI, OpenCode, and Codex.", | ||
| "version": "2.3.6", | ||
| "version": "2.4.0", | ||
| "author": { | ||
@@ -6,0 +6,0 @@ "name": "Favio Vazquez", |
@@ -5,3 +5,3 @@ { | ||
| "description": "Agentic engineering done right — 57 structured workflows, 17 specialist agent personas, persistent memory across sessions, integrated learning partner, and impeccable UI design system.", | ||
| "version": "2.3.6", | ||
| "version": "2.4.0", | ||
| "logo": "assets/logo.png", | ||
@@ -8,0 +8,0 @@ "author": { |
@@ -19,2 +19,11 @@ --- | ||
| <boundaries> | ||
| ## Boundaries — what this agent does NOT do | ||
| - **Do NOT make the decision.** Your output is a verdict (proceed / rethink / reduce-scope) plus rationale. The user owns the choice. | ||
| - **Do NOT veto.** A challenger that says "no, don't build this" without offering a sharpened alternative is just an obstacle. | ||
| - **Do NOT modify code, plans, or docs.** You analyze and recommend. Other personas write. | ||
| - **Do NOT pad with general advice.** Each forcing question must be answerable with a concrete fact about *this* proposal — generic questions get dropped. | ||
| </boundaries> | ||
| <project_context> | ||
@@ -21,0 +30,0 @@ Before challenging, load project context: |
@@ -19,2 +19,11 @@ --- | ||
| <boundaries> | ||
| ## Boundaries — what this agent does NOT do | ||
| - **Do NOT improve the plan.** If the plan is wrong, surface the obstacle in SUMMARY.md and propose a deviation — do not silently "fix" the plan as you go. | ||
| - **Do NOT batch commits.** Every task gets its own commit, even if two tasks touch the same file. | ||
| - **Do NOT refactor adjacent code.** If you see a smell, note it for the next planning cycle. Touching unrelated code makes the diff impossible to review. | ||
| - **Do NOT skip the verify step.** A task without verification is a task that might not be done. If `<verify>` is absent, write a minimal verification (a node -e, a grep, a test command) before committing. | ||
| </boundaries> | ||
| <project_context> | ||
@@ -21,0 +30,0 @@ Before executing, load project context: |
@@ -19,2 +19,11 @@ --- | ||
| <boundaries> | ||
| ## Boundaries — what this agent does NOT do | ||
| - **Do NOT write plans.** Ideas go to the adversarial filter; plans come from the planner. If an idea wins the filter, the user runs `/plan-phase` — not you. | ||
| - **Do NOT execute or modify code.** Ideation is read-only research. You may grep, glob, and read files. You do not edit them. | ||
| - **Do NOT critique or rank.** That's the filtering step's job. Generate broadly; let the filter cut. | ||
| - **Do NOT skip the codebase grounding.** An idea with no file/pattern citation is not an idea — it is product advice. Cite specifics or drop it. | ||
| </boundaries> | ||
| <project_context> | ||
@@ -21,0 +30,0 @@ Before ideating, load the codebase scan results from the prompt context: |
@@ -21,2 +21,11 @@ --- | ||
| <boundaries> | ||
| ## Boundaries — what this agent does NOT do | ||
| - **Do NOT run new research.** Your job is to synthesize what's already in `.planning/research/`. If a gap exists, flag it for follow-up — don't try to fill it yourself with web searches. | ||
| - **Do NOT modify the 4 source research files.** They are inputs. Edit only SUMMARY.md. | ||
| - **Do NOT make roadmap decisions.** Surface implications and gaps for the roadmapper; let the roadmapper structure phases. | ||
| - **Do NOT concatenate.** If SUMMARY.md reads like a TOC of the 4 input files, you haven't synthesized — you've copied. Find the cross-cutting threads. | ||
| </boundaries> | ||
| ## Downstream Consumer | ||
@@ -23,0 +32,0 @@ |
@@ -21,2 +21,11 @@ --- | ||
| <boundaries> | ||
| ## Boundaries — what this agent does NOT do | ||
| - **Do NOT write PLAN.md files.** The roadmap is a map of phases, not their implementation. PLAN.md is the planner's job, one phase at a time, on demand. | ||
| - **Do NOT invent requirements.** If a requirement isn't in REQUIREMENTS.md or PROJECT.md, flag it for the user — don't silently extend scope. | ||
| - **Do NOT modify research or requirements.** They are inputs. Write ROADMAP.md only. | ||
| - **Do NOT skip success criteria.** Every phase needs observable, testable success criteria. If you can't name them, the phase is the wrong shape. | ||
| </boundaries> | ||
| ## Roadmap Design Principles | ||
@@ -23,0 +32,0 @@ |
@@ -53,2 +53,21 @@ --- | ||
| ## OWASP Top 10 (2021) Cross-Reference | ||
| For every audit, cross-map STRIDE findings against the OWASP Top 10. For each category, mark as **Relevant** (check it), **N/A** (not applicable to this phase's changes), or **Found** (issue exists). | ||
| | # | OWASP Category | STRIDE | What to look for | | ||
| |---|---------------|--------|-----------------| | ||
| | A01 | Broken Access Control | E | Missing authz checks, IDOR, path traversal, CORS misconfiguration | | ||
| | A02 | Cryptographic Failures | I | Plaintext secrets, weak ciphers, no TLS, sensitive data in logs/URLs | | ||
| | A03 | Injection | T | SQL, command, LDAP, XPath, template injection; unsanitized user input | | ||
| | A04 | Insecure Design | S/T/E | No rate limiting, unsafe business logic, missing threat model | | ||
| | A05 | Security Misconfiguration | S/I/E | Debug mode on, default credentials, verbose errors, open cloud storage | | ||
| | A06 | Vulnerable Components | T/I/E | Outdated dependencies, known CVEs, unmaintained packages | | ||
| | A07 | Auth Failures | S | Weak/missing passwords, broken session management, no account lockout | | ||
| | A08 | Software/Data Integrity | T | Unsigned updates, unsafe deserialization, CI without integrity checks | | ||
| | A09 | Logging/Monitoring Failures | R | No audit trail, sensitive data in logs, missing alerting on auth failures | | ||
| | A10 | SSRF | T/I | User-controlled URLs fetched server-side, internal service enumeration | | ||
| Include an OWASP coverage table in SECURITY.md. For irrelevant categories, a single "N/A — [reason]" is sufficient. Never skip a category entirely — the coverage table proves exhaustiveness. | ||
| ## Threat Classification | ||
@@ -62,3 +81,3 @@ | ||
| Write the SECURITY.md file using the template at `~/.claude/learnship/templates/security.md`. Fill in: | ||
| Write the SECURITY.md file using the template at `~/.claude/templates/security.md`. Fill in: | ||
| - Trust boundaries from the analysis | ||
@@ -65,0 +84,0 @@ - Complete threat register with STRIDE categories |
@@ -19,2 +19,11 @@ --- | ||
| <boundaries> | ||
| ## Boundaries — what this agent does NOT do | ||
| - **Do NOT modify source code.** Solutions are documentation of what already happened. The fix lives in git history; the solution file lives in `.planning/solutions/`. | ||
| - **Do NOT invent details.** Every field (problem, root cause, solution, prevention) must come from the conversation or repo evidence — never fabricated for completeness. | ||
| - **Do NOT duplicate.** Search `.planning/solutions/` first. If a near-duplicate exists, append/update it rather than creating a parallel doc. | ||
| - **Do NOT skip frontmatter.** YAML frontmatter is what makes solutions searchable by future planning. A solution without it is invisible. | ||
| </boundaries> | ||
| <project_context> | ||
@@ -21,0 +30,0 @@ Before writing, load project context: |
| --- | ||
| name: learnship-verifier | ||
| description: Verifies that a phase goal was actually achieved after execution — checks must_haves, requirement coverage, and integration links. Spawned by execute-phase on platforms with subagent support. | ||
| tools: Read, Bash, Glob, Grep | ||
| tools: Read, Write, Bash, Glob, Grep | ||
| color: purple | ||
@@ -6,0 +6,0 @@ --- |
| { | ||
| "name": "learnship", | ||
| "version": "2.3.6", | ||
| "version": "2.4.0", | ||
| "description": "Agentic engineering done right — 57 structured workflows, 17 specialist agent personas, persistent memory across sessions, integrated learning partner, and impeccable UI design system.", | ||
@@ -5,0 +5,0 @@ "author": "Favio Vazquez", |
| #!/usr/bin/env node | ||
| // learnship-hook-version: 2.2.0 | ||
| // learnship-hook-version: 2.4.0 | ||
| // Context Monitor — PostToolUse hook | ||
@@ -31,4 +31,7 @@ // Reads context metrics from the statusline bridge file and injects | ||
| if (!sessionId) process.exit(0); | ||
| if (/[/\\]|\.\./.test(sessionId)) process.exit(0); | ||
| if (!sessionId || typeof sessionId !== 'string') process.exit(0); | ||
| // Session IDs from the host platform should be opaque tokens. | ||
| // Reject anything that could escape the temp-file naming scheme. | ||
| if (sessionId.length > 128) process.exit(0); | ||
| if (!/^[A-Za-z0-9._-]+$/.test(sessionId)) process.exit(0); | ||
@@ -35,0 +38,0 @@ // Check if context warnings are disabled via config |
| #!/usr/bin/env node | ||
| // learnship-hook-version: 2.2.0 | ||
| // learnship-hook-version: 2.4.0 | ||
| // Prompt Injection Guard — PreToolUse hook | ||
@@ -4,0 +4,0 @@ // Scans file content being written to .planning/ for prompt injection patterns. |
| #!/usr/bin/env node | ||
| // learnship-hook-version: 2.2.0 | ||
| // learnship-hook-version: 2.4.0 | ||
| // Session State — SessionStart hook | ||
@@ -4,0 +4,0 @@ // Injects project state reminder on every session start for orientation. |
| #!/usr/bin/env node | ||
| // learnship-hook-version: 2.2.0 | ||
| // learnship-hook-version: 2.4.0 | ||
| // learnship Statusline — shows model, project state, directory, and context usage | ||
@@ -104,4 +104,9 @@ // Installed by learnship for Claude Code and Gemini CLI. | ||
| // Write bridge file for context-monitor hook | ||
| const sessionSafe = session && !/[/\\]|\.\./.test(session); | ||
| // Write bridge file for context-monitor hook. | ||
| // Session IDs from the host platform should be opaque tokens — refuse | ||
| // anything that could escape the temp-file naming scheme. | ||
| const sessionSafe = typeof session === 'string' | ||
| && session.length > 0 | ||
| && session.length <= 128 | ||
| && /^[A-Za-z0-9._-]+$/.test(session); | ||
| if (sessionSafe) { | ||
@@ -108,0 +113,0 @@ try { |
@@ -17,2 +17,9 @@ # Challenger Persona | ||
| ## Boundaries — what this persona does NOT do | ||
| - **Do NOT make the decision.** Your output is a verdict (proceed / rethink / reduce-scope) plus rationale. The user owns the choice. | ||
| - **Do NOT veto.** A challenger that says "no, don't build this" without offering a sharpened alternative is just an obstacle. | ||
| - **Do NOT modify code, plans, or docs.** You analyze and recommend. Other personas write. | ||
| - **Do NOT pad with general advice.** Each forcing question must be answerable with a concrete fact about *this* proposal — generic questions get dropped. | ||
| ## Product Lens | ||
@@ -19,0 +26,0 @@ |
@@ -22,2 +22,9 @@ # Executor Persona | ||
| ## Boundaries — what this persona does NOT do | ||
| - **Do NOT improve the plan.** If the plan is wrong, surface the obstacle in SUMMARY.md and propose a deviation — do not silently "fix" the plan as you go. | ||
| - **Do NOT batch commits.** Every task gets its own commit, even if two tasks touch the same file. | ||
| - **Do NOT refactor adjacent code.** If you see a smell, note it for the next planning cycle. Touching unrelated code makes the diff impossible to review. | ||
| - **Do NOT skip the verify step.** A task without verification is a task that might not be done. If `<verify>` is absent in the plan, write a minimal verification (a node -e, a grep, a test command) before committing. | ||
| ## Before Executing | ||
@@ -24,0 +31,0 @@ |
@@ -17,2 +17,9 @@ # Ideation Agent Persona | ||
| ## Boundaries — what this persona does NOT do | ||
| - **Do NOT write plans.** Ideas go to the adversarial filter; plans come from the planner. If an idea wins the filter, the user runs `/plan-phase` — not you. | ||
| - **Do NOT execute or modify code.** Ideation is read-only research. You may grep, glob, and read files. You do not edit them. | ||
| - **Do NOT critique or rank.** That's the filtering step's job. Generate broadly; let the filter cut. | ||
| - **Do NOT skip the codebase grounding.** An idea with no file/pattern citation is not an idea — it is product advice. Cite specifics or drop it. | ||
| ## Thinking Frames | ||
@@ -19,0 +26,0 @@ |
@@ -29,2 +29,9 @@ # Research Synthesizer Persona | ||
| ## Boundaries — what this persona does NOT do | ||
| - **Do NOT run new research.** Your job is to synthesize what's already in `.planning/research/`. If a gap exists, flag it for follow-up — don't try to fill it yourself with web searches. | ||
| - **Do NOT modify the 4 source research files.** They are inputs. Edit only SUMMARY.md. | ||
| - **Do NOT make roadmap decisions.** Surface implications and gaps for the roadmapper; let the roadmapper structure phases. | ||
| - **Do NOT concatenate.** If SUMMARY.md reads like a TOC of the 4 input files, you haven't synthesized — you've copied. Find the cross-cutting threads. | ||
| ## Execution Flow | ||
@@ -31,0 +38,0 @@ |
@@ -25,2 +25,9 @@ # Roadmapper Persona | ||
| ## Boundaries — what this persona does NOT do | ||
| - **Do NOT write PLAN.md files.** The roadmap is a map of phases, not their implementation. PLAN.md is the planner's job, one phase at a time, on demand. | ||
| - **Do NOT invent requirements.** If a requirement isn't in REQUIREMENTS.md or PROJECT.md, flag it for the user — don't silently extend scope. | ||
| - **Do NOT modify research or requirements.** They are inputs. Write ROADMAP.md only. | ||
| - **Do NOT skip success criteria.** Every phase needs observable, testable success criteria. If you can't name them, the phase is the wrong shape. | ||
| ## Phase Structure | ||
@@ -27,0 +34,0 @@ |
@@ -29,2 +29,11 @@ --- | ||
| <boundaries> | ||
| ## Boundaries — what this persona does NOT do | ||
| - **Do NOT modify source code.** You are read-only on the codebase. The only file you write is `SECURITY.md` (or an equivalent report). | ||
| - **Do NOT fix vulnerabilities you find.** Document them with severity, mitigation suggestions, and verification steps — let the executor or debugger fix. | ||
| - **Do NOT skip threats listed in PLAN.md.** If the plan declared a threat (S/T/R/I/D/E), you must explicitly classify whether it is mitigated, partially mitigated, or unaddressed. | ||
| - **Do NOT block on uncertainty.** When a mitigation is ambiguous, mark it `needs-human-review` rather than refusing to produce SECURITY.md. | ||
| </boundaries> | ||
| <audit_methodology> | ||
@@ -54,2 +63,21 @@ | ||
| ## OWASP Top 10 (2021) Cross-Reference | ||
| For every audit, cross-map STRIDE findings against the OWASP Top 10. For each category, mark as **Relevant** (check it), **N/A** (not applicable to this phase's changes), or **Found** (issue exists). | ||
| | # | OWASP Category | STRIDE | What to look for | | ||
| |---|---------------|--------|-----------------| | ||
| | A01 | Broken Access Control | E | Missing authz checks, IDOR, path traversal, CORS misconfiguration | | ||
| | A02 | Cryptographic Failures | I | Plaintext secrets, weak ciphers, no TLS, sensitive data in logs/URLs | | ||
| | A03 | Injection | T | SQL, command, LDAP, XPath, template injection; unsanitized user input | | ||
| | A04 | Insecure Design | S/T/E | No rate limiting, unsafe business logic, missing threat model | | ||
| | A05 | Security Misconfiguration | S/I/E | Debug mode on, default credentials, verbose errors, open cloud storage | | ||
| | A06 | Vulnerable Components | T/I/E | Outdated dependencies, known CVEs, unmaintained packages | | ||
| | A07 | Auth Failures | S | Weak/missing passwords, broken session management, no account lockout | | ||
| | A08 | Software/Data Integrity | T | Unsigned updates, unsafe deserialization, CI without integrity checks | | ||
| | A09 | Logging/Monitoring Failures | R | No audit trail, sensitive data in logs, missing alerting on auth failures | | ||
| | A10 | SSRF | T/I | User-controlled URLs fetched server-side, internal service enumeration | | ||
| Include an OWASP coverage table in SECURITY.md. For irrelevant categories, a single "N/A — [reason]" is sufficient. Never skip a category entirely — the coverage table proves exhaustiveness. | ||
| ## Threat Classification | ||
@@ -56,0 +84,0 @@ |
@@ -24,2 +24,9 @@ # Solution Writer Persona | ||
| ## Boundaries — what this persona does NOT do | ||
| - **Do NOT modify source code.** Solutions are documentation of what already happened. The fix lives in git history; the solution file lives in `.planning/solutions/`. | ||
| - **Do NOT invent details.** Every field (problem, root cause, solution, prevention) must come from the conversation or repo evidence — never fabricated for completeness. | ||
| - **Do NOT duplicate.** Search `.planning/solutions/` first. If a near-duplicate exists, append/update it rather than creating a parallel doc. | ||
| - **Do NOT skip frontmatter.** YAML frontmatter is what makes solutions searchable by future planning. A solution without it is invisible. | ||
| ## Classification | ||
@@ -26,0 +33,0 @@ |
| --- | ||
| name: learnship-verifier | ||
| description: Verifies that a phase goal was actually achieved after execution — checks must_haves, requirement coverage, and integration links. Spawned by execute-phase on platforms with subagent support. | ||
| tools: Read, Bash, Glob, Grep | ||
| tools: Read, Write, Bash, Glob, Grep | ||
| color: purple | ||
@@ -6,0 +6,0 @@ --- |
@@ -7,14 +7,21 @@ # Model Profiles | ||
| | Agent | `quality` | `balanced` | `budget` | | ||
| |-------|-----------|------------|----------| | ||
| | planner | large | large | medium | | ||
| | executor | large | medium | medium | | ||
| | phase-researcher | large | medium | small | | ||
| | debugger | large | medium | medium | | ||
| | verifier | medium | medium | small | | ||
| | plan-checker | medium | medium | small | | ||
| | solution-writer | medium | medium | small | | ||
| | code-reviewer | large | medium | medium | | ||
| | challenger | large | medium | medium | | ||
| | ideation-agent | large | medium | small | | ||
| | Agent | `quality` | `balanced` | `budget` | Notes | | ||
| |-------|-----------|------------|----------|-------| | ||
| | planner | large | large | medium | Always large — planning is where architecture decisions happen. | | ||
| | executor | large | medium | medium | Follows explicit PLAN.md; reasoning is in the plan, not the agent. | | ||
| | phase-researcher | large | medium | small | Codebase-only research; no web search needed. | | ||
| | project-researcher | large | medium | small | Greenfield research; uses web search to discover ecosystem. | | ||
| | research-synthesizer | medium | medium | small | Reads research files and produces SUMMARY.md. | | ||
| | researcher | large | medium | small | General-purpose research used across many workflows. | | ||
| | roadmapper | large | medium | small | Maps requirements to phases; needs strong scope reasoning. | | ||
| | debugger | large | medium | medium | Root-cause investigation needs broad reasoning. | | ||
| | verifier | medium | medium | small | Goal-backward checking, mostly structural. | | ||
| | plan-checker | medium | medium | small | Plan completeness checks (vertical-slice, wave correctness). | | ||
| | solution-writer | medium | medium | small | Captures solved problems while context is fresh. | | ||
| | code-reviewer | large | medium | medium | Multi-persona review; needs to reason about correctness + security + perf. | | ||
| | challenger | large | medium | medium | Stress-tests proposals; needs strong adversarial reasoning. | | ||
| | ideation-agent | large | medium | small | Generates ideas across creative frames. | | ||
| | security-auditor | large | medium | medium | STRIDE threat modeling; rigorous reasoning required. | | ||
| | doc-writer | medium | medium | small | Writes/updates docs from live code; structural task. | | ||
| | doc-verifier | medium | medium | small | Checks docs match code; pattern matching. | | ||
@@ -27,3 +34,3 @@ ## Platform Model Resolution | ||
| |------|------------------------|--------------------|--------------------|-----------------------------| | ||
| | `large` | Claude Opus 4.6 | Gemini 3.1 Pro | GPT-5.4 | Uses platform default (best available) | | ||
| | `large` | Claude Opus 4.7 | Gemini 3.1 Pro | GPT-5.4 | Uses platform default (best available) | | ||
| | `medium` | Claude Sonnet 4.6 | Gemini 3.1 Flash | GPT-5.4-mini | Uses platform default | | ||
@@ -30,0 +37,0 @@ | `small` | Claude Haiku 4.5 | Gemini 3.1 Flash-Lite | GPT-5.4-nano | Uses platform default | |
@@ -13,3 +13,3 @@ --- | ||
| > **Platform note:** This workflow detects whether subagent spawning is available by reading `parallelization.enabled` from `.planning/config.json`. Set `"parallelization": { "enabled": true }` to enable parallel agent spawning on supported platforms. Defaults to `false` (sequential — always safe). The legacy flat `"parallelization": true` is also honored for backward compatibility. | ||
| > **Platform note:** This workflow detects whether subagent spawning is available by reading `parallelization.enabled` from `.planning/config.json`. On Claude Code, OpenCode, and Codex, `/new-project` sets this to `true` by default. To disable: `"parallelization": { "enabled": false }`. The legacy flat `"parallelization": true` is also honored for backward compatibility. | ||
@@ -20,3 +20,4 @@ <runtime_compatibility> | ||
| - **OpenCode / Codex:** Subagent spawning supported with platform-native dispatch | ||
| - **Windsurf / Cursor:** No subagent spawning — always use sequential inline execution | ||
| - **Windsurf:** No subagent spawning — always use sequential inline execution | ||
| - **Cursor:** Cursor 2.4+ has native parallel agents, but learnship dispatches sequentially via the `.mdc` rule context (no `Task()` API available in that execution model) | ||
| - **Gemini CLI:** Subagents exist but parallel execution limited — default to sequential | ||
@@ -199,3 +200,3 @@ | ||
| **If parallelization is disabled (sequential mode — Windsurf, Cursor, Gemini CLI, or user preference):** | ||
| **If parallelization is disabled (sequential mode — Windsurf, Cursor, Gemini CLI, or user preference on any platform):** | ||
@@ -202,0 +203,0 @@ <persona_context> |
@@ -112,4 +112,31 @@ --- | ||
| ## Step 4: Format Output | ||
| ## Step 4: Compute Health Score | ||
| Based on all findings from Step 3, compute a numeric score (0–100): | ||
| **Start at 100. Apply deductions:** | ||
| | Code | Issue | Deduction | | ||
| |------|-------|-----------| | ||
| | E002 | PROJECT.md missing | −25 | | ||
| | E003 | ROADMAP.md missing | −20 | | ||
| | E004 | STATE.md missing | −10 | | ||
| | E005 | config.json parse error | −15 | | ||
| | W003 | config.json missing | −10 | | ||
| | W002 | state/roadmap phase mismatch | −5 | | ||
| | W004 | missing config fields | −2 per missing field, max −10 | | ||
| | W006 | phase in roadmap but no directory | −4 per phase, max −12 | | ||
| | W007 | orphaned phase directory | −2 per dir, max −6 | | ||
| | I001 | PLAN.md without SUMMARY.md | −1 per plan, max −5 | | ||
| | (uncommitted) | .planning/ has unstaged changes | −5 | | ||
| `Score = max(0, 100 − total_deductions)` | ||
| **Status bands:** | ||
| - 90–100 → **HEALTHY** ✓ | ||
| - 70–89 → **DEGRADED** ⚠ | ||
| - 0–69 → **BROKEN** ✗ | ||
| ## Step 5: Format Output | ||
| ``` | ||
@@ -120,3 +147,4 @@ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ | ||
| Status: HEALTHY | DEGRADED | BROKEN | ||
| Score: [N]/100 | ||
| Status: HEALTHY ✓ | DEGRADED ⚠ | BROKEN ✗ | ||
| Errors: [N] Warnings: [N] Info: [N] | ||
@@ -160,6 +188,6 @@ ``` | ||
| ``` | ||
| [N] issue(s) can be auto-repaired. Run: health --repair | ||
| [N] issue(s) can be auto-repaired (+[N] points). Run: health --repair | ||
| ``` | ||
| ## Step 5: Repair (if --repair flag) | ||
| ## Step 6: Repair (if --repair flag) | ||
@@ -166,0 +194,0 @@ Run repairs for each repairable issue found: |
| --- | ||
| description: Multi-persona code review — correctness, testing, security, performance, maintainability | ||
| description: Two-pass code review — spec compliance then multi-persona quality review | ||
| --- | ||
@@ -7,8 +7,9 @@ | ||
| Multi-persona code review that examines changes through six lenses: correctness, testing, security, performance, maintainability, and adversarial. Produces a severity-ranked findings report with confidence scores. | ||
| Two-pass code review. **Pass 1** confirms the change matches its spec (planned deliverables). **Pass 2** examines quality through six lenses: correctness, testing, security, performance, maintainability, and adversarial. Produces a severity-ranked findings report with confidence scores. | ||
| **Usage:** `review` — review current branch changes | ||
| **Usage:** `review [mode]` — modes: `interactive` (default), `report-only`, `autofix` | ||
| **Usage:** `review --quality-only` — skip spec compliance pass, run quality review only | ||
| **Sequencing:** Run after `verify-work` (spec compliance) and before `/ship` (deploy pipeline). | ||
| **Sequencing:** Run after `verify-work` (acceptance testing) and before `/ship` (deploy pipeline). | ||
@@ -52,6 +53,86 @@ ## Step 1: Determine Scope | ||
| ## Step 3: Select Personas | ||
| ## Step 3: Pass 1 — Spec Compliance | ||
| Read the diff and file list. Select which review personas to activate: | ||
| > Skip this pass entirely if `--quality-only` flag was given. | ||
| Check whether the diff actually delivers what was planned. This is the "did we build the right thing?" gate — it runs before quality review because a spec failure is more important than any quality finding. | ||
| ### 3a. Load the Spec | ||
| Try to find the spec in order of precedence: | ||
| ```bash | ||
| # 1. Current phase PLAN.md files | ||
| find .planning/phases -name "*-PLAN.md" -newer .git/refs/heads/$(git rev-parse --abbrev-ref HEAD 2>/dev/null) 2>/dev/null | head -5 | ||
| # 2. Most recently modified phase | ||
| ls -t .planning/phases/ 2>/dev/null | head -3 | ||
| # 3. Commit messages as fallback spec | ||
| git log --oneline ${BASE}..HEAD | ||
| ``` | ||
| If PLAN.md files found: read their `must_haves` frontmatter fields — these are the spec. | ||
| If no PLAN.md: use commit message summaries as a lightweight spec. | ||
| If no commits at all: spec compliance is N/A — skip to Pass 2. | ||
| ### 3b. Check Spec Coverage | ||
| For each must-have deliverable or commit-described feature: | ||
| 1. Does the diff contain files that plausibly implement it? | ||
| 2. Are there test files covering it? | ||
| 3. Is it mentioned in any SUMMARY.md for the current phase? | ||
| Classify each item as: | ||
| - **COVERED** — evidence in diff matches the deliverable | ||
| - **PARTIAL** — diff touches the right area but coverage seems incomplete | ||
| - **MISSING** — no evidence in diff that this was implemented | ||
| ### 3c. Report Spec Compliance | ||
| ``` | ||
| ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ | ||
| learnship ► PASS 1: SPEC COMPLIANCE | ||
| ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ | ||
| Spec source: [PLAN.md path | commit messages] | ||
| | Deliverable | Status | Evidence | | ||
| |-------------|--------|----------| | ||
| | [item 1] | COVERED | [file/lines] | | ||
| | [item 2] | PARTIAL | [what's missing] | | ||
| | [item 3] | MISSING | — | | ||
| Result: PASS | PARTIAL | FAIL | ||
| ``` | ||
| **If FAIL or PARTIAL:** | ||
| ``` | ||
| AskUserQuestion([ | ||
| { | ||
| header: "Spec Gap", | ||
| question: "[N] planned deliverable(s) not found in this diff. Continue to quality review anyway?", | ||
| multiSelect: false, | ||
| options: [ | ||
| { label: "Continue anyway", description: "Run quality review on what exists — spec gaps noted in report" }, | ||
| { label: "Stop — fix spec gaps first", description: "Come back and re-run /review after completing missing deliverables" } | ||
| ] | ||
| } | ||
| ]) | ||
| ``` | ||
| > 🛑 STOP. Wait for reply before continuing. | ||
| If "Stop": output the missing items as a task list and stop. | ||
| If "Continue": add spec gap findings to the final report as P1 items. | ||
| **If PASS:** continue directly to Pass 2. | ||
| --- | ||
| ## Step 4: Pass 2 — Select Quality Personas | ||
| Read the diff and file list. Select which quality review personas to activate: | ||
| **Always-on (every review):** | ||
@@ -86,3 +167,3 @@ | ||
| ## Step 4: Run Review | ||
| ## Step 5: Run Quality Review | ||
@@ -144,3 +225,3 @@ Read `parallelization` from `.planning/config.json` (defaults to `false`). | ||
| ## Step 5: Merge & Deduplicate Findings | ||
| ## Step 6: Merge & Deduplicate Findings | ||
@@ -154,3 +235,3 @@ Combine findings from all personas: | ||
| ## Step 6: Present Report | ||
| ## Step 7: Present Report | ||
@@ -173,2 +254,3 @@ ### Severity Scale | ||
| Intent: [intent summary] | ||
| Spec compliance: PASS | PARTIAL ([N] gaps carried as P1) | SKIPPED (--quality-only) | ||
| Reviewers: [list] | ||
@@ -204,3 +286,3 @@ Mode: [interactive | report-only | autofix] | ||
| ## Step 7: Handle Mode | ||
| ## Step 8: Handle Mode | ||
@@ -222,3 +304,3 @@ **Interactive (default):** | ||
| ## Step 8: Suggest Next Steps | ||
| ## Step 9: Suggest Next Steps | ||
@@ -241,2 +323,16 @@ ``` | ||
| ## Design Quality Gate (UI changes only) | ||
| If the review touched any user-facing UI files (frontend components, templates, stylesheets, public HTML), suggest running a design pass as a final lens — code correctness does not catch design regressions: | ||
| > 🎨 **Design pass:** This review touched UI files. Run one of these `impeccable` actions on the changed views to catch issues code review misses (visual hierarchy, accessibility, motion, copy): | ||
| > | ||
| > - `@impeccable critique [component or view]` — Multi-frame critique (typography, color, spatial, motion, copy) | ||
| > - `@impeccable polish [component or view]` — Apply small refinements before shipping | ||
| > - `@impeccable audit [view]` — Scan for accessibility, contrast, and layout issues | ||
| > | ||
| > Skip if no UI files changed. | ||
| --- | ||
| ## Learning Checkpoint | ||
@@ -243,0 +339,0 @@ |
@@ -58,2 +58,4 @@ --- | ||
| **OWASP Top 10 surface scan:** As part of codebase analysis, note which OWASP categories are relevant to this phase's changes (see security-auditor agent for the full checklist). The SECURITY.md output must include an OWASP coverage table — marking each category as Relevant/N/A/Found. This makes the audit exhaustive and audit-trail-friendly. | ||
| ## Step 3: Build Threat Register | ||
@@ -60,0 +62,0 @@ |
@@ -211,2 +211,45 @@ --- | ||
| ## Pre-Ship Design Pass (UI changes only) | ||
| Before opening the PR, if the staged changes touch any user-facing UI files, run a final design pass — this catches issues that tests and code review don't: | ||
| ```bash | ||
| git diff --name-only --cached | grep -E '\.(tsx?|jsx?|vue|svelte|html|css|scss|less)$' | head -5 | ||
| ``` | ||
| If UI files appear in the diff, suggest: | ||
| > 🎨 **Design pass before ship:** Staged changes include UI files. Run one of these to catch design regressions before opening the PR: | ||
| > | ||
| > - `@impeccable polish [view]` — Quick refinement pass: typography, spacing, color, copy | ||
| > - `@impeccable audit [view]` — Accessibility + contrast + layout scan | ||
| > - `@impeccable harden [view]` — Edge-case resilience (small viewport, RTL, screen reader) | ||
| > | ||
| > Skip on non-UI changes. | ||
| --- | ||
| ## Live Smoke Test Before PR (when Playwright MCP is available) | ||
| **Supported on:** Any platform with MCP support configured (Claude Code, OpenCode, Cursor, Windsurf, Codex CLI, Gemini CLI). | ||
| If `mcp__playwright__*` tools are available and the staged changes touch a web UI, run a quick smoke test before creating the PR — catches rendering failures that tests don't: | ||
| ```bash | ||
| # Check server is running | ||
| curl -s -o /dev/null -w "%{http_code}" http://localhost:3000 2>/dev/null || echo "not-running" | ||
| ``` | ||
| If the server is running and Playwright is available: | ||
| 1. Navigate to the primary page | ||
| 2. Walk the changed flow once (the golden path for this change) | ||
| 3. Take a screenshot — verify it matches expectations | ||
| 4. Check the browser console — zero JS errors required | ||
| **If smoke test fails:** Stop the ship pipeline. Fix before pushing. | ||
| If Playwright is not configured or the server is not running: skip this step and note it in the PR description. To configure: see the `verify-work` workflow for Playwright MCP setup instructions per platform. | ||
| --- | ||
| ## Learning Checkpoint | ||
@@ -213,0 +256,0 @@ |
@@ -354,2 +354,35 @@ --- | ||
| ## Live UI Smoke Test (when Playwright MCP is available) | ||
| **Supported on:** Any platform with MCP support configured (Claude Code, OpenCode, Cursor, Windsurf, Codex CLI, Gemini CLI). Optional enhancement layer — the conversational UAT above is the primary mechanism on all platforms. | ||
| After UAT passes, if the tested deliverables include any user-facing UI **and** your tool list includes `mcp__playwright__*` tools (or equivalents), run a quick live smoke test before committing the UAT as complete: | ||
| **1. Find the entry point:** | ||
| ```bash | ||
| # Check common dev server patterns | ||
| grep -E '"(dev|start|serve)"' package.json 2>/dev/null | head -3 | ||
| cat README.md 2>/dev/null | grep -i "http://localhost" | head -3 | ||
| ``` | ||
| **2. Verify the server is running:** | ||
| ```bash | ||
| curl -s -o /dev/null -w "%{http_code}" http://localhost:3000 2>/dev/null || \ | ||
| curl -s -o /dev/null -w "%{http_code}" http://localhost:8080 2>/dev/null || \ | ||
| echo "not-running" | ||
| ``` | ||
| **3. Walk the golden path via Playwright:** | ||
| - Navigate to the primary entry point | ||
| - Walk through each UI deliverable from the UAT list once | ||
| - Take a screenshot at each key step | ||
| - Check the browser console for JS errors | ||
| **4. Record the result:** | ||
| If any Playwright step fails (HTTP error, JS exception, visual regression), treat it as a UAT issue with severity `blocker` and add it to the Gaps section. | ||
| > **Platform note:** Playwright MCP is supported wherever MCP is available — Claude Code, OpenCode, Cursor, Windsurf, Codex CLI, and Gemini CLI all support MCP servers. To enable it: install `@playwright/mcp` and add it to your platform's MCP config. On Claude Code: `claude mcp add playwright npx @playwright/mcp`. On Cursor/Windsurf: add `@playwright/mcp` as an MCP server in your IDE settings. Once configured, learnship workflows detect and use it automatically. | ||
| --- | ||
| ## Learning Checkpoint | ||
@@ -356,0 +389,0 @@ |
+1
-1
| { | ||
| "name": "learnship", | ||
| "version": "2.3.6", | ||
| "version": "2.4.0", | ||
| "description": "Learn as you build. Build with intent. — A multi-platform agentic engineering system for Windsurf, Claude Code, Cursor, OpenCode, Gemini CLI, and Codex: 57 spec-driven workflows, 17 specialist agent personas, integrated learning, and production-grade design.", | ||
@@ -5,0 +5,0 @@ "keywords": [ |
+34
-17
@@ -127,3 +127,3 @@ # learnship | ||
| VW["/verify-work N<br/>UAT + diagnose"] | ||
| RV["/review<br/>Multi-persona review"] | ||
| RV["/review<br/>Two-pass review"] | ||
| SH["/ship<br/>Test → PR"] | ||
@@ -144,3 +144,3 @@ CP["/compound<br/>Capture knowledge"] | ||
| | **4. Verify** | `/verify-work N` | You do UAT; agent diagnoses any gaps and creates fix plans | | ||
| | **5. Review** | `/review` | Multi-persona code review through 6 lenses (v2.0) | | ||
| | **5. Review** | `/review` | Two-pass review: spec compliance check then 6-lens quality review (v2.4.0) | | ||
| | **6. Ship** | `/ship` | Test → lint → commit → push → PR (v2.0) | | ||
@@ -177,3 +177,3 @@ | **7. Compound** | `/compound` | Capture what you learned as searchable documentation (v2.0) | | ||
| | Real parallel subagents | — | ✓ | ✓ | ✓ | ✓ | | ||
| | Parallel wave execution | — | ✓ opt-in | ✓ opt-in | ✓ | ✓ opt-in | | ||
| | Parallel wave execution | — | ✓ | ✓ | ⚠️ experimental | ✓ | | ||
| | Agent personas (17) | `model_decision` rules | `Task()` subagents | `Task()` subagents | `Task()` subagents | `Task()` subagents | | ||
@@ -185,4 +185,6 @@ | Interactive questions | `ask_user_question` | `AskUserQuestion` | `question` | `ask_user` | `request_user_input` | | ||
| **Parallel subagents:** On Claude Code, OpenCode, and Codex, `execute-phase` can spawn a dedicated executor per plan within a wave, each with its own 200k context budget. Enable with `"parallelization": { "enabled": true }` in `.planning/config.json`. Up to 5 concurrent agents per wave by default. All platforms default to sequential (always safe). | ||
| **Cursor** uses context injection via `cursor-rules/learnship.mdc` — it gets the full workflow library, design system, and learning partner, but does not appear in the feature matrix above because it has no first-class slash command or subagent API (rules load automatically as context). | ||
| **Parallel subagents:** Claude Code, OpenCode, and Codex default to parallel execution — `execute-phase` spawns a dedicated executor per plan within a wave, each with its own 200k context budget. Up to 5 concurrent agents per wave. To run sequentially, set `"parallelization": { "enabled": false }` in `.planning/config.json`. Windsurf, Cursor, and Gemini CLI use sequential execution (no real subagent API on those platforms). | ||
| --- | ||
@@ -200,4 +202,4 @@ | ||
| - **Structured process.** A repeatable phase loop with spec-driven plans, wave-ordered execution, and UAT-driven verification. | ||
| - **Knowledge compounding.** `/compound` captures solved problems. `/review` runs multi-persona code review. `/ship` runs the full delivery pipeline. | ||
| - **Security & recovery.** `/secure-phase` for STRIDE verification. `/forensics` for post-mortem. `/undo` for safe revert. | ||
| - **Knowledge compounding.** `/compound` captures solved problems. `/review` runs two-pass code review (spec compliance then quality). `/ship` runs the full delivery pipeline. | ||
| - **Security & recovery.** `/secure-phase` for STRIDE + OWASP Top 10 verification. `/forensics` for post-mortem. `/undo` for safe revert. | ||
| - **Session intelligence.** Hooks, context profiles, interactive questions, agent delegation. ([v2.2 details →](#whats-new-in-v22)) | ||
@@ -238,3 +240,3 @@ - **Built-in learning.** Neuroscience-backed checkpoints at every phase transition so you understand what you shipped. | ||
| - You care about **code quality and UI quality** beyond "it works" | ||
| - You want **parallel agent execution** on Claude Code, OpenCode, or Gemini CLI | ||
| - You want **parallel agent execution** — Claude Code, OpenCode, and Codex run it by default | ||
| - You've felt the frustration of **context loss**: repeating yourself while the agent forgets | ||
@@ -261,2 +263,14 @@ | ||
| ### What's new in v2.4.0 | ||
| v2.4.0 adds spec compliance checking to `/review`, OWASP Top 10 coverage to `/secure-phase`, a numeric score to `/health`, and Playwright MCP smoke-test guidance to `/verify-work` and `/ship`: | ||
| **Two-stage `/review`**: Pass 1 checks spec compliance — reads PLAN.md must-haves and classifies each as COVERED / PARTIAL / MISSING — before Pass 2 runs the existing 6-persona quality review. The spec compliance result appears in the report header. Use `--quality-only` to skip Pass 1 and run only the quality review. | ||
| **OWASP Top 10 in `/secure-phase`**: The security-auditor agent now cross-maps STRIDE findings against OWASP Top 10 (A01–A10). Every SECURITY.md output includes an OWASP coverage table alongside the STRIDE analysis. | ||
| **Numeric `/health` score**: The health check now outputs a 0–100 numeric score alongside the qualitative status. Starts at 100, deducts per issue found. Bands: HEALTHY (90–100), DEGRADED (70–89), BROKEN (0–69). | ||
| **Playwright MCP guidance in `/verify-work` and `/ship`**: Optional live UI smoke-test sections activate when `@playwright/mcp` is configured. Supported on all 6 MCP-capable platforms (Claude Code, OpenCode, Cursor, Windsurf, Codex CLI, Gemini CLI). In `/verify-work`, walks the golden path using `mcp__playwright__*` tools. In `/ship`, runs a quick smoke test before creating the PR. | ||
| ### What's new in v2.3.4 | ||
@@ -306,3 +320,3 @@ | ||
| |----------|--------------| | ||
| | **Security** | `/secure-phase` — per-phase STRIDE threat verification | | ||
| | **Security** | `/secure-phase` — per-phase STRIDE threat-model security verification | | ||
| | **Documentation** | `/docs-update` — generate and verify project docs against codebase | | ||
@@ -320,3 +334,3 @@ | **Recovery** | `/forensics` — post-mortem investigation · `/undo` — safe git revert | | ||
| ## Agentic Engineering vs Vibe Coding | ||
| ## ⚡ Agentic Engineering vs Vibe Coding | ||
@@ -385,3 +399,3 @@  | ||
| | `/execute-phase [N]` | Wave-ordered execution of all plans | After planning | | ||
| | `/verify-work [N]` | Manual UAT with auto-diagnosis and fix planning | After execution | | ||
| | `/verify-work [N]` | Manual UAT with auto-diagnosis and fix planning. Optional Playwright MCP live UI smoke test when `@playwright/mcp` is configured. | After execution | | ||
| | `/complete-milestone` | Archive milestone, tag release, prepare next | All phases verified | | ||
@@ -449,5 +463,5 @@ | `/audit-milestone` | Pre-release: requirement coverage, stub detection | Before completing milestone | | ||
| | `/compound` | Capture solved problem as searchable documentation | After `/debug`, `/verify-work`, or any aha moment | | ||
| | `/review` | Multi-persona code review (6 lenses) | After `/verify-work`, before shipping | | ||
| | `/review` | Two-pass review: spec compliance check then 6-persona quality review. `--quality-only` skips spec compliance. | After `/verify-work`, before shipping | | ||
| | `/challenge` | Stress-test scope through product + engineering lenses | Before committing to a milestone or large feature | | ||
| | `/ship` | Test → lint → commit → push → PR | After review, ready to deploy | | ||
| | `/ship` | Test → lint → commit → push → PR. Optional Playwright MCP smoke test before PR creation when `@playwright/mcp` is configured. | After review, ready to deploy | | ||
| | `/ideate` | Codebase-grounded idea generation | Before `/discuss-milestone`, between milestones | | ||
@@ -463,3 +477,3 @@ | `/guard` | Safety mode: protect sensitive directories | Working on auth, payments, migrations | | ||
| | `/set-profile [quality\|balanced\|budget]` | One-step model profile switch | Quick cost/quality adjustment | | ||
| | `/health` | Project health check | Stale files, missing artifacts | | ||
| | `/health` | Project health check with numeric 0–100 score (HEALTHY ≥90, DEGRADED ≥70, BROKEN <70) | Stale files, missing artifacts | | ||
| | `/cleanup` | Archive old artifacts | End of milestone | | ||
@@ -549,3 +563,3 @@ | `/update` | Update the platform itself | Check for new workflows | | ||
| | `context` | `dev`, `research`, `review` | `dev` | Output profile: `dev` (concise), `research` (detailed), `review` (audit-focused) | | ||
| | `parallelization.enabled` | `true`, `false` | `false` | Parallel subagents per plan on supported platforms | | ||
| | `parallelization.enabled` | `true`, `false` | `true` (Claude Code, OpenCode, Codex) / `false` (others) | Parallel subagents per plan on supported platforms | | ||
| | `test_first` | `true`, `false` | `false` | TDD mode: write failing test first, verify red, implement, verify green | | ||
@@ -600,3 +614,3 @@ | `planning.commit_mode` | `auto`, `manual` | `auto` | `auto` commits after each workflow step; `manual` skips all git commits | | ||
| > **Platform note:** Tiers map to the best available model on your platform: `large` = Claude Opus 4.6 / Gemini 3.1 Pro / GPT-5.4, `medium` = Claude Sonnet 4.6 / Gemini 3.1 Flash / GPT-5.4-mini, `small` = Claude Haiku 4.5 / Gemini 3.1 Flash-Lite / GPT-5.4-nano. Windsurf, Cursor, and OpenCode use the platform default model — tiers signal intended task complexity. | ||
| > **Platform note:** Tiers map to the best available model on your platform. On Claude Code: `large` = Opus, `medium` = Sonnet, `small` = Haiku. On Gemini CLI and Codex CLI the installer maps tiers to the best available model at install time. Windsurf, Cursor, and OpenCode use the platform default model — tiers signal intended task complexity. | ||
@@ -670,5 +684,8 @@ ### Speed vs. Quality Presets | ||
| | `/clarify` | Improve UX copy, error messages, microcopy, labels | | ||
| | `/typeset` | Improve typography: font choices, hierarchy, sizing, weight, and readability | | ||
| | `/arrange` | Improve layout, spacing, and visual rhythm; fix monotonous grids and weak hierarchy | | ||
| | `/optimize` | Performance: loading speed, rendering, animations, bundle size | | ||
| | `/harden` | Resilience: error handling, i18n, text overflow, edge cases | | ||
| | `/delight` | Add moments of joy and personality that make interfaces memorable | | ||
| | `/overdrive` | Push past conventional limits — shaders, spring physics, scroll-driven reveals | | ||
| | `/extract` | Extract reusable components and design tokens into your design system | | ||
@@ -705,3 +722,3 @@ | `/adapt` | Adapt designs across screen sizes, devices, and contexts | | ||
| /verify-work 1 # Manual UAT | ||
| /review # v2.0: multi-persona code review | ||
| /review # two-pass review: spec compliance + quality (v2.4.0) | ||
| /ship # v2.0: test → commit → push → PR | ||
@@ -926,3 +943,3 @@ /compound # v2.0: capture what you learned | ||
| ├── tests/ | ||
| │ └── run_all.sh # 15 test suites, 1200+ checks across 6 platforms | ||
| │ └── run_all.sh # 17 test suites, 1330+ checks across 6 platforms | ||
| ├── SKILL.md # Meta-skill: platform context loaded by Cascade / AI agents | ||
@@ -929,0 +946,0 @@ ├── install.sh # Shell installer wrapper |
+32
-11
@@ -106,16 +106,31 @@ # learnship | ||
| Learning checkpoints: | ||
| - After requirements approved → `@agentic-learning brainstorm` | ||
| - After discuss-phase → `@agentic-learning either-or` | ||
| - After plan-phase → `@agentic-learning cognitive-load` | ||
| - After execute-phase → `@agentic-learning reflect` | ||
| - After verify-work passes → `@agentic-learning space` | ||
| - After `/review` → `@agentic-learning learn` (review findings as learning material) | ||
| Learning checkpoints (auto mode triggers these; manual mode surfaces them as tips): | ||
| **Core phase loop:** | ||
| - After requirements approved → `@agentic-learning brainstorm` (design dialogue on the requirements) | ||
| - After `/discuss-phase` → `@agentic-learning either-or` (capture the decisions made) | ||
| - After `/plan-phase` → `@agentic-learning cognitive-load` (decompose if plan feels overwhelming) | ||
| - After `/execute-phase` → `@agentic-learning reflect` (consolidate the cycle) | ||
| - After `/verify-work` passes → `@agentic-learning space` (queue concepts for spaced revisit) | ||
| **Quality gates:** | ||
| - After `/review` → `@agentic-learning learn` (most significant finding as a learning topic) | ||
| - After `/review` (on UI changes) → `@agentic-learning quiz` (gaps in recall predict future bugs) | ||
| - After `/challenge` → `@agentic-learning either-or` (which lens was most valuable?) | ||
| - After `/secure-phase` → `@agentic-learning learn` (security patterns) | ||
| - After `/ship` → `@agentic-learning reflect` (what went well in this cycle?) | ||
| **Discovery, mapping, comprehension:** | ||
| - After `/map-codebase` or `/discovery-phase` → `@agentic-learning explain` (lock in the project knowledge log) | ||
| - When studying an unfamiliar function or pattern → `@agentic-learning explain-first` (oracy-first comprehension check) | ||
| - After absorbing research files (RESEARCH.md, STACK.md, etc.) → `@agentic-learning quiz` (test what stuck) | ||
| **Ideation and complex tasks:** | ||
| - After `/ideate` → `@agentic-learning brainstorm` (explore top idea collaboratively) | ||
| - During complex quick tasks → `@agentic-learning struggle` | ||
| - During complex `/quick` tasks → `@agentic-learning struggle` (productive struggle on hard parts) | ||
| - When stuck across multiple domains in one session → `@agentic-learning interleave` (mixed retrieval forces transfer) | ||
| **Recovery and reflection:** | ||
| - After `/forensics` → `@agentic-learning reflect` (what caused the failure?) | ||
| - After `/extract-learnings` → `@agentic-learning space` (schedule learnings for review) | ||
| - After `/secure-phase` → `@agentic-learning learn` (security patterns) | ||
| - After `/extract-learnings` → `@agentic-learning space` (schedule learnings for spaced review) | ||
| - After `/session-report` → `@agentic-learning reflect` (session-level reflection) | ||
@@ -125,4 +140,10 @@ | ||
| The `impeccable` skill suite is always available for any UI work. Use its steering commands (`/audit`, `/critique`, `/polish`, `/colorize`, `/animate`, `/bolder`, `/quieter`, `/distill`, `/clarify`, `/optimize`, `/harden`, `/delight`, `/extract`, `/adapt`, `/onboard`, `/normalize`, `/teach-impeccable`) when reviewing or building user-facing interfaces. | ||
| The `impeccable` skill suite is always available for any UI work. Use its 21 steering commands when reviewing or building user-facing interfaces: | ||
| **Review & critique:** `/audit`, `/critique`, `/teach-impeccable` | ||
| **Refine & elevate:** `/polish`, `/bolder`, `/quieter`, `/distill`, `/clarify`, `/normalize`, `/extract`, `/adapt` | ||
| **Specific concerns:** `/colorize` (color/contrast), `/typeset` (typography), `/arrange` (layout/spacing), `/animate` (motion), `/onboard` (first-time UX), `/delight` (interaction polish) | ||
| **Engineering attributes:** `/harden` (accessibility, resilience), `/optimize` (performance), `/overdrive` (push design quality to its ceiling) | ||
| **Foundations:** `/frontend-design` (full design system reference: typography, color, spatial, motion, interaction, responsive, UX writing) | ||
| ## Mandatory Gate — No Project, No Work | ||
@@ -129,0 +150,0 @@ |
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is too big to display
Fixed alerts
AI-detected potential code anomaly
Supply chain riskAI has identified unusual behaviors that may pose a security risk.
Improved metrics
- Total package byte prevSize
1326621
2.64%- Lines of code
2313
3.31%- Number of lines in readme file
955
1.81%- Number of low supply chain risk alerts
22
-4.35%No dependency changes