forsonny
- 34 skills
- 0 followers
- 12 hours ago last updated
- ▌ Judging · forsonnyDispatch the Court on evidence-only inputs (contract + diff + verify output + confidence). The Court is not a persona; it is a structured adjudicator.
- ▌ Planning · forsonnyDecompose a confirmed contract into an atomic task DAG with wave ordering. Every task cites one or more contract criterion ids.
- ▌ Executing · forsonnyDispatch one fresh subagent per plan task inside a per-task git worktree. Capture diff and tool output; never carry state across dispatches.
- ▌ Resetting · forsonnyOn verify or judge fail, append a non-null lesson to the Ledger and re-queue the task. Null lessons are refused; the task escalates instead.
- ▌ Verifying · forsonnyRun the four verification probes (Exists, Substantive, Wired, Functional) per criterion. All four green per criterion or the criterion fails.
- ▌ Contracting · forsonnyAuthor a machine-readable contract before execution. Produces anvil/contract.yml with four verification-level slots per criterion and Ledger-sourced counter-examples.
- ▌ Using Anvil · forsonnyBootstrap loader for the DG-Anvil plugin. Enumerates the five primitives, seven skills, five commands, and the core loop. Loaded at session-start.
- ▌ Authoring Skills · forsonnyMeta-skill governing every change to any skill file. Requires a RED-then-GREEN subagent pressure transcript before a skill change is accepted.
- ▌ Plan Novel · forsonnyCreate or substantially revise a novel premise, structure, chapter plan, character arcs, and required world foundations. Use for a new novel or major structural replan.
- ▌ Write Chapter · forsonnyDraft the next chapter or a specified chapter from the accepted outline while preserving manuscript continuity, character knowledge, and established voice.
- ▌ Revise Chapter · forsonnySubstantively revise a specified chapter for structure, prose, character, pacing, or continuity while preserving its intended story function and established voice.
- ▌ Continuity Pass · forsonnyAudit a chapter range or current manuscript for contradictions, timeline errors, knowledge leaks, rule violations, and unresolved continuity risks.
- ▌ Finalize Manuscript · forsonnyReview a substantially complete manuscript for structural gaps, continuity problems, unresolved promises, chapter order, and revision priorities before final polish.
- ▌ Brainstorming · forsonny bundleUse when the human partner asks to build, add, change, or modify anything (features, components, functionality, behavior). Explores intent, requirements, and design before implementation. Hard-gated; nothing implements until the human partner approves the written product spec.
- ▌ Using Leyline · forsonny bundleUse when starting any conversation - establishes how to find and use Leyline skills, requiring a Skill check before any response including clarifying questions.
- ▌ Writing Plans · forsonny bundleUse when you have approved specs and a clean worktree with a green baseline, before any code is written. Decomposes the specs into 2-5 minute tasks with exact file paths, complete code, and verification. Runs inside the worktree from stage 3; hands off to subagent-driven-development or executing-plans.
- ▌ Deep Discovery · forsonny bundleUse after the product spec is approved, before any implementation work. Pressure-tests the spec with a 100-question self-interrogation where each question builds on the previous answer. Returns critical issues, strengths, and a revised proposal. Material revisions loop back to brainstorming.
- ▌ Writing Skills · forsonny bundleUse when authoring a new skill for the Leyline plugin, modifying an existing skill's behavior-shaping text, or adding to the testing-anti-patterns / forbidden-phrases lists. Applies TDD-for-prose - baseline pressure test without the skill, write the minimal skill text that rebuts the observed rationalizations, verify compliance, refactor against new loopholes.
- ▌ Executing Plans · forsonnyUse when a committed plan exists, the harness does NOT support subagent dispatch, and the implementation is ready to begin. Executes the plan inline with human-partner checkpoints, task-by-task. Fallback to subagent-driven-development; hands off to stage 7 review on completion.
- ▌ Using Git Worktrees · forsonnyUse when starting feature work that needs isolation from the current workspace, or before executing implementation plans. Creates an isolated git worktree with systematic directory selection and a green-baseline test gate. Runs after Interrogate, before Plan.
- ▌ Design Brainstorming · forsonny bundleUse when the approved product spec touches any user-facing surface, before any implementation skill runs on that surface. Explores flows, states, accessibility, and voice. Hard-gated; nothing implements until the human partner approves the written UX spec.
- ▌ Design Interrogation · forsonny bundleUse at stage 2 after the UX spec has been approved and deep-discovery has cleared the product spec, when scope warrants dedicated UX pressure-testing. Runs a 100-question interrogation targeted at flows, state completeness, accessibility, voice, and platform appropriateness. Material revisions loop back to design-brainstorming.
- ▌ Systematic Debugging · forsonnyUse when any bug, test failure, or unexpected behavior surfaces, before proposing or applying any fix. Enforces four sequential phases (root cause investigation, pattern analysis, hypothesis formation, verification) and blocks fix proposals until root cause is identified. An overlay during stage 5.
- ▌ Receiving Code Review · forsonnyUse when receiving code review feedback, before implementing any suggestion. Drives the READ -> UNDERSTAND -> VERIFY -> EVALUATE -> RESPOND -> IMPLEMENT response pattern one finding at a time. Blocks performative agreement and blind implementation.
- ▌ Requesting Code Review · forsonnyUse at stage 7 after all tasks complete and before merging, to verify the entire feature meets requirements. Dispatches the code-reviewer subagent with branch-level constructed context (SHAs, plan excerpt, product spec reference, review log). Per-task quality review is a separate Stage 5 path via code-quality-reviewer-prompt.md; do not invoke this skill per-task.
- ▌ Receiving Design Review · forsonnyUse when receiving design review feedback, before implementing any UX or accessibility suggestion. Drives the same READ -> UNDERSTAND -> VERIFY -> EVALUATE -> RESPOND -> IMPLEMENT pattern as receiving-code-review, with additional forbidden phrases that block UX-specific performative agreement and taste-based dismissal.
- ▌ Test Driven Development · forsonny bundleUse when implementing any feature, bug fix, refactor, or behavior change, before any production code is written. Enforces RED-GREEN-REFACTOR. The failing test is written first, observed failing for the right reason, then the minimal code that passes is written. An overlay on every stage-5 code task.
- ▌ Requesting Design Review · forsonnyUse when completing any task or feature that touches a user-facing surface, before merging a branch with UX changes. Dispatches the design-reviewer subagent in parallel with requesting-code-review, with constructed context (UX spec path, surfaces touched, accessibility evidence, SHAs).
- ▌ Design Driven Development · forsonnyUse when implementing any task whose "Files:" block touches a user-facing surface, before writing the code for that surface. Enforces the DRAW-BUILD-RECONCILE cycle: the UX artifact is the source of truth, the implementation instantiates it, and any divergence is resolved explicitly. An overlay during stage 5 alongside test-driven-development.
- ▌ Accessibility Verification · forsonnyUse whenever you are about to claim a user-facing surface is complete - before committing, before marking the task done, before any success claim. Requires running an accessibility check fresh in the current message and reading its output before any completion claim. An overlay during stage 5 alongside verification-before-completion.
- ▌ Dispatching Parallel Agents · forsonnyUse during stage 5 execution when two or more genuinely independent problems surface at the same time, each understandable without context from the others. Dispatches one fresh subagent per problem concurrently. Not a pipeline stage; a tactical skill called from within subagent-driven-development.
- ▌ Subagent Driven Development · forsonny bundleUse when a committed plan exists in the worktree, the harness supports subagent dispatch, and the implementation is ready to begin. Dispatches a fresh subagent per task (implementer, spec reviewer, code-quality reviewer, plus design reviewer when surfaces are touched). Hands off to stage 7 review on completion.
- ▌ Finishing A Development Branch · forsonnyUse when implementation is complete, Stage 7 reviews are cleared, and the branch is ready to integrate. Verifies tests fresh, determines base branch, presents four options (merge local / push and PR / keep / discard), executes the chosen path, and cleans up the worktree. Pipeline terminates here.
- ▌ Verification Before Completion · forsonnyUse whenever you are about to claim that work is complete, fixed, or passing - before committing, creating a PR, or reporting status. Requires running the verification command fresh in the current message and reading its output before any claim is made. An overlay during stage 5 and every handoff in the pipeline.