@jakkrichm/create-nexus-devflow 2.0.0

package/template/.agents/skills/red-team-tactics/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: red-team-tactics
+description: Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting.
+allowed-tools: Read, Glob, Grep
+---
+
+# Red Team Tactics
+
+> Adversary simulation principles based on MITRE ATT&CK framework.
+
+---
+
+## 1. MITRE ATT&CK Phases
+
+### Attack Lifecycle
+
+```
+RECONNAISSANCE → INITIAL ACCESS → EXECUTION → PERSISTENCE
+       ↓              ↓              ↓            ↓
+   PRIVILEGE ESC → DEFENSE EVASION → CRED ACCESS → DISCOVERY
+       ↓              ↓              ↓            ↓
+LATERAL MOVEMENT → COLLECTION → C2 → EXFILTRATION → IMPACT
+```
+
+### Phase Objectives
+
+| Phase | Objective |
+|-------|-----------|
+| **Recon** | Map attack surface |
+| **Initial Access** | Get first foothold |
+| **Execution** | Run code on target |
+| **Persistence** | Survive reboots |
+| **Privilege Escalation** | Get admin/root |
+| **Defense Evasion** | Avoid detection |
+| **Credential Access** | Harvest credentials |
+| **Discovery** | Map internal network |
+| **Lateral Movement** | Spread to other systems |
+| **Collection** | Gather target data |
+| **C2** | Maintain command channel |
+| **Exfiltration** | Extract data |
+
+---
+
+## 2. Reconnaissance Principles
+
+### Passive vs Active
+
+| Type | Trade-off |
+|------|-----------|
+| **Passive** | No target contact, limited info |
+| **Active** | Direct contact, more detection risk |
+
+### Information Targets
+
+| Category | Value |
+|----------|-------|
+| Technology stack | Attack vector selection |
+| Employee info | Social engineering |
+| Network ranges | Scanning scope |
+| Third parties | Supply chain attack |
+
+---
+
+## 3. Initial Access Vectors
+
+### Selection Criteria
+
+| Vector | When to Use |
+|--------|-------------|
+| **Phishing** | Human target, email access |
+| **Public exploits** | Vulnerable services exposed |
+| **Valid credentials** | Leaked or cracked |
+| **Supply chain** | Third-party access |
+
+---
+
+## 4. Privilege Escalation Principles
+
+### Windows Targets
+
+| Check | Opportunity |
+|-------|-------------|
+| Unquoted service paths | Write to path |
+| Weak service permissions | Modify service |
+| Token privileges | Abuse SeDebug, etc. |
+| Stored credentials | Harvest |
+
+### Linux Targets
+
+| Check | Opportunity |
+|-------|-------------|
+| SUID binaries | Execute as owner |
+| Sudo misconfiguration | Command execution |
+| Kernel vulnerabilities | Kernel exploits |
+| Cron jobs | Writable scripts |
+
+---
+
+## 5. Defense Evasion Principles
+
+### Key Techniques
+
+| Technique | Purpose |
+|-----------|---------|
+| LOLBins | Use legitimate tools |
+| Obfuscation | Hide malicious code |
+| Timestomping | Hide file modifications |
+| Log clearing | Remove evidence |
+
+### Operational Security
+
+- Work during business hours
+- Mimic legitimate traffic patterns
+- Use encrypted channels
+- Blend with normal behavior
+
+---
+
+## 6. Lateral Movement Principles
+
+### Credential Types
+
+| Type | Use |
+|------|-----|
+| Password | Standard auth |
+| Hash | Pass-the-hash |
+| Ticket | Pass-the-ticket |
+| Certificate | Certificate auth |
+
+### Movement Paths
+
+- Admin shares
+- Remote services (RDP, SSH, WinRM)
+- Exploitation of internal services
+
+---
+
+## 7. Active Directory Attacks
+
+### Attack Categories
+
+| Attack | Target |
+|--------|--------|
+| Kerberoasting | Service account passwords |
+| AS-REP Roasting | Accounts without pre-auth |
+| DCSync | Domain credentials |
+| Golden Ticket | Persistent domain access |
+
+---
+
+## 8. Reporting Principles
+
+### Attack Narrative
+
+Document the full attack chain:
+1. How initial access was gained
+2. What techniques were used
+3. What objectives were achieved
+4. Where detection failed
+
+### Detection Gaps
+
+For each successful technique:
+- What should have detected it?
+- Why didn't detection work?
+- How to improve detection
+
+---
+
+## 9. Ethical Boundaries
+
+### Always
+
+- Stay within scope
+- Minimize impact
+- Report immediately if real threat found
+- Document all actions
+
+### Never
+
+- Destroy production data
+- Cause denial of service (unless scoped)
+- Access beyond proof of concept
+- Retain sensitive data
+
+---
+
+## 10. Anti-Patterns
+
+| ❌ Don't | ✅ Do |
+|----------|-------|
+| Rush to exploitation | Follow methodology |
+| Cause damage | Minimize impact |
+| Skip reporting | Document everything |
+| Ignore scope | Stay within boundaries |
+
+---
+
+> **Remember:** Red team simulates attackers to improve defenses, not to cause harm.

