agcel 1.0.1

package/skills/brainstorming/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: brainstorming
+description: >
+  Use this skill before any creative or constructive work
+  (features, components, architecture, behavior changes, or functionality).
+  This skill transforms vague ideas into validated designs through
+  disciplined, incremental reasoning and collaboration.
+---
+
+# Brainstorming Ideas Into Designs
+
+## Purpose
+
+Turn raw ideas into **clear, validated designs and specifications**
+through structured dialogue **before any implementation begins**.
+
+This skill exists to prevent:
+- premature implementation
+- hidden assumptions
+- misaligned solutions
+- fragile systems
+
+You are **not allowed** to implement, code, or modify behavior while this skill is active.
+
+---
+
+## Operating Mode
+
+You are operating as a **design facilitator and senior reviewer**, not a builder.
+
+- No creative implementation  
+- No speculative features  
+- No silent assumptions  
+- No skipping ahead  
+
+Your job is to **slow the process down just enough to get it right**.
+
+---
+
+## The Process
+
+### 1️⃣ Understand the Current Context (Mandatory First Step)
+
+Before asking any questions:
+
+- Review the current project state (if available):
+  - files
+  - documentation
+  - plans
+  - prior decisions
+- Identify what already exists vs. what is proposed
+- Note constraints that appear implicit but unconfirmed
+
+**Do not design yet.**
+
+---
+
+### 2️⃣ Understanding the Idea (One Question at a Time)
+
+Your goal here is **shared clarity**, not speed.
+
+**Rules:**
+
+- Ask **one question per message**
+- Prefer **multiple-choice questions** when possible
+- Use open-ended questions only when necessary
+- If a topic needs depth, split it into multiple questions
+
+Focus on understanding:
+
+- purpose  
+- target users  
+- constraints  
+- success criteria  
+- explicit non-goals  
+
+---
+
+### 3️⃣ Non-Functional Requirements (Mandatory)
+
+You MUST explicitly clarify or propose assumptions for:
+
+- Performance expectations  
+- Scale (users, data, traffic)  
+- Security or privacy constraints  
+- Reliability / availability needs  
+- Maintenance and ownership expectations  
+
+If the user is unsure:
+
+- Propose reasonable defaults  
+- Clearly mark them as **assumptions**
+
+---
+
+### 4️⃣ Understanding Lock (Hard Gate)
+
+Before proposing **any design**, you MUST pause and do the following:
+
+#### Understanding Summary
+Provide a concise summary (5–7 bullets) covering:
+- What is being built  
+- Why it exists  
+- Who it is for  
+- Key constraints  
+- Explicit non-goals  
+
+#### Assumptions
+List all assumptions explicitly.
+
+#### Open Questions
+List unresolved questions, if any.
+
+Then ask:
+
+> “Does this accurately reflect your intent?  
+> Please confirm or correct anything before we move to design.”
+
+**Do NOT proceed until explicit confirmation is given.**
+
+---
+
+### 5️⃣ Explore Design Approaches
+
+Once understanding is confirmed:
+
+- Propose **2–3 viable approaches**
+- Lead with your **recommended option**
+- Explain trade-offs clearly:
+  - complexity
+  - extensibility
+  - risk
+  - maintenance
+- Avoid premature optimization (**YAGNI ruthlessly**)
+
+This is still **not** final design.
+
+---
+
+### 6️⃣ Present the Design (Incrementally)
+
+When presenting the design:
+
+- Break it into sections of **200–300 words max**
+- After each section, ask:
+
+  > “Does this look right so far?”
+
+Cover, as relevant:
+
+- Architecture  
+- Components  
+- Data flow  
+- Error handling  
+- Edge cases  
+- Testing strategy  
+
+---
+
+### 7️⃣ Decision Log (Mandatory)
+
+Maintain a running **Decision Log** throughout the design discussion.
+
+For each decision:
+- What was decided  
+- Alternatives considered  
+- Why this option was chosen  
+
+This log should be preserved for documentation.
+
+---
+
+## After the Design
+
+### 📄 Documentation
+
+Once the design is validated:
+
+- Write the final design to a durable, shared format (e.g. Markdown)
+- Include:
+  - Understanding summary
+  - Assumptions
+  - Decision log
+  - Final design
+
+Persist the document according to the project’s standard workflow.
+
+---
+
+### 🛠️ Implementation Handoff (Optional)
+
+Only after documentation is complete, ask:
+
+> “Ready to set up for implementation?”
+
+If yes:
+- Create an explicit implementation plan
+- Isolate work if the workflow supports it
+- Proceed incrementally
+
+---
+
+## Exit Criteria (Hard Stop Conditions)
+
+You may exit brainstorming mode **only when all of the following are true**:
+
+- Understanding Lock has been confirmed  
+- At least one design approach is explicitly accepted  
+- Major assumptions are documented  
+- Key risks are acknowledged  
+- Decision Log is complete  
+
+If any criterion is unmet:
+- Continue refinement  
+- **Do NOT proceed to implementation**
+
+---
+
+## Key Principles (Non-Negotiable)
+
+- One question at a time  
+- Assumptions must be explicit  
+- Explore alternatives  
+- Validate incrementally  
+- Prefer clarity over cleverness  
+- Be willing to go back and clarify  
+- **YAGNI ruthlessly**
+
+---
+If the design is high-impact, high-risk, or requires elevated confidence, you MUST hand off the finalized design and Decision Log to the `multi-agent-brainstorming` skill before implementation.
+
+
+## Gap Analysis Rule
+Always identify gaps and suggest next steps to users. In case there is no gaps anymore, then AI should clearly state that there is no gap left.

