@elnora-ai/linear 1.0.1 → 2.0.0

package/references/workspace-projects.md

@@ -0,0 +1,56 @@
+# Workspace Projects — Documentation Template
+
+A schema you can fill in to document your projects per team. Pair this with `projects.json` (the machine-readable copy that the CLI consumes via `sync` and `context`).
+
+Load this file when you need full project context that doesn't fit on a `context --team` summary. Agents normally do not read it.
+
+## Projects by Team and Status
+
+### `<Team-1>`
+
+#### In Progress
+| Project | Priority | Lead | Purpose |
+|---------|----------|------|---------|
+| `<Project name>` | `<Urgent|High|Normal|Low>` | `<lead>` | `<one-line purpose>` |
+
+#### Planned
+| Project | Priority | Lead | Purpose |
+|---------|----------|------|---------|
+
+#### Backlog
+| Project | Priority | Lead | Purpose |
+|---------|----------|------|---------|
+
+#### Completed
+| Project | Priority | Lead | Purpose |
+|---------|----------|------|---------|
+
+#### Canceled
+| Project | Priority | Lead | Purpose |
+|---------|----------|------|---------|
+
+---
+
+### `<Team-2>`
+
+(same structure)
+
+---
+
+## Compliance workflow projects
+
+If you use the bundled compliance templates (see `template-index.md`), each template usually maps to its own project so the audit trail is easy to find. Typical names:
+
+- User Onboarding / Offboarding
+- Access Provisioning / Revocation / Reviews / Privileged Access
+- Standard / Significant / Major Changes
+- Security Incidents / Vulnerability Management / Pentest Remediation
+- Availability Incidents / Operational Requests
+- Root Cause Analysis / Lessons Learned / Corrective Actions
+- Internal Audits / Management Reviews
+- Risk Assessments / Vendor Assessments
+- AI Governance / Backup & DR Testing / Data Modifications
+
+---
+
+*Routing keywords: `workspace-routing.md` | Labels: `workspace-labels.md` | Run `elnora-linear sync all` to refresh the JSON references from Linear.*

package/references/workspace-routing.md

@@ -0,0 +1,58 @@
+# Workspace Routing
+
+Schema/template for documenting how your workspace's teams + projects + labels map to your work intake. Replace the examples below with your own workspace structure; populate `teams.json`, `projects.json`, and `label-policy.json` with the underlying machine-readable data.
+
+## Teams (example)
+
+| Team | Prefix | Use For |
+|------|--------|---------|
+| **Engineering** | ENG- | Customer-facing product code, features, bugs |
+| **Operations** | OPS- | Internal: tooling, compliance docs, HR, access management |
+| **Security** | SEC- | CVE/vulnerability remediation, pentest findings, incidents (not security features) |
+| **Customer Success** | CUS- | Customer support, onboarding, client feedback |
+
+## Routing Keywords (example)
+
+| Keywords | Route To |
+|----------|----------|
+| feature, bug, build, implement, develop, code, product, ship, api, ui | **Engineering** |
+| vulnerability, CVE, CodeQL, dependabot, pentest finding, patch, security incident | **Security** |
+| internal tooling, internal infrastructure, dev environment, plugin, marketplace, cli setup | **Operations** |
+| document, record, audit, review completed, change approved, compliance | **Operations** |
+| onboarding, offboarding, access provision, access revoke, quarterly review | **Operations** |
+| change request, policy change, procedure change, ISMS change | **Operations** |
+| internal audit, management review, corrective action, risk assessment | **Operations** |
+| AI use case, AI capability scope, model family change, foundation model swap, AI governance | **Operations** |
+| hr, admin, process improvement, team operations, company operations | **Operations** |
+| customer, support request, user reported, client feedback, customer onboarding | **Customer Success** |
+
+**Default:** Engineering
+
+## Project Keywords (schema)
+
+Each project belongs to a specific team. Document yours in `workspace-projects.md` and keep the underlying mapping in `projects.json`.
+
+| Project | Keywords | Team |
+|---------|----------|------|
+| `<Project name>` | `<keyword1>, <keyword2>, ...` | `<team>` |
+
+## State Mapping (example)
+
+| Project Status | Issue State |
+|----------------|-------------|
+| In Progress | Todo |
+| Planned | Todo |
+| Backlog | Backlog |
+
+(see `recommendedStateForStatus` in the CLI; this table is the human-readable version of that logic.)
+
+## Assignees
+
+Document your team's assignment rules here. Common patterns:
+
+- Map roles to default assignees (e.g. "platform code → Platform lead").
+- Rule of thumb: ASK the user for an assignee if not specified — defaults can silently route to the wrong person.
+
+---
+
+*Projects: `workspace-projects.md` | Labels: `workspace-labels.md` | Run `elnora-linear sync all` to refresh JSON references from Linear.*

