@jakkrichm/create-nexus-devflow 2.0.0

package/template/.agents/skills/devflow-concept-intake/references/adoption-proposal-template.md

@@ -0,0 +1,60 @@
+# Adoption Proposal Template
+
+Use this template for phase 2 after the user agrees a concept is worth exploring.
+
+```markdown
+# DevFlow Adoption Proposal: {concept-name}
+
+## Recommendation
+
+Adopt | Adapt | Defer
+
+## Why This Belongs In Nexus-DevFlow
+
+Explain the value in terms of DevFlow goals: clearer agent behavior, safer workflow gates, better artifacts, stronger validation, or reusable knowledge.
+
+## Target DevFlow Surface
+
+| Surface | Change |
+| :--- | :--- |
+| Workflow |  |
+| Agent |  |
+| Skill |  |
+| Artifact |  |
+| Option guide |  |
+| Wiki/docs |  |
+
+## Smallest Useful Version
+
+Describe the smallest change that proves the concept works inside DevFlow.
+
+## What Changes
+
+- Files or folders:
+- Commands or workflows:
+- Agent behavior:
+- Artifacts:
+- Validation:
+
+## What Does Not Change
+
+State core DevFlow behavior that must remain stable.
+
+## Option Pack
+
+Use this section only when concepts must be used together.
+
+- Pack name:
+- Required concepts:
+- Optional concepts:
+- Activation trigger:
+- Do not use when:
+
+## Risks And Rejection Criteria
+
+List reasons to stop or roll back.
+
+## Validation Plan
+
+List exact checks, scripts, docs review, or test tasks needed before considering adoption complete.
+```

package/template/.agents/skills/devflow-concept-intake/references/concept-report-template.md

@@ -0,0 +1,47 @@
+# Concept Report Template
+
+Use this template for phase 1: discussion-first repo or README study.
+
+```markdown
+# Concept Report: {source-name}
+
+## Source
+
+- Repo or document:
+- Revision, tag, branch, or date checked:
+- Files read:
+- Source confidence: high | medium | low
+
+## What The Source Is Trying To Do
+
+Summarize the source in plain language. Separate the project's stated goal from your inference.
+
+## Principles Found
+
+| Principle | Evidence | Interpretation |
+| :--- | :--- | :--- |
+|  |  |  |
+
+## Decision Matrix
+
+| Concept | Decision | Why | DevFlow Fit |
+| :--- | :--- | :--- | :--- |
+|  | Adopt |  |  |
+|  | Adapt |  |  |
+|  | Reject |  |  |
+|  | Defer |  |  |
+
+## Direct Critique
+
+State what is strong, what is weak, what is overbuilt, what is missing, and what should not be copied into Nexus-DevFlow.
+
+## Discussion Questions
+
+- 
+- 
+- 
+
+## Recommended Next Step
+
+Choose one: stop, discuss, write adoption proposal, create option pack, or track upstream.
+```

package/template/.agents/skills/devflow-concept-intake/references/upstream-tracking-template.md

@@ -0,0 +1,51 @@
+# Upstream Tracking Template
+
+Use this template for phase 3 only after the user chooses to adopt or actively evaluate a source concept.
+
+```markdown
+# Upstream Tracking: {source-name}
+
+## Source
+
+- Repo:
+- Upstream revision:
+- License:
+- Credit:
+- Date recorded:
+
+## Adopted Or Evaluated Concepts
+
+| Source Concept | Local DevFlow Mapping | Status |
+| :--- | :--- | :--- |
+|  |  | adopted | evaluating | rejected |
+
+## Local Integration Points
+
+- Workflows:
+- Agents:
+- Skills:
+- Artifacts:
+- Docs/wiki:
+- Scripts:
+
+## Update Strategy
+
+Choose one:
+
+- Manual review: revisit only when user asks.
+- Scheduled review: revisit on a calendar or release cadence.
+- Diff-based review: compare upstream changes against recorded revision.
+- No tracking: preserve credit, but do not follow upstream.
+
+## Compatibility Notes
+
+Explain what could break if upstream changes, and what local decisions intentionally diverge from upstream.
+
+## Review Checklist
+
+- [ ] Compare upstream README or docs against recorded revision.
+- [ ] Check whether adopted concepts changed meaning.
+- [ ] Check whether local DevFlow mapping is still valid.
+- [ ] Update adoption proposal or option guide if needed.
+- [ ] Preserve credit and license notes.
+```

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

