The world of software engineering is shifting at an unprecedented pace. Just a few years ago, we were amazed by AI that could autocomplete simple functions. Today, we are in an era where generative AI can execute projects from end to end.
However, there is a harsh reality often obscured by this technological euphoria: powerful AI without clear orchestration will only generate "spaghetti code" at warp speed. Imagine building a large-scale mobile application. You provide a simple prompt: "Build user authentication and profile features." Without strict boundaries, the AI will immediately take the initiative. It might wire up state management however it pleases, ignore dependency injection, and completely bulldoze the Clean Architecture principles you’ve worked so hard to establish. The code might run (and successfully compile), but when the time comes for maintenance or feature expansion, you’ll be staring at a mountain of technical debt.
This is exactly why we can no longer rely on the old ways. In a previous article, we discussed breaking down the Software Development Life Cycle (SDLC) into an orchestration of custom agents. Now, after various advanced experiments and iterations, it’s time to upgrade to version 2.0.
In this update, we adopt the GitHub Spec Kit approach a methodology that literally forces the AI to think like a Senior Software Architect before it even dares to touch a single line of code. This approach is the core of the Vibe Coding philosophy, where you act as the director interacting with the AI autonomously and iteratively, but with extremely strict guardrails.
The best part? I have gathered, refined, and open-sourced all the specialist agents we will discuss in this article in the Awesome Copilot Indonesia GitHub repository.
Let’s dissect how to conduct this god-tier AI orchestration, taking it from an abstract idea to a production launch.
Ending AI "Assumptive Hallucinations" with the Spec Kit
The fundamental flaw in current AI coding is "assumptive hallucination." When faced with confusion or a lack of context, Large Language Models (LLMs) tend to guess rather than ask.
The Spec Kit approach solves this problem by revoking the AI's freedom to guess. We separate the development lifecycle into a series of static, plain-text documents (Markdown) and require explicit approval at every transition point. The flow becomes highly linear, disciplined, and deterministic:
PRD ➡️ INTERROGATION ➡️ SPEC ➡️ VALIDATION ➡️ PLAN ➡️ CODE ➡️ DOCUMENTATION
We distribute this workload across 8 specialist Custom Agents. Each agent is armed with a "Zero Assumption" protocol, if they are confused, the instructions are ambiguous, or the context is lacking, they are strictly forbidden from making assumptions and must halt to ask you for clarification.
More Than Just Agents: A Multi-Platform Ecosystem
In the latest update, the Awesome Copilot ID repository doesn’t just contain Custom Agents; it provides a complete ecosystem consisting of:
- Agents & Skills: The specialist AI "brains" and step-by-step SOPs.
- Guardrails (Instructions / Rules): Global markdown files (e.g., taming-copilot.md or clean-code.md) that enforce strict coding standards and architectural patterns across the entire project.
- Automations (Prompts): Reusable shortcut commands (e.g., /create-specification) to instantly execute repetitive tasks without typing long prompts.
Note: This entire ecosystem is now multi-platform. All the components above are ready to be used natively with GitHub Copilot (.github), OpenCode (.opencode), CommandCode (.commandcode), and Google Antigravity (.agents).
The 8-Phase SDLC Orchestra with AI Specialists
Inside the Awesome Copilot Indonesia repository, each agent has strict boundaries of authority. Here is how they work in a relay:
Phase 0: Discovery & Onboarding with @BrainstormingExplorerAnalyst
What if you aren’t starting a project from scratch, but rather diving into a poorly documented legacy codebase? This is where SDLC 2.0 begins with Phase 0.
Instead of letting the AI guess and modify code right away, we deploy a specialized agent aliased @BrainstormingExplorerAnalyst. This agent operates purely under a read-only Senior Staff Engineer persona. Its job is to map entry points, detect stacks of tech debt, and critique the current code structure (e.g., flagging if business logic is leaking into the UI layer, violating Clean Architecture principles).
Its superpower: Once it finishes an interactive brainstorming session with you, it will proactively offer to generate a "Project Discovery Draft." This raw document is what you will hand over to the Product Manager Agent in Phase 1, ensuring new features don’t collide with existing architectural constraints.
Phase 1: Ideation & Product Definition (@ProductManagerPRD)
Everything starts with a business problem. A developer's fatal flaw is immediately thinking about database schemas upon hearing a new idea. In this phase, we summon the PM agent. It has one hard rule: Do not write or execute code. Its primary job is to interview you. It will dig into success metrics, target users, and most importantly: Non-Goals (what is NOT included in this release scope). The final output is a PRD document containing structured User Stories and crystal-clear Acceptance Criteria.
Phase 2: Interrogation & Ambiguity Resolution (@ClarificationAnalyst)
A PRD often harbors invisible logical loopholes. This is where @ClarificationAnalyst steps in as the Devil's Advocate. Instead of blindly agreeing, this agent will "attack" your PRD with extreme questions (interrogation). What if the user loses internet connection while this function is called? What happens to the data queue if the third-party API times out? This agent forces you to patch all edge cases before any code is written.
Adopting the "Grill Me" Protocol
One of the biggest upgrades in this Custom Agent orchestration is the injection of the "Grill Me" protocol into the Clarification and Specification agents. Often, when an AI analyzes a document, it bombards us with a list of 10 open-ended questions that are cognitively exhausting (Machine Gun Questioning).
With the Grill Me protocol, we force the agent to obey two strict rules:
- Ask One at a Time: The AI can only raise one ambiguity (or edge case) at a time. It may only proceed to the next issue after you answer.
- Do the Heavy Lifting: The AI is forbidden from asking lazy questions like, "How should we handle errors?" It must provide concrete technical options based on codebase analysis, for example: "For timeout errors, would you prefer to (A) Retry 3 times in the background, or (B) Show a 'Try Again' button to the user? I recommend Option A."
This approach shifts the AI from a "passive note-taker" to a "proactive brainstorming partner," making the Vibe Coding process feel like a natural, seamless back-and-forth rather than a one-way interrogation. All crucial, hard-to-reverse decisions agreed upon during this rapid-fire session are automatically frozen into an Architecture Decision Record (ADR) document by the Specification agent.
Phase 3: Technical Architecture Translation (@SpecificationArchitect)
Once the business logic is watertight, we hand the prd.md over to @SpecificationArchitect. This agent is the bridge. It reads the PRD, traverses the existing codebase, and formulates a technical contract document in the /spec/ directory. This document defines interfaces, data contracts (JSON schemas/static data types), and enforces Clean Architecture rules (such as the separation of Use Case and Repository layers coined by Uncle Bob).
Phase 4: Cross-Consistency Check (@ArtifactConsistencyChecker)
This is the security checkpoint. Before the final execution plan is locked in, @ArtifactConsistencyChecker audits the /spec/ documents against the prd.md. Its primary job is traceability validation. It ensures not a single business requirement is left out of the technical specs, and conversely, no "stealth" features are snuck into the spec if they were never requested in the PRD.
Phase 5: Phased Execution Plan (@PlannerArchitect)
The validated /spec/ document is then handed to @PlannerArchitect. This agent's job is to break down the architectural specification into ordered, atomic tasks inside the /plan/ directory (e.g., feature-auth-v1.md). The brilliance of this agent lies in its embedded Braking Mechanism. At the end of every implementation table in the Markdown document, the agent requires two tasks: VERIFY (the AI must run unit tests) and APPROVAL (the executing AI must come to a hard stop and wait for your explicit permission to proceed).
Phase 6: Code Execution (@GodModeDev)
Now, the stage belongs to our main executor. Armed with Karpathy Guidelines, @GodModeDev operates like a high-precision machine. Because all the cognitive load (architecture, design, validation) has been handled by the /plan/ document, this agent can focus 100% on writing code (Surgical Changes & Simplicity First). It will read the plan step-by-step, execute tasks, check them off automatically, and when it reaches an APPROVAL stage, the terminal locks up until you hit Enter or give the green light.
Phase 7: Quality Assurance & Smart Remediation
Code, no matter how well-written, requires oversight. We have two detective agents in this phase:
- @ExpertCodeReviewer: This agent dissects your Pull Requests or local commits. It analyzes Clean Code violations, audits security vulnerabilities (OWASP Top 10), and formulates a new plan specifically for refactoring.
- @BugRemediationArchitect: When the system crashes, this agent utilizes the Detective Protocol. It refuses to guess. It will ask for stack traces and reproduction steps. After analyzing the root cause, it creates a remediation plan using the Test-Driven Bug Fixing (TDBF) philosophy: Phase 1 writes a test that FAILS to reproduce the bug; Phase 2 fixes the logic until the test PASSES, complete with Rollback procedures.
Phase 8: Industry Standard Documentation (@DiataxisDocumentationArchitect)
Poor documentation is just as dangerous as poor code. This final agent adopts the global Diátaxis Framework standard. Before writing a single word, it will ask you: Is this document intended as a Tutorial (learning), How-To (problem-solving), Reference (pure specification), or Explanation (architectural concept explanation)? It ensures your documentation is organized, non-overlapping, and packaged in elegant, standard terminology.
Choosing the Right "Brain": AI Model Strategy (Thinking vs. Execution)
A common mistake developers make when orchestrating AI is using the exact same LLM for every task. However, Software Engineering requires two distinct types of intelligence: Deep Reasoning (Thinking) and Rapid Action (Execution/Coding).
For the workflow above to run optimally, you must pair the custom agent with the appropriate backend AI model.
1. Thinking & Reasoning Models
These models are built with massive parameters and possess high-level reasoning capabilities. They are highly meticulous but usually respond slightly slower and cost more tokens (if using an API). These models excel at crafting architecture, detecting logical flaws, and analyzing complex text.
Recommended Models: Gemini Pro Thinking, Claude Opus, GPT High / Extra High, or analytic variants like DeepSeek Pro, GLM, Minimax, Qwen, or other open source models that support reasoning and deep thinking.
Agent Match:
-
@ProductManagerPRD(Requires empathy and product analysis). -
@ClarificationAnalyst(Requires high-level critical logic). -
@SpecificationArchitect(Requires absolute comprehension of software architecture). -
@PlannerArchitect(Requires spatial capability to break complex tasks into atomic ones). -
@ExpertCodeReviewer(Requires anomaly detection akin to an auditor).
2. Action & Coding Models (Executors)
These models are highly agile. They are optimized for speed, have extremely low latency, and are specifically fine-tuned to understand programming syntax, execute terminal commands, and manipulate files.
Recommended Models: Claude Sonnet (currently the undisputed king of interactive coding), Gemini Flash (blazing fast with massive context windows), DeepSeek Flash, Qwen, MiniMax, Kimi, GLM, or Codex GPT High.
Agent Match:
-
@GodModeDev(Requires extreme speed to jump between files, run terminal commands, and output syntax relentlessly). -
@DiataxisDocumentationArchitect(Perfect for Flash models to produce long Markdown texts in seconds). -
@ArtifactConsistencyChecker(Fast models with large context windows, like Gemini Flash, are perfect for running parallel comparisons of two long text files).
By decoupling models based on specialization, you not only improve your app’s code quality and architecture but also optimize workflow speed and save on API token costs.
The Unified Ecosystem (The Vibe Coding Setup)
For those of you who love a minimalist yet extremely powerful workflow, this SDLC approach feels like absolute magic when integrated with the right tools.
Instead of being trapped in a heavy, traditional IDE, you can rely on a decoupled ecosystem. Imagine this: You open Google Antigravity or VS Code with Copilot (acting as your super-lightweight, standalone text editor) on your left monitor to write and read PRD and Plan ideas asynchronously. On your right monitor, you run OpenCode (the terminal-based agent executor engine).
When you save a document in Google Antigravity or VS Code, the AI agents inside OpenCode can be instructed to read the Markdown file changes in real-time and instantly execute the next step in the terminal. Everything communicates through a Single Source of Truth: the Markdown text contracts. It’s clean, deterministic, and you are entirely in control.
Bringing the Agents to Your Workspace
You might be wondering, "How do I bring these specialist AI agents from a GitHub repository into my daily code editor?"
The good news is, we’ve made the integration incredibly straightforward, regardless of your development environment. Whether you prefer the classic GitHub Copilot in VS Code, the lightweight asynchronous environment of Google Antigravity and Codex, a terminal-based executor like OpenCode, or the swift CLI assistance of CommandCode, the Awesome Copilot ID ecosystem has you covered.
At its core, setting up these agents is as simple as copying specific configuration folders (such as .github, .agents, .opencode, .codex or .commandcode) along with the AGENTS.md file from our repository into your project's root directory. Once they are in place, your chosen AI assistant will automatically read these files as strict guardrails, adopting the personas and "Zero Assumption" protocols instantly.
Since each tool has its own unique flavor and slight variations in the setup process, I have prepared a comprehensive, step-by-step installation guide to keep this article neat and focused.
You can find the complete setup instructions and download all the Custom Agents for your preferred editor or CLI right here:
👉GitHub - GulajavaMinistudio/awesome-copilot-id
Conclusion
Building software in the generative AI era is not about handing the entire steering wheel over to the machine; it’s about building intelligent guardrails.
By breaking down the software development lifecycle into an orchestra of specific agents, governing them with Spec Kit documents, and assigning AI models (Thinking vs. Execution) to their rightful places, we ensure that coding speed never sacrifices product quality or architectural integrity.
Interested in trying this out and rebuilding the way you produce code? Feel free to study, use, and fork these custom agents from the official repository at:
GitHub - GulajavaMinistudio/awesome-copilot-id
Video Tutorial: GitHub Spec Kit Crash Course by The Net Ninja (YouTube)
Let’s shift our paradigm in writing software. If you have any questions, don’t hesitate to leave them in the comments section. Happy Vibe Spec Coding! 🚀🚀🚀
Top comments (0)