@jakkrichm/create-nexus-devflow 2.0.0

package/template/.agents/skills/deployment-procedures/SKILL.md

@@ -0,0 +1,241 @@
+---
+name: deployment-procedures
+description: Production deployment principles and decision-making. Safe deployment workflows, rollback strategies, and verification. Teaches thinking, not scripts.
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# Deployment Procedures
+
+> Deployment principles and decision-making for safe production releases.
+> **Learn to THINK, not memorize scripts.**
+
+---
+
+## ⚠️ How to Use This Skill
+
+This skill teaches **deployment principles**, not bash scripts to copy.
+
+- Every deployment is unique
+- Understand the WHY behind each step
+- Adapt procedures to your platform
+
+---
+
+## 1. Platform Selection
+
+### Decision Tree
+
+```
+What are you deploying?
+│
+├── Static site / JAMstack
+│   └── Vercel, Netlify, Cloudflare Pages
+│
+├── Simple web app
+│   ├── Managed → Railway, Render, Fly.io
+│   └── Control → VPS + PM2/Docker
+│
+├── Microservices
+│   └── Container orchestration
+│
+└── Serverless
+    └── Edge functions, Lambda
+```
+
+### Each Platform Has Different Procedures
+
+| Platform | Deployment Method |
+|----------|------------------|
+| **Vercel/Netlify** | Git push, auto-deploy |
+| **Railway/Render** | Git push or CLI |
+| **VPS + PM2** | SSH + manual steps |
+| **Docker** | Image push + orchestration |
+| **Kubernetes** | kubectl apply |
+
+---
+
+## 2. Pre-Deployment Principles
+
+### The 4 Verification Categories
+
+| Category | What to Check |
+|----------|--------------|
+| **Code Quality** | Tests passing, linting clean, reviewed |
+| **Build** | Production build works, no warnings |
+| **Environment** | Env vars set, secrets current |
+| **Safety** | Backup done, rollback plan ready |
+
+### Pre-Deployment Checklist
+
+- [ ] All tests passing
+- [ ] Code reviewed and approved
+- [ ] Production build successful
+- [ ] Environment variables verified
+- [ ] Database migrations ready (if any)
+- [ ] Rollback plan documented
+- [ ] Team notified
+- [ ] Monitoring ready
+
+---
+
+## 3. Deployment Workflow Principles
+
+### The 5-Phase Process
+
+```
+1. PREPARE
+   └── Verify code, build, env vars
+
+2. BACKUP
+   └── Save current state before changing
+
+3. DEPLOY
+   └── Execute with monitoring open
+
+4. VERIFY
+   └── Health check, logs, key flows
+
+5. CONFIRM or ROLLBACK
+   └── All good? Confirm. Issues? Rollback.
+```
+
+### Phase Principles
+
+| Phase | Principle |
+|-------|-----------|
+| **Prepare** | Never deploy untested code |
+| **Backup** | Can't rollback without backup |
+| **Deploy** | Watch it happen, don't walk away |
+| **Verify** | Trust but verify |
+| **Confirm** | Have rollback trigger ready |
+
+---
+
+## 4. Post-Deployment Verification
+
+### What to Verify
+
+| Check | Why |
+|-------|-----|
+| **Health endpoint** | Service is running |
+| **Error logs** | No new errors |
+| **Key user flows** | Critical features work |
+| **Performance** | Response times acceptable |
+
+### Verification Window
+
+- **First 5 minutes**: Active monitoring
+- **15 minutes**: Confirm stable
+- **1 hour**: Final verification
+- **Next day**: Review metrics
+
+---
+
+## 5. Rollback Principles
+
+### When to Rollback
+
+| Symptom | Action |
+|---------|--------|
+| Service down | Rollback immediately |
+| Critical errors | Rollback |
+| Performance >50% degraded | Consider rollback |
+| Minor issues | Fix forward if quick |
+
+### Rollback Strategy by Platform
+
+| Platform | Rollback Method |
+|----------|----------------|
+| **Vercel/Netlify** | Redeploy previous commit |
+| **Railway/Render** | Rollback in dashboard |
+| **VPS + PM2** | Restore backup, restart |
+| **Docker** | Previous image tag |
+| **K8s** | kubectl rollout undo |
+
+### Rollback Principles
+
+1. **Speed over perfection**: Rollback first, debug later
+2. **Don't compound errors**: One rollback, not multiple changes
+3. **Communicate**: Tell team what happened
+4. **Post-mortem**: Understand why after stable
+
+---
+
+## 6. Zero-Downtime Deployment
+
+### Strategies
+
+| Strategy | How It Works |
+|----------|--------------|
+| **Rolling** | Replace instances one by one |
+| **Blue-Green** | Switch traffic between environments |
+| **Canary** | Gradual traffic shift |
+
+### Selection Principles
+
+| Scenario | Strategy |
+|----------|----------|
+| Standard release | Rolling |
+| High-risk change | Blue-green (easy rollback) |
+| Need validation | Canary (test with real traffic) |
+
+---
+
+## 7. Emergency Procedures
+
+### Service Down Priority
+
+1. **Assess**: What's the symptom?
+2. **Quick fix**: Restart if unclear
+3. **Rollback**: If restart doesn't help
+4. **Investigate**: After stable
+
+### Investigation Order
+
+| Check | Common Issues |
+|-------|--------------|
+| **Logs** | Errors, exceptions |
+| **Resources** | Disk full, memory |
+| **Network** | DNS, firewall |
+| **Dependencies** | Database, APIs |
+
+---
+
+## 8. Anti-Patterns
+
+| ❌ Don't | ✅ Do |
+|----------|-------|
+| Deploy on Friday | Deploy early in week |
+| Rush deployment | Follow the process |
+| Skip staging | Always test first |
+| Deploy without backup | Backup before deploy |
+| Walk away after deploy | Monitor for 15+ min |
+| Multiple changes at once | One change at a time |
+
+---
+
+## 9. Decision Checklist
+
+Before deploying:
+
+- [ ] **Platform-appropriate procedure?**
+- [ ] **Backup strategy ready?**
+- [ ] **Rollback plan documented?**
+- [ ] **Monitoring configured?**
+- [ ] **Team notified?**
+- [ ] **Time to monitor after?**
+
+---
+
+## 10. Best Practices
+
+1. **Small, frequent deploys** over big releases
+2. **Feature flags** for risky changes
+3. **Automate** repetitive steps
+4. **Document** every deployment
+5. **Review** what went wrong after issues
+6. **Test rollback** before you need it
+
+---
+
+> **Remember:** Every deployment is a risk. Minimize risk through preparation, not speed.

