chore: Remove blog-post from tracking and add to gitignore

- Add blog-post/ to .gitignore
- Keep local files but exclude from version control
This commit is contained in:
Luong NGUYEN committed 2025-12-26 11:04:41 +01:00
1 parent 0fcac18357
commit bb2a0fda42
3 files changed
+1 -660

No files matched your search

+1
View File
@@ -63,3 +63,4 @@ __pycache__/
*.egg-info/
dist/
build/
blog-post/
-332
View File
@@ -1,332 +0,0 @@
<!DOCTYPE html><html><head>
<title>4-essential-slash-commands</title>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.16.25/dist/katex.min.css">
<script src="https://cdn.jsdelivr.net/npm/mermaid@11.12.1/dist/mermaid.min.js"></script>
<style>
code[class*=language-],pre[class*=language-]{color:#333;background:0 0;font-family:Consolas,"Liberation Mono",Menlo,Courier,monospace;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.4;-moz-tab-size:8;-o-tab-size:8;tab-size:8;-webkit-hyphens:none;-moz-hyphens:none;-ms-hyphens:none;hyphens:none}pre[class*=language-]{padding:.8em;overflow:auto;border-radius:3px;background:#f5f5f5}:not(pre)>code[class*=language-]{padding:.1em;border-radius:.3em;white-space:normal;background:#f5f5f5}.token.blockquote,.token.comment{color:#969896}.token.cdata{color:#183691}.token.doctype,.token.macro.property,.token.punctuation,.token.variable{color:#333}.token.builtin,.token.important,.token.keyword,.token.operator,.token.rule{color:#a71d5d}.token.attr-value,.token.regex,.token.string,.token.url{color:#183691}.token.atrule,.token.boolean,.token.code,.token.command,.token.constant,.token.entity,.token.number,.token.property,.token.symbol{color:#0086b3}.token.prolog,.token.selector,.token.tag{color:#63a35c}.token.attr-name,.token.class,.token.class-name,.token.function,.token.id,.token.namespace,.token.pseudo-class,.token.pseudo-element,.token.url-reference .token.variable{color:#795da3}.token.entity{cursor:help}.token.title,.token.title .token.punctuation{font-weight:700;color:#1d3e81}.token.list{color:#ed6a43}.token.inserted{background-color:#eaffea;color:#55a532}.token.deleted{background-color:#ffecec;color:#bd2c00}.token.bold{font-weight:700}.token.italic{font-style:italic}.language-json .token.property{color:#183691}.language-markup .token.tag .token.punctuation{color:#333}.language-css .token.function,code.language-css{color:#0086b3}.language-yaml .token.atrule{color:#63a35c}code.language-yaml{color:#183691}.language-ruby .token.function{color:#333}.language-markdown .token.url{color:#795da3}.language-makefile .token.symbol{color:#795da3}.language-makefile .token.variable{color:#183691}.language-makefile .token.builtin{color:#0086b3}.language-bash .token.keyword{color:#0086b3}pre[data-line]{position:relative;padding:1em 0 1em 3em}pre[data-line] .line-highlight-wrapper{position:absolute;top:0;left:0;background-color:transparent;display:block;width:100%}pre[data-line] .line-highlight{position:absolute;left:0;right:0;padding:inherit 0;margin-top:1em;background:hsla(24,20%,50%,.08);background:linear-gradient(to right,hsla(24,20%,50%,.1) 70%,hsla(24,20%,50%,0));pointer-events:none;line-height:inherit;white-space:pre}pre[data-line] .line-highlight:before,pre[data-line] .line-highlight[data-end]:after{content:attr(data-start);position:absolute;top:.4em;left:.6em;min-width:1em;padding:0 .5em;background-color:hsla(24,20%,50%,.4);color:#f4f1ef;font:bold 65%/1.5 sans-serif;text-align:center;vertical-align:.3em;border-radius:999px;text-shadow:none;box-shadow:0 1px #fff}pre[data-line] .line-highlight[data-end]:after{content:attr(data-end);top:auto;bottom:.4em}html body{font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif;font-size:16px;line-height:1.6;color:#333;background-color:#fff;overflow:initial;box-sizing:border-box;word-wrap:break-word}html body>:first-child{margin-top:0}html body h1,html body h2,html body h3,html body h4,html body h5,html body h6{line-height:1.2;margin-top:1em;margin-bottom:16px;color:#000}html body h1{font-size:2.25em;font-weight:300;padding-bottom:.3em}html body h2{font-size:1.75em;font-weight:400;padding-bottom:.3em}html body h3{font-size:1.5em;font-weight:500}html body h4{font-size:1.25em;font-weight:600}html body h5{font-size:1.1em;font-weight:600}html body h6{font-size:1em;font-weight:600}html body h1,html body h2,html body h3,html body h4,html body h5{font-weight:600}html body h5{font-size:1em}html body h6{color:#5c5c5c}html body strong{color:#000}html body del{color:#5c5c5c}html body a:not([href]){color:inherit;text-decoration:none}html body a{color:#08c;text-decoration:none}html body a:hover{color:#00a3f5;text-decoration:none}html body img{max-width:100%}html body>p{margin-top:0;margin-bottom:16px;word-wrap:break-word}html body>ol,html body>ul{margin-bottom:16px}html body ol,html body ul{padding-left:2em}html body ol.no-list,html body ul.no-list{padding:0;list-style-type:none}html body ol ol,html body ol ul,html body ul ol,html body ul ul{margin-top:0;margin-bottom:0}html body li{margin-bottom:0}html body li.task-list-item{list-style:none}html body li>p{margin-top:0;margin-bottom:0}html body .task-list-item-checkbox{margin:0 .2em .25em -1.8em;vertical-align:middle}html body .task-list-item-checkbox:hover{cursor:pointer}html body blockquote{margin:16px 0;font-size:inherit;padding:0 15px;color:#5c5c5c;background-color:#f0f0f0;border-left:4px solid #d6d6d6}html body blockquote>:first-child{margin-top:0}html body blockquote>:last-child{margin-bottom:0}html body hr{height:4px;margin:32px 0;background-color:#d6d6d6;border:0 none}html body table{margin:10px 0 15px 0;border-collapse:collapse;border-spacing:0;display:block;width:10Line truncated
/* Please visit the URL below for more information: */
/* https://shd101wyy.github.io/markdown-preview-enhanced/#/customize-css */
</style>
<!-- The content below will be included at the end of the <head> element. --><script type="text/javascript">
document.addEventListener("DOMContentLoaded", function () {
// your code here
});
</script></head><body for="html-export">
<div class="crossnote markdown-preview ">
<h1 id="4-essential-slash-commands-i-use-in-every-project">4 Essential Slash Commands I Use in Every Project </h1>
<p><em>Building on the foundation of <a href="https://medium.com/@luongnv89/discovering-claude-code-slash-commands-cdc17f0dfb29">Discovering Claude Code Slash Commands</a>, this post focuses on the practical workflow commands I've found most valuable across different development phases.</em></p>
<hr>
<h2 id="introduction">Introduction </h2>
<p>After mastering the basics of Claude Code slash commands, I discovered that certain commands became indispensable across every project. These four commands form a complete development workflow—from quick commits to comprehensive project infrastructure.</p>
<p>In this post, I'll share how I integrate these commands into my development lifecycle, when to use each one, and practical tips for getting the most value from them.</p>
<hr>
<h2 id="development-workflow-overview">Development Workflow Overview </h2>
<div class="mermaid">graph TD
A[POC Phase] --&gt; B[/push-all - Quick commits\]
B --&gt; C[MVP Complete]
C --&gt; D[/setup-ci-cd - Quality gates\]
D --&gt; E[Development Milestones]
E --&gt; F[/unit-test-expand - Test coverage\]
F --&gt; G[Project Polish]
G --&gt; H[/doc-refactor - Documentation\]
H --&gt; I[Production Ready]
style B fill:#e1f5fe
style D fill:#f3e5f5
style F fill:#e8f5e8
style H fill:#fff3e0
</div><hr>
<h2 id="1-push-all---when-you-need-to-push-changes">1. <code>/push-all</code> - When You Need to Push Changes </h2>
<p><strong>Best for</strong>: Quick deployment of coherent changesets<br>
<strong>When to use</strong>: Multiple related changes that belong together<br>
<strong>Project phase</strong>: Any phase, especially POC and rapid iteration</p>
<h3 id="why-i-use-it">Why I Use It </h3>
<p>The <code>/push-all</code> command has become my go-to for situations where I've made multiple interconnected changes that need to be committed together. Unlike manual git workflows, this command provides comprehensive safety checks that prevent me from accidentally committing sensitive information.</p>
<h3 id="key-features">Key Features </h3>
<ul>
<li><strong>Safety First</strong>: Automatically scans for secrets, API keys, and large files</li>
<li><strong>Smart Commit Messages</strong>: Generates conventional commit messages based on changes</li>
<li><strong>Confirmation Required</strong>: Presents a clear summary before executing</li>
<li><strong>Error Recovery</strong>: Handles common git issues automatically</li>
</ul>
<h3 id="when-to-use-push-all">When to Use <code>/push-all</code> </h3>
<p>✅ <strong>Perfect for:</strong></p>
<ul>
<li>Multi-file documentation updates</li>
<li>Feature implementations with tests and docs</li>
<li>Bug fixes across multiple files</li>
<li>Project-wide formatting/refactoring</li>
<li>Configuration changes</li>
</ul>
<p>❌ <strong>Avoid when:</strong></p>
<ul>
<li>You're uncertain what's being committed</li>
<li>Contains sensitive data</li>
<li>Working on protected branches</li>
<li>You want granular commit history</li>
</ul>
<h3 id="full-command-reference">Full Command Reference </h3>
<p>Since this command exceeds 30 lines (153 lines total), you can view the complete implementation here:</p>
<p><strong><a href="../01-slash-commands/push-all.md">📄 View complete <code>/push-all</code> command</a></strong></p>
<hr>
<h2 id="2-setup-ci-cd---after-poc-completion">2. <code>/setup-ci-cd</code> - After POC Completion </h2>
<p><strong>Best for</strong>: Establishing quality infrastructure<br>
<strong>When to use</strong>: After completing POC, before scaling development<br>
<strong>Project phase</strong>: POC → MVP transition</p>
<h3 id="why-i-use-it-1">Why I Use It </h3>
<p>Once my POC is working and I'm ready to build a proper project, <code>/setup-ci-cd</code> ensures I have the right quality gates in place. It adapts to my project's tech stack and sets up both pre-commit hooks and GitHub Actions without me having to research best practices for each language.</p>
<h3 id="command-content">Command Content </h3>
<pre data-role="codeBlock" data-info="markdown" class="language-markdown markdown"><code><span class="token front-matter-block"><span class="token punctuation">---</span>
<span class="token front-matter yaml language-yaml">name: Setup CI/CD Pipeline
description: Implement pre-commit hooks and GitHub Actions for quality assurance
tags: ci-cd, devops, automation</span>
<span class="token punctuation">---</span></span>
<span class="token title important"><span class="token punctuation">#</span> Setup CI/CD Pipeline</span>
Implement comprehensive DevOps quality gates adapted to project type:
<span class="token list punctuation">1.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Analyze project</span><span class="token punctuation">**</span></span>: Detect language(s), framework, build system, and existing tooling
<span class="token list punctuation">2.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Configure pre-commit hooks</span><span class="token punctuation">**</span></span> with language-specific tools:
<span class="token list punctuation">-</span> Formatting: Prettier/Black/gofmt/rustfmt/etc.
<span class="token list punctuation">-</span> Linting: ESLint/Ruff/golangci-lint/Clippy/etc.
<span class="token list punctuation">-</span> Security: Bandit/gosec/cargo-audit/npm audit/etc.
<span class="token list punctuation">-</span> Type checking: TypeScript/mypy/flow (if applicable)
<span class="token list punctuation">-</span> Tests: Run relevant test suites
<span class="token list punctuation">3.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Create GitHub Actions workflows</span><span class="token punctuation">**</span></span> (.github/workflows/):
<span class="token list punctuation">-</span> Mirror pre-commit checks on push/PR
<span class="token list punctuation">-</span> Multi-version/platform matrix (if applicable)
<span class="token list punctuation">-</span> Build and test verification
<span class="token list punctuation">-</span> Deployment steps (if needed)
<span class="token list punctuation">4.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Verify pipeline</span><span class="token punctuation">**</span></span>: Test locally, create test PR, confirm all checks pass
Use free/open-source tools. Respect existing configs. Keep execution fast.
</code></pre><h3 id="what-it-sets-up">What It Sets Up </h3>
<ul>
<li><strong>Pre-commit hooks</strong>: Local quality checks before each commit</li>
<li><strong>GitHub Actions</strong>: CI/CD pipeline for pull requests and pushes</li>
<li><strong>Language-specific tools</strong>: Automatically detects and configures the right tools</li>
<li><strong>Security scanning</strong>: Integrates security best practices</li>
<li><strong>Multi-platform support</strong>: Configures testing across different environments</li>
</ul>
<hr>
<h2 id="3-doc-refactor---after-mvp-completion">3. <code>/doc-refactor</code> - After MVP Completion </h2>
<p><strong>Best for</strong>: Project documentation organization<br>
<strong>When to use</strong>: After MVP is functional, before scaling team<br>
<strong>Project phase</strong>: MVP → Production preparation</p>
<h3 id="why-i-use-it-2">Why I Use It </h3>
<p>Documentation often becomes an afterthought during MVP development. <code>/doc-refactor</code> helps me reorganize scattered documentation into a coherent structure that scales with the team and project.</p>
<h3 id="command-content-1">Command Content </h3>
<pre data-role="codeBlock" data-info="markdown" class="language-markdown markdown"><code><span class="token front-matter-block"><span class="token punctuation">---</span>
<span class="token front-matter yaml language-yaml">name: Documentation Refactor
description: Restructure project documentation for clarity and accessibility
tags: documentation, refactoring, organization</span>
<span class="token punctuation">---</span></span>
<span class="token title important"><span class="token punctuation">#</span> Documentation Refactor</span>
Refactor project documentation structure adapted to project type:
<span class="token list punctuation">1.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Analyze project</span><span class="token punctuation">**</span></span>: Identify type (library/API/web app/CLI/microservices), architecture, and user personas
<span class="token list punctuation">2.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Centralize docs</span><span class="token punctuation">**</span></span>: Move technical documentation to <span class="token code-snippet code keyword">`docs/`</span> with proper cross-references
<span class="token list punctuation">3.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Root README.md</span><span class="token punctuation">**</span></span>: Streamline as entry point with overview, quickstart, modules/components summary, license, contacts
<span class="token list punctuation">4.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Component docs</span><span class="token punctuation">**</span></span>: Add module/package/service-level README files with setup and testing instructions
<span class="token list punctuation">5.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Organize <span class="token code-snippet code keyword">`docs/`</span></span><span class="token punctuation">**</span></span> by relevant categories:
<span class="token list punctuation">-</span> Architecture, API Reference, Database, Design, Troubleshooting, Deployment, Contributing (adapt to project needs)
<span class="token list punctuation">6.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Create guides</span><span class="token punctuation">**</span></span> (select applicable):
<span class="token list punctuation">-</span> User Guide: End-user documentation for applications
<span class="token list punctuation">-</span> API Documentation: Endpoints, authentication, examples for APIs
<span class="token list punctuation">-</span> Development Guide: Setup, testing, contribution workflow
<span class="token list punctuation">-</span> Deployment Guide: Production deployment for services/apps
<span class="token list punctuation">7.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Use Mermaid</span><span class="token punctuation">**</span></span> for all diagrams (architecture, flows, schemas)
Keep docs concise, scannable, and contextual to project type.
</code></pre><h3 id="documentation-structure-it-creates">Documentation Structure It Creates </h3>
<pre data-role="codeBlock" data-info="" class="language-text"><code>project/
├── README.md (streamlined entry point)
├── docs/
│ ├── architecture/
│ ├── api-reference/
│ ├── user-guide/
│ ├── development-guide/
│ └── deployment/
└── src/
└── [component]/README.md
</code></pre><hr>
<h2 id="4-unit-test-expand---after-each-milestone">4. <code>/unit-test-expand</code> - After Each Milestone </h2>
<p><strong>Best for</strong>: Systematic test coverage improvement<br>
<strong>When to use</strong>: After completing development milestones<br>
<strong>Project phase</strong>: Throughout development, at milestone checkpoints</p>
<h3 id="why-i-use-it-3">Why I Use It </h3>
<p>Instead of letting test coverage lag behind, I use <code>/unit-test-expand</code> at each milestone to systematically identify and fill testing gaps. It's particularly valuable for catching edge cases and error paths that manual testing often misses.</p>
<h3 id="command-content-2">Command Content </h3>
<pre data-role="codeBlock" data-info="markdown" class="language-markdown markdown"><code><span class="token front-matter-block"><span class="token punctuation">---</span>
<span class="token front-matter yaml language-yaml">name: Expand Unit Tests
description: Increase test coverage by targeting untested branches and edge cases
tags: testing, coverage, unit-tests</span>
<span class="token punctuation">---</span></span>
<span class="token title important"><span class="token punctuation">#</span> Expand Unit Tests</span>
Expand existing unit tests adapted to project's testing framework:
<span class="token list punctuation">1.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Analyze coverage</span><span class="token punctuation">**</span></span>: Run coverage report to identify untested branches, edge cases, and low-coverage areas
<span class="token list punctuation">2.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Identify gaps</span><span class="token punctuation">**</span></span>: Review code for logical branches, error paths, boundary conditions, null/empty inputs
<span class="token list punctuation">3.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Write tests</span><span class="token punctuation">**</span></span> using project's framework:
<span class="token list punctuation">-</span> Jest/Vitest/Mocha (JavaScript/TypeScript)
<span class="token list punctuation">-</span> pytest/unittest (Python)
<span class="token list punctuation">-</span> Go testing/testify (Go)
<span class="token list punctuation">-</span> Rust test framework (Rust)
<span class="token list punctuation">4.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Target specific scenarios</span><span class="token punctuation">**</span></span>:
<span class="token list punctuation">-</span> Error handling and exceptions
<span class="token list punctuation">-</span> Boundary values (min/max, empty, null)
<span class="token list punctuation">-</span> Edge cases and corner cases
<span class="token list punctuation">-</span> State transitions and side effects
<span class="token list punctuation">5.</span> <span class="token bold"><span class="token punctuation">**</span><span class="token content">Verify improvement</span><span class="token punctuation">**</span></span>: Run coverage again, confirm measurable increase
Present new test code blocks only. Follow existing test patterns and naming conventions.
</code></pre><h3 id="testing-gaps-it-targets">Testing Gaps It Targets </h3>
<ul>
<li><strong>Error paths</strong>: Exception handling and failure scenarios</li>
<li><strong>Boundary conditions</strong>: Edge values at limits and empty states</li>
<li><strong>State transitions</strong>: Side effects and state changes</li>
<li><strong>Integration points</strong>: Cross-component interactions</li>
<li><strong>Security scenarios</strong>: Input validation and authorization</li>
</ul>
<hr>
<h2 id="integration-into-development-lifecycle">Integration Into Development Lifecycle </h2>
<h3 id="phase-based-usage">Phase-Based Usage </h3>
<div class="mermaid">graph LR
A[POC] --&gt; B[push-all]
B --&gt; C[MVP]
C --&gt; D[setup-ci-cd]
D --&gt; E[Development]
E --&gt; F[unit-test-expand]
F --&gt; G[Polish]
G --&gt; H[doc-refactor]
H --&gt; I[Production]
subgraph "Quick Iteration"
B
end
subgraph "Foundation"
D
end
subgraph "Quality Gates"
F
end
subgraph "Documentation"
H
end
</div><h3 id="my-typical-workflow">My Typical Workflow </h3>
<ol>
<li><strong>POC Phase</strong>: Use <code>/push-all</code> frequently for rapid iteration</li>
<li><strong>MVP Complete</strong>: Run <code>/setup-ci-cd</code> to establish quality infrastructure</li>
<li><strong>Development Sprints</strong>: Use <code>/unit-test-expand</code> at each milestone</li>
<li><strong>Pre-Production</strong>: Execute <code>/doc-refactor</code> for project documentation</li>
<li><strong>Ongoing</strong>: <code>/push-all</code> continues to serve for coherent changesets</li>
</ol>
<hr>
<h2 id="tips-for-maximum-value">Tips for Maximum Value </h2>
<h3 id="1-customize-commands-for-your-project">1. Customize Commands for Your Project </h3>
<p>While these commands work out-of-the-box, I often customize them for project-specific needs:</p>
<pre data-role="codeBlock" data-info="bash" class="language-bash bash"><code><span class="token comment"># Add project-specific patterns to push-all safety checks</span>
<span class="token comment"># Customize doc-refactor for your documentation standards</span>
<span class="token comment"># Extend unit-test-expand with your testing framework preferences</span>
</code></pre><h3 id="2-team-adoption">2. Team Adoption </h3>
<ul>
<li><strong>Start with <code>/push-all</code></strong>: Easiest to adopt and provides immediate value</li>
<li><strong>Progressive introduction</strong>: Add commands as the project matures</li>
<li><strong>Document customizations</strong>: Keep track of project-specific modifications</li>
</ul>
<h3 id="3-integration-with-existing-workflows">3. Integration with Existing Workflows </h3>
<p>These commands complement rather than replace existing practices:</p>
<ul>
<li><strong>Git hooks</strong>: Can trigger these commands automatically</li>
<li><strong>CI/CD pipelines</strong>: Use them as templates for pipeline steps</li>
<li><strong>Code reviews</strong>: Reference command outputs in review discussions</li>
</ul>
<hr>
<h2 id="conclusion">Conclusion </h2>
<p>These four slash commands have transformed how I approach project development:</p>
<ul>
<li><strong><code>/push-all</code></strong> provides safety and speed for coherent changes</li>
<li><strong><code>/setup-ci-cd</code></strong> establishes quality foundations without research overhead</li>
<li><strong><code>/unit-test-expand</code></strong> ensures systematic test coverage improvement</li>
<li><strong><code>/doc-refactor</code></strong> creates scalable documentation structures</li>
</ul>
<p>Together, they form a complete workflow that adapts to different project phases while maintaining consistency and quality standards.</p>
<p>The real power comes from integrating them into your natural development rhythm—not as additional overhead, but as tools that make each phase more efficient and reliable.</p>
<hr>
<h2 id="next-steps">Next Steps </h2>
<ol>
<li><strong>Try <code>/push-all</code></strong> on your next multi-file change</li>
<li><strong>Run <code>/setup-ci-cd</code></strong> after your next POC completion</li>
<li><strong>Use <code>/unit-test-expand</code></strong> at your next milestone</li>
<li><strong>Execute <code>/doc-refactor</code></strong> before your next team expansion</li>
</ol>
<p>Have questions or want to share your own essential slash commands? <a href="https://github.com/luongnv89/claude-howto/issues">Join the discussion</a> in the claude-howto repository.</p>
<hr>
<p><em>This post is part of the <a href="../">claude-howto</a> project, which provides comprehensive examples and documentation for Claude Code features.</em></p>
</div>
<script type="module">
// TODO: If ZenUML gets integrated into mermaid in the future,
// we can remove the following lines.
var MERMAID_CONFIG = ({"startOnLoad":false});
if (typeof MERMAID_CONFIG !== 'undefined') {
MERMAID_CONFIG.startOnLoad = false
MERMAID_CONFIG.cloneCssStyles = false
MERMAID_CONFIG.theme = "default"
}
mermaid.initialize(MERMAID_CONFIG || {})
if (typeof(window['Reveal']) !== 'undefined') {
function mermaidRevealHelper(event) {
var currentSlide = event.currentSlide
var diagrams = currentSlide.querySelectorAll('.mermaid')
for (var i = 0; i < diagrams.length; i++) {
var diagram = diagrams[i]
if (!diagram.hasAttribute('data-processed')) {
mermaid.init(null, diagram, ()=> {
Reveal.slide(event.indexh, event.indexv)
})
}
}
}
Reveal.addEventListener('slidetransitionend', mermaidRevealHelper)
Reveal.addEventListener('ready', mermaidRevealHelper)
await mermaid.run({
nodes: document.querySelectorAll('.mermaid')
})
} else {
await mermaid.run({
nodes: document.querySelectorAll('.mermaid')
})
}
</script>
</body></html>
-328
View File
@@ -1,328 +0,0 @@
# 4 Essential Slash Commands I Use in Every Project
*Building on the foundation of [Discovering Claude Code Slash Commands](https://medium.com/@luongnv89/discovering-claude-code-slash-commands-cdc17f0dfb29), this post focuses on the practical workflow commands I've found most valuable across different development phases.*
---
## Introduction
After mastering the basics of Claude Code slash commands, I discovered that certain commands became indispensable across every project. These four commands form a complete development workflow—from quick commits to comprehensive project infrastructure.
In this post, I'll share how I integrate these commands into my development lifecycle, when to use each one, and practical tips for getting the most value from them.
---
## Development Workflow Overview
```mermaid
graph TD
A[POC Phase] --> B[/push-all - Quick commits\]
B --> C[MVP Complete]
C --> D[/setup-ci-cd - Quality gates\]
D --> E[Development Milestones]
E --> F[/unit-test-expand - Test coverage\]
F --> G[Project Polish]
G --> H[/doc-refactor - Documentation\]
H --> I[Production Ready]
style B fill:#e1f5fe
style D fill:#f3e5f5
style F fill:#e8f5e8
style H fill:#fff3e0
```
---
## 1. `/push-all` - When You Need to Push Changes
**Best for**: Quick deployment of coherent changesets
**When to use**: Multiple related changes that belong together
**Project phase**: Any phase, especially POC and rapid iteration
### Why I Use It
The `/push-all` command has become my go-to for situations where I've made multiple interconnected changes that need to be committed together. Unlike manual git workflows, this command provides comprehensive safety checks that prevent me from accidentally committing sensitive information.
### Key Features
- **Safety First**: Automatically scans for secrets, API keys, and large files
- **Smart Commit Messages**: Generates conventional commit messages based on changes
- **Confirmation Required**: Presents a clear summary before executing
- **Error Recovery**: Handles common git issues automatically
### When to Use `/push-all`
✅ **Perfect for:**
- Multi-file documentation updates
- Feature implementations with tests and docs
- Bug fixes across multiple files
- Project-wide formatting/refactoring
- Configuration changes
❌ **Avoid when:**
- You're uncertain what's being committed
- Contains sensitive data
- Working on protected branches
- You want granular commit history
### Full Command Reference
Since this command exceeds 30 lines (153 lines total), you can view the complete implementation here:
**[📄 View complete `/push-all` command](../01-slash-commands/push-all.md)**
---
## 2. `/setup-ci-cd` - After POC Completion
**Best for**: Establishing quality infrastructure
**When to use**: After completing POC, before scaling development
**Project phase**: POC → MVP transition
### Why I Use It
Once my POC is working and I'm ready to build a proper project, `/setup-ci-cd` ensures I have the right quality gates in place. It adapts to my project's tech stack and sets up both pre-commit hooks and GitHub Actions without me having to research best practices for each language.
### Command Content
```markdown
---
name: Setup CI/CD Pipeline
description: Implement pre-commit hooks and GitHub Actions for quality assurance
tags: ci-cd, devops, automation
---
# Setup CI/CD Pipeline
Implement comprehensive DevOps quality gates adapted to project type:
1. **Analyze project**: Detect language(s), framework, build system, and existing tooling
2. **Configure pre-commit hooks** with language-specific tools:
- Formatting: Prettier/Black/gofmt/rustfmt/etc.
- Linting: ESLint/Ruff/golangci-lint/Clippy/etc.
- Security: Bandit/gosec/cargo-audit/npm audit/etc.
- Type checking: TypeScript/mypy/flow (if applicable)
- Tests: Run relevant test suites
3. **Create GitHub Actions workflows** (.github/workflows/):
- Mirror pre-commit checks on push/PR
- Multi-version/platform matrix (if applicable)
- Build and test verification
- Deployment steps (if needed)
4. **Verify pipeline**: Test locally, create test PR, confirm all checks pass
Use free/open-source tools. Respect existing configs. Keep execution fast.
```
### What It Sets Up
- **Pre-commit hooks**: Local quality checks before each commit
- **GitHub Actions**: CI/CD pipeline for pull requests and pushes
- **Language-specific tools**: Automatically detects and configures the right tools
- **Security scanning**: Integrates security best practices
- **Multi-platform support**: Configures testing across different environments
---
## 3. `/doc-refactor` - After MVP Completion
**Best for**: Project documentation organization
**When to use**: After MVP is functional, before scaling team
**Project phase**: MVP → Production preparation
### Why I Use It
Documentation often becomes an afterthought during MVP development. `/doc-refactor` helps me reorganize scattered documentation into a coherent structure that scales with the team and project.
### Command Content
```markdown
---
name: Documentation Refactor
description: Restructure project documentation for clarity and accessibility
tags: documentation, refactoring, organization
---
# Documentation Refactor
Refactor project documentation structure adapted to project type:
1. **Analyze project**: Identify type (library/API/web app/CLI/microservices), architecture, and user personas
2. **Centralize docs**: Move technical documentation to `docs/` with proper cross-references
3. **Root README.md**: Streamline as entry point with overview, quickstart, modules/components summary, license, contacts
4. **Component docs**: Add module/package/service-level README files with setup and testing instructions
5. **Organize `docs/`** by relevant categories:
- Architecture, API Reference, Database, Design, Troubleshooting, Deployment, Contributing (adapt to project needs)
6. **Create guides** (select applicable):
- User Guide: End-user documentation for applications
- API Documentation: Endpoints, authentication, examples for APIs
- Development Guide: Setup, testing, contribution workflow
- Deployment Guide: Production deployment for services/apps
7. **Use Mermaid** for all diagrams (architecture, flows, schemas)
Keep docs concise, scannable, and contextual to project type.
```
### Documentation Structure It Creates
```
project/
├── README.md (streamlined entry point)
├── docs/
│ ├── architecture/
│ ├── api-reference/
│ ├── user-guide/
│ ├── development-guide/
│ └── deployment/
└── src/
└── [component]/README.md
```
---
## 4. `/unit-test-expand` - After Each Milestone
**Best for**: Systematic test coverage improvement
**When to use**: After completing development milestones
**Project phase**: Throughout development, at milestone checkpoints
### Why I Use It
Instead of letting test coverage lag behind, I use `/unit-test-expand` at each milestone to systematically identify and fill testing gaps. It's particularly valuable for catching edge cases and error paths that manual testing often misses.
### Command Content
```markdown
---
name: Expand Unit Tests
description: Increase test coverage by targeting untested branches and edge cases
tags: testing, coverage, unit-tests
---
# Expand Unit Tests
Expand existing unit tests adapted to project's testing framework:
1. **Analyze coverage**: Run coverage report to identify untested branches, edge cases, and low-coverage areas
2. **Identify gaps**: Review code for logical branches, error paths, boundary conditions, null/empty inputs
3. **Write tests** using project's framework:
- Jest/Vitest/Mocha (JavaScript/TypeScript)
- pytest/unittest (Python)
- Go testing/testify (Go)
- Rust test framework (Rust)
4. **Target specific scenarios**:
- Error handling and exceptions
- Boundary values (min/max, empty, null)
- Edge cases and corner cases
- State transitions and side effects
5. **Verify improvement**: Run coverage again, confirm measurable increase
Present new test code blocks only. Follow existing test patterns and naming conventions.
```
### Testing Gaps It Targets
- **Error paths**: Exception handling and failure scenarios
- **Boundary conditions**: Edge values at limits and empty states
- **State transitions**: Side effects and state changes
- **Integration points**: Cross-component interactions
- **Security scenarios**: Input validation and authorization
---
## Integration Into Development Lifecycle
### Phase-Based Usage
```mermaid
graph LR
A[POC] --> B[push-all]
B --> C[MVP]
C --> D[setup-ci-cd]
D --> E[Development]
E --> F[unit-test-expand]
F --> G[Polish]
G --> H[doc-refactor]
H --> I[Production]
subgraph "Quick Iteration"
B
end
subgraph "Foundation"
D
end
subgraph "Quality Gates"
F
end
subgraph "Documentation"
H
end
```
### My Typical Workflow
1. **POC Phase**: Use `/push-all` frequently for rapid iteration
2. **MVP Complete**: Run `/setup-ci-cd` to establish quality infrastructure
3. **Development Sprints**: Use `/unit-test-expand` at each milestone
4. **Pre-Production**: Execute `/doc-refactor` for project documentation
5. **Ongoing**: `/push-all` continues to serve for coherent changesets
---
## Tips for Maximum Value
### 1. Customize Commands for Your Project
While these commands work out-of-the-box, I often customize them for project-specific needs:
```bash
# Add project-specific patterns to push-all safety checks
# Customize doc-refactor for your documentation standards
# Extend unit-test-expand with your testing framework preferences
```
### 2. Team Adoption
- **Start with `/push-all`**: Easiest to adopt and provides immediate value
- **Progressive introduction**: Add commands as the project matures
- **Document customizations**: Keep track of project-specific modifications
### 3. Integration with Existing Workflows
These commands complement rather than replace existing practices:
- **Git hooks**: Can trigger these commands automatically
- **CI/CD pipelines**: Use them as templates for pipeline steps
- **Code reviews**: Reference command outputs in review discussions
---
## Conclusion
These four slash commands have transformed how I approach project development:
- **`/push-all`** provides safety and speed for coherent changes
- **`/setup-ci-cd`** establishes quality foundations without research overhead
- **`/unit-test-expand`** ensures systematic test coverage improvement
- **`/doc-refactor`** creates scalable documentation structures
Together, they form a complete workflow that adapts to different project phases while maintaining consistency and quality standards.
The real power comes from integrating them into your natural development rhythm—not as additional overhead, but as tools that make each phase more efficient and reliable.
---
## Next Steps
1. **Try `/push-all`** on your next multi-file change
2. **Run `/setup-ci-cd`** after your next POC completion
3. **Use `/unit-test-expand`** at your next milestone
4. **Execute `/doc-refactor`** before your next team expansion
Have questions or want to share your own essential slash commands? [Join the discussion](https://github.com/luongnv89/claude-howto/issues) in the claude-howto repository.
---
*This post is part of the [claude-howto](../) project, which provides comprehensive examples and documentation for Claude Code features.*