@lifeaitools/rdc-skills 0.35.8 → 0.35.10

package/commands/preplan.md

@@ -1,134 +0,0 @@
----
-name: preplan
-description: rdc:preplan (topic) — research the unknowns before committing to an architecture
----
-
-> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
-> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
-> One checklist upfront, updated in place, shown again at end with a 1-line verdict.
-
-> If dispatching subagents or running as a subagent: read `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` first (fallback: `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`).
-
-
-# rdc:preplan — Research Before Planning
-
-## When to Use
-- Starting a new feature area you haven't built before
-- Need to understand how best-in-class projects solve a problem
-- Codebase has unknowns that need mapping before planning
-- Project lead says "research", "look into", "what's the best way to", "how do others do"
-- Called by `rdc:overnight` before planning an epic with no existing tasks
-
-## Arguments
-- `rdc:preplan <topic>` — interactive research session
-- `rdc:preplan <topic> --unattended` — silent mode for overnight builds
-
-## Procedure
-
-1. **Parse the topic** from user input or epic title/description.
-   - Interactive: if vague, ask ONE clarifying question before proceeding
-   - Unattended: infer from the epic title + description — never pause to ask
-
-2. **Load source documents — MANDATORY before any analysis.**
-
-   **Step 2a — Always load these regardless of topic:**
-   ```
-   .claude/rules/infrastructure-contract.md   — hard deployment + registry rules
-   .claude/rules/work-items-rpc.md            — work item schema and RPC patterns
-   .claude/rules/system-quick-links.md        — routing map to system architecture docs
-   docs/CODING-STANDARDS.md                   — SOLID/Clean-Architecture standard; names
-                                                 ATF's Test-Ladder and rdc-harness's
-                                                 proof-ledger pattern where either applies
-                                                 (regen-root; skip if absent)
-   ```
-
-   **Step 2b — Identify affected domains, then load the matching architecture doc:**
-
-   | Domain keywords in topic | Architecture doc to read |
-   |--------------------------|---------------------------|
-   | PRT, trust, capital, NAV, investor, land, DST | `docs/systems/prt/ARCHITECTURE.md` |
-   | CS 2.0, HAIL, PAL, virtue, quad-pixel, ontology, BPMN, cognitive | `docs/systems/cs2/ARCHITECTURE.md` |
-   | marketing, CRM, campaign, contact, outreach, RDC app | `docs/systems/rdc/ARCHITECTURE.md` |
-   | Claude workflow, skills, agents, dispatch, rdc:build | `docs/systems/claude-workflow/ARCHITECTURE.md` |
-   | Life AI, LIFEAI platform, life.ai | `docs/systems/lifeai/ARCHITECTURE.md` |
-   | media, R2, images, regen-media, MCP image | `docs/systems/media/ARCHITECTURE.md` |
-   | UI, component, brand, design token, shared, OG image | `docs/systems/shared/ARCHITECTURE.md` |
-
-   If topic spans multiple domains, read ALL matching architecture docs.
-   If unsure which domain applies, read `docs/systems/claude-workflow/ARCHITECTURE.md` as the fallback.
-
-   **Step 2c — Load domain-specific rules and context files:**
-
-   | Domain | Additional files to read |
-   |--------|---------------------------|
-   | CS 2.0 / any CS2 paradigm work | `.claude/rules/cs2-architecture-first.md` |
-   | Database, schema, migrations, RPC | `.claude/context/supabase-schema.md` |
-   | UI, components, brand, tokens | `.claude/context/design-system-global.md` |
-   | Deploy, infrastructure, DNS, SSL | `.claude/context/coolify-deployment.md` |
-   | Credentials, MCP, clauth, subagents | `.claude/context/clauth.md` |
-   | OG images, social meta, brand assets | `.claude/context/brand-gate.md` |
-   | Cross-platform, Cowork, subagent MCP | `.claude/context/platform-cross-ref.md` |
-
-   **Step 2d — Load CLAUDE.md for every affected package:**
-   - Identify which packages in `packages/` are relevant to the topic
-   - Read `packages/<name>/CLAUDE.md` for each one
-   - At minimum read `packages/supabase/CLAUDE.md` if any DB work is involved
-   - At minimum read `packages/ui/CLAUDE.md` if any UI work is involved
-
-3. **Web research** — search for current (2025-2026) best practices:
-   - How do major projects solve this?
-   - What tools/libraries exist?
-   - What are the common tradeoffs?
-
-4. **Codebase analysis** — what do we already have?
-   - Search relevant packages for existing code
-   - Check `.rdc/research/` for prior research on this topic (fallback: `.rdc/research/`)
-   - Check `docs/archive/` for historical work
-   - Research agents should read relevant guides from `.rdc/guides/` (fallback: `.rdc/guides/`)
-   - Check work items for related epics
-
-5. **Best-in-class comparison** — create a comparison table:
-   | Approach | Pros | Cons | Fit for Us |
-
-6. **Surface unknowns** — what questions remain unanswered?
-
-7. **Write research doc** to `.rdc/research/<topic-slug>.md` (fallback: `.rdc/research/<topic-slug>.md` if `.rdc/` does not exist):
-   ```markdown
-   # Research: <Topic>
-   > Generated: <date> | Requested by: Project Lead
-
-   ## Source Documents Read
-   (list every architecture doc, rules file, context file, and package CLAUDE.md loaded in Step 2)
-
-   ## Question
-   ## What We Already Have
-   ## Best-in-Class Analysis
-   ## Comparison Table
-   ## Unknowns & Open Questions
-   ## Recommendation (preliminary — not a decision)
-   ```
-
-8. **Report results:**
-   - Interactive: summarize findings. Do NOT create epics or write code.
-   - Unattended: skip summary, emit status block only:
-     ```
-     PREPLAN_STATUS: { topic, doc_path, unknowns_count, recommendation_confidence: "high|medium|low", source_docs_read: [list] }
-     ```
-
-## Unattended Escalation
-
-When `--unattended` and `recommendation_confidence` is `"low"` (≥5 unresolved unknowns,
-or no clear best-fit approach exists), escalate via the advisor tool rather than stopping.
-Provide the advisor with: topic, unknowns list, comparison table. Resume with advisor's
-direction if given. If advisor cannot resolve, log and skip to next step.
-
-## Rules
-- **Source documents in Step 2 are MANDATORY — research without them is blind**
-- Output is a RESEARCH DOC, not a plan
-- Do not make architectural decisions — surface options with tradeoffs
-- Do not create work items
-- Do not write code
-- Web search is mandatory — don't just analyze the codebase
-- Keep the doc under 200 lines — concise, not exhaustive
-- Unattended: NEVER pause for input; infer and proceed
-- Always list source docs read in the output doc header

