Referensi skill

Semua skill noskill

Penjelasan setiap skill: kapan dipakai, cara memanggil, langkah kerjanya, hasil yang didapat, dan aturan penting. Sebagian besar skill dipanggil otomatis oleh Claude sesuai permintaanmu; lima shortcut dipanggil manual dengan /noskill:….

feature-flow ticket-workflow project-profile tiket rapikan lazy tiket fix tiket board tiket lanjut prd-writer erp-requirements task-breakdown mockup-prototype coding-standards debug-assistant user-guide standup-update freelance-proposal

Alur kerja

Skill bertanda internal tidak muncul di menu /; skill itu dipakai otomatis oleh agent dan orkestrator, dan tetap bisa dipanggil Claude saat relevan.

feature-floworkestrator

Menjalankan pekerjaan seperti tim engineering: tiket dikerjakan developer, dicek reviewer, diuji QA, lalu DONE. Skill ini berjalan di sesi utama dan satu-satunya yang memindahkan status tiket.

Kapan
Saat kamu minta "kerjakan sampai selesai", "lewat review dan QA", "dari PRD sampai done", atau melanjutkan board tiket.
Cara pakai
/noskill:feature-flow lalu jelaskan pekerjaannya, atau minta dengan kalimat biasa.
Dua mode
  • Cepat — bug fix, fitur kecil, atau revisi fitur yang sudah ada. Permintaan langsung jadi tiket, kamu setujui, lalu masuk loop.
  • Lengkap — fitur atau modul baru: desain domain → PRD → BRD (lengkap, ringkas, atau tanpa BRD) → tiket → loop.
Tahapan
  1. Konteks: prefix ID, satu repo atau beberapa, level BRD, profil project, branch kerja feat/… atau fix/….
  2. Desain domain (khusus ERP/WMS) dengan erp-requirements Bagian A.
  3. PRD dengan prd-writer di sesi utama, karena butuh tanya-jawab. Gate: kamu setujui.
  4. BRD oleh agent brd-tracer, dilewati kalau tanpa BRD. Gate: kamu setujui.
  5. Tiket oleh agent task-planner. Gate: board dan Kontrak API disetujui; pilih otomatis/per tiket dan berurutan/paralel.
  6. Loop tiket: developer → reviewer → QA, dengan jalur BUG, HOLD, dan revisi.
  7. Selesai: typecheck, lint, dan seluruh test sekali, lalu push + PR, merge lokal, atau dibiarkan.
Fitur hemat waktu
  • Revisi dikirim ke developer yang sama, jadi tiket dan kode tidak dibaca ulang.
  • Tiket complexity: simple dikerjakan developer dengan Sonnet.
  • Database dan server dinyalakan sekali per sesi untuk semua QA.
  • Mode paralel: tiket berikutnya dikerjakan di git worktree selagi tiket sebelumnya di-review/QA (maks 2, atau 3 kalau beda repo).
Hasil
File tiket di docs/noskill/tickets/, satu commit per tiket di branch kerja, dan PR dengan deskripsi yang disusun dari tiket. Multi-repo: satu PR per repo yang saling menautkan.
Aturan penting
  • Tidak ada tahap yang dilompati tanpa persetujuanmu.
  • Orkestrator tidak menulis dan tidak menilai kode sendiri; itu tugas agent.
  • Satu tiket HOLD tidak menghentikan tiket lain. Pertanyaan HOLD dikumpulkan lalu ditanyakan sekaligus.
  • Tanpa agent (misal di claude.ai), tahap dikerjakan di sesi yang sama, tetapi review dan QA tetap dipisah dengan verdict yang jelas.
Terkait
ticket-workflow, task-breakdown, project-profile, semua agent.

ticket-workflowkontrak · internal

Aturan bersama untuk semua tiket: format file, arti tiap status, siapa yang memindahkan, dan verdict agent. Dipakai otomatis oleh orkestrator dan agent.

Kapan
Saat tiket dibuat, dipindahkan, atau dilaporkan, dan saat kamu tanya status tiket.
Status
  • TODO → IN_PROGRESS (developer) → REVIEW (reviewer) → QA (QA) → DONE.
  • BUG: gagal QA, kembali ke developer dengan bug report.
  • HOLD: butuh keputusanmu, blocker dari luar, atau sudah 3 putaran gagal.
