Skip to content
Back to skills

Tech Brief

ASecurity

Technical briefing for developer sharing. Use when: sharing implementation findings with technical colleagues, post-development knowledge transfer, documenting what was built and why. Not for: PM/CTO summary (use project-brief), first-principles reasoning (use fp-brief), design-phase specs (use tech-spec). Output: 6-section technical brief with source provenance.

  • 191 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added May 27, 2026
developmentbashnodegitapisecurity

Works with

  • cli
  • api

Security analysis

A100/100

Pro scans all 3 files and shows the line behind each finding

Scanned May 27, 2026

npx -y skills add sd0xdev/sd0x-dev-flow --skill tech-brief --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Tech Brief?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Tech Brief
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/sd0xdev-tech-brief/badge)](https://www.skillsdirectory.com/skills/sd0xdev-tech-brief)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: tech-brief
description: "Technical briefing for developer sharing. Use when: sharing implementation findings with technical colleagues, post-development knowledge transfer, documenting what was built and why. Not for: PM/CTO summary (use project-brief), first-principles reasoning (use fp-brief), design-phase specs (use tech-spec). Output: 6-section technical brief with source provenance."
allowed-tools: Read, Grep, Glob, Write, Bash(git:*), Bash(node:*)
---

# Technical Briefing Skill

## Trigger

- Keywords: tech brief, technical briefing, share with team, tech-brief, dev sharing, share findings, technical memo

## When NOT to Use

| Scenario | Alternative |
|----------|------------|
| PM/CTO executive summary (strip technical details) | `/project-brief` |
| First-principles reasoning chain (why decisions were made) | `/fp-brief` |
| Design-phase technical specification (before implementation) | `/tech-spec` |
| Code explanation at function/file level | `/codex-explain` |
| Simple document summary | Ask Claude directly |

## Command Signature

```
/tech-brief [<feature-key>|<docs-path>] [--depth brief|normal|deep] [--output <path>] [--no-save]
```

| Flag | Default | Description |
|------|---------|-------------|
| `<feature-key>` | Auto-detect | Feature key or docs path |
| `--depth` | `normal` | Output depth (brief/normal/deep) |
| `--output` | `docs/features/<key>/5-tech-brief.md` | Custom output path |
| `--no-save` | false | Print to stdout only |

## Workflow

```mermaid
sequenceDiagram
    participant U as User
    participant S as /tech-brief
    participant FR as feature-resolver.js
    participant D as Feature Docs
    participant G as Git History
    participant C as Changed Files
    participant O as Output File

    U->>S: /tech-brief [feature] [--depth] [--output]
    Note over S: Phase 1: Context Resolution
    S->>FR: Resolve feature (5-level cascade)
    FR-->>S: Feature key + doc inventory
    Note over S: Phase 2: Multi-Source Collection
    S->>D: Stage 1 — Read docs (tech-spec, architecture, requests)
    S->>G: Stage 2 — git log + diff + changed file reading
    S->>D: Stage 3 — Request selection (top 3 by date)
    Note over S: Phase 3: Synthesis
    S->>S: Build Source Provenance table
    S->>S: Extract & organize by output template
    S->>S: Apply depth filter
    Note over S: Phase 4: Output
    S->>O: Write tech-brief file
    S-->>U: Report complete
```

### Phase 1: Context Resolution

1. Parse `$ARGUMENTS` for feature-key, path, or flags
2. Resolve feature using `node scripts/resolve-feature-cli.js [--feature <key>]`
3. Load `doc_inventory` and `canonical_docs` from resolver output
4. Validate paths (see Path Security)

#### Input Resolution Table

| Input Type | Example | Feature Resolution | Default Output Path |
|-----------|---------|-------------------|-------------------|
| Feature key | `/tech-brief fp-brief` | `--feature fp-brief` | `docs/features/fp-brief/5-tech-brief.md` |
| Feature dir | `/tech-brief docs/features/fp-brief/` | Extract key from path | `docs/features/fp-brief/5-tech-brief.md` |
| Feature doc | `/tech-brief docs/features/fp-brief/2-tech-spec.md` | Extract key from parent | `docs/features/fp-brief/5-tech-brief.md` |
| Non-feature | `/tech-brief /tmp/notes.md` | No feature context | Require `--output` |
| No argument | `/tech-brief` | Auto-detect (5-level cascade) | Based on resolved feature |

### Phase 2: Multi-Source Collection

Three-stage collection. See `references/source-guide.md` for detailed strategy.

**Stage 1 — Document Collection**: Read feature docs via `canonical_docs` (tech-spec, architecture, feasibility) and `doc_inventory` (implementation). All optional.

**Stage 2 — Code & Git Evidence**: `git log -20`, `git diff --stat`, read top 5 changed source files (100 lines each) for `file:line` references.

**Stage 3 — Request Selection**: Glob all request docs (no status filter — completed features are the primary use case), max 3 by date desc. Extract `## References` for threadIds and PR links.

### Phase 3: Synthesis

1. Build Source Provenance table (Section | Source Files | Confidence)
2. For each output section, extract content from mapped sources (see `references/output-template.md`)
3. Apply depth filter (section inclusion and detail level per depth matrix)
4. Apply Evidence Insufficient Rule: `[Source unavailable — no <type> found for this feature]`

### Phase 4: Output

See Save Behavior for output path resolution.

## Path Security

1. **Path normalization**: Resolve `..` and symlinks, verify repo boundary
2. **Traversal rejection**: Input containing `..` is rejected
3. **Output path**: `--output` allows repo-external paths (e.g. `/tmp/`), emit warning "writing outside repo"
4. **Secret redaction**: Before reading source docs, scan for high-confidence secret patterns (API keys, private keys) — high confidence: abort; medium confidence: mask `[REDACTED]`

## Depth Levels

| Level | Max Length | Description |
|-------|-----------|-------------|
| brief | ~500 words | Key points only — suitable for Slack sharing |
| normal | ~1500 words | Full coverage with source citations |
| deep | ~3000 words | Full coverage + code snippets + alternative comparison |

These are upper bounds, not targets. Source-thin features will produce shorter output.

## Output

See `references/output-template.md` for full template and depth matrix.

```markdown
# Tech Brief: <Feature Title>

> Feature: <key> | Depth: <level> | Generated: <timestamp>
> Sources: <list of docs read>

## Source Provenance
| Section | Source Files | Confidence |

## 1. Background & Problem
## 2. Design Decisions & Trade-offs
## 3. Implementation Highlights
## 4. Limitations & Known Issues
## 5. Discussion & References
## 6. Next Steps
```

### Save Behavior

| Condition | Output Path |
|-----------|------------|
| Default (feature resolved) | `docs/features/<key>/5-tech-brief.md` |
| `--output <path>` | Specified path (warn if outside repo) |
| `--no-save` | stdout only, no file written |
| No feature + no `--output` | Gate: Need Human |

Preferred canonical name: `5-tech-brief.md`. If `5-` prefix is occupied, use next available number.

## Verification

- [ ] Feature context resolved (5-level cascade or explicit)
- [ ] Path validation executed (no traversal, repo boundary)
- [ ] Secret redaction scan completed
- [ ] Source Provenance table present in output
- [ ] Each section cites source (or shows Missing Source marker)
- [ ] Output length within depth-level upper bound
- [ ] Evidence Insufficient markers used where source is thin

## References

- Output template: `references/output-template.md`
- Source collection guide: `references/source-guide.md`
- Feature context resolution: `@skills/tech-spec/references/feature-context-resolution.md`

## Examples

```
Input: /tech-brief seek-verdict
Action: Resolve feature → read tech-spec + request → git log → write 5-tech-brief.md

Input: /tech-brief --depth brief --output /tmp/sharing.md
Action: Auto-detect feature → collect sources → brief output → write /tmp/sharing.md

Input: /tech-brief docs/features/auto-loop-evolution/ --depth deep
Action: Extract key → read all docs + requests (top 3) → deep output with code snippets

Input: /tech-brief --no-save
Action: Auto-detect → collect → print to stdout (no file)
```

Files in this skill

  • SKILL.md7.2 KB
  • references/output-template.md5.2 KB
  • references/source-guide.md4.7 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.