package/commands/release.md

@@ -1,60 +0,0 @@
----
-
-description: rdc:release (repo, [version]) - [--patch, --minor, --major, --dry-run] — bump, tag, publish and verify a package
----
-
-# rdc:release — Generic Release
-
-> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
-> Checklist-only output. No raw git/npm/CI dumps.
-> One checklist upfront, updated in place, shown again at end with 1-line verdict.
-
-## Checklist
-
-```
-rdc:release: <repo> vX.Y.Z -> vA.B.C
-[ ] Source path resolved
-[ ] Release metadata read
-[ ] Working tree clean or user-approved dirty scope identified
-[ ] Current version detected
-[ ] New version computed
-[ ] Dry-run gate handled
-[ ] Version files updated
-[ ] Tests/self-test passed
-[ ] Commit created
-[ ] Tag created
-[ ] Branch and tag pushed
-[ ] CI/publish status verified
-[ ] Registry/package/deploy target shows vA.B.C, if applicable
-[ ] Local install/update executed, if applicable
-[ ] Installed/runtime version verified
-[ ] Smoke test passed
-✅ rdc:release <repo>: vA.B.C live and verified
-```
-
-## Rules
-
-- Do not release without explicit user authorization.
-- Prefer repo-local release instructions in `.rdc/release.json`, README, package scripts, or CI workflows.
-- Never force push or bypass hooks.
-- Never declare success without verifying the installed or deployed version.
-
-For a `package`-class target that already resolves through `rdc-harness`
-(a real monorepo subtree, not a standalone repo like this one), its
-`packages/deploy/src/runners/registry-release.mjs` runner already proves the
-"Tests/self-test passed" through "Local install/update executed" steps
-safely — real `npm pack`, isolated-prefix install (never the real global
-store), real verify, and `--live` explicitly gates the actual publish. Where
-applicable, `node C:/Dev/rdc-harness/bin/rdc-harness.mjs deploy <slug>
-[--live]` can supply those checklist rows' evidence directly instead of
-hand-rolling the same pack/install/verify cycle. This does not replace
-version bump/tag/push — the harness CLI does neither.
-
-## RDC Skills Package
-
-After publishing this package to npm, a clean-box install should use:
-
-```bash
-npm install -g @lifeaitools/rdc-skills@latest
-rdc-skills-install --profile core
-```