Aturan transisi
  • Hanya orkestrator yang mengubah status, rounds, dan Riwayat.
  • Satu tiket per direktori kerja, supaya diff review hanya berisi tiket itu.
  • Urutan ambil: BUG dulu, lalu TODO yang depends_on-nya DONE, tiket BE sebelum FE.
  • rounds naik setiap tiket kembali ke developer; di angka 3 tiket masuk HOLD.
  • Tidak ada status yang dilompati. DONE hanya dengan bukti test yang dijalankan.
  • Tiket dengan integrates_with baru diuji QA setelah tiket BE-nya DONE, lalu diuji bersama.
Isi file tiket
  • Frontmatter: id, title, type, complexity, repo (multi-repo), status, trace, ac, tc, depends_on, integrates_with, related, rounds, tracker_ref.
  • Bagian: Deskripsi, Acuan, File/Lokasi, Kontrak API (tiket BE), Acceptance Criteria, Cara Verifikasi, Catatan (temuan pembuat tiket: helper yang dipakai ulang, file contoh, test yang ada), Riwayat.
Verdict agent
  • developer: READY_FOR_REVIEW atau BLOCKED.
  • reviewer: APPROVED, CHANGES_REQUESTED, atau BLOCKED.
  • QA: PASS, FAIL (dengan bug report: langkah, expected, actual, bukti), atau BLOCKED.
Catatan
Bug di luar AC tiket jadi tiket BUG-NNN baru. Kalau perilaku benarnya belum ditentukan, tiket itu masuk HOLD dulu. Board dibaca langsung dari file tiket, tidak disimpan terpisah.

project-profilesekali per project

Men-scan repo sekali lalu menulis docs/noskill/project-profile.md yang dibaca semua agent, supaya command, struktur, dan helper tidak dicari ulang di setiap tiket.

Kapan
Pertama kali memakai noskill di sebuah project, saat feature-flow tidak menemukan profil, atau saat kamu minta "refresh profil".
Cara pakai
/noskill:project-profile
Cara scan
  • Hanya membaca manifest dan konfigurasi (package.json, go.mod, composer.json, CI, CLAUDE.md, awal README), bukan seluruh source.
  • Struktur folder dua level teratas.
  • Nama helper yang di-export di folder utilitas, beserta satu baris kegunaannya.
  • Command test/typecheck/lint dijalankan sekali untuk memastikan benar.
Isi profil
  • Stack dan versi.
  • Tabel command: install, test semua, test satu file, test terkait file yang diubah, lint file tertentu, typecheck, menyalakan environment, health check.
  • Struktur folder, helper yang dipakai ulang, aturan project.
  • Daftar repo (untuk fitur multi-repo) dan tracker (none, github, atau notion).
Aturan
Hanya fakta yang terverifikasi; yang belum dicek ditulis "belum dicek". Refresh kalau manifest/lockfile berubah, command gagal, atau kamu minta "refresh profil". Saat refresh, hanya bagian yang berubah yang diganti, dan baris baru yang belum ada di profil lama (misalnya command environment dan health check) ditambahkan. Tulisan manual tetap dipertahankan. Profil repo lain disimpan di repo dokumen sebagai project-profile-<nama>.md.

Shortcut

Aksi tiket digabung dalam satu perintah /noskill:tiket: board (default kalau tanpa argumen), fix, lanjut, dan rapikan. Hanya bagian aksi yang dipilih yang dibaca, jadi tetap hemat token. /noskill:lazy tetap perintah sendiri.

tiket rapikan/noskill:tiket rapikan

Merapikan tiket yang sudah dibuat supaya sesuai aturan tiket terbaru, atau mereview ulang kode tiket yang sudah DONE.

Cara pakai
  • /noskill:tiket rapikan — semua tiket TODO dan HOLD.
  • /noskill:tiket rapikan WMS-BE-004 — satu tiket saja.
  • /noskill:tiket rapikan review WMS-BE-004 — review ulang kode tiket DONE.