package/skills/c4-context/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: c4-context
+description: Expert C4 Context-level documentation specialist. Creates
+  high-level system context diagrams, documents personas, user journeys, system
+  features, and external dependencies. Synthesizes container and component
+  documentation with system documentation to create comprehensive context-level
+  architecture. Use when creating the highest-level C4 system context
+  documentation.
+metadata:
+  model: sonnet
+---
+
+# C4 Context Level: System Context
+
+## Use this skill when
+
+- Working on c4 context level: system context tasks or workflows
+- Needing guidance, best practices, or checklists for c4 context level: system context
+
+## Do not use this skill when
+
+- The task is unrelated to c4 context level: system context
+- You need a different domain or tool outside this scope
+
+## Instructions
+
+- Clarify goals, constraints, and required inputs.
+- Apply relevant best practices and validate outcomes.
+- Provide actionable steps and verification.
+- If detailed examples are required, open `resources/implementation-playbook.md`.
+
+## System Overview
+
+### Short Description
+
+[One-sentence description of what the system does]
+
+### Long Description
+
+[Detailed description of the system's purpose, capabilities, and the problems it solves]
+
+## Personas
+
+### [Persona Name]
+
+- **Type**: [Human User / Programmatic User / External System]
+- **Description**: [Who this persona is and what they need]
+- **Goals**: [What this persona wants to achieve]
+- **Key Features Used**: [List of features this persona uses]
+
+## System Features
+
+### [Feature Name]
+
+- **Description**: [What this feature does]
+- **Users**: [Which personas use this feature]
+- **User Journey**: [Link to user journey map]
+
+## User Journeys
+
+### [Feature Name] - [Persona Name] Journey
+
+1. [Step 1]: [Description]
+2. [Step 2]: [Description]
+3. [Step 3]: [Description]
+   ...
+
+### [External System] Integration Journey
+
+1. [Step 1]: [Description]
+2. [Step 2]: [Description]
+   ...
+
+## External Systems and Dependencies
+
+### [External System Name]
+
+- **Type**: [Database, API, Service, Message Queue, etc.]
+- **Description**: [What this external system provides]
+- **Integration Type**: [API, Events, File Transfer, etc.]
+- **Purpose**: [Why the system depends on this]
+
+## System Context Diagram
+
+[Mermaid diagram showing system, users, and external systems]
+
+## Related Documentation
+
+- [Container Documentation](./c4-container.md)
+- [Component Documentation](./c4-component.md)
+```
+
+## Context Diagram Template
+
+According to the [C4 model](https://c4model.com/diagrams/system-context), a System Context diagram shows the system as a box in the center, surrounded by its users and the other systems that it interacts with. The focus is on **people (actors, roles, personas) and software systems** rather than technologies, protocols, and other low-level details.
+
+Use proper Mermaid C4 syntax:
+
+```mermaid
+C4Context
+    title System Context Diagram
+
+    Person(user, "User", "Uses the system to accomplish their goals")
+    System(system, "System Name", "Provides features X, Y, and Z")
+    System_Ext(external1, "External System 1", "Provides service A")
+    System_Ext(external2, "External System 2", "Provides service B")
+    SystemDb(externalDb, "External Database", "Stores data")
+
+    Rel(user, system, "Uses")
+    Rel(system, external1, "Uses", "API")
+    Rel(system, external2, "Sends events to")
+    Rel(system, externalDb, "Reads from and writes to")
+```
+
+**Key Principles** (from [c4model.com](https://c4model.com/diagrams/system-context)):
+
+- Focus on **people and software systems**, not technologies
+- Show the **system boundary** clearly
+- Include all **users** (human and programmatic)
+- Include all **external systems** the system interacts with
+- Keep it **stakeholder-friendly** - understandable by non-technical audiences
+- Avoid showing technologies, protocols, or low-level details
+
+## Example Interactions
+
+- "Create C4 Context-level documentation for the system"
+- "Identify all personas and create user journey maps for key features"
+- "Document external systems and create a system context diagram"
+- "Analyze system documentation and create comprehensive context documentation"
+- "Map user journeys for all key features including programmatic users"
+
+## Key Distinctions
+
+- **vs C4-Container agent**: Provides high-level system view; Container agent focuses on deployment architecture
+- **vs C4-Component agent**: Focuses on system context; Component agent focuses on logical component structure
+- **vs C4-Code agent**: Provides stakeholder-friendly overview; Code agent provides technical code details
+
+## Output Examples
+
+When creating context documentation, provide:
+
+- Clear system descriptions (short and long)
+- Comprehensive persona documentation (human and programmatic)
+- Complete feature lists with descriptions
+- Detailed user journey maps for all key features
+- Complete external system and dependency documentation
+- Mermaid context diagram showing system, users, and external systems
+- Links to container and component documentation
+- Stakeholder-friendly documentation understandable by non-technical audiences
+- Consistent documentation format
+
+
+## Gap Analysis Rule
+Always identify gaps and suggest next steps to users. In case there is no gaps anymore, then AI should clearly state that there is no gap left.

package/skills/ci-cd-engineer/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: ci-cd-engineer
+description: Design and implement continuous integration and deployment pipelines
+---
+
+# CI/CD Engineer
+
+## Overview
+
+Your role is to automate the software delivery process. You ensure that code can be reliably built, tested, and deployed to production.
+
+## When to Use This Skill
+
+- Setting up GitHub Actions / GitLab CI
+- Automating testing and linting
+- Configuring deployment environments (Staging, Production)
+- Managing secrets and environment variables
+
+## Core Responsibilities
+
+1.  **Pipeline Design**: Defining steps for build, test, and deploy.
+2.  **Automation**: reducing manual toil in release processes.
+3.  **Environment Management**: ensuring parity between dev, stage, and prod.
+4.  **Security**: Scanning dependencies and secrets in the pipeline.
+
+## Pipeline Stages
+
+1.  **Lint & Format**: Fail fast if code style is wrong.
+2.  **Build**: Compile code and check for errors.
+3.  **Test**: Run unit and integration tests.
+4.  **Security**: Run SAST/DAST scans.
+5.  **Deploy**: Push artifact to target environment (e.g. AWS, Vercel).
+
+### Example GitHub Action Snippet
+```yaml
+name: CI
+on: [push]
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v2
+      - run: npm install
+      - run: npm test
+```
+
+
+## Gap Analysis Rule
+Always identify gaps and suggest next steps to users. In case there is no gaps anymore, then AI should clearly state that there is no gap left.

package/skills/code-auditing/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: code-auditing
+description: Analyze code for security vulnerabilities like SQL injection, XSS, and broken authentication. Use when tasked with reviewing code for security flaws.
+allowed-tools: Read, Glob, Grep
+---
+
+# Code Auditing Framework
+
+> "Trust, but verify. Then verify again."
+
+## 🎯 Selective Reading Rule
+
+**Read ONLY files relevant to the security context!**
+
+| File | Description | When to Read |
+|------|-------------|--------------|
+| `*.py`, `*.js`, `*.ts` | Source code files | Identify potential vulnerabilities |
+| `poetry.lock`, `package-lock.json` | Dependency files | Check for known vulnerable dependencies |
+| `README.md` | Project documentation | Understand architecture and data flow |
+
+---
+
+## 🔗 Related Skills
+
+| Skill | Use For |
+|-------|---------|
+| `@[skills/secure-refactoring]` | Fixing identified vulnerabilities |
+| `@[skills/security-documentation]` | Documenting findings |
+| `@[skills/api-security-best-practices]` | API specific security checks |
+
+---
+
+## Core Principle
+
+**"Security is not an afterthought."**
+
+- Identify input vectors (API endpoints, form inputs)
+- Trace data flow to sinks (Database queries, HTML output)
+- Look for missing validation or sanitization
+
+---
+
+## Auditing Checklist
+
+Before reporting findings:
+
+- [ ] Identified potential SQL injection points
+- [ ] Checked for XSS vulnerabilities in output
+- [ ] Verified authentication and authorization logic
+- [ ] Checked for hardcoded secrets
+- [ ] Validated input sanitization
+
+
+## Gap Analysis Rule
+Always identify gaps and suggest next steps to users. In case there is no gaps anymore, then AI should clearly state that there is no gap left.