create-agentic-app 1.1.56 → 1.1.58

package/template/.claude/skills/security-scanner/references/report-template.md

@@ -0,0 +1,148 @@
+# Security Audit Report
+
+**Project:** [PROJECT_NAME]
+**Date:** [YYYY-MM-DD]
+**Auditor:** Claude Code Security Scanner
+**Framework:** OWASP Top 10:2025
+**Scope:** [LIST_OF_DIRECTORIES_AND_FILES_ANALYZED]
+**Technology Stack:** [LANGUAGES_FRAMEWORKS_DETECTED]
+
+---
+
+## Executive Summary
+
+[2-3 paragraph overview: what was analyzed, key risk areas found, overall risk posture, most urgent items to address]
+
+**Overall Risk Score:** [SCORE] ([Low/Moderate/High/Critical] Risk)
+
+| Severity | Count |
+|----------|-------|
+| Critical | [X]   |
+| High     | [X]   |
+| Medium   | [X]   |
+| Low      | [X]   |
+| Info     | [X]   |
+| **Total**| **[X]** |
+
+---
+
+## Findings
+
+### A01:2025 — Broken Access Control
+
+[If findings exist, list each one using the format below. If no findings, write: "No issues identified. Checked: [list what was checked]."]
+
+#### [SEVERITY] [Finding Title]
+- **File:** `[path/to/file.ext]`
+- **Line(s):** [XX-YY]
+- **CWE:** [CWE-XXX: Name]
+- **Description:** [What the vulnerability is and why it matters]
+- **Evidence:**
+  ```[language]
+  // vulnerable code snippet from the actual codebase
+  ```
+- **Recommendation:**
+  ```[language]
+  // fixed code snippet showing the remediation
+  ```
+
+---
+
+### A02:2025 — Security Misconfiguration
+
+[Same format as above]
+
+---
+
+### A03:2025 — Software Supply Chain Failures
+
+[Same format as above]
+
+---
+
+### A04:2025 — Cryptographic Failures
+
+[Same format as above]
+
+---
+
+### A05:2025 — Injection
+
+[Same format as above]
+
+---
+
+### A06:2025 — Insecure Design
+
+[Same format as above]
+
+---
+
+### A07:2025 — Authentication Failures
+
+[Same format as above]
+
+---
+
+### A08:2025 — Software or Data Integrity Failures
+
+[Same format as above]
+
+---
+
+### A09:2025 — Security Logging and Alerting Failures
+
+[Same format as above]
+
+---
+
+### A10:2025 — Mishandling of Exceptional Conditions
+
+[Same format as above]
+
+---
+
+## Risk Score Breakdown
+
+Scoring: Critical = 10 pts, High = 7 pts, Medium = 4 pts, Low = 2 pts, Info = 0 pts.
+
+| Category | Critical | High | Medium | Low | Info | Points |
+|----------|----------|------|--------|-----|------|--------|
+| A01 — Broken Access Control        | [X] | [X] | [X] | [X] | [X] | [XX] |
+| A02 — Security Misconfiguration    | [X] | [X] | [X] | [X] | [X] | [XX] |
+| A03 — Supply Chain Failures        | [X] | [X] | [X] | [X] | [X] | [XX] |
+| A04 — Cryptographic Failures       | [X] | [X] | [X] | [X] | [X] | [XX] |
+| A05 — Injection                    | [X] | [X] | [X] | [X] | [X] | [XX] |
+| A06 — Insecure Design              | [X] | [X] | [X] | [X] | [X] | [XX] |
+| A07 — Authentication Failures      | [X] | [X] | [X] | [X] | [X] | [XX] |
+| A08 — Data Integrity Failures      | [X] | [X] | [X] | [X] | [X] | [XX] |
+| A09 — Logging & Alerting Failures  | [X] | [X] | [X] | [X] | [X] | [XX] |
+| A10 — Exceptional Conditions       | [X] | [X] | [X] | [X] | [X] | [XX] |
+| **Total**                           |     |     |     |     |     | **[XX]** |
+
+**Risk Rating:** 0-10 = Low | 11-30 = Moderate | 31-60 = High | 61+ = Critical
+
+---
+
+## Remediation Priority
+
+[Ordered list of the most critical items to fix first, with brief rationale]
+
+1. **[Most critical finding]** — [why this is urgent and what to do]
+2. **[Second most critical]** — [why and what]
+3. **[Third most critical]** — [why and what]
+[Continue as needed...]
+
+---
+
+## Methodology
+
+This audit was performed using static analysis against the OWASP Top 10:2025 framework. Each category was evaluated using pattern-matching (grep), code review (file reading), dependency analysis, and configuration inspection. The analysis covered source code, configuration files, dependency manifests, and environment settings.
+
+**Limitations:** This is a static analysis — it does not include dynamic/runtime testing, penetration testing, or network-level analysis. Some vulnerabilities may only be discoverable through dynamic testing.
+
+## References
+
+- [OWASP Top 10:2025](https://owasp.org/Top10/2025/)
+- [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/)
+- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)

package/template/AGENTS.md

@@ -1,87 +1,31 @@
-## Planning mode
+# CRITICAL RULES - MUST FOLLOW
 
-Never make assumptions about what the user wants. Always ask clarifying questions before proceeding.
+## RESPONSES
 
-# MANDATORY: Feature Planning & Implementation Workflow
+- Keep responses concise and to the point - unless the user asks otherwise
 