package/template/.agents/skills/release-git-operations/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: release-git-operations
+description: Handle commit, pull request, merge, deployment, and changelog work around Release. Use when packaging verified work for sharing, integration, deployment, or release communication.
+---
+
+# Release Git Operations
+
+## Overview
+
+This skill groups release-adjacent git and deployment behavior that used to be spread across multiple companion workflows.
+
+It is the shared behavior layer behind:
+
+- `Commit`
+- `PR`
+- `Merge`
+- `Deploy`
+- `Changelog`
+
+## Related Foundation Skills
+
+This skill should reuse and align with:
+
+- `.agents/skills/git-workflow-and-versioning/SKILL.md`
+- `.agents/skills/shipping-and-launch/SKILL.md`
+- `.agents/skills/deployment-procedures/SKILL.md`
+
+## When to Use
+
+- After `/50-Verify` when verified work is ready for packaging
+- During `/70-Release` when the team needs commit, PR, merge, deployment, or changelog support after the report is already aligned
+- When release communication must be built from markdown-first stage artifacts
+
+## Supported Modes
+
+- `commit`
+- `pr`
+- `merge`
+- `deploy`
+- `changelog`
+
+## Process
+
+### 1. Confirm Release Context
+
+Read the minimum required artifacts:
+
+- `verify.md`
+- `release.md`
+- `report.md` when relevant
+- git state and repository policy when relevant
+
+### 2. Run The Appropriate Mode
+
+#### Commit
+
+- stage the intended scope
+- use disciplined commit messaging
+- preserve branch safety rules
+
+#### PR
+
+- build PR narrative from markdown-first artifacts
+- preserve repository template fidelity
+- route follow-up review work cleanly
+
+#### Merge
+
+- confirm verification and review gates are satisfied
+- integrate safely using repository policy
+- route conflicts back to implementation or follow-up
+
+#### Deploy
+
+- apply shipping and launch discipline
+- verify platform-specific readiness
+- keep rollback and health checks explicit
+
+#### Changelog
+
+- summarize user-facing changes from stage artifacts and git evidence
+- avoid leaking low-value internal detail
+
+### 3. Route Back
+
+- return to `/70-Release` when packaging is still in progress
+- return to `/60-Report` when communication is the remaining task
+- return to `/40-Implement`, `/50-Verify`, or `PR-Followup` if release blockers are discovered
+
+## Output
+
+Return:
+
+- mode executed
+- artifacts or git actions produced
+- risks, blockers, or follow-up needs
+- recommended next stage or companion command

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

