Total Skills
15
Author Profile: chughtapan
Skills published by chughtapan with real stars/downloads and source-aware metadata.
Total Stars
0
Total Downloads
0
Skills Performance
Comparison chart based on real stars and downloads signals from source data.
architect
0
Stars
0
Downloads
0
implement-senior
0
Stars
0
Downloads
0
implement-staff
0
Stars
0
Downloads
0
orchestrate
0
Stars
0
Downloads
0
research
0
Stars
0
Downloads
0
spec
0
Stars
0
Downloads
0
typescript
0
Stars
0
Downloads
0
stamina
0
Stars
0
Downloads
0
Published Skills
architect
Turn an approved spec into a module layout: named modules, public interfaces, data flow, error channels, dependency choices. Produces a design doc (markdown) plus interface-stub files (function signatures with `throw new Error("not implemented")` bodies) so downstream `implement-*` modalities can execute against a published contract. Use when a spec exists and the next question is "what shape of code." Do NOT use when no spec exists (send to `/safer:spec` first), or when the work is obviously one-module (send to `/safer:implement-junior`).
Repository SourceNeeds Review
implement-senior
Cross-module coordination WITHIN an approved architect plan. May refactor internals across modules, add private helpers that span modules, and reorganize file layouts when the plan authorizes it. May NOT introduce new modules, new architectural patterns, new public contracts outside the plan, or new deps. Use when the architect plan explicitly covers multi-module work and the implementer needs to coordinate across them. Do NOT use for one-module work (route to `/safer:implement-junior`) or for introducing new modules/deps (route to `/safer:implement-staff`).
Repository SourceNeeds Review
implement-staff
Introduce new modules, new public interfaces, and new package dependencies in service of an approved spec. Every change traces back to a spec line. Staff does not revise the spec. Use when the spec explicitly names new architectural territory (a new module, a new API, a new dep) and someone has to build it. Do NOT use when the work fits inside an existing module (route to `/safer:implement-junior`) or when the plan is multi-module but stays within existing modules (route to `/safer:implement-senior`).
Repository SourceNeeds Review
orchestrate
Decompose a multi-step intent into sub-tasks, classify each by modality, route each sub-task to the right modality skill, gate every handoff on a published artifact, and track the whole pipeline via GitHub issues. Use when a goal spans more than one modality (not just implementation, not just investigation, not just research) or when sub-tasks have dependencies that need sequencing. Do NOT use for single-modality work — invoke the modality directly. This skill is the VP of Engineering.
Repository SourceNeeds Review
research
Run an iterative hypothesis loop on an open question with no known answer. Produces a ledger of claim, evidence, experiment, insight, and confidence for every round, closing with a final report of validated insights. Use when the question is open-ended ("how do X systems handle Y?", "why does Z regress under load?"), when literature review is load-bearing, or when the next step depends on answers the team does not have yet. Do NOT use when the question is a yes/no feasibility probe (route to /safer:spike) or when the work is to ship code (route to /safer:spec or /safer:implement-*).
Repository SourceNeeds Review
spec
Turn an ambiguous intent into a spec document: goals, non-goals, invariants, acceptance criteria, and open questions. Produces a written artifact that every downstream modality (architect, implement-*, verify) can read and execute against without needing the original conversation. Use when an intent is under-specified, when acceptance criteria are implicit, or when multiple reasonable interpretations exist and need to be narrowed. Do NOT use for architecture choices, library choices, or implementation work.
Repository SourceNeeds Review
typescript
TypeScript craft floor. The concrete projection of PRINCIPLES.md principles 1 through 4 onto TypeScript code. Invoked in-context by the implement-* skills when the target repo is TypeScript. Encodes the ideal repo state, the decision table between human-era shortcuts and agent-era full versions, the phrases that signal a shortcut is about to happen, and the mapping from eslint-plugin-agent-code-guard rules back to principles. Auto-applies when writing or reviewing .ts files outside of a /safer:spike branch.
Repository SourceNeeds Review
stamina
Fan-out review adapter. Routes a high-blast-radius artifact (plan or PR) through multiple heterogeneous review passes and gates on consensus. Does not review; dispatches existing review skills (/simplify, /review, /review-senior, /safer:dogfood, /codex, /security-review for PRs; /safer:dogfood + /safer:review-senior + /codex for plans) and aggregates their verdicts. N is set by the blast-radius x reversibility table in PRINCIPLES.md > Durability. Two invocation modes: --plan <sub-issue-URL> and --pr <pr-URL>. Use when the caller (typically /safer:orchestrate Phase 5c) has decided the artifact warrants stamina. Do NOT self-invoke from the working modality; that is Principle 5 self-polishing.
Repository SourceNeeds Review
dogfood
Read any published artifact (spec, design doc, PR body, issue comment, investigation writeup) with NO prior session context and report on how a cold-start consumer would feel picking it up. Scores four numeric axes (clarity, completeness, actionability, trust) plus a friction list with evidence, emits a SHIP / REVISE / REJECT verdict, and publishes the report back to the artifact's GitHub thread. Use when an artifact is about to be handed off and you want a portability check before the next modality runs. Do NOT use to rewrite the artifact; this is a reading modality, not a writing one.
Repository SourceNeeds Review
implement-junior
Fill in the internals of ONE module against a clear acceptance criterion. No public surface changes. No new deps. No cross-module reach. Use when the work is either (a) backed by an architect design doc that names the module and leaves only the body to write, or (b) an obvious-scope change like a bug fix, small feature, or added test that touches one module's internals. Do NOT use for refactors across modules (route to `/safer:implement-senior`), new modules or new public surface (`/safer:implement-staff`), or work without an approved plan.
Repository SourceNeeds Review
investigate
Reproduce a defect, isolate the failing code path, and name the root cause with file:line evidence. Produces a written writeup and a fix recommendation routed to the correct implementation modality. Use when a bug is reported, when production is misbehaving, or when a test fails for non-obvious reasons. Do NOT use to apply the fix; that is a separate modality. Investigation and remediation are different budgets.
Repository SourceNeeds Review
review-senior
Pre-merge code review for a PR. Reads the diff and the sub-issue acceptance criteria, then writes a native GitHub PR review (approve, request changes, or comment) with inline findings. Checks craft principles, scope alignment, and tests. Use when a PR is ready for senior review and before merge. Do NOT use to apply fixes; the author applies fixes. Review is a reading modality, not a writing one.
Repository SourceNeeds Review
spike
Answer one specific feasibility question with throwaway code and a go/no-go verdict. Use when the user asks "can we X?", "is Y tractable?", or "does this library actually do what it claims?". The output is a written verdict with evidence, not production code. Do NOT use when the question is open-ended (route to /safer:research) or when the implementation path is already known (go straight to spec + architect + implement).
Repository SourceNeeds Review
verify
Run the repo test suite and lint, check each acceptance criterion from the sub-issue against the diff and the test output, and emit a ship or hold verdict with evidence. Use immediately after a PR has passed senior review and before merge. Do NOT use to fix failing tests; fixing is a separate implement-* modality. Verify reads, runs, and reports.
Repository SourceNeeds Review
setup
One-time bootstrap for a TypeScript repo adopting safer-by-default. Detects the package manager, existing ESLint config, and tsconfig strict posture; installs eslint-plugin-agent-code-guard and companion rules; writes eslint.config.js in three blocks; flips tsconfig strict flags; probes that the lint actually fires on a known anti-pattern; reports the lint baseline and asks the user how to handle it. User-invoked only; never auto-routes. Safe to re-run; idempotent by construction.
Repository SourceNeeds Review