The Story Behind My Akademik Dosen OBE Fiq Skill: From RPS Headaches to a Reusable Claude Skill

Update — 3 September 2026: the skill is now at v5.16.0, and this post has grown with each release. If you take one thing from it: what started as an "RPS generator" isn't just about the RPS anymore. It's a full OBE document suite — curriculum, CPL/CPMK/Sub-CPMK, the RPS itself, the SIAKAD export, teaching tools, assessment and rubrics, end-of-semester CPMK attainment, the WBI learning roadmap, and the dosen–mahasiswa learning contract (Kontrak Pembelajaran). The most recent changes: the learning contract (v5.14.0), a rebuilt WBI roadmap layout (v5.15.0), and one institutional letterhead across every output (v5.16.0).

The Problem Isn't the AI — It's the Paperwork

Writing academic documents for OBE (Outcome-Based Education) is not a five-minute job. In Indonesia's higher-ed system, a single RPS (Rencana Pembelajaran Semester — the semester lesson plan every course must have) has to chain together Graduate Learning Outcomes → CPL (Program Learning Outcomes) → subject matter → the course itself → CPMK (Course Learning Outcomes) → Sub-CPMK (session-level outcomes) → activities → assessment → rubric. Every link has to hold, and every link has to be traceable back to a regulation.

When I first tried leaning on a generic AI for this, the problems showed up fast:

• CPL/CPMK get made up. A generic AI will confidently fill in learning outcomes that sound plausible, even though they're not the department's actual official data.
• Bloom's taxonomy level gets sloppy. Verbs like "understand" or "explain" (Bloom levels C1-C3) kept sneaking in, even though OBE's primary outcomes are required to sit at C4-C6 (analyze and above).
• Assessment weights never get double-checked. The total could land at 95% or 105% and nobody notices until a manual review catches it.
• Regulations change, but the prompt doesn't. Indonesia's Permendiktisaintek No. 39/2025 (as amended by No. 10/2026) superseded the prior regulation — if you have to retype that context into a prompt every single time, sooner or later someone forgets.

This isn't a "the AI isn't smart enough" problem. It's a lack of consistent rules applied every time someone asks for an academic document. So instead of hunting for a longer prompt, I built a skill.

Why a Skill, Not Just a Prompt

A custom skill in Claude is essentially a bundle of instructions, references, and templates that gets loaded whenever the topic matches. The difference from a regular prompt: a skill can carry supporting files that actually get opened and used, instead of being half-remembered from the model's own memory.

For this OBE use case, I organized it into layers:

Three principles I locked in from day one, non-negotiable:

1. Source-first / no fabrication — if official data (learning outcomes, credit hours, weights, lecturer research, campus policy) isn't available yet, the skill has to ask first, never invent it. If the user insists on continuing anyway, the output gets a hard label: "Initial draft proposal; must be validated by the department/curriculum team before use."
2. Bloom C4-C6 only — every time it formulates a learning outcome, the skill is required to open the verb bank rather than guess from memory. Interestingly, the "C4/C5/C6" label itself is never allowed to appear in the output document — only the resulting high-level outcome wording.
3. The full OBE alignment chain must hold — if any link from Graduate Profile to the quality-assurance cycle breaks, the document simply isn't OBE-compliant. Full stop.

The Update That Mattered Most: Asking About Lecturer Research First

The first version of this skill had a subtle but annoying process bug. The old flow: ask for the curriculum document first, fill in 12 data items (course name, credit hours, learning outcomes, course outcomes, etc.), and only at item 13 — almost the very end — did the skill ask for the lecturer's research to cite as supporting reference material.

The problem: an RPS is required to include the lecturer's own research as part of its content. Asking for it that late meant exactly what happened to me — the RPS was already half-built by the time I realized the research data was missing, forcing me to backtrack and patch it in.

In v5.9.0, I flipped the order entirely. Now, as the very first step — before building any part of the RPS — the skill has to ask for two things at once, in a single message:

1. The lecturer's research data (name, title, year, source type, DOI/URL, relevance to the course)
2. The department's curriculum document (or at minimum, the graduate profile, learning outcomes, and curriculum map)

If the lecturer doesn't have that data yet, that's fine — the skill continues with an explicit placeholder, "Lecturer research: [to be filled in by the lecturer/department]", and logs it as incomplete data. The one rule that never bends: never invent a research title.

A small change in question order, but a big difference in how it actually feels to use.

Making It Usable by Other Lecturers

A good skill that only I know how to use is basically wasted. So I wrote it to be picked up by any lecturer in the D4 TRPL study program at Politeknik Wilmar Bisnis Indonesia, not just me.

