cfsa-antigravity 1.0.0

package/template/.agent/skills/code-review-pro/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: Code Review Pro
+description: Deep code analysis covering security, performance, maintainability, and best practices
+---
+
+# Code Review Pro
+
+Deep code analysis covering security, performance, maintainability, and best practices.
+
+## When to Use This Skill
+Activate when the user:
+- Asks for a code review
+- Wants security vulnerability scanning
+- Needs performance analysis
+- Asks to "review this code" or "audit this code"
+- Mentions finding bugs or improvements
+- Wants refactoring suggestions
+- Requests best practice validation
+
+## Instructions
+1. **Security Analysis (Critical Priority)**
+   - SQL injection vulnerabilities
+   - XSS (cross-site scripting) risks
+   - Authentication/authorization issues
+   - Secrets or credentials in code
+   - Unsafe deserialization
+   - Path traversal vulnerabilities
+   - CSRF protection
+   - Input validation gaps
+   - Insecure cryptography
+   - Dependency vulnerabilities
+
+2. **Performance Analysis**
+   - N+1 query problems
+   - Inefficient algorithms (check Big O complexity)
+   - Memory leaks
+   - Unnecessary re-renders (React/Vue)
+   - Missing indexes (database queries)
+   - Blocking operations
+   - Resource cleanup (file handles, connections)
+   - Caching opportunities
+   - Excessive network calls
+   - Large bundle sizes
+
+3. **Code Quality & Maintainability**
+   - Code duplication (DRY violations)
+   - Function/method length (should be <50 lines)
+   - Cyclomatic complexity
+   - Unclear naming
+   - Missing error handling
+   - Inconsistent style
+   - Missing documentation
+   - Hard-coded values that should be constants
+   - God classes/functions
+   - Tight coupling
+
+4. **Best Practices**
+   - Language-specific idioms
+   - Framework conventions
+   - SOLID principles
+   - Design patterns usage
+   - Testing approach
+   - Logging and monitoring
+   - Accessibility (for UI code)
+   - Type safety
+   - Null/undefined handling
+
+5. **Bugs and Edge Cases**
+   - Logic errors
+   - Off-by-one errors
+   - Race conditions
+   - Null pointer exceptions
+   - Unhandled edge cases
+   - Timezone issues
+   - Encoding problems
+   - Floating point precision
+
+6. **Provide Actionable Fixes**
+   - Show specific code changes
+   - Explain why change is needed
+   - Include before/after examples
+   - Prioritize by severity
+
+## Output Format
+```markdown
+# Code Review Report
+
+## 🚨 Critical Issues (Fix Immediately)
+### 1. [Issue Title] (line X)
+**Severity**: Critical
+**Issue**: [Description]
+**Impact**: [What could happen]
+
+**Current Code:**
+```
+[problematic code]
+```
+
+**Fixed Code:**
+```
+[corrected code]
+```
+
+**Explanation**: [Why this matters]
+
+## ⚠️ High Priority Issues
+### 2. [Issue] (line Y)
+[Details...]
+
+## 💡 Medium Priority Issues
+### 3. [Issue] (line Z)
+[Details...]
+
+## ✅ Low Priority / Nice to Have
+### 4. [Issue]
+[Details...]
+
+## 📊 Summary
+- **Total Issues**: N
+  - Critical: X
+  - High: Y
+  - Medium: Z
+  - Low: W
+
+## 🎯 Quick Wins
+Changes with high impact and low effort:
+1. [Fix 1]
+2. [Fix 2]
+
+## 🏆 Strengths
+- [Positive observation 1]
+- [Positive observation 2]
+
+## 🔄 Refactoring Opportunities
+1. **Extract Method**: Lines X-Y could be extracted into `functionName()`
+2. **Remove Duplication**: [specific code blocks]
+```
+
+## Best Practices
+- Always prioritize security issues first
+- Provide specific line numbers for issues
+- Include before/after code examples
+- Explain *why* something is a problem
+- Consider the language/framework context
+- Don't just criticize—acknowledge good code too
+- Suggest gradual improvements for large refactors
+- Link to documentation for recommendations
+- Consider project constraints (legacy code, deadlines)
+- Balance perfectionism with pragmatism
+- Focus on impactful changes
+- Group similar issues together
+- Make recommendations actionable