@@ -0,0 +1,143 @@
+---
+name: research
+description: Research workflow
+---
+
+---
+description: Codebase and evidence research. Transitional compatibility path for the Research companion command in DevFlow 2.0.
+---
+
+# Research - Codebase And Evidence Exploration
+
+## Topic: $ARGUMENTS
+
+This file keeps its old numeric path for migration compatibility.
+
+In DevFlow 2.0, `Research` is a companion command, not a numbered mainline workflow. The operational behavior remains detailed so it can still function like the original research workflow.
+
+## Purpose
+
+Use `Research` to answer complex questions with code evidence, source material, and structured findings.
+
+Use it when:
+
+- facts are missing
+- source material must be collected
+- the codebase or external docs need deeper investigation
+- Discover, Define, or Spec cannot proceed confidently without evidence
+
+Use `prototype` when the fastest reliable evidence is a runnable throwaway experiment rather than more reading.
+
+Preferred DevFlow 2.0 pairing:
+
+- from `/00-Discover`
+- from `/10-Define`
+- from `/20-Spec`
+- from `/50-Verify` when validating a claim or implementation choice
+
+When invoked with a Discovery ID, link the research report to that discovery and return to `/00-Discover {discovery_id}` so Discover can synthesize the evidence and make the decision. Research must not allocate a Running ID.
+
+---
+
+## Internal Process
+
+You are an orchestrator. Your goal is to perform deep technical or evidence research while preserving the richer research UX from the original workflow.
+
+Apply prompt addon patterns when the topic matches:
+
+| Topic | Addon pattern | Output |
+| :--- | :--- | :--- |
+| External libraries, APIs, SDKs, services | `spec_researcher` | validated integration notes with sources and implementation constraints |
+| Competitors, alternatives, market gaps | `competitor_analysis` | competitor list, pain points, differentiator opportunities |
+| Completed implementation lessons | `insight_extractor` | reusable patterns, gotchas, file insights, recommendations |
+| API/database/browser validation | `mcp_tools/*` | available validation steps for the current IDE/tooling |
+
+### Phase 1: Query Decomposition
+
+- clarify the research question
+- classify whether the work is mainly codebase research, external research, or both
+- identify the evidence needed to answer it
+
+### Phase 2: Exploration
+
+- locate relevant code with file and line references
+- trace data flows, architecture, and integration points
+- gather external documentation and source material when needed
+- prioritize "what is" over "what should be"
+
+### Phase 3: Synthesis And Documentation
+
+- summarize key findings
+- separate facts from inference
+- record constraints, risks, and unanswered questions
+- save the durable research note to disk
+
+### Phase 4: Knowledge Management
+
+- if significant patterns or durable lessons are discovered, recommend recording them in `devflow/lessons.md` or `Wiki`
+
+## Output Format
+
+Save the full research note to `devflow/research/{date}-{slug}.md`.
+
+Before generating the report:
+
+1. Inspect `.agent/resources/schemas/research.template.md`
+2. Preserve its required headings and tables
+3. Replace placeholder text with concrete evidence
+4. Re-check the output against `research.template.md`, ensure required headings remain, and remove all placeholders before completion
+
+Return a concise chat summary plus a persistent report with:
+
+```markdown
+## Research Summary: [Topic]
+
+### Question
+[What needed to be answered]
+
+### Findings
+- [Finding 1]
+- [Finding 2]
+
+### Evidence
+- [file:line, source, or doc link]
+
+### Constraints And Risks
+- [Constraint]
+
+### Open Questions
+- [Question still unanswered]
+
+### Recommended Next Step
+- [What to do with this research]
+```
+
+## Examples
+
+```text
+Research auth patterns in the current codebase
+Research Stripe webhook handling constraints
+Research competitor onboarding flows
+Research whether this API version is compatible
+```
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Not a numbered stage
+- Typical entry points: `/00-Discover`, `/10-Define`, `/20-Spec`, `/30-Plan`
+- Typical handoff targets: return to the stage that asked for the evidence
+
+## Sources
+
+- `AGENTS.md`
+- `.agent/resources/schemas/research.template.md`
+- Related commands: `/00-Discover`, `/10-Define`, `/20-Spec`, `/30-Plan`, `Spec-Research`, `Agent`
+- Support skills: `prototype`, `spec-research`, `competitor-analysis`, `insight-capture`
+
+## Next Workflow Recommendation
+
+- Default: return to the stage that asked for evidence; for discovery-owned research this is `/00-Discover {discovery_id}`
+- Common routes: `/10-Define`, `/20-Spec`, `/30-Plan`, or `/50-Verify`
+- Alternate: `Brainstorm` if the research opens multiple strategic options
+

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

