iconsa-business-rules

Enforces 27 HumanOS business rules before writing migrations, RLS policies, and approval logic.

Updated May 7, 2026
One-click install
npx skills add https://github.com/jecg2804/HumanOS --skill iconsa-business-rules-jecg2804
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: iconsa-business-rules
Source: https://github.com/jecg2804/HumanOS/tree/main/.claude/skills/iconsa-business-rules
Command: npx skills add https://github.com/jecg2804/HumanOS --skill iconsa-business-rules-jecg2804

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Developers working on the HumanOS HR platform risk violating critical business rules (R1-R27) when writing database migrations, RLS policies, approval chains, or auth.users operations, which can cause data loss, broken approval flows, or security exposure of sensitive employee documents. ## Core Features & Use Cases - Blocking-rule checklist: Flags immediately blocking violations such as writing to prohibited schemas (public., humanos.), self-approval, exposing restricted medical documents, and unfiltered destructive operations on auth.users. - Approval chain guidance: Details ticket status transitions, approval JSONB structure, SOP-driven chain fidelity rulings (ADR-0027), stamp formats, and back-and-forth modification flows. - Use Case: Before writing a migration that adds an approval step for a PRESTAMO ticket, consult this Skill to confirm the full chain (supervisor + hr_admin + president) applies with no threshold logic, and that the stamp format and request_number generation follow R7 and R17. ## Quick Start Ask the agent to review your planned migration or approval logic against the ICONSA business rules before writing any SQL touching the HumanOS database.

Frequently Asked Questions about iconsa-business-rules

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement approval logic for HumanOS tickets?▼

Approval logic must follow the JSONB structure in R24 with modes parallel, direct_hr_admin, any_of_hr, or parent_only, and enforce that approver_id differs from requester_id in code, not as a database constraint. SOP-defined chains must not be deviated from without approval.

What database schemas are allowed in HumanOS Supabase migrations?▼

Allowed schemas include hr, requests, docs, workflows, audit, notifications, files, performance, learning, payroll, core, and several others. Writing to public.* or recreating the dropped humanos.* schema is strictly prohibited and blocked by a PreToolUse hook.

Can I run DELETE or mass UPDATE on auth.users in Supabase?▼

Destructive operations on auth.users require filtering by raw_app_meta_data->'allowed_apps' in SQL or app_metadata->'allowed_apps' in JS and RLS. A snapshot to backup.auth_users_YYYYMMDD is required first, after an incident erased 47 users.

What ticket status values does HumanOS support?▼

Exactly eight values are allowed in the CHECK constraint: Borrador, Enviada, En_Revision, Aprobada, Rechazada, Devuelta_Modificacion, Completada, and Cancelada. No other status values may be introduced.

Why is there no supervisor role in the HumanOS app_role enum?▼

HumanOS uses a single user concept where app_role is limited to employee, hr_admin, president, and admin. Being a supervisor is contextual, determined by hr.employments.supervisor_id or requests.tickets.selected_supervisor_id, not a separate account type.

When should I not apply threshold logic to PRESTAMO requests?▼

Never. The $250 figure is an operational cap, not an escalation threshold, so all loans go through the full approval chain of supervisor, hr_admin, and president. ChainResolver must contain no threshold logic.