package/template/.agents/skills/deprecation-and-migration/SKILL.md

@@ -0,0 +1,206 @@
+---
+name: deprecation-and-migration
+description: Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.
+---
+
+# Deprecation and Migration
+
+## Overview
+
+Code is a liability, not an asset. Every line of code has ongoing maintenance cost — bugs to fix, dependencies to update, security patches to apply, and new engineers to onboard. Deprecation is the discipline of removing code that no longer earns its keep, and migration is the process of moving users safely from the old to the new.
+
+Most engineering organizations are good at building things. Few are good at removing them. This skill addresses that gap.
+
+## When to Use
+
+- Replacing an old system, API, or library with a new one
+- Sunsetting a feature that's no longer needed
+- Consolidating duplicate implementations
+- Removing dead code that nobody owns but everybody depends on
+- Planning the lifecycle of a new system (deprecation planning starts at design time)
+- Deciding whether to maintain a legacy system or invest in migration
+
+## Core Principles
+
+### Code Is a Liability
+
+Every line of code has ongoing cost: it needs tests, documentation, security patches, dependency updates, and mental overhead for anyone working nearby. The value of code is the functionality it provides, not the code itself. When the same functionality can be provided with less code, less complexity, or better abstractions — the old code should go.
+
+### Hyrum's Law Makes Removal Hard
+
+With enough users, every observable behavior becomes depended on — including bugs, timing quirks, and undocumented side effects. This is why deprecation requires active migration, not just announcement. Users can't "just switch" when they depend on behaviors the replacement doesn't replicate.
+
+### Deprecation Planning Starts at Design Time
+
+When building something new, ask: "How would we remove this in 3 years?" Systems designed with clean interfaces, feature flags, and minimal surface area are easier to deprecate than systems that leak implementation details everywhere.
+
+## The Deprecation Decision
+
+Before deprecating anything, answer these questions:
+
+```
+1. Does this system still provide unique value?
+   → If yes, maintain it. If no, proceed.
+
+2. How many users/consumers depend on it?
+   → Quantify the migration scope.
+
+3. Does a replacement exist?
+   → If no, build the replacement first. Don't deprecate without an alternative.
+
+4. What's the migration cost for each consumer?
+   → If trivially automated, do it. If manual and high-effort, weigh against maintenance cost.
+
+5. What's the ongoing maintenance cost of NOT deprecating?
+   → Security risk, engineer time, opportunity cost of complexity.
+```
+
+## Compulsory vs Advisory Deprecation
+
+| Type | When to Use | Mechanism |
+|------|-------------|-----------|
+| **Advisory** | Migration is optional, old system is stable | Warnings, documentation, nudges. Users migrate on their own timeline. |
+| **Compulsory** | Old system has security issues, blocks progress, or maintenance cost is unsustainable | Hard deadline. Old system will be removed by date X. Provide migration tooling. |
+
+**Default to advisory.** Use compulsory only when the maintenance cost or risk justifies forcing migration. Compulsory deprecation requires providing migration tooling, documentation, and support — you can't just announce a deadline.
+
+## The Migration Process
+
+### Step 1: Build the Replacement
+
+Don't deprecate without a working alternative. The replacement must:
+
+- Cover all critical use cases of the old system
+- Have documentation and migration guides
+- Be proven in production (not just "theoretically better")
+
+### Step 2: Announce and Document
+
+```markdown
+## Deprecation Notice: OldService
+
+**Status:** Deprecated as of 2025-03-01
+**Replacement:** NewService (see migration guide below)
+**Removal date:** Advisory — no hard deadline yet
+**Reason:** OldService requires manual scaling and lacks observability.
+            NewService handles both automatically.
+
+### Migration Guide
+1. Replace `import { client } from 'old-service'` with `import { client } from 'new-service'`
+2. Update configuration (see examples below)
+3. Run the migration verification script: `npx migrate-check`
+```
+
+### Step 3: Migrate Incrementally
+
+Migrate consumers one at a time, not all at once. For each consumer:
+
+```
+1. Identify all touchpoints with the deprecated system
+2. Update to use the replacement
+3. Verify behavior matches (tests, integration checks)
+4. Remove references to the old system
+5. Confirm no regressions
+```
+
+**The Churn Rule:** If you own the infrastructure being deprecated, you are responsible for migrating your users — or providing backward-compatible updates that require no migration. Don't announce deprecation and leave users to figure it out.
+
+### Step 4: Remove the Old System
+
+Only after all consumers have migrated:
+
+```
+1. Verify zero active usage (metrics, logs, dependency analysis)
+2. Remove the code
+3. Remove associated tests, documentation, and configuration
+4. Remove the deprecation notices
+5. Celebrate — removing code is an achievement
+```
+
+## Migration Patterns
+
+### Strangler Pattern
+
+Run old and new systems in parallel. Route traffic incrementally from old to new. When the old system handles 0% of traffic, remove it.
+
+```
+Phase 1: New system handles 0%, old handles 100%
+Phase 2: New system handles 10% (canary)
+Phase 3: New system handles 50%
+Phase 4: New system handles 100%, old system idle
+Phase 5: Remove old system
+```
+
+### Adapter Pattern
+
+Create an adapter that translates calls from the old interface to the new implementation. Consumers keep using the old interface while you migrate the backend.
+
+```typescript
+// Adapter: old interface, new implementation
+class LegacyTaskService implements OldTaskAPI {
+  constructor(private newService: NewTaskService) {}
+
+  // Old method signature, delegates to new implementation
+  getTask(id: number): OldTask {
+    const task = this.newService.findById(String(id));
+    return this.toOldFormat(task);
+  }
+}
+```
+
+### Feature Flag Migration
+
+Use feature flags to switch consumers from old to new system one at a time:
+
+```typescript
+function getTaskService(userId: string): TaskService {
+  if (featureFlags.isEnabled('new-task-service', { userId })) {
+    return new NewTaskService();
+  }
+  return new LegacyTaskService();
+}
+```
+
+## Zombie Code
+
+Zombie code is code that nobody owns but everybody depends on. It's not actively maintained, has no clear owner, and accumulates security vulnerabilities and compatibility issues. Signs:
+
+- No commits in 6+ months but active consumers exist
+- No assigned maintainer or team
+- Failing tests that nobody fixes
+- Dependencies with known vulnerabilities that nobody updates
+- Documentation that references systems that no longer exist
+
+**Response:** Either assign an owner and maintain it properly, or deprecate it with a concrete migration plan. Zombie code cannot stay in limbo — it either gets investment or removal.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "It still works, why remove it?" | Working code that nobody maintains accumulates security debt and complexity. Maintenance cost grows silently. |
+| "Someone might need it later" | If it's needed later, it can be rebuilt. Keeping unused code "just in case" costs more than rebuilding. |
+| "The migration is too expensive" | Compare migration cost to ongoing maintenance cost over 2-3 years. Migration is usually cheaper long-term. |
+| "We'll deprecate it after we finish the new system" | Deprecation planning starts at design time. By the time the new system is done, you'll have new priorities. Plan now. |
+| "Users will migrate on their own" | They won't. Provide tooling, documentation, and incentives — or do the migration yourself (the Churn Rule). |
+| "We can maintain both systems indefinitely" | Two systems doing the same thing is double the maintenance, testing, documentation, and onboarding cost. |
+
+## Red Flags
+
+- Deprecated systems with no replacement available
+- Deprecation announcements with no migration tooling or documentation
+- "Soft" deprecation that's been advisory for years with no progress
+- Zombie code with no owner and active consumers
+- New features added to a deprecated system (invest in the replacement instead)
+- Deprecation without measuring current usage
+- Removing code without verifying zero active consumers
+
+## Verification
+
+After completing a deprecation:
+
+- [ ] Replacement is production-proven and covers all critical use cases
+- [ ] Migration guide exists with concrete steps and examples
+- [ ] All active consumers have been migrated (verified by metrics/logs)
+- [ ] Old code, tests, documentation, and configuration are fully removed
+- [ ] No references to the deprecated system remain in the codebase
+- [ ] Deprecation notices are removed (they served their purpose)

