adr
Write an Architecture Decision Record (ADR) for a feature — Context / Decision / Status / Consequences / Alternatives, filed as…
First-principles briefing from technical documents. Use when: understanding why decisions were made, onboarding to feature reasoning, reviewing decision chains, explaining doc from first principles. Not for: PM/CTO summary (use project-brief), pre-doc analysis (use
$ npx -y skills add sd0xdev/sd0x-dev-flow --skill fp-brief --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/fp-briefContext preview
The summary Claude sees to decide when to auto-load this skill.
First-principles briefing from technical documents. Use when: understanding why decisions were made, onboarding to feature reasoning, reviewing decision chains, explaining doc from first principles. Not for: PM/CTO summary (use project-brief), pre-doc analysis (use
name: fp-brief description: "First-principles briefing from technical documents. Use when: understanding why decisions were made, onboarding to feature reasoning, reviewing decision chains, explaining doc from first principles. Not for: PM/CTO summary (use project-brief), pre-doc analysis (use feasibility-study), code explanation (use codex-explain). Output: structured reasoning chain with sensitivity analysis." allowed-tools: Read, Grep, Glob, Write, Bash(node:*)
| Scenario | Alternative | |----------|------------| | PM/CTO executive summary (strip technical details) | `/project-brief` | | Pre-doc feasibility analysis (before writing spec) | `/feasibility-study` | | Code explanation at function/file level | `/codex-explain` | | Code architecture overview | `/code-explore` | | Simple document summary | Ask Claude directly |
/fp-brief <doc-path> [--depth brief|normal|deep] [--verify off|codex] [--output <path>] [--no-save]
| Flag | Default | Description | |------|---------|-------------| | `<doc-path>` | Required | Source markdown document path | | `--depth` | `normal` | Output detail level | | `--verify` | `off` | Independent Codex reasoning verification | | `--output` | Same dir, `-fp-brief.md` suffix | Custom output path | | `--no-save` | false | Print to stdout instead of file |
sequenceDiagram
participant U as User
participant S as /fp-brief
participant D as Source Doc
participant O as Output File
participant X as Codex (optional)
U->>S: /fp-brief <doc-path> [--depth] [--verify]
Note over S: Phase 1: Input Resolution
S->>S: Validate path (repo boundary)
S->>D: Read source document
S->>S: Redaction scan (fail-safe)
S->>S: Auto-detect format (hybrid)
Note over S: Phase 2: First-Principles Extraction
S->>S: Extract Root Problem (5-Why)
S->>S: Build Assumptions Register
S->>S: Build Reasoning Chain
S->>S: Build Alternative Rejection Log
S->>S: Build Decision Sensitivity
S->>S: Identify Open Unknowns
Note over S: Phase 3: Output Assembly
S->>O: Write *-fp-brief.md
alt --verify codex
S->>X: Independent reasoning verification
X-->>S: Verification Delta
S->>O: Append Verification Delta
end
S-->>U: Report complete1. **Path validation**: Normalize, reject `..` traversal, enforce repo boundary 2. **Read source document** 3. **Redaction scan**: High-confidence secret patterns → abort; medium → mask `[REDACTED]` 4. **Format auto-detection**: See `references/detection-rules.md` 5. **Select extraction template** based on detected format
See `references/extraction-guide.md` for section-by-section heuristics.
| Section | Core Question | |---------|--------------| | Root Problem | What fundamental truth makes this problem unavoidable? | | Assumptions Register | What are we taking for granted, and why? | | Reasoning Chain | How does each decision trace back to a principle? | | Alternative Rejection Log | Why do other approaches violate our principles? | | Decision Sensitivity | If assumption X breaks, which decisions collapse? | | Open Unknowns | What don't we know, and what should we find out? |
For long documents (>500 lines): split by `##` headings, extract per-section, merge + dedup.
1. Apply depth filter (section inclusion matrix) 2. Apply source citations (reference source doc section headings) 3. Apply Evidence Insufficient Rule — never fabricate content for thin sections 4. Write output file (or stdout if `--no-save` — which `--verify codex` rejects, see § Save Behavior) 5. If `--verify codex`: dispatch verification per `references/codex-verify-prompt.md`
| Level | Description | Sections Included | |-------|-------------|-------------------| | brief | Core reasoning only (~500 words max) | Root Problem (full), Assumptions (top 3), Reasoning Chain (key decisions), Sensitivity (top 3) | | normal | Full reasoning chain (~1500 words max) | All 6 sections with citations | | deep | Full chain + analysis (~2500 words max) | All 6 sections + challenge questions, evidence ratings, counterfactual analysis, risk-weighted unknowns |
Verification Delta (section 7) appears only when `--verify codex` is used, at any depth level.
**Length policy**: These are upper bounds, not targets. If source doc is thin, output will be shorter. The Evidence Insufficient Rule applies: `[Evidence insufficient — source doc lacks data for this section]`.
See `references/output-template.md` for full template.
# First-Principles Briefing: <title> > Source: <path> | Depth: <level> | Format: <type> | Generated: <timestamp> ## 1. Root Problem ## 2. Assumptions Register ## 3. Reasoning Chain ## 4. Alternative Rejection Log ## 5. Decision Sensitivity ## 6. Open Unknowns ## 7. Verification Delta (optional)
| Condition | Output Path | |-----------|------------| | Default | Same directory as source, `-fp-brief.md` suffix | | `--output <path>` | Specified path | | `--no-save` | stdout only, no file written. **Incompatible with `--verify codex`** — refuse the combination and say why: the verification prompt is built around `${OUTPUT_PATH}` and instructs Codex to `cat` that file, so with nothing on disk there is no subject to verify. Run them separately, or drop `--no-save` for the verified run |
Example: `docs/features/auth/2-tech-spec.md` → `docs/features/auth/2-tech-spec-fp-brief.md`
Language: English | 繁體中文 | 简体中文 | 日本語 | 한국어 | Español The harness layer for Claude Code. Let the model choose the path. Keep "done" verifiable. Full control plane on Claude Code. Skills-only distribution for Codex CLI and other compatible agents.
Repo: sd0xdev/sd0x-dev-flow
Write an Architecture Decision Record (ADR) for a feature — Context / Decision / Status / Consequences / Alternatives, filed as…
Architecture design and documentation. Produces 3-architecture.md with component diagrams, data flow, integration points, and architecture decisions. Reads…
Context-aware Q&A with auto context gathering. Use when: user has a quick question about codebase, git history, rules, docs, or skills during development. Not…
Industry best practices conformance audit with mandatory adversarial debate. Produces audit artifact: verdict (OK/WARN/FAIL) + gap roadmap + debate proof. Use…
Bug fix workflow. Use when: fixing bugs, resolving issues, regression fixes. Not for: new features (use feature-dev), understanding code (use code-explore).…
Bump package and plugin version in sync. Updates package.json, .claude-plugin/plugin.json, and install-state manifest to the same version. Use when: user says…