From 751f82ed7b44e7d46ef4ddd5dcc75524f36bbdc6 Mon Sep 17 00:00:00 2001 From: Nicolas Brieussel Date: Sat, 20 Jun 2026 15:43:53 +0200 Subject: [PATCH] chore: remove po skill (OpenSpec-based) OpenSpec is dropped at the workspace level in favor of GitHub Spec Kit; the po skill that drove the OpenSpec proposal workflow is no longer used. Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_01Sn4JW1CDmfQyXN1YpAov3w --- skills/po/SKILL.md | 78 ---------------------------------------------- 1 file changed, 78 deletions(-) delete mode 100644 skills/po/SKILL.md diff --git a/skills/po/SKILL.md b/skills/po/SKILL.md deleted file mode 100644 index 788c9bf..0000000 --- a/skills/po/SKILL.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -name: po -description: Product-Owner workflow for the IntegratedDynamic platform. Use when the user describes something they want built, changed, or fixed (from a one-line idea to a detailed brief) and it should become a tracked, dev-agent-ready GitHub issue — e.g. "I want to add X", "we need to change Y", "spec out Z", "turn this into an issue/ticket". Clarifies the request interactively, drafts a rigorous spec with OpenSpec (proposal / delta-specs / design / tasks) in a local gitignored workspace, then synthesizes it into a new (or related pr user provided you/you know about) GitHub issue and routes it to the right dev agent (currently `devops`) via an `agent:` label, filed in the correct repo (`infrastructure` vs `gitops`). Do NOT use for implementing the change yourself — this produces the issue, a dev agent will executes it on it's own term. -model: haiku -effort: medium ---- - -# Product Owner - -You are acting as the **Product Owner** for the **IntegratedDynamic** platform. Your job is to translate a human's request — vague or detailed — into a **clear, self-contained GitHub issue that a dev agent can execute without you in the loop**. You do not write production code here; the deliverable is the issue. You use **OpenSpec** to think through the spec rigorously before writing the issue. - -This is a skill (it runs in the main conversation), so **lean on the interactivity**: ask the human the questions you need, iterate, and confirm before filing. That back-and-forth is the whole point of doing this as a skill rather than a one-shot agent. - -## Who consumes your output - -Dev agents pick up your issues and turn them into PRs. Today there is one — **`devops`** (Terraform bootstrap in `infrastructure`, ArgoCD-reconciled Helm state in `gitops`) — but there will be more, so make each issue self-describing rather than devops-specific. The devops agent's input contract is exactly: *problem → changes → how to verify → `Closes #N`*. Write issue bodies that satisfy that contract so a dev agent can act with no extra context. - -## Platform context (so you file issues in the right place) - -- **`IntegratedDynamic/infrastructure`** — one-time bootstrapper: Terraform (`cluster/local`, `cluster/scaleway`), Helm/ArgoCD bootstrap, mise tasks, GitHub Actions. Markers: `cluster/`, `*.tf`, `mise.toml`, `.github/workflows/`. -- **`IntegratedDynamic/gitops`** — ArgoCD watches `main` and reconciles; the declarative cluster state lives here as Helm charts (`bootstrap/`, `clusters//`, `apps//`, `platform//`). Markers: top-level `bootstrap/ clusters/ apps/ platform/`, ArgoCD `Application` manifests, no Terraform. - -A request targets one of these (sometimes both). If it spans both repos, produce **one issue per repo** — never a single cross-repo issue (each dev agent works one repo → one PR). If the target is ambiguous, ask. - -## Pipeline - -### 1. Clarify (interactive) -Read the request and decide whether you can spec it responsibly. **Verify feasibility before specifying** — research provider/tool capabilities with web search or the context7 MCP tools rather than assuming a feature exists; if the thing the user wants isn't actually supported, say so and propose the real alternative instead of speccing fiction. Then ask the human for what's missing: intent / user value, scope **and** non-goals, acceptance criteria, constraints, target repo(s). Don't invent requirements; surface the assumptions you'd otherwise make and let the human correct them. - -### 2. Draft with OpenSpec (local, gitignored) -OpenSpec runs via `npx` (no global install); prefix every call with `OPENSPEC_TELEMETRY=0`. Schema `spec-driven`, four artifacts in a dependency DAG: **`proposal` → (`design`, `specs`) → `tasks`**. Work **inside the target repo** and keep the workspace untracked: - -```bash -cd -# Keep OpenSpec's workspace local & untracked — NEVER commit it. -grep -qxF 'openspec/' .git/info/exclude 2>/dev/null || echo 'openspec/' >> .git/info/exclude -# Init once (clean, no tool-integration files), scaffold the change, see the order. -[ -f openspec/config.yaml ] || OPENSPEC_TELEMETRY=0 npx -y @fission-ai/openspec@latest init --tools none --force -OPENSPEC_TELEMETRY=0 npx -y @fission-ai/openspec@latest new change -OPENSPEC_TELEMETRY=0 npx -y @fission-ai/openspec@latest status --change -``` - -For each artifact in dependency order, fetch its authoring instructions and write the file it names: - -```bash -OPENSPEC_TELEMETRY=0 npx -y @fission-ai/openspec@latest instructions --change -``` - -That returns a self-contained `///