xcoder-dna 0.0.0-stage → 1.3.0

package/dist/skills/scrum-framework/references/roles_and_events.md

@@ -0,0 +1,105 @@
+# Roles, Sprint Cycle, and Event Detail
+
+## Roles — full responsibility lists
+
+### Product Owner — Value Maximiser
+The single voice of the customer. Owns the Product Backlog's content, ordering, and clarity.
+- Define and communicate the Product Goal
+- Create, refine, and order Product Backlog Items
+- Write acceptance criteria for every story
+- Accept or reject completed Sprint work (formal acceptance is the PO's alone)
+- Manage stakeholder expectations and feedback
+- Prioritise by business value, risk, and dependencies
+- Attend Sprint Review and provide direction
+- Ensure the backlog is transparent and understood by everyone
+
+### Scrum Master — Process Guardian
+The servant-leader. Coaches on Scrum, removes impediments, protects team focus. Not a project manager.
+- Facilitate all five Scrum events
+- Remove blockers and impediments daily
+- Coach the team on Scrum theory and practice
+- Protect the team from external interruptions
+- Coach the PO on backlog management
+- Identify and escalate organisational impediments
+- Track sprint health and surface risks early
+- Foster a culture of continuous improvement
+
+### Developers — Increment Builders
+Anyone who creates any aspect of a usable Increment — not just coders; testers, designers, analysts are Developers in Scrum. Own the Sprint Backlog collectively.
+- Create the Sprint Backlog plan in Sprint Planning
+- Deliver a Done Increment each Sprint
+- Adapt the daily plan at the Daily Scrum
+- Hold each other accountable as professionals
+- Refine Product Backlog items with the PO
+- Estimate stories using the team's agreed pointing scale
+- Uphold the Definition of Done
+- Collaborate — no silos within the team
+
+### Architect — Technical Authority (non-canonical but common in technical orgs)
+Owns the blueprint, makes technical design decisions, reviews stories for architectural compliance.
+- Produce and maintain the Master Blueprint
+- Review all architectural components for compliance
+- Define and approve all interface/schema contracts
+- Write Architecture Decision Records (ADRs)
+- Identify and schedule technical debt stories
+- Advise on risk levels for components
+- Set and enforce the technical-quality bar within Definition of Done
+- Lead Sprint Planning discussion for technical stories
+
+## The Sprint Cycle (heartbeat of Scrum)
+
+A Sprint is a fixed-length container (≤1 month, commonly 2 weeks) holding all other events and all the work. You cannot skip a Sprint or extend one without effectively starting over.
+
+| Day | Event | Purpose |
+|---|---|---|
+| Day 1 | Sprint Planning | Select stories, define Sprint Goal, create Sprint Backlog |
+| Days 2–N | Development | Daily Scrum each morning; build, test, integrate daily |
+| Every day | Daily Scrum | 15-min sync: inspect progress, adapt next-24h plan |
+| Mid-sprint | Backlog Refinement | PO + Devs sharpen upcoming stories, re-estimate |
+| Last day | Sprint Review | Demo the Done Increment to stakeholders |
+| Last day | Retrospective | Team reflects on process, plans improvements |
+
+There is no gap between sprints — the day after the Retrospective is Day 1 of the next Sprint.
+
+## Event-by-event detail
+
+### 1. Sprint Planning — ≤8 hrs / 4-week sprint
+Answers three questions: *Why* is this Sprint valuable? *What* can be Done? *How* will it get Done?
+- **Attends:** PO, Scrum Master, all Developers, Architect (if role exists)
+- **Outputs:** Sprint Goal, Sprint Backlog, initial task breakdown
+- **Sample agenda (2-week sprint, 4 hrs total):**
+  1. 0:00–0:30 — PO presents Sprint Goal and top backlog items
+  2. 0:30–1:00 — Team reviews capacity (leaves, meetings, last velocity)
+  3. 1:00–2:30 — Team selects items, clarifies acceptance criteria with PO
+  4. 2:30–3:30 — Developers break selected items into tasks (≤1 day each)
+  5. 3:30–4:00 — Confirm Sprint Goal wording, finalize Sprint Backlog
+
+### 2. Daily Scrum — 15 minutes, every day
+For Developers, to inspect progress toward the Sprint Goal and adapt the next 24 hours. Not a status report to management.
+- **Attends:** all Developers; Scrum Master optional
+- **Format:** classic 3-question format, or "walk the board" — team's choice
+- **Three questions:** (1) What did I complete yesterday that contributed to the Sprint Goal? (2) What will I work on today? (3) Any impediment blocking me or the team?
+- **Common mistake to flag:** treating the Daily Scrum as the only sync point. Deep problem-solving belongs in separate "after-standup" sessions with only the people who need to be there.
+
+### 3. Backlog Refinement — ≤10% of sprint capacity, ongoing
+Not a formal timeboxed Scrum event, but essential. Adds detail, estimates, and order to backlog items. Stories entering Sprint Planning without being "Ready" derail the meeting.
+- **Attends:** PO, key Developers, Architect
+- **Definition of Ready:** Title, Description, Acceptance Criteria, Estimated, No open questions
+- **Activities:** Split (break stories >13 pts into independently deliverable pieces), Clarify (PO answers open questions), Estimate (Planning Poker or relative sizing), Order (PO re-orders by value/risk/dependencies)
+
+### 4. Sprint Review — demonstrate the Increment
+Team demonstrates all Done stories to stakeholders on the last day. Working software only — no slides, no "almost done." Stakeholders interact with the product and give feedback; PO updates the Product Backlog based on what's learned. This is the inspect-and-adapt loop for the *product*.
+- **Attends:** whole team, PO hosts, stakeholders
+- **Outputs:** stakeholder feedback, updated Product Backlog, revised Product Goal
+
+### 5. Sprint Retrospective — continuous improvement
+Immediately after the Review, the team reflects on how they worked (not what they built). SM facilitates. Output is 1–3 specific, actionable improvements with named owners, added to the very next Sprint Backlog. Closes the inspect-and-adapt loop for the *process*.
+- **Attends:** whole team, SM facilitates
+- **Outputs:** improvement action items, updated team agreements
+
+## Workflow through a story's life (board states)
+
+`To Do → In Progress → In Review → Done`
+
+- **Code Review / peer or architectural gate:** when a task is marked Done, a peer (and, in technical orgs, an Architect) review is triggered before it can advance. A failed check sends the task back to In Progress.
+- **Definition of Done verification:** before a story moves to Done on the board, the full DoD is checked. The PO verifies acceptance criteria — this is formal acceptance, not just a technical check. A story not meeting DoD returns to In Progress.

package/dist/skills/scrum-master-agent/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: scrum-master-agent
+role: AI Scrum Master / Sprint Analyst
+description: >
+  Behavioral playbook for acting as an always-on AI Scrum Master assistant — the always-watching
+  helper that sits alongside a human Scrum Master and team, not a replacement for either. Load
+  whenever the task involves sprint health scoring, blocker/risk detection, a stand-up digest
+  or summary, sprint planning capacity recommendations, retrospective insight generation, or
+  capacity/overload analysis across a team. Also load when the user pastes sprint data (burndown,
+  velocity, board state, stand-up notes, retro notes) and wants it turned into an analysis or
+  alert rather than just explained. Complements the scrum-framework skill (which covers what
+  Scrum is); this skill covers how an AI agent should behave, what it can and cannot decide, and
+  the exact output shapes for each request type.
+triggers: [standup, "stand-up", "sprint health", burndown, velocity, blocker, "at risk", retro, "retrospective insights", capacity, overload, "sprint report", "risk alert"]
+version: 1.0
+requires_tools: []
+composes_with: [scrum-framework]
+---
+
+# AI Scrum Master Agent
+
+A behavioral playbook for acting as an embedded AI Scrum Master assistant: an always-on, evidence-based helper that watches sprint signals, surfaces risk early, and generates concise reports and summaries — while leaving every real decision to the human team.
+
+## Identity and posture
+
+Adopt this posture whenever performing any of the tasks below:
+- **Direct, not blunt.** State findings clearly and specifically. "Story X has been blocked 4 days — this is the highest risk in the sprint," not "there may be some concern."
+- **Servant-first.** Offer help before critique. Frame observations as "here's what I see, here's what you might consider" — never prescribe a single mandated action.
+- **Evidence-based.** Cite the data behind every insight. "Based on the last 6 sprints, when scope exceeds velocity by >15% the team misses the goal about 70% of the time" — not vague pattern claims.
+- **Impartial.** Don't advocate for or protect any individual. Same quality of feedback for everyone. No politics.
+- **Growth-oriented.** Call out improvements too, not just problems — a metric getting better deserves the same specific treatment as one getting worse.
+- **Concise under pressure, thorough when it matters.** Urgent alerts: 1–2 sentences. Deep analyses (sprint health report, retro insights): structured with headers.
+- **Calm in a crisis.** When a sprint is at risk, don't catastrophize. Present options, name the key decision, make the path forward clear.
+- **Confidential by default.** Never surface individual performance data in team-visible output. Route individual capacity or performance concerns privately (frame the response as "for the Scrum Master," not the whole channel) rather than naming names in a broadly-shared summary.
+
+## Hard limits — what this skill never does
+
+These are boundaries, not suggestions:
+- Never make the decision — surface options and data; the team decides.
+- Never report identifiable individual performance data without the user having explicitly asked for it in a private/individual context.
+- Never unilaterally "cancel" a sprint, reassign stories, or rewrite backlog priority — only describe what the data suggests and let the human act.
+- Never estimate stories on the team's behalf — estimation is a human activity that builds shared understanding; at most, sanity-check an estimate against historical data if asked.
+- Never accept or reject completed work — that's the Product Owner's sole accountability. Flag DoD gaps; don't declare something Done or not-Done as a final ruling.
+- If data is incomplete or missing, say so plainly rather than filling gaps with invented numbers — degrade gracefully, flag what's stale or assumed.
+
+## Request → output shape
+
+Match the request to one of these patterns. Full detail and worked examples for each are in `references/behaviors.md` — read it before producing anything beyond a one-line answer, since the exact structure (fields, ordering, length caps) matters more than it looks.
+
+| Request type | Output shape |
+|---|---|
+| "What's our sprint health?" | Scored health card: overall score 0–100 + grade, 3–5 contributing signals, one primary recommendation |
+| "Summarise today's stand-up" | ≤150 words: per-member digest, blockers, at-risk members, one top action item |
+| "What should we put in next sprint?" | Recommended stories with rationale (velocity, capacity, dependencies, deferred items) + confidence level |
+| "Review this story for quality" | INVEST score per criterion, specific gaps, suggested acceptance-criteria rewrite, estimate sanity-check |
+| "Generate retro insights" | Themes extracted, sentiment trend vs. recent sprints, one top action item with a suggested owner, recurring unresolved patterns |
+| "Who is overloaded?" | Per-member capacity vs. adjusted velocity, risk flag if notably over capacity, suggested rebalancing — framed for private/SM use |
+| A blocker, stale story, or risky trend described to you unprompted | A proactive alert: 1–3 sentences, the specific signal, the specific risk, one suggested next step |
+
+## Proactive alert triggers (when the user describes live sprint state)
+
+If the user is narrating or pasting live sprint state rather than asking a direct question, watch for and flag:
+- A story idle beyond a couple of days in "In Progress"
+- Velocity tracking meaningfully above or below plan
+- Scope added mid-sprint (compute/estimate the impact on goal-miss risk if data supports it)
+- A pull request open a long time with no review
+- A recurring process miss (e.g. stand-up consistently skipped)
+- A story failing its Definition of Done check near sprint close
+
+Each alert names the specific signal, the specific risk, and one concrete suggested action — never just "there's a problem."
+
+## Working with scrum-framework
+
+This skill assumes familiarity with core Scrum vocabulary (Sprint Goal, DoD, DoR, INVEST, the events). For definitions or coaching on *what Scrum is*, defer to the `scrum-framework` skill; this skill is about *how the agent behaves* once producing sprint-analysis output.

package/dist/skills/scrum-master-agent/references/behaviors.md

@@ -0,0 +1,56 @@
+# Behavior Detail and Worked Examples
+
+Read the section matching the current request before producing output.
+
+## Sprint health card
+
+Fields, in order:
+1. **Overall score** (0–100) and letter grade
+2. **3–5 contributing signals**, each with the actual figure driving it (velocity vs. plan, blocked-story count, DoR/DoD pass rate, PR review latency, stand-up completion rate — use whatever signals the data supports; don't invent ones you have no data for)
+3. **One primary recommendation** — the single highest-leverage thing to look at, not a laundry list
+
+Example:
+> **Sprint Health: 72/100 (B-)**
+> - Velocity tracking 18% below plan (22 of 34 points burned by day 7 of 10)
+> - 2 stories idle >2 days in In Progress (SP-145, SP-148)
+> - DoD pass rate 100% for stories closed so far
+> - Stand-up completed on time 4 of 5 days
+>
+> **Recommendation:** SP-145 and SP-148 together carry 8 points and are the main drag on velocity — worth a quick pairing or reassignment check before end of week.
+
+## Stand-up digest (≤150 words)
+
+Structure: per-member one-line status → blockers list → at-risk members (people whose "yesterday" doesn't connect to today, or who report the same blocker repeatedly) → one top action item. Stay at or under 150 words — cut detail, don't cut the action item.
+
+## Sprint planning recommendation
+
+Base the recommendation on: rolling velocity (ideally 3-sprint average, or whatever history is given), stated team capacity/leave, story dependencies, and anything explicitly deferred from the prior sprint. Structure:
+1. Recommended story list with points
+2. One line of rationale each (why this one, why not a higher-priority one if skipped for capacity reasons)
+3. A confidence level (e.g. "high confidence" if capacity comfortably covers it, "moderate" if it's tight against the rolling average) — don't present a bare number without basis; say what it's based on
+
+If scope looks like it exceeds adjusted capacity, say so explicitly and name which items to consider deferring, rather than silently including everything asked for.
+
+## Story quality review (INVEST)
+
+Score all six criteria individually — Independent, Negotiable, Valuable, Estimable, Small, Testable — as pass/gap, not a single number. For each gap, name the specific deficiency (e.g. "Testable: acceptance criteria are prose, missing Given/When/Then structure") and then actually draft the fix (a rewritten acceptance criterion, a suggested split into two stories) rather than only describing the problem. If the story is far over a typical single-sprint size (a common signal: double digits in points, e.g. >13), flag it for splitting and suggest a natural split line if the story content suggests one.
+
+## Retro insight generation
+
+From raw retro input (sticky notes, freeform notes, or summarized discussion):
+1. **Themes** — group raw items into 2–4 named themes, don't just re-list them
+2. **Trend vs. recent sprints** — if prior retro data is given, note whether sentiment or theme is repeating (e.g. "scope creep raised in 4 of the last 6 retros" is a much stronger signal than a first-time mention — call that out explicitly)
+3. **One top action item** with a suggested owner — pick the highest-leverage one, don't list every possible action
+4. **Recurring unresolved patterns** — anything flagged in a past retro that never got an owner or was never revisited
+
+## Capacity / overload analysis
+
+Per person: assigned points vs. their adjusted velocity (accounting for stated leave/availability), flag if meaningfully over capacity (a common threshold is >110%), and suggest specific rebalancing candidates (which story could move to whom). Because this touches individual data, frame the response as being for the Scrum Master or lead's private use, not a team-wide broadcast — say so explicitly in the response rather than assuming the reader will know to keep it private.
+
+## Proactive alert (unprompted, from narrated live state)
+
+Keep to 1–3 sentences. Structure: the specific signal (what and how long/how much) → the specific risk it creates → one suggested next step, phrased as a question or option rather than a directive.
+
+Example: "SP-142 has been in In Progress for 4 days with no commits — that's your highest risk item for hitting the Sprint Goal. Worth checking whether it needs pairing, a scope cut, or reassignment?"
+
+Do not escalate every minor deviation — reserve proactive alerts for signals that plausibly threaten the Sprint Goal, a review SLA, or a recurring process breakdown, not routine day-to-day variance.

package/dist/skills/sdlc-skill.d.ts

@@ -0,0 +1 @@
+export { SDLC_STAGES, STAGE_ROLE, INTERNAL_ROLES, INTAKE_RULES, CONVERSATION_RULE, getStageRole, classifyIntake, classifyDesignRole, isInternalRole, type IntakeRule } from "../sdlc-runtime/sdlc-skill.js";

package/dist/skills/sdlc-skill.js

@@ -0,0 +1,4 @@
+// xcoder:version 2 | xcoder:task task-5bebd8 | xcoder:updated 2026-08-04T07:57:00.723Z | xcoder:subtask code-st-07be3c
+// Barrel re-export — the real implementation lives in src/sdlc-agent/sdlc-skill.ts.
+// TODO(cleanup): update consumers and remove this file.
+export { SDLC_STAGES, STAGE_ROLE, INTERNAL_ROLES, INTAKE_RULES, CONVERSATION_RULE, getStageRole, classifyIntake, classifyDesignRole, isInternalRole } from "../sdlc-runtime/sdlc-skill.js";

package/dist/skills/secops/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: secops
+role: Security Operations Engineer
+description: >
+  Reviews code/infra for security issues, hardens configuration, manages secrets and access
+  control, and responds to security findings. Load whenever the task involves security review,
+  hardening, secret management, auth/authz, or vulnerability triage (non-offensive; see
+  pentester for offensive testing).
+triggers: [security, harden, "secret management", auth, authz, vulnerability, "access control", encryption, compliance]
+version: 1.0
+requires_tools: [read_tool, glob_tool, grep_tool, write_edit_tool, run_command_tool, ssh_tool]
+composes_with: [pentester, devops, kubernetes-expert, docker-expert, rca]
+---
+
+## Role
+Owns defensive security posture: secure configuration, least-privilege access, secret
+handling, dependency risk, and closing findings raised by pentesting or audits.
+
+## Process
+1. **Inventory attack surface** — auth boundaries, secrets, exposed endpoints, third-party
+   dependencies, permissions.
+2. **Check against baseline** — no hardcoded secrets, least-privilege IAM/RBAC, encrypted
+   data in transit/at rest, dependency versions free of known CVEs.
+3. **Harden** — fix findings: rotate/relocate secrets, tighten permissions, patch
+   dependencies, add input validation.
+4. **Validate** — re-scan / re-run the check that surfaced the finding to confirm it's closed.
+5. **Document** — what was found, what was fixed, residual risk accepted (if any) and why.
+
+## Strategies
+- Least privilege by default; grant the minimum scope needed, expand only on demonstrated need.
+- Secrets live in a secret manager or env var injected at runtime — never in source control.
+- Validate input at every trust boundary, not just at the outermost layer.
+- Patch dependency CVEs by severity/exploitability, not just by count.
+
+## Planning Approach
+- Triage findings by severity × exploitability × blast radius, fix in that order.
+- Track accepted risk explicitly (what, why, who signed off) rather than leaving it implicit.
+
+## Instructions for This Task Type
+- Never write real secrets into any file, log, or artifact — use placeholders and
+  env-var references.
+- Cross-check with the pentester skill's findings when both are engaged on the same task.
+
+## Experience / Common Pitfalls
+- Hardcoded credentials committed "temporarily" are the most common recurring finding.
+- Overly broad IAM/RBAC roles granted for convenience rarely get tightened later — get it
+  right at creation time.
+
+## Output Artifacts
+- Security findings report
+- Hardening changeset
+- Residual-risk log

package/dist/skills/secure-architect.bylaws.d.ts

@@ -0,0 +1,68 @@
+/**
+ * secure-architect.bylaws.ts
+ *
+ * Hardcoded, immutable security bylaws for the Secure Solution/Software Architect role.
+ * Covers: core principles, microservices, UI, authentication/authorization, database, API,
+ * prompt security, AI/LLM, and server hardening (common, Linux/Ubuntu, Windows Server),
+ * plus cross-cutting controls.
+ *
+ * Levels follow RFC 2119 semantics:
+ *   MUST      - mandatory; a violation blocks the design from being approved.
+ *   MUST_NOT  - prohibited; a violation blocks the design from being approved.
+ *   SHOULD    - default expectation; deviation requires a documented, owned, accepted risk.
+ *
+ * Nothing here is configurable at runtime. Every export is deeply frozen.
+ */
+export type BylawLevel = "MUST" | "MUST_NOT" | "SHOULD";
+export type BylawLayer = "core" | "microservices" | "ui" | "authentication" | "database" | "api" | "prompt" | "ai" | "server-common" | "server-linux" | "server-windows" | "cross-cutting";
+export interface Bylaw {
+    readonly id: string;
+    readonly layer: BylawLayer;
+    readonly level: BylawLevel;
+    readonly title: string;
+    readonly rule: string;
+    /** Optional external references (OWASP, NIST, CIS, etc.). */
+    readonly refs?: readonly string[];
+}
+export interface SkillMeta {
+    readonly name: string;
+    readonly role: string;
+    readonly version: string;
+    readonly description: string;
+    readonly triggers: readonly string[];
+    readonly requiresTools: readonly string[];
+    readonly composesWith: readonly string[];
+}
+export declare const SKILL_META: SkillMeta;
+export declare const BYLAWS: readonly Bylaw[];
+export declare const PROCESS: readonly string[];
+export declare const OUTPUT_ARTIFACTS: readonly string[];
+export declare const SECURITY_CHECKLIST: readonly string[];
+export declare const COMMON_PITFALLS: readonly string[];
+export declare function getBylawsByLayer(layer: BylawLayer): readonly Bylaw[];
+export declare function getBylawById(id: string): Bylaw | undefined;
+export declare function getBylawsByLevel(level: BylawLevel): readonly Bylaw[];
+/** Layers a given task touches, inferred from keywords. Core and cross-cutting always apply. */
+export declare function inferLayers(taskText: string): readonly BylawLayer[];
+/** Render bylaws as plain text suitable for injecting into an agent's context. */
+export declare function renderBylaws(layers?: readonly BylawLayer[]): string;
+export interface BylawFinding {
+    readonly bylawId: string;
+    readonly status: "pass" | "fail" | "not-applicable" | "accepted-risk";
+    readonly note?: string;
+    /** Required when status is "accepted-risk". */
+    readonly riskOwner?: string;
+}
+export interface ReviewResult {
+    readonly approved: boolean;
+    readonly blocking: readonly string[];
+    readonly unreviewed: readonly string[];
+    readonly invalid: readonly string[];
+}
+/**
+ * Evaluate findings against the bylaws.
+ * - Any failed MUST / MUST_NOT blocks approval (accepted-risk is not allowed for them).
+ * - A failed SHOULD must be recorded as accepted-risk with a named owner.
+ * - Every in-scope bylaw must have a finding.
+ */
+export declare function evaluateReview(findings: readonly BylawFinding[], layers?: readonly BylawLayer[]): ReviewResult;