@@ -0,0 +1,55 @@
+---
+name: review
+description: Two-axis review for changed work. Use inside /50-Verify or /70-Release when a branch, PR, or work-in-progress diff needs standards and spec review.
+---
+
+# Review
+
+Use this support skill as one verification lane. `/50-Verify` owns validation evidence; this skill reviews a diff from two separate angles.
+
+## Axes
+
+- **Standards**: does the change follow documented repo conventions?
+- **Spec**: does the change implement the originating issue, PRD, spec, or stage artifact?
+
+Keep the axes separate so one does not hide the other.
+
+## Process
+
+1. Pin the fixed point.
+   - Use the user-supplied commit, branch, tag, or merge-base.
+   - If none is supplied, default to the active branch merge-base with `main` when available.
+   - Confirm the diff is non-empty.
+
+2. Identify the spec source.
+   - Prefer `devflow/runs/{ID}-*/20-spec.md`, `30-plan.md`, issue brief, PRD, or explicit user path.
+   - If no spec exists, mark the Spec axis as skipped.
+
+3. Identify standards sources.
+   - Look for repo docs such as `AGENTS.md`, `CONTRIBUTING.md`, coding standards, workflow docs, or stage contracts.
+
+4. Review standards.
+   - Cite the violated standard.
+   - Distinguish hard violations from judgment calls.
+   - Skip issues that tooling already enforces unless tooling is missing.
+
+5. Review spec.
+   - Report missing or partial requirements.
+   - Report scope creep.
+   - Report implemented behavior that appears wrong against the spec.
+
+6. Aggregate findings.
+   - Present `Standards` and `Spec` separately.
+   - Lead with concrete findings and file references.
+   - Record residual risk and skipped axes.
+
+## Output
+
+Return:
+
+- fixed point and diff scope
+- standards sources
+- spec source or skipped reason
+- findings by axis
+- worst issue per axis
+- recommended DevFlow route

package/template/.agents/skills/review-followup-routing/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: review-followup-routing
+description: Classify review comments, extend existing work safely, and route corrective or future work back into the right DevFlow 2.0 stage. Use for PR follow-up and post-review follow-up planning.
+---
+
+# Review Follow-up Routing
+
+## Overview
+
+This skill groups follow-up handling that used to be split across:
+
+- `PR-Followup`
+- `Followup`
+
+It keeps follow-up work attached to the right running ID without replacing the numbered mainline.
+
+## Related Foundation Assets
+
+This skill should reuse and align with:
+
+- `.agent/resources/schemas/pr_followup.template.md`
+- active stage markdown artifacts under `devflow/runs/{ID}-*/`
+
+## Supported Modes
+
+- `pr-followup`
+- `task-followup`
+
+## When to Use
+
+- after `PR-Review` when review comments need classification and response
+- after human feedback, QA, or release review when a task needs additional scoped work
+- when existing work should be extended instead of replaced
+
+## Process
+
+### 1. Load Current Context
+
+Read only the minimum needed:
+
+- existing running ID workspace artifacts
+- latest review comments, requested changes, or QA findings
+- current implementation or verification notes when relevant
+
+### 2. Classify The Follow-up
+
+Classify each item into a useful bucket such as:
+
+- fix now
+- already resolved
+- needs clarification
+- new scope follow-up
+- pre-existing issue
+- non-actionable
+
+For task follow-up, also classify the change shape:
+
+- extension
+- enhancement
+- integration
+- refinement
+- bug fix after review
+
+### 3. Preserve Existing History
+
+Extend existing markdown artifacts instead of replacing them:
+
+- keep current phases and completed work intact
+- append new phases, subtasks, notes, or decision logs
+- keep the same running ID unless the new scope truly deserves a separate work line
+
+### 4. Save Reusable Output
+
+For PR-centered follow-up, save a report under:
+
+```text
+devflow/reports/{date}-pr-followup-{ID}.md
+```
+
+Use `.agent/resources/schemas/pr_followup.template.md` when a formal report is required.
+
+For task follow-up, append the approved follow-up work directly into the relevant stage markdown files for the same running ID.
+
+### 5. Route Back
+
+- `/40-Implement` for immediate corrective work
+- `/50-Verify` when only verification needs another pass
+- `/10-Define` or `/20-Spec` when the follow-up becomes genuinely new scope
+
+## Output
+
+Return:
+
+- mode used
+- classification summary
+- what changes now versus later
+- where the follow-up was recorded
+- exact recommended next command