Yang dicek
  • Tiket per layer (migration, DTO, test sendiri) → digabung ke tiket endpoint/fitur-nya.
  • Tiket terlalu besar atau mencakup beberapa repo → dipecah.
  • Tiket BE tanpa Kontrak API → dilengkapi dari PRD/BRD atau kode.
  • Tiket FE yang memakai depends_on ke tiket BE → diganti integrates_with.
  • complexity kosong, File/Lokasi generik, AC tanpa sisi negatif → dilengkapi.
  • Duplikat atau sudah tercakup tiket DONE → diusulkan dihapus.
Alur
  1. Usulan ditampilkan dulu: tabel ID lama → aksi → ID hasil, board sesudahnya, jumlah tiket sebelum → sesudah, dan pertanyaan terbuka.
  2. File tiket baru diubah setelah kamu setujui. Riwayat mencatat asal tiket (misal "gabungan dari WMS-BE-002, WMS-BE-003"), dan rujukan depends_on/integrates_with di tiket lain ikut diperbarui.
Review ulang
Reviewer menilai commit tiket DONE itu. Kalau ada temuan, tiket asal tetap DONE dan dibuat tiket BUG-NNN baru yang merujuk ke tiket asal.
Batasan
Tiket yang sedang jalan (IN_PROGRESS, REVIEW, QA, BUG) dan tiket DONE tidak diubah saat merapikan.

lazy/noskill:lazy

Lazy senior dev mode: mengerjakan permintaan langsung dengan solusi paling sederhana dan terpendek yang benar-benar jalan, tanpa tiket, review, atau QA.

Cara pakai
/noskill:lazy tambahkan filter status di endpoint list order
Kapan
Perubahan kecil yang jelas dan tidak butuh alur tim. Untuk yang butuh review dan QA, pakai /noskill:tiket fix.
Cara berpikir
  1. Perlu dibuat atau tidak.
  2. Sudah ada di codebase? Pakai.
  3. Standard library atau fitur framework? Pakai.
  4. Dependency yang sudah terpasang? Pakai; tidak menambah dependency.
  5. Kalau tetap harus ditulis: kode minimal.
Aturan
  • Diff sekecil mungkin, tanpa refactor atau reformat.
  • Tidak ada abstraksi, config, opsi, atau kode "buat nanti" yang tidak diminta.
  • Validasi input, error handling yang perlu, dan keamanan tidak dipangkas.
  • Tetap ada bukti: test atau command yang relevan dijalankan.
Kapan berhenti
Kalau ternyata menyentuh aturan bisnis baru, skema database, lebih dari ±5 file, atau beberapa repo, Claude berhenti dan menyarankan /noskill:tiket fix atau /noskill:feature-flow.
Laporan
Maksimal ±8 baris: file yang diubah, kenapa ini cara paling sederhana, hasil test, dan yang belum dicek.

tiket fix/noskill:tiket fix

Jalan pintas untuk bug fix atau perubahan kecil lewat mode cepat feature-flow.

Cara pakai
/noskill:tiket fix diskon di atas 100% bikin harga minus
Yang terjadi
  1. Kode terkait dibaca supaya tiket berisi path nyata.
  2. Tiket FIX-NNN ditulis: AC positif dan negatif, File/Lokasi, Cara Verifikasi.
  3. Kamu menyetujui tiketnya.
  4. Tiket masuk loop developer → reviewer → QA → DONE.
Catatan
Kalau deskripsinya terlalu kabur untuk dijadikan AC, Claude bertanya sekali dulu.

tiket board/noskill:tiket board

Menampilkan status semua tiket tanpa mengubah file apa pun.

Cara pakai
/noskill:tiket board
Isi
  • Satu tabel per status: TODO, IN_PROGRESS, REVIEW, QA, BUG, HOLD, DONE, dengan ID, judul, rounds, dan repo kalau ada.
  • Pertanyaan yang menunggu jawabanmu dari setiap tiket HOLD.
  • Durasi tiap tiket di tahap developer, review, dan QA (dari jam di Riwayat), rata-rata per tahap, dan tahap yang paling lama.
  • Jumlah per status dan tiket berikutnya yang akan diambil.
Hemat token
Status dibaca sekaligus dengan satu grep; file tiket hanya dibuka penuh untuk tiket HOLD.

tiket lanjut/noskill:tiket lanjut

Melanjutkan alur tiket dari sesi sebelumnya berdasarkan status yang tersimpan di file.

