Orchestrating large projects
Codex plugin for governing large software projects from discovery through release and operations.
npx -y skills add VKK-00/agentic-project-lifecycle --skill orchestrating-large-projectsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 16 days oldThe repository was created 16 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when Codex must start, decompose, plan, recover, or govern a multi-week product or software initiative with multiple subsystems, stakeholders, agents, or release stages. Do not use for an isolated bugfix, small refactor, or one already-approved bounded feature.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.5 KB, as published. Nobody here has run it
Orchestrating Large Projects
Treat repository artifacts, code, tests, and observed evidence as project memory. Use this skill as a router and activate only the smallest specialist set that matches the work.
Orient and decompose
- RULE-ORCH-01: Inspect applicable
AGENTS.md, project docs, code structure, tests, CI, deployment path,git status, and recent history before proposing edits. State the current mode, outcome, nearest gate, and highest-risk unknown. - RULE-ORCH-02: Split independent outcomes, release cadences, ownership boundaries, or data/security boundaries into separate subprojects. Give each subproject its own
spec → plan → implementation → verificationcycle. - RULE-ORCH-03: During discovery, ask one highest-value unanswered question per message. Do not repeat facts already supplied or discoverable in the repository.
Make decisions inspectable
- RULE-ORCH-04: Maintain a concise ledger of facts, assumptions, decisions, open questions, risks, and evidence. Never silently promote an assumption into a requirement.
- RULE-ORCH-05: Before a consequential product, UX, architecture, data, security, or delivery decision, present two or three materially different approaches with trade-offs and a recommendation.
- RULE-ORCH-06: Do not write production-bound code until the current slice has testable acceptance criteria and an approved design. A disposable spike is allowed only with a hypothesis, timebox, non-production boundary, and exit criterion.
Route and finish
Activate specialists only when their triggers apply: building-saas-products, building-ai-products, modernizing-existing-projects, rescuing-software-projects, releasing-and-operating-products, and auditing-project-readiness.
- RULE-ORCH-08: End each substantial turn with the current phase and decision, files read or changed, observed verification results, unresolved assumptions and risks, and the next bounded gate or executable task.
Read routing and gates for phase selection and artifact model when establishing sources of truth.