-**This workflow is non-negotiable for any non-trivial feature or multi-step change.** Do not implement multi-task features directly in a single session. Do not write a monolithic plan and start coding from it. The workflow below exists because implementation plans that live in a single file are either too large for a context window or too shallow for independent execution — both lead to poor results.
+## PLANNING MODE
 
-### The workflow has three stages. Execute them in order, every time.
+- Always ask clarifying questions
+- Never assume design, tech stack or features
+- Use deep-dive sub-agents to assist with research
+- Use deep-dive sub-agents to review the different aspects of your plan before presenting to the user
 
-**Stage 1 — Plan.** Discuss the feature with the user. Ask clarifying questions. Understand requirements, technical constraints, and acceptance criteria. This happens naturally in planning mode.
+## CHANGE / EDIT MODE
 
-**Stage 2 — Create the spec.** Once planning is complete, invoke the `create-spec` skill. This converts the planning conversation into a structured `specs/{feature}/` folder with:
-- Self-contained task files (one per task, in a `tasks/` subfolder)
-- A README with a dependency graph and parallel execution waves
-- Requirements and manual action items
+- Never implement features yourself when possible - use sub-agents!
+- Identify changes from the plan that can be implemented in parallel, and use sub-agents to implement the features efficiently
+- When using sub-agents to implement features, act as a coordinator only
+- Use the best model for the task - premium models for complex tasks (like coding) and mid-tier models for simpler tasks, like documentation
+- After completing features (large or small), always run commands like lint and type check to check code quality
 
-Do not skip this step. Do not proceed to implementation without a spec folder. The spec is what enables parallel agent execution — without it, you're back to single-threaded implementation.
+## TESTING
 
-**Stage 3 — Implement via orchestration.** Once the spec folder exists and the user approves it, invoke the `implement-feature` skill. This orchestrates parallel coder agents wave-by-wave:
-- Each task is dispatched to its own coder agent
-- Tasks within a wave run in parallel
-- A code review gate runs between waves
-- Issues from review are dispatched back to coder agents
-- The cycle repeats until everything passes
+- Use any testing tools, libraries available to the project for testing your changes
+- Never assume your changes simply work, always test!
+- If the project does not have any testing tools, scripts, MCP tools, skills, etc. available for testing, ask the user whether testing should be skipped.
 
-The main agent (you) does NOT write code during Stage 3. You orchestrate. Coder subagents implement. The code-review agent verifies. You manage progress and commit completed waves.
+## UI DESIGN
 
-### When does this workflow apply?
-
-- Any feature with 2+ tasks or files to change
-- Any work that came out of a planning conversation
-- Any time the user says "implement", "build", "create this feature", or similar after discussing what to build
-
-### When does it NOT apply?
-
-- Single-file bug fixes or trivial changes
-- Quick config edits or one-line patches
-- Tasks the user explicitly asks to do inline ("just fix this here")
-
-If in doubt, ask the user: "This looks like it could benefit from a spec — should I create one, or would you prefer I implement it directly?"
-
----
-
-# Project Agent Instructions
-
-## Skills
-
-This repo ships agent skills under `.claude/skills` (mirrored at `.agents/skills`). **Read and follow the relevant skill** when your task matches its domain—skills encode stack conventions and patterns for this project.
-
-Use **`find-skills`** when you are unsure whether a skill exists for a task or want to discover installable skills from registries.
-
-## Pre-flight (non-trivial tasks)
-
-1. Map the work to skills using the routing table below.
-2. Open and follow matching skills before writing substantial code or making architectural decisions.
-
-If you start down the wrong path, stop, invoke the right skill, and continue from there.
-
-## Task → skill routing
-
-| If you are about to… | Invoke first |
-| --- | --- |
-| Plan a feature, create a spec, break work into tasks | `create-spec` |
-| Implement a planned feature, execute a spec | `implement-feature` |
-| Create a checkpoint commit | `checkpoint` |
-| Review a pull request | `review-pr` |
-| Touch Next.js App Router, routing, RSC, data fetching, deployment | `nextjs` |
-| Touch shadcn/ui components or registries | `shadcn` |
-| Touch Better Auth configuration or auth flows | `better-auth-best-practices` |
-| Optimize or review React / Next.js performance | `vercel-react-best-practices` |
-| Build, modify, or review an MCP server | `mcp-builder` |
-| Build or review a frontend design / UI | `frontend-design`, `web-design-guidelines` |
-| Automate browser testing (Playwright) | `playwright-cli` |
-| Create or refine project agent skills | `skill-creator` |
-| Look for a skill or extend capabilities | `find-skills` |
-
-Stack skills compose: invoking `nextjs` does not excuse skipping `shadcn` or `better-auth-best-practices` when those layers are involved.
-
-## Hard rules
-
-1. **Never touch the Next.js / shadcn / Better Auth / MCP layers without reading their corresponding skill** for this repo. They are mandatory references, not optional browsing.
-2. **Before claiming work is done, fixed, or passing**, run the project’s verification commands (see workspace rules: lint and typecheck scripts) and only assert success when the output supports it.
-
-## If no skill matches
-
-Fall back to sound engineering judgment. State explicitly: _"I checked the skills list and none applied because …"_ so the user can correct a missed skill.
+- Always following the UI design system when creating or reviewing components or pages.
+- Design System: @DESIGN.md