Cara pakai
/noskill:tiket lanjut, atau /noskill:tiket lanjut pakai pembulatan ke bawah untuk sekaligus menjawab tiket HOLD.
Yang terjadi
  1. Board dan profil dibaca, branch kerja dan worktree dicocokkan.
  2. Tiket yang berhenti di tengah dilanjutkan dari tahapnya: IN_PROGRESS/BUG ke developer, REVIEW ke reviewer, QA ke QA.
  3. Catatanmu dicatat di Riwayat tiket HOLD, lalu tiket dikembalikan ke status sebelumnya.
  4. Loop berlanjut sampai semua DONE atau ada yang perlu keputusanmu.

Requirement & desain

prd-writer

Menyusun Product Requirements Document dengan struktur baku dan diagram Mermaid, selalu didahului pertanyaan klarifikasi.

Kapan
Saat kamu minta PRD, dokumen requirement, atau scoping sistem baru. Juga untuk membuat PRD dari kode yang sudah ada (Reverse-PRD).
Alur
  1. Kamu memberi deskripsi singkat.
  2. Claude menyusun minimal 5 pertanyaan yang sesuai konteks (role dan akses, integrasi, aturan bisnis, batasan teknis, notifikasi, skala), semuanya dalam satu pesan.
  3. Setelah dijawab, PRD ditulis sebagai file Markdown.
Struktur PRD
  • Header, Overview, Requirements (RBAC: bisa dan tidak bisa per role), Core Features, User Flow, Architecture, Database Schema, API Design, Design & Technical Constraints.
  • Wajib ada diagram: flowchart atau sequence untuk alur utama, dan ERD untuk database.
Reverse-PRD
Kode dibaca dulu (model, route, guard, komponen), lalu setiap bagian PRD disusun dari bukti di kode. Bagian yang tidak bisa dipastikan ditandai, tidak dikarang.
Prinsip
Spesifik dan bisa diverifikasi, eksplisit soal pengecualian, menjelaskan alasan keputusan, dan merujuk standar yang sudah ada.
Terkait
erp-requirements (Bagian A sebelum PRD, Bagian B sesudahnya), task-breakdown, mockup-prototype.

erp-requirementsERP/WMS · internal, dipakai brd-tracer

Requirement ERP/WMS dalam dua bagian yang dipakai berurutan: desain domain sebelum menulis schema, lalu dokumen requirement dengan rantai ID yang bisa ditelusuri.

Kapan
Saat merancang modul atau ERD untuk inventory, purchasing, sales, finance, atau WMS, dan saat kamu minta BRD, user story dan acceptance criteria, atau traceability matrix. Kalau hanya butuh salah satu bagian, hanya bagian itu yang dipakai.
Bagian A — desain domain
  1. Tentukan core business dulu.
  2. Master data terpusat, dipakai semua modul.
  3. Stock ledger (pergerakan stok), bukan field stock yang diubah langsung.
  4. Setiap transaksi punya workflow status, bukan sekadar CRUD.
  5. RBAC, bukan role yang di-hardcode.
  6. Audit trail untuk data penting.
  7. Penomoran dokumen tersentralisasi.
  8. Satu source of truth per entity.
  9. Business flow dulu, baru ERD.
  10. Roadmap MVP bertahap.
  11. Modular monolith dulu, microservices belakangan.
  12. Inventory satu-satunya pemilik stok; event hanya untuk efek samping.
Bagian B — BRD
  • Rantai BR → PROC → US (+ FR) → AC → TECH → TC → UAT, misalnya BR-INV-001 → US-INV-001 → AC-002 → TECH-003 → TC-INV-002.
  • Level lengkap (layer 1–5) untuk fitur lintas divisi atau yang butuh sign-off/UAT; ringkas (US → AC → TECH + TC) untuk perubahan kecil. Di feature-flow ada juga pilihan tanpa BRD.
  • Hasilnya di folder 01-business sampai 05-testing. Setiap Test Case berjenis positif, negatif, atau batas.
Di feature-flow
Bagian A dipakai di Tahap 1 di sesi utama; Bagian B dikerjakan agent brd-tracer di Tahap 3.
Terkait
Contoh lengkap Goods Receipt ada di folder references/ skill ini. Sebelumnya skill ini terpisah menjadi erp-domain-design dan erp-brd-traceability.

