@fenixforce/edition-pro 0.1.0

package/skills/builtin/api-development/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: api-development
+description: "Use this skill when the user asks to design an API, create API documentation, build REST or GraphQL endpoints, handle API versioning, or implement API patterns like pagination, filtering, and rate limiting. Triggers: 'API design', 'REST API', 'GraphQL', 'API documentation', 'OpenAPI', 'Swagger', 'endpoint design', 'pagination', 'API versioning', or requests focused specifically on API architecture and contracts."
+license: MIT
+---
+
+# API Development
+
+## What This Skill Does
+
+Design, document, and build APIs. REST conventions, GraphQL schemas, versioning strategy, pagination, filtering, error contracts, and OpenAPI documentation.
+
+## Before You Start
+
+1. **Context7:** Fetch docs for the API framework (Hono, Express, Fastify, etc.)
+2. **Clarify scope:** New API design, adding endpoints, or documenting existing?
+
+## REST API Design
+
+### URL Conventions
+```
+/api/v1/users                    # Collection
+/api/v1/users/:id                # Single resource
+/api/v1/users/:id/posts          # Nested resource
+```
+
+Rules:
+- Plural nouns (`/users` not `/user`)
+- No verbs (`POST /users` not `POST /createUser`)
+- Lowercase, hyphenated
+- Max 3 levels of nesting
+
+### Pagination
+```
+GET /api/v1/posts?page=2&limit=20
+
+Response:
+{
+  "data": [...],
+  "meta": { "page": 2, "limit": 20, "total": 156, "totalPages": 8, "hasNext": true }
+}
+```
+
+Cursor-based for large datasets:
+```
+GET /api/v1/posts?cursor=eyJpZCI6MTAwfQ&limit=20
+Response: { "data": [...], "meta": { "nextCursor": "...", "hasMore": true } }
+```
+
+### Filtering and Sorting
+```
+GET /api/v1/posts?status=published&author=123&sort=-createdAt,title&fields=id,title
+```
+
+### Error Response Contract
+```typescript
+interface ErrorResponse {
+  error: {
+    code: string;          // "VALIDATION_ERROR"
+    message: string;       // "Email is required"
+    details?: Array<{ field: string; message: string; code: string }>;
+    requestId?: string;
+  };
+}
+```
+
+Standard codes: `VALIDATION_ERROR` 422, `NOT_FOUND` 404, `UNAUTHORIZED` 401, `FORBIDDEN` 403, `CONFLICT` 409, `RATE_LIMITED` 429, `INTERNAL_ERROR` 500
+
+### Versioning
+URL-based: `/api/v1/users`, `/api/v2/users`. Bump major only for breaking changes. Support previous version 6+ months.
+
+## GraphQL API Design
+
+```graphql
+type User {
+  id: ID!
+  email: String!
+  name: String!
+  posts(first: Int, after: String): PostConnection!
+}
+
+type Query {
+  user(id: ID!): User
+  users(first: Int, after: String, filter: UserFilter): UserConnection!
+}
+
+type Mutation {
+  createPost(input: CreatePostInput!): Post!
+  updatePost(id: ID!, input: UpdatePostInput!): Post!
+  deletePost(id: ID!): Boolean!
+}
+```
+
+### Relay-Style Connections
+```graphql
+type PostConnection {
+  edges: [PostEdge!]!
+  pageInfo: PageInfo!
+  totalCount: Int!
+}
+type PostEdge { node: Post!; cursor: String! }
+type PageInfo { hasNextPage: Boolean!; endCursor: String }
+```
+
+## OpenAPI Documentation
+
+```yaml
+openapi: 3.1.0
+info:
+  title: My API
+  version: 1.0.0
+paths:
+  /api/v1/users:
+    get:
+      summary: List users
+      parameters:
+        - name: page
+          in: query
+          schema: { type: integer, default: 1 }
+      responses:
+        "200":
+          description: Paginated user list
+```
+
+Always generate OpenAPI specs for REST APIs.
+
+## Rules
+
+- Every endpoint must have input validation
+- Every endpoint must return consistent error format
+- Pagination is required for any list endpoint
+- Rate limiting must be documented per endpoint
+- Auth requirements must be explicit per endpoint
+- CORS must be configured explicitly, never wildcard in production
+
+## Verification
+
+1. Every endpoint responds with correct status codes
+2. Pagination works with edge cases
+3. Validation rejects bad input with descriptive errors
+4. Auth protected endpoints reject unauthenticated requests
+5. OpenAPI spec or equivalent documentation exists
+
+## Integration with Other Skills
+
+- **backend-development:** Handles implementation. This skill handles design.
+- **context7-docs:** Fetch framework docs before implementing endpoints

