← all publishers

davidlee

@davidlee source repo

Report this profile Claim this profile

• 35 skills
• 0 followers
• 6 hours ago last updated

1. ▌
   Pair · davidlee

   Agentic pair programming — drive a change together with a human partner in the loop, narrating intent and pausing at decision points. Use when the user wants to work side-by-side rather than hand off a whole task. Calibrated by three dials (role, detail, autonomy) and an always-on challenge mandate.
   0
   installs
2. ▌
   Plan · davidlee

   Use when a slice's design is locked and it needs an executable phase plan — refine each phase's objective and entry/exit/verification criteria, author plan.toml + plan.md, and materialise the runtime phase sheets. Routed to from /design.
   0
   installs
3. ▌
   Audit · davidlee

   Use after a slice's phases are implemented, when the task is now evidence, conformance, and reconciliation against the design — disposition every finding on a reconciliation review ledger (the RV kind) before closure.
   0
   installs
4. ▌
   Canon · davidlee

   Use before making architectural or workflow choices, when correctness depends on project governance, or when entering an unfamiliar subsystem — to load the project's authoritative rules before you act on assumptions.
   0
   installs
5. ▌
   Close · davidlee

   Use to formally close a slice once its phases are complete, audited, and reconciled — confirm the rollup, verify spec-coherence, harvest durable findings, reconcile lifecycle status, and land a clean final commit. Routed to from /reconcile.
   0
   installs
6. ▌
   Route · davidlee

   Use at the very start of ANY substantive work in a Doctrine repo — before inspecting files, running commands, or writing code. The mandatory gate that chooses the governing skill. Skip it only when the user has explicitly told you to.
   0
   installs
7. ▌
   Slice · davidlee

   Use when code-changing intent has emerged and there is no governing slice yet — to scope the change into a slice (scope document + metadata) before any design or implementation. Routed to from /route.
   0
   installs
8. ▌
   Design · davidlee

   Use when a slice needs architectural shaping before implementation — decision triage, critical analysis of tradeoffs and solutions, and section-by-section validation of design.md until the decisions lock. Routed to from /route once a slice exists.
   0
   installs
9. ▌
   Elicit · davidlee

   Use when running a value-elicitation session — surfacing and asking the next worthwhile pairwise value questions, reviewing suspect anchors, or calibrating value evidence with a human via `doctrine compare elicit`.
   0
   installs
10. ▌
    Rigour · davidlee bundle

    Use when operating at the edge of your capacity — high complexity, deep uncertainty, unfamiliar territory, expensive context — and being confidently wrong would be costly. A conduct posture layered onto whatever skill governs the stage; it changes how you work, not which work you do.
    0
    installs
11. ▌
    Backlog · davidlee

    Use when the user wants to create, survey, triage, tag, or transition a doctrine backlog item (issue / improvement / chore / risk / idea) — `doctrine backlog` is the CLI surface; use this skill to drive the correct verb for the intent.
    0
    installs
12. ▌
    Consult · davidlee

    Use the moment you hit an unanticipated obstacle, a decision with competing tradeoffs, or emergent complexity mid-task — before adapting planned scope, adding a dependency, taking a shortcut, or making any impactful concession on your own.
    0
    installs
13. ▌
    Execute · davidlee

    Use to implement one planned, approved phase of a slice — once its design and plan exist and its runtime phase sheet is ready. Move the phase to in_progress, build it TDD red/green/refactor, keep notes current, end green, and surface blockers early.
    0
    installs
14. ▌
    Harvest · davidlee

    Use at the end of any coherent unit — a phase, task, review close, or slice wrap — to sweep what the unit produced, learned, and left open into their durable sinks, and to maintain the Harvest section of the governing slice's notes.
    0
    installs
15. ▌
    Dispatch · davidlee

    Use to drive a slice's phases to completion through confined subprocess workers in isolated worktrees — you orchestrate and are the sole writer, the workers execute. Workers spawn via `/dispatch-spawn`, one path for every harness. You drive the landing yourself — import, commit, record, verify, conclude, reap; `doctrine dispatch next` prescribes only for a fork bound at creation, which this path does not mint. Default serial (one worker per phase); parallelize file-disjoint phases. Conflicts report-and-halt, never auto-merge.
    0
    installs
16. ▌
    Dreaming · davidlee

    Unified memory corpus maintenance — covers both reactive (change-triggered) and proactive (periodic/idle-time improvement) paths. One skill, two entries.
    0
    installs
17. ▌
    Feedback · davidlee

    Use when receiving feedback on your work — review findings, user corrections, audit results, external reviewer notes — to triage by authority, adjudicate each point on evidence, integrate without regressions, and close the loop with the source. Evidence flips positions; assertions don't.
    0
    installs
18. ▌
    Handover · davidlee

    Use when handing work to a fresh context — first bring the durable harvest current, then emit a continuation at one of two weights — a printed continuation prompt (light) or a handover.md context packet (full). Use whenever a fresh agent would more efficiently continue.
    0
    installs
19. ▌
    Research · davidlee

    Use when a slice is scoped but not yet designed — run the pre-design research round and persist its evidence artefact — or when a consuming skill's staleness advisory reports drift. Produces a cited, verification-legended research.md that design and plan load-bear instead of recall.
    0
    installs
20. ▌
    Worktree · davidlee bundle

    Use when work needs isolation from the current workspace — when /execute (mode=solo) or the /dispatch funnel must run a phase on its own branch without touching the main working tree. Detects existing isolation, creates a fork via `doctrine worktree fork` (the sole creation+provision+bind verb; coordination tier excluded), runs the commit-before-spawn / branch-point / baseline guards, and hands back the fork branch.
    0
    installs