@@ -0,0 +1,75 @@
+---
+name: devflow-wiki
+description: Use when creating, updating, linting, querying, or deciding whether to ingest Nexus-DevFlow framework or project wiki knowledge under devflow/wiki.
+---
+
+# DevFlow Wiki
+
+Use DevFlow Wiki to compile reusable knowledge from source artifacts into small, source-backed Markdown pages.
+
+## Core Rules
+
+- Treat wiki pages as compiled knowledge, not source truth.
+- Keep `framework` and `project` namespaces separate.
+- Include `## Sources` on every page.
+- Use `_drafts/` for generated or unreviewed project pages.
+- Prefer one focused page over broad rewrites.
+- Do not ingest noisy logs, unverified hypotheses, or routine edits with no reusable lesson.
+
+## Namespace Decision
+
+| Scope | Use For | Path |
+| :--- | :--- | :--- |
+| `framework` | DevFlow workflows, agents, commands, install behavior, output contracts, token/context rules | `devflow/wiki/framework/` |
+| `project` | Target project architecture, domain concepts, decisions, patterns, gotchas, task lessons | `devflow/wiki/project/` |
+
+Promote project pages to framework only when the lesson applies beyond one project.
+
+## Commands
+
+Initialize and maintain wiki pages through the documented markdown structure under `devflow/wiki/`. Do not rely on the retired PRP runtime for wiki commands.
+
+Use `Wiki {scope} ingest {source}` for workflow-level ingestion and route reporting.
+
+## Project Wiki Contract
+
+Every project wiki uses:
+
+```text
+devflow/wiki/project/
+|-- index.md
+|-- architecture/
+|-- decisions/
+|-- domain/
+|-- gotchas/
+|-- patterns/
+|-- tasks/
+|-- token-context/
+`-- _drafts/
+```
+
+Each published page should follow `.agent/resources/schemas/wiki_page.template.md`.
+
+## Ingest Heuristics
+
+Ingest when the source contains reusable knowledge:
+
+- verified QA evidence
+- confirmed root cause and prevention
+- durable project decision
+- stable architecture or domain concept
+- repeated gotcha or risk pattern
+- context/token optimization lesson
+
+Skip ingest when the source is one-off, unverified, noisy, or already represented in a focused page.
+
+## Output Expectation
+
+Always report:
+
+- pages created or updated
+- source artifacts used
+- lint result or remaining issue
+- next workflow recommendation
+- wiki update recommendation
+

package/template/.agents/skills/diagnosing-bugs/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: diagnosing-bugs
+description: Diagnosis loop for hard bugs and performance regressions. Use inside Debug, /40-Implement, or /50-Verify when behavior is broken, throwing, failing, flaky, or slow.
+---
+
+# Diagnosing Bugs
+
+Use this support skill when the active DevFlow owner needs a disciplined root-cause loop.
+
+Do not let this skill replace `Debug`, `/40-Implement`, or `/50-Verify`. It supplies the method; the owning workflow records the artifact.
+
+## Phase 1: Build A Tight Feedback Loop
+
+Before hypothesizing, create a command or repeatable action that can catch the exact symptom.
+
+Preferred loops:
+
+1. failing automated test
+2. CLI command with fixture input
+3. HTTP request or curl script
+4. browser automation
+5. captured trace replay
+6. throwaway harness
+7. property or stress loop
+8. bisection loop
+9. differential loop
+10. structured human-in-the-loop notes when automation is impossible
+
+The loop must be:
+
+- red-capable for the user's exact symptom
+- deterministic, or high-reproduction-rate for flaky bugs
+- fast enough to run repeatedly
+- runnable by an agent or explicitly documented when human input is required
+
+If no loop can be built, stop and ask for missing artifacts such as logs, HAR files, screen recordings, production access, or permission for temporary instrumentation.
+
+## Phase 2: Reproduce And Minimize
+
+Run the loop and confirm it reproduces the described symptom.
+
+Then minimize:
+
+- reduce inputs
+- reduce configuration
+- reduce steps
+- remove dependencies one at a time
+
+Stop minimizing only when every remaining element is load-bearing.
+
+## Phase 3: Hypothesize
+
+Write 3-5 ranked, falsifiable hypotheses.
+
+Each hypothesis must say:
+
+```text
+If <cause> is true, then <probe or change> should produce <observable result>.
+```
+
+Proceed with the best hypothesis when user input is unavailable, but keep the ranked list in the artifact.
+
+## Phase 4: Instrument
+
+Probe one variable at a time.
+
+- Prefer debugger or REPL inspection when available.
+- Use targeted logs only at boundaries that distinguish hypotheses.
+- Tag temporary logs with a unique prefix such as `[DEBUG-a4f2]`.
+- For performance bugs, establish a measurement baseline before changing code.
+
+## Phase 5: Fix And Guard
+
+When a correct test seam exists:
+
+1. Convert the minimized repro into a failing regression test.
+2. Watch it fail.
+3. Apply the fix.
+4. Watch it pass.
+5. Re-run the original feedback loop.
+
+If no correct seam exists, record that architecture finding and route to `codebase-design` or `/30-Plan` after the bug is fixed.
+
+## Phase 6: Cleanup And Post-Mortem
+
+Before reporting done:
+
+- original repro no longer reproduces
+- regression test passes, or missing test seam is documented
+- temporary debug instrumentation is removed
+- throwaway harnesses are deleted or clearly marked
+- root cause is recorded in the owning stage artifact
+- prevention follow-up is captured when useful

package/template/.agents/skills/documentation-and-adrs/SKILL.md

@@ -0,0 +1,278 @@
+---
+name: documentation-and-adrs
+description: Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.
+---
+
+# Documentation and ADRs
+
+## Overview
+
+Document decisions, not just code. The most valuable documentation captures the *why* — the context, constraints, and trade-offs that led to a decision. Code shows *what* was built; documentation explains *why it was built this way* and *what alternatives were considered*. This context is essential for future humans and agents working in the codebase.
+
+## When to Use
+
+- Making a significant architectural decision
+- Choosing between competing approaches
+- Adding or changing a public API
+- Shipping a feature that changes user-facing behavior
+- Onboarding new team members (or agents) to the project
+- When you find yourself explaining the same thing repeatedly
+
+**When NOT to use:** Don't document obvious code. Don't add comments that restate what the code already says. Don't write docs for throwaway prototypes.
+
+## Architecture Decision Records (ADRs)
+
+ADRs capture the reasoning behind significant technical decisions. They're the highest-value documentation you can write.
+
+### When to Write an ADR
+
+- Choosing a framework, library, or major dependency
+- Designing a data model or database schema
+- Selecting an authentication strategy
+- Deciding on an API architecture (REST vs. GraphQL vs. tRPC)
+- Choosing between build tools, hosting platforms, or infrastructure
+- Any decision that would be expensive to reverse
+
+### ADR Template
+
+Store ADRs in `docs/decisions/` with sequential numbering:
+
+```markdown
+# ADR-001: Use PostgreSQL for primary database
+
+## Status
+Accepted | Superseded by ADR-XXX | Deprecated
+
+## Date
+2025-01-15
+
+## Context
+We need a primary database for the task management application. Key requirements:
+- Relational data model (users, tasks, teams with relationships)
+- ACID transactions for task state changes
+- Support for full-text search on task content
+- Managed hosting available (for small team, limited ops capacity)
+
+## Decision
+Use PostgreSQL with Prisma ORM.
+
+## Alternatives Considered
+
+### MongoDB
+- Pros: Flexible schema, easy to start with
+- Cons: Our data is inherently relational; would need to manage relationships manually
+- Rejected: Relational data in a document store leads to complex joins or data duplication
+
+### SQLite
+- Pros: Zero configuration, embedded, fast for reads
+- Cons: Limited concurrent write support, no managed hosting for production
+- Rejected: Not suitable for multi-user web application in production
+
+### MySQL
+- Pros: Mature, widely supported
+- Cons: PostgreSQL has better JSON support, full-text search, and ecosystem tooling
+- Rejected: PostgreSQL is the better fit for our feature requirements
+
+## Consequences
+- Prisma provides type-safe database access and migration management
+- We can use PostgreSQL's full-text search instead of adding Elasticsearch
+- Team needs PostgreSQL knowledge (standard skill, low risk)
+- Hosting on managed service (Supabase, Neon, or RDS)
+```
+
+### ADR Lifecycle
+
+```
+PROPOSED → ACCEPTED → (SUPERSEDED or DEPRECATED)
+```
+
+- **Don't delete old ADRs.** They capture historical context.
+- When a decision changes, write a new ADR that references and supersedes the old one.
+
+## Inline Documentation
+
+### When to Comment
+
+Comment the *why*, not the *what*:
+
+```typescript
+// BAD: Restates the code
+// Increment counter by 1
+counter += 1;
+
+// GOOD: Explains non-obvious intent
+// Rate limit uses a sliding window — reset counter at window boundary,
+// not on a fixed schedule, to prevent burst attacks at window edges
+if (now - windowStart > WINDOW_SIZE_MS) {
+  counter = 0;
+  windowStart = now;
+}
+```
+
+### When NOT to Comment
+
+```typescript
+// Don't comment self-explanatory code
+function calculateTotal(items: CartItem[]): number {
+  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
+}
+
+// Don't leave TODO comments for things you should just do now
+// TODO: add error handling  ← Just add it
+
+// Don't leave commented-out code
+// const oldImplementation = () => { ... }  ← Delete it, git has history
+```
+
+### Document Known Gotchas
+
+```typescript
+/**
+ * IMPORTANT: This function must be called before the first render.
+ * If called after hydration, it causes a flash of unstyled content
+ * because the theme context isn't available during SSR.
+ *
+ * See ADR-003 for the full design rationale.
+ */
+export function initializeTheme(theme: Theme): void {
+  // ...
+}
+```
+
+## API Documentation
+
+For public APIs (REST, GraphQL, library interfaces):
+
+### Inline with Types (Preferred for TypeScript)
+
+```typescript
+/**
+ * Creates a new task.
+ *
+ * @param input - Task creation data (title required, description optional)
+ * @returns The created task with server-generated ID and timestamps
+ * @throws {ValidationError} If title is empty or exceeds 200 characters
+ * @throws {AuthenticationError} If the user is not authenticated
+ *
+ * @example
+ * const task = await createTask({ title: 'Buy groceries' });
+ * console.log(task.id); // "task_abc123"
+ */
+export async function createTask(input: CreateTaskInput): Promise<Task> {
+  // ...
+}
+```
+
+### OpenAPI / Swagger for REST APIs
+
+```yaml
+paths:
+  /api/tasks:
+    post:
+      summary: Create a task
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/CreateTaskInput'
+      responses:
+        '201':
+          description: Task created
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/Task'
+        '422':
+          description: Validation error
+```
+
+## README Structure
+
+Every project should have a README that covers:
+
+```markdown
+# Project Name
+
+One-paragraph description of what this project does.
+
+## Quick Start
+1. Clone the repo
+2. Install dependencies: `npm install`
+3. Set up environment: `cp .env.example .env`
+4. Run the dev server: `npm run dev`
+
+## Commands
+| Command | Description |
+|---------|-------------|
+| `npm run dev` | Start development server |
+| `npm test` | Run tests |
+| `npm run build` | Production build |
+| `npm run lint` | Run linter |
+
+## Architecture
+Brief overview of the project structure and key design decisions.
+Link to ADRs for details.
+
+## Contributing
+How to contribute, coding standards, PR process.
+```
+
+## Changelog Maintenance
+
+For shipped features:
+
+```markdown
+# Changelog
+
+## [1.2.0] - 2025-01-20
+### Added
+- Task sharing: users can share tasks with team members (#123)
+- Email notifications for task assignments (#124)
+
+### Fixed
+- Duplicate tasks appearing when rapidly clicking create button (#125)
+
+### Changed
+- Task list now loads 50 items per page (was 20) for better UX (#126)
+```
+
+## Documentation for Agents
+
+Special consideration for AI agent context:
+
+- **CLAUDE.md / rules files** — Document project conventions so agents follow them
+- **Spec files** — Keep specs updated so agents build the right thing
+- **ADRs** — Help agents understand why past decisions were made (prevents re-deciding)
+- **Inline gotchas** — Prevent agents from falling into known traps
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "The code is self-documenting" | Code shows what. It doesn't show why, what alternatives were rejected, or what constraints apply. |
+| "We'll write docs when the API stabilizes" | APIs stabilize faster when you document them. The doc is the first test of the design. |
+| "Nobody reads docs" | Agents do. Future engineers do. Your 3-months-later self does. |
+| "ADRs are overhead" | A 10-minute ADR prevents a 2-hour debate about the same decision six months later. |
+| "Comments get outdated" | Comments on *why* are stable. Comments on *what* get outdated — that's why you only write the former. |
+
+## Red Flags
+
+- Architectural decisions with no written rationale
+- Public APIs with no documentation or types
+- README that doesn't explain how to run the project
+- Commented-out code instead of deletion
+- TODO comments that have been there for weeks
+- No ADRs in a project with significant architectural choices
+- Documentation that restates the code instead of explaining intent
+
+## Verification
+
+After documenting:
+
+- [ ] ADRs exist for all significant architectural decisions
+- [ ] README covers quick start, commands, and architecture overview
+- [ ] API functions have parameter and return type documentation
+- [ ] Known gotchas are documented inline where they matter
+- [ ] No commented-out code remains
+- [ ] Rules files (CLAUDE.md etc.) are current and accurate

package/template/.agents/skills/domain-modeling/ADR-FORMAT.md

@@ -0,0 +1,47 @@
+# ADR Format
+
+ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, and so on.
+
+Create the `docs/adr/` directory lazily, only when the first ADR is needed.
+
+## Template
+
+```md
+# {Short title of the decision}
+
+{1-3 sentences: what is the context, what did we decide, and why.}
+```
+
+That is enough for many ADRs. The value is in recording that a decision was made and why, not in filling out sections.
+
+## Optional Sections
+
+Only include these when they add genuine value:
+
+- Status frontmatter: `proposed`, `accepted`, `deprecated`, or `superseded by ADR-NNNN`
+- Considered Options: only when the rejected alternatives are worth remembering
+- Consequences: only when non-obvious downstream effects need to be called out
+
+## Numbering
+
+Scan `docs/adr/` for the highest existing number and increment by one.
+
+## When To Offer An ADR
+
+All three of these must be true:
+
+1. Hard to reverse: the cost of changing your mind later is meaningful.
+2. Surprising without context: a future reader will wonder why the decision was made.
+3. Based on a real trade-off: there were genuine alternatives and one was chosen for specific reasons.
+
+If a decision is easy to reverse, skip it. If it is not surprising, nobody will need the explanation. If there was no real alternative, there is nothing to record beyond doing the obvious thing.
+
+## What Qualifies
+
+- Architectural shape, such as monorepo structure or event-sourced write models.
+- Integration patterns between contexts.
+- Technology choices that carry lock-in, such as database, message bus, auth provider, or deployment target.
+- Boundary and scope decisions.
+- Deliberate deviations from the obvious path.
+- Constraints not visible in the code.
+- Rejected alternatives when the rejection is non-obvious.