package/template/.agent/skills/concise-planning/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: concise-planning
+description: "Use when a user asks for a plan for a coding task, to generate a clear, actionable, and atomic checklist."
+risk: unknown
+source: community
+date_added: "2026-02-27"
+---
+
+# Concise Planning
+
+## Goal
+
+Turn a user request into a **single, actionable plan** with atomic steps.
+
+## Workflow
+
+### 1. Scan Context
+
+- Read `README.md`, docs, and relevant code files.
+- Identify constraints (language, frameworks, tests).
+
+### 2. Minimal Interaction
+
+- Ask **at most 1–2 questions** and only if truly blocking.
+- Make reasonable assumptions for non-blocking unknowns.
+
+### 3. Generate Plan
+
+Use the following structure:
+
+- **Approach**: 1-3 sentences on what and why.
+- **Scope**: Bullet points for "In" and "Out".
+- **Action Items**: A list of 6-10 atomic, ordered tasks (Verb-first).
+- **Validation**: At least one item for testing.
+
+## Plan Template
+
+```markdown
+# Plan
+
+<High-level approach>
+
+## Scope
+
+- In:
+- Out:
+
+## Action Items
+
+[ ] <Step 1: Discovery>
+[ ] <Step 2: Implementation>
+[ ] <Step 3: Implementation>
+[ ] <Step 4: Validation/Testing>
+[ ] <Step 5: Rollout/Commit>
+
+## Open Questions
+
+- <Question 1 (max 3)>
+```
+
+## Checklist Guidelines
+
+- **Atomic**: Each step should be a single logical unit of work.
+- **Verb-first**: "Add...", "Refactor...", "Verify...".
+- **Concrete**: Name specific files or modules when possible.
+
+## When to Use
+This skill is applicable to execute the workflow or actions described in the overview.