package/schemas/label-policy.json

@@ -0,0 +1,72 @@
+{
+	"$schema": "https://json-schema.org/draft/2020-12/schema",
+	"$id": "https://github.com/Elnora-AI/elnora-linear/blob/main/schemas/label-policy.json",
+	"title": "Label Policy",
+	"description": "Per-team required-label rules. Read by `issues create`, `issues update`, and `context` to surface required labels + enforce them at write time. Keyed by team key.",
+	"type": "object",
+	"additionalProperties": false,
+	"properties": {
+		"$schema": { "type": "string" },
+		"_placeholder": { "type": "boolean", "const": true },
+		"_example": { "type": "boolean", "const": true },
+		"_populated_by": { "type": "string" },
+		"policies": {
+			"type": "object",
+			"description": "Map of team key → policy. Keys are uppercase Linear team keys (e.g. ENG).",
+			"patternProperties": {
+				"^[A-Z][A-Z0-9]*$": {
+					"type": "object",
+					"additionalProperties": false,
+					"required": ["name", "required", "allowedPrefixes"],
+					"properties": {
+						"name": {
+							"type": "string",
+							"minLength": 1,
+							"description": "Human-readable team name (informational; the key is canonical)."
+						},
+						"required": {
+							"type": "array",
+							"description": "List of required label-prefix groups; each group must be satisfied for a write to succeed.",
+							"items": {
+								"type": "object",
+								"additionalProperties": false,
+								"required": ["prefixes", "min"],
+								"properties": {
+									"prefixes": {
+										"type": "array",
+										"items": { "type": "string", "minLength": 1 },
+										"description": "Any label whose name starts with one of these prefixes counts toward this group."
+									},
+									"min": {
+										"type": "integer",
+										"minimum": 0,
+										"description": "Minimum total label count across the listed prefixes."
+									},
+									"max": {
+										"type": ["integer", "null"],
+										"description": "Maximum total count, or null for no upper bound."
+									},
+									"description": {
+										"type": "string",
+										"description": "Human-readable hint surfaced in error responses."
+									}
+								}
+							}
+						},
+						"allowedPrefixes": {
+							"type": "array",
+							"items": { "type": "string" },
+							"description": "Master list of label prefixes valid for this team. Used for grouping in context responses."
+						},
+						"requiresProject": {
+							"type": "boolean",
+							"description": "If true (default), every new issue on this team must have a project set; `issues create` exits 2 with a structured ProjectValidationError when --project is omitted. Set false to allow issues without a project. Teams with zero projects available auto-pass regardless. Bypass per-call with --skip-project-check."
+						}
+					}
+				}
+			},
+			"additionalProperties": false
+		}
+	},
+	"required": ["policies"]
+}

package/scripts/postinstall.mjs