package/skills/builtin/api-exploit-prover/SKILL.md

@@ -0,0 +1,74 @@
+# API Exploit Prover
+
+## Purpose
+Convert API vulnerability leads into confirmed impact or cleanly disproven outcomes with reproducible evidence.
+
+## Inputs
+- `candidate_findings`
+- `target_base_url`
+- `auth_and_role_context`
+- `test_data_or_seed_objects`
+- `constraints` (noise limits, forbidden write actions)
+
+## Confidence Model
+- `C0`: hypothesis only
+- `C1`: suspicious signal
+- `C2`: reproducible behavior anomaly
+- `C3`: exploit primitive proven
+- `C4`: business impact proven
+
+## Execution Workflow
+### Phase 1: Reproduction Baseline
+1. Replay original request as control.
+2. Capture stable baseline across repeated requests.
+3. Validate request preconditions (auth, ownership, object existence).
+
+### Phase 2: Alternative Technique Check
+1. Re-test with a different method than original lead.
+2. Vary payload shape and transport encoding.
+3. Confirm behavior survives minor variance.
+
+### Phase 3: Impact Escalation
+1. Attempt controlled state change or unauthorized data access.
+2. Test cross-tenant and cross-role boundaries where legal.
+3. Validate whether impact persists after session/token refresh.
+
+### Phase 4: Confounder Elimination
+1. Rule out caching and stale object state.
+2. Rule out test-environment race artifacts.
+3. Rule out expected business behavior incorrectly interpreted as vulnerability.
+
+### Phase 5: Classification
+1. `confirmed` only when exploit and impact are replayable.
+2. `disputed` when mitigation or expected behavior is proven.
+3. `inconclusive` when blockers prevent decision.
+
+## Technique Rules by Vulnerability Type
+| Type | Rule |
+|---|---|
+| BOLA/BFLA | Must show unauthorized object or action with foreign identifier |
+| Injection | Must show parser/engine effect beyond literal handling |
+| Mass assignment | Must show unauthorized field control and persisted impact |
+| SSRF | Must prove outbound request/control over target or metadata access |
+| Rate abuse | Must show bypass of intended limit with practical impact |
+
+## Output Contract
+```json
+{
+  "confirmed_findings": [],
+  "disputed_findings": [],
+  "inconclusive_findings": [],
+  "evidence": [],
+  "confidence": []
+}
+```
+
+## Failure Modes
+- Single-shot confirmation without retest.
+- Treating error differences as exploit proof.
+- Claiming impact without business-context validation.
+
+## Quality Checklist
+- [ ] Every finding has final status and explicit reason.
+- [ ] Confirmed findings include replayable impact proof.
+- [ ] Inconclusive findings list unblockers.