A few things that matter when someone else uses it:

• Triggering the skill is just plain keywords. Lecturers don't need to memorize special commands. Type "build an RPS," "draft a curriculum," "check Bloom level," or "audit my RPS," and the skill detects the right mode on its own.
• Upload documents before asking for an RPS. If an old curriculum, a research list, or a previous RPS is already attached to the conversation, the skill reads that first — no need to retype everything by hand.
• Watch the label at the end of the document. Every output is marked "Final" or "Draft Proposal [NEEDS DEPARTMENT/CAMPUS VALIDATION]" — that's not a formality, it's the signal for whether a document is ready for official use or still needs department review.
• The campus SIAKAD export format is a different file from the narrative RPS. To get the campus system's format, you have to ask for it explicitly ("SIAKAD format," "session-by-session breakdown") so the skill fills in the official .xlsx template instead of treating it like a regular RPS draft.

The full OBE alignment chain the skill enforces:

Graduate Profile → CPL → Subject Matter → Course → CPMK → Sub-CPMK → Activities → Assessment → Rubric → Quality Cycle (PPEPP)

If any single link in that chain breaks, the document can't be called OBE-compliant — the rule is that simple, and it's also the single most common finding whenever the skill is used to audit an old RPS.

The v5.10.0 Update: Cowork Mode, Projects, and Automatic Folder Structure

After using this for a while, one small complaint kept resurfacing: preparing a full course package — RPS, module, worksheets, slides — in a regular chat meant uploading every file manually, one at a time, and the results just appeared on screen. Saving everything into the right folder was still on me, file by file, session by session.

Claude actually already has an answer for this: Cowork mode and Projects. The difference from a regular chat:

Add Projects and Project Instructions on top: an instruction like "always use the OBE Fiq skill" only needs to be typed once into Project Instructions, and Project Knowledge (the old curriculum, the research list) only needs to be uploaded once — no re-uploading every time you open a new chat. Cowork can also run inside that same Project, so its instructions and files come along for the ride.

The catch: the moment a skill gets access to a working folder, it needs clear folder rules — otherwise things get messy, or it starts creating random folders every time a new document is requested. So in v5.10.0 I added a standard folder pattern the skill must follow:

Academic 2026/                          (main folder, set up once by the user)
├── Regulations & Curriculum/           (cross-course references, NOT per-course)
├── [Course A]/
│   ├── RPS, module, worksheets, slides for this course (in the course folder's root)
│   ├── Session 1/
│   ├── Session 2/
│   └── Session .../
└── [Other courses, same pattern]

The rules I locked into this flow:

• Regulations & Curriculum/ is only for cross-course documents — department curriculum, decrees, regulations — never let one of those end up inside a specific course's folder.
• Course-level documents live in the course folder's root, not inside a session folder. Session N/ folders are only for material specific to that one session.
• Check the existing structure before creating a new folder — never assume the folder is empty, and never create a duplicate folder with a similar name.
• Don't create all 16 session folders at once if only a few have actually been requested — create only as many as needed.
• No folders outside this pattern without asking first. If there's a need for something outside the pattern (say, an accreditation-specific folder), the skill is required to ask where it should go.

The practical effect: a lecturer only has to name the main folder once at the start (or just let Cowork use whatever folder is already connected), then simply asks for whatever document they need — the skill figures out where it belongs, and mentions briefly in chat whenever it creates a new folder.

The v5.13.0 Update: Closing the Loop — CPMK Attainment and a Learning Roadmap

Everything up to v5.10.0 was about producing documents — curriculum, RPS, teaching tools. But OBE doesn't end when the RPS is written. The cycle only closes when you go back at the end of the semester, check whether the course learning outcomes (CPMK) were actually met, and feed that back into the next round. v5.13.0 adds the two pieces that were missing from that loop.

CPMK attainment evaluation. Give the skill the Sub-CPMK → assessment → weight map from the RPS, plus the students' actual scores per assessment, and it computes:

• each student's CPMK score, weighted (not a flat average)
• per-student pass/fail against the minimum threshold (NBM) for each CPMK
• classroom-level attainment percentage per CPMK, compared against the program's target
• the final course grade and pass/fail status per student
• a follow-up plan (RTL) for any CPMK that landed under target — probable cause, remediation options, who owns the fix — mapped to the PPEPP quality cycle

The same non-negotiable rule carries over: the minimum threshold, the classroom target, and the course pass mark all have to come from institutional policy. If they're not supplied, the skill asks; if you push it to run on example numbers anyway, every result gets stamped [DEFAULT ASSUMPTION - NEEDS PROGRAM/SPMI VALIDATION]. Student scores are never invented.

There's also an auto-formula Excel version. Copy the template, fill in one sheet (raw scores per assessment), and the CPMK scores, classroom attainment, and course pass/fail dashboard all calculate themselves. The weighting chain baked into it — assessment instrument → Sub-CPMK → CPMK → CPL → final course grade — matches Politeknik WBI's official 9+1 assessment components.

Learning roadmap in the WBI format. This one groups the Sub-CPMK that already exist into modules spanning ranges of sessions, then builds a WBI-style Excel roadmap: Output / Concept / Indicators / Learning Strategy per module, the exam sessions marked distinctly, a pastel colour per module. Two guardrails: it only runs after the Sub-CPMK exist — no roadmap built on invented outcomes — and the module grouping is interpretive, so the skill proposes a grouping and waits for confirmation before generating the file. (v5.15.0 reworked exactly how this file is laid out — see below.)

One more reference file. For anything touching internal quality assurance (SPMI/PPEPP), the skill now points to the 2026 SPMI Implementation Guide — the current rule is that internal quality standards have to exceed the national standard (SN-Dikti), not merely copy it.

The v5.14.0 Update: The Learning Contract (Kontrak Pembelajaran)

Here's the thing this whole post keeps circling back to: people call it "the RPS skill," but the RPS was only ever the first mode. By v5.13.0 the same skill was already producing the curriculum, deriving CPL/CPMK/Sub-CPMK, filling the campus SIAKAD .xlsx, building teaching tools, scoring end-of-semester CPMK attainment, and generating the WBI learning roadmap. v5.14.0 adds the one document that sits between the lecturer and the students: the Kontrak Pembelajaran — the learning contract.

At Politeknik WBI this is a Formulir Mutu (a quality-assurance form), signed at the start of the semester by three parties: the lecturer, the class representative (Komting), and the head of study program. It's not a new planning document — it's the "agreed, student-facing version" of the RPS for that same course. And that's exactly where a generic AI gets it wrong: asked for a learning contract, it happily writes a fresh set of outcomes, a different weekly schedule, its own assessment weights. Now you have two documents for one course that don't agree with each other.

So the skill's rule for this mode is blunt: the contract is derived from the RPS, never re-authored. Course description, CPL/CPMK, the weekly matrix, and the 100% assessment split are all pulled straight from the existing RPS. The mode's first step is literally to check whether the RPS for that course already exists in the conversation or working folder — if it doesn't, the skill offers to build the RPS first rather than inventing contract content from nothing.

What it produces:

• The quality-form header and signature block — institution identity, document code (the course code, unless the campus numbers its forms separately), and the three-column Pihak I / Pihak II / Disetujui table. Names of the Komting and the head of program have to come from the user — the skill will not make up the name of someone who signs an official document.
• Ten content sections — description, practical benefits, learning outcomes written as plain narrative (not a table of CPL codes) so students can actually read them, an instructional analysis drawn as a flow diagram, teaching strategy, reading list, assignments, grading criteria, weekly schedule, and class ground rules (late tolerance, minimum attendance, plagiarism policy, quiz timing — a WBI default draft is offered but must be confirmed, never auto-pasted).
• A consistency guarantee — the instructional-analysis diagram reuses the same module grouping as the course's WBI learning roadmap if one already exists; assignments and schedule have to line up with the RPS weekly matrix; the grading summary has to total 100% and match the RPS exactly, not be recalculated on its own.

Three new files ship with it: workflows/alur_kontrak_pembelajaran.md, templates/template_kontrak_pembelajaran.md, and the WBI quality-assurance unit's logo asset for the form header.

The v5.15.0 Update: Getting the WBI Roadmap Layout Right

No new mode this time — v5.15.0 is one workflow file (alur_roadmap_wbi.md) rewritten until the generated roadmap actually matches the WBI reference format instead of an approximation of it. Three concrete changes:

• Weights belong in the roadmap. The Output row now carries a percentage next to each Sub-CPMK — analyse … (15%) — and those numbers have to come from the course's already-validated 100% assessment weighting, not be made up on the spot. If per-Sub-CPMK weights were never set, the skill stops and offers to work them out with the weight calculator first, rather than printing a roadmap with guessed or blank percentages.
• Exams attach to the module before them, not floating columns. In the old output UTS and UAS were standalone columns. In the WBI format they sit at the tail of the preceding module: the session number and a merged "Output + Concept" cell (Mid Exam (10%)) get their own exam colour, but the Sub Learning Outcome, Indicators, and Learning Strategy rows stay merged into the parent module — because there's no separate indicator or teaching strategy for an exam sitting.
• The visual spec is pinned down. An explicit repeating pastel palette for modules (#C0D5EC, #F0CCB0, #CADFB6, #AEB8C9), yellow #F9DB78 for UTS and orange #DF8344 for UAS, the course name as bold-italic vertical text down the right edge, and the LEARNING OUTCOME: heading spanning the full table width. Small stuff, but it's the difference between "a table" and "the form the study program recognises."

It's a minor version bump, and that's the point: once a deliverable is in real use, most of the work is these fit-and-finish passes, not new capabilities.

The v5.16.0 Update: One Letterhead for Everything

Another small one, same spirit. Until now, whether an output file carried the Politeknik WBI logo depended on whether I remembered to attach one. v5.16.0 makes it a rule: every deliverable that needs institutional identity — RPS, module, worksheet, roadmap, CPMK evaluation, slides, PDF — uses the bundled assets/logo_wbi_politeknik.png in its header by default. The one exception is documents formally issued by the campus quality-assurance body (Lembaga Penjaminan Mutu), like the learning contract, which keep the separate LPM logo. And an explicit guardrail that matters more than it sounds: the skill must use the actual image asset, never try to redraw the logo from text or shapes.

Not exciting, but it's the kind of consistency that makes a stack of generated documents look like they came from one office instead of five.

What I Learned From Building This

A few things worth writing down for anyone building a similar skill for administrative or academic work:

• Ban fabrication explicitly — don't expect the model to "just know." The anti-fabrication principle needs to be written as a hard rule with an actual verification flow (alur_anti_ngarang.md), not just mentioned once in the skill's description.
• Put formulas in a file, not in the prompt. I moved credit-hour math (1 credit hour = 45 hours = 2,700 minutes per semester) and assessment-weight math into a separate calculator file so it's applied consistently, instead of being "roughly" recalculated with a different result every time.
• A final self-check is mandatory, not optional. The audit checklist that runs before output ships catches a lot of things that are easy to miss — a weight total that isn't 100%, a Bloom label accidentally left in the document, an outdated regulation that's technically been superseded but still lingering.
• Updating a skill is an iterative process, not a one-shot design. Version 5.9.0 came from a real problem with the order lecturer research got asked for; version 5.10.0 came from a complaint about messy files when using Cowork; version 5.13.0 came from noticing the skill only covered the front half of the OBE cycle and never the end-of-semester evaluation that closes it; version 5.14.0 came from realizing the learning contract kept drifting out of sync with the RPS whenever it was written separately; version 5.15.0 was pure fit-and-finish — making the WBI roadmap file match the study program's real template down to the exam-column layout and the palette; version 5.16.0 turned "remember to add the logo" into a default the skill can't forget. A good skill is the product of repeated real use, not something perfectly designed up front.
• Name a tool by its first job and people will underrate the rest. Everyone still calls this "the RPS skill," even though the RPS is one mode among more than a dozen. That's fine as a nickname, but when a new lecturer picks it up it's worth saying out loud: it also does the curriculum, the outcomes, the assessment, the end-of-semester evaluation, the roadmap, and the learning contract — one aligned chain, not a pile of separate tools.
• The moment a skill gets folder access, lock down the folder pattern from day one. Without strict rules about where files can and can't go, the "autonomy" to work independently through Cowork turns into folder chaos fast.

Try It Yourself

If you're a lecturer or from another department who wants to try this, the skill file (akademik-dosen-obe-fiq, v5.16.0) is available for download here:

Download OBE Fiq Skill v5.16.0 (.skill)

The setup is short: download the file, then upload it as a custom skill in Claude (Settings → Capabilities → Skills, or through Claude Code). After that, just type requests as usual — "build an RPS for course X," "draft the CPL," "audit my RPS," "evaluate CPMK attainment from these grades," "build the learning roadmap for this course," "write the Kontrak Pembelajaran for this course" — and the skill detects the right mode and immediately asks for whatever data is required before building anything. If you want a full course package at once (RPS + module + worksheets + slides) without repeated manual uploads, use it through Cowork mode or inside a Project so the skill can read and write directly to a working folder using the Academic 2026 → Regulations & Curriculum + per-course → per-session structure described above.

One reminder that applies to anyone trying this: this skill is designed to help you draft, not replace department validation. Every draft proposal still needs to be checked by the curriculum team before it's used as an official document.

Or, if you're reading this on your phone, just scan below: