| name | orchestrating-software-lifecycle |
| description | MANDATORY. DO NOT start a new task, fix a bug, or implement a feature without calling 'activate_skill' on 'orchestrating-software-lifecycle' first. This is the REQUIRED PROTOCOL to manage the full software development lifecycle (SDLC) through a high-fidelity 5-phase workflow: Alignment, Architecture, Implementation, Validation, and Submission. This skill is the MANDATORY ORCHESTRATOR for starting any new feature, fixing a bug, or performing code reviews. TRIGGER THIS SKILL IMMEDIATELY for any task involving 'start a task', 'help with this project', or 'what's next?'. Use it to prevent 'context drift' and ensure every task follows a rigorous engineering path from initial alignment to final verification. DO NOT proceed with implementation until Phase 1 Alignment is established. It serves as the primary gateway for ensuring that all development is grounded in clear objectives and verified architectural strategies. Proceeding without activation constitutes a protocol failure. |
Standard Software Engineering Lifecycle
You are the project engineer. You MUST strictly follow the Research -> Strategy -> Execution lifecycle. Do not skip phases or take shortcuts.
๐ Re-Entry & Starting Mid-Task
If you are starting a session where work is already in progress (e.g., addressing PR feedback):
- Identify the State: Use
git status and check for open PRs/MRs.
- Re-Enter: State your entry point (e.g., "Current Phase: 5. Submission & Peer Review (Addressing Feedback)").
- Read the Room: Read all existing PR comments/reviews before making any changes.
๐ก๏ธ Workflow Enforcement
The Workflow is the Law. All tasks must proceed through the phases defined below.
- No Skipping: Never jump to implementation before Alignment and Architecture are formally completed.
- Explicit State: Always prefix your intent with the current workflow phase (e.g., "Current Phase: 1. Alignment").
- Evidence-Based Transitions: Moving between phases requires evidence (e.g., an issue comment, a drafted ADR, or passing tests).
๐ Clarity & Ambiguity Protocol
Avoid errors due to unspoken assumptions by applying this protocol:
- Low Ambiguity: State key assumptions and move to Strategy.
- Moderate Ambiguity: Engage in focused clarification first (ask 1-3 targeted questions).
- High Ambiguity: Explicitly state assumptions and WAIT for user validation before proceeding.
๐ค Session Mode Protocols
- Interactive Mode: Mandatory "Wait-for-Approval" at the end of Phase 1 and Phase 2. Use "Radical Candor"โchallenge the user and propose alternatives.
- Autonomous Mode: Do not block. Document your self-alignment/architecture in the project's tracking system (Issue/ADR) and proceed immediately. If risk is extreme, halt and log a critical intervention request.
๐ฆ Strict Workflow Mandate
- Announcement: At the start of every task or major step, you MUST explicitly state which Phase you are currently in (e.g., "Current Phase: 1. Alignment").
- Sequential Progress: You MUST complete each phase in order. Do not move to Architecture without Alignment, or Implementation without an approved Strategy/ADR.
- Discovery: Before acting, you MUST identify the project's specific protocol (test runners, build tools, and Git Platform: GitHub or GitLab).
- Verification: You MUST verify your changes through automated tests before proceeding to Phase 5. If no tests exist, you MUST create a reproduction script.
- Documentation: You MUST update the project's documentation (
GEMINI.md, README.md, or component docs) simultaneously with code changes in the same commit/PR.
- Diff Hygiene: You MUST be extremely careful when using replacement tools to avoid accidental deletions of existing content. Always verify your
git diff before committing.
๐ง Mental Checklist
๐ The Workflow
1. Alignment (Problem Space / Research)
๐ Read Phase 1 Guide
- Action (External Discovery): If the task involves understanding or troubleshooting external libraries or repositories, you MUST activate and follow the
investigating-external-dependencies skill. DO NOT use generic search tools (web_fetch, google_web_search) as your primary source-level discovery mechanism.
2. Architecture (Solution Space / Strategy)
๐ Read Phase 2 Guide
- Action: If high-ambiguity, activate
deep-brainstorming.
- Action: Document decisions using
maintaining-rigorous-architecture-decisions.
3. Implementation (Execution)
๐ Read Phase 3 Guide
- Action: Consult the relevant
engineering-reliable-[software/scripts]-with-[Language] skill.
4. Validation (Verification & Cleanup)
๐ Read Phase 4 Guide
- Mandate: Identify and run the project's specific test runner.
- Local-CI Parity: Strive to run the full validation suite locally before pushing. Look for
Makefiles, Taskfiles, or local-ci scripts that mirror the remote pipeline.
- Cleanup: Remove unneeded changes and simplify code before submission.
5. Submission & Peer Review (Delivery & Iteration)
๐ Read Phase 5 Guide
- Action: Use
collaborating-on-git-projects for PR creation and feedback loops.
- Iteration: This phase is a loop. Address feedback, push updates, and reply to threads until the PR is merged.
๐ ๏ธ Project Discovery Cheat Sheet
| Task | Typical Discovery Files |
|---|
| Project Context | GEMINI.md, README.md, ARCHITECTURE.md |
| Build/Test | Makefile, package.json, Cargo.toml, pyproject.toml |
| Dependencies | requirements.txt, package-lock.json, go.mod |
| CI/CD | .github/workflows/, .gitlab-ci.yml, jenkinsfile |
๐ References
maintaining-rigorous-architecture-decisions: ADR & Strategy standards.testing-software-efficiently: The Testing Trophy & Mocking principles.collaborating-on-git-projects: Commits & PR Standards.authoring-effective-user-documentation: External doc standards (Diรกtaxis).upholding-devsecops-standards: Security & Hardening mandates.investigating-external-dependencies: Senior-Level library investigation (source code, APIs, best practices).
