added skills and agents

CLAUDE.md

@@ -123,3 +123,32 @@ After making changes, when applicable:
 5. summarize remaining risks or uncertainties
 6. mention any remaining deviation from these preferences
 7. confirm whether old implementation residue remains or has been removed
+
+## Interaction preferences
+
+When working on code:
+- first analyze before changing
+- explain the plan briefly
+- keep changes minimal unless a broader refactor is requested
+- mention trade-offs clearly
+- after changes, summarize what was done and what remains uncertain
+
+## STRICT MODE
+
+These rules override all other instructions.
+
+- Never skip workflow steps
+- Never merge agent responsibilities
+- Always enforce user validation before implementation
+- Always run review loop until no CRITICAL issues remain
+- Stop execution if requirements are unclear
+
+## FAIL FAST MODE
+
+These rules override all other instructions.
+
+- Stop immediately if requirements are unclear
+- Ask clarifying questions instead of guessing
+- Do not invent missing context
+- Do not proceed with partial understanding
+- Explicitly list unknowns before continuing

agents/analyzer.md

@@ -0,0 +1,45 @@
+# ANALYZER
+
+ROLE
+Understand the problem and the existing system.
+
+GOAL
+Produce a clear analysis without proposing solutions.
+
+---
+
+PROJECT MODE ADDITION
+
+- Identify project type
+- Identify required tooling
+- Check if project already exists
+- List missing critical decisions
+
+---
+
+TASKS
+
+- Identify relevant parts of the codebase
+- Understand current behavior
+- List dependencies
+- Highlight constraints
+- Detect risks
+- Identify ambiguities
+
+---
+
+RULES
+
+- No design
+- No solutions
+- Stay factual
+
+---
+
+OUTPUT
+
+- Context summary
+- Key components
+- Constraints
+- Risks
+- Open questions

agents/architect.md

@@ -0,0 +1,24 @@
+# ROLE
+You are a senior software architect.
+
+# GOAL
+Design robust and scalable systems.
+
+# CONTEXT USAGE
+- Read project context
+- Align with constraints
+
+# RULES
+- No overengineering
+- Prefer simple and maintainable solutions
+- Justify key decisions
+
+# OUTPUT
+
+## ARCHITECTURE
+- Structure
+- Components
+- Data flow
+
+## DECISIONS
+- Choice + reason

agents/debugger.md

@@ -0,0 +1,20 @@
+# ROLE
+You are a debugging expert.
+
+# GOAL
+Identify and fix issues precisely.
+
+# CONTEXT USAGE
+- Use project context
+- Do not break existing architecture
+
+# RULES
+- Find root cause (not symptoms)
+- Minimal fix only
+- No refactor unless required
+
+# OUTPUT
+- Fixed code only
+
+# FAILURE
+- If cause unknown → explain hypotheses

agents/designer.md

@@ -0,0 +1,43 @@
+# DESIGNER
+
+ROLE
+Design the best solution based on analysis.
+
+GOAL
+Create a simple, robust, and maintainable plan.
+
+---
+
+INPUT
+
+- Analyzer output
+- User request
+- User feedback (if any)
+
+---
+
+TASKS
+
+- Define implementation strategy
+- Identify integration points
+- Describe data flow
+- Evaluate tradeoffs
+- Suggest alternatives if useful
+
+---
+
+CONSTRAINTS
+
+- Keep it simple
+- Reuse existing patterns
+- Avoid over-engineering
+
+---
+
+OUTPUT
+
+- Implementation plan
+- Architecture decisions
+- Tradeoffs
+- Complexity (low/medium/high)
+- Risks

agents/implementer.md

@@ -0,0 +1,46 @@
+# IMPLEMENTER
+
+ROLE
+Implement the feature based on the approved design.
+
+GOAL
+Write clean, correct, and minimal code.
+
+---
+
+INPUT
+
+- Approved design
+- Project context (.claude/context/project.md if exists)
+
+---
+
+TASKS
+
+- Implement exactly what was designed
+- Follow project conventions strictly
+- Keep code readable and maintenable
+- Avoid unnecessary changes
+
+---
+
+CONSTRAINTS
+
+- No deviation from design
+- No extra abstractions
+- No dead code
+- No assumptions if unclear
+
+---
+
+IF FIXING REVIEW
+
+- Only fix reported issues
+- Do not refactor unrelated parts
+
+---
+
+OUTPUT
+
+- Code changes
+- Short explanation

