Full Islamic Finance Agent: SKILL.md Library Build
In Lesson 17, you applied established accounting frameworks to fintech structures that the standards did not anticipate. Now you step back and look at the complete system. Over the preceding seventeen lessons, you have worked through every major Islamic finance product, explored jurisdiction-specific variations across thirteen countries, navigated cross-border consolidation, and reasoned through emerging fintech structures. This final lesson deploys the complete infrastructure.
This is the agent-building capstone. You will audit the full 25-file SKILL.md library, build and verify the global routing skill, apply both Knowledge Extraction methods, deploy the scheduled task architecture, validate the system with a multi-jurisdiction test suite, and produce the agent capability statement that defines the boundary between what the agent executes and what the Shariah Supervisory Board judges.
The Complete Library Architecture
The Islamic finance SKILL.md library has three layers:
Layer 1: Global Router
islamic-finance-global-router.md
↓ Routes to appropriate product + jurisdiction
Layer 2: Product Skills (12 files)
products/
murabaha.md ijarah-imb.md musharaka-dm.md
mudaraba.md musharaka-full.md sukuk-issuer.md
sukuk-investor.md salam.md istisna-a.md
takaful-ifrs17.md zakat-global.md shariah-screening-global.md
Layer 3: Jurisdiction Overlays (13 files)
jurisdictions/
bahrain-aaoifi.md qatar-aaoifi.md malaysia-mfrs.md
indonesia-psak.md saudi-ifrs.md uae-ifrs.md
kuwait-ifrs.md oman-ifrs.md pakistan-ifrs.md
uk-ifrs.md nigeria-ifrs.md turkey-tfrs.md
gcc-crossborder.md
The routing logic follows a strict protocol: (1) identify jurisdiction, (2) identify product, (3) load product skill, (4) load jurisdiction overlay, (5) apply product rules first, then overlay modifications. If jurisdiction is not specified, the agent must ask before proceeding.
Plugin: Islamic Finance Domain Agents (install once: see Lesson 3)
Exercise 15: Full SKILL.md Library Build (90 min)
Step 1: Review the Installed Plugin's Skills Library
Open Cowork's Skills panel and review the installed Islamic finance plugin's skill library. For each of the 25 skills (12 products + 13 jurisdictions), verify:
Review the Islamic finance plugin's installed skills in Cowork.
For each skill, confirm:
(1) The skill is listed and active in the Skills panel
(2) It specifies the governing standard (AAOIFI FAS number or
IFRS standard)
(3) It includes the key accounting instructions (recognition,
measurement, presentation, disclosure)
(4) It includes the "NEVER" rules — what the agent must never do
in this context (e.g., "NEVER use interest income" for any
product, "NEVER use Loans and Advances" for AAOIFI jurisdictions)
(5) It includes the SSB escalation triggers — what questions must
be escalated to the Shariah Supervisory Board
Report any gaps or incomplete skills.
Step 2: Create the Global Routing Skill
The routing skill is the control layer that ensures the correct product and jurisdiction skills are loaded. Create it using Write skill instructions in Cowork's Skills panel:
- Skill name:
islamic-finance-global-router - Description: Activate whenever any Islamic finance term appears in a query: murabaha, ijarah, musharaka, mudaraba, sukuk, takaful, zakat, AAOIFI, FAS, Shariah-compliant, Islamic banking, non-interest banking, halal finance, riba, gharar. Before any output: identify jurisdiction and product, then load the appropriate product skill and jurisdiction overlay skill.
- Instructions: Enter the routing rules:
- Step 1: Identify jurisdiction from query context. If no jurisdiction specified: ask the user before proceeding. NEVER assume IFRS without confirming jurisdiction. AAOIFI jurisdictions (mandatory): Bahrain, Qatar, Sudan. MFRS jurisdictions: Malaysia. IFRS jurisdictions: UAE, Saudi Arabia, Kuwait, Oman, UK, Nigeria, Kenya, South Africa, Turkey.
- Step 2: Identify product from query context. Load the corresponding product skill.
- Step 3: Load the jurisdiction overlay skill.
- Step 4: Apply product rules first, then jurisdiction overlay.
- Step 5: Before generating any journal entry or financial statement: confirm the governing standard in the response header, label income consistently with jurisdiction requirements, NEVER use "interest income" in any Islamic finance context, NEVER use "loans and advances" in AAOIFI regime outputs.
Click Create.
Verify the routing logic handles edge cases: what happens when a query mentions two jurisdictions (consolidation)? When a product is not in the library (new fintech structure)? When the jurisdiction uses a local standard not in the library (Iran, Bangladesh)?
Step 3: Find a Gap in the Installed Library
The installed plugin covers 13 jurisdictions. Your task: identify a jurisdiction that is NOT in the library but has an active Islamic finance market.
Choose one of: Jordan, Iran, Sudan, Bangladesh, Brunei, Morocco, or another country with Islamic banking regulation. Research its regulatory framework and determine:
- Which regime does it fall under? (AAOIFI mandatory, IFRS with Islamic guidance, or local standard)
- What regulator oversees Islamic banking?
- What specific labelling requirements exist?
- What would the router need to know to route queries for this jurisdiction?
If you choose a jurisdiction from the AAOIFI mandatory group (Sudan, Jordan), compare its requirements against the existing Bahrain overlay: what is shared and what is jurisdiction-specific?
Step 4: Build the Extension: New Jurisdiction Overlay
Build a new jurisdiction overlay skill for the jurisdiction you identified in Step 3. Use one of two approaches:
Option A: Create with Claude: Open Cowork's Skills panel, select Create with Claude, and tell Cowork: "Help me build a jurisdiction overlay skill for [JURISDICTION]. Here are the key regulatory requirements: [PASTE KEY REQUIREMENTS from the regulator's website or published framework]. The skill should cover: primary accounting framework, AAOIFI role, accounting treatment differences from default IFRS, required Shariah disclosures, regulatory-specific requirements, NEVER rules, and SSB escalation triggers." Review Claude's draft, refine, and save.
Option B: Upload a skill: If the companion repository includes a reference overlay for your chosen jurisdiction, use Upload a skill in the Skills panel to import it, then customise the instructions for any jurisdiction-specific requirements you identified in Step 3.
Compare the resulting skill's structure against the existing Bahrain or Malaysia overlay from the installed plugin: does it follow the same format? Does it contain the same section headings?
Step 5: Test Your Extension
Test your new jurisdiction overlay by running 3 queries against it:
- Murabaha query: Does the routing logic correctly identify your new jurisdiction and apply the right labels?
- Sukuk investor query: Does the classification match your jurisdiction's adopted framework?
- Zakat query: Does the zakat treatment follow the local regulatory approach?
If any query produces incorrect output, identify whether the gap is in the product skill (unlikely: these are universal) or in your jurisdiction overlay (the labels, disclosure references, or regulatory requirements you specified). Fix the overlay and re-test.
Also verify the scheduled task architecture would work for your jurisdiction. Configure these operational tasks using Cowork's /schedule feature. Each task runs automatically at the specified frequency: the router loads the correct skills and jurisdiction overlays.
| Frequency | Task | What It Does |
|---|---|---|
| Daily | Murabaha profit recognition | Calculates and records daily profit accrual on all active murabaha facilities |
| Daily | Ijarah rental recognition | Records daily rental income on operating ijarah portfolio |
| Daily | Sukuk income accrual | Accrues daily income on sukuk investment portfolio |
| Monthly | Profit pool distribution | Calculates IAH profit-sharing pool and distributes to mudaraba account holders |
| Monthly | Zakat monitoring | Tracks minimum balance positions against zakat nisab thresholds |
| Monthly | Shariah income check | Calculates non-Shariah-compliant income as percentage of total: flags if above threshold |
| Quarterly | Shariah portfolio screen | Re-screens investment portfolio against adopted Shariah methodology |
| Quarterly | SSB quarterly report | Produces quarterly Shariah compliance report for SSB review |
| Annual | AAOIFI-IFRS reconciliation | For groups with both AAOIFI and IFRS entities: produces full reconciliation |
To configure the daily murabaha profit recognition task in Cowork:
Set up a daily scheduled task: Murabaha Profit Recognition
Frequency: Every business day at 17:00
Action: Calculate and record daily profit accrual on all active
murabaha facilities using the murabaha skill.
For each facility:
- Extract: facility ID, cost price, selling price, total deferred
profit, tenure, outstanding receivable, ECL stage, jurisdiction
- AAOIFI jurisdictions (Bahrain, Qatar): apply proportional
allocation — monthly income = (total deferred profit / total
instalments) × instalments due. Label: "Murabaha Income"
- MFRS jurisdictions (Malaysia): apply effective profit rate
method. Label: "Profit from Islamic Financing"
- IFRS jurisdictions (UAE, Saudi, UK, others): apply effective
profit rate method. Label: "Income from Islamic Financing"
- Stage 3 facilities: suspend accrual recognition, reverse any
accrued income not yet received in cash
- Generate journal entries per facility with jurisdiction-compliant
labels — NEVER use "interest income" in any jurisdiction
Output: Daily accrual journal entries with governing framework
header, deferred income movement schedule, and non-performing
facility report.
Escalation: If any facility has unrecognised profit > 5 days, flag
for Operations review. If any Stage 1 facility transitions
directly to Stage 3, notify Head of Islamic Finance immediately.
For the monthly Shariah income check, the task chains screening with escalation:
Set up a monthly scheduled task: Non-Shariah Income Monitoring
Frequency: Last business day of each month
Action:
Step 1 — Extract all income lines from the general ledger for
the period using the shariah-screening-global skill
Step 2 — Classify each income line as Shariah-compliant or
non-Shariah-compliant (conventional interest received on
nostro balances, penalty income, late-payment charges)
Step 3 — Calculate non-Shariah-compliant income as a percentage
of total income
Step 4 — Compare against the institution's adopted threshold:
- SC Malaysia methodology: 5% of total revenue
- AAOIFI Governance Standard 21: per SSB resolution
- Fund-level: per prospectus or offering circular
Step 5 — For any non-Shariah income identified, draft the
purification entry: Dr Retained Earnings (or Charity Payable),
Cr Non-Shariah Income Suspense
Output: Monthly Shariah income purity report with percentage,
breakdown by category, purification journal entries, and
trend chart (rolling 12 months).
Escalation: If non-Shariah income exceeds the adopted threshold,
escalate to SSB chair immediately with full breakdown and
recommended purification action.
For the annual zakat computation, the task spans multiple jurisdictions with different methodologies:
Set up an annual scheduled task: Institutional Zakat Computation
Frequency: Aligned with fiscal year-end (or 1st Ramadan for
Pakistan entities)
Action:
Step 1 — Determine applicable methodology per jurisdiction
using the zakat-global skill:
- Saudi Arabia: ZATCA balance sheet formula (mandatory)
- Pakistan: Zakat & Ushr Ordinance 1980 (deduction at source)
- Malaysia: Hanafi net zakatable assets (voluntary, SSB-approved)
- UK/UAE/Bahrain: per Shariah board adopted method (voluntary)
Step 2 — Extract financial data from audited statements:
- Saudi: share capital, reserves, retained earnings, provisions,
less fixed assets and long-term investments → net ZATCA base
- Pakistan: eligible deposit balances as of 1st Ramadan,
less exemption certificates → net deposits subject to zakat
- Malaysia/UK: cash, financing receivables, sukuk investments,
liquid trade assets, less current liabilities → net zakatable
wealth, then nisab check
Step 3 — Calculate zakat at 2.5% of net base per jurisdiction
Step 4 — Generate journal entries:
- Saudi: Dr Zakat Expense (P&L), Cr Zakat Payable — ZATCA
- Pakistan: Dr Customer Deposits, Cr Zakat Collected — CZF
- Malaysia: Dr Retained Earnings (appropriation), Cr Zakat
Payable — NOT a P&L expense
- UK: footnote disclosure only (most common) or expense per
SSB resolution
Step 5 — Draft jurisdiction-specific disclosure notes and
prepare filing where required (ZATCA portal, SBP reporting)
Output: Zakat computation workbook per jurisdiction, journal
entries, disclosure note drafts, and filing-ready returns.
Escalation: If ZATCA zakat base differs > 5% from prior year,
flag for tax manager review before filing. If any jurisdiction's
zakat methodology requires SSB re-approval, escalate to SSB
chair before computation.
Step 6: Multi-Jurisdiction Test Suite
Run 13 test queries (one per jurisdiction) confirming the routing logic correctly loads the right overlay for each. Each query should be a simple murabaha income recognition question, and you verify three things in the output:
| # | Test Query Jurisdiction | Verify Framework | Verify Income Label | Verify Key Disclosure |
|---|---|---|---|---|
| 1 | Bahrain | AAOIFI FAS 2 | "Murabaha Income" | AAOIFI FAS 2 disclosure notes |
| 2 | Qatar | AAOIFI FAS 2 | "Murabaha Income" | QCB regulatory note |
| 3 | Malaysia | MFRS 9 | "Profit from Islamic Financing" | MASB Islamic guidance reference |
| 4 | Indonesia | PSAK | "Pendapatan Murabahah" or local equivalent | OJK regulatory note |
| 5 | Saudi Arabia | IFRS as adopted KSA | "Murabaha Income" (convention) | ZATCA zakat reference |
| 6 | UAE | IFRS | "Financing Income" | CBUAE regulatory note |
| 7 | Kuwait | IFRS | "Financing Income" | CBK framework reference |
| 8 | Oman | IFRS | "Financing Income" | AAOIFI Shariah compliance note |
| 9 | Pakistan | IFRS + SBP | "Income from Islamic Financing" | SBP SGF reference |
| 10 | UK | IFRS | "Profit from Home Finance" | HMRC tax equivalence note |
| 11 | Nigeria | IFRS | "Non-Interest Income" | CBN NIBF reference |
| 12 | Turkey | TFRS | "Katilim Hesabi Geliri" or local equivalent | BDDK participation banking note |
| 13 | GCC Cross-Border | IFRS consolidated | Uniform group labelling | Dual-framework policy note |
A test failure in any jurisdiction means the routing logic or the overlay file has a gap that must be fixed before deployment.
Step 7: Document the Agent Capability Statement
Produce a one-page capability statement suitable for client engagements. The statement should cover:
- The products and jurisdictions the agent handles
- The routing architecture that ensures correct framework application
- The scheduled tasks that automate recurring accounting workflows
- The quality controls (test suite, SSB escalation triggers, NEVER rules)
The final paragraph must define the boundary:
"This agent automates the mechanical accounting, schedule generation, disclosure drafting, and regulatory reporting workflows across 13 Islamic finance jurisdictions. It does not make Shariah compliance judgments. The question of whether a specific transaction structure is Shariah-permissible, whether a borderline equity screening case passes or fails the fund's adopted methodology, or whether a new product innovation complies with the relevant fatwa: these are judgments for qualified Shariah scholars on the institution's Shariah Supervisory Board. The agent's role is to execute, flag, escalate, and document. The SSB's role is to judge."
Five Key Insights From Chapter 31
These five structural insights from this chapter deserve to be carried forward into every future engagement:
One: The accounting numbers are often identical across frameworks; the labels and disclosures differ. A murabaha schedule under AAOIFI FAS 2 and under IFRS 9 produces the same amortisation figures. The difference is in what those figures are called, how they are presented, and what supplementary disclosures are required. An AI agent that gets the calculation right but the labels wrong produces a compliance error.
Two: The IFRS/AAOIFI convergence project is unfinished. AAOIFI is reviewing its standards to remove deviations that do not conflict with IFRS. Despite these efforts, significant differences remain. The practitioner working today must navigate the current divergence, not the eventual convergence.
Three: Sukuk accounting has one unresolved structural risk. Draft AAOIFI Standard 62's proposed shift from asset-based to asset-backed sukuk would, if adopted, require restructuring of a significant portion of the global sukuk market. Any practitioner advising on sukuk in 2025-2027 must assess the Standard 62 risk as a material contingent event.
Four: Islamic fintech is creating accounting questions the standards have not answered. Digital murabaha, P2P Islamic lending, impact sukuk through mobile apps: these structures are scaling faster than the standard-setters can respond. The CA/CPA who develops well-reasoned technical positions now will be the sought-after adviser as the sector grows.
Five: The agent executes; the SSB judges. No SKILL.md file and no AI agent can determine whether a specific transaction structure is Shariah-permissible. Shariah compliance is a scholarly function, not an accounting function. The value of the AI-augmented Islamic finance practice is that it automates execution, freeing the professional's time for the judgment work that only qualified practitioners can perform.
Chapter Contract: Revisited
Return to the five questions from the Chapter 31 README. You should now be able to answer each from direct experience:
-
What are the three accounting regimes? You worked through all three: AAOIFI primary (L04-L06, L14), IFRS with Islamic guidance (L08-L11), and applied them comparatively in every exercise.
-
How does the router-to-product-to-overlay architecture work? You built and tested it in this lesson: the global router dispatches to the correct product and jurisdiction files before any output is generated.
-
Why do AAOIFI and IFRS produce different balance sheet presentations? You produced both side-by-side in L14 and reconciled them in L15's consolidation exercise.
-
How would you build a jurisdiction overlay for a new country? You applied Method A and Method B in Steps 3-4 of this exercise: interview-based and document-based knowledge extraction.
-
Where is the boundary between agent execution and SSB judgment? You defined it in the capability statement: the agent handles accounting mechanics, the SSB handles Shariah permissibility.
Try With AI
Setup: Use these prompts in Cowork or your preferred AI assistant.
Prompt 1: Reproduce
I need to add a new jurisdiction to the Islamic finance SKILL.md
library: [CHOOSE ONE: Jordan, Sudan, Iran, Bangladesh, Egypt, or
Kenya].
Research the jurisdiction and produce:
1. The jurisdiction overlay SKILL.md file — following the same
structure as the existing overlays
2. The routing logic update — what line must be added to the
global router for this jurisdiction?
3. A test query for this jurisdiction — a murabaha income
recognition question that validates the overlay produces
correct framework, labels, and disclosures
4. One unique regulatory requirement for this jurisdiction that
does not exist in any of the 13 existing overlays
What you are learning: The library is designed to be extensible. Adding a jurisdiction is not a custom development project: it is Method B document analysis applied to a new regulatory source, followed by a test query to validate. This is the pattern for extending any domain agent library to new contexts.
Prompt 2: Adapt
The router-to-product-to-overlay architecture used in this chapter
handles jurisdictional variation in Islamic finance. Identify another
professional domain where the same pattern would solve the same
problem:
1. Name the domain (e.g., international tax, pharmaceutical
regulation, employment law)
2. What is the equivalent of the "product" layer? (e.g., tax
treaty types, drug classifications, contract types)
3. What is the equivalent of the "jurisdiction overlay"? (e.g.,
country-specific tax rules, national drug authorities,
employment law variations)
4. What would the routing logic look like?
5. What is the equivalent of the SSB boundary — what judgment
cannot be automated in this domain?
Design the skill library structure for this domain.
What you are learning: The architectural contribution of this chapter is not limited to Islamic finance. The router-to-product-to-overlay pattern transfers to any domain where the same transaction or process has different rules by jurisdiction. Tax, legal, healthcare, and regulatory compliance all share this structure. Recognising the pattern across domains is the meta-skill that makes you an architect, not just a domain specialist.
Prompt 3: Apply
Choose a real Islamic finance scenario from your own practice,
institution, or jurisdiction. It could be a murabaha facility
you have worked on, a sukuk issuance in your market, a zakat
computation for a client, or a Shariah screening question for
a portfolio you manage.
Run the scenario through the full skill library:
1. Which product skill does the router select?
2. Which jurisdiction overlay loads?
3. Does the output use the correct income labels, disclosure
references, and regulatory framework for your jurisdiction?
4. Where does the agent produce output that you would need to
adjust based on your professional judgment or local practice?
5. Identify one gap — a rule, label, or disclosure requirement
specific to your context that the library does not yet cover.
Draft the addition you would make to the relevant overlay
skill to close this gap.
Conclude with your assessment: does the deployed library handle
your real-world scenario accurately, or does it require extension?
What is the boundary between what the agent executed correctly and
what required your professional intervention?
What you are learning: Testing the library against your own practice is the definitive validation. A library that handles textbook scenarios but fails on your actual work is incomplete. By identifying gaps and drafting extensions, you are practising the same skill maintenance workflow that keeps any domain agent library current as regulations, standards, and practice evolve.
Flashcards Study Aid
Return to Chapter 31 Overview to review the Chapter Contract questions.