Gemini CLI's Default Capabilities Are So Powerful That I Reconsidered My Approach to Creating Skills
I created skills for Gemini CLI to achieve operations like inputting PDF content into Excel.
Skills I Created
| Skill | Function |
|---|---|
| pdf-to-text | Convert PDF documents to plain text |
| text-to-excel | Convert Markdown tables to Excel (.xlsx) format |
By combining these, I could create a conversion pipeline: PDF → Text → Excel.
But the Default Capabilities Were Enough
After creating the skills, I realized that Gemini CLI’s default capabilities alone could achieve the same thing.
添付した PDF ファイルを Excel ファイルへ書き出して！
(Export the attached PDF file to an Excel file!)
With just this one-shot prompt, it automatically installs the necessary libraries, parses the PDF content, and outputs it as an Excel file.
There was no need to create skills in advance.
Reconsidering the Order of Skill Creation
My traditional way of thinking was the same as product development. The approach was to create small features (skills) and combine them to achieve larger operations.
| Step | Content |
|---|---|
| 1 | Design and create necessary skills |
| 2 | Build a pipeline by combining skills |
| 3 | Achieve operations using the pipeline |
| 4 | Improve based on feedback |
However, with AI’s default capabilities being so powerful now, this “build from components” mindset is inefficient.
The DCAP Cycle: An AI-native Approach
A better approach is the DCAP cycle instead of PDCA.
| Cycle | Meaning | Interpretation in the AI Era |
|---|---|---|
| D (Do) | Execute first | Ask Gemini CLI to achieve what you want from scratch |
| C (Check) | Verify | Check how much was achieved with default capabilities |
| A (Act) | Improve | Fine-tune the output as needed |
| P (Plan) | Plan | If you’ll use it repeatedly, create skills and standardize |
The key point is that A (Act) and P (Plan) are only executed when necessary.
- If the output is fine → Complete as is (no need for skills)
- If fine-tuning is needed → Repeat feedback in A
- If it’s a recurring operation → Create skills in P, including the conversation logs
Why DCAP Is Better
With AI’s default capabilities being so powerful now, creating skills in advance tends to be a waste of time.
| Traditional (PDCA) | AI-native (DCAP) |
|---|---|
| Requires upfront planning and design | Just let AI try first |
| Rework due to unexpected issues | Judge based on actual output |
| Takes time to create skills | Achieve immediately with default capabilities |
| Over-focus on generality | Work backward from specific use cases |
By running the DCAP cycle, you can fully leverage AI’s power while efficiently creating only the skills that are truly needed.
When to Create Skills
So, when should you create skills?
| Condition | Description |
|---|---|
| Repeated execution | When you perform the same operation many times |
| Fine-tuning is established | When the optimal prompt is determined through dialogue with AI |
| Want to share with others | When you want the team to use the same operation |
| Want to ensure quality | When you want to maintain a certain level of quality |
Conversely, if it’s a one-time operation, there’s no need to create skills. The default capabilities are sufficient.
Summary
Gemini CLI’s default capabilities are more powerful than expected, and many operations can be achieved with a one-shot prompt.
Rather than creating skills in advance, first ask AI, check the output, and create skills only if necessary. I feel that this DCAP cycle is the best practice for AI-native Ops.
As AI evolves, our development processes need to change as well.
That’s all from the Gemba, where I was surprised by Gemini CLI’s default capabilities and proposed the DCAP cycle.