openindu-control-tower

Onboard the current openIndu repo to the public workflow plugin and converge duplicate governance assets (principle copies, duplicate governance agents, ghost /launch commands). Use when a sub-repo first introduces the public principles or has a self-hosted principle.md / PRINCIPLE.md copy.

Run the SDLC pipeline at a chosen autonomy tier — L0 human-gated (prod/irreducible), L1 feature-branch semi-auto, L2 staging auto-deploy with auto-rollback, L3 sandbox full-auto. Wraps /design so per-phase STOP points are skipped for L2/L3 and kept for L0/L1. Use when you want the team to run a 0-to-1 idea with minimal intervention.

Build and push a Docker image for an openIndu service. Part of RULE 11 step ④ — image build → push to Aliyun CR. Use after aggregate submodule PR merges, when a service's image needs rebuilding, or to verify a Dockerfile builds correctly before PR.

Use when analyzing, reverse-engineering, onboarding to, or documenting any large codebase. Triggers on requests like "分析这个项目", "explain the architecture", "trace the call stack", "how does X work", "code review", or when needing to understand an unfamiliar codebase before making changes. Follows a 7-step logical flow: problem → features → components → code deep-dive → architecture → 4+1 view → markdown output.

Research and analyze a company for a decision-ready profile or recurring daily company-observation column. Use for company research, industry dynamics, competitive position, or daily company analysis. Do not use as a substitute for personalized investment, legal, or tax advice.

Generate and check the RULE 11 delivery-pipeline completeness checklist (sub-repo PR → merge → aggregate submodule → image build → infra-deploy PR → kubectl apply). Must run before reporting any openIndu bug fix / feature complete, to prevent "applied but not live".

Orchestrate the 0-to-1 SDLC pipeline across the role agents. Hands off along business-analyst → product-manager → architect → ui-ux-designer → build (backend/frontend/edge/station-control) → ops → bi-analyst, with each phase writing its design/<domain>/ artifact and the next phase reading it. Use when a feature needs the full design pipeline (not a one-off fix).

Adopt a DESIGN.md design-system document for a project — pick from the awesome-design-md collection or generate one for the user's brand. ui-ux-designer then writes design/uiux/DESIGN.md and frontend implements against it, producing visually consistent UI. Use when a feature needs UI work and there's no design system yet, or to match a known brand's look.

Collect open issues across a GitHub organization, classify which require action, challenge each actionable recommendation with independent reviewers, and dispatch accepted work through the existing SDLC pipeline until its PR has green CI. Use for organization-wide issue triage and execution, not for a single already-selected issue.

Bring up the openindu-maintainers team and spawn manager. Use for cross-repo coordination or when manager/arbiter need the full review-dispatch flow.

Read/write the team's reusable lessons ledger. Each role's踩坑/技巧/repeated-wins沉淀 to team/memory/<role>/ so agents don't re-derive them. Every agent reads its role memory at startup and appends a lesson after a non-trivial success or failure. Use to seed a role's memory before a task or to record a hard-won insight.

The sole authoritative source of openIndu's 11 AI Agent behavior RULEs. Any openIndu repo must load this before starting any task (RULE 1). Also load when涉及 git push, K8s manifests, Gitee PR, production DB writes, delivery pipeline, agent authorization tiers, or completed-artifact modification.

Create a revision record (changelog) in the control-tower repo logging actual changes to principles / route.json / agent definitions / manifest. Mandatory after editing these control-layer assets; without it, changes aren't traceable.

Query openIndu repo routing — repo URL, type, host (GitHub/Gitee), image, domain, aggregate ownership, K8s namespace. Use to determine "which repo does this change belong to", "what's this service's image/domain", or "GitHub PR or Gitee PR".

Create a new spec design draft (feature / process improvement / principle evolution) in the control-tower repo, following spec/TEMPLATE.md with a 5-dimension self-check, then submit to arbiter for review. Cross-repo changes, principle edits, and new RULEs must go through this flow first (RULE 5).