21. ▌
    Knowledge · davidlee

    Use when work surfaces something epistemic worth keeping — "we're assuming / proceeding as if X", "we decided X over Y", "open question worth outliving this session", "we're bound by X", "evidence for/against X", "testable hypothesis", or a stable concept worth naming — and when settling, relating, or surveying such records. Routes capture, settle, and survey intent to the correct `doctrine knowledge` verb.
    0
    installs
22. ▌
    Preflight · davidlee

    Use after routing has chosen this path, when the next step is bounded up-front research to understand a substantive task, surface unknowns and tensions, and assess readiness — without drifting into implementation or open-ended exploration.
    0
    installs
23. ▌
    Reconcile · davidlee

    Use after /audit resolved the RV ledger and wrote the reconciliation brief — you are the sole explicit writer of reconciled truth. Consume the RV + brief, write changes through two surfaces (direct edit for per-slice artefacts, REV for governance/spec), and hand off a resolved outcome to /close. Routed to from /audit.
    0
    installs
24. ▌
    Spec Tech · davidlee

    Use when authoring or revising the technical specification — the how of a capability, downstream of the product spec and upstream of per-slice design. Use to record durable architecture and mechanism, not a single change's design.
    0
    installs
25. ▌
    Phase Plan · davidlee

    Use just before executing a specific phase — expand its authored plan entry (objective + EN/EX/VT) into the disposable runtime phase sheet with a concrete task breakdown, assumptions, and verification steps. Routed to from /plan or /execute.
    0
    installs
26. ▌
    Code Review · davidlee

    Use whenever reviewing code for quality and correctness — a diff, PR, module, or subsystem — producing verified, severity-ranked findings on the RV ledger. Not for comprehension tours (walkthrough) or doctrine-conformance hunts (inquisition, user-invoked only).
    0
    installs
27. ▌
    Inquisition · davidlee

    Use only when the user explicitly requests an "inquisition" (e.g. "seek out heresy", "begin an inquisition", "inquisition on X") to hunt adversarially for deviations from doctrine, design, plan, conventions, or acceptance criteria. Do NOT use for routine "review X" or ordinary code review.
    0
    installs
28. ▌
    Walkthrough · davidlee

    Guided walkthrough of code, a diff/PR, architecture, tests, or docs — build the reader's mental model, explain the choices made and their tradeoffs, and critically evaluate the artifact. Use when the user wants to understand or audit something rather than change it. Adapts to expert vs learner; companion to the pair skill.
    0
    installs
29. ▌
    Spec Product · davidlee

    Use when authoring, revising, normalising, or reviewing a doctrine product specification/PRD - the durable product intent, requirements, success measures, behaviours, and verification basis for an evergreen capability. use before creating or scoping slices that descend from shared product intent. use when a request asks for product requirements, functional requirements, non-functional requirements, product scope, acceptance gates, out-of-scope boundaries, success measures, or agent-readable product context. do not use for one-off change planning, implementation design, technical architecture, or phase execution.
    0
    installs
30. ▌
    Record Memory · davidlee

    Use when you discover or confirm a durable fact, constraint, invariant, convention, sharp edge, footgun, or reusable workflow that a future agent would otherwise rediscover — capture it before it is lost to conversation context. Triggers at phase/slice wrap-up too.
    0
    installs
31. ▌
    Capsule Driver · davidlee

    Use to drive a slice's phases to completion through in-session capsule subagents in the MAIN worktree — you are the super-orchestrator seat, spawning capsule-orchestrators that each charter 2-4 phases and spawn their own planners and workers. No worktrees, no dispatch, no confinement. Use when you want a whole slice implemented under a tight context budget without handing the tree to confined workers. Not for confined or parallel-worktree execution — that is /dispatch.
    0
    installs
32. ▌
    Dispatch Spawn · davidlee

    The one spawn path for `/dispatch` — `scripts/spawn-confined.sh <harness>` forks the worker's worktree, wraps it in a kernel-level jail, and runs the harness headless inside it. Every harness takes this path; there is no in-session arm and no unconfined fallback. The worker cannot commit — it hands back an uncommitted working tree and the orchestrator imports it. Reached from the `/dispatch` router; do not invoke directly.
    0
    installs
33. ▌
    Retrieve Memory · davidlee

    Use before making non-trivial assumptions — before touching a subsystem you have not this session, before running or changing a command pipeline, when code and docs conflict, when asked "what is the right way here?", when debugging a recurring failure, or when about to answer with "probably/usually/likely".
    0
    installs
34. ▌
    Reviewing Memory · davidlee

    Structured audit for stability gates — before releases, migrations, large refactors, or when agent confusion is detected. Use to prune, correct, and re-anchor the memory corpus before it drifts past useful.
    0
    installs
35. ▌
    Spec Coverage Assessment · davidlee

    Use when a named subsystem, capability, or code surface needs governance coverage assessed before authoring a spec — deciding what is already governed by an existing PRD / tech spec / ADR, what is dark, and where new spec boundaries should fall by product altitude and C4 level. Use before creating or scoping a product or technical spec for an unfamiliar or partially-governed surface. Use when a request asks to "assess coverage", "find governance gaps", "what's already specified", "where should this spec's boundary sit", "one spec or several", "what needs a PRD vs a tech spec", or "is this subsystem properly documented". Produces a reviewable coverage-map artifact that feeds `/spec-product` and `/spec-tech`. Do not use when the target spec and its boundary are already known and unambiguous — go straight to `/spec-product` or `/spec-tech`. Do not confuse with `doctrine coverage` — unrelated CLI verb for requirement verification.
    0
    installs