package/template/.agent/skills/cross-layer-consistency/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: cross-layer-consistency
+description: Systematic methodology for verifying that IA, BE, and FE specification layers are mutually consistent. Covers coverage matrices, field mapping checks, error code propagation, access control consistency, and data contract drift detection.
+---
+
+# Cross-Layer Consistency
+
+This skill provides the systematic consistency verification pass run by `audit-ambiguity-execute`, `remediate-pipeline-execute`, `propagate-decision-scan`, and `evolve-feature-cascade`, and its output is a set of labeled consistency issues with layer attribution.
+
+## When to Use
+
+- After all three spec layers (IA, BE, FE) have at least one document written
+- As part of every audit, every remediation, every decision propagation, and every feature evolution cascade
+- As a standalone pre-gate check before advancing any pipeline stage
+
+## Instructions
+
+### 1. IA → BE Coverage Matrix
+
+Open `docs/plans/ia/index.md` to enumerate all IA shards. For each shard, read its data model and state transition sections. Then open `docs/plans/be/` and verify:
+
+- Every IA data model entity has a corresponding BE spec section describing its schema, storage contract, and CRUD operations.
+- Every IA state transition has a corresponding BE endpoint that drives it.
+- Every IA user action (described in the interactions section) has a corresponding API contract in the BE spec.
+
+Build a coverage table:
+
+| IA Shard | IA Section | BE Spec Section | Status |
+|----------|-----------|-----------------|--------|
+| [name]   | [section] | [BE section]    | ✅ / ❌ |
+
+Document each gap as:
+
+```
+COVERAGE GAP: IA shard [name] § [section] → no corresponding BE spec section found.
+```
+
+### 2. BE → FE Field Mapping Check
+
+For every BE endpoint documented in `docs/plans/be/`, enumerate all response fields. For each field, verify it appears in `docs/plans/fe/` — in a component prop definition, a display element, a table column, or an explicit "field not rendered" exclusion.
+
+Then for each FE component, verify every input prop maps to a BE request field.
+
+Build a mapping table:
+
+| BE Endpoint | Field | FE Spec Location | Status |
+|-------------|-------|-------------------|--------|
+| [endpoint]  | [field] | [FE location]   | ✅ / ❌ |
+
+Document each gap as:
+
+```
+MAPPING GAP: BE endpoint [name] field [field] → not referenced in FE spec.
+```
+
+### 3. Error Code Consistency Cross-Reference
+
+Build an error code table across layers: for every HTTP status code and application error type defined in BE specs, create a row. Then for each row, identify the FE spec location that handles it (error boundary, toast handler, inline error state, retry logic).
+
+| BE Endpoint | Error Code | FE Handler | FE Spec Location | Status |
+|-------------|-----------|------------|-------------------|--------|
+| [endpoint]  | [code]    | [handler]  | [location]        | ✅ / ❌ |
+
+Any BE error code with no corresponding FE entry is a gap. Document as:
+
+```
+CONSISTENCY ISSUE: BE § [endpoint] error [code] ↔ FE — no handling found — remediation: add [code] handler to [FE spec section].
+```
+
+### 4. Access Control Propagation Check
+
+For every access control rule defined in IA shards (role-resource-operation triplets), verify the rule appears in both:
+
+- **BE**: as a middleware guard, route-level permission check, or explicit authorization step in the endpoint contract.
+- **FE**: as a conditional render, route guard, or disabled state on the triggering UI element.
+
+A rule missing from either layer is a gap. Document as:
+
+```
+CONSISTENCY ISSUE: IA § [access control section] permission [role→resource:operation] ↔ [BE or FE] — not found — remediation: add guard to [target layer § section].
+```
+
+### 5. Data Contract Drift Detection
+
+When invoked in the context of a schema change (e.g., after `evolve-contract` or a `propagate-decision` run), scan all files under `docs/plans/` for references to the changed type, field name, or validation rule. Check for:
+
+- Field name string matches
+- Type annotation references
+- Validation rule references
+
+For each file that references the old definition and has not been updated, document as:
+
+```
+CONSISTENCY ISSUE: [source layer] § [section] ↔ [target file] § [section] — [field/type] changed in source but not reflected in target — remediation: update [target] to match [source].
+```
+
+### 6. Documenting Inconsistencies
+
+All consistency issues must be written using this exact format:
+
+```
+CONSISTENCY ISSUE: [source layer] § [section] ↔ [target layer] § [section] — [what is inconsistent] — [remediation: update [target] to match [source] OR raise for user decision]
+```
+
+- **Source layer** is the authoritative layer (the one that should not change).
+- **Target layer** is the one that needs updating.
+- When it is unclear which layer is authoritative, write `raise for user decision` as the remediation and present both versions to the user. Never silently pick one.
+
+## Anti-Patterns
+
+- **One-direction-only checking** — Checking only one direction of the matrix (IA→BE but not BE→IA). Coverage gaps exist in both directions.
+- **Skipping the error code table** — Skipping the error code table because "the FE will just show a generic error." Every BE error code must have an explicit FE handling specification.
+- **Treating access control propagation as optional** — Treating access control propagation as optional when the spec "looks simple." Missing FE route guards are a security gap, not a style preference.
+
+## Related Skills
+
+- **`resolve-ambiguity`** — Hand off to `resolve-ambiguity` when a consistency issue cannot be resolved by simply updating the target layer to match the source. Specifically: when both layers present plausible but conflicting definitions and it is unclear which is authoritative, or when the inconsistency reveals a gap that requires new information from the user. This skill detects *what is inconsistent*; `resolve-ambiguity` determines *what the correct answer should be* through its tiered information-gathering methodology.