package/commands/review.md

@@ -1,15 +0,0 @@
----
-name: review
-description: rdc:review () - [--unattended] — post-build gate over tsc, tests, docs and code review
----
-
-# review
-
-Use Skill tool with skill: "review", passing `--unattended` through if given.
-
-> This file previously carried a full duplicate of the procedure now owned by
-> `skills/review/SKILL.md`. The two drifted — this copy was missing the
-> mandatory code-review gate (step 8b) and the `engineering-behavior.md` read
-> that the other had. One home for the content closes that class of bug
-> permanently rather than requiring the next editor to remember to update
-> both.

package/commands/status.md

@@ -1,85 +0,0 @@
----
-name: status
-description: rdc:status () — snapshot open epics, health, blockers and next action
----
-
-> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
-> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
-> One checklist upfront, updated in place, shown again at end with a 1-line verdict.
-
-> If dispatching subagents or running as a subagent: read `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` first (fallback: `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`).
-
-
-# rdc:status — Project Dashboard
-
-## When to Use
-- Start of any session
-- Project lead asks "what's the status", "where are we", "what's open"
-- Before deciding what to work on next
-
-## Procedure
-
-1. **Open epics:**
-   ```sql
-   SELECT get_open_epics();
-   ```
-
-2. **Work item counts by status:**
-   ```sql
-   SELECT status, count(*) FROM work_items 
-   WHERE status != 'archived' 
-   GROUP BY status ORDER BY status;
-   ```
-
-3. **Items by label/project (top 10 labels):**
-   ```sql
-   SELECT unnest(labels) as label, count(*), 
-          count(*) FILTER (WHERE status = 'done') as done,
-          count(*) FILTER (WHERE status = 'todo') as todo,
-          count(*) FILTER (WHERE status = 'in_progress') as wip
-   FROM work_items 
-   GROUP BY label ORDER BY count DESC LIMIT 10;
-   ```
-
-4. **Recent activity (last 48 hours):**
-   ```sql
-   SELECT title, status, updated_at 
-   FROM work_items 
-   WHERE updated_at > now() - interval '48 hours'
-   ORDER BY updated_at DESC LIMIT 15;
-   ```
-
-5. **Git status:**
-   ```bash
-   git log --oneline -10
-   git status
-   git branch -v
-   ```
-
-6. **Infrastructure health** (if MCP available):
-   - Get infrastructure overview or diagnose issues
-   - Report any apps with failed builds or down containers
-
-7. **Present as a compact dashboard:**
-   ```
-   ## Open Epics (N)
-   <table>
-   
-   ## Work Items: X done | Y todo | Z in_progress
-   
-   ## Recent (48h)
-   <list>
-   
-   ## Deployments
-   <green/red/yellow status>
-   
-   ## Recommended Next
-   <highest priority unstarted epic>
-   ```
-
-## Rules
-- Keep output concise — this is a glance, not a deep dive
-- Always end with a recommendation for what to work on next
-- After the Recommended Next section, suggest which guide file from `.rdc/guides/` (fallback: `.rdc/guides/`) the recommended work would need
-- Use database MCP for queries (not raw curl)
-- If infrastructure MCP is unavailable, skip deployment status and note it