package/template/.agents/skills/roadmap-strategy/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: roadmap-strategy
+description: Create or refresh product roadmap direction using markdown-first discovery and roadmap artifacts. Use when strategic planning should stay outside the mainline but still follow DevFlow 2.0 contracts.
+---
+
+# Roadmap Strategy
+
+## Overview
+
+This skill is the shared behavior layer behind `Roadmap`.
+
+It replaces the older JSON-centered roadmap flow with a markdown-first strategy workflow that still preserves structured validation.
+
+## Related Assets
+
+This skill should reuse and align with:
+
+- `.agent/resources/schemas/roadmap_discovery.template.md`
+- `.agent/resources/schemas/roadmap.template.md`
+- `ROADMAP.md`
+
+## When to Use
+
+- when product direction, priority, or sequencing needs a dedicated roadmap pass
+- when competitor, PRD, research, or delivery insight should be consolidated into strategy
+- when roadmap work should stay outside the numbered mainline but still hand off cleanly into `PRD`, `/10-Define`, or `/20-Spec`
+
+## Canonical Artifacts
+
+Use markdown-first artifacts:
+
+- `devflow/roadmap/roadmap-discovery.md`
+- `ROADMAP.md`
+
+Optional supporting context may include:
+
+- `devflow/project_index.json` until project-index migration is fully complete
+- research notes
+- PRD outputs
+- release or insight notes
+
+## Process
+
+### 1. Load Current Strategy Context
+
+Read the minimum useful context:
+
+- existing `ROADMAP.md`
+- `devflow/roadmap/roadmap-discovery.md`
+- current research, competitor notes, PRD, or insights when relevant
+
+### 2. Refresh Discovery
+
+Capture:
+
+- project purpose
+- target users
+- current state
+- constraints
+- market context
+- known gaps
+
+Save discovery notes in `devflow/roadmap/roadmap-discovery.md` using the discovery template.
+
+### 3. Prioritize The Roadmap
+
+Group roadmap work into useful strategic buckets such as:
+
+- near-term improvements
+- medium-term bets
+- long-term bets
+- technical debt and platform readiness
+
+Keep priorities traceable to evidence from stage work, user feedback, competitor findings, or implementation insight.
+
+### 4. Save The Canonical Roadmap
+
+Update `ROADMAP.md` using `.agent/resources/schemas/roadmap.template.md`.
+
+Replace placeholder content fully and keep headings and tables intact so validation can inspect the roadmap structure.
+
+### 5. Route Back
+
+- `PRD` when product framing needs to deepen
+- `/10-Define` when roadmap decisions should become bounded work
+- `/20-Spec` when one item is ready for delivery contract work
+- `Brainstorm` when strategy is still too fuzzy to lock
+
+## Output
+
+Return:
+
+- what changed in discovery
+- what changed in the roadmap
+- priority rationale
+- validation result
+- the recommended next command