package/template/.agents/skills/devflow/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: devflow
+description: Flagship interactive guide, intent router, workspace state inspector, and sitemap for Nexus-DevFlow workflows. Inspects current workspace state, maps natural language requests to matching stages/commands, and provides a cheat sheet of all available DevFlow skills. Use when the user runs /devflow, asks how to use devflow, asks what command to run next, or needs guidance on DevFlow lifecycle paths.
+---
+
+# devflow - Interactive Workflow Guide & Intent Router for Nexus-DevFlow
+
+Use this skill to guide the user on what to do next, inspect current workspace state, map their natural language intent to the right Nexus-DevFlow stage or companion command, or display a sitemap of available DevFlow skills.
+
+## Input
+
+- **No argument (`/devflow`)**: Inspect current workspace state (active run in `devflow/runs/` or `devflow/context/current-stage.md`, active discovery in `devflow/discoveries/`, open findings in `devflow/context/findings.md`, and project overview in `devflow/context/project-overview.md`) and recommend the exact next action.
+- **With user request (`/devflow "<request>"`)**: Classify the user's intent and guide them to the matching DevFlow 2.0 stage or companion command path.
+
+## Workspace State Inspection
+
+When invoked without an argument (or when determining the next step), inspect:
+
+1. **Active Delivery Run**: Read `devflow/context/current-stage.md` and check `devflow/runs/{RUNNING_ID}/` for active artifacts (`10-define.md`, `20-spec.md`, `30-plan.md`, `40-implement.md`, `50-verify.md`, `60-report.md`, `70-release.md`).
+2. **Active Discovery**: Check `devflow/discoveries/` for open discovery notes.
+3. **Audit Findings Ledger**: Check `devflow/context/findings.md` for open high-severity findings.
+4. **Project Overview**: Read `devflow/context/project-overview.md` for overall stack and context.
+
+### State-Based Recommendation Rules
+
+- If a run is at `10-define.md` -> Recommend `/20-spec {RUNNING_ID}`.
+- If a run is at `20-spec.md` -> Recommend `/30-plan {RUNNING_ID}`.
+- If a run is at `30-plan.md` -> Recommend `/40-implement {RUNNING_ID}`.
+- If a run is at `40-implement.md` with incomplete tasks -> Recommend `/40-implement {RUNNING_ID}`.
+- If a run is at `40-implement.md` with all tasks done -> Recommend `/50-verify {RUNNING_ID}`.
+- If a run passed `50-verify.md` -> Recommend `/60-report {RUNNING_ID}` then `/70-release {RUNNING_ID}`.
+- If no run is active and user wants to explore an idea -> Recommend `/00-discover` or `Brainstorm`.
+- If no run is active and open P0/P1 findings exist -> Recommend `Security-Review` or `Debug`.
+
+## Intent Classification & Skill Routing
+
+When the user specifies a request, map it to the matching DevFlow 2.0 stage or companion command:
+
+| User Intent / Request Type | Recommended Skill | Lifecycle Path |
+| --- | --- | --- |
+| "Explore a new request / idea" | `/00-discover` | `/00-discover` -> `/10-define` -> `/20-spec` -> ... |
+| "Define delivery boundaries and ID" | `/10-define` | `/10-define` -> `/20-spec` -> `/30-plan` |
+| "Write formal markdown specification" | `/20-spec` | `/20-spec` -> `/30-plan` -> `/40-implement` |
+| "Break down spec into actionable plan" | `/30-plan` | `/30-plan` -> `/40-implement` -> `/50-verify` |
+| "Execute code implementation" | `/40-implement` | `/40-implement` -> `/50-verify` |
+| "Verify code quality & QA review" | `/50-verify` | `/50-verify` -> `/60-report` -> `/70-release` |
+| "Generate summary HTML/MD report" | `/60-report` | `/60-report` -> `/70-release` |
+| "Package for PR merge or deployment" | `/70-release` | `/70-release` |
+| "High-level goal or long-running task" | `Goal` | `Goal` -> `/00-discover` |
+| "Brainstorm ideas without allocating ID" | `Brainstorm` | `Brainstorm` -> `/00-discover` |
+| "Deep codebase or web research" | `Research` | `Research` |
+| "Investigate failure or root cause" | `Debug` | `Debug` -> `/40-implement` or `/10-define` |
+| "Product framing & PRD creation" | `PRD` | `PRD` -> `/00-discover` |
+| "Intake and triage incoming bugs" | `Issue-Triage` | `Issue-Triage` -> `Debug` or `/10-define` |
+| "High-severity security audit" | `Security-Review` | `Security-Review` |
+| "Manage project knowledge base" | `Wiki` | `Wiki` |
+| "Verify or update DevFlow setup" | `Check-For-Updates` | `Check-For-Updates` |
+
+## Available Skills Sitemap
+
+Always provide a clean summary of available Nexus-DevFlow skills grouped by lifecycle stage:
+
+### 1. Mainline Lifecycle Stages (Linear Order)
+- `/00-discover` - Explore request, route inquiries, go/no-go under Discovery ID
+- `/10-define` - Lock delivery boundaries and allocate Running ID (`devflow/runs/{ID}`)
+- `/20-spec` - Formalize markdown-first specifications and acceptance criteria
+- `/30-plan` - Transform spec into executable task breakdown
+- `/40-implement` - Execute planned tasks incrementally with evidence
+- `/50-verify` - Senior QA review, validation checks, and pass/fail gate
+- `/60-report` - Generate standardized markdown and HTML summary report
+- `/70-release` - Package verified work for PR merge or deployment
+
+### 2. Public Companion Commands
+- `Goal` - Route broad goals before Discovery
+- `Brainstorm` - Ideate without allocating running IDs
+- `Research` - Conduct codebase or web research
+- `Debug` - Root cause investigation before or during implementation
+- `PRD` - Product framing before delivery commitment
+- `Issue-Triage` - Intake and triage incoming bug reports
+- `Security-Review` - High-severity security review
+- `Wiki` - Knowledge base management under `devflow/wiki/`
+- `Check-For-Updates` - Verify or upgrade DevFlow setup
+- `Help` - Process assistance and stage routing
+
+### 3. Engineering & Specialist Skills
+- **Frontend & UI**: `frontend-ui-engineering`, `nextjs-react-expert`, `tailwind-patterns`, `ui-ux-pro-max`, `mobile-design`
+- **Quality & Security**: `code-review-and-quality`, `security-and-hardening`, `test-driven-development`, `vulnerability-scanner`, `performance-optimization`
+- **Architecture & System**: `architecture`, `database-design`, `domain-modeling`, `codebase-design`, `api-and-interface-design`
+- **Tools & Productivity**: `md2html`, `obsidian-markdown`, `git-workflow-and-versioning`, `parallel-agents`, `context-engineering`