task-breakdowninternal, dipakai task-planner

Memecah PRD atau BRD menjadi tiket yang bisa dikerjakan, dengan aturan ukuran yang sederhana.

Kapan
Saat kamu minta "pecah jadi task", "breakdown PRD", atau backlog. Di feature-flow dijalankan oleh agent task-planner.
Aturan tiket
  • BE: satu tiket per endpoint baru atau yang berubah, termasuk migration, DTO, service, test, Swagger, dan Kontrak API.
  • FE: satu tiket per fitur atau halaman.
  • Bug: satu tiket per bug.
  • Tidak ada tiket per layer atau per file.
  • Perubahan kecil digabung: maksimal 3 endpoint simple di resource yang sama (list, detail, lookup, CRUD biasa), atau perubahan kecil di halaman yang sama, jadi satu tiket. Endpoint dengan aturan bisnis, transaksi, perubahan akses, atau tabel baru tetap tiket sendiri.
Checklist AC
Saat menulis AC, setiap input dan aturan dicek terhadap daftar ini, dan AC negatif/batas ditambahkan hanya untuk yang relevan: batas angka termasuk batas kolom database (misal int4), pencocokan teks tanpa membedakan huruf besar/kecil dan spasi, input kosong, respons error persis sesuai Kontrak API, upload/import, batas tanggal/periode, dan role yang harus ditolak. Bug yang ketahuan setelah QA paling mahal.
BE dan FE
  1. Tiket BE memuat Kontrak API sejak dibuat: method, path, request, response sukses, dan kode error.
  2. Tiket FE memakai integrates_with ke tiket BE, sehingga bisa dikerjakan bersamaan berdasarkan kontrak.
  3. QA tiket FE menunggu BE DONE, lalu menguji keduanya bersama.
  4. Perubahan kontrak lewat BLOCKED dan dicatat di kedua tiket.
Langkah
  1. Pahami konteks: project baru atau menambah ke yang sudah ada, berapa repo yang terdampak.
  2. Turunkan tiket dari setiap bagian PRD/BRD.
  3. Tiket integrasi dibuat presisi: proxy tipis tetap tipis, tidak menduplikasi logic.
  4. Setiap tiket berisi deskripsi, acuan, Trace, File/Lokasi nyata, AC, Cara Verifikasi, dan dependency.
  5. Urutkan fase yang wajar.
Prinsip
Setiap tiket bisa ditelusuri ke PRD/BRD, menyesuaikan codebase yang ada, dan "selesai" dibuktikan lewat Cara Verifikasi.

Standar & kualitas

coding-standardsinternal, dipakai developer & reviewer

Standar penulisan dan review kode untuk NestJS, Laravel, Golang/Gin, Vue, Next.js, serta PostgreSQL/MySQL.

Kapan
Saat membuat project, modul, endpoint, atau migration, saat review kode, atau saat kamu menyebut "sesuai standar".
Prinsip inti
  • Reuse dulu: cari helper yang sudah ada sebelum menulis logic baru; logic bisnis di service/usecase, bukan di controller atau UI.
  • Perubahan surgical: hanya yang diminta, tanpa refactor atau reformat sampingan.
  • Solusi paling sederhana dulu: perlu atau tidak → sudah ada → standard library → dependency terpasang → kode minimal.
  • Nyatakan asumsi; refactor besar butuh rencana dulu.
Isi
  • Naming per bahasa dan database.
  • ORM dan akses database, termasuk menghindari N+1.
  • Struktur folder per stack.
  • TDD (RED dulu), quality gate berurutan (typecheck → lint → test → review), simplify pass.
  • Logging: error log vs audit log.
  • Desain API: versioning /api/v{n}, format response, paginasi.
  • Dokumentasi Swagger/OpenAPI per stack (NestJS @nestjs/swagger, Laravel l5-swagger/scramble, Golang swaggo), checklist breaking change, dan checklist sebelum merge — dulu skill api-doc-standard.
  • State management frontend, konvensi Git dan commit, checklist code review.
Hemat token
Detail per stack ada di folder references/ dan hanya dibaca saat dibutuhkan.

debug-assistantdipakai untuk tiket BUG