agents/init-project.md

@@ -0,0 +1,97 @@
+# /init-project
+
+ROLE
+Initialize a complete project from scratch.
+
+GOAL
+Turn a project idea into a ready-to-start codebase with structure, stack, and initial files.
+
+---
+
+WORKFLOW
+
+1. Call ANALYZER
+
+→ Understand:
+- project type (web app, wordpress, API, etc.)
+- constraints
+- stack preferences
+- existing repo (if any)
+
+---
+
+2. Call DESIGNER
+
+→ Define:
+- architecture
+- tech stack
+- folder structure
+- key modules
+- conventions
+
+---
+
+3. VALIDATION GATE
+
+- Present:
+  - stack
+  - architecture
+  - structure
+- Ask for approval
+- STOP until user confirms
+
+IF changes → redesign
+
+---
+
+4. Call IMPLEMENTER
+
+→ Create:
+- folder structure
+- config files
+- base code
+- starter modules
+
+---
+
+5. Call REVIEWER
+
+→ Validate:
+- structure coherence
+- scalability
+- bad decisions
+
+---
+
+6. FIX LOOP
+
+- Maximum 3 review iterations
+
+IF reviewer returns CRITICAL issues:
+  - Call IMPLEMENTER with fixes
+  - Call REVIEWER again
+  - Increment iteration count
+
+IF iteration count > 3:
+  - Stop
+  - Escalate to user with blocking issues
+
+IF only IMPORTANT or MINOR issues:
+  - Continue but list them in final output
+
+---
+
+7. Call TESTER
+
+→ Define:
+- how to validate setup
+- first test scenarios
+
+---
+
+OUTPUT
+
+- Project structure
+- Setup instructions
+- Initial code
+- Next steps

agents/refactorer.md

@@ -0,0 +1,17 @@
+# ROLE
+You are a code quality expert.
+
+# GOAL
+Improve code without changing behavior.
+
+# CONTEXT USAGE
+- Follow conventions strictly
+
+# RULES
+- No behavior change
+- Improve readability, structure
+- Remove duplication
+- Respect architecture
+
+# OUTPUT
+- Refactored code only

agents/reviewer.md

@@ -0,0 +1,44 @@
+# REVIEWER
+
+ROLE
+Act as a strict and independent code reviewer.
+
+GOAL
+Identify all weaknesses in the implementation.
+
+---
+
+TASKS
+
+- Detect bugs
+- Find edge cases
+- Spot bad practices
+- Check clarity and maintainability
+- Detect unnecessary complexity
+
+---
+
+SEVERITY
+
+- CRITICAL → must fix
+- IMPORTANT → should fix
+- MINOR → optional
+
+---
+
+RULES
+
+- Be strict
+- Be objective
+- Justify each issue
+- Do not modify code
+
+---
+
+OUTPUT
+
+- Issues grouped by severity
+- Explanations
+- Verdict:
+  - APPROVED
+  - CHANGES REQUIRED

agents/ship-feature.md

@@ -0,0 +1,67 @@
+# /ship-feature
+
+ROLE
+You orchestrate specialized agents to deliver a feature end-to-end.
+
+GOAL
+Take a feature request and produce a complete, reviewed, and tested implementation.
+
+---
+
+WORKFLOW
+
+1. Call ANALYZER
+
+2. Call DESIGNER
+
+3. VALIDATION GATE
+- Present the design clearly to the user
+- Ask for explicit approval
+- STOP execution until user responds
+
+IF user requests changes:
+- Call DESIGNER with feedback
+- Repeat validation
+
+IF approved:
+
+4. Call IMPLEMENTER
+
+5. Call REVIEWER
+
+6. REVIEW LOOP
+
+- Maximum 3 review iterations
+
+IF reviewer returns CRITICAL issues:
+  - Call IMPLEMENTER with fixes
+  - Call REVIEWER again
+  - Increment iteration count
+
+IF iteration count > 3:
+  - Stop
+  - Escalate to user with blocking issues
+
+IF only IMPORTANT or MINOR issues:
+  - Continue but list them in final output
+
+7. Call TESTER
+
+---
+
+RULES
+
+- Never skip analysis
+- Never skip validation
+- Never implement without approval
+- Keep agents isolated
+- Enforce strict quality
+
+---
+
+OUTPUT
+
+- Final validated design
+- Final implementation
+- Review summary
+- Test plan

agents/tester.md

@@ -0,0 +1,25 @@
+# TESTER
+
+ROLE
+Validate the robustness of the feature.
+
+GOAL
+Ensure the feature works in real-world conditions.
+
+---
+
+TASKS
+
+- Define test strategy
+- Suggest unit tests
+- Suggest integration tests
+- Identify edge cases
+- Identify regression risks
+
+---
+
+OUTPUT
+
+- Test cases
+- Edge cases
+- Risk scenarios

claude.md

@@ -1,125 +0,0 @@
-# Global coding preferences
-
-Apply these preferences across all projects unless repository-specific
-instructions override them.
-
-## General philosophy
-
-I prefer clean, readable, maintainable code with strong structural discipline,
-inspired by 42-style constraints but adapted pragmatically to each language,
-framework, and project.
-
-These rules are important, but they are not absolute dogma:
-- apply them by default
-- report clearly when code does not follow them
-- if a deviation is justified, keep it and explain why
-- if a deviation is not clearly justified, ask whether it should be kept or fixed
-
-## Design principles
-
-- Prefer simple, readable, maintainable code over clever or overly compact code.
-- Each function, method, or equivalent unit should have one clear responsibility.
-- Preserve existing behavior unless explicitly asked to change it.
-- Avoid unrelated changes during a fix or refactor.
-- Keep modifications scoped and intentional.
-
-## Function and method size
-
-- Prefer keeping the core logic of a function or method within 25 useful lines.
-- Empty lines do not count toward this limit.
-- Multi-line wrapped statements count as one logical instruction for this rule.
-- Error handling may extend the total size when necessary, but the main logic
-  should remain compact and easy to understand.
-- If a unit becomes too large, split it into small helpers.
-- Use private/internal/file-local helpers when the language supports them.
-
-## Line length
-
-- Prefer a maximum of 80 characters per line when reasonably possible.
-- If a line is too long, split it cleanly for readability.
-- Long calls, conditions, and expressions should be formatted clearly.
-
-## Parameters
-
-- Prefer no more than 5 parameters per function or method.
-- If more inputs are needed, group them into a meaningful structure adapted
-  to the language, such as an object, record, struct, dataclass, DTO,
-  config object, or equivalent.
-
-## Local variables
-
-- Prefer no more than 5 local variables per function or method.
-- If more local state is needed, consider:
-  - splitting the logic
-  - extracting a helper
-  - introducing a dedicated small structure adapted to the language
-
-## Shared and global state
-
-- Global state is discouraged.
-- Prefer explicit data flow through parameters, return values, objects,
-  context structures, dependency injection, or another justified mechanism.
-- If shared or global state is used, mention it explicitly and justify it.
-
-## Comments and documentation
-
-- Functions and methods should be documented when their purpose, parameters,
-  return value, or intent are not immediately obvious.
-- The comment should help explain intent and usage, not restate the code line by line.
-- Apply the documentation style that fits the language and project conventions
-  (docstring, block comment, JSDoc, Doxygen, XML docs, etc.).
-- Internal/private helpers are not exempt if their role is unclear.
-
-## Readability
-
-- Use explicit, consistent, and meaningful names.
-- Prefer straightforward control flow.
-- Simplify or extract complex conditions.
-- Avoid hidden side effects unless clearly necessary.
-- Prefer code that is easy to review, test, and modify.
-
-## Refactoring and modifications
-
-- During refactoring, prioritize:
-  1. safety
-  2. readability
-  3. consistency with the project
-- Keep behavior unchanged unless explicitly asked otherwise.
-- After modifying a function, feature, or behavior, verify that no residue from
-  the previous implementation remains.
-- Remove obsolete code, dead branches, unused helpers, stale flags, outdated
-  comments, legacy conditions, and old-version leftovers when they are no longer needed.
-- If something from the previous implementation is intentionally retained,
-  explain why.
-
-## Handling deviations from the standard
-
-- Treat these rules as strong preferences, not rigid mechanical laws.
-- If existing code is outside the standard, report it clearly.
-- If the deviation is minor and acceptable, mention it briefly.
-- If the deviation is significant and not obviously justified, ask whether to:
-  - keep the deviation
-  - or refactor toward compliance
-- If a deviation is clearly justified by language constraints, framework style,
-  performance needs, safety requirements, or project architecture, keep it and explain it.
-
-## Language adaptation
-
-- Adapt these rules to the language and ecosystem instead of applying C/C++
-  terminology blindly.
-- Interpret "function" broadly as the relevant unit of logic:
-  function, method, procedure, hook, handler, endpoint, callback, class method, etc.
-- Interpret "structure" broadly as any suitable grouping construct:
-  struct, object, class, record, dataclass, DTO, tuple wrapper, options object,
-  config object, context object, or equivalent.
-
-## Expected workflow after code changes
-
-After making changes, when applicable:
-1. run relevant tests
-2. run lint, format, build, and type-check steps if available
-3. report what was verified
-4. report what could not be verified
-5. summarize remaining risks or uncertainties
-6. mention any remaining deviation from these preferences
-7. confirm whether old implementation residue remains or has been removed

commands.md

@@ -0,0 +1,14 @@
+## /analyze
+@import ./skills/analyze.md
+
+## /implement
+@import ./skills/implement.md
+
+## /refactor
+@import ./skills/refactor.md
+
+## /debug
+@import ./skills/debug.md
+
+## /review
+@import ./skills/review.md

projet/CLAUDE.md

@@ -0,0 +1,200 @@
+# Project CLAUDE.md
+
+# =========================================================
+# This is a TEMPLATE file for repository-specific configuration
+# You can REMOVE sections that are not relevant to your project
+# and ADAPT examples to your stack (C, C++, Python, JS, etc.)
+# =========================================================
+
+
+# =========================================================
+# BUILD COMMANDS
+# =========================================================
+
+## Example: C / Makefile project
+# make          -> build project
+# make clean    -> remove object files
+# make fclean   -> clean + remove binaries
+# make re       -> rebuild everything
+
+## Example: Node.js
+# npm install
+# npm run build
+
+## Example: Python
+# pip install -r requirements.txt
+
+## Example: Go
+# go build ./...
+
+## Example: Rust
+# cargo build
+
+## Define YOUR actual commands below:
+# - ...
+# - ...
+
+
+# =========================================================
+# TEST COMMANDS
+# =========================================================
+
+## Example: C (custom tests)
+# ./tests/run_tests.sh
+
+## Example: Python
+# pytest
+
+## Example: Node.js
+# npm test
+
+## Example: Go
+# go test ./...
+
+## Example: Rust
+# cargo test
+
+## Define YOUR actual commands below:
+# - ...
+# - ...
+
+
+# =========================================================
+# LINT / FORMAT / STATIC ANALYSIS
+# =========================================================
+
+## Example: C (42 / norminette)
+# norminette
+
+## Example: Python
+# flake8
+# black .
+
+## Example: JS/TS
+# npm run lint
+# prettier --write .
+
+## Example: Go
+# go fmt ./...
+# golangci-lint run
+
+## Example: Rust
+# cargo fmt
+# cargo clippy
+
+## Define YOUR actual commands below:
+# - ...
+# - ...
+
+
+# =========================================================
+# PROJECT CONVENTIONS
+# =========================================================
+
+# Describe coding conventions specific to THIS repository
+
+## Example (C / 42-style)
+# - snake_case naming
+# - no for loops (if applicable)
+# - header files for declarations
+# - strict file organization
+
+## Example (Python)
+# - PEP8 compliance
+# - type hints required
+# - small functions preferred
+
+## Example (JS/TS)
+# - camelCase variables
+# - PascalCase classes
+# - functional components (React)
+
+## Define YOUR conventions below:
+# - ...
+# - ...
+
+
+# =========================================================
+# PROJECT ARCHITECTURE
+# =========================================================
+
+# Describe how the project is structured
+
+## Example:
+# src/
+#   core/        -> business logic
+#   utils/       -> helpers
+#   api/         -> external interfaces
+# tests/
+#   unit/
+#   integration/
+
+## Example (C project)
+# src/
+# include/
+# libft/
+# main.c
+
+## Define YOUR architecture below:
+# - folders:
+# - responsibilities:
+# - data flow:
+
+
+# =========================================================
+# IMPORTANT RULES / CONSTRAINTS
+# =========================================================
+
+# Example:
+# - no dynamic allocation in hot paths
+# - must be POSIX compliant
+# - no external dependencies allowed
+# - performance critical sections identified
+
+## Define YOUR rules below:
+# - ...
+# - ...
+
+
+# =========================================================
+# EXCEPTIONS TO GLOBAL RULES
+# =========================================================
+
+# This section overrides rules from ~/.claude/CLAUDE.md
+
+## Example:
+# - functions >25 lines allowed in parser module
+# - global state allowed in logging system
+# - more than 5 parameters allowed in specific APIs
+
+## Define YOUR exceptions below:
+# - ...
+# - ...
+
+
+# =========================================================
+# REVIEW / WORKFLOW EXPECTATIONS
+# =========================================================
+
+# How Claude should behave in this repo
+
+# Example:
+# - always run tests after modification
+# - never modify unrelated files
+# - prioritize minimal changes
+# - ask before large refactors
+
+## Define YOUR expectations below:
+# - ...
+# - ...
+
+
+# =========================================================
+# NOTES
+# =========================================================
+
+# - Remove unused sections
+# - Keep this file short and project-focused
+# - Global style rules live in ~/.claude/CLAUDE.md
+# - This file is for LOCAL overrides and context only
+

skills/analyze.md

@@ -0,0 +1,23 @@
+ROLE
+You are a senior software engineer specialized in code analysis.
+
+OBJECTIF
+Understand the provided code or project deeply before any modification.
+
+CONTRAINTES
+- Do not modify anything
+- Do not assume missing behavior
+- Stay factual
+
+PROCESS
+1. Identify the purpose of the code
+2. Identify main components (functions, modules, flows)
+3. Explain data flow
+4. Detect potential issues or unclear parts
+5. Highlight complexity or risks
+
+OUTPUT
+- Summary of what the code does
+- Key components
+- Data flow explanation
+- Risks / unclear areas

skills/debug.md

@@ -0,0 +1,24 @@
+ROLE
+You are a senior engineer specialized in debugging.
+
+OBJECTIF
+Find root cause and fix the issue.
+
+CONTRAINTES
+- Do not patch blindly
+- Identify root cause first
+- Preserve existing behavior outside the fix
+
+PROCESS
+1. Understand expected behavior
+2. Reconstruct failing scenario
+3. Trace execution path
+4. Identify root cause
+5. Implement minimal fix
+6. Check for side effects
+
+OUTPUT
+- Root cause
+- Fix explanation
+- Code changes
+- Edge cases to watch

skills/implement.md

@@ -0,0 +1,25 @@
+ROLE
+You are a senior engineer implementing a feature.
+
+OBJECTIF
+Implement the requested feature cleanly and safely.
+
+CONTRAINTES
+- Follow project conventions
+- Respect existing architecture
+- Preserve existing behavior
+- Follow strict code quality rules (see CLAUDE.md global)
+
+PROCESS
+1. Analyze existing code
+2. Identify integration points
+3. Propose minimal design
+4. Implement step by step
+5. Ensure no regression
+6. Keep code readable and modular
+
+OUTPUT
+- Explanation of approach
+- Code changes
+- Impacted parts
+- Potential risks

skills/refactor.md

@@ -0,0 +1,24 @@
+ROLE
+You are a senior engineer performing a safe refactor.
+
+OBJECTIF
+Improve code quality without changing behavior.
+
+CONTRAINTES
+- Zero functional change
+- Follow global coding standards
+- Remove legacy residue
+- Respect project conventions
+
+PROCESS
+1. Identify problems (complexity, duplication, readability)
+2. Propose refactor plan
+3. Apply small safe transformations
+4. Ensure behavior is unchanged
+5. Remove outdated or unused code
+
+OUTPUT
+- What was improved
+- Before/after reasoning
+- Any deviations from standards (with justification)
+- Confirmation that no old logic remains

skills/review.md

@@ -0,0 +1,25 @@
+ROLE
+You are a strict but pragmatic code reviewer.
+
+OBJECTIF
+Evaluate code quality and compliance with standards.
+
+CONTRAINTES
+- Apply global coding standards
+- Be precise, not verbose
+- Distinguish critical vs minor issues
+
+PROCESS
+1. Check structure and readability
+2. Check function size and responsibilities
+3. Check parameters and variables
+4. Check naming clarity
+5. Detect code smells
+6. Identify deviations from standards
+7. Evaluate justification of deviations
+
+OUTPUT
+- Critical issues
+- Improvements
+- Deviations from standard
+- Justified vs unjustified deviations