@groupby/ai-dev 0.5.8 → 0.5.10

package/teams/rangers/skills/team-phase-planning/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: team-phase-planning
+description: >-
+  Break project work into reviewable phases using the repo's routing docs, workflow, phase plan, architecture, and decision log. Use when planning a feature slice, sequencing Jira tickets, defining review gates, or turning broad work into implementable phases.
+---
+
+# Team Phase Planning
+
+## Purpose
+
+Use this skill to convert broad work into small phases that can be implemented, validated, and reviewed independently.
+
+## Context Loading
+
+1. Read the project router:
+   - `docs/ai/index.md`
+   - `docs/project/ai-context.md`
+   - `.github/copilot-instructions.md`, if present
+   - `docs/ai/resources/project-doc-contract.md`, if no project router exists
+2. Read the working agreement and workflow docs.
+3. Load task-specific planning docs:
+   - phase plan
+   - decision log
+   - architecture docs
+   - API or frontend scope docs when the work touches those surfaces
+4. For large or unfamiliar doc sets, use `team-docs-snapshot` and read its manifest first.
+
+## Planning Flow
+
+1. State the goal and non-goals.
+2. Identify dependencies, unknowns, and project constraints.
+3. Split the work into phases that each have:
+   - user-visible or reviewable scope
+   - files or areas likely to change
+   - validation plan
+   - review gate
+   - docs that may need updates
+4. Put risky discovery early.
+5. Keep phases small enough that a reviewer can understand the diff without reconstructing the entire project.
+
+## Output Format
+
+Use this shape unless the user asks otherwise:
+
+```markdown
+# Plan: [Work Name]
+
+## Goal
+[One paragraph]
+
+## Assumptions
+- [Assumption]
+
+## Phases
+### Phase 1: [Name]
+Scope:
+Validation:
+Review gate:
+Docs impact:
+
+## Open Questions
+- [Question]
+```

package/teams/rangers/skills/team-project-orientation/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: team-project-orientation
+description: >-
+  Orient to an unfamiliar repository through its AI routing docs, project docs, README, architecture notes, and working agreement. Use when entering a repo, moving a task into a new chat, preparing implementation, or auditing whether the project exposes enough context for AI-assisted work.
+---
+
+# Team Project Orientation
+
+## Purpose
+
+Use this skill to build a small, accurate mental model of a project without reading the whole repo. The goal is to find the project's own context router, then load the smallest useful set of docs.
+
+## Orientation Flow
+
+1. Inspect the repo shape:
+   - `README.md`
+   - `AGENTS.md`
+   - package or workspace manifests
+   - top-level app, package, and docs folders
+2. Locate the AI/project routing entrypoints, in this order:
+   - `docs/ai/index.md`
+   - `.github/copilot-instructions.md`
+   - `docs/project/ai-context.md`
+   - `docs/ai/working-agreement.md`
+   - `docs/ai/resources/project-doc-contract.md`, if this team resource is installed
+3. If a routing table exists, follow it. Always prefer its task-specific guidance over generic assumptions.
+4. If no router exists, infer a temporary route from common docs:
+   - architecture: `docs/**/architecture*.md`
+   - product/context: `docs/**/product*.md`, `docs/**/overview*.md`
+   - decisions: `docs/**/decision*.md`, `docs/**/adr*.md`
+   - workflow: `docs/**/workflow*.md`, `docs/**/phase*.md`
+   - contracts: `docs/**/*contract*.md`, `docs/**/*api*.md`
+5. For broad documentation analysis, use `team-docs-snapshot` before loading many files.
+
+## Orientation Notes
+
+Keep the output concise and project-owned:
+
+- purpose and product/domain
+- main apps/packages and how they fit together
+- tech stack and validation commands, when documented
+- AI routing map and any missing entrypoints
+- implementation rules that look non-negotiable
+- risks or ambiguities to resolve before coding
+
+Do not copy project knowledge into a reusable skill. Project facts belong in that repo's docs.