Alur debugging terstruktur supaya perbaikan menyasar penyebab, bukan gejala.

Kapan
Saat kamu melaporkan error, stack trace, atau "kok nggak jalan". Developer memakainya otomatis untuk tiket BUG.
Alur
  1. Reproduce: pastikan bug bisa diulang.
  2. Isolasi: persempit lokasi masalah.
  3. Diagnosa root cause: telusuri mundur sampai titik asal data atau state yang salah.
  4. Fix terkecil di titik asal, lalu verifikasi dengan bukti.
  5. Cegah berulang: test yang mengunci bug itu.
Format jawaban
Kemungkinan penyebab (diurutkan), cara memverifikasi tiap kemungkinan, lalu rekomendasi fix setelah penyebab pasti.
Integrasi eksternal
Untuk WMS API, n8n, Power Automate, dan Microsoft Graph: cek request (header, auth, body), baca body error lengkap, dan cek status layanan pihak luar.

Tambahan — plugin noskill-extras

Skill di luar alur tiket ada di plugin terpisah noskill-extras, dipanggil dengan awalan /noskill-extras:. Pasang hanya kalau perlu: /plugin install noskill-extras@noskill.

mockup-prototype

Membuat mockup atau prototype UI (HTML atau React) dari PRD, per layar dan per role.

Kapan
Saat kamu minta mockup, prototype, wireframe, atau desain UI dari requirement.
Langkah
  1. Daftar layar diambil dari PRD, dikelompokkan per role.
  2. Fidelity ditentukan: wireframe, mockup (default), atau prototype yang bisa diklik.
  3. Design system yang sudah ada dicek dulu; modul tambahan mengikuti tampilan aplikasi induknya.
  4. Mockup dibangun termasuk state loading, kosong, dan error.
  5. Review akhir terhadap PRD, lalu anotasi singkat.
Hasil
File HTML/React yang bisa dibuka dan didiskusikan dengan stakeholder.

user-guide

Panduan pemakaian untuk pengguna non-teknis, dengan bahasa sederhana dan langkah per fitur.

Kapan
Saat kamu minta user guide, panduan pengguna, atau manual book. Ditawarkan otomatis di akhir feature-flow.
Alur
  1. PRD dipakai sebagai sumber fitur, role, dan alur.
  2. Untuk dokumen besar (lebih dari 5 bagian), outline disepakati dulu sebelum menulis.
  3. Dokumen ditulis per role dan per fitur.
Struktur
Judul dan pembuka, daftar isi, memulai, panduan per fitur, flowchart dalam bahasa sehari-hari, slot screenshot, FAQ, dan kontak bantuan.
Prinsip
Istilah pengguna, bukan istilah teknis; satu langkah satu tindakan.

standup-update

Merangkum pekerjaan menjadi update standup harian atau laporan mingguan.

Kapan
Saat kamu minta standup, update harian, status report, atau progress report.
Sumber
  • Kalau ada tiket noskill: tiket yang DONE sejak update terakhir jadi Yesterday, tiket yang sedang jalan jadi Today, tiket HOLD jadi Blockers, semuanya dari Riwayat tiket.
  • Selain itu: commit log, daftar task, atau ceritamu.
Format
Daily: Yesterday, Today, Blockers. Mingguan: ringkasan per project yang rapi ditempel ke Notion.
Prinsip
Bahasa hasil, bukan daftar commit; dikelompokkan per project; blocker yang tersirat diangkat secara eksplisit.

freelance-proposal

Proposal dan scoping project freelance dengan fase, timeline, dan harga dalam Rupiah.

Kapan
Saat kamu minta proposal, quotation, penawaran harga, atau estimasi project untuk client.
Struktur
  1. Ringkasan kebutuhan.
  2. Lingkup per fase, setiap fase punya hasil yang bisa didemokan.
  3. Stack teknologi.
  4. Timeline.
  5. Harga per fase dalam Rupiah.
  6. Syarat dan ketentuan, termasuk syarat pembayaran.
Estimasi
Mempertimbangkan integrasi pihak ketiga, jenis client, dan kompleksitas (landing page vs full-stack dengan panel admin). Angka akhir selalu didiskusikan denganmu, tidak ditentukan otomatis.