skills/sdlc/SKILL.md

@@ -1,25 +1,29 @@
 ---
 name: sdlc
 description: >
-  Software development lifecycle for GroomBook. Covers GitHub authentication,
+  Software development lifecycle for GroomBook. Covers Gitea authentication,
   branch strategy across Dev/UAT/Prod, the four-phase SDLC pipeline with
   product analysis intake, PR review and merge policy, the handoff protocol,
   status semantics, infrastructure layout, the canonical tools list, the
-  GitHub-origin issue board-approval gate, the cc-cpfarhood visibility rule,
+  Gitea-origin issue board-approval gate, the cc-cpfarhood visibility rule,
   the scheduled penetration testing program, and delegation model tier policy.
 ---
 
 # Software Development Lifecycle
 
-## GitHub authentication
+## Gitea authentication
 
-**Invoke the `github-app-token` skill** before any GitHub operation. It generates a short-lived installation token and sets `GH_TOKEN`. **Never** run `gh auth login` — it hangs headless agents. Token expires after ~1 hour; re-invoke to regenerate.
+**Use the `tea` CLI** with the `GITEA_TOKEN` environment variable for all Gitea operations. Configure it once:
 
-GitHub is the **primary source of truth**. Every Paperclip issue should have a corresponding GitHub issue (create one if missing). Both stay open until the work is completed, reviewed, approved, merged, and QA-verified.
+```bash
+tea login add --url https://git.farh.net --token $GITEA_TOKEN --name groombook
+```
 
-## GitHub-origin issue policy — board approval required
+Gitea is the **primary source of truth**. Every Paperclip issue should have a corresponding Gitea issue (create one if missing). Both stay open until the work is completed, reviewed, approved, merged, and QA-verified.
 
-If a task originated from GitHub (`originKind: "github"`), **do not begin work**. Immediately create a board approval:
+## Gitea-origin issue policy — board approval required
+
+If a task originated from Gitea (`originKind: "gitea"`), **do not begin work**. Immediately create a board approval:
 
 ```
 POST /api/companies/{companyId}/approvals
@@ -28,8 +32,8 @@ POST /api/companies/{companyId}/approvals
   "requestedByAgentId": "{your-agent-id}",
   "issueIds": ["{issueId}"],
   "payload": {
-    "title": "Board approval required: GitHub issue",
-    "summary": "Summarize what the GitHub issue requests.",
+    "title": "Board approval required: Gitea issue",
+    "summary": "Summarize what the Gitea issue requests.",
     "recommendedAction": "Approve to begin work.",
     "risks": ["Work begins without board review if approved."]
   }
@@ -55,7 +59,7 @@ Three long-lived branches map to the three deployment environments:
 All changes happen via pull request. Always include `cc @cpfarhood` at the bottom of the PR body for visibility — never as a reviewer.
 
 ```bash
-gh pr create --base dev --title "..." --body "... cc @cpfarhood"
+tea pr create --base dev --title "..." --body "... cc @cpfarhood"
 ```
 
 ## PR review & merge policy
@@ -79,7 +83,7 @@ gh pr create --base dev --title "..." --body "... cc @cpfarhood"
 
 ### Phase 0 — Product analysis (feature intake)
 
-* Feature requests arrive at the CEO via Paperclip or GitHub Issues.
+* Feature requests arrive at the CEO via Paperclip or Gitea Issues.
 * CEO delegates to CMPO (Pawla Abdul) for review.
 * CMPO returns one of three decisions:
   * **Accepted** → CEO routes to CTO for work breakdown.
@@ -176,7 +180,7 @@ Without this release, the receiving agent cannot check out the issue.
 
 ## Deployment — 2-stage Flux GitOps
 
-**Stage 1 — CI (GitHub Actions, runs in each application repo):**
+**Stage 1 — CI (Gitea Actions, uses GitHub Actions-compatible YAML syntax, runs in each application repo):**
 - Triggered automatically on every merge to `main`
 - Builds and tags the Docker image
 - Pushes tagged images to `ghcr.io/groombook/<service>`