[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71N376R6RVB43EYCCHM4CVD":3,"skill-same:01M71N376R6RVB43EYCCHM4CVD":84},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":15,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":6,"updatedAt":64,"install":65,"resources":78},"01M71N376R6RVB43EYCCHM4CVD","healthcare-phi-compliance",null,"Use when code touches patient PHI or PII in a healthcare system: data classification, Postgres row-level security, tamper-proof audit trails and leak vectors. Applies to HIPAA, GDPR and DISHA; covers error messages, logs and URLs as common leak paths.","monoes\u002Fmonomind","monoes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F276744696?v=4","01M71KWF37AJ2NJBP3KWBVSDGT","01M71KWF4CSF8ADH0M6HA09VD2",23,"MIT","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fhealthcare-phi-compliance\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fhealthcare-phi-compliance\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"phi","compliance","healthcare phi compliance","healthcare","proof audit","error messages","as","security","data","paths","audit","common","logs","code","when","patient","messages","pii","postgres","error","2026-11-10 10:56:23",false,"---\nname: healthcare-phi-compliance\ndescription: \"Use when code touches patient PHI or PII in a healthcare system: data classification, Postgres row-level security, tamper-proof audit trails and leak vectors. Applies to HIPAA, GDPR and DISHA; covers error messages, logs and URLs as common leak paths.\"\ntags: [\"legal\",\"security\",\"engineering\",\"compliance\",\"postgres\"]\ntools: []\nlicense: MIT\nsource: https:\u002F\u002Fgithub.com\u002Faffaan-m\u002FECC\nsource_path: \"skills\u002Fhealthcare-phi-compliance\"\nsource_commit: bf70150eb2df8070024e5bdf08e4aa08959e2735\n---\n# Healthcare PHI\u002FPII Compliance Patterns\n\nPatterns for protecting patient data, clinician data, and financial data in healthcare applications. Applicable to HIPAA (US), DISHA (India), GDPR (EU), and general healthcare data protection.\n\n## When to Use\n\n- Building any feature that touches patient records\n- Implementing access control or authentication for clinical systems\n- Designing database schemas for healthcare data\n- Building APIs that return patient or clinician data\n- Implementing audit trails or logging\n- Reviewing code for data exposure vulnerabilities\n- Setting up Row-Level Security (RLS) for multi-tenant healthcare systems\n\n## How It Works\n\nHealthcare data protection operates on three layers: **classification** (what is sensitive), **access control** (who can see it), and **audit** (who did see it).\n\n### Data Classification\n\n**PHI (Protected Health Information)** — any data that can identify a patient AND relates to their health: patient name, date of birth, address, phone, email, national ID numbers (SSN, Aadhaar, NHS number), medical record numbers, diagnoses, medications, lab results, imaging, insurance policy and claim details, appointment and admission records, or any combination of the above.\n\n**PII (Non-patient-sensitive data)** in healthcare systems: clinician\u002Fstaff personal details, doctor fee structures and payout amounts, employee salary and bank details, vendor payment information.\n\n### Access Control: Row-Level Security\n\n```sql\nALTER TABLE patients ENABLE ROW LEVEL SECURITY;\n\n-- Scope access by facility\nCREATE POLICY \"staff_read_own_facility\"\n  ON patients FOR SELECT TO authenticated\n  USING (facility_id IN (\n    SELECT facility_id FROM staff_assignments\n    WHERE user_id = auth.uid() AND role IN ('doctor','nurse','lab_tech','admin')\n  ));\n\n-- Audit log: insert-only (tamper-proof)\nCREATE POLICY \"audit_insert_only\" ON audit_log FOR INSERT\n  TO authenticated WITH CHECK (user_id = auth.uid());\nCREATE POLICY \"audit_no_modify\" ON audit_log FOR UPDATE USING (false);\nCREATE POLICY \"audit_no_delete\" ON audit_log FOR DELETE USING (false);\n```\n\n### Audit Trail\n\nEvery PHI access or modification must be logged:\n\n```typescript\ninterface AuditEntry {\n  timestamp: string;\n  user_id: string;\n  patient_id: string;\n  action: 'create' | 'read' | 'update' | 'delete' | 'print' | 'export';\n  resource_type: string;\n  resource_id: string;\n  changes?: { before: object; after: object };\n  ip_address: string;\n  session_id: string;\n}\n```\n\n### Common Leak Vectors\n\n**Error messages:** Never include patient-identifying data in error messages thrown to the client. Log details server-side only.\n\n**Console output:** Never log full patient objects. Use opaque internal record IDs (UUIDs) — not medical record numbers, national IDs, or names.\n\n**URL parameters:** Never put patient-identifying data in query strings or path segments that could appear in logs or browser history. Use opaque UUIDs only.\n\n**Browser storage:** Never store PHI in localStorage or sessionStorage. Keep PHI in memory only, fetch on demand.\n\n**Service role keys:** Never use the service_role key in client-side code. Always use the anon\u002Fpublishable key and let RLS enforce access.\n\n**Logs and monitoring:** Never log full patient records. Use opaque record IDs only (not medical record numbers). Sanitize stack traces before sending to error tracking services.\n\n### Database Schema Tagging\n\nMark PHI\u002FPII columns at the schema level:\n\n```sql\nCOMMENT ON COLUMN patients.name IS 'PHI: patient_name';\nCOMMENT ON COLUMN patients.dob IS 'PHI: date_of_birth';\nCOMMENT ON COLUMN patients.aadhaar IS 'PHI: national_id';\nCOMMENT ON COLUMN doctor_payouts.amount IS 'PII: financial';\n```\n\n### Deployment Checklist\n\nBefore every deployment:\n- No PHI in error messages or stack traces\n- No PHI in console.log\u002Fconsole.error\n- No PHI in URL parameters\n- No PHI in browser storage\n- No service_role key in client code\n- RLS enabled on all PHI\u002FPII tables\n- Audit trail for all data modifications\n- Session timeout configured\n- API authentication on all PHI endpoints\n- Cross-facility data isolation verified\n\n## Examples\n\n### Example 1: Safe vs Unsafe Error Handling\n\n```typescript\n\u002F\u002F BAD — leaks PHI in error\nthrow new Error(`Patient ${patient.name} not found in ${patient.facility}`);\n\n\u002F\u002F GOOD — generic error, details logged server-side with opaque IDs only\nlogger.error('Patient lookup failed', { recordId: patient.id, facilityId });\nthrow new Error('Record not found');\n```\n\n### Example 2: RLS Policy for Multi-Facility Isolation\n\n```sql\n-- Doctor at Facility A cannot see Facility B patients\nCREATE POLICY \"facility_isolation\"\n  ON patients FOR SELECT TO authenticated\n  USING (facility_id IN (\n    SELECT facility_id FROM staff_assignments WHERE user_id = auth.uid()\n  ));\n\n-- Test: login as doctor-facility-a, query facility-b patients\n-- Expected: 0 rows returned\n```\n\n### Example 3: Safe Logging\n\n```typescript\n\u002F\u002F BAD — logs identifiable patient data\nconsole.log('Processing patient:', patient);\n\n\u002F\u002F GOOD — logs only opaque internal record ID\nconsole.log('Processing record:', patient.id);\n\u002F\u002F Note: even patient.id should be an opaque UUID, not a medical record number\n```\n","# Healthcare PHI\u002FPII Compliance Patterns\n\nPatterns for protecting patient data, clinician data, and financial data in healthcare applications. Applicable to HIPAA (US), DISHA (India), GDPR (EU), and general healthcare data protection.\n\n## When to Use\n\n- Building any feature that touches patient records\n- Implementing access control or authentication for clinical systems\n- Designing database schemas for healthcare data\n- Building APIs that return patient or clinician data\n- Implementing audit trails or logging\n- Reviewing code for data exposure vulnerabilities\n- Setting up Row-Level Security (RLS) for multi-tenant healthcare systems\n\n## How It Works\n\nHealthcare data protection operates on three layers: **classification** (what is sensitive), **access control** (who can see it), and **audit** (who did see it).\n\n### Data Classification\n\n**PHI (Protected Health Information)** — any data that can identify a patient AND relates to their health: patient name, date of birth, address, phone, email, national ID numbers (SSN, Aadhaar, NHS number), medical record numbers, diagnoses, medications, lab results, imaging, insurance policy and claim details, appointment and admission records, or any combination of the above.\n\n**PII (Non-patient-sensitive data)** in healthcare systems: clinician\u002Fstaff personal details, doctor fee structures and payout amounts, employee salary and bank details, vendor payment information.\n\n### Access Control: Row-Level Security\n\n```sql\nALTER TABLE patients ENABLE ROW LEVEL SECURITY;\n\n-- Scope access by facility\nCREATE POLICY \"staff_read_own_facility\"\n  ON patients FOR SELECT TO authenticated\n  USING (facility_id IN (\n    SELECT facility_id FROM staff_assignments\n    WHERE user_id = auth.uid() AND role IN ('doctor','nurse','lab_tech','admin')\n  ));\n\n-- Audit log: insert-only (tamper-proof)\nCREATE POLICY \"audit_insert_only\" ON audit_log FOR INSERT\n  TO authenticated WITH CHECK (user_id = auth.uid());\nCREATE POLICY \"audit_no_modify\" ON audit_log FOR UPDATE USING (false);\nCREATE POLICY \"audit_no_delete\" ON audit_log FOR DELETE USING (false);\n```\n\n### Audit Trail\n\nEvery PHI access or modification must be logged:\n\n```typescript\ninterface AuditEntry {\n  timestamp: string;\n  user_id: string;\n  patient_id: string;\n  action: 'create' | 'read' | 'update' | 'delete' | 'print' | 'export';\n  resource_type: string;\n  resource_id: string;\n  changes?: { before: object; after: object };\n  ip_address: string;\n  session_id: string;\n}\n```\n\n### Common Leak Vectors\n\n**Error messages:** Never include patient-identifying data in error messages thrown to the client. Log details server-side only.\n\n**Console output:** Never log full patient objects. Use opaque internal record IDs (UUIDs) — not medical record numbers, national IDs, or names.\n\n**URL parameters:** Never put patient-identifying data in query strings or path segments that could appear in logs or browser history. Use opaque UUIDs only.\n\n**Browser storage:** Never store PHI in localStorage or sessionStorage. Keep PHI in memory only, fetch on demand.\n\n**Service role keys:** Never use the service_role key in client-side code. Always use the anon\u002Fpublishable key and let RLS enforce access.\n\n**Logs and monitoring:** Never log full patient records. Use opaque record IDs only (not medical record numbers). Sanitize stack traces before sending to error tracking services.\n\n### Database Schema Tagging\n\nMark PHI\u002FPII columns at the schema level:\n\n```sql\nCOMMENT ON COLUMN patients.name IS 'PHI: patient_name';\nCOMMENT ON COLUMN patients.dob IS 'PHI: date_of_birth';\nCOMMENT ON COLUMN patients.aadhaar IS 'PHI: national_id';\nCOMMENT ON COLUMN doctor_payouts.amount IS 'PII: financial';\n```\n\n### Deployment Checklist\n\nBefore every deployment:\n- No PHI in error messages or stack traces\n- No PHI in console.log\u002Fconsole.error\n- No PHI in URL parameters\n- No PHI in browser storage\n- No service_role key in client code\n- RLS enabled on all PHI\u002FPII tables\n- Audit trail for all data modifications\n- Session timeout configured\n- API authentication on all PHI endpoints\n- Cross-facility data isolation verified\n\n## Examples\n\n### Example 1: Safe vs Unsafe Error Handling\n\n```typescript\n\u002F\u002F BAD — leaks PHI in error\nthrow new Error(`Patient ${patient.name} not found in ${patient.facility}`);\n\n\u002F\u002F GOOD — generic error, details logged server-side with opaque IDs only\nlogger.error('Patient lookup failed', { recordId: patient.id, facilityId });\nthrow new Error('Record not found');\n```\n\n### Example 2: RLS Policy for Multi-Facility Isolation\n\n```sql\n-- Doctor at Facility A cannot see Facility B patients\nCREATE POLICY \"facility_isolation\"\n  ON patients FOR SELECT TO authenticated\n  USING (facility_id IN (\n    SELECT facility_id FROM staff_assignments WHERE user_id = auth.uid()\n  ));\n\n-- Test: login as doctor-facility-a, query facility-b patients\n-- Expected: 0 rows returned\n```\n\n### Example 3: Safe Logging\n\n```typescript\n\u002F\u002F BAD — logs identifiable patient data\nconsole.log('Processing patient:', patient);\n\n\u002F\u002F GOOD — logs only opaque internal record ID\nconsole.log('Processing record:', patient.id);\n\u002F\u002F Note: even patient.id should be an opaque UUID, not a medical record number\n```\n",{"name":5,"tags":49,"tools":52,"source":53,"license":14,"description":7,"source_path":54,"source_commit":55},[50,31,51,25,42],"legal","engineering",[],"https:\u002F\u002Fgithub.com\u002Faffaan-m\u002FECC","skills\u002Fhealthcare-phi-compliance","bf70150eb2df8070024e5bdf08e4aa08959e2735","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fhealthcare-phi-compliance",2,"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","https:\u002F\u002Fmonoes.github.io\u002Fmonomind\u002F","https:\u002F\u002Fgithub.com\u002Fmonoes","https:\u002F\u002Fmonoes.me","2026-11-14 03:30:52",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add monoes\u002Fmonomind --skill healthcare-phi-compliance",{"tool":71,"command":72},"bunx","bunx skills add monoes\u002Fmonomind --skill healthcare-phi-compliance",{"tool":74,"command":75},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill healthcare-phi-compliance","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fhealthcare-phi-compliance\u002FSKILL.md",true,[79],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":15},"LICENSE.txt","LICENSE","许可证",1071,[85,113,144,171,194,221],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":89,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":112},"01M71PB3SHWKMNJM6MD65VX8D6","zk-steward","Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward\u002FSKILL.md",[],[93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,31,110,111],"zk","zk steward","steward","zero-knowledge","engineer","choice","design","knowledge","impact","query","snark","review","monomind","security review","stark","zettelkasten","cryptography","org","blockchain","2026-11-10 13:02:02",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":117,"sourceHtmlUrl":118,"categories":119,"keywords":128,"publishedAt":112},"01M71PB18SDG28WBKPKJNB814K","writing-plans","Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FSKILL.md",[120,125],{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[129,130,131,97,132,133,38,134,102,37,135,136,137,138,139,33,140,141,142,143],"writing","writing plans","plans","superpowers","implementation plan","you","tasks","plan","product","write","commands","suggest","coding","context","ZeRO",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":89,"licenseFileUrl":148,"sourceHtmlUrl":149,"categories":150,"keywords":154,"publishedAt":112},"01M71PAXFM488X9ARXK0T04TF5","write-spec","Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FSKILL.md",[151],{"categoryNo":152,"categoryName":153,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理",[138,155,156,157,158,100,159,38,160,161,162,137,163,164,165,166,167,168,169,170],"write spec","spec","user request","problem","acceptance","ask","vague","work","request","scoping","idea","metrics","feature","problem statement","use","document",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":89,"licenseFileUrl":175,"sourceHtmlUrl":176,"categories":177,"keywords":181,"publishedAt":112},"01M71PASSZY800C0RPEARBS918","write-query","Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FSKILL.md",[178],{"categoryNo":179,"categoryName":180,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师",[102,138,182,42,183,184,100,169,38,185,186,187,188,162,189,190,191,192,193,32],"write query","for","snowflake","best practices","natural-language","with","multi","github","sql","https","syntax","plugins",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":89,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":206,"publishedAt":112},"01M71PAPTX0T3PF6ETFVR96SJJ","workflow-automation","Org role guidance for workflow automation: build and maintain CI\u002FCD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-automation\u002FSKILL.md",[200,203],{"categoryNo":201,"categoryName":202,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":204,"categoryName":205,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000023","Skill与智能体开发",[207,208,209,210,183,211,212,213,214,101,215,216,217,102,105,189,218,219,220,191],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":222,"name":223,"nameZh":6,"description":224,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":89,"licenseFileUrl":6,"sourceHtmlUrl":225,"categories":226,"keywords":228,"publishedAt":112},"01M71PAM19Z1XTV9NPCFSE2MY8","workflow-architect","Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-architect\u002FSKILL.md",[227],{"categoryNo":204,"categoryName":205,"taxonomyType":123,"taxonomyTypeDesc":124},[209,229,230,231,232,233,234,183,235,236,37,237,238,239,105,189,240,241,191,242],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","operations","systems"]