@@ -0,0 +1,195 @@
+#!/usr/bin/env node
+// Postinstall hook for @elnora-ai/linear.
+//
+// Goal: after the user installs the package, automatically populate the
+// reference files (teams/projects/users/workflows) from their Linear workspace
+// so the agents and slash commands are personalised on first use — without
+// requiring a manual `elnora-linear sync all` step.
+//
+// Behaviour:
+//   - If no API key is reachable, print a friendly notice telling the user how
+//     to enable the sync. Never block the install.
+//   - If a key is reachable (LINEAR_API_KEY env var, or already saved in
+//     ~/.config/elnora-linear/.env), run `sync all` with a hard timeout.
+//     Network/API failures degrade to a printed notice.
+//   - Always exits 0. A postinstall hook that fails the install is worse than
+//     no postinstall hook at all.
+//
+// Escape hatches (set any of these to skip the auto-sync entirely):
+//   - ELNORA_LINEAR_SKIP_POSTINSTALL=1
+//   - CI=true                            (most CI systems set this)
+//   - npm_config_global=false            (local installs in a project)
+//
+// The "local install" skip prevents this from firing on every fresh
+// node_modules in CI builds, monorepo workspaces, Docker layer caches, etc.
+// Global installs (`npm install -g @elnora-ai/linear`) are the user-facing
+// path we want to personalise.
+
+import { spawn } from "node:child_process";
+import { existsSync, readFileSync } from "node:fs";
+import { homedir } from "node:os";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = dirname(__filename);
+const PACKAGE_ROOT = dirname(__dirname);
+const CLI_ENTRY = join(PACKAGE_ROOT, "dist", "cli.js");
+const ENV_FILE = join(homedir(), ".config", "elnora-linear", ".env");
+
+const SYNC_TIMEOUT_MS = 60_000;
+
+const ESC = "\x1b[";
+const useColor = () => process.stdout.isTTY && !process.env.NO_COLOR;
+const COLORS = {
+	dim: (s) => (useColor() ? `${ESC}2m${s}${ESC}0m` : s),
+	yellow: (s) => (useColor() ? `${ESC}33m${s}${ESC}0m` : s),
+	green: (s) => (useColor() ? `${ESC}32m${s}${ESC}0m` : s),
+	cyan: (s) => (useColor() ? `${ESC}36m${s}${ESC}0m` : s),
+};
+
+function log(line) {
+	process.stdout.write(`${line}\n`);
+}
+
+export function shouldSkip(env = process.env) {
+	if (env.ELNORA_LINEAR_SKIP_POSTINSTALL === "1") {
+		return "ELNORA_LINEAR_SKIP_POSTINSTALL=1 is set";
+	}
+	if (env.CI === "true" || env.CI === "1") {
+		return "running in CI";
+	}
+	// npm sets npm_config_global=true for `-g` installs. Anything else (a local
+	// install, a yarn workspace, a pnpm dep resolution) skips. Note: npm sets
+	// the env var as a literal string.
+	if (env.npm_config_global !== undefined && env.npm_config_global !== "true") {
+		return "not a global install";
+	}
+	return null;
+}
+
+export function findApiKey(env = process.env, envFile = ENV_FILE) {
+	const raw = env.LINEAR_API_KEY?.trim().replace(/^["']|["']$/g, "");
+	if (raw?.startsWith("lin_api_")) {
+		return { source: "env", value: raw };
+	}
+	if (existsSync(envFile)) {
+		try {
+			const content = readFileSync(envFile, "utf8");
+			for (const line of content.split("\n")) {
+				const match = line.match(/^LINEAR_API_KEY\s*=\s*(.+?)\s*$/);
+				if (match) {
+					const value = match[1].replace(/^["']|["']$/g, "");
+					if (value.startsWith("lin_api_")) {
+						return { source: envFile, value };
+					}
+				}
+			}
+		} catch {
+			// Unreadable env file — fall through to no-key.
+		}
+	}
+	return null;
+}
+
+function printNoKeyNotice() {
+	log("");
+	log(COLORS.yellow("⚠  elnora-linear: could not personalise your Linear agents."));
+	log("");
+	log("   No Linear API key was found, so the reference files");
+	log("   (teams, projects, users, workflows) were not populated from");
+	log("   your Linear workspace.");
+	log("");
+	log("   To finish setup:");
+	log(`     1. Get a key at ${COLORS.cyan("https://linear.app/settings/api")}`);
+	log(`     2. ${COLORS.cyan("export LINEAR_API_KEY=lin_api_...")}`);
+	log(`     3. ${COLORS.cyan("elnora-linear sync all")}`);
+	log("");
+	log(COLORS.dim("   (Skip this notice with ELNORA_LINEAR_SKIP_POSTINSTALL=1.)"));
+	log("");
+}
+
+function printFailureNotice(reason) {
+	log("");
+	log(COLORS.yellow("⚠  elnora-linear: auto-sync did not complete."));
+	log(`   ${reason}`);
+	log("");
+	log(`   You can rerun it any time: ${COLORS.cyan("elnora-linear sync all")}`);
+	log("");
+}
+
+function printSuccessNotice() {
+	log("");
+	log(COLORS.green("✓ elnora-linear: reference files populated from your Linear workspace."));
+	log(COLORS.dim("  (teams, projects, users, workflows — refresh any time with `elnora-linear sync all`.)"));
+	log("");
+}
+
+function runSync(apiKey, cliEntry = CLI_ENTRY, timeoutMs = SYNC_TIMEOUT_MS) {
+	return new Promise((resolve) => {
+		if (!existsSync(cliEntry)) {
+			resolve({ ok: false, reason: `CLI entry not found at ${cliEntry}` });
+			return;
+		}
+		const child = spawn(process.execPath, [cliEntry, "sync", "all", "--output", "json"], {
+			env: { ...process.env, LINEAR_API_KEY: apiKey },
+			stdio: ["ignore", "pipe", "pipe"],
+		});
+		let stderr = "";
+		child.stderr.on("data", (chunk) => {
+			stderr += chunk.toString();
+		});
+		// Drain stdout so the child doesn't block on a full pipe buffer.
+		child.stdout.on("data", () => {});
+
+		const timer = setTimeout(() => {
+			child.kill("SIGTERM");
+			resolve({ ok: false, reason: `sync timed out after ${timeoutMs / 1000}s` });
+		}, timeoutMs);
+
+		child.on("error", (err) => {
+			clearTimeout(timer);
+			resolve({ ok: false, reason: err.message });
+		});
+		child.on("exit", (code) => {
+			clearTimeout(timer);
+			if (code === 0) {
+				resolve({ ok: true });
+			} else {
+				const tail = stderr.trim().split("\n").slice(-3).join(" | ") || `exit ${code}`;
+				resolve({ ok: false, reason: tail });
+			}
+		});
+	});
+}
+
+async function main() {
+	if (shouldSkip()) {
+		// Silent on skip — postinstall noise during CI/local installs is annoying.
+		return;
+	}
+
+	const key = findApiKey();
+	if (!key) {
+		printNoKeyNotice();
+		return;
+	}
+
+	const result = await runSync(key.value);
+	if (result.ok) {
+		printSuccessNotice();
+	} else {
+		printFailureNotice(result.reason);
+	}
+}
+
+// Only run when invoked directly (not when imported by tests).
+const invokedDirectly = process.argv[1] && fileURLToPath(import.meta.url) === process.argv[1];
+if (invokedDirectly) {
+	main().catch((err) => {
+		// Truly defensive: any uncaught error must not fail the install.
+		printFailureNotice(err?.message ?? String(err));
+	});
+}
+
+export const _internal = { runSync, ENV_FILE, CLI_ENTRY };

package/skills/linear-workspace/SKILL.md

@@ -28,9 +28,11 @@ Router for Linear work. Dispatches to specialized agents or slash commands rathe
 | Refresh reference data from Linear | Slash command: `/linear-sync` |
 | Run the curator (collect signals from external sources) | Slash command: `/linear-curator-run` |
 
+For parallel work (e.g. 5 issues from 5 URLs), dispatch multiple agents in a single message — that's why they exist.
+
 ## First-run install
 
-1. Install the plugin: `/plugin marketplace add Elnora-AI/elnora-linear` then `/plugin install linear-workspace@elnora-linear`
+1. `/plugin marketplace add Elnora-AI/elnora-linear` then `/plugin install linear-workspace@elnora-linear`
 2. Make sure the `elnora-linear` CLI is on your PATH: `npm install -g @elnora-ai/linear`
 3. On your first Linear command, you'll be prompted for your Linear API key (get one at https://linear.app/settings/api). It's saved to `~/.config/elnora-linear/.env` (mode 0600).
 4. Populate the reference files: `/linear-sync` (runs `elnora-linear sync all` — fetches teams, projects, users, workflows in one batch).
@@ -40,13 +42,72 @@ Router for Linear work. Dispatches to specialized agents or slash commands rathe
 The plugin reads user-specific config from `~/.config/elnora-linear/` by default (override via `LINEAR_REFERENCES_DIR`):
 
 - `teams.json`, `projects.json`, `users.json`, `workflows.json` — populated by `/linear-sync`
-- `slack.json`, `repos.json`, `signal-sources.json` — populated manually in v0; interactive prompts coming in a future release
+- `slack.json`, `repos.json`, `signal-sources.json`, `label-policy.json` — populated manually (schemas in [`schemas/`](../../schemas/), examples in [`references/*.example.json`](../../references/))
 
 Run `elnora-linear sync verify` to see which are populated vs placeholder.
 
+## Dispatch prompt — what to include
+
+1. The user's raw request, verbatim
+2. Suspected team (let the agent confirm via `elnora-linear teams list`)
+3. Compliance flag (see below), if any
+4. Anything the user already specified (project, priority, assignee, due date)
+5. **If a URL appears anywhere in the request → dispatch to `linear-url-to-issues`**, not `linear-issue-creator`
+
+The agent handles searching for duplicates, label requirements, state matching, and asking the user about anything unclear.
+
+### Fast-path saves tokens
+
+The creator agent has a fast path that skips the dupe scan, project-status check, and reference reads when the dispatch already specifies team + project + priority + assignee + a clear novel title (and no compliance keywords). When you have all five, write them out explicitly in the prompt — the agent will detect the fast path and complete in roughly one CLI call instead of three.
+
+### Compliance flag
+
+If the request mentions any of: **incident, breach, vulnerability, CVE, pentest, penetration test, onboarding, offboarding, access provision/revoke, audit, SOC 2, change request, risk assessment, vendor review, backup test, RCA, lessons learned, DPA, DSR / data subject request** — say so in the dispatch prompt. The agent will load `references/template-index.md` and apply the matching template (`SEC-*`, `CHG-*`, `ACC-*`, `AUD-*`, `RSK-*`, `OPS-*`, `SLA-*`, `RCA-*`, `LRN-*`).
+
+### Model tiering — pass `model:` on the Agent dispatch
+
+Match the model to task complexity. The agent frontmatter sets the default; override per-dispatch when the task is clearly easier or harder. Haiku < Sonnet < Opus on cost AND token usage — Opus uses **more** tokens than Sonnet for the same task, not fewer. It's a quality escalation, never a token-saving move.
+
+| Task | Agent | Model | Why |
+|---|---|---|---|
+| Fast-path create (all fields explicit, no compliance) | `linear-issue-creator` | `haiku` | Mechanical CRUD, single CLI call |
+| Full-path create (ambiguous routing, dupe scan, compliance template) | `linear-issue-creator` | `sonnet` | Branching + judgment |
+| Single-field update (state, assignee, priority, label add) | `linear-issue-updater` | `haiku` | One CLI call, fixed flag |
+| Cross-team move, full description rewrite | `linear-issue-updater` | `sonnet` | Validates required labels across teams |
+| URL → issues extraction | `linear-url-to-issues` | `sonnet` | Real synthesis from unstructured content |
+| Issue completeness review | `linear-issue-reviewer` | `sonnet` | Reads description + comments + acceptance criteria |
+| Headless curator pass (scheduled) | `linear-state-curator` | `haiku` | Mechanical signal collection + tier dispatch |
+| Interactive curator dry-run / triage | `linear-state-curator` | `sonnet` | Reading curator-report.jsonl + judgment calls on MEDIUM queue |
+
+Don't reach for Opus by default. Sonnet handles every Linear task cleanly. Only escalate to Opus if Sonnet has *actually failed* on this task type (looped, produced wrong output, gave up). If the request mentions a compliance keyword, upgrade the creator to Sonnet automatically.
+
+### Dispatch prompt budget
+
+When the user request is fully specified, keep the dispatch prompt short — the agent already knows the playbook. Pass through:
+
+- The user's raw request, verbatim
+- Team / project / priority / assignee if explicit
+- Compliance flag if relevant
+
+Don't re-format the description, don't restate the playbook, don't tell the agent how to structure its output. A 100-token dispatch prompt is fine; a 500-token one wastes tokens with no quality gain.
+
+## Cold-start primitive
+
+For workflows that need team metadata up front (e.g. extracting N issues from a URL into one team), the parent should suggest the agent call `elnora-linear context --team "<Team>"` ONCE before iterating. The response contains projects with statuses, workflow states, the full label catalog grouped by prefix, the required-label policy, and active members — replacing four separate calls (`teams get` + `projects list --team` + `states list --team` + `labels list --team`) and eliminating every reference-file read.
+
+The CLI is the source of truth for label policy: `elnora-linear projects get` and `elnora-linear teams get` both return `requiredLabels` and `validStates` directly. `elnora-linear issues create` rejects invalid label combinations with a structured error (`missing`, `availableForPrefix`, `suggestedRetry`) so the agent can self-correct in one retry without reading any reference file.
+
 ## Safety guardrails
 
-- `bulk` and `cleanup` default to **dry-run**; they print what would change and require explicit `--yes` to commit
+- `bulk` and `cleanup` default to **dry-run** — they print what would change and require `--yes` to commit
 - `bulk` requires at least one of `--set-state` or `--add-comment` — refuses no-op invocations
 - `cleanup` defaults to `comment` action (least destructive); `close` / `cancel` are explicit opt-ins
-- `external_command` signal sources run user-configured commands with the user's privileges — only configure commands from sources the user trusts
+- `external_command` signal sources run user-configured commands with the user's privileges — only configure commands from sources you trust
+- Permanent deletes need an explicit `--yes` at the CLI layer — a prompt-injected agent cannot bypass it
+- Full guarantees and gated commands documented in [SAFETY.md](../../SAFETY.md)
+
+## Don't
+
+- Don't read reference `.md` files for label requirements — required-label policy is enforced server-side by the CLI
+- Don't run the create/update workflow inline. The agent owns it.
+- Don't pick a team without confirming via `elnora-linear teams list` or `references/teams.json`

package/templates/ACC-PRO-provision.md

@@ -0,0 +1,74 @@
+# ACC-PRO: Access Provisioning
+
+## Quick Reference
+- **SLA:** Same day
+- **Team:** *the team that owns this workflow in your workspace*
+- **Project:** Access Provisioning
+
+## Required Labels
+- `Type: feature`
+- `Account Setup` (7-day SLA)
+- `Layer: devops`
+
+## Issue Template
+```markdown
+## Access Provisioning Request
+
+**Request ID:** ACC-PRO-YYYY-XXX
+**Request Date:** [YYYY-MM-DD]
+**Required By Date:** [Start date - access cannot be granted earlier]
+
+## Employee/Contractor Information
+- **Name:** [Full name]
+- **Role/Title:** [Job title]
+- **Department:** [Department/Team]
+- **Manager:** [Manager name]
+- **Employment Type:** [Employee / Contractor]
+- **Start Date:** [YYYY-MM-DD]
+- **End Date:** [If contractor - YYYY-MM-DD]
+
+## HR Verification Checklist
+- [ ] Signed employment/contractor agreement received
+- [ ] IP agreement signed
+- [ ] Security policy acknowledgment signed
+- [ ] Background check complete (if applicable)
+
+## Access Requirements
+
+### System Access
+| System | Access Level | Justification | Data Owner Approval |
+|--------|--------------|---------------|---------------------|
+| Google Workspace | [Standard/Admin] | | [ ] |
+| GitHub | [Read/Write/Admin] | | [ ] |
+| AWS | [Specific roles] | | [ ] |
+| Linear | [Member/Admin] | | [ ] |
+| Slack | [Member] | | [ ] |
+| [Other] | | | [ ] |
+
+### Privileged Access (if any)
+[If elevated access needed, create linked ACC-PRV issue]
+
+## Segregation of Duties Check
+- [ ] Verified no conflicting access combinations
+- [ ] No violations of separation of duties policy
+
+## Approvals
+- [ ] HR verification complete: _________________ Date: _______
+- [ ] Manager approval: _________________ Date: _______
+- [ ] System owner approval(s) obtained
+
+## Provisioning Checklist
+- [ ] Google Workspace account created
+- [ ] Added to appropriate Google Groups
+- [ ] GitHub organization membership
+- [ ] AWS IAM user/role configured
+- [ ] MFA enrollment required/verified
+- [ ] Linear workspace access
+- [ ] Slack workspace access
+- [ ] Welcome email sent with access instructions
+- [ ] Security training assigned
+
+## Verification
+- [ ] User confirmed access working
+- [ ] Access logged in provisioning records
+```

package/templates/ACC-PRV-privileged.md

@@ -0,0 +1,66 @@
+# ACC-PRV: Privileged Access Request
+
+## Quick Reference
+- **SLA:** Same day
+- **Team:** *the team that owns this workflow in your workspace*
+- **Project:** Privileged Access
+
+## Required Labels
+- `Type: feature`
+- `Flag: security`
+- `Layer: devops`
+- `Access Request`
+
+## Issue Template
+```markdown
+## Privileged Access Request
+
+**Request ID:** ACC-PRV-YYYY-XXX
+**Request Date:** [YYYY-MM-DD]
+**Urgency:** [Urgent / Standard]
+
+## Requestor Information
+- **Name:** [Full name]
+- **Role:** [Job title]
+- **Department:** [Team]
+- **Manager:** [Manager name]
+
+## Access Details
+- **System:** [System requiring privileged access]
+- **Privilege Level:** [Specific privilege - admin, root, etc.]
+- **Current Access:** [What access user currently has]
+- **Requested Access:** [Specific new privileges needed]
+
+## Business Justification
+[Detailed explanation of why privileged access is needed]
+
+## Duration
+- **Access Type:** [Temporary / Permanent]
+- **Start Date:** [YYYY-MM-DD]
+- **End Date:** [YYYY-MM-DD or "Ongoing until role change"]
+- **Revocation Trigger:** [What event should trigger access removal]
+
+## Competency Verification
+- [ ] User has completed security training
+- [ ] User understands privileged access responsibilities
+- [ ] User acknowledges logging of all privileged actions
+
+## Security Requirements
+- [ ] MFA will be configured for privileged access
+- [ ] Access will be time-bound when possible
+- [ ] All privileged actions will be logged
+
+## Approvals
+- [ ] Manager approval: _________________ Date: _______
+- [ ] System owner approval: _________________ Date: _______
+- [ ] Security review (for admin/root): _________________ Date: _______
+
+## Provisioning
+- [ ] Privileged access configured
+- [ ] MFA verified active
+- [ ] User notified of access and responsibilities
+- [ ] Access logged in privileged account register
+
+## Review Schedule
+Next review date: [Date - privileged access reviewed quarterly]
+```