package/skills/builtin/api-integration/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: api-integration
+description: "Use this skill when connecting to third-party APIs, handling OAuth, managing API keys, implementing pagination, or building service connectors. Triggers: 'integrate with', 'connect to', 'API client', 'OAuth', 'third-party', 'external service', or any request to consume an external API."
+license: MIT
+---
+
+# API Integration
+
+## What This Skill Does
+
+Connect to third-party APIs reliably. Authentication, pagination, rate limiting, error handling, retry logic, and type-safe API clients.
+
+## API Client Pattern
+
+```typescript
+class ApiClient {
+  constructor(
+    private baseUrl: string,
+    private apiKey: string,
+    private maxRetries = 3
+  ) {}
+
+  async request<T>(path: string, options: RequestInit = {}): Promise<T> {
+    const url = `${this.baseUrl}${path}`;
+    let lastError: Error | null = null;
+
+    for (let attempt = 0; attempt < this.maxRetries; attempt++) {
+      try {
+        const res = await fetch(url, {
+          ...options,
+          headers: {
+            "Authorization": `Bearer ${this.apiKey}`,
+            "Content-Type": "application/json",
+            ...options.headers,
+          },
+        });
+
+        if (res.status === 429) {
+          const retryAfter = parseInt(res.headers.get("retry-after") || "5");
+          await sleep(retryAfter * 1000);
+          continue;
+        }
+
+        if (!res.ok) throw new Error(`HTTP ${res.status}: ${await res.text()}`);
+        return await res.json() as T;
+      } catch (err) {
+        lastError = err as Error;
+        if (attempt < this.maxRetries - 1) await sleep(2 ** attempt * 1000);
+      }
+    }
+    throw lastError;
+  }
+}
+```
+
+## Auth Patterns
+
+| Method | Implementation |
+|--------|---------------|
+| API Key | Header: `Authorization: Bearer <key>` or `X-API-Key: <key>` |
+| OAuth 2.0 | Authorization code flow with PKCE for web, client credentials for server |
+| Basic Auth | Header: `Authorization: Basic <base64(user:pass)>` |
+| Webhook Signature | HMAC-SHA256 verification of request body |
+
+## Rules
+
+- Always implement retry with exponential backoff
+- Always respect rate limits (read headers: `X-RateLimit-Remaining`, `Retry-After`)
+- Never log API keys or tokens
+- Type all API responses (never use `any`)
+- Handle pagination (don't assume single-page responses)
+- Set reasonable timeouts (10-30 seconds)
+- Cache responses where appropriate (respect Cache-Control headers)

package/skills/builtin/api-security-tester/SKILL.md

@@ -0,0 +1,82 @@
+# API Security Tester
+
+## Purpose
+Run a complete API assessment cycle with strong evidence discipline and predictable output.
+
+## Inputs
+- `target_base_url`
+- `api_spec_or_collection`
+- `auth_context`
+- `engagement_rules`
+
+## Standard Test Order
+1. Discovery and endpoint normalization.
+2. Auth and authorization checks.
+3. Input handling and injection checks.
+4. Workflow and state-machine abuse checks.
+5. Impact confirmation and verification.
+
+## Execution Workflow
+### Phase 1: Discovery
+- Build endpoint and trust map.
+- Confirm content types, schema validation, and versioning.
+- Identify sensitive operations and privileged paths.
+
+### Phase 2: Access Control
+- Test object-level access control.
+- Test function-level authorization by role.
+- Test tenant boundary isolation.
+
+### Phase 3: Input Abuse
+- Injection candidates by sink class.
+- Mass assignment on create/update.
+- Filter/operator abuse on search APIs.
+
+### Phase 4: Workflow Abuse
+- Bypass prerequisite steps.
+- Replay or reorder transitions.
+- Abuse bulk and async operations.
+
+### Phase 5: Verification
+- Independently confirm positives.
+- Capture remediation-relevant root cause.
+- Downgrade or dispute weak findings.
+
+## Minimum Test Matrix
+| Category | Required Assertions |
+|---|---|
+| Authentication | unauthenticated access rejected consistently |
+| Authorization | foreign objects and privileged actions are blocked |
+| Input validation | malformed and malicious payloads handled safely |
+| Error handling | no internal leakage in error bodies |
+| State transitions | invalid transitions rejected |
+| Rate limiting | sensitive operations throttled |
+
+## Output Contract
+```json
+{
+  "scope_summary": {},
+  "test_log": [],
+  "confirmed_vulnerabilities": [],
+  "verification_notes": [],
+  "remediation_guidance": []
+}
+```
+
+## Constraints
+- Keep tests reproducible and proportional.
+- Do not overclaim severity without business impact.
+
+## Quality Checklist
+- [ ] Coverage includes auth, authz, input, workflow.
+- [ ] Findings include clear exploit path.
+- [ ] Remediation ties to code/control failure.
+
+## Conditional Decision Matrix
+| Condition | Action | Evidence Requirement |
+|---|---|---|
+| Endpoint undocumented but reachable | Add to inventory and prioritize authz checks | request/response baseline + auth behavior |
+| Auth behavior inconsistent across methods | Split tests by method and content type | per-method status + body signatures |
+| Time-based anomaly only | run matched control timing series | repeated control/test timing traces |
+| Object access differs by role | escalate to cross-tenant/cross-role checks | role-tagged replay proof |
+| Validation differs by parser | run semantic-equivalent content-type tests | parser-path differential evidence |

package/skills/builtin/api-test-executor/SKILL.md

@@ -0,0 +1,62 @@
+# API Test Executor
+
+## Purpose
+Run assigned API test cases exactly as scoped and return high-integrity evidence.
+
+## Inputs
+- `target_base_url`
+- `test_plan`
+- `auth_material`
+- `data_seeds`
+- `retry_policy`
+
+## Preflight
+- [ ] Test plan identifiers are unique.
+- [ ] Required accounts/tokens are valid.
+- [ ] Seed data exists and is not stale.
+- [ ] Retry policy is defined.
+
+## Execution Workflow
+### Phase 1: Case Preparation
+1. Resolve each case precondition.
+2. Attach correct role context.
+3. Build request template and expected baseline.
+
+### Phase 2: Deterministic Execution
+1. Run case with exact payload and headers.
+2. Capture full response metadata and body hash.
+3. Apply retries only under policy.
+
+### Phase 3: Outcome Classification
+1. `pass` when expected secure behavior observed.
+2. `fail` when expected secure behavior breaks.
+3. `blocked` when environment prevents valid execution.
+4. `inconclusive` when signal is unstable.
+
+### Phase 4: Evidence Packaging
+1. Store request/response artifacts.
+2. Map artifact to case ID.
+3. Add concise analyst note for anomalies.
+
+## Required Logging Fields
+- `case_id`, `timestamp_utc`, `role_context`, `request_signature`
+- `status_code`, `response_signature`, `verdict`
+
+## Output Contract
+```json
+{
+  "case_results": [],
+  "evidence_index": [],
+  "blocked_cases": [],
+  "environment_notes": []
+}
+```
+
+## Constraints
+- Do not expand scope.
+- Do not mutate payloads outside case definition.
+
+## Quality Checklist
+- [ ] Every case has terminal status.
+- [ ] Evidence references are complete.
+- [ ] Blockers include concrete unblock requests.

package/skills/builtin/app-store-optimization/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: app-store-optimization
+description: "Use this skill for App Store and Google Play optimization: metadata, keywords, screenshots, A/B testing, and review management. Triggers: 'ASO', 'app store', 'Google Play', 'app listing', 'app keywords', 'app screenshots', 'app ratings', or requests to improve app store presence."
+license: MIT
+---
+
+# App Store Optimization
+
+## What This Skill Does
+
+Optimize mobile app listings for discoverability and conversion. Keyword strategy, metadata, visual assets, and review management.
+
+## App Store Metadata
+
+### iOS App Store
+- App Name: 30 chars (include primary keyword)
+- Subtitle: 30 chars (secondary keyword)
+- Keywords: 100 chars (comma-separated, no spaces after commas)
+- Description: 4000 chars (first 3 lines visible before "more")
+- Promotional Text: 170 chars (can update without review)
+
+### Google Play
+- Title: 30 chars
+- Short Description: 80 chars
+- Full Description: 4000 chars (keyword-rich, formatted)
+
+## Keyword Strategy
+
+1. Research competitor keywords (use App Annie, Sensor Tower, or manual search)
+2. Target: high volume + low competition keywords
+3. Include in: title, subtitle/short description, keyword field
+4. Track rankings weekly and adjust quarterly
+
+## Visual Assets
+
+- Screenshots: show the app in action with value-proposition captions
+- First 2 screenshots are most important (visible before scrolling)
+- App preview video: 15-30 seconds showing core feature
+- Icon: simple, recognizable at small sizes, no text
+
+## Rules
+
+- Update keywords quarterly based on ranking data
+- Respond to all 1-2 star reviews within 48 hours
+- A/B test screenshots and descriptions (Google Play Experiments)
+- Localize listings for top markets (at minimum: English, Spanish, Portuguese, French, German, Japanese)

package/skills/builtin/audio-tour-guide/SKILL.md

@@ -0,0 +1,18 @@
+# Audio Tour Guide
+## Multi-Agent Pipeline
+1. **Architecture Agent**: describe buildings, design elements, urban planning (with web search for current info)
+2. **History Agent**: historical context, significant events, cultural evolution
+3. **Culture Agent**: local customs, food, art, community life
+
+Each agent produces conversational content within strict word limits (natural speech, no headings or formatting).
+
+## Voice Output Rules
+- Content must sound natural when spoken aloud
+- No markdown formatting, bullet points, or headings in the output
+- Spell out numbers: "one hundred and fifty" not "150"
+- No citations or links (spoken output)
+- Word count per segment: 100-200 words (45-90 seconds of speech)
+- Transitions between segments should flow naturally
+
+## Integration
+Uses Fenix voice pipeline: text → TTS → audio output. Each agent's output concatenated with smooth transitions.

package/skills/builtin/auth-flow-operator/SKILL.md

@@ -0,0 +1,70 @@
+# Auth Flow Operator
+
+## Purpose
+Securely obtain reliable authenticated context for downstream security testing.
+
+## Inputs
+- `target_url`
+- `known_credentials` (optional)
+- `auth_notes` (MFA, email verification, SSO, CAPTCHA)
+- `allowed_test_accounts` policy
+
+## Workflow
+### Phase 1: Route Discovery
+1. Identify login, registration, password reset, token refresh, logout paths.
+2. Determine auth mode: local creds, SSO, OTP, magic link, API token.
+
+### Phase 2: Login Path
+1. Attempt known credentials in defined order.
+2. Validate success via authenticated-only action, not UI guess.
+3. Record session artifacts and expiry behavior.
+
+### Phase 3: Registration Path
+1. Create dedicated test accounts when permitted.
+2. Capture verification dependencies.
+3. Validate role assignment and default permissions.
+
+### Phase 4: Session Lifecycle
+1. Test logout invalidation.
+2. Test token/cookie rotation after privilege change.
+3. Test concurrent session behavior.
+
+### Phase 5: Access Validation
+1. Confirm protected route gating.
+2. Confirm role-sensitive feature differences.
+3. Confirm cross-account isolation.
+
+## Anti-Patterns
+- Assuming logged-in state from UI text only.
+- Reusing stale tokens without validation.
+- Mixing account identities in one evidence stream.
+
+## Output Contract
+```json
+{
+  "working_auth_paths": [],
+  "accounts": [],
+  "session_lifecycle": [],
+  "role_validation": [],
+  "blockers": []
+}
+```
+
+## Constraints
+- No brute force.
+- Respect account-creation and cleanup rules.
+- Keep PII and credentials minimized in logs.
+
+## Quality Checklist
+- [ ] At least one stable auth path established.
+- [ ] Session behavior tested, not inferred.
+- [ ] Role boundaries verified with action-level checks.
+
+## Conditional Decision Matrix
+| Condition | Action | Evidence Requirement |
+|---|---|---|
+| Credentials succeed in UI but fail in API | validate token audience/session binding | endpoint-level auth proof |
+| Registration requires email verification | capture verification state transitions | account timeline with states |
+| MFA optional for some flows | compare protected action access with/without MFA | role/action differential |
+| Logout appears successful but token works | test token reuse after logout/reset | post-logout replay proof |
+| Role appears in UI only | validate backend authorization with privileged actions | server-side denial/allow traces |

package/skills/builtin/autonomous-rag/SKILL.md

@@ -0,0 +1,21 @@
+# Autonomous RAG
+## Pipeline
+1. **Ingest**: upload documents (PDF, text, web pages) → chunk → embed → store in vector DB
+2. **Query**: user asks question → embed query → search vector store
+3. **Evaluate**: are retrieved results sufficient to answer?
+4. **Fallback**: if insufficient, automatically search the web (DuckDuckGo, Tavily)
+5. **Generate**: answer from best available sources, citing whether from KB or web
+
+## Ingestion
+```typescript
+// PDF → chunks → embeddings → pgvector
+const chunks = splitDocument(pdfContent, { chunkSize: 500, overlap: 50 });
+const embeddings = await embed(chunks);
+await vectorStore.upsert(chunks.map((c, i) => ({ content: c, embedding: embeddings[i] })));
+```
+
+## Rules
+- Always try knowledge base first (user uploaded those docs for a reason)
+- Web fallback is transparent: "I didn't find this in your documents, but web search shows..."
+- Cite sources: [KB: document.pdf, page 3] or [Web: url]
+- Re-ingest documents when they change.