raisedadead/self-develop

Self-Develop — Steal the Best Bits, Learn from Our Own

Goal

Make the dp-cto flow so good that Claude runs on autopilot. Every pattern extracted, every comparison made, every verdict rendered serves this goal. Inputs can be external (repos, docs, blog posts) or internal (field notes, postmortems, session feedback).

Input

The user provides one of:

• External source: A URL, a resource name from specs/benchmarks/references/SOURCES.md, or a repo identifier for DeepWiki
• Internal feedback: A field note from specs/research/field-notes-*.md, a postmortem finding, or direct session observations
• Audit trigger: "what's changed", "check our sources", or "self-audit" — triggers a staleness scan of SOURCES.md

If a name is given without a URL, look it up in SOURCES.md first. If not found, ask.

Phase 1: Extract

For external sources

Read the resource thoroughly. Use WebFetch for URLs, DeepWiki (mcp__claude_ai_Deepwiki__read_wiki_structure then mcp__claude_ai_Deepwiki__read_wiki_contents) for repos.

For internal feedback

Read the field note or feedback. Identify concrete improvement proposals — not vague observations, but specific mechanisms that could change.

For audit triggers

Scan SOURCES.md Last Audited dates. Flag resources >30 days stale. Present the stale list and ask the user which to re-evaluate. Then proceed with each selected resource as an external source.

Pattern cards

Before producing cards, read the current dotplugins codebase state for each pattern area. Check hooks (plugins/dp-cto/hooks/), agents (plugins/dp-cto/agents/), skills, shared/ files, and lib/. Do not guess what "we do" — verify by reading the actual file.

For each concrete pattern found, produce a card:

### [Pattern Name]

**Source:** [url, repo, or field note path]
**What they do / What was observed:** [specific mechanism or finding]
**What we do:** [cite the actual file:line, or "nothing"]
**CTO flow phase:** [plan / run / review / cross-cutting]
**Gap:** [the specific delta — what is missing, or why their mechanism is better/worse]

Concrete means: "They dispatch agents with a typed envelope that includes retry policy" — not "They have good architecture."

When we already have a mechanism for the same purpose, the card is a mechanism comparison, not a gap card. "We do this differently" is not a gap — "their way prevents a failure class ours doesn't" IS a gap.

Present all cards to the user. Ask: "These are the patterns I found. Add any? Remove any? Then I'll run the comparison."

Phase 2: Compare — Adversarial and Appeasing

For each pattern, run TWO lenses back to back. No hedging. Real talk.

Adversarial Lens

Argue AGAINST adoption/change. Be specific:

• Architecture mismatch — Does this require runtime, build steps, or infra we don't have? Our stack is Markdown skills + shell hooks + beads.
• Solving a phantom problem — Have we actually been burned by this absence? Check the cabinet, postmortems, and session history. Theoretical pain is not pain.
• Complexity tax — What maintenance burden does this add? More hooks, more state, more failure modes.
• Worse than what we have — Are we already doing this better? Don't adopt lateral moves.

Appeasing Lens

Argue FOR adoption/change. Be equally specific:

• Autopilot impact — Does this reduce CTO turns per run cycle? Be specific: "saves ~N turns" or "eliminates manual X step."
• Failure class prevention — Does this prevent a known failure class? Reference postmortems or cabinet items.
• Agent quality — Better receipts, fewer fabrications, tighter scope, faster convergence.
• Token efficiency — Does this reduce per-dispatch cost or eliminate unnecessary dispatches?
• Compounding value — Does this get more valuable over time?

Verdict

After both lenses, deliver a verdict for each pattern:

### [Pattern Name] — ADOPT / ADAPT / SKIP

**Adversarial:** [1-2 sentences — strongest argument against]
**Appeasing:** [1-2 sentences — strongest argument for]
**Verdict:** [ADOPT/ADAPT/SKIP] — [why this verdict wins]
**If ADAPT:** [what changes to make it fit]
**CTO flow phase:** [plan / run / review / cross-cutting]
**Autopilot impact:** [none / incremental / significant / transformative]
**Effort:** quick-win / planned-work / next-major

Ask the user to confirm or override verdicts before Phase 3.

Phase 3: File

For each ADOPT or ADAPT pattern:

• quick-win: File in the cabinet via /dp-cab:file with source link, pattern description, adoption approach, and which part of the CTO flow it improves. Tag P2 or P3. After filing, add the self-develop:pending label: dp-engine label-add "{task-id}" "self-develop:pending".
• planned-work: File as a cabinet item with enough context for a future /dp-cto:plan session. Include the adversarial/appeasing summary so the planner has context. After filing, add the self-develop:pending label: dp-engine label-add "{task-id}" "self-develop:pending".
• next-major: Note in the next major version feature request as a consideration, don't file separately.

After filing, report the summary (see below), then proceed to Phase 4.

Phase 4: Record Decision

Write an ADR to specs/decisions/ADR-NNN-{source-name}.md. Auto-number by scanning existing ADR files.

Format:

# ADR-NNN: [title]

Date: [today]
Status: Accepted

## Context

[1-2 sentences: what was evaluated and why]

## Decision

[Shipped/Filed/Skipped tables from the summary]

## Consequences

[Key architectural insights, what follows from this batch]

Present the draft to the user: "Write this ADR? (yes / edit / skip)"

After writing the ADR, append an entry to specs/INDEX.md under the Decisions (ADRs) section.

After writing the ADR, update the Last Audited column in specs/benchmarks/references/SOURCES.md for the evaluated resource to today's date.

Summary

- **Ingested:** [N] patterns from [source type: external/internal/audit]
- **ADOPT:** [N] ([list])
- **ADAPT:** [N] ([list])
- **SKIP:** [N] ([list])
- **Filed:** [N] cabinet items
- **Autopilot impact:** [aggregate assessment]

Principles

• Read the actual resource, don't summarize from memory. If WebFetch fails, say so — don't fake it.
• Read the actual codebase before claiming "what we do." If you can't cite file:line, you don't know.
• One source per invocation. Don't batch multiple resources.
• Concrete patterns only. "They have good architecture" is not a pattern.
• The user decides, not the skill. Present findings, let the user override any verdict.
• The adversarial lens is not decoration. If you can't find a real argument against, the pattern is obvious — ask why it isn't already adopted.
• The appeasing lens is not cheerleading. If the best argument is "it's a nice idea," that's a SKIP.
• Internal feedback is first-class. Operational pain from our own usage is higher-signal than external patterns.
• Phase 4 (ADR) is for batches and significant decisions. For single quick-wins from internal feedback, skip the ADR — the cabinet item is sufficient. Ask the user.