package/template/.agents/skills/devflow-concept-intake/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: devflow-concept-intake
+description: Studies external Git repositories, READMEs, prompt frameworks, agent workflows, and engineering-methodology repos before adapting ideas into Nexus-DevFlow. Use when the user asks to research a repo for DevFlow, compare concepts, decide what to adopt or reject, create an adoption proposal, write an option guide for coupled practices, or track upstream sources for adopted concepts.
+---
+
+# DevFlow Concept Intake
+
+## Overview
+
+Use this skill to turn external repo ideas into deliberate Nexus-DevFlow decisions. Study the source, critique the principles, discuss trade-offs with the user, then propose adoption only when the concept improves the workflow without unnecessary complexity.
+
+## Core Rule
+
+Do not import ideas just because they are interesting. Every concept must pass through critique, DevFlow fit analysis, and user discussion before it becomes a workflow, agent, skill, artifact, or option guide.
+
+## Core Process
+
+### 1. Source Intake
+
+Identify the source before judging it:
+
+- Record repo URL, README path, docs path, branch, commit, tag, or release when available.
+- Prefer primary source files: `README`, docs, examples, workflow definitions, prompts, CLI scripts, schemas, and changelog.
+- If the user gives only a summary, mark source confidence as `low` and ask for the repo/README before making durable recommendations.
+- Separate stated principles from inferred principles.
+
+For current or remote source facts, browse or fetch the source when tools allow it. Do not rely on memory for live repo state.
+
+### 2. Discussion-First Report
+
+Produce a direct critique before proposing implementation. Use `references/concept-report-template.md` when a written artifact is requested or the analysis is substantial.
+
+Classify each concept:
+
+| Decision | Meaning |
+| :--- | :--- |
+| `Adopt` | Fits DevFlow as-is and adds clear value. |
+| `Adapt` | Useful idea, but must be reshaped for DevFlow. |
+| `Reject` | Does not fit, adds avoidable risk, or conflicts with DevFlow goals. |
+| `Defer` | Potentially useful, but needs evidence, a real use case, or upstream maturity. |
+
+Be explicit about what not to take. A rejected idea is useful output, not a failure.
+
+### 3. Adoption Proposal
+
+Only create an adoption proposal after the user agrees the concept is worth exploring. Use `references/adoption-proposal-template.md`.
+
+Map the concept to the smallest fitting DevFlow surface:
+
+| Target | Use When |
+| :--- | :--- |
+| Workflow | The idea changes phase order, gates, or user-visible commands. |
+| Agent | The idea needs a specialist persona with a bounded responsibility. |
+| Skill | The idea is reusable guidance or a discipline layer inside existing workflows. |
+| Artifact | The idea needs persistent JSON or Markdown state. |
+| Option guide | The idea is useful only as an optional bundle of practices. |
+| Wiki/docs | The idea is knowledge, not behavior. |
+
+Prefer skill-backed or option-guide adoption before adding new slash workflows. Keep the canonical `/00-Discover -> /10-Define -> /20-Spec -> /30-Plan -> /40-Implement -> /50-Verify -> /60-Report -> /70-Release` path stable unless the concept improves a core invariant.
+
+### 4. Coupled Concepts And Option Packs
+
+When principles must be used together, do not scatter them across unrelated flows. Write them as an option pack:
+
+- Name the pack with the `devflow-*` prefix.
+- State which concepts are mandatory together and which are optional.
+- Define when to activate the pack.
+- Define what workflows, agents, skills, artifacts, and validation gates are affected.
+- Include an explicit "Do not use this option when..." section.
+
+Examples:
+
+- `devflow-upstream-sync-pack`: use only when adopting concepts that need regular upstream review.
+- `devflow-agent-discipline-pack`: use when multiple agent behavior rules must work together.
+- `devflow-research-to-adoption-pack`: use when repo study, proposal, and tracking must be chained.
+
+### 5. Upstream Tracking
+
+Track upstream only for concepts the user chooses to adopt or actively evaluate. Use `references/upstream-tracking-template.md`.
+
+Record:
+
+- Source repo and exact revision.
+- Adopted concepts and local DevFlow mapping.
+- Local files or workflows affected.
+- Update strategy: manual review, scheduled review, diff-based review, or no tracking.
+- Compatibility risk if upstream changes.
+- Credit and license notes when applicable.
+
+Do not promise automatic syncing unless the repository has a clear, testable transformation path. Prefer reviewable update notes over blind merges.
+
+## Fit Criteria
+
+Favor concepts that:
+
+- Reduce ambiguity in agent work.
+- Improve traceability, validation, or recovery.
+- Strengthen user-controlled phase gates.
+- Fit the markdown-first stage artifact contract.
+- Can be explained as a small rule, skill, option, or workflow addition.
+- Preserve source credit and make upstream drift visible.
+
+Reject or defer concepts that:
+
+- Add autonomous execution that skips human approval gates.
+- Require copying large frameworks wholesale.
+- Make core workflows harder to understand.
+- Depend on brittle prompt magic with no observable artifact.
+- Duplicate an existing DevFlow skill, agent, or workflow.
+- Create tracking burden without clear recurring value.
+
+## Output Expectations
+
+For lightweight discussion, answer in Thai or the user's language with:
+
+- Source studied.
+- Main principles found.
+- `Adopt / Adapt / Reject / Defer` table.
+- Direct critique.
+- Recommended next DevFlow action.
+
+For substantial work, produce one or more Markdown artifacts under an appropriate workspace path such as:
+
+```text
+devflow/research/devflow-concepts/{source-slug}/concept-report.md
+devflow/research/devflow-concepts/{source-slug}/adoption-proposal.md
+devflow/research/devflow-concepts/{source-slug}/upstream-tracking.md
+```
+
+Ask before writing files unless the user explicitly requested artifacts.
+
+## Red Flags
+
+- Summarizing the repo without giving a recommendation.
+- Treating upstream popularity as proof of DevFlow fit.
+- Proposing a new workflow when a skill or option guide is enough.
+- Omitting the "do not adopt" list.
+- Tracking every studied repo instead of only adopted or actively evaluated concepts.
+- Mixing source truth, interpretation, and local proposal in one undifferentiated document.
+
+## Verification
+
+Before finishing:
+
+- Confirm the source and revision confidence.
+- Confirm every major concept has `Adopt`, `Adapt`, `Reject`, or `Defer`.
+- Confirm rejected concepts and reasons are included.
+- Confirm any adoption proposal maps to a specific DevFlow surface.
+- Confirm coupled concepts are represented as an option pack.
+- Confirm upstream tracking exists only when adoption or active evaluation is chosen.

package/template/.agents/skills/devflow-concept-intake/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "DevFlow Concept Intake"
+  short_description: "Evaluate repo concepts for DevFlow adoption"
+  default_prompt: "Use $devflow-concept-intake to study this repo or README, critique the concepts, and propose whether Nexus-DevFlow should adopt, adapt, reject, or track them."